[Bad0512 2]

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

Ладно вопрос опять новичка.....на схеме понятно, где логика. А в проекте VHDL, синтезатор сам схему составляет (по идее разработчик должен понимать сам во что вльется код), но тем не менее....Получается по данной тематике лучше про конвейер почитать...? подскажите простой проект, чтобы применить данный подход и посмотреть на каком-то примере результаты с конвейером и без: ?

Есть много разных причин "плохих" таймингов. Проще объяснить проблему на конкретном примере, чем рассказывать сразу абстрактно обо всех возможных случаях. Приведите код, приводящий к проблемам а тайминге, тогда можно будет что-то посоветовать.

З Ы Судя по названиям в вашем примере исходник всё-таки - схема, а не VHDL.

 

[Gorby 6]

За 10 лет практики в области именно fpga ни разу не видел разработчика, который бы занимался симуляцией на уровне

выше функционального с пользой для дела (чиста для себя поиграться да, сам gate-моделированием занимался).

Для работоспособности достаточно функционального моделирования, правильное описание всех ограничений и

отсутствие временных ошибок на анализаторе.

Ага, а потом "включаешь - не работает" (с)

 

Слова Вы говорите правильные.

Но "правильное описание всех ограничений" Вы сделаете ...никогда. Ну или за бесконечное время.

 

Чисто функциональная симуляция типа

if rising_edge (CLK) then

x <= y;

end if;

 

при определенных обстоятельствах работает не так, как Вы ожидаете. Там обязательно нужна задержка.

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

 

А я вот никогда не делаю функциональную симуляцию. Только временнУю. Но зато с хорошим тестбенчем, внешней моделью ИС памяти

(с распознаванием ошибок), шина с реальными измеренными задержками и проч - это если делаю контроллер ДДР.

Такого перформанса Вы не достигнете только лишь с функциональной. Тогда зачем?! Быстрее симулирует? Но ведь симулирует НЕ ТО.

 

 

[Bad0512 2]

А я вот никогда не делаю функциональную симуляцию. Только временнУю.

Это означает лишь что ни с чем сложнее ДДР контроллера вы ещё не работали.

Многие проекты просто невозможно симулировать с реальными задержками именно из-за их объёма.

 

[Gorby 6]

Я создаю проект в VHDL. С начало выполняю behavior симуляцию. Как я понимаю это без учета задержек. Т.е. идеальный случай. И выполняю Post-Route симуляцию. Выполняю с помощью ISIM, кажется так называется

Это достаточно? Правда я файлов sdf не подключаю..он сам цепляется? Просто дело не в прошивке (загрузки конфигурации). Я хочу делать проект и быть уверенным, что завтра, когда я его запущу он заработает и я смогу его отдаить в случае чего. А не написать модель абстрактно, а потом еще сидеть огромное количество времени и думать как средой пользоваться, как выявлять ошибки , исправлять, отлаживать, откуда reset брать.

Я пока дальше симулятора не хожу.

 

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

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

 

Вы делаете всё правильно. Если Post-Route симуляция работает без ошибок, вероятность работающего дизайна в микросхеме приближается к 1.0 ;

 

Таки читать этот сигнал длительностью в один период клока надо по тому же фронту, по которому он был сформирован (rising). Этим Вы гарантируете максимальную гибкость дизайна.

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

Единственное, о чем стоит беспокоиться - это о соблюдении условий setup\hold для всех триггеров дизайна. К счастью, при правильном задании констрейнов ПО делает это автоматически.

Отсюда есть интересное следствие: если дизайн полностью синхронен, то необходимо и достаточно задать один-единственный констрейн - тактовую частоту.

 

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

 

Кстати о симуляторах. Таки Моделсиму и Ментор Графикс доверия больше, чем доморощенному ISIMу.

 

 

Это означает лишь что ни с чем сложнее ДДР контроллера вы ещё не работали.

Многие проекты просто невозможно симулировать с реальными задержками именно из-за их объёма.

То есть Вы запускаете Бураны на Альфу Центавра (ну типа сложный проект), причем функционально моделируется, а после разводки - уже нет?

Бред.

И как же Вы докажете Главному Принимающему (мамой клянусь?), что Ваш проект вообще рабочий? Типа смотрите, на столе в течении 10 минут работает?

Всегда можно моделировать по частям, или просто долго (некоторые проекты таки могут симулироваться десятки часов на секунду реального времени,

особенно если привлекается еще и процессор с эмуляцией его же софта).

Ну или голову включать и симулировать отдельные аспекты.

 

Знавал я одного программиста, который отказался работать с AVR Atmega644 (64кбайт флеш!) по той причине,

что скомпилированная AVR GCC с DEBUG информацией прошивка не влезала в эти 64К. Без отладочной информации - 4кб(!!!).

Оказался беспомощен без отладчика с хождением по строкам исходника.

[Bad0512 2]

То есть Вы запускаете Бураны на Альфу Центавра (ну типа сложный проект), причем функционально моделируется, а после разводки - уже нет?

Бред.

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

которые можно было поймать только на уровне gate-level симуляции с реальными задержками. Кроме того не забывайте, что никакой тестбенч не

покрывает 100% возможных ситуаций.

Разумеется, я не использую асинхронщину и прочее "шаманство".

 

 

[bogaev_roman 0]

То есть Вы запускаете Бураны на Альфу Центавра (ну типа сложный проект), причем функционально моделируется, а после разводки - уже нет?

Бред.

И как же Вы докажете Главному Принимающему (мамой клянусь?), что Ваш проект вообще рабочий? Типа смотрите, на столе в течении 10 минут работает?

Конкретно я писал именно про fpga, а не ASIC. Извиняюсь за оффтоп, но принимал участие в разработке прототипов на протяжении нескольких лет, к примеру, вот этого устройства (это еще не самое сложное) http://www.mcst.ru/server_elbrus-4.4. Так вот сам прототип состоял из нескольких десятков плисин и был предназначен для отработки алгоритмов не только самого процессора, но и всей обвязки (включая DDR3). После настройки и правильного задания всех ограничений сам прототип без сбоев работал очень долго (месяцы), а Вы утверждаете, что все ограничения описать невозможно. Там из временных ограничений было только описание частот, мультициклы и были ошибки по холдам в контроллерах DDR3 - пришлось жестко отодвинуть выходы регистров на приеме от пинов - все. Некоторые элементы Вы вообще не сможете промоделировать на Gate-уровне, к примеру, гигабитные приемопередатчики - производитель функциональную ( ) модель только дает.

[go2winner 0]

 

Проект не мой, я сам вписал ограничение на глобальную тактовую частоту (там еще пару глобальных сигналов есть, но их пока не трогал)

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

NET "GEN_100MHz" TNM_NET = GEN_100MHz;
TIMESPEC TS_GEN_100MHz = PERIOD "GEN_100MHz" 100 MHz HIGH 50%;

и откомпилировал (как вы советовали выше)

 

Потом зашел в пункт Static Timing . Собственно там есть n-ое количество крестиков. Вот пытаюсь осознать, как сначало извлечь оттуда побольше информации , а потом, как ею воспользоваться для устранения минусов.

 

 Maximum Data Path at Slow Process Corner: XLXI_7012/Q0 to XLXI_1112/Q_0 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X29Y6.CQ       Tcko                  0.430   NB0 
                                                        XLXI_7012/Q0 
     SLICE_X27Y6.C4       net (fanout=15)       0.780   NB0 
     SLICE_X27Y6.C        Tilo                  0.259   XLXN_40258 
                                                        XLXI_8788/Mmux_D11111 
     SLICE_X27Y6.B6       net (fanout=4)        0.353   Sel_B11 
     SLICE_X27Y6.B        Tilo                  0.259   XLXN_40258 
                                                        XLXI_10176 
     SLICE_X29Y5.C1       net (fanout=3)        0.741   Set_command 
     SLICE_X29Y5.C        Tilo                  0.259   B3_Mux<2> 
                                                        XLXI_5856 
     SLICE_X31Y2.A3       net (fanout=8)        1.528   CE_AT 
     SLICE_X31Y2.A        Tilo                  0.259   ARX_CH6<3> 
                                                        XLXI_8115 
     SLICE_X32Y2.CE       net (fanout=1)        0.347   XLXN_22878 
     SLICE_X32Y2.CLK      Tceck                 0.314   ARX_CH5<3> 
                                                        XLXI_1112/Q_0 
     -------------------------------------------------  --------------------------- 
     Total                                      5.529ns (1.780ns logic, 3.749ns route) 
                                                        (32.2% logic, 67.8% route)

 

 

Огромное спасибо. я даже не заметил (точнее не знал о колонке с путями). На самом деле часть этого проекта неработоспособна (как раз временные задержки), поэтому я его использую. Как раз данный путь показывает неработоспособный кусок (из -за задержек.)....

 

Как это схемно выглядит...я рисунок приведу этого пути..... (коряво, но суть понятна)

 

ну и все в таком духе...теперь как интегрпетировать все результаты?

