Защелки в FSM Опции

[Fynjisx]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

[Methane]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

Что такое защелки и что такое FSM? Вообще деад-локи плохой стиль. Система должна предсказуемо выходить из любого состояния.

[DmitryR]

Включив телепатические способности на полную мощность предположу, что под защелкой имеется в виду latch. И тогда верно, использовать их в FSM нехорошо даже в ASIC, не говоря уже о FPGA (где их вообще нет смысла использовать).

[glock17]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

если вы имеете ввиду latch, то использование их считается плохим стилем в принципе, а не только в FSM

[AsJohnAs]

Ну если сама стейт-машина находиться в процессе т.е. она меняет свои состояния синхронно с тактовым сигналом, тогда под защелками будут пониматься уже триггеры. Тогда данная ситуация будет трактоваться синтезатором как просто триггер с некоторым CE который пришел с комбинаторной логики.
И если картина примерно такая то применение синхронных защелок в FSM корректно. Но тут ключевое слово СИНХРОННЫЙ.

[bogaev_roman]

"Так как информация на выходе остаётся неизменной до прихода очередного импульса синхронизации, D-триггер называют также триггером с запоминанием информации или триггером-защёлкой."//из википедии
Так что пусть автор лучше пояснит, что он подразумевает под защелкой.
Если это триггер, который срабатывает при некотором условии, а при остальных непонятно что делает, то да - это latch, и большинство синтезаторов выдадут предупреждение и это не есть хорошо. Например в верилог для spartan3 под xilinx создавал ради интереса обычный синхронный D-триггер в вариантах:

Код

always @(posedge clk)
if (ce) D<=in;
else D<=D;

Ну и без else. Так вот в первом варианте был обычный триггер, а во втором еще мультиплексор вешался, правда давно очень это было...

Сообщение отредактировал bogaev_roman - May 20 2010, 07:47

[Fynjisx]

Что такое защелки и что такое FSM?

Защелки и FSM(FiniteStateMachine) - это стандартные понятия и думаю их спутать с чем то другим нельзя... Наверно не зря Вы профессионал...

Включив телепатические способности на полную мощность предположу, что под защелкой имеется в виду latch. И тогда верно, использовать их в FSM нехорошо даже в ASIC, не говоря уже о FPGA (где их вообще нет смысла использовать).

защелка это и есть latch, даже без включения телепатии... Думаю Вы ответили на мой вопрос.

если вы имеете ввиду latch, то использование их считается плохим стилем в принципе, а не только в FSM

Т.е от них надо стремиться уходить, даже ценой привлечения дополнительных ресурсов ПЛИС? Если так, то спасибо за ответ...я понял

"Так как информация на выходе остаётся неизменной до прихода очередного импульса синхронизации, D-триггер называют также триггером с запоминанием информации или триггером-защёлкой."//из википедии
Так что пусть автор лучше пояснит, что он подразумевает под защелкой.

Ладно буду придерживаться вашей терминологии. Триггер-защелка.

[DmitryR]

Т.е от них надо стремиться уходить, даже ценой привлечения дополнительных ресурсов ПЛИС?

Надо не стремиться, а уходить. Чтобы не было ни одной. Изменение количества используемых логических ресурсов при этом вряд ли будет заметным.

[Fynjisx]

Триггер со статическим управлением это называется в русскоязычной литературе)

[des333]

Ладно буду придерживаться вашей терминологии. Триггер-защелка.

Лучше употребляйте термин "latch". 

Хотя, лично я, сразу понял Ваш вопрос - не знаю, чего на Вас все накинулись.

И, как уже, советовали, не стоит использовать latch.

...
Если это триггер, который срабатывает при некотором условии, а при остальных непонятно что делает, то да - это latch
...

Не совсем понятна фраза, не могли бы Вы привести пример кода?

[bogaev_roman]

Это я про триггер-защелку, а не про latch, просто выразился неправильно

Код

