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

    

topor_topor

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

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

  • Посещение

Репутация

0 Обычный

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

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

Контакты

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

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

1 756 просмотров профиля
  1. Cadence Encounter Test.С учетом того что в миксид сигнал чипах цифра внутри аналога и без падов, тулза просто обязана ставить боундари скан без падов... А кстати зачем боудари скан вам понадобился? Для теста самого чипа внутри он вроде как и не нужен....
  2. Как я вижу в драйвере USB, HAL как раз и использован как наслоение над CMSIS с целью изоляции особенностей архитектуры. А не наоборот добавлен CMSIS с целью ускорить работу. Это не понятно. Ещё CMSIS использован как интерфейс к RTOS. Видимо чтобы от конкретной RTOS отвязать драйвер. Это понятно. Выходит к RTOS и битам USB полезли через CMSIS, а к апликейшену через HAL.... В общем, запутал меня ST :( Это что нормально лепить всё в кучу?
  3. Ка-кто давно я JTAG boundary scan вставлял тулзой.... Но насколько помню, ей достаточно видеть ТОП модуль на верилоге (RTL или нетлист) без падов. Она тупо читает на верилоге что вход\выход, что указано как клок\ресет и вставляет нужные ячейки вокруг ТОПа. -------------------------- Насчёт вкинуть ТОП с падами в DFT, для вставления boundary scan вокруг падов вместо портов ТОПа не знаю... Я всё-таки думаю что boundary scan оборачивается вокруг ТОП модуля а не падов...
  4. Спасибо за ответы. Действительно 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....
  5. Только начал изучать 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) эти вызовы не изменятся...
  6. Если микросхема чисто цифровая и делается в цифровых тулзах то пады ставятся в RTL в топе цифры. Правда часто пады имеют аналоговые сигналы которые надо подключать аналоговым способом (как минимум запретить вставление буферов итп.). Если миксид сигнал, то часто цифра есть внутренним блоком аналогового топа. Тут пады тоже аналогово подключаются аналоговым дизайнером а цифра делается отдельно без них. Если есть честный LIB падов то лучше с ними - задержки входов \ выходов учтутся автоматом... если конечно обконстрейнено всё правильно в SDC (и если вообще сигналы через пады надо констрейнить). Если честных LIB нет то не принципиально. Задержки через пады можно и в SDC описать... Можно как угодно :) Для DFT с падами или без падов вообще без разницы. ------------- "Возможно и исключение этапа макетирования СНК, если все используемые СФ-блоки аттестованы и адекватно описаны на языках высокого уровня (VHDL, VHDL-AMS и др.)" Это из библии какой-то? :) Не знаю что такое "СНК" и "СФ" и чем способ "снизу" от способа "сверху отличается", но менять фло сообразно разуму и текущему моменту очень даже стоит :)
  7. Из практики могу сказать, что в "дизайн фло" нету ничего "обязательного" Тут не аероспейс где без освещения файнал тест протонов не проходит :) Можна и нужно понимать зачем что делается и когда можно что исключить и с каким риском.
  8. HDL - это язык описания аппаратуры. Другими словами - схемы электрической принципиальной. Код в примере это просто программа а не схема. Схему нарисовать перед описанием на языке можете?
  9. "Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?" Для разработки софта до появления железа применяю такие варианты: - Если проект ASIC/FPGA и процессор есть в виде RTL, то создаются напрямую прошивки памяти и симулятся в цифровом симуляторе (аналоговая периферия моделируется в верилоге напр.) - До появления силикона (ASIC) делается FPGA и софт заливается через дебагер (железо процессора конечно должно иметь этот дебагер) - Использую программный эмулятор процессора + модели периферии написанные специально под платформу. Это часть аппаратного дебагера, которая вместо заливки программы в железо симулирует процессор. Такой вариант требует относительно длительного периода создания моделей периферии. Часто используется без моделей периферии. - Абстрагирование от железа достигается например применением RTOS. Т..е доступ к периферии делается через вызов стандартных функций ОС. Или как минимум периферийные адреса прячутся за DEFINE. Плюс пишется более-менее стандартный набор функций (напр. TimeEnable(), TimeSet(), TimeGet() итд.) - Касаемо тестирования софта, на уровне отдельных функций пишутся тести на том-же языке и считается код кавередж. Плюс встраиваются асершены (не компилируются в финальную прошивку) для проверки того что входные данные в рендже, что произошли нужные события итп. Создание и Тестирование софта для больших машин под Win\Unix это отдельная тема...
  10. А кто ни будь (может НИИ какие, или частные фирмы) делает дизайны для зарубежных заказчиков? В европах достаточный спрос как на аутсорсинг: верификацию, цифровой, аналоговый дизайн, так и на дизайн и изготовление готовых чипов (миксид сигнал чаще).
  11. Для ошибок CDC рекомендую статический анализ в Conformal или SpyGlass CDC. timing simulation не всё увидиш. Особенно когда приходится иметь дело с сопровождением большого проекта, или стороннего проекта и особенно когда в CDC накручено и нет внятного описания что и зачем накручено (для ревью). Эти тулзи красиво показывают часть схемы с проблемами. timing simulation на нетлисте с SDF позволяет "верифицировать" констрейны из SDC (и-то частично), посмотреть времянки с задержками (например тайминги на памяти, внешнем интерфейсе). Подтвердить сетап\холды можно частично потому, что SDF обычно делают на ворст-типикал-бест корнеры, а силикон может не работать в каком-то промежуточном корнере (это из практики). Нетлист используется для "точного" расчёта рассеиваемой мощности. Примерный можна и при синтезе получить. ---- Если CDC просто и прозрачно сделано, когда нет трюков с SDC, и точно мощность считать не надо - то можно и не симулить нетлисты. Особенно в следующей версии дизайна.
  12. Вспомнил анекдот: "...теоритически мы миллионеры, а практически живем с двумя...". Так вот, оди и тот же "объект" назови разными терминами и сразу и смысл и подходы меняются :) HDL - язык описания аппаратуры, описания схемы - применимо для дизайна А для Тест Бенча - можна и "программой" тестирования назвать или программированием на верилоге. "Программирование" тут сленгом скорее будет если отталкиваться от изначального термина HDL, но по смыслу очень подходит (особенно если речь о классах UVM). --- Короче: Описание схемы и программирование тестов.
  13. Как-то до дебага нетлиста ни разу не доходили.... Если есть причини симулить нетлист (какие?) то тест бенчи пишутся с минимальным подключением к внутренним сигналам и с ограниченными проверками
  14. Это я так, для более глобального понимания вопроса написал пару слов о DFT --------- Если хорошему дизайн центру заплатить так и ПЛИСом и чё там в нём заморачиваться не надо. Там разберутся и всё сделают :) Короче с верилога переходим на экономику и маркетинг - сколько доплатить за "допиливание дизайн центром" и будет ли всё вообще иметь смысл....
  15. Офигеть активный форум :))) Итак, прошло три года со времени моего последнего поста... Пишу на SV. Интерфейсы нравятся.... да и тулзы всё отлично поддерживают.