Задача в общих чертах выглядит так. Есть FPGA Virtex4 11 speed grade. К ней подключен АЦП. С АЦП данные идут на частоте 200МГц (CLK1) и попадают в FIFO. Вся логика дальнейшей обработки данных тактируется внешним генератором 400МГц (CLK2). Так вот по CLK2 при компиляции и фиксируются множественые Timing Errors. В UCF файле на тактовую цепь есть запись
NET "CLK" TNM_NET = "CLK";
TIMESPEC "TS_CLK" = PERIOD "CLK" 2.5 ns HIGH 50%;
Ошибки не исчезают. И логика обработки данных работает не стабильно, хотя в симуляторе все проверено и отлажено.
Возможно ли победить данную проблему и какие пути решения существуют без замены ПЛИС.

Вы в симуляторе проводили функциональное моделирование или временное?
Если только функциональное, то просмотрите внимательно все пути с временными ошибками и анализируйте их - меняйте алгоритм, параллельте, добавляйте ограничения и т.д. Хотя 400МГц - не подарок, возможно следует как-то перейти на более низкую частоту. Какая максимальная триггерная частота для данной ПЛИС?

400 мгц для этого кристалла очень близко к максимуму. А Timing Score какой показывает?

400 на таком чипе, для толстого дизайна? нереально %)

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

По вашей же гиперссылке для -11 кристалла граничная частота для BRAM и DSP 450 МГц, мне так кажется это самые медленные элементы. Правда это почти ничего не меняет, без бубна и PlanAhead разогнать большой проект даже до 400 МГц сложно. Но нет ничего невозможного, удачи.

Вам кажется %)

Аргументируйте.

450MHz = 2.2нс, теперь берем времянку CLB
TIF5X 5-input function: F/G inputs to X output 0.49
TCKO FF Clock CLK to XQ/YQ outputs 0.31
TDICK BX/BY inputs 0.4

итого, если бы задержек на трассах не было, то выстроенная в колонну 5 ти входовая логика будет хлопать на (0,49+0,31+0,4) = 1.2нс/833МГц. Казалось бы УРА товарищи, НО
1. Задержки трасс, к сожалению в даташите нет, но сдается мне там наберется как минимум под одну нс.
2. Если логика не вписывается в один слой логики 1LUT/MUXF5/MUXF6/MUXF7, то слоев будет уже два, т.е. помимо задержек логики будет еще бОльшая задержка трасс.
3. проекты редко вытягиваются в одну линию, поэтому длины трасс будут неизбежно расти в большом проекте %)

Логика быстрая спору нет, но в реальном проекте при кол-ве слоев логики больше 2/3 выйти на 450 МГц не реально.

Смею согласится с вами, но вы так и не привели элементов более медленных. То, что нагородить логики в кучу слоев, сумматоров с километровыми цепями переноса и т.п. можно, я не сомневался. По моему опыту -11 кристалл тянул фильтры, занимающие 90% DSP слайсов на 450 МГц вполне. Вы правилно заметили, что автору темы нужно посоветовать уменьшать количество слоев логики в первую очередь.

фильтры на DSP слайсах он тянуть будет, т.к. они для этого и были сделаны (спец трассы, расположение, конвейеризация и т.д.). Но вот все остальное большой вопрос. Особенно у хилых туго с математикой НЕ на дсп слайсах.

А где с ней хорошо? А то может мне уже на альтеру бежать переучиваться?

не поверите именно там, сам удивляюсь %)

недавно квартус меня вообще поразил, разведя рекурсивный фильтр вида y(n) = x(n) + scale_to_18bit(y(n-1)*var), где y/x/var 18 ти битные данные на 120 МГц при 95% забитости кристалла %)

а уж как он меня поражает на синтезе комплексных и обычных фиров с выходом до 36-40 бит... %)

ЗЫ. все это на "дохлых" и "тормозных" третьих сыклонах i7

Хочу рассказать о моем изумлении при встрече с одним уникумом, который достигал ошеломительных цифр применяя Матлаб. Он там разрисовывал макроячейку своей микросхемы и вел на основании такого элемента и её маски(для переноса!) моделирование в Матлабе. Он получал и фильтры и ФФТ на 600МГц тактовой. Сам контролировал укладку в чипе всех элементов.

Как-то бездоказательно. В чем конктерно техническое преимущество?

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

Но если использовать тригерры на выходе каждого слоя логики + RPM может быть что-то и могло бы получится. Одна проблема Global Clock Tree для Virtex-4 -11 тоже 450 МГц

