Ох, да. Думал про что-то другое когда писал. Оператор "=" по сути эквивалентен ":=" в VHDL и работе там с переменными. Оператор "<=" полностью аналогичен присвоению сигналов в процессах в VHDL.
Это опять же связано с отсутствием дельта задержки.
Неверно. Это связано с тем, что неблокирующие присваивания как раз сделаны для того, чтобы можно было сразу забрать результат и использовать его в следующем присваивании, но нужно следить за порядком выполнения операций. Вместо того чтобы использовать правильный инструмент (блокирующее присваивание), вы пытаетесь его симулировать с помощью задержек.
Раньше в некоторых проектах использовал задержки, потом перестал. Да, немного удобнее воспринимать диаграммы, но значительный overhead в виде «after sim_delay» в каждом присвоении того не стоит. Кроме того, появлялись еще какие-то неупомянутые ниже проблемы, о которых сейчас не вспомню.
Чисто технически задержки тянут за собой как минимум две проблемы:
1. Задержку можно забыть написать в каком-то присвоении, и это притащит за собой обратно все те же самые проблемы, от которых мы хотели избавиться задержками.
2. Если добавлять задержки *везде*, то при достаточном количестве вложенной логики можно умудриться перескочить через такт, что тоже ни к чему хорошему не приведёт.
С синхросигналами в HDL вообще нужно работать осторожно и внимательно, конкретно вот пример
clk2 <= clk1;
ведь ничего не даёт в схеме, а только создаёт проблему. Я бы еще понял
clk2 <= not clk1;
или какую-то другую логику, но в таком случае это уже модификация синхросигнала, и работа с такими вещами требуется соответствующая.
Добавлю, что занимаюсь в основном разработкой под ASIC, но часто с верификацией на FPGA, так что знаком с обоими «мирами».
При разработке ASIC (нет, не про блокчейны), в которых асинхронный сброс/установка является как раз нормой, и прототипировании кода в FPGA переделывать весь код с асинхронного сброса на синхронный обычно не только сложно и бесполезно, но и невозможно ввиду логики работы схемы.
Вскрытие показало, что чукча умер от вскрытия
Да, действительно, если написать код неправильно, то можно получить неожиданный результат. Это и называется Undefined behaviour ;)
В Verilog проблема с тем, что полностью корректно описать триггер с асинхронным сбросом невозможно, т.к. в таком элементе сброс работает по уровню, а не по фронту, а в always-блоке можно задавать только либо фронты, либо уровни. Впрочем, и в VHDL это не сильно лучше — список чувствительности в process при моделировании работает только по уровням (что очевидно), хотя в самом тексте и более явно указывается проверка по уровню или проверка по фронту (
clk'event and clk = '1'
или альяс
rising_edge(clk)
). С этой точки зрения и существуют нормативы написания корректно синтезируемых конструкций, указанные в комментариях выше.
В SystemVerilog, к слову, есть некоторые расширения (always_ff, always_comb, always_latch), позволяющие организовать дополнительный статический анализ кода и избежать множества ошибок, допустимых в чистом Verilog.
В вашем переводе половины вышеупомянутых фраз присутствуют какие-то избыточные додумывания, зачем?
“I said, ‘It's serious doctor, I've broken my arm in 20 places.’
He said: ‘Well stop going to those places.’”
(Томми Купер на своем шоу: «Я сказал: «Это серьезно доктор, я сломал руку аж в двадцати местах». Он ответил «Ну, тогда перестаньте ходить в такие травматичные места»)
«травматичных» мест никаких в предложении нет.
“My wedding was like a fairy tale. It wasn’t magical; it’s just that I’ve got an ugly sister.”
(Элли Тейлор: «Моя свадьба была похожа на свадьбу из сказок. Не потому, что была какая-то магия, просто у меня уродливая сестра»);
Не «свадьба из сказок», а «сказка».
Ну и про «восемь персонажей» лучше было вообще не приводить пример…
В общем похоже, что вы занимаетесь переводом названий для российского кинопроката.
Если вам приятно помнится оригинальный Red Alert, C&C или Dune2000, попробуйте OpenRA — opensource-проект на написанном с нуля движке на C#, использующий оригинальную графику. Значительно переработан баланс (особенно это заметно по RA-моду, в котором вертолёты целиком отдали Союзникам), что сделало возможной нормальную соревновательную многопользовательскую игру.
«Современных» в данном случае не только указание даты выпуска, но и содержимого (экран и железо). Ни один из перечисленных телефонов под этот критерий не попадает увы. Экран как раз основная проблема, потому что современные дисплеи в таких формфакторах не производятся.
В статье речь про UHF-метки, Mifare это NFC, не путайте.
Но суть идентификации верная — различный доступ по разным паролям, плюс использование открытого/закрытого ключей и внутреннего блока шифрования в метке.
С тем же Lightning'ом влёт получилось. Apple просто сказала — он удобней, он современней, берем и меняем.
… и не добавила его в MacBook Pro, заставив пользователей проделывать вот такие инновации: http://cs9.pikabu.ru/post_img/2016/10/29/6/1477734558123894713.jpg
Неверно. Это связано с тем, что неблокирующие присваивания как раз сделаны для того, чтобы можно было сразу забрать результат и использовать его в следующем присваивании, но нужно следить за порядком выполнения операций. Вместо того чтобы использовать правильный инструмент (блокирующее присваивание), вы пытаетесь его симулировать с помощью задержек.
Чисто технически задержки тянут за собой как минимум две проблемы:
1. Задержку можно забыть написать в каком-то присвоении, и это притащит за собой обратно все те же самые проблемы, от которых мы хотели избавиться задержками.
2. Если добавлять задержки *везде*, то при достаточном количестве вложенной логики можно умудриться перескочить через такт, что тоже ни к чему хорошему не приведёт.
С синхросигналами в HDL вообще нужно работать осторожно и внимательно, конкретно вот пример ведь ничего не даёт в схеме, а только создаёт проблему. Я бы еще понял или какую-то другую логику, но в таком случае это уже модификация синхросигнала, и работа с такими вещами требуется соответствующая.
Добавлю, что занимаюсь в основном разработкой под ASIC, но часто с верификацией на FPGA, так что знаком с обоими «мирами».
Вскрытие показало, что чукча умер от вскрытияДа, действительно, если написать код неправильно, то можно получить неожиданный результат. Это и называется Undefined behaviour ;)
В Verilog проблема с тем, что полностью корректно описать триггер с асинхронным сбросом невозможно, т.к. в таком элементе сброс работает по уровню, а не по фронту, а в always-блоке можно задавать только либо фронты, либо уровни. Впрочем, и в VHDL это не сильно лучше — список чувствительности в process при моделировании работает только по уровням (что очевидно), хотя в самом тексте и более явно указывается проверка по уровню или проверка по фронту ( или альяс ). С этой точки зрения и существуют нормативы написания корректно синтезируемых конструкций, указанные в комментариях выше.
В SystemVerilog, к слову, есть некоторые расширения (always_ff, always_comb, always_latch), позволяющие организовать дополнительный статический анализ кода и избежать множества ошибок, допустимых в чистом Verilog.
«травматичных» мест никаких в предложении нет.
Не «свадьба из сказок», а «сказка».
Ну и про «восемь персонажей» лучше было вообще не приводить пример…
В общем похоже, что вы занимаетесь переводом названий для российского кинопроката.
Но суть идентификации верная — различный доступ по разным паролям, плюс использование открытого/закрытого ключей и внутреннего блока шифрования в метке.
… и не добавила его в MacBook Pro, заставив пользователей проделывать вот такие инновации: http://cs9.pikabu.ru/post_img/2016/10/29/6/1477734558123894713.jpg
и