always @(posedge clk)
if (Ce) D<=in;
else D<=D;

обычный триггер

Код

always @(posedge clk)
if (Ce) D<=in;

Триггер-защелка, имея ввиду, что непонятно действие при CE=0. Ну это человеку понятно что в этом случае ничего делать не надо кроме как сохранить результат, а старый ISE выдавал предупреждение о возможной защелке(иногда вешая доп.логику на вход), квартус никогда не ругался.
Про latch обычный уже все сказали и до меня...

Сообщение отредактировал bogaev_roman - May 20 2010, 10:40

[Fynjisx]

Лучше употребляйте термин "latch". 

Хотя, лично я, сразу понял Ваш вопрос - не знаю, чего на Вас все накинулись.

Хорошо хоть мой вопрос не затронул другие аспекты работы защелок(к примеру, что они ещё и прозрачными бывают ) ), а то бы меня здесь вообще съели

[dvladim]

Триггер-защелка, имея ввиду, что непонятно действие при CE=0. Ну это человеку понятно что в этом случае ничего делать не надо кроме как сохранить результат, а старый ISE выдавал предупреждение о возможной защелке(иногда вешая доп.логику на вход), квартус никогда не ругался.

Это что-то с ISE не то. Согласно стандарту, и человеку и машине должно быть понятно, что если нет ветки else, то надо хранить значение. Обычно, защелки, как раз и возникают из-за то, что забывают написать else.

Хорошо хоть мой вопрос не затронул другие аспекты работы защелок(к примеру, что они ещё и прозрачными бывают ) ), а то бы меня здесь вообще съели

Понятно, что защелки прозрачные, иначе они перестают быть защелками.
Вы лучше скажите как у вас в FSM защелки-то получились?

[icyrock]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

На мой взгляд использование защелок никакой проблемы не составляет. У меня половина обычных триггеров, а половина защёлок. Живу и радуюсь - никаких проблем.

А использовать ветку else только для того чтобы написать что триггер должен сохранить свое значение - это только засорять код. От ошибок это не защищает.

[des333]

На мой взгляд использование защелок никакой проблемы не составляет. У меня половина обычных триггеров, а половина защёлок. Живу и радуюсь - никаких проблем.

Главный вопрос: а зачем?

[Builder]

На мой взгляд использование защелок никакой проблемы не составляет. У меня половина обычных триггеров, а половина защёлок. Живу и радуюсь - никаких проблем.

А использовать ветку else только для того чтобы написать что триггер должен сохранить свое значение - это только засорять код. От ошибок это не защищает.

С защёлками могут возникать неочевидные ошибки. Просто нужно осознанно их использовать. Это как с асинхронщиной, если обосновано и со знанием дела - пожалуста, используйте, будет работать. Но как показывает практика, у многих почему-то не работает. На симуляторе вроде работает, а на железе - глючит.
Поэтому тут по моему должен действовать принцип - не уверен - не используй, уверен - нет проблем
По else, пишу на V/SV, обычно ставлю _ff, и не имею проблем с засорением кода лишней информацие.

Добавлено: а разве защёлки во всех ПЛИС есть? Если нету - то тоже нарваться можно, т.к. она будет неким способом симитирована, и нужно ещё смотреть как именно...

[ViKo]

а разве защёлки во всех ПЛИС есть?

Вот пример защелки

Код

assign out = in & out;

[des333]

Вот пример защелки

Код

assign out = in & out;

Это не защелка, а комбинационная петля.


Защелка - это:

Код

always @(*)
  if(en)
   out = in;

[ViKo]

Это не защелка, а комбинационная петля.
Защелка - это:

Ну, нехай так будет. И то, и другое легко сделать в любой ПЛИС
Вот пример, выполняющий то же самое. Но на него Quartus ругается, как на комбинационную петлю.

Код

  assign out = in & en | out & !en;

[icyrock]

Главный вопрос: а зачем?

Алгоритмы у меня такие : нужно