Говорю о своих умозаключениях, смысла что то доказывать вам не вижу абсолютно никакого, ваше право верить или нет. Практика критерий истины. Сделайте ради примера фильтр приподнятого косинуса со скруглением 0.1, фильтр симметричный 100 коэфиициентов, разрядность входа 16 бит, выхода 16 бит, коэффициентов 14 бит. реализация без ДСП слайсов, фильтр хлопает по clkena, символ за такт %) Чип лучше взять маленький, что бы забитость была ~80% (легко обеспечить коли-ом таких фильтров).


Есть два таких человека на форуме, но не будем показывать пальцем.

ИМХО гемор, лучше полифазную обработку сделать %)

UPD. фильр из корня приподнятного косинуса, иначе из 100 коэффициентов половина будет нулевых %)

Я верю, но хочу разобраться формально - какой именно фактор вызывает такие ощущения? Пока по цифрам в даташитах Xilinx выигрывает. Упс. Кажется мне в другую тему пора.

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

основной фактор в том, что мне удается запихать в маленький чип, нужную функциональность и обеспечить выполнение времянкок(100/200МГц). При этом занятыми оказываются дсп блоки на 90-100%, память на 50-60%, логка и регистры на 95-99%. Тогда как прикидки на хилые чипы, показывают необходимость вставки дополнительных регистров и т.д.
Толи квартус на голову выше исе/симплифай синтезирует/оптимизирует математику, толи с трассировочными ресурсами лучше, в общем не понятно.


создавайте тему, фильтр прототип и условия тестирования я выложу %)

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

Распараллелил и упростил все что можно. Количество ошибок сократилось с 800 до 60, сейчас timing score около 11000. Судя по анализу в местах где есть ошибки Levels of Logic колеблется 9-11. Ситуация не улучшилась - проект по прежнему работает не стабильно. При включении питания проект может или сразу нормально работать, или не работать совсем. Да к тому же исправление одних ошибок приводит к появлению других - замкнутый круг. Может надо руками проект на кристалл как-то раскладывать? Не умею я этого, увы.

Конечно. Проект будет работать стабильно, когда timing score будет равен нулю. Пока у вас будет хоть одна дорожка, не вписывающаяся во времянку - вы будете ловить глюки, хоть возможно и не при любых условиях (в основном температурных).
Ставьте дополнительные регистры туда, где 9-11 уровней.


Вы, вероятно, двигаете триггеры по проекту, а надо их добавлять. Когда есть места, где 9-11 уровней - можете двигать до посинения, не заработает. И включите retiming, кстати, если не включен - тогда вы сможете добавлять степени конвейеризации в длинные цепочки туда, где это логически удобнее, а синтезатор сам их будет ставить в середину цепи, перераспределяя логику.


Вообще-то, в столь сложных проектах с этого надо начинать. Ожидать, что ISE по собственной инициативе разложит весь проект на 400MHz - это супероптимистично. Учитесь, это несложно, недаром PlanAhead включили в стандартную поставку.

Мультицикловые констрейны и те, которые можно сунуть в игнор могут спасти отца русской демократии. Если конечно это не сделано, и если это вообще возможно для ваше проекта. 11000 вообщем то не так много, по крайне мере можно пытаться засунуть в этот чип. Еще можно попробывать smartexplorer, он будет до посинения перебирать варианты размещения. потом выберете тот что лучше и будете его мучить.

Это IMHO помогает, когда не влезает чуть-чуть. А когда 9-11 уровней логики - думаю, что пустая потеря времени.

Кстати у меня еще вопрос появился: а вы с 400MHz результаты обработки куда выводите?

Конечно не помогает. Это просто позволяет не заниматься ручной трасировкой кристалла. Которая при 9-11 уровнях логики тоже не поможет.

вы говорите что данные идут с АЦП на 200МГц, а в констрейне указали 2.5нс, что означает что входной клок 400МГц а не 200МГц.

и еще такой вопрос, а это жесткое требование чтобы сама логика на 400МГц работала? Или вы думаете что если принимаете на 200Мгц то нужно обрабатывать данные на 400Мгц?

Данные на чип идут в режиме SDR я так понял? или DDR?

Копаю дальше проект. Изменив алгоритм и упростив все что можно сократил ошибки до 3-ех. Timing Score уменьшился до 136. Уровни логики 9. Количество проблемных путей по анализатору равно 9. Замена чипа на 12-ый полностью устраняет ошибки. Все бы хорошо, да помимо куска проекта на 400МГц, есть еще огромный кусок на значительно более низких частотах. И его еще дорабатывать сильно надо, но при добавлении чего-либо в него, количество ошибок снова растет.

Добавлю - проекты на столь больших частотах мне не встречались. Зачастую не требовалось вообще констрейны использовать. Так что прошу извинить за серость, но многих советов я не понимаю.

Теперь по порядку:

Не знаю что такое retiming. Где он включается?

Осознаю, что добавление триггеров увеличивает скорость работы. Но как их добавить? В ручную через FPGAEditor?

"Мультицикловые констрейны и те, которые можно сунуть в игнор" - можно для чайника рассказать что это?

smartexplorer - как его запустить?

Результаты обработки идут далее в низкочастотную часть проекта
Данные идут в режиме DDR, поэтому обработка на 400МГц должна быть.

В проблемных местах, где задержка велика, триггеры включаются в HDL(после выявления источника и приемника). После чего в симуляторе убедитесь, что введенная вами задержка не изменила работу. Как правило что-то придется подвинуть еще... как следствие! Будьте внимательны с временными диаграммами...

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

мультициклы

Еще раз: сделайте в floorplan в PlanAhead, разбейте проект на партиции - вы сможете предотвратить перемещение тех кусков проекта, которые уже размещены правильно.


Register retiming, в настройках PAR.


Нет конечно.
У вас есть код типа:

То есть много логики в один такт.
Вы из него делаете

Добавили 2 ступени триггеров.


Например, вы знаете, что enable некой группы триггеров у вас по дизайну работает четко не чаще, чем раз в два такта. Вы можете пути между этими триггерами объявить в два цикла, и компилятор будет знать, что эти пути можно укладывать в 5 ns, несмотря на тактовую в 400MHz.

Интересно, а можно подробнее?

Если честно, прочитал только завязку дискусии и последнюю страницу, так что может чего и пропустил. Но нет сил просто.. )
Так вот.
Всё это, если честно, полный бред. И про 400МГц на V-4, и про 600(это вообще отжиг)) ). И даже фильтры на DSP не работают на таких частота, если их число больше, чем в одном столбце приходится на один фильтр. Для V-4 со скоростью -10 при 85% забитии кристалла максимум, что выжимал(хотя стараля, использовал только 2-х!! входовые мультиплексоры и т.д.) это 270 МГц. Дальше роутер начинает проводить совершенно нереальные соединения, и в итоге, ещё ухудшает времянку. Для -11, ну ещё 50 МГц - это потолок. Так что, поменьше иллюзий.

Тут на самом деле не так все просто. Про 600 МГц я думаю имели ввиду только теоретическую скорость работы небольшой или плотноуложенной схемы. Просто в V4 даже такт такой не завести.
Что касается 450 МГц и фильтра на DSP, так он у меня был еще и полностью комплЕксный высокго порядка, и одно умножение занимало 4 DSP48, и 4 столбца сразу было использовано. Но и архитектура этого фильтра была не простой, использующей все возможности архитектуры, другое дело что логики практически никакой больше не было использовано, поэтому и такие цифры. Многое зависит от плотности логики и качества разводочных ресурсов. Ув. des00 утверждает что у Alter'ы с этим получше чем у Xilinx, хотя мы это еще не проверили.

И что, работал фильтр, занимающий 2 столбца на 400 МГц?! Извините, но не верю. Если можно, киньте усечённый кусочек( чего не жалко) на ZalilovTimur87@gmail.com). Мне было бы очень полезно.

Это было пару лет назад. Знаю, что связывался с альтерой о применении параметров маски , после чего сделал эксперимент для всех вариантов масок, чтобы убедиться в выгодности и преимущества по быстродействию при переносе.
Его любимым режимом был тогда ВИЗИВИНГ(как рисую, так и разводится!). Он отслеживал расположение внутренней топологии ФПЖА, чтобы оптимально легли ответственные ножки. Речь о "столбиках"(близко расположенные макроячейки) внутри ПЛИС. Так достигалось предельное быстродействие!..

У меня на это руки не дошли,-занят был, а потом поменял работу и связь только по тлф. По праздникам....
-------- Это бомба! Колюсь...
Кстати, он утверждал, что в маске весь секрет! Что пользователю не дают возможности разогнать ячейку до предельного значения быстродействия!!!!!!
На самом деле это из недокументированного.... Так что его заявление о 1000МГц при встрече на осенней выставке меня не смутили.

как бы начали проверять в соседней теме, но народ как то не шибко этим интересуется.

Конечно работал, собственно чему там не работать? Все элементы на этой частоте работают по даташиту, все полностью законвейерезировано было, разводочные ресурсы в основном использованы специальные, которые между DSP48 проложены. Выкладывать не буду, лень. Там половина в схематике была сделана - зеленый еще был.



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

