FakeDevice

Pavel_I, я прежде занимался всякими этими вашими программированиями. Вижу — Вы уже не нуб. Можно и подсказать )) Опишу собственный опыт. В подобных случаях, как мне подсказывает практика, искать причину нужно совершенно в другом месте. Отключите «Туннельное зрение» и разберётесь. Обычно причина, зачастую бывает, — тупая очепятка. Да, может и месяцами тормозиться проект, пока она там )) Если не получится — в личку напишите, бесплатно попробую помочь разобраться в ситуации. Сам уже давно в другую сферу перешёл, просто ностальгия долбанула )) Как наркотик, йо-маййоО! ))

Сделано на трансиверах. Подразумевается восстановление тактовой частоты. Я правильно понимаю? Если да, то ответ -- никто и никогда не пообещает вам никаких констант. В т.ч. и временных.

Здесь же таже самая проблема, заменить if rising_edge на wait until rising_edge

Если клок не указан в списке чувствительности процесса, то просто заменить на wait until rising_edge(clock);

если всё, о чём вспоминали тут, исправлено, но SPI_DATA по-прежнему в "X" или "U", то еще стоит обратить внимание на направление порта SPI_DATA : inout std_logic_vector(3 downto 0); двунаправленная шина. Заменив строки файла quadspi.vhd process(CLK) variable clk_count : integer range 0 to 6 := 0; begin if (rising_edge(CLK)) then case QSpiState is на process(CLK) variable clk_count : integer range 0 to 6 := 0; begin SPI_DATA <= "ZZZZ"; if (rising_edge(CLK)) then case QSpiState is можно увидеть, что на шине появляются значения отличные от "X" или "U". Но это в качестве примера, показать, как с двунаправленными шинами можно поступать. Точнее -- это надо с протоколом выверять. Высокий импенданс ('Z') можно подавать как со стороны тестируемого юнита, так и со стороны тестбенча.

еще осталась проблема с if (rising_edge(clock)) then в процессе stim_proc

Ды вот, пришлось вспомнить, где у меня тут что установлено ))

точно, да, инициализация один раз, если в теле нет обнуления, тупанул. Но всё же, покажите все сигналы/переменные из тестбенча. Что там куда пропадает? а, вижу. Тут проблема с чувствительностью процесса еще есть: wait until rising_edge(clock) бы лучше подошло

Может, просто переобозвалось как-то в среде? Несите скрин в студию, где у вас присутствует тот процесс, но ничего не генерируется. Ну и побольше накидайте в waveform всего, что найдете в тестбенче. Нет, это инициализация переменной (в данном случае clk_count). В VHDL сигналы и переменные немного разные сущности. Я бы настоятельно рекомендовал пока забыть про переменные, а пользоваться исключительно сигналами.

Ну так не бывает, чтобы совсем ничего. Давайте по порядку. clk3 формируется? По коду вижу, что должно, худо-бедно. clk_count не инкрементируется? Логично. При каждом "входе в процесс" переменная clk_count обнуляется (строка объявления переменной) [в данном случае переменной логично предпочесть сигнал, так оно понятней должно быть] Соответственно, максимальное значение, которого может достичь эта переменная будет равно 1. С последующим обнулением к следующему такту. Это во-первых. А во-вторых, сигнал QSpiState в каком состоянии находится? Нужно всё мониторить. Как правильно тут выше подсказали, забудьте пока про QUADSPI, сначала нужно с тестбенчем разобраться. Всё по иерархии. Сначала сигналы, которые явно задаются, затем всё, что от них зависит, после то, что зависит от зависимых и т.д. UPD: да, еще неприятный момент... qspi_cs <= '1'; wait for 80 ns; qspi_cs <= '0'; период такта 40 ns, а вы внутри периода ждете 80 ns. Как-то нелогично. Может, логичней state'ов добавить, чтобы просто такта за 3 всё это сделать, но без мешанины rising_edge+wait?

Не факт. В тестбенче у вас qspi_data зависит от некоторых сигналов. Например, от clk_count. Вы уверены, что clk_count и, соответственно, qspi_data формируются так, как вы ожидаете? Ну и сразу замечу, что конструкции типа являются некорректными. Вложенный rising_edge -- это неправильно. Плюс, вопрос на засыпку... Согласно тест-бенчу, как часто должно обновляться значение счетчика clk_count? Судя по коду -- оно вообще не будет обновляться. Процесс доходит до строки "wait;" и всё, до рестарта симуляции в этом процессе больше ничего не произойдет. Т.е. процесс нужно переписать либо так, чтобы он каждый раз срабатывал по очередному клоку, либо нужно будет использовать цикл, в котором последовательно, с учетом ожиданий следующих тактов, менялись бы значения clk_count и qspi_data. Но я бы для начала рекомендовал бы первый вариант, "перезапускаемый" процесс без оператора "wait;" А счётчик clk_count вообще можно вынести в другой процесс.

Это лишь часть правды. Выкладывайте весь модуль ))

Есть немного. Во-первых, непонятно, что с сигналом RST. на waveform его не видно, в тест-бенче он после инициализации тоже нигде не формируется. Ну и то, что прям по старту симуляции у вас на модуль идет управляющий сигнал SPI_CS -- тоже, как правило, неверно. Подождите хотя бы с 10-20 тактов, потом подавайте. Возможно, какая-то завязка есть. Затем, из картинки видно, что и на SPI_DATA постоянно подается "UUUU". Как должна реагировать в данном случае схема? Я тоже не знаю. В общем, проверяйте сигнал за сигналом, чтобы полностью соответствовало временным диаграммам из документации, для начала. А потом, если ВСЕ условия окажутся соблюденными, но так и не заработает -- будет иметь смысл разбираться дальше. Вы не торопитесь, тут больше зависит от внимательности и тщательности. Методом перебора здесь вы ничего хорошего не добьетесь.

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

Форсировать clock из "wave" -- точно неправильно. Разбирайтесь, добивайтесь того, чтобы из тест-бенча генерировался.