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

    

topor_topor

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

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

  • Посещение

Репутация

0 Обычный

Информация о topor_topor

  • Звание
    Местный
  • День рождения 04.01.1980

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

1 607 просмотров профиля
  1. А кто ни будь (может НИИ какие, или частные фирмы) делает дизайны для зарубежных заказчиков? В европах достаточный спрос как на аутсорсинг: верификацию, цифровой, аналоговый дизайн, так и на дизайн и изготовление готовых чипов (миксид сигнал чаще).
  2. Для ошибок CDC рекомендую статический анализ в Conformal или SpyGlass CDC. timing simulation не всё увидиш. Особенно когда приходится иметь дело с сопровождением большого проекта, или стороннего проекта и особенно когда в CDC накручено и нет внятного описания что и зачем накручено (для ревью). Эти тулзи красиво показывают часть схемы с проблемами. timing simulation на нетлисте с SDF позволяет "верифицировать" констрейны из SDC (и-то частично), посмотреть времянки с задержками (например тайминги на памяти, внешнем интерфейсе). Подтвердить сетап\холды можно частично потому, что SDF обычно делают на ворст-типикал-бест корнеры, а силикон может не работать в каком-то промежуточном корнере (это из практики). Нетлист используется для "точного" расчёта рассеиваемой мощности. Примерный можна и при синтезе получить. ---- Если CDC просто и прозрачно сделано, когда нет трюков с SDC, и точно мощность считать не надо - то можно и не симулить нетлисты. Особенно в следующей версии дизайна.
  3. Вспомнил анекдот: "...теоритически мы миллионеры, а практически живем с двумя...". Так вот, оди и тот же "объект" назови разными терминами и сразу и смысл и подходы меняются :) HDL - язык описания аппаратуры, описания схемы - применимо для дизайна А для Тест Бенча - можна и "программой" тестирования назвать или программированием на верилоге. "Программирование" тут сленгом скорее будет если отталкиваться от изначального термина HDL, но по смыслу очень подходит (особенно если речь о классах UVM). --- Короче: Описание схемы и программирование тестов.
  4. Как-то до дебага нетлиста ни разу не доходили.... Если есть причини симулить нетлист (какие?) то тест бенчи пишутся с минимальным подключением к внутренним сигналам и с ограниченными проверками
  5. Это я так, для более глобального понимания вопроса написал пару слов о DFT --------- Если хорошему дизайн центру заплатить так и ПЛИСом и чё там в нём заморачиваться не надо. Там разберутся и всё сделают :) Короче с верилога переходим на экономику и маркетинг - сколько доплатить за "допиливание дизайн центром" и будет ли всё вообще иметь смысл....
  6. Офигеть активный форум :))) Итак, прошло три года со времени моего последнего поста... Пишу на SV. Интерфейсы нравятся.... да и тулзы всё отлично поддерживают.
  7. Сделав десятки бекэндов и DFT позволю себе заметить пару моментов: - Этап DFT в тулзе для синтеза (Genus) действительно выглядит как "просто говоря, замена триггеров ".... Но в тулзе для для ATPG (Encounter Test) можно вставить JTAG контроллер и боундари скан. Или BIST контроллер и ещё кое-чё. - Тайминг констрейны дописывать надо, как минимум для тест моды. Иногда не просто их отделить от остальных. - Построение клок три с тестовыми структурами и без может отличаться. - Надо пины для тест интерфейса. И просто JTAG пинов может и не хватить (но некоторые и через землю+питание всё тестить умеют) - ATPG фолт кавередж нас интересует? Надо его вручную допиливать (лучше прямо меняя исходный RTL). При 85% и партиях в пару сот тысяч\год готовтесь платить за брак (вынуть долларовую микросхему, например с машины, и проанализировать, стоит от 15 000УЕ). Особенно жестко, это когда заказчик останавливает производство до выяснения (распила кристала в месте где он сломан) и устранения за счёт нерадивого дизайнера. - Имея четкое представление что и как происходит можно на этапе FPGA сделать дружественный к DFT и безгиморный дизайн. Даже специализация такая есть - DFT инженер (особенно когда аналог на борту есть) ------------------------------------- - Насчёт того, есть ли смысл переводить FPGA->ASIC.... Думаю да, если дешевле чип будет при массовом производстве. Ну ещё в ASIC можна вытянуть характеристики получше, если прям сильно надо. Но хотел-бы услышать про реальные и успешные риал кейсы, если есть у кого...
  8. А я правильно понимаю что в FPGA проект и все DFT засовывается для последующего производства? Я могу предположить что если производитель FPGA делает ASIC, то он-же и DFT уже встраивает сам на уровне своих макроячеек (eASIC, BaySand). А вот если кто-то переводит RTL в ASIC то это дополнительный этап дописывания кода, констрейнов и т.п У кого-то есть опыт такого перевода RTL в ASIC?
  9. Насколько я понимаю, тулза анализирует схему статически - т.е. ей пофигу когда и в какой последовательности чтото может приходить (как и при STA). Тулза смотрит есть ли общий сигнал (по функции - enable, но с любым именем) который разрешает запись в группу тригеров и ставит туда клок-гейти (если число тригеров не меньше N). Почему не ставит в конкретном случае - трудно сказать без RTL
  10. Главное знать ответ на вопрос: Круче для чего и за какие деньги? По конкретным тулзам если смотреть то одни лучше там а другие там на каких-то спец тестах. CADENCE вроде гибче в лицензионной политике. Если стоит вопрос выбора - то берите: - то что лучше поддерживает ваш фаб библиотеками итп. - то что для вас "достаточно хорошо" а не "круче всего на свете", - то что покроет своей гибкостью ваши потребности на многие годы (чтоб новых людей не нанимать и все скрипты и дизайн фло не переписывать). - цифровой CADENCE более подходит под асинхронные трюки миксид сигнала (гибкость команд и возможностей). SYNOPSYS - под строго синхронную цифру. - когда все тулзы от одного производителя то они более менее дружат друг с другом и лучше брать все у одного, а не разнобой Касаемо документации... Самому долго и нудно разбираться. Но у CADENCE просто супер внятные тренинги (цена тренинга мизерна по сравнению с ценой лицензии - 1к 100 где-то. т.е. надо брать :) ) Сколько работаю все эти тулзы перманентно сыроваты :) В целом, CADENCE имеет более интегрированные и дружелюбные к скриптингу тулзы. Поработав и с тем и с тем, я-бы брал CADENCE из-за удобства писать скрипты. ---- P.S Документация говорит что тулза и как делает, но не говорит нафига это надо и когда и зачем этим пользоваться. А тут-то вся собака и зарыта. Хорошо-бы у кого-то перенять опыт сначала....
  11. 1) результат синтеза во многом зависит от: SDC, Fmax, включенных опций оптимизации, флурплана и.т.д Бится за буквы в Verilog - не совсем благодарное дело в этом случае... 2) а чё это Вы не верите в способности современных супер синтезаторов-оптимизаторов?
  12. Цитата(Shivers @ Oct 29 2015, 14:50) .... В случае, если синтез делает один человек, а RTL пишет другой, такой контроль не возможен, и лучше использовать старый проверенный верилог, imho. Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно. Теряя на времени разработки, оптимальности по скорости\площади итп. Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе. Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.
  13. Цитата(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
  14. Цитата(v_mirgorodsky @ Jul 28 2015, 10:54) Самой логичной причиной деления клоков может быть часть дизайна, которая не успевает работать на основном клоке Я так думаю. Для этого в тригерах FPGA придумано FF.CE Ну или это CE неявно выходит из описания функции переключения тригера.... Исходя из этого только ~20% тригеров меняют состояния на текущем клоковом эдже. Т.е. 80% дизайна работает реально медленнее системного клока....
  15. Цитата(v_mirgorodsky @ Jul 28 2015, 04:40) Даже не знаю, возможно за последнее время Квартус вместе с ИСЕ серьезно добавили в интеллекте, или проект в котором возможна такая манипуляция клоками крайне далек от предела возможностей выбранного кристала. .... - пришлось переделать пару блоков и вставить синхронизаторы. Неоптимально и неправильно - это разные вещи. Да - можно делать делёные клоки, но архитектура FPGA это плохо поддерживает (ибо клоковое дерево намертво и изначально встроено без учёта таких фокусов). В ASIC - никаких проблем (никакие "холды", подобно тем что Вы нашли там не возникают). Да - FPGA тузы нормально понимают такое описание и делают правильно STA и всё остальное, но как Вы заметили уже выжать максимум в этом случае не выходит (тулза тратит дополнительные ресурсы на то чтобы выполнить заданное требование STA в своей архитектуре, которая на делёные клоки не заточена ) И главное. Ума не приложу нафига в дизайне на FPGA делить клоки?