Стандартная логика - схемотехника

[Viktor2312]

Странно тема переместилась, чтоли? Тогда не понятно почему тема посвящённая полностью железу, оказалась в разделе Software.

[Advertiser]

[Ewgeny7]

Странно тема переместилась, чтоли?

Да.

Тогда не понятно почему тема посвящённая полностью железу, оказалась в разделе Software

Уже обсуждалось, считай, что она не в софте, а вообще где-то между. Т.е. не обращай внимания.
А всякое "железо" неспектрумовской национальности переносится именно сюда, если не попадает под категории отечественных или зарубежных компьютеров.
Т.е. "просто электроника" живет в "Разном".

[e2e4]

12нс, что-то многовато, для К155 серии указано максимальное значение 10нс, как и К555.

А 12нс для F это скорее всего при температуре 90 градусов и максимальной нагрузке на выходы,

Могу только сослаться на pdf'ки, например вот. Значение взято при VCC = +5.0V ± 10%, Tamb = –40°C to +85°C, CL = 50pF, RL = 500W.

Для серии К155, которая аналогична серии 74 без всяких букв, значение будет в районе 27 нс (см. вот тут).

Что бы добиться максимальной скорости нельзя юзать двунаправленные буферы и Z состоянием, переключение направления и вход/выход в/из Z состояния самые медленные операции.

Двунаправленных не использую, но как же обойтись без буферов с Z-состоянием??? Шины же...

вместо того что бы нагружать цепь несколькими источниками надо делать мультиплексор,

Который внесет свою дополнительную задержку.

Если архитектура не RISC можно поюзать SRAM для микрокода, количество сэкономленной логики на декодере команд и устройстве управления может с лихвой покрыть колво микрух нужных для загрузки SRAM, но это не чистая логика, можно ПЗУ но оно медленное.

Юзаю PROM AM27S19SA 15 нс (32х8). Такой быстрой SRAM не нашел.

А что до цены, по доступной информации порядка 100тыс.$ за итерацию производства (подготовка производства, изготовление кремниевой пластины).

Что-то нереально дорого. Это для какого техпроцесса? Мы же тут не об уровне Core-подобных процессоров говорим.

ну в принципе можно отдельные узлы конечно и на ЭСЛ построить, у неё устойчивость к помехам лучше.

Везде пишут, что наоборот - ниже за счет меньшей разницы напряжений для лог. уровней.

Нет, ЭСЛ - увольте. Да и частота - не самоцель.

---------- 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 состоянием. Кол-во вентилей от кол-ва входов лог. элемента не зависит - скорее всего должны быть использованы многоэммитерные транзисторы на входы. Поправьте если где-то грубо соврал.

[spensor]

Что-то нереально дорого. Это для какого техпроцесса? Мы же тут не об уровне Core-подобных процессоров говорим.

За что купил, за то и продал, такая цифра пролетала в разговоре с разработчиками специализированных БИС, уровень интеграции сопоставим c кодером PAL. Возможно это были понты, с целью продать чип подороже, но другой информацией не располагаю.

[e2e4]

За что купил, за то и продал, такая цифра пролетала в разговоре с разработчиками специализированных БИС, уровень интеграции сопоставим c кодером PAL. Возможно это были понты, с целью продать чип подороже, но другой информацией не располагаю.

В любом случае за информацию спасибо, однако цифра просто не поместилась в голове. ИМХО с помощью древнего аналогового искусства фотодела () вполне можно создавать чипы с малой степенью интеграции (насколько я это себе представляю). Ну не стоит эта технология 100к $ за итерацию!

Может быть, имеются в виду разные вещи.

[Atari]

e2e4, хотелось бы таки "понюхать" вашу систему команд.

[e2e4]

e2e4, хотелось бы таки "понюхать" вашу систему команд.

Да вот, готовлю более-менее удобный к прочтению текстик. Кроме системы команд надо регистровый файл еще описать. Вкратце идея следующая: любая команда - 8 бит. Без исключений. Операндов нет. Это сильно упрощает декодер команд, сокращает обращения к памяти и, соответственно, кол-во тактов на команду. А вот АЛУ, все регистры - 16 битные. Соответственно, надо как-то впихнуть в 256 команд все необходимое, да еще так, чтобы было не сильно хуже, чем у настоящих процессоров. Основная проблема - это загрузка 16-битной константы.

При этом, система команд - не MISC в ее стандартном понимании (стек-машина). А все-таки, более-менее классическая.

В ближайшее время выложу.

[spensor]

В любом случае за информацию спасибо, однако цифра просто не поместилась в голове. ИМХО с помощью древнего аналогового искусства фотодела () вполне можно создавать чипы с малой степенью интеграции (насколько я это себе представляю). Ну не стоит эта технология 100к $ за итерацию!

