Значит этот компонент написан так, что он синтезируется правильно. Но в его описании есть ошибка, которая приводит к неправильному моделированию. Может где в списке чувствительности в компоненте U_MASTER_SPI ошибка.
А вообще странно, что Вы применяете компонент который неправильно моделируется. Обычно "в железе" идет тестирование тогда, когда моделирование прошло удачно. Во всяком случае у меня всегда идет тестирование в железе только тогда, когда моделирование работает как надо.
P.S. А вообще я уже могу назвать одну неприятную ошибку. У вас есть в проекте gated clock. Т.к Ваш модуль формирует клок либо системный, если делитель равен одному, либо деленный клок. И по этому "некрасивому" клоку у вас тактируются триггеры. Я бы так не делал.
UPD. Хотя тут не совсем gated clock. Тут клок сформированный на делителе. Он будет Gated если в процессе работы будут меняться коэфициенты делителя.
Я бы сформировал необходимый деленный клок. Затем выделил бы фронт этого клока детектором фронта. И весь проект бы тактировал от одного системного клока. А сформированный клок применял в качестве сигнала разрешения. Результат тот-же. Но Вы не уродуете тактовое дерево клоком, сформированным на делителе. И у вас нет никаких пересечений клоковых доменов, т.к все работает на едином клоке. Да и без особых причин лучше не заводить в тактовое дерево клок полученный делителем на логике. Н а крайний случай лучше уж PLL переконфигурирвоать в процессе работы и получать необходимый деленный клок,
А при чем тут тест, если сигнал s_mspi_clk формируется в компоненте U_MASTER_SPI ?
Если этот сигнал формируется неправильно логично предположить, что проблема в этом компоненте.
Я правильно понял, что в результате симуляции Вы ходите увидеть s_mspi_clk равный s_clk ?
Но тогда при чем тут тестбенч, который Вы здесь выложили. ?
Если s_mspi_clk неправильны, значит модуль, который формирует этот сигнал делает это неправильно...
И ещё один вопрос. Как у Вас используется в дальнейшем s_mspi_clk ? Как клок для тактирования триггров ?
Его не стоит избегать, а надо просто понимать что inout - это двунаправленный порт доступный только на выходных пинах. И применяется именно в качестве двунаправленного порта. Например шина данных DRAM памяти. Внутри самой ПЛИС никаких двунаправленных портов нет и попытка описать логику через такой порт - банальная ошибка в проектировании.
Всё просто:
REG_OUT_SEL1 : out std_logic_vector(5 downto 0);
REG_OUT_SEL2 : out std_logic_vector(5 downto 0);
signal out_sel1 : std_logic_vector(5 downto 0);
signal out_sel2 : std_logic_vector(5 downto 0);
signal iREG_OUT_SEL1 : std_logic_vector(5 downto 0); -- Внутренний сигнал для выдачи наружу и чтения
signal iREG_OUT_SEL2 : std_logic_vector(5 downto 0); -- Внутренний сигнал для выдачи наружу и чтения
out_sel1 <= iREG_OUT_SEL1; -- Читаем наш внутренний сигнал
out_sel2 <= iREG_OUT_SEL2; -- Читаем наш внутренний сигнал
REG_OUT_SEL1 <= iREG_OUT_SEL1; -- Выдаем наш внутренний сигнал наружу
REG_OUT_SEL2 <= iREG_OUT_SEL2; -- Выдаем наш внутренний сигнал наружу
when ST_WORD_READ =>
when X"0022" => sspi_data_out <= "0000000000" & out_sel1;
when X"0023" => sspi_data_out <= "0000000000" & out_sel2;
when ST_WORD_WRITE =>
when X"0022" => iREG_OUT_SEL1 <= sspi_data_in(5 downto 0);
when X"0023" => iREG_OUT_SEL2 <= sspi_data_in(5 downto 0);
Вообще VHDL 2008 вроде как поддерживает и чтение выходных портов внутри архитектурного тела. Но работает криво и не всегда.
Это и есть причина.
Sel не формируется. Поэтому выражение не выполняется. Поэтому всегда у нас работает ветка когда sel = 0 т.е на выход присваивается константа.
Вот только странно. В первом сообщении нужен обычный мультиплексор. А сейчас Вы хотите, чтобы он тактировался, т.е чтобы где-то ещё стоял триггер.
Так как вам надо то сделать ?
Никакой разницы между
X <= A when (SEL = '1') else B;
и
process(all)
begin
if (sel = '1') then
x <= a ;
else
x <= b ;
end if;
end process;
У нас нет.
А вот с задержкой распространения чуть сложнее. Т.к эта задержка сильно зависит от конкретной FPGA. Но 2..3 нс. слишком много. В FPGA большие задержки от физического входа (ножки) до самой матрицы. Как и наоборот, от матрицы до выхода.
Вроде как выдается сообщение о том, что Вы подключаете клок на PLL не через специально предназначенный для этого пин, и предупреждает что у такого клока будет большой Jitter.
Вот заниматься переводом чисел в калькуляторе это и есть заморачиваться. А преобразовывать типы - это не заморочки. Причем зачем везде писать std_logic_vector ?
Его имеет смысл использовать только на входных\выходных интерфейсах, или на интерфейсах, сопрягаемых с IP корками.
Ну Вы сами и ответили :rolleyes:
В случае если:
signal sig : std_logic_vector(7 downto 0);
То действительно выражение sig <= X"003" выдаст ошибу, ибо вы "впихиваете невпихуемое"
Примерно то же и с sig <= 3. Ибо сколько разрядов у Вас - знаете только Вы.
Напишите вот так:
sig <= std_logic_vector(to_unsigned(3,8));
Т.е явно укажите разрядность при конвертации типа стандартными библиотеками - то VHDL вас поймет.
Потому-что никто кроме Вас не знает какая в итоге нужна разрядность для представления вашего числа. VHDL - строг. Вы сами должны контролировать разрядность чисел.
