Почему задержки нельзя синтезировать в verilog?

Я всегда читал, что задержки, объявленные в RTL-коде, никогда не могут быть синтезированы. Они предназначены только для целей моделирования, а современные инструменты синтеза просто игнорируют объявления задержек в коде.

Например: x = #10 y; будет рассматриваться инструментом синтеза как x = y;.

Может ли кто-нибудь объяснить причины, по которым объявления задержки на любом языке описания оборудования (например, VHDL, Verilog или System-Verilog) не могут быть синтезированы?


person Anand    schedule 12.07.2014    source источник
comment
Это перекрестный вопрос, поскольку он находится между SO и ElectronicsSE.   -  person Morgan    schedule 14.07.2014
comment
Во что вы хотите их синтезировать?   -  person shrm    schedule 15.07.2014
comment
@mishr Я хочу, чтобы они синтезировались в аппаратное обеспечение, генерирующее задержку.   -  person Anand    schedule 15.07.2014
comment
@Anand VHDL/Verilog обеспечивает задержку для моделирования присущей каждому компоненту задержки (например, вентилей), а не наоборот. В чем польза «аппаратного обеспечения, генерирующего задержку», о котором вы говорите?   -  person shrm    schedule 15.07.2014


Ответы (2)


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

assign #120 A = B * C;

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

Как написано в большинстве инструментов синтеза, вся информация о времени указана отдельно от вашего описания Verilog. Только функциональные аспекты вашего описания извлекаются из вашего кода Verilog. Гораздо проще получить временную информацию для часов и требования к вводу/выводу из отдельного файла, чем пытаться проанализировать свой тестовый стенд.

person dave_59    schedule 12.07.2014

В Verilog мы можем подразумевать логику, которая изменяет значение на фронтах тактовых импульсов, которые синтезируются в триггеры. Мы можем подразумевать несинхронизированную логическую логику, это синтезирует комбинаторную логику, просто набор И и ИЛИ.

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

Однако при производстве ASIC существует разница в скорости, на высоком уровне ее можно рассматривать как медленную, типичную и быструю. На практике существуют сотни вариантов таких углов, в которых одни типы кремниевых устройств работают быстро, а другие — медленно.

Эти углы кремния также имеют номинальную температуру, в худшем случае это может быть +140°C для быстрого кремния и -40°C для медленного кремния. Изменение задержки через буфер в этом случае может составлять от 1 нс до 30 нс.

Чтобы вернуть это в Verilog, если бы #10 можно было синтезировать, вы фактически получили бы 155+-145, то есть от 10 нс до 300 нс, если вы также разработали что-то с #20, чтобы быть частью того же интерфейса или структуры управления, это будет иметь диапазон 20 нс до 600нс. Поэтому все это на самом деле не действует против вашего дизайна.

Деревья часов спроектированы таким образом, чтобы ограничивать максимальные и минимальные задержки и таким образом, чтобы все узлы дерева часов масштабировались относительно друг друга. Им никогда не дается такое строгое правило, что это должно быть #10ns, так как это физически невозможно гарантировать в комбинаторной схеме.

person Morgan    schedule 12.07.2014