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

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

Делаю устройство, рабочая частота которого 160 МГц, так же имеется двухнаправленная шина данных 64 разряда!

Создал проект в симуляторе до трассировки все успешно работало, ну а после...

В общем понял что весь проект можнго выкидывать, даже начиная с входных-выходных буффферов. Начал заново, сначало с одним IOB, затем с 64. При симуляции после полной разводки ПЛИС я добился минимальных задержек.

Но вот проблема используя внутренний блок для выдачи информации на шину, описанный на VHDL я получаю ужасную картину "гонки" сигналов данных, которая не зависит от входных-выходных буферов!

 

Может котнибудь подсказать как правильно описывать алгоритм работы на VHDL при такой разрядности сигнала?

 

Код тестового проекта представленн в архиве!

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


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

Делаю устройство, рабочая частота которого 160 МГц, так же имеется двухнаправленная шина данных 64 разряда!

Создал проект в симуляторе до трассировки все успешно работало, ну а после...

В общем понял что весь проект можнго выкидывать, даже начиная с входных-выходных буффферов. Начал заново, сначало с одним IOB, затем с 64. При симуляции после полной разводки ПЛИС я добился минимальных задержек.

Но вот проблема используя внутренний блок для выдачи информации на шину, описанный на VHDL я получаю ужасную картину "гонки" сигналов данных, которая не зависит от входных-выходных буферов!

 

Может котнибудь подсказать как правильно описывать алгоритм работы на VHDL при такой разрядности сигнала?

 

Код тестового проекта представленн в архиве!

 

Какой файл то смотреть ?? насчет гонки нужно делать регистровые выходы у модулей и будет счастье :)

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


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

и еще пользоваться в синтезируемых консструкциях процессами, а не wait untill ИМХО :)

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


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

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

 

Двунаправленная шина на VHDL 64 разряда:

Порты:
 D : inout std_logic_vector(63 downto 0);
 DI : in std_logic_vector(63 downto 0);
 DO : out std_logic_vector(63 downto 0);
 E : in std_logic;
Код архитектуры:
 DI <= D;
 D <= DO when E = '1' else (others => 'Z');

Здесь буфер открывается сигналом E = '1'.

 

Удачи

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


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

Все это учтенно, если вы посмотрите в архив, то увидете там весь проект для ISE 6.3 (cnt.vhd - используется как верхний уровень), и у каждого IOB стоит тригер как на вход так и на выход, так же использую атрибуты MAXDELAY - на данные и PERIOD - на тактовую!

А процес переключения данных из одного значения в другое протекает больше одного такта, а мне это недопустимо!!!

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


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

для таких частот смотри в сторону timing constraint, правильно клоки подключай, ну и с асинхронными сигналами поосторожней....

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


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

А Вы смотрели в FPGA editor? Если нет, то посмотрите и увидите, что сигнал для выхода DPI(63:0) берется от триггеров в блоках ввода-вывода DP(63:0), а это значит что для разных разрядов задержка от IOB "DP(..)" до IOB "DPI(..)" будет различна. Пересмотрите логику схемы: зачем дублировать сигнал DP(63:0) в DPI(63:0) таким образом. Лучше разместить OFD как блоках ввода-вывода DP(63:0), так и в блоках ввода-вывода DPI(63:0).

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


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

Предложение использовать два буфера не приводит к требуемому результату, вообще интересно пишу использовать OBD и IFD, а трассировщик их выкидывает, но не у всей шины, у парочки оставляет, а это уже задержка на такт!

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


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

Предложение использовать  два буфера не приводит к требуемому результату, вообще интересно пишу использовать OBD и IFD, а трассировщик их выкидывает, но не у всей шины, у парочки оставляет, а это уже задержка на такт!

 

Хочу уточнить: оптимизация может производиться как на этапе синтеза списка цепей (компилятор языка), так и на этапе размещения и трассировки в кристалле (Plase&Route). Оптимизацию на втором этапе можно вообще отключить в настройках Plase&Route (по умолчанию после установки пакета она отключена), а вот оптимизацией на этапе синтеза можно поуправлять с помощью атрибутов в исходном тексте (каких - это зависит от используемого компилятора) и даже не включать системные примитивы типа IFD. А еще не плохо бы посмотреть "критические узлы" по итогам синтеза (опять-таки если компилятор предоставляет такую возможность). Если же не найден путь управления компилятором, то есть надежный метод - создание "черных ящиков" (модулей созданных в FPGA Editor).

Замечание. Компилятор XST - мягко говоря не самый удачный выбор.

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


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

А какой компилятор для Xilinx Vertex E можно использовать, если не XST?

 

Например Simplify или Leonardo Spectrum. Эти продукты достаточно гибки и дают возможность управления процессом синтеза.

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


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

А какой компилятор для Xilinx Vertex E можно использовать, если не XST?

 

Например Simplify или Leonardo Spectrum. Эти продукты достаточно гибки и дают возможность управления процессом синтеза.

 

А можно глупый вопрос, что в вашем понимании управление процессом синтеза ?

И почему XST не дает им управлять ?

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


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

А можно глупый вопрос, что в вашем понимании управление процессом синтеза ?

И почему XST не дает им управлять ?

 