Продолжим. Ошибки побеждены. Минимальный запас по setup есть.
Посмотрел как 400МГц часть разложилась на кристалл - схема раскинулась аж на пол кристалла.
Есть желание сделать 2 вещи:
1) создать Pblock и указать чтобы вся 400МГц часть располагалась в этом блоке
2) создать partition с 400МГц частью, чтобы раз и навсегда отладить этот кусок и не зависеть от того как будет написана остальная часть проекта

Читаю мануал к PlanAhead. Прочитал Hierarchical_Design_Methodology_Guide и PlanAhead_Tutorial_Design_Preservation. Да, и видео посмотрел с оф. сайта.
Вроде все просто, но применить эти знания не могу. Не могу понять как выделить нужные компоненты проекта для создания partition - если коры идут отдельным списком, то компоненты написанные мной на VHDL автоматичеки разбиваются на примитивы. Нужно все примитивы компонента выискивать?

Разобрался. В настройках компилятора в ISE надо галку поставить keep hierarchy. Создал один единственный компонент внутрь которого запихнул все, что связано с 400МГц. Pblock создал. Плохо что нельзя его создавать произвольным по форме - у меня почти все DSP48 использованы, поэтому блок получился длиной почти на вест кристал. После имплемента получил запас по setup 32пС. Затем этот же модуль назначил как partition. Снова сдела имплемент - и получил запас по setup равным 0. Это почему так?
Ну да ладно. Нажал remote partitions. Вроде как должен был создаться компонент для вставки в свой проект, но я так и не понял где он и как его вставить в общий проект. Подскажите!

Приветствую!



Почему нельзя - все можно - просто задаете несколько прямоугольников для одного pblock (Add Pblock rectange) можно даже не перекрывающихся.
Так можно нарисовать какую угодно форму. Причем необязательно чтобы в контур для LUT попадали все DSP или BRAM - это независимые друг от друга контуры

Удачи! Rob.

Так и не понимаю как сформированный partition из PlanAhead вставить обратно в ISE проект

След вашего пребывания в PlanAhead остается в *.ucf. Все там. Тупо перенесите в редакторе...

В UCF файле появился только констрейм AREA_GROUP, который относится к Pblock. А как с partition то быть. Мне надо чтобы модуль на 400МГц стал черным ящиком с неизменным размещением примитивов на кристалле.
Кстати при попытке скомпилировать в ISE тот же проект с новым UCF (добавлен только AREA_GROUP) - ISE выдал что недостаточно ресурсов, в то время как Planahead нормально развел. Чудеса.

Продолжу монолог.
После задания Pblock и Partition на нужный модуль я сделал Export IP. В настройках экспорта указал Physical constraints, галку fixed placement only не ставил. Получил файлы edn и ucf на нужный модуль. Далее последовательно порпустил edn файл через программы EDIF2NGD NGD2SPL и SPL2SYM и получил SYM файл. Поскольку головной файл проекта у меня в схематике сделан. Далее скопировал все полученные файлы в рабочую папку проекта. Добавил в проект edn файл. Вставил SYM файл в схему. Все нормально откомпилировалось. Без ошибок. Глянул в FPGA editor как разложился проект на кристале и ....... проект опять раскидан по всему кристалу. Как будто и не создавал я Pblock и Partition.
В чем дело? Что я не правильно делаю? Как мне раз и на всегда зафиксировать на кристалле ответственный высокоскоростной модуль? Я осознаю, что для гуру - все эти вопросы на уровне ликбеза, но я бьюсь уже третий день. Не проходите мимо.

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

Достаточно рамки AREA_GROUP и правильных настроек инструментов, при которых проект хорошо складывается.

Эти экспортно-импортные дела не всегда работают. Например, у меня 13.1 не кушает ядро, которое сам же сделал, подавай ему от 11.5.





>Получил файлы edn и ucf на нужный модуль. Далее последовательно порпустил edn файл через программы EDIF2NGD NGD2SPL и SPL2SYM и получил SYM файл.

Полученный ucf файл как использовали?

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

ucf файл просто скопировал в папку проекта. Никак его не использую.

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

А макрос ваш - без ucf, он данных о размещении не содержит. Сделайте макрос, используя ucf.

Так в том то и дело, что и в ucf файле топология не прописана. Там собраны временные констрены, размер Pblock-а и его состав. Все. Добавив содержимое ucf файла в головной ucf - макрос-то раскладывается естественно в границах Pblock-a, но те так как это было сделано в PlanAhead.