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

[Volkov 0]

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

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

[warrior-2001 0]

Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик?

 

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

 

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

[Мур 1]

Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик?

 

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

 

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

 

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

[dxp 34]

Зачем левый? Свой родной, ISE-яшный!

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

 

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

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

[bogaev_roman 0]

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

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

[Мур 1]

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

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

 

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

 

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

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

 

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

 

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

[bogaev_roman 0]

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

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

[Мур 1]

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

 

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

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

 

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

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

 

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

[bogaev_roman 0]

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

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

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

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

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

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

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

 

[Мур 1]

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

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

 

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

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

 

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

[bogaev_roman 0]

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

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

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

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

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

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

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