Вопрос даже очень неглупый. Я попытаюсь дать пояснения (в меру своего понимания), но конечно в контексте обсуждаемой темы (заниматься обсуждением ПО не совсем корректно). Каждый компилятор реализует определенный алгоритм синтеза, который выполняет оптимизацию на основе выбранной стратегии (оптимизация по скорости, оптимизация по количеству используемой логики, тип конечных автоматов FSM..). Управление процессом синтеза заключается не только в возможности выбора стратегии, но в возможности задавать ограничения (constraints) функциональным узлам внутри проекта, что позволяет еще на этапе написания исходного текста представлять физичесую реализацию в кристалле.

 

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

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

 

Что касается XST, то возможно, что моя реплика была излишне эмоциональна, но я от нее не отказываюсь и вот почему: компилятор XST впервые появился в ISE4, как альтернатива компилятору "FPGA Express" (которым я и пользовался) и оба этих компилятора существовали в четвертой версии. Однако уже в пятой версии ISE в комплекте остался лишь XST, и поэтому стоял выбор какой компилятор использовать. Пришлось провести сравнение в рамках ISE4: XST, FPGA Express, Simplify, Leonardo Spectrum. У меня был проект (Virtex2 - 500), к которому я подключал по очереди все четыре компилятора. Данные, которые получились позволяют оценить совершенство алгоритма синтеза (использование ресурсов кристалла): FPGA Express - 92%, Sinplify - 86%, Leonardo Spectrum - 85%, XST - 105% (увы, не поместился). Замечу, что устанавливались достаточно жесткие ограничения по быстродействию (были выполнены в первых трех случаях). Что касается гибкости, то XST (ISE4) мне так и не удалось заставить компилятор не вставлять автоматически тактовый буфер, там где он не нужен.

Перед ответом на последнюю реплику я посмотрел на возможности XST (ISE6.3) и скажу что документация регламентирует множество настроек, что вселяет надежду, алгоритмы синтеза тоже притерпели изменения (я извлек из архива тот же проект и получил 95% - уже поместился, но все равно последний). Возможно я и не "копнул" достаточно глубоко XST (ISE6.3), но переходить на него пока не собираюсь, и сейчас использую Synplify (Synplify Pro), а иногда и Leonardo Spectrum (компании Synplicity и Mentor Graphics имеют большую практику в создании подобных программных продуктов и используемые в них алгоритмы более отточены).

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


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

Вопрос даже очень неглупый. Я попытаюсь дать пояснения (в меру своего понимания), но конечно в контексте обсуждаемой темы (заниматься обсуждением ПО не совсем корректно). Каждый компилятор реализует определенный алгоритм синтеза, который выполняет оптимизацию на основе выбранной стратегии (оптимизация по скорости, оптимизация по количеству используемой логики, тип конечных автоматов FSM..). Управление процессом синтеза заключается не только в возможности выбора стратегии, но в возможности задавать ограничения (constraints) функциональным узлам внутри проекта, что позволяет еще на этапе написания исходного текста представлять физичесую реализацию в кристалле.

 

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

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

 

Что касается XST, то возможно, что моя реплика была излишне эмоциональна, но я от нее не отказываюсь и вот почему: компилятор XST впервые появился в ISE4, как альтернатива компилятору "FPGA Express" (которым я и пользовался) и оба этих компилятора существовали в четвертой версии. Однако уже в пятой версии ISE в комплекте остался лишь XST, и поэтому стоял выбор какой компилятор использовать. Пришлось провести сравнение в рамках ISE4: XST, FPGA Express, Simplify, Leonardo Spectrum. У меня был проект (Virtex2 - 500), к которому я подключал по очереди все четыре компилятора. Данные, которые получились позволяют оценить совершенство алгоритма синтеза (использование ресурсов кристалла): FPGA Express - 92%, Sinplify - 86%, Leonardo Spectrum - 85%, XST - 105% (увы, не поместился). Замечу, что устанавливались достаточно жесткие ограничения по быстродействию (были выполнены в первых трех случаях). Что касается гибкости, то XST (ISE4) мне так и не удалось заставить компилятор не вставлять автоматически тактовый буфер, там где он не нужен.

Перед ответом на последнюю реплику я посмотрел на возможности XST (ISE6.3) и скажу что документация регламентирует множество настроек, что вселяет надежду, алгоритмы синтеза тоже притерпели изменения (я извлек из архива тот же проект и получил 95% - уже поместился, но все равно последний). Возможно я и не "копнул" достаточно глубоко XST (ISE6.3), но переходить на него пока не собираюсь, и сейчас использую Synplify (Synplify Pro), а иногда и Leonardo Spectrum (компании Synplicity и Mentor Graphics имеют большую практику в создании подобных программных продуктов и используемые в них алгоритмы более отточены).

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

ИМХО разработчкики XST, все таки оставляют контроль синтеза (под контролем я понимаю результирующую схему) на разработчика, именно для этого они ввели такое количество настроек (констрейны синтеза, размещениея и т.д.)

И ИМХО XST прививает большую аккуратность при написании синтезируемого кода, как раз из-за своей большей "дубовости". Но в этом есть и минусы это большее кол-во времени на оптимизацию блока в XST.

Симплифай же являеться более мошьным инструментом, но ИМХО с ним есть соблазн описать блок проще, и более грубо, надеясь на синтезатор.

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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