Jump to content

    
Какой способ разработки систем на ПЛИС сейчас наиболее популярен?  

208 members have voted

  1. 1. Какой способ разработки Вы используете?

    • Схемотехнический ввод
      11
    • Verilog
      102
    • VHDL
      82
    • AHDL
      5
    • другой
      8


Какой способ разработки систем на ПЛИС сейчас наиболее популярен?

С переходом на Xilinx автоматом перешел на VHDL. До этого - схематик Quartus-a. По моему, до того момента как выкинули WaweForm editor, это был самый оптимальный путь. По сути - сразу на RTL уровне создаешь проект.

И структурное описание лучше воспринимается, чем текстовое. Но против тенденции не попрешь.

Share this post


Link to post
Share on other sites
Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик?

 

Легко, и это уже не раз обсуждалось на форуме. Просто большинство САПР "левый схематик" переводит в стуртурное описание на указанном пользователем языке, и уж потом скармливает это дело моделсиму. И Quartus делает это не хуже САПР от Mentor или Cadenсe.

 

И к вопросу о тенденциях - разработчики ПЛИС свой САПР всё больше начинают затачивать на работу с netlist. Лично мне от Altera и Xilinx нужен лишь place&route. Остальное делает Precision. И графические решения для верхнего уровня СФ-блоков и конфигураций ПЛИС в целом от того же Mentor меня вполне устраивают. И легко можно писать комментарии прямо в графике, и generate доступно для части схемы. Это всё есть. И когда люди начинают говорить об убогости схемотехнического ввода, они в основном имеют в виду тех же Altera и Xilinx. Но не стоит говорить за весь САПР.

Share this post


Link to post
Share on other sites
Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик?

 

Зачем левый? Свой родной, ISE-яшный! Модел снямает аж бегом!...

 

А мне на этапе отработки логики важен прежде всего Модел. При завершении уже спокойно перевожу в HDL...

 

А дальше хоть в Кактус, хоть в Либеро...

Share this post


Link to post
Share on other sites
Зачем левый? Свой родной, ISE-яшный!

Вы пользуетесь ISE'ным схематиком?

 

Модел снямает аж бегом!...

Похоже, я отстал от жизни - до сих пор полагал, что моделсим на входе понимает только текст.

Share this post


Link to post
Share on other sites
А мне на этапе отработки логики важен прежде всего Модел. При завершении уже спокойно перевожу в HDL...

А как у Вас дела с верификацией обстоят - на чем тесты пишете с проверкой работоспособности?

Share this post


Link to post
Share on other sites
Вы пользуетесь ISE'ным схематиком?

Изредка... В ТОПЕ или когда сложная комутация блоков(VHDL)

 

Похоже, я отстал от жизни - до сих пор полагал, что моделсим на входе понимает только текст.

 

А там на самом деле текст на входе .VHF

Нет проблем! Только надо не забывать именование цепей и блоков, чтобы легче ориентироваться в иерархии проекта под Моделом

 

А как у Вас дела с верификацией обстоят - на чем тесты пишете с проверкой работоспособности?

 

Стандартные тестбенчи на VHDL.. Соседи практикуют .do файлы, как под Active-HDL

Share this post


Link to post
Share on other sites
Стандартные тестбенчи на VHDL.. Соседи практикуют .do файлы, как под Active-HDL

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

Share this post


Link to post
Share on other sites
Ну то есть все равно фактически переводите топовый модуль из схемоты в RTL именно для верификации?

 

Даже не заморачиваюсь! Можно и не компилироать вообще(RTL-ом и не пахнет!) отлаживать сначала логику(без реальных задержек) и схематик на вход Модела. Единственно, что раздражает, - приходится при модификации отключать модуль от проекта, а затем снова включать и по новой сгенерировать новый графический элемент. (Если этого не сделать, проект будет работать как до модификации. )Соответственно апдейт схемы(будет приглашение!) и вперед на Simulate Behavioral Model со старым тестбенчем на входе.

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

 

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

Я работаю в Моделе на "посмотреть". Оттуда можно снять и задокументировать события в файл, если нужно...

 

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

Share this post


Link to post
Share on other sites
Даже не заморачиваюсь! Можно и не компилироать вообще(RTL-ом и не пахнет!)

Я опечатался и имел ввиду HDL :) но идею понял.

Я работаю в Моделе на "посмотреть".

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

Вопрос - есть в устройстве конечный автомат, у него 20 состояний, находится он по иерархии уровне на 10, хочу проверить, что все состояния за время теста были пройдены. Я же не буду вручную просматривать все состояния и на бумажку заносить? Хочу просто в конце теста увидеть строчку state_mach - PASSED.

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

Для некоторых проектов, видимо, не хватит жизни...

 

Share this post


Link to post
Share on other sites
В этом и суть вопроса, похоже Вы немного подменяете понятия верификации и моделирование.

Вопрос - есть в устройстве конечный автомат, у него 20 состояний, находится он по иерархии уровне на 10, хочу проверить, что все состояния за время теста были пройдены. Я же не буду вручную просматривать все состояния и на бумажку заносить? Хочу просто в конце теста увидеть строчку state_mach - PASSED.

 

Это понятно, но "жизнь диктует свои суровые законы" (с)Бендер и работодатель берет на работу человека, чтобы за мимнимум времени и з\п получить приемлемый продукт. Это лотерея при таком подходе , но на выручку приходит предыдущий опыт, а железо ставит уже все точки над и...

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

 

Редкий заказчик понимает нюансы технологии проектирования на ПЛИС...

Share this post


Link to post
Share on other sites
Это понятно, но "жизнь диктует свои суровые законы" (с)Бендер и работодатель берет на работу человека, чтобы за мимнимум времени и з\п получить приемлемый продукт. Это лотерея при таком подходе , но на выручку приходит предыдущий опыт, а железо ставит уже все точки над и...

Этот подход годится при разработке тостера для домохозяек, а если делается какой-нить коммутатор для суперкомпутера на АЭС, где цена изменения 1 на 0 может быть критичной и с таким же подходом написано ПО, то на выходе будет не очень все хорошо...Вот и "Фобос-Грунт" чой-то не отвечает с орбиты - недомоделировали, наверное, железо или может программисту бонус не додали...

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

Да, это известный подход и он хорошо годится для потоковых схем - цифровые приемопередатчик скажем.

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

Да и jtag не всесилен - для вытягивания новых сигналов в signal tap, скажем, требуется получить новую прошивку, которая может довольно долго делаться, при этом потребуется еще каким-то образом получить сам факт наличия ошибки, чтоб снять сигналы до события, что иногда тоже проблематично, ибо к ошибке может привести событие произошедшее гораздо раньше. Плюс могут появляться "неповторимые" сбои.

При этом, если верификация проведена на уровне функционального моделирования грамотно и все временные ограничения выполнены, то с 99,9% влазить jtag'ом вообще не потребуется.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this