[bogaev_roman]

Алгоритмы у меня такие : нужно

А Вы уверены, что в Вашем алгоритме без защелок не обойтись? Все-таки защелки - хитрая вещь и ИМХО лучше без них.
Да и по себе могу сказать - читая чужой код и встречая защелки (особенно в case любят опускать состояния) ну очень настораживает - как бы в неопределенность не погрузиться, особенно если обратная связь.
assign out = in & en | out & !en; - Вот такая то оплошность быстро обнаружиться, а вот если case состояний этак на 100, ну и одно забыли - хана, не обнаружишь.

Сообщение отредактировал bogaev_roman - May 27 2010, 15:17

[des333]

Алгоритмы у меня такие : нужно

Это как с оператором goto. Всегда можно обойтись и без него. 

[icyrock]

А Вы уверены, что в Вашем алгоритме без защелок не обойтись? Все-таки защелки - хитрая вещь и ИМХО лучше без них.
Да и по себе могу сказать - читая чужой код и встречая защелки (особенно в case любят опускать состояния) ну очень настораживает - как бы в неопределенность не погрузиться, особенно если обратная связь.

Вижу в использовании защёлки (когда это требуется) следующие факторы увеличивающие наглядность кода
1. Нет лишней засоряющей пространство ветви else
2. Чем реже меняет значение триггер тем меньше "ряби" и посторонних (промежуточных) значений на симуляции
3. Текст
always @(posedge clk)
if (ce)
dout<=din;
Прямо говорит что меняется значение dout тогда когда ce в единице
4. В принципе можно напрячься и избавиться от защёлок. Но это может привести к тому, что код хоть и будет работать правильно но идею алгоритма придётся расшифровывать внимательно вглядываясь в превращение входных данных в выходные.

[Builder]

3. Текст
always @(posedge clk)
if (ce)
dout<=din;

Чёт-т туплю к концу дня, это разве защёлка? Вы точно уверены?
По моему это банальный тригер, и тогда все остальные рассуждения теряют смысл.

[des333]

3. Текст
always @(posedge clk)
if (ce)
dout<=din;

Это не защелка. Смотрите пример защелки выше.

[bogaev_roman]

always @(posedge clk)
if (ce)
dout<=din;

Это триггер-защелка (синтезирован будет как обычный триггер). Тока вот теперь ответьте на вопрос что Вы будете делать если будет вложенный оператор
if else if else и забудете первый else поставить? А вообще можно просто написать else ; И насчет читабельности я бы еще поспорил.

Сообщение отредактировал bogaev_roman - May 27 2010, 17:30

[ViKo]

Это триггер-защелка (синтезирован будет как обычный триггер).

Это - не триггер-защелка.
Защелка (Latch) - это триггер, который передает входной сигнал, когда L = 1 (прозрачный), и не передает входной сигнал, когда L = 0. В момент перехода L из 1 в 0 триггер "защелкивает" сигнал, а до этого момента сигнал на выходе мог меняться вместе с входным.

P.S. А для case есть слово default.

[bogaev_roman]

Это - не триггер-защелка.
Защелка (Latch) - это триггер, который передает входной сигнал, когда L = 1 (прозрачный), и не передает входной сигнал, когда L = 0. В момент перехода L из 1 в 0 триггер "защелкивает" сигнал, а до этого момента сигнал на выходе мог меняться вместе с входным.

P.S. А для case есть слово default.

Все-таки откопал из старого форума-конференции - вот собственно тема http://www.telesys.ru/wwwboards/fpga/270/m...ges/21837.shtml
А вот подробное описание отличий - http://www.telesys.ru/wwwboards/fpga/270/m...ges/22311.shtml
Так что то о чем говорил des333 - это latch, то о чем писал я -flip-flop and latch в общем случае, и речь шла немного о разных вещах.
Некоторым лень сознательно ставить default так же как и else - типа читается лучше да и строчек меньше, а потом начинается в крупных проектах "выковыривание" ошибки.
Интересно, а вот сходу скажет кто-нибудь - стандарт рекомендует по стилю вставлять else и default? По-моему рекомендует, хотя и не обязывает...

