Jump to content

    
Sign in to follow this  
DLR

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

Recommended Posts

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

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

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

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

 

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

 

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

Share this post


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

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

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

Двунаправленная шина на 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'.

 

Удачи

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

А Вы смотрели в 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).

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

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

Share this post


Link to post
Share on other sites
А какой компилятор для Xilinx Vertex E можно использовать, если не XST?

 

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

Share this post


Link to post
Share on other sites
А какой компилятор для Xilinx Vertex E можно использовать, если не XST?

 

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

 

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

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

Share this post


Link to post
Share on other sites
А можно глупый вопрос, что в вашем понимании управление процессом синтеза ?

И почему 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 имеют большую практику в создании подобных программных продуктов и используемые в них алгоритмы более отточены).

Share this post


Link to post
Share on other sites
Вопрос даже очень неглупый. Я попытаюсь дать пояснения (в меру своего понимания), но конечно в контексте обсуждаемой темы (заниматься обсуждением ПО не совсем корректно). Каждый компилятор реализует определенный алгоритм синтеза, который выполняет оптимизацию на основе выбранной стратегии (оптимизация по скорости, оптимизация по количеству используемой логики, тип конечных автоматов 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 :(

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this