Comments 10
Если не опираться на событийные модели (а практически никто и не опирается), наверно так и есть. Проверять готовую схему действительно сложно. Если сначала сконструировать поведение, перед глазами сразу будет то, что схема будет делать.
Подумал, да ладно, а сколько синхронщики с разводкой дрюкаются, с отлавливанием глюков. И это ведь не какие-то случайности, это система.
У NCL реализации комбинационных схем есть два серьезных недостатка:
Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.
Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.
Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.
В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.
Наконец дождался толкового комментария, как манны небесной. Алексей, приветствую.
По первому недостатку дополню. В NCL пайплайнах также используется ускоренная передача данных (без сигнала req). Но там это не система, а исключение. К тому же я не претендую на новизну такого ускоренного интерфейса (я просто постарался разложить это явление по полочкам). Это как со SI: жить с этим можно, но ахинея жуткая. К тому же я как раз не говорю, что изобретаю что-то новое (кроме самого метода). Я беру конструктор с уже готовыми деталями и собираю их так, что остается много лишнего.
Второй момент. Да, идея использовать инвертирующие элементы кажется привлекательной. Но я сам с этим экспериментировал, в литературе смотрел. Решение на С-элементах всегда лучше, может не намного, но по всем параметрам. Пример такой же иллюзорной попытки оптимизации это считывание данных по обоим фронтам сигнала req. Я, кстати не рассматриваю С-элементы, как средство запоминания состояний. Просто их использование дает лучшие решения. В качестве сравнения я предлагаю обращать внимание только на последний пример (вернее предпоследний, последний это NCL схема). Все предшествующие примеры это отражение этапов развития метода, не более.
Кодирование особая тема. Вы сами должны помнить, что я настаивал на необязательности его. Да, схемы без кодирования делать можно. Но, тогда надо возвращать сигнал req. А также либо использовать входные инверторы (чего Варшавский не одобряет), либо отказываться от SI (т.е. от независимости от задержек элементов), либо сооружать схему переходник (чего делать не умеют), на выходе которой будет тот самый закодированный сигнал. Если сравнивать управление и вычисления, то главное отличие управляющих схем в том, что смена значений сигналов в них заранее предопределена (1, 0, 1, 0, ...). Использование кодирование в этом случае - напрасная трата ресурсов. В арифметике очередность смены значений заранее не предугадать. Поэтому и нужен переход через спейсер. Можно принудительно отказаться от кодирования, но оно все равно так или иначе проявится. И на это потребуются дополнительные ресурсы.
NCL можно разложить на 4 составные части: библиотека, комбинационные схемы, управление с регистрами и миф о DI. Сначала о последнем. В библиотеку не лезем, это внутренняя кухня. Управление с регистрами, да, DI. Но в этом нет особого подвига, поскольку является следствием параллельного интерфейса, а также (по сути) реализацией функции в однозначной системе счисления (это собственно управление). В том, что я предлагаю, параллельный интерфейс гарантирует DI вне модулей. А вот комбинационные схемы напичканы нарушениями DI по уши, как и обычная управляющая схема (не арифметическая). Фант скромно говорит об орфанах, как об исключениях, но это система. Вот почему делать управляющие схемы методами NCL расточительство.
Но это, ладно, PR. Вот, что действительно в NCL плохо, так это управление с регистрами. От этого надо избавляться напрочь. Именно за счет этого Вы и выигрываете у NCL. А вот библиотека и, как следствие, комбинационные схемы, на мой взгляд, наиболее эффективное решение (для арифметики). Избыточность NCL связана с управлением и регистрами, а также применением метода к синтезу управляющих схем.
Я далек от мысли меряться комбинационными схемами на таком избитом примере, как сумматор. Хотя на более сложном примере можно было бы попробовать. Но не это главное, а избавление от всякого внешнего управления. Вы можете представить любое удачное решение и я, не особо мудрствуя, за счет избавления от индикатора (путем встраивания ответов в комбинационную схему) сделаю лучше. В плане быстродействия сигналы ответа бесплатны. А по транзисторам (за счет гибкости), мягко говоря, не хуже индикаторов.
И последнее. Если Вы скажете, что индикатор есть хорошо, можете бросить в меня камнем (а я спрячусь).
В догонку. Вы выигрываете у NCL за счет модернизации управления, а я у Вас - за счет полного отказа от внешнего управления и использования NCL библиотеки. Это тот ребенок, которого выплескивать не надо.
Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:
Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.
Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.
Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.
DI вещь хорошая, но не осуществимая. DI интерфейс это не сложно, да практически и бесплатно. DI комбинационная схема (модуль) это фикция (кому-то что-то показалось). Если не будет изобретен элемент с 2 (точнее 3) выходами. SI комбинационная схема предел мечтаний, к тому же реально. Сказки блочников про DI из того же разряда. Интерфейс - да, внутренности блоков - нет. Так что проблема надуманная.
Про crosstalk толком ничего не скажу, первый раз об этом услышал. Могу, кроме ликвидации индикаторов, обратить внимание на такой момент. Обычно комбинационная схема строится как логическая функция. И, если функция достаточно сложная, комбинационная схема может реализовывать не одно поведение, одно из которых может завести схему не туда. Здесь комбинационная схема строится как поведение. В результате она реализует единственное предопределенное поведение, что избавит от нежелательных эффектов. В синхронном дизайне такое тоже могло бы быть полезно.
По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.
Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.
А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.
Как я понял, С-элемент (и ему подобные) принято считать наиболее уязвимыми в отношении шума. На мой взгляд последствия от ложного импульса для С-элемента не так катастрофичны, как принято считать. Рассмотрим схему (модуль) на С-элементах. NCL элемент по сути функционально является совокупностью С-элементов, чьи выходы соединены с общим элементом ИЛИ. Для переключения С-элемента одного ложного импульса недостаточно, нужно чтобы на остальных входах уже были единицы. Следовательно ложное срабатывание С-элемента может произойти только в фазе данных. А вероятность реакции на ложный импульс для 4-входового элемента 1/4. При этом в половине из этих случаев переключение С-элемента будет не ложным, а преждевременным. То есть вероятность ложного переключения 1/8. Далее, С-элемент - внутреннее дело модуля. Для внешней среды существенно выставляемое значение выходной функции. Если функций две, то вероятность совпадений их значений на обоих входных наборах (С-элемент по сути отлавливает свой входной набор) 1/4. То есть, вероятность выставления ложного значения функции меньше 10 процентов. Но при этом и истинное значение функции также будет выставлено. Два значения функции - ситуация недопустимая и ее можно отлавливать аппаратно. Но и это не все. Ложное переключение С-элемента (как и истинное) вызывает переключение выходного сигнала ответа в модули - источники данных. Это вызовет сброс входных данных в 0, что приведет к переключению в 0 обоих С-элементов (истинного и ложного). Причем схема будет ждать переключения обоих. Таким образом, пострадавший модуль к следующей итерации придет в нормальное состояние. Другое дело, что ошибка (выставление двух значений функции) практически гарантированно распространится во все модули-приемники. Но, тем не менее, все они к следующей итерации восстановят свое нормальное функционирование.
Если предположить, что ложный импульс может быть только единицей, то переход к дуальной библиотеке может изменить картину. В этом случае опасность состоит в преждевременном сбросе выходного значения. Это грозит прерыванием волны вычислений в текущей итерации. При этом все модули будут работать в штатном режиме, но отследить такую ситуацию уже практически невозможно.
Все выкладки выше носят предварительный характер, но все подробно обсчитать наверно не так уж трудно.
По поводу большего быстродействия комбинационных схем в dual-rail, нежели чем в NCL (второй абзац от 25.3) Вы преувеличиваете (про себя я тут даже не комментирую). Параллельный индикатор это хорошо, но смотреть надо по итогу. У меня перед глазами схема переноса сумматора от Мараховского (оптимизированная, на И-ИЛИ-НЕ). D-R дает результат за 4 переключения (С-элемент тестера - 2 переключения). Не самый лучший вариант NCL (DIMS) дает те же 4 переключения (элемент ИЛИ - 2 переключения). А реализация на элементах библиотеки NCL - вообще всего 2. Затем у вас, у каждого, своя история: регистры, глобальные С-элементы или глобальные индикаторы. Но это все уже без меня.
Асинхронная обработка данных (асинхронные вычисления). Анализ поведения