Сообщение отредактировал bogaev_roman - May 28 2010, 06:24

[ViKo]

Во всяком случае, Quartus предлагает следующий шаблон для case:

Код

case(<constant_expr>)
<constant_expr>:
  begin : <block_name>
    // Generate Items
  end
<constant_expr>:
  begin : <block_name>
    // Generate Items
  end
// ...
default:
  begin : <block_name>

  end
endcase

// NOTE: Block names are optional but Altera recommends them.

Кстати...

assign out = in & en | out & !en; - Вот такая то оплошность быстро обнаружиться

Это не оплошность, а осознанное решение. Ничего плохого в нем нет. Именно - триггер-защелка, применяется часто. Пример - 74HC373 - Octal 3-State Noninverting Transparent Latch.
Бывают защелки "полезные", а бывают "непредусмотренные"

[des333]

Так что то о чем говорил des333 - это latch, то о чем писал я -flip-flop and latch в общем случае, и речь шла немного о разных вещах.

Ну, я думал, по контексту темы все поняли, что имеется в виду та защелка, которая latch. 

Это не оплошность, а осознанное решение. Ничего плохого в нем нет. Именно - триггер-защелка, применяется часто. Пример - 74HC373 - Octal 3-State Noninverting Transparent Latch.
Бывают защелки "полезные", а бывают "непредусмотренные"

Altera рекомендует не использовать latch вообще.

[ViKo]

Altera рекомендует не использовать latch вообще.

потому что у нее в каждом триггере есть нормальный тактовый вход clk

[des333]

потому что у нее в каждом триггере есть нормальный тактовый вход clk

Не понял.

Разве существуют FPGA, в которых у триггера нет нормального тактового входа?

[ViKo]

Не понял.
Разве существуют FPGA, в которых у триггера нет нормального тактового входа?

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС
Когда сигнал изменяется по тактам, можно получить большее быстродействие, чем когда он меняется, когда захочет.
Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

[sazh]

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС
Когда сигнал изменяется по тактам, можно получить большее быстродействие, чем когда он меняется, когда захочет.
Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

Потому что выходы latch изначально в неопределенном состоянии. Пока en в 1 единицу не перевести.
За это время много чего пожечь можно.

[Maverick]

Altera рекомендует не использовать latch вообще.

Я знаю что Xilinx также не рекомендует latch испльзовать.
PS Мое мнение использование latch в проектах для ПЛИС это плохая практика. Должно быть по возможности 100% RTL кодирование и синхронный дизайн (синхронная цифровая схемотехника) без использования асинхронной логики.

[sazh]

PS Мое мнение использование latch в проектах для ПЛИС это плохая практика.

Например Q-bus (МПИ шина). Асинхронный обмен. В системной шине нет клока. И на ПЛИС ложится.
От протокола обмена зависит. (Хотя это уже история)

[ViKo]

Пока быстродействие ПЛИС позволяет делать схему тактированной, так и нужно делать.
Как только потребуется что-то более быстрое, например, задержать сигнал на 0.2 ns, или выработать коротенький импульс, придется использовать асинхронные решения.
Одно из известных применений Latch - фиксация адреса по мультиплексированной шине address-data во многих микропроцессорных системах по сигналу ALE. В этом случае адрес на выходе защелки появляется раньше, чем если бы использовался синхронный триггер. Получается больше времени установления для подключенных к шине адреса устройств.

[fars]

Коде конвншн для РТЛ, запрещяет использовать защелки, тактирование с разными фронтами и прочее - ибо это есть неправильно и обосновано на ошибках многих зарубежних разработчиков

[dvladim]

Интересно, а вот сходу скажет кто-нибудь - стандарт рекомендует по стилю вставлять else и default? По-моему рекомендует, хотя и не обязывает...

