Что означает правильность аппаратного обеспечения, синтезированного из кода Verilog

Все -

Пришло время поделиться полезной справочной информацией и моим собственным мнением.

Во-первых, стандарт синтеза IEEE-1364.1-2002 Verilog RTL никогда не был полностью реализован ни одним поставщиком, поэтому никто из нас не торопился обновлять стандарт или предоставлять версию стандарта синтеза для SystemVerilog. Насколько мне известно, стандарт не был «заменен», а просто истек. Насколько мне известно, атрибуты, описанные в Стандарте, никогда не были полностью реализованы ни одним поставщиком. Единственная полезная функция в Стандарте, которая, как я полагаю, была реализована всеми поставщиками, заключалась в том, что поставщик должен установить макрос `define SYNTHESIS перед чтением любого пользовательского кода, так что теперь вы можете использовать` ifndef SYNTHESIS - `endif в качестве общей замены для конкретных поставщиков // synopsys translate_on - // synopsys translate_off pragma-comments.

Verilog был изобретен как язык моделирования и никогда не задумывался как язык синтеза. В конце 1980-х годов Synopsys осознала, что инженерам очень нравится этот язык моделирования Verilog, и начала определять подмножество языка, которое они (Synopsys) распознали бы и преобразовали посредством синтеза в оборудование. Теперь мы называем это подмножеством синтеза RTL, и это подмножество может со временем расти, поскольку поставщики инструментов синтеза обнаруживают уникальные и творческие способы преобразования нового типа описания в оборудование.

На самом деле не существует «определенной корректности синтеза Verilog». В 1999 году мы с Доном Миллсом написали статью под названием «Стили кодирования RTL, которые приводят к несоответствиям моделирования и синтеза», чтобы предупредить инженеров о законных стилях кодирования Verilog, которые могут определять синтезируемое оборудование с различным поведением. http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch.pdf

Учтите, что если бы синтезированные результаты всегда соответствовали поведению моделирования Verilog, не было бы необходимости запускать моделирование ворот. Дизайн, смоделированный с помощью RTL, был бы правильным. Поскольку нет гарантированного совпадения, инженеры запускают симуляторы ворот, чтобы доказать, что поведение ворот соответствует поведению RTL, или они пытаются запустить инструменты проверки эквивалентности, чтобы математически доказать, что код RTL перед синтезом эквивалентен моделям ворот после синтеза. , так что гейт-симки не требуются.

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

Что касается четко определенного кода в моделировании и синтезе с разными результатами, рассмотрим:

module code1c (output reg o, input a, b);

  always
    o = a & b;
endmodule

В симуляции вы никогда не пройдете мимо времени-0. Моделирование будет повторяться бесконечно из-за отсутствия списка чувствительности. Инструменты синтеза даже не учитывают список чувствительности при выводе комбинационной логики, поэтому вы получите два входа и логический элемент и предупреждение об отсутствующих элементах списка чувствительности, которые могут вызвать несоответствие между симуляциями до и после синтеза. В Verilog-2001 мы добавили always @ *, чтобы избежать этой распространенной проблемы, а в SystemVerilog мы добавили always_comb, чтобы удалить список чувствительности и сообщить инструменту синтеза логику, заданную разработчиком.

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

«В заключение, в разделе, упомянутом в предыдущем абзаце, говорится, что блокирующие назначения могут использоваться для вычисления RHS неблокирующего назначения. Это, по-видимому, нарушает рекомендацию № 5 Каммингса».

Вы правы, это нарушает правило кодирования №5 и, на мой взгляд, не должно использоваться.

Рекомендация по кодированию №5 часто нарушается в проектах VHDL, потому что переменные VHDL не могут запускать другой процесс. Я считаю, что лагерь VHDL по этому вопросу разделен поровну. Половина говорит, что вы не должны использовать назначения переменных, а другая половина использует переменные для повышения производительности моделирования, но затем требуется смешать назначения переменных с окончательным назначением сигнала для запуска других процессов.

Если вы нарушите рекомендацию по кодированию № 5 и если ваш код верен, моделирование будет работать, и синтез также будет работать, но если у вас есть какие-либо ошибки в вашем коде, очень сложно отладить проекты, которые нарушают рекомендацию по кодированию № 5, потому что отображение формы волны для комбинационного фрагмента не имеет смысла. Выходные данные комбинационной логики в отображении формы сигнала обновляются только тогда, когда сброс не заявлен и на фронте тактового сигнала, что не соответствует поведению реального комбинационного оборудования, и это оказалось сложной проблемой при отладке этих конструкций с использованием дисплеев сигналов (I не включил эту информацию в статью).

С уважением - Клифф Каммингс - Verilog и SystemVerilog Guru

Я считаю, что причина, по которой синтез будет происходить правильно, заключается в том, что в реальном кремнии нет разницы между «блокировкой» и «неблокированием».

Synthesis прочитает это и создаст три шлепанца, прикованных спиной к спине, как вы описали.

Это не будет проблемой при синтезе (при условии, что вы не нарушаете время удержания флопа), потому что у настоящих гейт есть задержки. По нарастающему фронту clk потребуется несколько нс для того, чтобы значение d перешло в q1. К тому времени, когда d переходит в q1, q1 уже будет семплирован на втором флопе, аналогично с q2 и q3.

Причина, по которой это не работает при моделировании, состоит в том, что нет задержек гейта. На положительном фронте тактового сигнала q1 будет немедленно заменен на d, возможно, до того, как q1 был выбран вторым флопом. В реальной схеме (с правильной настройкой и временем удержания) q1 гарантированно будет дискретизирован по положительному фронту тактового сигнала до того, как первый флоп сможет изменить свое выходное значение.

Я знаю, что этому 3 года, но ваш пост просто пометили, когда кто-то попытался его отредактировать. Ответ Клиффа, конечно, исчерпывающий, но на самом деле он не отвечает на ваш вопрос. Другой ответ также совершенно неверен.

Мой вопрос: как определяется правильность синтеза Verilog, если не на основании семантики моделирования?

Вы, конечно, правы. Синтез является «правильным» только в том случае, если (а) результат (выход) моделируется таким же образом, как и исходный (входной), после возможного учета некоторых проблем с синхронизацией и т. Д., И / или (б) выход синтезатора может быть формально оказался эквивалентен входу синтезатора.

предоставить простейшую возможную программу Verilog, которая имеет четко определенную семантику синтеза и не имеет четко определенной семантики моделирования

В принципе, этого быть не должно. Производители синтезаторов пытались определить шаблоны, основанные на коде с четко определенной семантикой моделирования. Однако Verilog был (и остается) плохо определенным, а NBA изначально не существовали в языке, поэтому у вас есть странности, такие как пример с конвейером. Лучше забыть о них.

Фактически, может ли кто-нибудь дать мне часть Verilog, которая хорошо определена как при моделировании, так и при синтезе, но при этом они дают разные результаты?

Единственное определение термина «хорошо определенный» (в отличие от «правильного») в синтезе - это то, что несколько поставщиков будут давать один и тот же неверный результат. Это маловероятно. Я думаю, классический async reset и async set clocked F / F был бы близок.