topor_topor

Ка-кто давно я JTAG boundary scan вставлял тулзой.... Но насколько помню, ей достаточно видеть ТОП модуль на верилоге (RTL или нетлист) без падов. Она тупо читает на верилоге что вход\выход, что указано как клок\ресет и вставляет нужные ячейки вокруг ТОПа. -------------------------- Насчёт вкинуть ТОП с падами в DFT, для вставления boundary scan вокруг падов вместо портов ТОПа не знаю... Я всё-таки думаю что boundary scan оборачивается вокруг ТОП модуля а не падов...

Спасибо за ответы. Действительно HAL использует CMSIS, т.е. он надстройка над CMSIS. Например: #include "stm32f4xx.h" // <- CMSIS void HAL_NVIC_DisableIRQ(IRQn_Type IRQn) { /* Check the parameters */ assert_param(IS_NVIC_DEVICE_IRQ(IRQn)); /* Disable interrupt */ NVIC_DisableIRQ(IRQn); // <- CMSIS } ================================================================ Подскажите пожалуйста какой API используют драйверы которые генерит CuebMX? Напр. USB, Eth. Как я вижу в "usbh_conf.h" используется микс HAL и CMSIS: // В "usbh_conf.h" есть инклуды с HAL & CMSIS #include "cmsis_os.h" #include "stm32f4xx.h" #include "stm32f4xx_hal.h" // Есть вызовы HAL ("usbh_platform.с") HAL_GPIO_WritePin(GPIOC,GPIO_PIN_0,(GPIO_PinState)data); // Есть вызовы CMSIS ("usbh_core.с") osThreadDef(USBH_Thread, USBH_Process_OS, USBH_PROCESS_PRIO, 0U, USBH_PROCESS_STACK_SIZE); Зачем использовать микс ? Похоже что на уровне ядра (usbh_core) пишется платформенно независимо с использованием CMSIS, а при переходе к конкретному микроконтроллеру (usbh_platform) уже с использованием HAL. В результате USB надо использовать по-любому через HAL. Выходит нет смысла использовать CMSIS (а это немного сложнее) так как нужные драйвера всё равно в HAL....

Только начал изучать STM32 CubeMX. До сих пор не понятен один момент - как соотносятся CMSIS и HAL библиотеки? Пересекаются, дополняют друг-друга или независимы? ------------------------------------------------------------------------- Насколько понял сам: а) Есть CMSIS для конкретного ядра (без периферии) \Drivers\CMSIS\Include. В этих инклудах нет ничего из периферии типа ADC\GPIO б) Есть CMSIS для STM32 периферии \Drivers\CMSIS\Device\ST\STM32F4xx\Include. В этих инклудах есть периферия (ADC\GPIO итд) но нет ничего с ядра в) Есть CMSIS обертка для FreeRTOS \Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS/ г) Есть FreeRTOS и без CMSIS обертки \Middlewares\Third_Party\FreeRTOS\Source\include д) Есть HAL \Drivers\STM32F4xx_HAL_Driver\Inc. В этих инклудах есть периферия (ADC\GPIO итд) и ядро (stm32f4xx_hal_cortex.h) е) А вот сгенеренный CubeMX \Inc\main.h содержит микс CMSIS и HAL. #define LD5_Pin GPIO_PIN_14 - ссылка на HAL #define B1_GPIO_Port GPIOA - ссылка на CMSIS ------------------------------------------------------------------------- Вопросы появились такие: 1) Достаточно ли CMSIS библиотек (пп.а), б), в)) для использования и ядра и периферии STM32 совместно с FreeRTOS? 2) Достаточно ли HAL библиотек (пп.д)) для использования и ядра и периферии STM32 совместно с FreeRTOS (п.г))? 3) Зачем CubeMX замешал CMSIS и HAL? Имеет ли смысл такой микс? 4) Если STM32 имеет свою "не стандартную" (писанную под конкретный микроконтроллер) библиотеку CMSIS (п.б)), то есть ли смысл говорить об универсальности и переносимости кода? В другом контроллере свои биты и свой вариант периферийной части CMSIS. Т.е. в любом случае переписывать код под другую периферию... Ради стиля написания разве.... Для тех кто операционку под голое ядро пишет может только и есть смысл работать в CMSIS. Если делать вызовы операционки через CMSIS (п.г)), то при замене операционки (на uOS) эти вызовы не изменятся...