Насчет стандарта не скажу, а вот проверка покрытия у Кейденса выдает сообщение если отсутствует default даже если описаны все возможные состояния.

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

Если вы имели ввиду что конвейер на триггерах будет быстрее конвейера на латчах, то это не так. В конвейере на латчах предыдущий каскад предоставляет свой временной запас следующему. Это и позволяет при несогласованности стадий конвейера повысить тактовую по сравнению с реализацией на триггерах.

[ViKo]

Если вы имели ввиду что конвейер на триггерах будет быстрее конвейера на латчах, то это не так. В конвейере на латчах предыдущий каскад предоставляет свой временной запас следующему. Это и позволяет при несогласованности стадий конвейера повысить тактовую по сравнению с реализацией на триггерах.

Я сомневаюсь. Можно попытаться объяснить теоретически, что предельное быстродействие будет определяться теми же временами предустановки, удержания и распространения. Но лучше попробовать на практике. Если что-то получится, я напишу позже. Возможно, Вы и правы.
В синхронной схеме есть гарантированное время для каждой ступени.

[des00]

Я сомневаюсь.

ну и зря, недаром есть проекты по асинхронизации изначально синхронных устройств(например асинхронный пик16 в ~4 раза быстрее синхронного). Рости производительности оправдывает асинхру.

[murmel1]

есть проекты по асинхронизации изначально синхронных устройств

Ссылочку не дадите ли ?
ИМХО, для создания больших асинхронных схем требуется язык, описывающий порядок срабатывания. HDL позволяет описывать порядок срабатывания только по тактам.

[des333]

ИМХО, для создания больших асинхронных схем требуется язык, описывающий порядок срабатывания. HDL позволяет описывать порядок срабатывания только по тактам.

Поясните, если не сложно.


Как это должно выглядеть в схематике? И что конкретно Вы хотите добавить к возможностям HDL, чтобы это описать?

[des00]

Ссылочку не дадите ли ?

гугл всё знает
dlx
arm
еще арм

[des333]

гугл всё знает
dlx
arm
еще арм

Перехожу на асинхронщину 

[dvladim]

Перехожу на асинхронщину

Только вот такие схемы больше по площади и существенно сложнее в разработке.
Хотя тут была тема о новом производителе ПЛИС (судя по всему загнулся). Так вот схема, по некоторым признакам, была асинхронной и несколько патентов насчет автоматизированного перевода с RTL к асинхронной схеме у него было.

[ViKo]

ну и зря, недаром есть проекты по асинхронизации изначально синхронных устройств(например асинхронный пик16 в ~4 раза быстрее синхронного). Рости производительности оправдывает асинхру.

В ссылках, что Вы привели ниже, не говорится про PIC. Если имелся в виду подобный проект, на ПЛИС, то не в быстродействии ли самой ПЛИС заложена такая скорострельность ПИКа?
В самом ПИКе каждая команда выполняется за 4 такта (если помните, в 51-й микроЭВМ их было 12). Если эти 4 такта слепить в один, то, наверное, можно сделать устройство слегка более быстрым. Быстродействие будет определяться длительностью самой сложной команды. Как здесь писали, ценой аппаратных затрат. Но асинхронным от этого процессор все равно не станет.
Беда в другом. В соседних темах о том же говорится. Если на триггере есть асинхронный сброс, который может кончиться в момент тактового сигнала - вот вам метастабильное состояние! Вам это надо?
P.S. Еще примерчик - если не ошибаюсь, в Intel Pentium4 глубина конвейера была 20 тактов. А там, надеюсь, не дураки сидят.

[des00]

В ссылках, что Вы привели ниже, не говорится про PIC.

вот тунеядец то (с) Старый мульт %))) Можно было погуглить и найти вот такую статью САМОСИНХРОННАЯ СХЕМОТЕХНИКА – ПЕРСПЕКТИВНЫЙ ПУТЬ РЕАЛИЗАЦИИ АППАРАТУРЫ вот из статьи

