Перейти к содержанию
    

Задержки при написании на VHDL

а вот RTL просмотрщик в симплифае лучше чем в XST :(

Конечно лучше, если учесть, что в XST его вообще нет. :biggrin:

 

Ну Падлавили :)) в ИСЕ есно :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я надеюсь, что автору темы подобный подход поможет быстрее решение. Автор темы мог бы выложить схему желаемой реализации проблемных узлов (достаточно для одного разряда) - это позволило бы дать конкретные рекомендации.

 

 

Спасибо за ответ,

а требования к трассировщику простые - не допускать удаления тригерров, которые я сам расставил и в особенности не удолять IFD и OFD, заменяя их простыми FD гдето внутри!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я еще раз взглянул в ваш проект и выяснил окончательно, что все результат (FPGA Editor) полностью соответствует с тем, что вы написали в исходнике. Вы заглядывали внутрь

макросов "iobfdbus" и "iobfd"? Блок ввода-вывода для каждого разряда шины DP содержит как OFD, так и IFD. Разряды шины DPI просто транслируют сигналы с выходов триггеров IFD (другого блока ввода-вывода - DP) а для сигналов шины DPOO нет триггеров, которые могли бы быть размещены в блок ввода-вывода, что и подтверждается результатами физического размещения (PLASE&ROUTE), а разная задержка объясняется разной длиной линий от IFD (IOB DP) до контактов DPI в первом случае и почти аналогично - во втором. Таким образом, результат соответствует проекту (вы явно перемудрили), а компилятор вообще не виноват (я все же вначале был не сразу во всем разобрался, когда первый раз рассматривал ваш проект, и погорячился с обсуждением возможностей компиляторов - здесь случай значительно проще).

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

 

Далее что касается компиляторов. За размещением триггеров в блоке ввода-вывода, в конечном итоге, отвечает физический транслятор (PLASE&ROUTE).

Для того, чтобы это произошло необходимо, выполнение 2-х условий:

1. Соответствующая настройка PLASE&ROUTE (галочка о размещении). Указывать что-либо дополнительное в исходнике для этого необязательно (см. п.2).

2. Построение исходника таким образом, чтобы к триггеру (получающемуся в результате компиляции), который вы подразумеваете в дальнейшем как OFD в блоке ввода-вывода был подключен только один(!) потребитель - выходной порт (выход триггера OFD может бытьподключен только к контакту и никуда больше). Если же это не так - триггер не может быть размещен в блок ввода-вывода.

 

Бывают и более сложные случаи, где для выполнения п.2 (исключение объединения дублирующихся триггеров в один и дальнейшего разветвления сигналов) необходимо использовать специальные атрибуты. Выход всегда помогает найти анализ того, что получилось, а так же изучение возможностей средств разработки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Далее что касается компиляторов. За размещением триггеров в блоке ввода-вывода, в конечном итоге, отвечает физический транслятор (PLASE&ROUTE).

Насколько я понимаю, за размещение триггеров в блоках ввода/вывода отвечает Map (если не брать во внимание, что некоторые средства синтеза еще на этапе синтеза позволяют использовать технологические примитивы IFD и т. д.), т. к. именно на этом этапе определяется четкое соответствие схемы и технологических примитивов (см. map report).

Для того, чтобы это произошло необходимо, выполнение 2-х условий:

1. Соответствующая настройка PLASE&ROUTE (галочка о размещении).

Галочка находится в параметрах процесса Map.

 

PS: здесь речь шла о Xilinx, до ISE 7.1 было так

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Галочка находится в параметрах процесса Map.

PS: здесь речь шла о Xilinx, до ISE 7.1 было так

 

Спасибо, что поправили. Все совершенно справедливо (я допустил неточность, хотя на самом деле подразумевался в целом процесс трансляции в кристалл "Implement Design").

 

Что касается средств синтеза, то могу добавить, что использование технологических примитивов типа IFD и OFD (включение в исходник как компонент) при наличии логических ошибок (невыполнение п.2 в моем предыдущем сообщении) может привести к остановке трансляции в кристалл и к сообщению об ошибке, что конечно само по себе не является недостатком такого подхода, однако это делать совсем не обязательно: бывает достаточно поставить галочку в параметрах процесса Map и получить желаемый результат (конечно если проект корректен).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не стоит забывать, что еще можно явно указать регистры размещаемые в IOB, с помощью констрейнов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пробую, описываю ATTRIBUTE IOB COMPONENT FD IS TRUE,

В одних случаях подключает, в других нет!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я стараюсь не в VHDL-исходниках hard-code'ить те моменты place'n'route, которые могут быть реализованы другими средствами. В частности, размещение триггеров в блоках ввода/вывода у меня делается директивой синтезатора и опцией map (согласен с коллегой Genn). Проблем не было.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...