Volkov 0 November 8, 2011 Posted November 8, 2011 · Report post С переходом на Xilinx автоматом перешел на VHDL. До этого - схематик Quartus-a. По моему, до того момента как выкинули WaweForm editor, это был самый оптимальный путь. По сути - сразу на RTL уровне создаешь проект. И структурное описание лучше воспринимается, чем текстовое. Но против тенденции не попрешь. Quote Share this post Link to post Share on other sites More sharing options...
warrior-2001 0 November 9, 2011 Posted November 9, 2011 · Report post Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик? Легко, и это уже не раз обсуждалось на форуме. Просто большинство САПР "левый схематик" переводит в стуртурное описание на указанном пользователем языке, и уж потом скармливает это дело моделсиму. И Quartus делает это не хуже САПР от Mentor или Cadenсe. И к вопросу о тенденциях - разработчики ПЛИС свой САПР всё больше начинают затачивать на работу с netlist. Лично мне от Altera и Xilinx нужен лишь place&route. Остальное делает Precision. И графические решения для верхнего уровня СФ-блоков и конфигураций ПЛИС в целом от того же Mentor меня вполне устраивают. И легко можно писать комментарии прямо в графике, и generate доступно для части схемы. Это всё есть. И когда люди начинают говорить об убогости схемотехнического ввода, они в основном имеют в виду тех же Altera и Xilinx. Но не стоит говорить за весь САПР. Quote Share this post Link to post Share on other sites More sharing options...
Мур 2 November 10, 2011 Posted November 10, 2011 · Report post Что значит, хоть так, хоть так? Вы можете скормить, скажем, моделсиму или альдеку какой-то левый схематик? Зачем левый? Свой родной, ISE-яшный! Модел снямает аж бегом!... А мне на этапе отработки логики важен прежде всего Модел. При завершении уже спокойно перевожу в HDL... А дальше хоть в Кактус, хоть в Либеро... Quote Share this post Link to post Share on other sites More sharing options...
dxp 115 November 10, 2011 Posted November 10, 2011 · Report post Зачем левый? Свой родной, ISE-яшный! Вы пользуетесь ISE'ным схематиком? Модел снямает аж бегом!... Похоже, я отстал от жизни - до сих пор полагал, что моделсим на входе понимает только текст. Quote Share this post Link to post Share on other sites More sharing options...
bogaev_roman 0 November 10, 2011 Posted November 10, 2011 · Report post А мне на этапе отработки логики важен прежде всего Модел. При завершении уже спокойно перевожу в HDL... А как у Вас дела с верификацией обстоят - на чем тесты пишете с проверкой работоспособности? Quote Share this post Link to post Share on other sites More sharing options...
Мур 2 November 10, 2011 Posted November 10, 2011 · Report post Вы пользуетесь ISE'ным схематиком? Изредка... В ТОПЕ или когда сложная комутация блоков(VHDL) Похоже, я отстал от жизни - до сих пор полагал, что моделсим на входе понимает только текст. А там на самом деле текст на входе .VHF Нет проблем! Только надо не забывать именование цепей и блоков, чтобы легче ориентироваться в иерархии проекта под Моделом А как у Вас дела с верификацией обстоят - на чем тесты пишете с проверкой работоспособности? Стандартные тестбенчи на VHDL.. Соседи практикуют .do файлы, как под Active-HDL Quote Share this post Link to post Share on other sites More sharing options...
bogaev_roman 0 November 10, 2011 Posted November 10, 2011 · Report post Стандартные тестбенчи на VHDL.. Соседи практикуют .do файлы, как под Active-HDL Ну то есть все равно фактически переводите топовый модуль из схемоты в RTL именно для верификации? Это я к тому, что, например, хочется сделать некое тестовое покрытие или посмотреть состояние конечного автомата или записать некие события в отчетный файл. Quote Share this post Link to post Share on other sites More sharing options...
Мур 2 November 10, 2011 Posted November 10, 2011 · Report post Ну то есть все равно фактически переводите топовый модуль из схемоты в RTL именно для верификации? Даже не заморачиваюсь! Можно и не компилироать вообще(RTL-ом и не пахнет!) отлаживать сначала логику(без реальных задержек) и схематик на вход Модела. Единственно, что раздражает, - приходится при модификации отключать модуль от проекта, а затем снова включать и по новой сгенерировать новый графический элемент. (Если этого не сделать, проект будет работать как до модификации. )Соответственно апдейт схемы(будет приглашение!) и вперед на Simulate Behavioral Model со старым тестбенчем на входе. Тут ISE может тупить(это глюк ISE!) в Топе. Тогда (если не приглашает на обновление) приходится выходить из проекта и заходить по новой. Тогда точно бедет апдейт схемы Ну то есть все равно фактически переводите топовый модуль из схемоты в RTL именно для верификации? Это я к тому, что, например, хочется сделать некое тестовое покрытие или посмотреть состояние конечного автомата или записать некие события в отчетный файл. Я работаю в Моделе на "посмотреть". Оттуда можно снять и задокументировать события в файл, если нужно... Покрытие обеспечиваю набором различных тестбенчей под все случаи жизни... Подключаю по очереди.... Этап, пожалуй, самый важный! Именно на вариациях видна ошибка в работе очередной версии. Заставляешь себя бесонечно ходить по кругу тестов при очередном изменении... Исключений быть не должно! Quote Share this post Link to post Share on other sites More sharing options...
bogaev_roman 0 November 10, 2011 Posted November 10, 2011 · Report post Даже не заморачиваюсь! Можно и не компилироать вообще(RTL-ом и не пахнет!) Я опечатался и имел ввиду HDL :) но идею понял. Я работаю в Моделе на "посмотреть". В этом и суть вопроса, похоже Вы немного подменяете понятия верификации и моделирование. Вопрос - есть в устройстве конечный автомат, у него 20 состояний, находится он по иерархии уровне на 10, хочу проверить, что все состояния за время теста были пройдены. Я же не буду вручную просматривать все состояния и на бумажку заносить? Хочу просто в конце теста увидеть строчку state_mach - PASSED. Покрытие обеспечиваю набором различных тестбенчей под все случаи жизни... Для некоторых проектов, видимо, не хватит жизни... Quote Share this post Link to post Share on other sites More sharing options...
Мур 2 November 11, 2011 Posted November 11, 2011 · Report post В этом и суть вопроса, похоже Вы немного подменяете понятия верификации и моделирование. Вопрос - есть в устройстве конечный автомат, у него 20 состояний, находится он по иерархии уровне на 10, хочу проверить, что все состояния за время теста были пройдены. Я же не буду вручную просматривать все состояния и на бумажку заносить? Хочу просто в конце теста увидеть строчку state_mach - PASSED. Это понятно, но "жизнь диктует свои суровые законы" (с)Бендер и работодатель берет на работу человека, чтобы за мимнимум времени и з\п получить приемлемый продукт. Это лотерея при таком подходе , но на выручку приходит предыдущий опыт, а железо ставит уже все точки над и... В острые моменты проблем на железе приходится брать на пуп. После локализации проблем джитагом снимается слепок сигналов, который загоняется в новый бенч. Тогда появляется шанс прояснит в моделировании конкретный случай. Редкий заказчик понимает нюансы технологии проектирования на ПЛИС... Quote Share this post Link to post Share on other sites More sharing options...
bogaev_roman 0 November 11, 2011 Posted November 11, 2011 · Report post Это понятно, но "жизнь диктует свои суровые законы" (с)Бендер и работодатель берет на работу человека, чтобы за мимнимум времени и з\п получить приемлемый продукт. Это лотерея при таком подходе , но на выручку приходит предыдущий опыт, а железо ставит уже все точки над и... Этот подход годится при разработке тостера для домохозяек, а если делается какой-нить коммутатор для суперкомпутера на АЭС, где цена изменения 1 на 0 может быть критичной и с таким же подходом написано ПО, то на выходе будет не очень все хорошо...Вот и "Фобос-Грунт" чой-то не отвечает с орбиты - недомоделировали, наверное, железо или может программисту бонус не додали... В острые моменты проблем на железе приходится брать на пуп. После локализации проблем джитагом снимается слепок сигналов, который загоняется в новый бенч. Тогда появляется шанс прояснит в моделировании конкретный случай. Да, это известный подход и он хорошо годится для потоковых схем - цифровые приемопередатчик скажем. Но есть схемы с многоуровневым арбитражом по приоритетам и схемами коммутации, где он не годится, так как потребуется снять все внутренние состояния и загнать их перех перед началом проверки конкретного случая. Да и jtag не всесилен - для вытягивания новых сигналов в signal tap, скажем, требуется получить новую прошивку, которая может довольно долго делаться, при этом потребуется еще каким-то образом получить сам факт наличия ошибки, чтоб снять сигналы до события, что иногда тоже проблематично, ибо к ошибке может привести событие произошедшее гораздо раньше. Плюс могут появляться "неповторимые" сбои. При этом, если верификация проведена на уровне функционального моделирования грамотно и все временные ограничения выполнены, то с 99,9% влазить jtag'ом вообще не потребуется. Quote Share this post Link to post Share on other sites More sharing options...
