Comments 9
Вроде бы и интересно, но читается с трудом. По-русски мы всё-таки привыкли читать слева направо и сверху вниз. А когда на схемах выходы оказываются сверху, а входы - справа, уловить мысль явно сложнее.
С формулами - то же самое. Если вы не дружите с маркдауном, латехом или юникодом - не стоит общую кашу приправлять ещё и сложными подстрочными индексами. Уважайте читателя, и читатель ответит взаимно.
Картинки из патентов, а патенты на то и патенты, чтобы защищать изобретение, а понимание наоборот усложнить.
Это схемы времен СССР, общепринятых правил рисования схем тогда либо не было, либо они сильно отличались от современных. Взять хотя бы аналоговые схемы времен СССР, где земля и питание рисовались не как рейлы внизу-вверху соотв., а могли быть где угодно, как угодно, равно как и транзисторы поворачивали как бог на душу положит. В общем, остается только понять и простить (сначала простить, а потом попытаться понять).
На патенты похоже, да, это тихий ужас.
А вот у цифровых схем в СССР как раз жёсткие правила были почти сразу, начиная как минимум с ГОСТ 2.743-68. В следующих ревизиях послабления пошли. Ну и в предыдущих статьях автора нормально же всё нарисовано.
Эти картинки не из Авт.св., а скорее из книги, на которую есть ссылки в статье, да и то не все - есть одна новая. В СССР существовала ЕСКД - единая система конструкторской документации по правилам которой и рисовались схемы. Ее, вроде, не отменяли.
Спасибо за справедливое замечание. Я действительно не знаком с указанными инструментами, но постараюсь их изучить. Что касается схем - то почти у всех входы снизу, а выходы сверху, что вполне допустимо. Замеченный вам недостаток только у первых двух, которые настолько просты, что указанный недостаток не мешает их пониманию.
Можно еще добавить, что наиболее хорошо эта тема изложена в статьях Мараховского (и самых поздних - Варшавского), где они называют этот процесс синхронизацией (обработки данных) в логическом времени (при этом асинхронно - в физическом времени), и в противовес pipeline (волновая обработка информации - по Варшавскому) приводят альтернативу - параллельную синхронизацию (так же обработки данных, и так же в логическом времени, но асинхронно - в физическом). Более того, производится выделение в отдельные категории схем управления (материал данной статьи, в частности), и автоматов обработки информации - которыми собственно и надо управлять. Мухи отдельно от котлет т.с.
Другими словами, поздние публикации Мараховского излагают данный материал более глубоко, шире, и понятнее, на мой взгляд. Такое вот частное мнение
Я пытался объяснить построение схем регистров не претендуя на изложение общей теории, которая к тому же достаточно полно излагается в книге, на которую есть ссылки в статье. При этом меня увлекала идея проследить наследование родовых свойств, которые имелись еще в регистре, предложенном Маллером. По этому принципу и отбирались описываемые схемы.
И снова хочу заметить, что говоря об имплементации, нужно учитывать и особенности базиса элементов. Если базис - т.н. 'россыпуха', отдельные корпуса (ЭСЛ, БТ и т.д.), то очень сложно будет найти элементы с числом входов больше 4-5, а если говорить об интегральных схемах (ASIC, т.е. фактически КМОП), то проблема ровно та же, поскольку элементы с большим числом входов очень медленные (в разы и даже на порядки, в зависимости от числа входов). И получается что изложенный подход (составление функций сброса и установки RS защелки) работает только на бумаге. Как только мы переходим в 3-4 входовой базис элементов, картинка становится непрезентабельной. А если отталкиваться от имплементации, то окажется - выскажу частное мнение -, что самыми компактными (по числу транзисторов) будут схемы на С-элементах, а не RS триггерах. Даже при том, что на практике, для интегрального исполнения, реально спроектировать только 2-х и 3х входовые С-элементы, а большее число входов получать уже их каскадированием.
Ну или не говорить об имплементации вообще. Тогда это материал для математиков, а не электронщиков.
Не воспринимайте вышесказанное как критику, просто мнение инженера-практика, который микросхемы (обычные, не асинхронные) проектирует каждый день.
С вами трудно не согласится - действительно предложенные схемы далеки от реальной схемотехники, так - теоретические упражнения. Может это одна из причин того, что это направление не нашло применения. С другой стороны может когда-нибудь этот барьер сложности будет преодолён технологически и об этой теории вспомнят и инженеры-практики.
Pipeline цифровые устройства