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

    

topor_topor

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

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

  • Посещение

Репутация

0 Обычный

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

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

Контакты

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

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

1 732 просмотра профиля
  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 - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.