3.14 0 14 декабря, 2004 Опубликовано 14 декабря, 2004 · Жалоба Вернулся из коммандировки, настоение не рабочее, решил исповедаться ;) Начну. Когда я устраивался на сегодняшнюю работу то не имел никакого опыта работы с ПЛИС. Тогда наша фирма работала с Xilinx CPLD в основном это были 95xc216. Первое впечатление было - "Просто фантастика!!! Рисуеш схему и она раз и в кристалле". Но очень бысто эти инфантильные настроения как ветром сдуло. На первых же проектах проявилась следующая особенность, все содержимое ПЛИС крайне кореллировано, стоило добавить инвертор и совсем не имеющий к нему отношения счетчик переставал работать. Такое поведение проекта мягко говоря вводило в шок, первым же делом задумалься как от этого избавиться. Первое интуитивное решение было - использование более высокоуровневых языков описания аппаратуры. Начал с VHDL. Описал пару проектов. Результат не изменился. Обратил внимание на временные ограгничения. Но для Xilinx CPLD они очень ограничены. Примерно в это время нашей фирме разрешили использовать Spartan2-200. Радости моей не было пердела :) Казалось, вот оно счастье, решение всех моих проблем. Но не тут то было, на первом же проекте проявилась "непредсказуемость" содержимого. В то время я пользовался только кострейнами "PERIOD" и "OFFSET", а ими можно ограничивать практически только конвейеры, моя логика была хоть и не большой но крайне не вписывающейся в конвейер. Следующим решением был ответ на вопрос: "Как модули в проекте превратить в подобие отдельных микросхем". Ответ нашелся быстро - ModularDesign. Поясню в кратце суть: 1) Проект бьется на модули. Над каждым модулем может работать отдельный человек. 2) Кристалл как в игре "земельки" делится на части и раздается модулям. 3) Модули по отдельности размещаются в своих физических границах. 4) Собирается все целиком. Т.е. в идеале изменения в модуле А никак не скажутся на модуле В. Но везде есть нюансы гадящие всю идею, в ModularDesign это так называемые псевдопины. На стадии экспериментов с ModularDesign у меня получалось добиться того, что даже не только изменения в модуле В не влияли на модуль А, но и при перетаскивании физических границ модуля А, взаимное расположение элементов не изменялось. В работе этого эффекта я добиться не смог, т.к. необходимо закреплять псевдопины которые делятся на псевдонагрузку и псевдодрайвер, иначе содержимое получается такое же кореллированное. В моем случае загвоздкой оказался один блок со 120 линий подходящим к нему, помимо того что по времени этот процесс крайне весом, я не стал их закреплять из-за частых изменений в этих линиях. Да, еще сама методология крайне не интерактивна (сначала нужно получить EDIF без подключения пинов, далее описать скрипты инициализации проекта, размещения модулей, сборки проекта) и по времени процесс затягивается примерно в пару раз. В итоге мне пришлось в который раз более вдумчиво обратиться к констрейнам и попытаться ограничить свою писанину. Все вышесказанное имело цель вывести читающего на откровенный разговор посредством которого повысить КПД обмена опытом. Буду рад если в чем то ошибаюсь и Вы меня наставите на путь истинный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 19 января, 2005 Опубликовано 19 января, 2005 · Жалоба в серьезных системах разработки (читай для ASIC-ов) "модулар дезайн" это единственный естественный подход - то есть это итеративный процесс, в котором "главный" выделяет констрейны (время и площадь) для разработчиков отдельных модулей - и модули синтезируются независимо (понянуть синтез всего проекта - производительности не хватает у компутеров) там еще очень хитрая процедура (для автоматизации) начальной оценки этих констрейнов как я понимаю - ISE-овский MD отсюда и пошел Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy-P 0 19 января, 2005 Опубликовано 19 января, 2005 · Жалоба В Quartus подобная методология «разделяй и властвуй» именуется LogicLock. В реальном проекте эта технология показала себя весьма достойно. FIR фильтр, выделенный в модуль и переданный в верхний уровень через эту технологию, имел весьма устойчивый внутренний тайминг с изменениями примерно +/- 100ps при изменениях в верхнем уровне проекта. При этом запас по периоду для модуля составлял более 3ns. Изменения тайминга возможно вследствие того, что для модуля не был зафиксирован роутинг и положение local_lcell внутри LAB (10 llcell на LAB). Что касается псевдопинов (собственно камень преткновения в вашем случае), то такого аналога у Quartus не припоминаю. Есть виртуальные пины - применяются, когда модуль имеет I/O больше числа допустимых ног в выбранном девайсе. Их можно также использовать для определения места будущего входа/выхода в модуль, но большого смысла в этом не вижу, поскольку после фиксации относительного или абсолютного местоположения входной/выходной local_lcell, при трассировки всего проекта уже есть ограничения в возможных трассах для этой local_lcell. Кстати процедура определения, фиксации и передачи модуля не занимает много времени. (Основное время уходит на достижение заданной производительности) Модульная технология в принципе хороша и правильна, а вот насколько хороша в реалиях, возможно, зависит от софта и от оправданности ее использования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 19 января, 2005 Опубликовано 19 января, 2005 · Жалоба <"модулар дезайн" это единственный естественный подход - то есть это итеративный процесс, в котором "главный" выделяет констрейны (время и площадь) для разработчиков отдельных модулей - и модули синтезируются независимо (понянуть синтез всего проекта - производительности не хватает у компутеров)> Вот только у Xilinx похоже этот "естественный подход" перешел в "безобразное естество" ;). Люди, возлагающие надежды на MD, не призываю "забить", наоборот, пробуйте, делитесь впечатлениями. Просто я уже наигрался, результат не понравился. В моем случае получилось так: 1) Времянки безобразно "ездили" при изменении в блоках :( 2) Времени на "сборку" уходило раза в 2 - 3 больше :( Наблюдалась такая вещь: измениш модуль, переPARиш, собереш все в кучу получиш одну "прошивку", переPARиш все модули и собереш, получиш другую прошивку :( Склонен думать что это следствие не закрепленных псевдопинов. На тестовых проектах прыгал от радости, когда при перетаскиваниях или изменениях в модулях остальные оставались как есть, вот только в моем специфичном случае как то это не прижилось. Сейчас появляется задача, когда прийдется натурально один кристалл на двоих разработчиков делить. Только я думаю проще будет удерживать иерерхию и железно лочить содержимое частей разработчиков. < через эту технологию, имел весьма устойчивый внутренний тайминг с изменениями примерно +/- 100ps при изменениях в верхнем уровне проекта. При этом запас по периоду для модуля составлял более 3ns.> 100ps - Супер!!! В моем случае ездило не меньшн чем на +/-1нс :( Причем, разводиш модуль вписывается в ограничение (8.3нс) с запасом в 0.5нс (радуюсь, потираю руки;)). Собираеш все целиком, разъезжается на +1.5нс (тут я обычно вскакивал, плевался и матерился, в общем наносил вред нервной системе). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LeonY 0 19 января, 2005 Опубликовано 19 января, 2005 · Жалоба <"модулар дезайн" это единственный естественный подход - то есть это итеративный процесс, в котором "главный" выделяет констрейны (время и площадь) для разработчиков отдельных модулей - и модули синтезируются независимо (понянуть синтез всего проекта - производительности не хватает у компутеров)> Вот только у 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, так тоска и берет, практически эта опция никогда толком не работала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться