[3.14 0]

Вернулся из коммандировки, настоение не рабочее, решил исповедаться ;)

 

Начну. Когда я устраивался на сегодняшнюю работу то не имел никакого опыта работы с ПЛИС. Тогда наша фирма работала с Xilinx CPLD в основном это были 95xc216. Первое впечатление было - "Просто фантастика!!! Рисуеш схему и она раз и в кристалле". Но очень бысто эти инфантильные настроения как ветром сдуло. На первых же проектах проявилась следующая особенность, все содержимое ПЛИС крайне кореллировано, стоило добавить инвертор и совсем не имеющий к нему отношения счетчик переставал работать. Такое поведение проекта мягко говоря вводило в шок, первым же делом задумалься как от этого избавиться. Первое интуитивное решение было - использование более высокоуровневых языков описания аппаратуры. Начал с VHDL. Описал пару проектов. Результат не изменился. Обратил внимание на временные ограгничения. Но для Xilinx CPLD они очень ограничены. Примерно в это время нашей фирме разрешили использовать Spartan2-200. Радости моей не было пердела :) Казалось, вот оно счастье, решение всех моих проблем. Но не тут то было, на первом же проекте проявилась "непредсказуемость" содержимого. В то время я пользовался только кострейнами "PERIOD" и "OFFSET", а ими можно ограничивать практически только конвейеры, моя логика была хоть и не большой но крайне не вписывающейся в конвейер. Следующим решением был ответ на вопрос: "Как модули в проекте превратить в подобие отдельных микросхем".

Ответ нашелся быстро - ModularDesign. Поясню в кратце суть:

1) Проект бьется на модули. Над каждым модулем может работать отдельный человек.

2) Кристалл как в игре "земельки" делится на части и раздается модулям.

3) Модули по отдельности размещаются в своих физических границах.

4) Собирается все целиком.

Т.е. в идеале изменения в модуле А никак не скажутся на модуле В. Но везде есть нюансы гадящие всю идею, в ModularDesign это так называемые псевдопины. На стадии экспериментов с ModularDesign у меня получалось добиться того, что даже не только изменения в модуле В не влияли на модуль А, но и при перетаскивании физических границ модуля А, взаимное расположение элементов не изменялось. В работе этого эффекта я добиться не смог, т.к. необходимо закреплять псевдопины которые делятся на псевдонагрузку и псевдодрайвер, иначе содержимое получается такое же кореллированное. В моем случае загвоздкой оказался один блок со 120 линий подходящим к нему, помимо того что по времени этот процесс крайне весом, я не стал их закреплять из-за частых изменений в этих линиях. Да, еще сама методология крайне не интерактивна (сначала нужно получить EDIF без подключения пинов, далее описать скрипты инициализации проекта, размещения модулей, сборки проекта) и по времени процесс затягивается примерно в пару раз.

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

 

Все вышесказанное имело цель вывести читающего на откровенный разговор посредством которого повысить КПД обмена опытом. Буду рад если в чем то ошибаюсь и Вы меня наставите на путь истинный.

[yes 5]

в серьезных системах разработки (читай для ASIC-ов)

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

 

там еще очень хитрая процедура (для автоматизации) начальной оценки этих констрейнов

 

как я понимаю - ISE-овский MD отсюда и пошел

[Andy-P 0]

В Quartus подобная методология «разделяй и властвуй» именуется LogicLock. В реальном проекте эта технология показала себя весьма достойно. FIR фильтр, выделенный в модуль и переданный в верхний уровень через эту технологию, имел весьма устойчивый внутренний тайминг с изменениями примерно +/- 100ps при изменениях в верхнем уровне проекта. При этом запас по периоду для модуля составлял более 3ns. Изменения тайминга возможно вследствие того, что для модуля не был зафиксирован роутинг и положение local_lcell внутри LAB (10 llcell на LAB).

Что касается псевдопинов (собственно камень преткновения в вашем случае), то такого аналога у Quartus не припоминаю. Есть виртуальные пины - применяются, когда модуль имеет I/O больше числа допустимых ног в выбранном девайсе. Их можно также использовать для определения места будущего входа/выхода в модуль, но большого смысла в этом не вижу, поскольку после фиксации относительного или абсолютного местоположения входной/выходной local_lcell, при трассировки всего проекта уже есть ограничения в возможных трассах для этой local_lcell.

Кстати процедура определения, фиксации и передачи модуля не занимает много времени. (Основное время уходит на достижение заданной производительности)

Модульная технология в принципе хороша и правильна, а вот насколько хороша в реалиях, возможно, зависит от софта и от оправданности ее использования.

[3.14 0]

<"модулар дезайн" это единственный естественный подход - то есть это итеративный процесс, в котором "главный" выделяет констрейны (время и площадь) для разработчиков отдельных модулей - и модули синтезируются независимо (понянуть синтез всего проекта - производительности не хватает у компутеров)>

Вот только у Xilinx похоже этот "естественный подход" перешел в "безобразное естество" ;).

 

Люди, возлагающие надежды на MD, не призываю "забить", наоборот, пробуйте, делитесь впечатлениями. Просто я уже наигрался, результат не понравился.

В моем случае получилось так:

1) Времянки безобразно "ездили" при изменении в блоках :(

2) Времени на "сборку" уходило раза в 2 - 3 больше :(

Наблюдалась такая вещь: измениш модуль, переPARиш, собереш все в кучу получиш одну "прошивку", переPARиш все модули и собереш, получиш другую прошивку :(

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

На тестовых проектах прыгал от радости, когда при перетаскиваниях или изменениях в модулях остальные оставались как есть, вот только в моем специфичном случае как то это не прижилось.

 

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

 

< через эту технологию, имел весьма устойчивый внутренний тайминг с изменениями примерно +/- 100ps при изменениях в верхнем уровне проекта. При этом запас по периоду для модуля составлял более 3ns.>

100ps - Супер!!!

В моем случае ездило не меньшн чем на +/-1нс :(

Причем, разводиш модуль вписывается в ограничение (8.3нс) с запасом в 0.5нс (радуюсь, потираю руки;)). Собираеш все целиком, разъезжается на +1.5нс (тут я обычно вскакивал, плевался и матерился, в общем наносил вред нервной системе).

[LeonY 0]

<"модулар дезайн" это единственный естественный подход - то есть это итеративный процесс, в котором "главный" выделяет констрейны (время и площадь) для разработчиков отдельных модулей - и модули синтезируются независимо (понянуть синтез всего проекта - производительности не хватает у компутеров)>

Вот только у Xilinx похоже этот "естественный подход" перешел в "безобразное естество" ;).

 

Люди, возлагающие надежды на MD, не призываю "забить", наоборот, пробуйте, делитесь впечатлениями. Просто я уже наигрался, результат не понравился.

В моем случае получилось так:

1) Времянки безобразно "ездили" при изменении в блоках :(

2) Времени на "сборку" уходило раза в 2 - 3 больше :(

Наблюдалась такая вещь: измениш модуль, переPARиш, собереш все в кучу получиш одну "прошивку", переPARиш все модули и собереш, получиш другую прошивку :(

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

На тестовых проектах прыгал от радости, когда при перетаскиваниях или изменениях в модулях остальные оставались как есть, вот только в моем специфичном случае как то это не прижилось.

 

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

 

< через эту технологию, имел весьма устойчивый внутренний тайминг с изменениями примерно +/- 100ps при изменениях в верхнем уровне проекта. При этом запас по периоду для модуля составлял более 3ns.>

100ps - Супер!!!

В моем случае ездило не меньшн чем на +/-1нс :(

Причем, разводиш модуль вписывается в ограничение (8.3нс) с запасом в 0.5нс (радуюсь, потираю руки;)). Собираеш все целиком, разъезжается на +1.5нс (тут я обычно вскакивал, плевался и матерился, в общем наносил вред нервной системе).

<{POST_SNAPBACK}>

Ну не знаю - давно используем MD для Altera, в том числе и при разработке группой инженеров, где каждый отвечает за свой кусок, и при "монопольной работе" - особых проблем не возникало даже при высоких тактовых частотах (более 400МГц). Вот сейчас вынуждены будем опробовать подобную технологию для Actel - в проекте заняты не только несколько разработчиков, а несколько контор. Как результаты получу - поделюсь инфой. Хотя у меня настроение довольно пессимистичное - как вспомню incremental place & route у Actel, так тоска и берет, практически эта опция никогда толком не работала.