Slack (setup path):     -11.755ns (requirement - (data path - clock path skew + uncertainty))

К примеру clock path skew и slack setup...почему значение отрицательное?

 

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

Получаются данные слишком поздно приходят?

Изменено 28 апреля, 2016 пользователем go2winner

[andrew_b 16]

А я вот никогда не делаю функциональную симуляцию. Только временнУю

Ну возьмите, например, пятую серию Альтеры и сделайте временную. А я посмотрю.

[bogaev_roman 0]

Получаются данные слишком поздно приходят?

Да, но проблема не в этом. Каким тактовым сигналом тактируется триггер XLXI_7012/Q0? Вы его не задали в ограничениях и анализатор не знает как это интерпретировать и развести. В результате получаете непонятно что. Проверьте, то о чем я уже писал. Просто такое ощущение, что у Вас несколько частот, несвязанных между собой (триггер источник работает на одной, приемный на другой)

Tools->constraints editor и посмотрите, какие ограничения подчеркнуты красным (это то, что используется в качестве тактового сигнала, но реальные значения в ограничениях не прописаны)

[go2winner 0]

Да, но проблема не в этом. Каким тактовым сигналом тактируется триггер XLXI_7012/Q0? Вы его не задали в ограничениях и анализатор не знает как это интерпретировать и развести. В результате получаете непонятно что. Проверьте, то о чем я уже писал. Просто такое ощущение, что у Вас несколько частот, несвязанных между собой (триггер источник работает на одной, приемный на другой)

 

Там по-правде несколько частот глобальных.....на всех нужно получается ввести ограничения (подобно Вашим примерам и тому как я первый задал), а после компилировать?

Там два тригерра , с одной и той же частотой, но разный фронт (инверсный тактовый сигнал)

 

 

 

Сигнал получается путем инверсии входной тактовой.....как быть? его нет в списке на ограничения? Они видны только в разделе Exception-> nets

 

Те. идет вход тактовой частоты......От нее идет сеть с названием Mhz_100....от этой сети на выходе получается еще одна сеть с другим названием и ивертированным значением.

Изменено 28 апреля, 2016 пользователем go2winner

[bogaev_roman 0]

Там по-правде несколько частот глобальных.....на всех нужно получается ввести ограничения (подобно Вашим примерам и тому как я первый задал), а после компилировать?

Вы слишком большой пласт информации пытаетесь поднять. Я советовал начать с синхронного дизайна и одной тактовой. Если частоты формируются не из одной pll, то требуется грамотный переход из одного клокового домена в другой, читайте статьи iosifk. В общем случае все сигналы, которые используются, в качестве тактовых отображаются в окне

Все частоты должны быть описаны. Насчет инверсного клока - зачем его потребовалось инвертировать и каким образом это реализовано (просто инвертор)?

[go2winner 0]

Все частоты должны быть описаны. Насчет инверсного клока - зачем его потребовалось инвертировать и каким образом это реализовано (просто инвертор)?

 

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

Почему-то ее все равно нету в списке глоб частот.

 

У меня простые проекты, там исследовать нечего..там опыт описания нарабатывать сначало(

И тайм анализ показывает правильно, что рекомендуется 5нс (т.е. он понимает, что там 100 мгц, но по один конец пути по заднему второй переднему...если я правильно все понимаю.

Изменено 28 апреля, 2016 пользователем go2winner

[bogaev_roman 0]

Тогда в чем проблема с таймингом....если тригерры фактически зависят от одной и той же глоб частоты (только одна инверсная)

А какой путь пройдет тактовая частота сначала до инвертора, потом до глобального буфера (даже если известно его положение), согласно чему будет определено местоположение инвертора? Так обычно не делают, варианта два - сформировать на pll удвоенную частоту и работать по фронту и сформировать управляющий сигнал ce, который фактически и будет говорить о том, работает по фронту или срезу, либо на pll сформировать дополнительную частоту, сдвинутую на 180 (в этом случае во временных ограничениях нужно указать только исходную частоту, остальное анализатор поймет и сделает сам). Вариант 1 проще и лучше.

[Bad0512 2]

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

Две серьёзных ошибки тут уже :

1. Gated clock - нельзя получать инверсный клок таким способом (инверсией на логике). Если нужна инверсия клока (скорее всего не нужна) - заводите на PLL и крутите там фазу клока на 180 градусов.

2 - Работа по падающему фронту - никаких плюсов от такого подхода нет, только ухудшается в 2 раза временной бюджет.

Всё это неоднократно обсуждалось на этом форуме и не только.

 

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