Ну мы же говорим не о уровне детализации и плотности 155ЛА3, а о БИС с количеством транзисторов порядка 10-100тыс на кристале в 1мм2, и скоростью переключения от 100нс и меньше. Фотодело тут слабо катируется ввиду того что это гальваника полупроводниковых материалов. Эта технология недоступна ввиду дороговизны и крупным предприятиям, вследствии того что окупаемость наступает при сериях чипа в сотни тысяч. В иных случаях применяют полузаказные маричные чипы, ПЛИС или модули (функционально завершенное устройство, по сути эволюция гибридных микросхем). Даже технология PCB продолжает оставаться дорогой для того чтобы иметь собственные производственные мощности, что уж говорить о технологиях требующих на три и более порядков тонкие процессы, сверх чистые помещения и все такое прочее. А технология требует как реальных затрат на материалы, так и очень больших амартизационных отчислений. Так что цена производства чипов приближенно близка к реальной, пусть не 100 тыс, но 10 тыс $ наверняка, иначе бы в производстве мы бы видели совершенно другую картину - жесткая логика куда приемлемее в работе программируемых контроллеров и ПЛИС.

[AM]

Да вот, готовлю более-менее удобный к прочтению текстик. Кроме системы команд надо регистровый файл еще описать.

Вкратце идея следующая: любая команда - 8 бит. Без исключений. Операндов нет. Это сильно упрощает декодер команд, сокращает обращения к памяти и, соответственно, кол-во тактов на команду. А вот АЛУ, все регистры - 16 битные. Соответственно, надо как-то впихнуть в 256 команд все необходимое, да еще так, чтобы было не сильно хуже, чем у настоящих процессоров. Основная проблема - это загрузка 16-битной константы.

При этом, система команд - не MISC в ее стандартном понимании (стек-машина). А все-таки, более-менее классическая.

В ближайшее время выложу.

С интересом просмотрел вашу тему. Если дело в итоге сдвинулось хоть на миллиметр, не расскажете, что уже есть на сегодня?

В любом случае за информацию спасибо, однако цифра просто не поместилась в голове. ИМХО с помощью древнего аналогового искусства фотодела () вполне можно создавать чипы с малой степенью интеграции (насколько я это себе представляю).

Можно. Вспоминается, что когда начиналаcь известная фирма Интел, Гроув лично ходил в магазин выбирать подходящие объективы. Если нужна точная цитата, придется искать и вспоминать где именно это встретилось (быстро не нашлось, сам бы перечитал).

Ну не стоит эта технология 100к $ за итерацию!

Может быть, имеются в виду разные вещи.

"Эта технология" -- если говорить о совр. процессах -- стоит намного больше. Один набор масок может стоить миллионов 5 (я давно перестал отслеживать тему, навскидку вспоминается $2M для 65nm (могу ошибиться с нодом), все это можно быстро найти), а это лишь отдельно взятая статья расходов всего цикла.

[e2e4]

С интересом просмотрел вашу тему.

Спасибо!

Можно. Вспоминается, что когда начиналаcь известная фирма Интел, Гроув лично ходил в магазин выбирать подходящие объективы.

Именно этот исторический период и именно команду под руководствам Энди Гроува я и имел ввиду, когда писал про фотографию и производство чипов .

Если дело в итоге сдвинулось хоть на миллиметр, не расскажете, что уже есть на сегодня?

Дело сдвинулось, да. Во-первых, придумать-то систему команд я придумал (всего 256 команд). И загрузка 16-битной константы осуществляется за 3 команды (24 бита, 3 такта), что не хуже, чем если иметь префикс операции (8 бит) + 16-битная константа (16 бит) = те же 24 бита. Правда в моей системе команд загрузка константы возможна только в один регистр (условно назвал его аккумулятор, хотя это не аккумулятор в классической его трактовке). Когда дело оставалось за малым - всего-то нарисовать схему устройства управления и, как ее часть - декодера команд, то тут обозначился полярный пушной зверек. Во-первых, что-то около 60 сигналов управления (это после тщательной оптимизации). Во-вторых, декодер команд реально построить только на EEPROM (60/8 = около 8 EEPROM 16k x 8 = 128 кбайт прошивки), в-третьих, когда оставалось еще чуть-чуть чтобы довести дело до конца, я понял все уродство такого дизайна, и потер его нафиг.

Сейчас потихоньку (в качестве упражнения для ума) думаю над такой концепцией:
1. Длина команды = разрядности шины данных = разрядности шина адреса = разрядности АЛУ = 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.

3. Ну и набор из 7 регистров, 1 из которых - PC, другой - условно SP (условно потому, что автоматически инкрементируется при чтении, при записи - не декрементируется, это надо делать вручную). Каждый регистр может адресовать память. Присутствует механизм записи 16-битной константы за одну команду в любой регистр с использованием регистра PC. Присутствует механизм прерываний (примитивный, всего одно маскируемое прерывание). Присутствует механизм чтения/записи одного 16-битного порта ввода/вывода, который при желании с помощью внешней логики может быть отремаплен в пространство памяти. Также изначально раздельные пространства памяти программ/данных, но их также можно с помощью внешней логики объединять.
Главное - все операции донельзя примитивны и выполняются за одинаковое число тактов (в идеале - в 1, но к этому не стремлюсь, это, только лишь вопрос частоты внешнего тактового генератора), в том числе - загрузка константы и вход/выход из прерывания.
Как-то так. Пока более подробно делиться не хочу. Пишу эмулятор, в котором хочу попробовать написать простеньое приложение с рисованием линий по Брезенхаму и т.п. для того, чтобы "прочувствовать" недостатки и ограничения архитектуры.