Странно тема переместилась, чтоли? Тогда не понятно почему тема посвящённая полностью железу, оказалась в разделе Software.
Вид для печати
Странно тема переместилась, чтоли? Тогда не понятно почему тема посвящённая полностью железу, оказалась в разделе Software.
Да.
Уже обсуждалось, считай, что она не в софте, а вообще где-то между. Т.е. не обращай внимания.
А всякое "железо" неспектрумовской национальности переносится именно сюда, если не попадает под категории отечественных или зарубежных компьютеров.
Т.е. "просто электроника" живет в "Разном".
Цитата:
Сообщение от Viktor2312
Могу только сослаться на pdf'ки, например вот. Значение взято при VCC = +5.0V ± 10%, Tamb = –40°C to +85°C, CL = 50pF, RL = 500W.Цитата:
Сообщение от ZEK
Для серии К155, которая аналогична серии 74 без всяких букв, значение будет в районе 27 нс (см. вот тут).
Двунаправленных не использую, но как же обойтись без буферов с Z-состоянием??? Шины же...Цитата:
Сообщение от ZEK
Который внесет свою дополнительную задержку.Цитата:
Сообщение от ZEK
Юзаю PROM AM27S19SA 15 нс (32х8). Такой быстрой SRAM не нашел.Цитата:
Сообщение от ="ZEK"
Что-то нереально дорого. Это для какого техпроцесса? Мы же тут не об уровне Core-подобных процессоров говорим.Цитата:
Сообщение от spensor
Везде пишут, что наоборот - ниже за счет меньшей разницы напряжений для лог. уровней.Цитата:
Сообщение от CodeMaster
Нет, ЭСЛ - увольте. Да и частота - не самоцель.
---------- Post added at 14:52 ---------- Previous post was at 14:47 ----------
Для себя придумал следующее по кол-ву вентилей на лог. элемент:
NOT - 1; NAND, NOR, NXOR - 2; AND, OR, XOR - 3; каждый выход (простой, HI-Z) - 2; один бит PROM - 1. При этом выходы учитываются только те, которые идут непосредственно на пины процессора или на внутренние шины с HI-Z состоянием. Кол-во вентилей от кол-ва входов лог. элемента не зависит - скорее всего должны быть использованы многоэммитерные транзисторы на входы. Поправьте если где-то грубо соврал.
За что купил, за то и продал, такая цифра пролетала в разговоре с разработчиками специализированных БИС, уровень интеграции сопоставим c кодером PAL. Возможно это были понты, с целью продать чип подороже, но другой информацией не располагаю.Цитата:
Сообщение от e2e4
В любом случае за информацию спасибо, однако цифра просто не поместилась в голове. ИМХО с помощью древнего аналогового искусства фотодела (:)) вполне можно создавать чипы с малой степенью интеграции (насколько я это себе представляю). Ну не стоит эта технология 100к $ за итерацию!Цитата:
За что купил, за то и продал, такая цифра пролетала в разговоре с разработчиками специализированных БИС, уровень интеграции сопоставим c кодером PAL. Возможно это были понты, с целью продать чип подороже, но другой информацией не располагаю.
Может быть, имеются в виду разные вещи.
e2e4, хотелось бы таки "понюхать" вашу систему команд.
Да вот, готовлю более-менее удобный к прочтению текстик. Кроме системы команд надо регистровый файл еще описать. Вкратце идея следующая: любая команда - 8 бит. Без исключений. Операндов нет. Это сильно упрощает декодер команд, сокращает обращения к памяти и, соответственно, кол-во тактов на команду. А вот АЛУ, все регистры - 16 битные. Соответственно, надо как-то впихнуть в 256 команд все необходимое, да еще так, чтобы было не сильно хуже, чем у настоящих процессоров. Основная проблема - это загрузка 16-битной константы.Цитата:
e2e4, хотелось бы таки "понюхать" вашу систему команд.
При этом, система команд - не MISC в ее стандартном понимании (стек-машина). А все-таки, более-менее классическая.
В ближайшее время выложу.
Ну мы же говорим не о уровне детализации и плотности 155ЛА3, а о БИС с количеством транзисторов порядка 10-100тыс на кристале в 1мм2, и скоростью переключения от 100нс и меньше. Фотодело тут слабо катируется ввиду того что это гальваника полупроводниковых материалов. Эта технология недоступна ввиду дороговизны и крупным предприятиям, вследствии того что окупаемость наступает при сериях чипа в сотни тысяч. В иных случаях применяют полузаказные маричные чипы, ПЛИС или модули (функционально завершенное устройство, по сути эволюция гибридных микросхем). Даже технология PCB продолжает оставаться дорогой для того чтобы иметь собственные производственные мощности, что уж говорить о технологиях требующих на три и более порядков тонкие процессы, сверх чистые помещения и все такое прочее. А технология требует как реальных затрат на материалы, так и очень больших амартизационных отчислений. Так что цена производства чипов приближенно близка к реальной, пусть не 100 тыс, но 10 тыс $ наверняка, иначе бы в производстве мы бы видели совершенно другую картину - жесткая логика куда приемлемее в работе программируемых контроллеров и ПЛИС.Цитата:
Сообщение от e2e4
С интересом просмотрел вашу тему. Если дело в итоге сдвинулось хоть на миллиметр, не расскажете, что уже есть на сегодня?
Можно. Вспоминается, что когда начиналаcь известная фирма Интел, Гроув лично ходил в магазин выбирать подходящие объективы. Если нужна точная цитата, придется искать и вспоминать где именно это встретилось (быстро не нашлось, сам бы перечитал).Цитата:
В любом случае за информацию спасибо, однако цифра просто не поместилась в голове. ИМХО с помощью древнего аналогового искусства фотодела () вполне можно создавать чипы с малой степенью интеграции (насколько я это себе представляю).
"Эта технология" -- если говорить о совр. процессах -- стоит намного больше. Один набор масок может стоить миллионов 5 (я давно перестал отслеживать тему, навскидку вспоминается $2M для 65nm (могу ошибиться с нодом), все это можно быстро найти), а это лишь отдельно взятая статья расходов всего цикла.Цитата:
Ну не стоит эта технология 100к $ за итерацию!
Может быть, имеются в виду разные вещи.
Спасибо!Цитата:
С интересом просмотрел вашу тему.
Именно этот исторический период и именно команду под руководствам Энди Гроува я и имел ввиду, когда писал про фотографию и производство чипов :).Цитата:
Можно. Вспоминается, что когда начиналаcь известная фирма Интел, Гроув лично ходил в магазин выбирать подходящие объективы.
Дело сдвинулось, да. Во-первых, придумать-то систему команд я придумал (всего 256 команд). И загрузка 16-битной константы осуществляется за 3 команды (24 бита, 3 такта), что не хуже, чем если иметь префикс операции (8 бит) + 16-битная константа (16 бит) = те же 24 бита. Правда в моей системе команд загрузка константы возможна только в один регистр (условно назвал его аккумулятор, хотя это не аккумулятор в классической его трактовке). Когда дело оставалось за малым - всего-то нарисовать схему устройства управления и, как ее часть - декодера команд, то тут обозначился полярный пушной зверек. Во-первых, что-то около 60 сигналов управления (это после тщательной оптимизации). Во-вторых, декодер команд реально построить только на EEPROM (60/8 = около 8 EEPROM 16k x 8 = 128 кбайт прошивки), в-третьих, когда оставалось еще чуть-чуть чтобы довести дело до конца, я понял все уродство такого дизайна, и потер его нафиг.Цитата:
Если дело в итоге сдвинулось хоть на миллиметр, не расскажете, что уже есть на сегодня?
Сейчас потихоньку (в качестве упражнения для ума) думаю над такой концепцией:
1. Длина команды = разрядности шины данных = разрядности шина адреса = разрядности АЛУ = 16 бит.
3. Ну и набор из 7 регистров, 1 из которых - PC, другой - условно SP (условно потому, что автоматически инкрементируется при чтении, при записи - не декрементируется, это надо делать вручную). Каждый регистр может адресовать память. Присутствует механизм записи 16-битной константы за одну команду в любой регистр с использованием регистра PC. Присутствует механизм прерываний (примитивный, всего одно маскируемое прерывание). Присутствует механизм чтения/записи одного 16-битного порта ввода/вывода, который при желании с помощью внешней логики может быть отремаплен в пространство памяти. Также изначально раздельные пространства памяти программ/данных, но их также можно с помощью внешней логики объединять.Цитата:
2. Команда имеет вид:
xccfmmdddaaaoobb
x - top secret :)
cc - operation execute condition
00 execute always
01 execute if FC=...
10 execute if FZ=...
11 execute if FZ=...
f - flags
0 do not alter flags
1 alter flags
mm - memory addressing
00 none
01 *aaa
10 *ddd
11 ...
oo - operation, altered flags (when f = 1)
00 OP1 ,z
01 OP2 ,z
10 OP3 ,c, z
11 OP4 ,c, z
ddd - destination = aaa - first arg OP bb - second arg.
Главное - все операции донельзя примитивны и выполняются за одинаковое число тактов (в идеале - в 1, но к этому не стремлюсь, это, только лишь вопрос частоты внешнего тактового генератора), в том числе - загрузка константы и вход/выход из прерывания.
Как-то так. Пока более подробно делиться не хочу. Пишу эмулятор, в котором хочу попробовать написать простеньое приложение с рисованием линий по Брезенхаму и т.п. для того, чтобы "прочувствовать" недостатки и ограничения архитектуры.