Если микросхема чисто цифровая и делается в цифровых тулзах то пады ставятся в RTL в топе цифры. Правда часто пады имеют аналоговые сигналы которые надо подключать аналоговым способом (как минимум запретить вставление буферов итп.). Если миксид сигнал, то часто цифра есть внутренним блоком аналогового топа. Тут пады тоже аналогово подключаются аналоговым дизайнером а цифра делается отдельно без них. Если есть честный LIB падов то лучше с ними - задержки входов \ выходов учтутся автоматом... если конечно обконстрейнено всё правильно в SDC (и если вообще сигналы через пады надо констрейнить). Если честных LIB нет то не принципиально. Задержки через пады можно и в SDC описать... Можно как угодно :) Для DFT с падами или без падов вообще без разницы. ------------- "Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.)" Это из библии какой-то? :) Не знаю что такое "СНК" и "СФ" и чем способ "снизу" от способа "сверху отличается", но менять фло сообразно разуму и текущему моменту очень даже стоит :)

Из практики могу сказать, что в "дизайн фло" нету ничего "обязательного" Тут не аероспейс где без освещения файнал тест протонов не проходит :) Можна и нужно понимать зачем что делается и когда можно что исключить и с каким риском.

HDL - это язык описания аппаратуры. Другими словами - схемы электрической принципиальной. Код в примере это просто программа а не схема. Схему нарисовать перед описанием на языке можете?

"Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?" Для разработки софта до появления железа применяю такие варианты: - Если проект ASIC/FPGA и процессор есть в виде RTL, то создаются напрямую прошивки памяти и симулятся в цифровом симуляторе (аналоговая периферия моделируется в верилоге напр.) - До появления силикона (ASIC) делается FPGA и софт заливается через дебагер (железо процессора конечно должно иметь этот дебагер) - Использую программный эмулятор процессора + модели периферии написанные специально под платформу. Это часть аппаратного дебагера, которая вместо заливки программы в железо симулирует процессор. Такой вариант требует относительно длительного периода создания моделей периферии. Часто используется без моделей периферии. - Абстрагирование от железа достигается например применением RTOS. Т..е доступ к периферии делается через вызов стандартных функций ОС. Или как минимум периферийные адреса прячутся за DEFINE. Плюс пишется более-менее стандартный набор функций (напр. TimeEnable(), TimeSet(), TimeGet() итд.) - Касаемо тестирования софта, на уровне отдельных функций пишутся тести на том-же языке и считается код кавередж. Плюс встраиваются асершены (не компилируются в финальную прошивку) для проверки того что входные данные в рендже, что произошли нужные события итп. Создание и Тестирование софта для больших машин под Win\Unix это отдельная тема...

А кто ни будь (может НИИ какие, или частные фирмы) делает дизайны для зарубежных заказчиков? В европах достаточный спрос как на аутсорсинг: верификацию, цифровой, аналоговый дизайн, так и на дизайн и изготовление готовых чипов (миксид сигнал чаще).

Для ошибок CDC рекомендую статический анализ в Conformal или SpyGlass CDC. timing simulation не всё увидиш. Особенно когда приходится иметь дело с сопровождением большого проекта, или стороннего проекта и особенно когда в CDC накручено и нет внятного описания что и зачем накручено (для ревью). Эти тулзи красиво показывают часть схемы с проблемами. timing simulation на нетлисте с SDF позволяет "верифицировать" констрейны из SDC (и-то частично), посмотреть времянки с задержками (например тайминги на памяти, внешнем интерфейсе). Подтвердить сетап\холды можно частично потому, что SDF обычно делают на ворст-типикал-бест корнеры, а силикон может не работать в каком-то промежуточном корнере (это из практики). Нетлист используется для "точного" расчёта рассеиваемой мощности. Примерный можна и при синтезе получить. ---- Если CDC просто и прозрачно сделано, когда нет трюков с SDC, и точно мощность считать не надо - то можно и не симулить нетлисты. Особенно в следующей версии дизайна.

Вспомнил анекдот: "...теоритически мы миллионеры, а практически живем с двумя...". Так вот, оди и тот же "объект" назови разными терминами и сразу и смысл и подходы меняются :) HDL - язык описания аппаратуры, описания схемы - применимо для дизайна А для Тест Бенча - можна и "программой" тестирования назвать или программированием на верилоге. "Программирование" тут сленгом скорее будет если отталкиваться от изначального термина HDL, но по смыслу очень подходит (особенно если речь о классах UVM). --- Короче: Описание схемы и программирование тестов.

