Целочисленный вывод превращается в двоичный при синтезе ISE
У меня есть счетчик VHDL BCD, выход которого представляет собой целочисленное значение (цифру).
Но когда я моделирую код в Xilinx ISE, он показывает форму сигнала кода в двоичном формате. Код работает, но вывод должен быть целым числом, но это не так. Я протестировал этот код в Modelsim, и результат правильный и имеет целочисленное значение. Эта проблема также связана с синтезом кода, и значение является двоичным.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity bcdcnt is
Port ( clk : in STD_LOGIC;
digit : out INTEGER RANGE 0 TO 9);
end bcdcnt;
architecture Behavioral of bcdcnt is
begin
count: PROCESS(clk)
VARIABLE temp : INTEGER RANGE 0 TO 10;
BEGIN
IF (clk'EVENT AND clk = '1') THEN
temp := temp + 1;
IF (temp = 10) THEN temp := 0;
END IF;
END IF;
digit <= temp;
END PROCESS count;
end Behavioral;
Вы имеете в виду ISim от Xilinx ISE? Руководство пользователя ISim UG660 (v14.3) от 16 октября 2012 г. в ISE 14.7 есть гл. 4: Анализ формы волны, Настройка конфигурации волны, Основания, объясняющие, как изменить основание формы волны. Вы также ожидаете, что целые типы будут преобразованы в двоичный тип при синтезе.
Ответы 1
Вот что делает синтез.
Это то, что ДОЛЖЕН делать синтез: он переводит ваш высокоуровневый дизайн в ресурсы вашей FPGA или ASIC, которые являются двоичными. Итак, в чем проблема?
Если вам нужно смоделировать результат после синтеза, обычный подход заключается в создании объекта-оболочки, который принимает правильные типы портов и выполняет преобразование между ними и компонентом списка соединений после синтеза.
Затем симуляция должна работать либо с исходным объектом, либо с этим объектом-оболочкой, оба из которых имеют целочисленные порты.
Более того, вы можете повторно использовать один и тот же объект и добавить оболочку в качестве второй архитектуры, тем самым гарантируя, что она использует тот же интерфейс (порты).
(Вы даже можете создать и оригинал, и пост-синтезатор в его обертке на тестовом стенде, параллельно с компаратором на их выходах, чтобы увидеть, что они оба делают одно и то же. Но обратите внимание, что между ними будут задержки на уровне ворот; обычно вы проверяете выходы только по краям тактов, поэтому они не имеют значения.)
Другой подход заключается в том, чтобы ограничить типы портов на верхнем уровне дизайна двоичными типами, такими как std_logic_vector. Это лучше работает с плохо разработанными инструментами, такими как ISE, где автоматически сгенерированный тестовый стенд будет иметь бинарные типы портов (я обычно редактирую их обратно на правильные; почти легче писать ТБ с нуля).
Но это ограничивает вас использованием неясного и сложного стиля дизайна вместо абстракций более высокого уровня, таких как целые числа.
Плохо, очень плохо, что этот подход так широко преподается и поощряется. Но это так, и иногда вам просто придется с этим жить. (Даже при таком подходе нет причин избегать приличных абстракций внутри FPGA, если инструмент синтеза их понимает).
Третий подход — грубо говоря, «доверяй, но проверяй» — заключается в том, чтобы верить в то, что инструменты синтеза написаны грамотно (что обычно верно), и забыть о моделировании после синтеза.
Просто тщательно проверьте проект на поведенческом уровне в моделировании, затем синтезируйте его и протестируйте в реальных условиях ПЛИС.
В 99% случаев (если только вы не пишете действительно странный VHDL), синтезатор и P&R поступают правильно, и любые различия, которые вы видите, связаны с вышеупомянутыми таймингами ввода-вывода (задержки ворот на входе-выходе). булавки). Затем смоделируйте их в тестовом стенде и/или оболочке, пока не увидите одинаковое поведение в обоих случаях (исправьте все, что нужно исправить, и повторно синтезируйте).
При таком подходе вам нужно возиться только с (ГОРАЗДО более медленными) симуляциями после синтеза и после PAR, если вам нужно отследить предполагаемую ошибку инструмента синтеза.
Такое бывает: я видел двоих за четверть века.
В большинстве случаев я просто использую третий подход.
Во всех существующих технологиях целое число будет представлено как двоичное число на реальном оборудовании.