VHDL Compare не работает в аппаратном обеспечении, но работает в моделировании

Привет, ребята, у меня есть следующий VHDL, который не делает то, что должен делать в аппаратном обеспечении, но работает в моделировании. В основном у меня есть счетчик, и в зависимости от счетчика я хочу, чтобы определенные данные выводились, я реализовал мультиплексор следующим образом:

write_data  <=  
('1' & '0' & "1111"                                                              )  when (data_cnt_r < 1)  else             
('0' & '0' & "1111"                                                              ) when (data_cnt_r >= 1 and data_cnt_r < 2 ) else
('0' & '0' & "0000"                                                              ) when (data_cnt_r >= 2 and data_cnt_r < 3 ) else  
('0' & '0' & data_reg                                                        ) when (data_cnt_r >= 3  and data_cnt_r < 1027 ) else
('0' & '1' & CRC16_o(63) & CRC16_o(47) & CRC16_o(31) & CRC16_o(15) ) when (data_cnt_r >= 1027  and data_cnt_r < 1043 ) else 
('0' & '0' & "1111");   

Проблема, с которой я сталкиваюсь, заключается в том, что когда счет равен 1043, я вижу вывод CRC вместо «1111» для последней строки кода. В симуляции это работает так, как я и ожидал. Есть ли лучший способ написать это? Любые идеи, почему несоответствие?

* РЕДАКТИРОВАТЬ Более подробную информацию по запросу:

я использую

   use IEEE.STD_LOGIC_UNSIGNED.ALL; 

data_cnt — счетчик свободного запуска, все — std_logic_vector или std_logic

    signal data_cnt_r       : std_logic_vector(11 downto 0); -- 12 bit counter

write_data поступает в BUFIO и также является стандартным логическим вектором.


person user968102    schedule 03.11.2011    source источник
comment
Вы можете рассмотреть возможность использования (n = 0) вместо (n ‹ 1). Кроме того, предполагая логику с двумя состояниями для data_cnt_r, первое условие во всех случаях является избыточным.   -  person    schedule 04.11.2011
comment
каков тип данных data_cnt_r?   -  person Philippe    schedule 04.11.2011
comment
Я не думаю, что проблема только в этой строке. Мне, вероятно, нужно увидеть больше кода. Обычно расхождения между симуляцией и аппаратным обеспечением сводятся к таким вещам, как неправильные списки чувствительности, но это не в процессе. Они также должны появляться в качестве предупреждений во время sim/syn.   -  person Paul S    schedule 04.11.2011


Ответы (1)


Что происходит рядом с другими вашими переходами? (1027, 3, 2, 1) это в блоке процесса или асинхронно? является ли data_cnt_r беззнаковым? А как насчет значений data_reg и CRC? Я предполагаю, что оба std_logic_vectors?

Нам нужно немного больше контекста

вы можете попробовать явно добавить переход, чтобы увидеть, поможет ли это аля:

('0' & '1' & CRC_stor)  when (data_cnt_r >= 1027 and data_cnt_r < 1043 ) else 
('0' & '0' & "1111"  )  when (data_cnt_r = 1043) else
('0' & '0' & "1111"  );

если это на самом деле находится в синхронизированном блоке процесса, вы можете увидеть значения CRC в write_data через тактовый цикл, но тогда вы также увидите эту проблему вокруг других ваших переходов (все они будут обновлять цикл после data_cnt_r)

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

Кроме того, это немного легче читать.

CRC_stor <= CRC16_o(63) & CRC16_o(47) & CRC16_o(31) & CRC16_o(15)

write_data  <=  
   ('1' & '0' & "1111"  )  when (data_cnt_r = 0) else             
   ('0' & '0' & "1111"  )  when (data_cnt_r = 1) else
   ('0' & '0' & "0000"  )  when (data_cnt_r = 2) else  
   ('0' & '0' & data_reg)  when (data_cnt_r >= 3    and data_cnt_r < 1027 ) else
   ('0' & '1' & CRC_stor)  when (data_cnt_r >= 1027 and data_cnt_r < 1043 ) else 
   ('0' & '0' & "1111"  );
person Paul Seeb    schedule 04.11.2011
comment
Хорошие моменты, спасибо всем, я ценю отзывы и помощь каждого, я решил эту проблему. У меня было две проблемы. 1) Я не регистрировал выходные данные, 2) Выходные часы должны быть на 90 не в фазе, а данные выходят из FPGA, чтобы устройство синхронизировалось правильно. - person user968102; 05.11.2011