Как-то до дебага нетлиста ни разу не доходили.... Если есть причини симулить нетлист (какие?) то тест бенчи пишутся с минимальным подключением к внутренним сигналам и с ограниченными проверками

Это я так, для более глобального понимания вопроса написал пару слов о DFT --------- Если хорошему дизайн центру заплатить так и ПЛИСом и чё там в нём заморачиваться не надо. Там разберутся и всё сделают :) Короче с верилога переходим на экономику и маркетинг - сколько доплатить за "допиливание дизайн центром" и будет ли всё вообще иметь смысл....

Офигеть активный форум :))) Итак, прошло три года со времени моего последнего поста... Пишу на SV. Интерфейсы нравятся.... да и тулзы всё отлично поддерживают.

Сделав десятки бекэндов и DFT позволю себе заметить пару моментов: - Этап DFT в тулзе для синтеза (Genus) действительно выглядит как "просто говоря, замена триггеров ".... Но в тулзе для для ATPG (Encounter Test) можно вставить JTAG контроллер и боундари скан. Или BIST контроллер и ещё кое-чё. - Тайминг констрейны дописывать надо, как минимум для тест моды. Иногда не просто их отделить от остальных. - Построение клок три с тестовыми структурами и без может отличаться. - Надо пины для тест интерфейса. И просто JTAG пинов может и не хватить (но некоторые и через землю+питание всё тестить умеют) - ATPG фолт кавередж нас интересует? Надо его вручную допиливать (лучше прямо меняя исходный RTL). При 85% и партиях в пару сот тысяч\год готовтесь платить за брак (вынуть долларовую микросхему, например с машины, и проанализировать, стоит от 15 000УЕ). Особенно жестко, это когда заказчик останавливает производство до выяснения (распила кристала в месте где он сломан) и устранения за счёт нерадивого дизайнера. - Имея четкое представление что и как происходит можно на этапе FPGA сделать дружественный к DFT и безгиморный дизайн. Даже специализация такая есть - DFT инженер (особенно когда аналог на борту есть) ------------------------------------- - Насчёт того, есть ли смысл переводить FPGA->ASIC.... Думаю да, если дешевле чип будет при массовом производстве. Ну ещё в ASIC можна вытянуть характеристики получше, если прям сильно надо. Но хотел-бы услышать про реальные и успешные риал кейсы, если есть у кого...

А я правильно понимаю что в FPGA проект и все DFT засовывается для последующего производства? Я могу предположить что если производитель FPGA делает ASIC, то он-же и DFT уже встраивает сам на уровне своих макроячеек (eASIC, BaySand). А вот если кто-то переводит RTL в ASIC то это дополнительный этап дописывания кода, констрейнов и т.п У кого-то есть опыт такого перевода RTL в ASIC?

Насколько я понимаю, тулза анализирует схему статически - т.е. ей пофигу когда и в какой последовательности чтото может приходить (как и при STA). Тулза смотрит есть ли общий сигнал (по функции - enable, но с любым именем) который разрешает запись в группу тригеров и ставит туда клок-гейти (если число тригеров не меньше N). Почему не ставит в конкретном случае - трудно сказать без RTL

Главное знать ответ на вопрос: Круче для чего и за какие деньги? По конкретным тулзам если смотреть то одни лучше там а другие там на каких-то спец тестах. CADENCE вроде гибче в лицензионной политике. Если стоит вопрос выбора - то берите: - то что лучше поддерживает ваш фаб библиотеками итп. - то что для вас "достаточно хорошо" а не "круче всего на свете", - то что покроет своей гибкостью ваши потребности на многие годы (чтоб новых людей не нанимать и все скрипты и дизайн фло не переписывать). - цифровой CADENCE более подходит под асинхронные трюки миксид сигнала (гибкость команд и возможностей). SYNOPSYS - под строго синхронную цифру. - когда все тулзы от одного производителя то они более менее дружат друг с другом и лучше брать все у одного, а не разнобой Касаемо документации... Самому долго и нудно разбираться. Но у CADENCE просто супер внятные тренинги (цена тренинга мизерна по сравнению с ценой лицензии - 1к 100 где-то. т.е. надо брать :) ) Сколько работаю все эти тулзы перманентно сыроваты :) В целом, CADENCE имеет более интегрированные и дружелюбные к скриптингу тулзы. Поработав и с тем и с тем, я-бы брал CADENCE из-за удобства писать скрипты. ---- P.S Документация говорит что тулза и как делает, но не говорит нафига это надо и когда и зачем этим пользоваться. А тут-то вся собака и зарыта. Хорошо-бы у кого-то перенять опыт сначала....