В работе представлены результаты испытаний С- и СС-вариантов исполнения тестового кри­сталла «Микроядро», который реализует функции вычислительного ядра восьмиразрядного мик­роконтроллера PIC18CXX, широко используемого в отечественных разработках
......
На рис. 6 представлен график зависимости быстродействия образцов Микроядра от темпера­туры и напряжения питания. Видно, что быстродействие С-реализаций Микроядра есть величина постоянная для всех возможных условий эксплуатации в пределах области работоспособности и составляет 4 МГц. Быстродействие же ССС-микроядра широко изменяется в зависимости от внешних и внутренних факторов. Например, в зоне работоспособности, гарантированной изгото­вителем БМК, его быстродействие изменяется от 10,9 МГц (5,5 В; -63°С) до 5,2 МГц (4,5 В; +125°С) и в среднем выше быстродействия С-Микроядра почти в два раза. На рис. 7 приведен график зависимо­сти тока потребления (Iсс) С- н ССС-вариантов реализации Микроядра от величины питающего напряжения при номинальной температуре. При одном и том же питаю­щем напряжении ССМ потребляет не­сколько больше, чем СМ. Однако при этом быстродействие ССС-реализаций существенно выше.

ошибся немного, не в 4, а в 2 раза всего средний выигрыш по производительности, это не считая потребления

[ViKo]

Вы серьезно рассматриваете данную статью как пример, доказывающий преимущества асинхронных схем?
Пробежав ее по-диагонали, я в очередной раз убедился во мнении, что академики даром едят свой хлеб. Ничем иным, кроме попыток выбить "бабла", я не могу оправдать данную "тему".
Вот один из "перлов":

Дальнейшие исследования показали, что исключение из цепи питания микросхем миллиамперметра и использование низкоомного провода минимальной длины от источника питающего напряжения до микросхемы позволяет расширить зону работоспособности до беспрецедентно низкого уровня – 0,2 В. Этот интересный феномен требует дополнительного исследования и подтверждения на более представительной выборке микросхем.

Вот как надо быстродействие повышать! Долой амперметры!!
А по-серьезному:
- Не увидел никакой разницы между рис 1,а и 1,б. А на этом основана вся дальнейшая работа.
- Работа, требующая подтверждения своей завершенности, не может выполниться быстрее, если бы подтверждения не требовалось. Исключения - когда какая-то процедура (умножение, например) требует намного большего времени, чем остальные действия. Если привязывать такты к такой команде, придется терять время для остальных. Поэтому такие команды выполняются за несколько тактов.
- PIC18 работают на частоте 40MHz, выполняют команду за 100ns (4 такта). Вот оно, преимущество конвейера (вспомним еще раз Pentium4).
- еще примерчик - синхронные и асинхронные интерфейсы - какие быстрее?
upd. извиняюсь, не быстродействие, а потребление уменьшать с помощью исключения амперметра

[des00]

Вы серьезно рассматриваете данную статью как пример, доказывающий преимущества асинхронных схем?
Пробежав ее по-диагонали, я в очередной раз убедился во мнении, что академики даром едят свой хлеб. Ничем иным, кроме попыток выбить "бабла", я не могу оправдать данную "тему".
Вот один из "перлов":

Нормальный такой тезис, столкнулся чел с неизвестным вот и удивился.

А по-серьезному:

идея самосинхронного конвейера стара как мир, больше всего я думал над "Таблица 1. Модельные времена исполнения команд" и прикидывал куда, что и зачем. А когда накладывал выкладки на результаты ковыряния своего проца в роутере, находил общие выводы с авторами статьи. Так что рациональное звено в самосинхронных схемах есть, ну и промышленные процы тоже. Линки уже приводил.

