Перейти к содержанию

    

topor_topor

Свой
  • Публикаций

    439
  • Зарегистрирован

  • Посещение

Весь контент topor_topor


  1. Из практики могу сказать, что в "дизайн фло" нету ничего "обязательного" Тут не аероспейс где без освещения файнал тест протонов не проходит :) Можна и нужно понимать зачем что делается и когда можно что исключить и с каким риском.
  2. HDL - это язык описания аппаратуры. Другими словами - схемы электрической принципиальной. Код в примере это просто программа а не схема. Схему нарисовать перед описанием на языке можете?
  3. "Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?" Для разработки софта до появления железа применяю такие варианты: - Если проект ASIC/FPGA и процессор есть в виде RTL, то создаются напрямую прошивки памяти и симулятся в цифровом симуляторе (аналоговая периферия моделируется в верилоге напр.) - До появления силикона (ASIC) делается FPGA и софт заливается через дебагер (железо процессора конечно должно иметь этот дебагер) - Использую программный эмулятор процессора + модели периферии написанные специально под платформу. Это часть аппаратного дебагера, которая вместо заливки программы в железо симулирует процессор. Такой вариант требует относительно длительного периода создания моделей периферии. Часто используется без моделей периферии. - Абстрагирование от железа достигается например применением RTOS. Т..е доступ к периферии делается через вызов стандартных функций ОС. Или как минимум периферийные адреса прячутся за DEFINE. Плюс пишется более-менее стандартный набор функций (напр. TimeEnable(), TimeSet(), TimeGet() итд.) - Касаемо тестирования софта, на уровне отдельных функций пишутся тести на том-же языке и считается код кавередж. Плюс встраиваются асершены (не компилируются в финальную прошивку) для проверки того что входные данные в рендже, что произошли нужные события итп. Создание и Тестирование софта для больших машин под Win\Unix это отдельная тема...
  4. А кто ни будь (может НИИ какие, или частные фирмы) делает дизайны для зарубежных заказчиков? В европах достаточный спрос как на аутсорсинг: верификацию, цифровой, аналоговый дизайн, так и на дизайн и изготовление готовых чипов (миксид сигнал чаще).
  5. Для ошибок CDC рекомендую статический анализ в Conformal или SpyGlass CDC. timing simulation не всё увидиш. Особенно когда приходится иметь дело с сопровождением большого проекта, или стороннего проекта и особенно когда в CDC накручено и нет внятного описания что и зачем накручено (для ревью). Эти тулзи красиво показывают часть схемы с проблемами. timing simulation на нетлисте с SDF позволяет "верифицировать" констрейны из SDC (и-то частично), посмотреть времянки с задержками (например тайминги на памяти, внешнем интерфейсе). Подтвердить сетап\холды можно частично потому, что SDF обычно делают на ворст-типикал-бест корнеры, а силикон может не работать в каком-то промежуточном корнере (это из практики). Нетлист используется для "точного" расчёта рассеиваемой мощности. Примерный можна и при синтезе получить. ---- Если CDC просто и прозрачно сделано, когда нет трюков с SDC, и точно мощность считать не надо - то можно и не симулить нетлисты. Особенно в следующей версии дизайна.
  6. Вспомнил анекдот: "...теоритически мы миллионеры, а практически живем с двумя...". Так вот, оди и тот же "объект" назови разными терминами и сразу и смысл и подходы меняются :) HDL - язык описания аппаратуры, описания схемы - применимо для дизайна А для Тест Бенча - можна и "программой" тестирования назвать или программированием на верилоге. "Программирование" тут сленгом скорее будет если отталкиваться от изначального термина HDL, но по смыслу очень подходит (особенно если речь о классах UVM). --- Короче: Описание схемы и программирование тестов.
  7. Как-то до дебага нетлиста ни разу не доходили.... Если есть причини симулить нетлист (какие?) то тест бенчи пишутся с минимальным подключением к внутренним сигналам и с ограниченными проверками
  8. Это я так, для более глобального понимания вопроса написал пару слов о DFT --------- Если хорошему дизайн центру заплатить так и ПЛИСом и чё там в нём заморачиваться не надо. Там разберутся и всё сделают :) Короче с верилога переходим на экономику и маркетинг - сколько доплатить за "допиливание дизайн центром" и будет ли всё вообще иметь смысл....
  9. Офигеть активный форум :))) Итак, прошло три года со времени моего последнего поста... Пишу на SV. Интерфейсы нравятся.... да и тулзы всё отлично поддерживают.
  10. Сделав десятки бекэндов и DFT позволю себе заметить пару моментов: - Этап DFT в тулзе для синтеза (Genus) действительно выглядит как "просто говоря, замена триггеров ".... Но в тулзе для для ATPG (Encounter Test) можно вставить JTAG контроллер и боундари скан. Или BIST контроллер и ещё кое-чё. - Тайминг констрейны дописывать надо, как минимум для тест моды. Иногда не просто их отделить от остальных. - Построение клок три с тестовыми структурами и без может отличаться. - Надо пины для тест интерфейса. И просто JTAG пинов может и не хватить (но некоторые и через землю+питание всё тестить умеют) - ATPG фолт кавередж нас интересует? Надо его вручную допиливать (лучше прямо меняя исходный RTL). При 85% и партиях в пару сот тысяч\год готовтесь платить за брак (вынуть долларовую микросхему, например с машины, и проанализировать, стоит от 15 000УЕ). Особенно жестко, это когда заказчик останавливает производство до выяснения (распила кристала в месте где он сломан) и устранения за счёт нерадивого дизайнера. - Имея четкое представление что и как происходит можно на этапе FPGA сделать дружественный к DFT и безгиморный дизайн. Даже специализация такая есть - DFT инженер (особенно когда аналог на борту есть) ------------------------------------- - Насчёт того, есть ли смысл переводить FPGA->ASIC.... Думаю да, если дешевле чип будет при массовом производстве. Ну ещё в ASIC можна вытянуть характеристики получше, если прям сильно надо. Но хотел-бы услышать про реальные и успешные риал кейсы, если есть у кого...
  11. А я правильно понимаю что в FPGA проект и все DFT засовывается для последующего производства? Я могу предположить что если производитель FPGA делает ASIC, то он-же и DFT уже встраивает сам на уровне своих макроячеек (eASIC, BaySand). А вот если кто-то переводит RTL в ASIC то это дополнительный этап дописывания кода, констрейнов и т.п У кого-то есть опыт такого перевода RTL в ASIC?
  12. Насколько я понимаю, тулза анализирует схему статически - т.е. ей пофигу когда и в какой последовательности чтото может приходить (как и при STA). Тулза смотрит есть ли общий сигнал (по функции - enable, но с любым именем) который разрешает запись в группу тригеров и ставит туда клок-гейти (если число тригеров не меньше N). Почему не ставит в конкретном случае - трудно сказать без RTL
  13. Главное знать ответ на вопрос: Круче для чего и за какие деньги? По конкретным тулзам если смотреть то одни лучше там а другие там на каких-то спец тестах. CADENCE вроде гибче в лицензионной политике. Если стоит вопрос выбора - то берите: - то что лучше поддерживает ваш фаб библиотеками итп. - то что для вас "достаточно хорошо" а не "круче всего на свете", - то что покроет своей гибкостью ваши потребности на многие годы (чтоб новых людей не нанимать и все скрипты и дизайн фло не переписывать). - цифровой CADENCE более подходит под асинхронные трюки миксид сигнала (гибкость команд и возможностей). SYNOPSYS - под строго синхронную цифру. - когда все тулзы от одного производителя то они более менее дружат друг с другом и лучше брать все у одного, а не разнобой Касаемо документации... Самому долго и нудно разбираться. Но у CADENCE просто супер внятные тренинги (цена тренинга мизерна по сравнению с ценой лицензии - 1к 100 где-то. т.е. надо брать :) ) Сколько работаю все эти тулзы перманентно сыроваты :) В целом, CADENCE имеет более интегрированные и дружелюбные к скриптингу тулзы. Поработав и с тем и с тем, я-бы брал CADENCE из-за удобства писать скрипты. ---- P.S Документация говорит что тулза и как делает, но не говорит нафига это надо и когда и зачем этим пользоваться. А тут-то вся собака и зарыта. Хорошо-бы у кого-то перенять опыт сначала....
  14. 1) результат синтеза во многом зависит от: SDC, Fmax, включенных опций оптимизации, флурплана и.т.д Бится за буквы в Verilog - не совсем благодарное дело в этом случае... 2) а чё это Вы не верите в способности современных супер синтезаторов-оптимизаторов?
  15. Цитата(Shivers @ Oct 29 2015, 14:50) .... В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho. Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно. Теряя на времени разработки, оптимальности по скорости\площади итп. Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе. Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.
  16. Цитата(Doka @ Oct 28 2015, 19:34) Прошу высказаться у кого есть опыт (удачный, а в особенности - неудачный) использования поддерживаемых тулами Synopsys конструкций SystemVerilog. Прежде всего интересуют тулы: DC, Formality (по нему в гайде вообще не нашёл описание поддерживаемого подмножества конструкций), Synplify. Ситуация: есть два лагеря (кодеры и малочисленная группа принимающих решение консерваторов), которые имеют диаметрально противоположные взгляды. Позиция RTL-кодеров такова: Кодеры понимают преимущества SV, не только для упрощения описания некоторых аспектов и сокращения объёма кода и человеческого фактора (использование интерфейсов на топ-левеле, свои типы данных), но и удобство верификации (enum, однозначное описание регистровой и комбинационной логики) и не хотели бы снижать скорость и качество кода даунгрейдом до Verilog-2001. Позиция ярых консерваторов такова: несмотря на то, что SV давно поддерживается тулами, поддержка эта только на бумаге, из-за того что этими конструкциями никто не пользуется и тул не проверен (пользователи как тестеры не репортовали о багах). В числе компаний, которые не пользуются SV для RTL: ARM, Imagination, Synopsys (IP). Позвольте и свои 5 копеек вставить... 1) SV для верификации - всеми частями за. Симулятори поддерживают хорошо и стандартно. да, при этом симулить микс языков тоже на проблема...как собственно и синтезить микс. 2) Для RTL немного сложнее.... Могут быть ограничения из-за тупой реальности: заказчики не принимают в SV (милитари, спейс), уже всё описано на Верилоге 2001 и надо продолжать поддержку, Вы делаете миксид сигнал симуляцию и ваш симулятор не проддерживает SV... Если таких ограничений нет, то конечно стоит использовать новые возможности. Никого-ж не смущает например что Cadence Encounter от верси и к версии имеет по разному настроенное и работающее ядро для STA (хрен и заметиш) и силикон работать будет "странно". Почему тогда проблема перепроверять ваш код на правильность синтеза? Проверили в своём фло - синтезилось правильно - пользуйтесь Да и вообще, почему прохождение бек-энд фло не часть процеса верификации IP? Единственное что надо учитывать так это то, что не все возможности языка полно и правильно поддерживаются бек-энд тулзами. Т.е. в новых версиях IP ядро может и не синтезится как надо.... а вдругой тулзе и вообще не синтезится... Я советую использовать SV для синтеза только в той части что действительно упрощает кодинг ( использование интерфейсов на топ-левеле очень улутшает читабельность кода). Все остальные супер-програмистские навороты лутше отложить пока.... Ну и перед использованием SV для синтеза верифицировать код в бек-энде. Цитата(Shivers @ Oct 29 2015, 11:12) .....Предлагаю простой тест - выясните, насколько Ваши RTLщики знают STA. Ведь большинство RTL'щиков .... RTL'щик знающий STA (и что такое синхронный дизайн с Back-End) это такая-же редкость как и Преподаватель сопромата с обложки Playboy
  17. Цитата(v_mirgorodsky @ Jul 28 2015, 10:54) Самой логичной причиной деления клоков может быть часть дизайна, которая не успевает работать на основном клоке Я так думаю. Для этого в тригерах FPGA придумано FF.CE Ну или это CE неявно выходит из описания функции переключения тригера.... Исходя из этого только ~20% тригеров меняют состояния на текущем клоковом эдже. Т.е. 80% дизайна работает реально медленнее системного клока....
  18. Цитата(v_mirgorodsky @ Jul 28 2015, 04:40) Даже не знаю, возможно за последнее время Квартус вместе с ИСЕ серьезно добавили в интеллекте, или проект в котором возможна такая манипуляция клоками крайне далек от предела возможностей выбранного кристала. .... - пришлось переделать пару блоков и вставить синхронизаторы. Неоптимально и неправильно - это разные вещи. Да - можно делать делёные клоки, но архитектура FPGA это плохо поддерживает (ибо клоковое дерево намертво и изначально встроено без учёта таких фокусов). В ASIC - никаких проблем (никакие "холды", подобно тем что Вы нашли там не возникают). Да - FPGA тузы нормально понимают такое описание и делают правильно STA и всё остальное, но как Вы заметили уже выжать максимум в этом случае не выходит (тулза тратит дополнительные ресурсы на то чтобы выполнить заданное требование STA в своей архитектуре, которая на делёные клоки не заточена ) И главное. Ума не приложу нафига в дизайне на FPGA делить клоки?
  19. Цитата(Nix_86 @ May 23 2015, 13:12) Кодcreate_generated_clock -name i_clk_12_5MHz \     -source [get_ports clk] \     -divide_by 4 \     [get_pins clk_12_5_reg/q] 1-й Подозревая типичную ошибку синхронно дизайна, таки спрошу - а зачем делить именно клоки понадобилось? Цитата(v_mirgorodsky @ Jul 18 2015, 09:55) Если коротко, то делить так клоки принципиально нельзя. Ни в ASIC, ни в FPGA. Эта система сильно подвержена нарушению холдов при переходе из одного клокового домена в другой. Можно. в FPGA немного труднее тулзе. Ничё подобного.
  20. Цитата(serjj @ Jun 25 2015, 12:12) зы: собственно я предлагаю сделать аналог латча. как вариант попробовать имплиментировать латч: Кодalways_latch begin     if (a & b)         err = 1'b1; end Вечный Эррор.... Любые 2 идельно похожие сигналы изз-за гонок всегда будут чуть сдвинуты или чуть отличаться на фронтах - т.е. всегда будут как минимум спайки. В результате - латч всегда словит ошибку (ну или метастабильность какую, если совсем пичёк).... Тут сначала надо определится что значит " проверить два сигнала на перекрещивание" в смысле синхронного дизайна....
  21. Цитата(yaghtn @ Jun 19 2015, 12:04) Обмен происходит изредка и не быстрее мегагерца, поэтому мне показалось неоптимальным постоянно тактовать модуль SPI от быстрого системного клока ПЛИС. А чем по Вашему такое решение неоптимально в этом случае если есть такая возможность? Делать SPI от внешнего клока имеет смысл только если нет возможности привязатть к внутреннему клоку (напр. он сравним по скорости с SPI, или его нет )
  22. Цитата(iosifk @ Jun 18 2015, 17:29) Сделать два ресета, каждый в своем домене под свои клоки... У Ксайлинкса при установке есть пример, там именно так и сделано... да...но только там обмен данными между доменами... На старте надо аккуратно, ато может с 250 пойти в 125, которое есчё в ресете....
  23. Цитата(Inanity @ Jun 18 2015, 17:17) Скорее всего это правда, которую синтезатор сам вряд ли поймёт, хотя теоретически косвенно можно было это автоматически определять по настройкам ядер. В чём проблема поставить синхронизаторы на каждый домен? Имхо, может это более избыточное (на 2 триггера!), но более прозрачное решение, чем сложные констрейны и клоки со сдвинутыми фазами.. Кнстрейны ошибки не исправляют, а выявляют
  24. Цитата(seemann @ Jun 18 2015, 16:56) Объясните мне, как reset может стать асинхронным в одном из доменов если он синхронизируется к одному из клоков которые привязанные друг к другу по фазе? 1) .... Значит есть два клок домена.... Клок домены обычно асинхронны... 2) Так как Вам в репорте тулза и написала. 3) Может Вам эти домены с PLL и не нужны?
  25. Цитата(seemann @ Jun 18 2015, 16:00) Доброго времени суток! Мигрировал дизайн с четвёртого Циклона на пятый, и появились recovery violations reset-сигнала... Значит есть два клок домена, один на 250 МГц и второй на 125 МГц, без сдвига по фазе. Reset синхронизируется на 125 МГц и распределяется по обеим доменам. Оба клока и reset проводятся через клок буферы (смотрим картинку). TimeQuest показывает, что reset-сигнал не попадает вовремя на триггера 250 МГц-ного домена. Вижу два варианта: И шо Вы хотели? Вы привязали reset к 125МГц клоку и подали его асинхронно в 250МГц домен. Оно и в жизни работать не будет нормально...