1) результат синтеза во многом зависит от: SDC, Fmax, включенных опций оптимизации, флурплана и.т.д Бится за буквы в Verilog - не совсем благодарное дело в этом случае... 2) а чё это Вы не верите в способности современных супер синтезаторов-оптимизаторов?

Написать универсальный RTL для IP пригодный для синтеза в любых технологиях и тулзах можно. Теряя на времени разработки, оптимальности по скорости\площади итп. Тут может помочь например Cadence HAL чекер - если там нет варнингов, почти наверняка нет проблем в синтезе. Остальное - упёртость RTLщика и нежилание писать под STA & Back-End - это просто неуважение к колегам. Вопрос к менеджменту а не по технике.

Позвольте и свои 5 копеек вставить... 1) SV для верификации - всеми частями за. Симулятори поддерживают хорошо и стандартно. да, при этом симулить микс языков тоже на проблема...как собственно и синтезить микс. 2) Для RTL немного сложнее.... Могут быть ограничения из-за тупой реальности: заказчики не принимают в SV (милитари, спейс), уже всё описано на Верилоге 2001 и надо продолжать поддержку, Вы делаете миксид сигнал симуляцию и ваш симулятор не проддерживает SV... Если таких ограничений нет, то конечно стоит использовать новые возможности. Никого-ж не смущает например что Cadence Encounter от верси и к версии имеет по разному настроенное и работающее ядро для STA (хрен и заметиш) и силикон работать будет "странно". Почему тогда проблема перепроверять ваш код на правильность синтеза? Проверили в своём фло - синтезилось правильно - пользуйтесь :) Да и вообще, почему прохождение бек-энд фло не часть процеса верификации IP? Единственное что надо учитывать так это то, что не все возможности языка полно и правильно поддерживаются бек-энд тулзами. Т.е. в новых версиях IP ядро может и не синтезится как надо.... а вдругой тулзе и вообще не синтезится... Я советую использовать SV для синтеза только в той части что действительно упрощает кодинг ( использование интерфейсов на топ-левеле очень улутшает читабельность кода). Все остальные супер-програмистские навороты лутше отложить пока.... Ну и перед использованием SV для синтеза верифицировать код в бек-энде. RTL'щик знающий STA (и что такое синхронный дизайн с Back-End) это такая-же редкость как и Преподаватель сопромата с обложки Playboy :)

Для этого в тригерах FPGA придумано FF.CE Ну или это CE неявно выходит из описания функции переключения тригера.... Исходя из этого только ~20% тригеров меняют состояния на текущем клоковом эдже. Т.е. 80% дизайна работает реально медленнее системного клока....

Неоптимально и неправильно - это разные вещи. Да - можно делать делёные клоки, но архитектура FPGA это плохо поддерживает (ибо клоковое дерево намертво и изначально встроено без учёта таких фокусов). В ASIC - никаких проблем (никакие "холды", подобно тем что Вы нашли там не возникают). Да - FPGA тузы нормально понимают такое описание и делают правильно STA и всё остальное, но как Вы заметили уже выжать максимум в этом случае не выходит (тулза тратит дополнительные ресурсы на то чтобы выполнить заданное требование STA в своей архитектуре, которая на делёные клоки не заточена ) И главное. Ума не приложу нафига в дизайне на FPGA делить клоки?

1-й Подозревая типичную ошибку синхронно дизайна, таки спрошу - а зачем делить именно клоки понадобилось? Можно. в FPGA немного труднее тулзе. Ничё подобного.

Вечный Эррор.... Любые 2 идельно похожие сигналы изз-за гонок всегда будут чуть сдвинуты или чуть отличаться на фронтах - т.е. всегда будут как минимум спайки. В результате - латч всегда словит ошибку (ну или метастабильность какую, если совсем пичёк).... Тут сначала надо определится что значит " проверить два сигнала на перекрещивание" в смысле синхронного дизайна....

А чем по Вашему такое решение неоптимально в этом случае если есть такая возможность? Делать SPI от внешнего клока имеет смысл только если нет возможности привязатть к внутреннему клоку (напр. он сравним по скорости с SPI, или его нет )