ЗЫ. Насчет асинхронности, на форуме есть тема где участник рассказывает об асинхронном RAKE приемнике, который в ~3 раза производительнее синхронного. Хотя подозреваю что он не совсем асинхронный, он с многофазной синхронизацией.

[ViKo]

Нормальный такой тезис, столкнулся чел с неизвестным вот и удивился.

У статьи 5 авторов, не считая рецензентов, помощников, и т.д. Они что, камень с Луны исследуют? Связь с изготовителем БМК потеряна навсегда?
На рис. 6 при напряжении ниже 1V (кстати, почему там цифры 3,1 2,1 1,1 В - обычное разгильдяйство) рабочая частота падает до 0. Примерно так выделяются сигналы на фоне шумов - накапливаем, накапливаем, потом какой-то результат получаем...

[ViKo]

Хочу еще добавить пару слов.
Кто мешал упомянутым "академикам" запихнуть свое "изобретение" в ПЛИС, у которой перед каждым триггером с синхронным входом есть асинхронная 4-х-входовая таблица просмотра (истинности)? Ну, пусть было бы нерациональное использование, но весь их PIC уложился бы в ПЛИС (а то и оба - синхронный и асинхронный, и еще осталось бы для схем тестирования).
Не все идеи, старые, как мир, проходят проверку временем. Прогресс вообще петляет, как заяц. Но неизменно продвигается вперед.
Я не отвергаю асинхронные схемы. Но критерий истины - практика. Пока что практических доказательств преимуществ асинхронности я не увидел.

[Builder]

Хочу еще добавить пару слов.
Кто мешал упомянутым "академикам" запихнуть свое "изобретение" в ПЛИС, у которой перед каждым триггером с синхронным входом есть асинхронная 4-х-входовая таблица просмотра (истинности)? Ну, пусть было бы нерациональное использование, но весь их PIC уложился бы в ПЛИС (а то и оба - синхронный и асинхронный, и еще осталось бы для схем тестирования).
Не все идеи, старые, как мир, проходят проверку временем. Прогресс вообще петляет, как заяц. Но неизменно продвигается вперед.

Тут нужно смотреть кирпичики, из которых это делается. Не факт что эти асинхронные кирпичики нормально ложатся на ПЛИС с его лутами. Может там такие-же проблемы будут как с асинхронными схемами на ПЛИС, когда люди знающие схемотехнику на рассыпухе лепили по старинке и получали кучу проблем в ПЛИС. Тут запросто может быть такая-же проблема.
Для того что- сказать что это так или не так, нужно знать что там за кирпичики. Где есть описание этих "кирпичиков" подробнее чем в статье?

[ViKo]

Где есть описание этих "кирпичиков" подробнее чем в статье?

Я не знаю.
Пусть ПЛИС будет неоптимальна для подобной разработки. Но все же лучше, чем ничего. Для доказательства преимуществ асинхронного процессора хватило бы, наверное.
Мне кажется, что идеи (только первичные идеи, про дальнейшую реализацию молчу) могли бы пригодиться при разработке компьютеров для роботов и т.п., если нужна "безотказность" вычислений в первую очередь, а уж потом быстродействие. Т.е., если не получается вычислить быстро, пусть процессор "подумает" над командой еще, пока не "осилит".

[dvladim]

Мне кажется, что идеи (только первичные идеи, про дальнейшую реализацию молчу) могли бы пригодиться при разработке компьютеров для роботов и т.п., если нужна "безотказность" вычислений в первую очередь, а уж потом быстродействие. Т.е., если не получается вычислить быстро, пусть процессор "подумает" над командой еще, пока не "осилит".

Вот как раз для роботов используются RTOS - т.е. время выполнения критично, ждать нельзя.

[ViKo]

Вот как раз для роботов используются RTOS - т.е. время выполнения критично, ждать нельзя.

По-началу хотел написать "для луноходов", но подумал, крутовато будет
В-общем - туда, где нужна безотказная работа. Хотя для этого делается несколько компьютеров, работающих параллельно.
?