Нечетный вопрос VHDL: восходящий клин (CLK) не стреляет - PullRequest
Новая
       8

Нечетный вопрос VHDL: восходящий клин (CLK) не стреляет

0 голосов
/ 04 декабря 2018

У меня есть большой имитационный испытательный стенд, который выполняет интерфейс между двумя ультрамаскими FPGA Kintex.У меня возникла странная проблема: я не могу заставить запускатьising_edge (CLK).

В проекте есть несколько примеров этого: я прослежу логический путь и получуобнаруживая восходящий_круг (что угодно), который не стреляет.

Вот кикер: заменаising_edge с CLK'EVENT и CLK = '1' приводит к корректному срабатыванию логики, но я не могу просмотреть тысячу исходных файлов, чтобы заменить их все, а затем нажать нагрупповое репо - это было бы абсурдно (плюс код действителен и использовался несколько раз, поэтому внесение такого изменения было бы огромной тратой времени).

Восходящий_круг также эквивалентенCLK'LAST = '0' и CLK'EVENT и CLK = '1' - это утверждение также не запускается.Так что, должно быть, CLK'LAST = '0' не удовлетворен, верно?(Если CLK'EVENT и CLK = '1' срабатывает, а добавление CLK'LAST = '0' не срабатывает, то это должен быть последний элемент, вызывающий проблему).

Однако я смотрюпри дельта-просмотре я не вижу промежуточных значений между 0 и 1 - нет промежуточных состояний с высоким Z, нет неопределенного сигнала, ничего.Выглядит отлично.

Я проверил это с несколькими различными версиями Modelsim с одинаковым результатом (просто чтобы убедиться, что это не регрессия инструмента).

Что в мире может быть причиной этого?

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

Может ли использование внешних имен для принудительной установки значений каким-то образом вызвать пропадание края, даже если сигналы выглядят правильно (даже до дельт?), Или это может вызвать некоторую несоответствие окна формы сигнала?Что заставляет CLK'LAST эффективно теряться?

Спасибо всем!

Ответы [ 2 ]

0 голосов
/ 05 декабря 2018

Я предполагаю, что вы используете VHDL force для этих иерархических сигналов.Если это так, я столкнулся с той же проблемой, используя ModelSim.Я не уверен, что это связано с реализацией ModelSim поддержки VHDL-2008 или чем-то подобным.

Находя это, я обычно использую команду ModelSim force через макрос TCL, а не VHDL, так каккоманда ModelSim ведет себя более предсказуемо (в том числе распознается rising/falling_edge()) и (без IEEE 1076, доступной для ссылки), я считаю, что она поддерживает больше параметров, чем версия VHDL.

0 голосов
/ 04 декабря 2018

Если тип CLK не является bit, например, если это std_ulogic или std_logic, то нет, rising_edge(CLK) не эквивалентно: 

CLK'EVENT and CLK='1'

или: 

CLK'LAST='0' and CLK'EVENT and CLK='1'

rising_edge(CLK) также включает 'L' и 'H';он возвращает true для любого перехода от '0' или 'L' к '1' или 'H'.То есть любой из: 

'L' -> 'H'
'L' -> '1'
'0' -> 'H'
'0' -> '1'

В то время как CLK'EVENT and CLK='1' оценивается как истинный для любого из: 

'U' -> '1'
'X' -> '1'
'0' -> '1'
'Z' -> '1'
'W' -> '1'
'L' -> '1'
'H' -> '1'
'-' -> '1'

Так, например, переход от 'H' к '1',не является нарастающим фронтом для rising_edge(CLK), но для CLK'EVENT and CLK='1'.И, наоборот, переход от '0' к 'H' является нарастающим фронтом для rising_edge(CLK), но не для CLK'EVENT and CLK='1'.

Другая потенциальная причина этой проблемы гораздо менее вероятна: вы используетепользовательская версия функции rising_edge ...

...