demidrol 0 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба Как правило, в корпусах ножки -- ограниченный ресурс, и поэтому приходится так или иначе их мультиплексировать (скажем, uart.tx, spi.sck и gpio). В целом, для маленьких корпусов написать мультиплексоры вручную -- не проблема, но когда их количество приближается к сотне-другой -- становится страшно что-то перепутать. Ну, и тесты пропорционально разбухают. Вопрос к знатокам -- а не придумало ли человечество какого-нибудь способа описывать такие вот мультиплексоры на ногах микросхем? Мол, у первой ножки -- функции такие-то, переключаются они таким-то битом в таком-то регистре. Да вот даже какой-нибудь XML? Профит очевиден -- из xml-подобного описания можно было бы сгенерировать как HDL для синтеза, так и BSDL-файл для скан-тестирования, так и заголовочные файлы для софта. Велосипед изобретать уж очень не хочется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба за человечество не скажу - я писал awk скрипт для генерации верилога и h-файла из csv (excel), но это очень давно и кода уже нет предположу, что сейчас проще взять питон и написать самому, чем разбираться с чужим кодом для генерации софта (c, h) у frescale есть и отдельные программы и экселевские макросы и т.д. (и хранят эти генераторы инфу обычно в xml - почему, для меня загадка, наверно из-за любви к халявным парсерам :) для генерации HDL вряд ли кто-то будет заморачиваться созданием GUI и мануалов. но генераторы, скорее всего, пишут Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 17 декабря, 2019 Опубликовано 17 декабря, 2019 (изменено) · Жалоба Тоже приходилось писать парсер csv в схожей задаче (таблица с порядком падов в вайрбонд корпусе -> размещение на флорплане), скрипт писал на тикле. Думаю, это оптимальный маршрут, потому что в экселе очень удобно с исходной информацией работать. p.s. лучше не мультиплексировать клоки и данные - сильно усложняет констрейнты и имплементацию Изменено 17 декабря, 2019 пользователем Aleх Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demidrol 0 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба спасибо отписавшимся! Понятно, будем велосипедить. А между прочим, в целях повышения уровня сознательности — не осталось ли у вас примерной "рыбы" экселевского файла? Понятно, что задачи у всех разные, но все же... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 18 декабря, 2019 Опубликовано 18 декабря, 2019 · Жалоба Ничего не осталось. Общий принцип следующий: чем больше эксель похож на полноценную документацию, тем сложнее будет парсер. И наоборот - конструкции целевого формата можно заложить в эксель сразу так, что парсер и не нужен. У меня была таблица, где в строке было указано - название сигнала в документации, сигнала в rtl, название инстанса пада (филлера, корнерселла, клампа и т.д.), название селла, размеры пада, ориентация, сторона на кристалле, и текст с описанием. Парсер читал файл построчно, бил строку на слова, и слова с определенной позицией сохранялись в переменные, потом по этой информации я делал автоматический плейс на флорплан. Очень удобно, когда падов много, или они в несколько рядов. Сам же эксель был универсальной докой на согласование с - разработчиками корпуса, ртль-щиками, и бэкендом. Любое изменение (конструкторами, ртль-щиками) в этой доке я моментально переносил на флорплан с помощью парсера/скриптов.Исключительно удобно. В Вашем случае, если парсер писать неохота, можете сразу в эксель конструкции верилога закладывать. Так, чтобы при конвертации в csv получался готовый код на верилоге. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 19 декабря, 2019 Опубликовано 19 декабря, 2019 · Жалоба @demidrol давно ходят идеи законтрибьютить генерилку PAD-MUX, но поскольку с разаработкой SoC сейчас не связан - трудно оправдать "нецелевое" использование времени. поделюсь некоторыми идеями, дабы после тейпаута не было мучительно больно: 1. Самое главное: аккуратно выписать сценарии применения SoC - т.е. в таком сценарии такое-то кол-во таких-то интерфейсов. взять wosrt case сценарий и посчитать пролезаем ли по пинам в текущую спеку из ТЗ (например) с учётом % пинов, которые будут заняты землей/питанием/ddr/дебагом/etc внимательно посмотреть на выписанные сценарии и понять как можно оптимизировать их число - какие можно объединить/от каких онтерфейсов отказаться, чтобы объединить сценарии далее весьма творческая работа по раскидыванию сценариев (alternative pin func) в матрицу пинов - в соответствии с требованиями по внешнему layout чипа (инфа от заказчика/потенц.пользователя иоли на основании здравого смысла (например, не особо двигать от сценария к сценарию клоковые сигналы)). 2. Вкусовщина: таблиц может быть две или одна (но длинная): 1я таблица: описание свойств пинов (похожее на то, что привёл Алекс), примитивный пример можно посмотреть у меня в репо здесь: https://github.com/iDoka/asic-pinout-drawer/blob/master/example/pinout.adoc (убрана проприетарная инфа типа имени цела конкретной либы) 2я таблица: собственно матрица пинов и сценариев как описано выше 3. Сама реализация идеи - дело десятое, когда есть понимание как это архитектурно должно выглядеть, но я бы избегал использования TCL или перла для этих задач. Велосипед по ссылке выше написан на php (в нем такие же удобные возможности работать с экзелем/csv/json/svg как и в python) + есть возможности использования шаблонизаторов при генерации исходного кода. PS: для больших дизайнов может так получиться что несколько PAD-MUX вместо одного может сильно упростить жизнь не только физдизайнерам (например, свой отдельный PAD-MUX на каждую сторону вайрбонда). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demidrol 0 20 декабря, 2019 Опубликовано 20 декабря, 2019 · Жалоба классно, спасибо! Есть только пара "но" 1. Я так понял, что у вас не было вариантов разварки (т.е. все пады всегда выводились наружу) 2. А как было устроено документирование самого pinmux'а? Т.е. были ли у вас переназначаемые или многофункциональные пины, а если да -- то как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 20 декабря, 2019 Опубликовано 20 декабря, 2019 · Жалоба 7 hours ago, demidrol said: Т.е. были ли у вас переназначаемые или многофункциональные пины да, были. 7 hours ago, demidrol said: как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором) "регистр управляемый процессором" - я так понимаю речь про периферийный модуль GPIO? это тоже вопрос архитектуры: делать ли его совмещенным с PAD-MUX (т.е. внутри него) либо выносить в отдельный уровень иерархии и подключать к PAD-MUX снаружи как прочую периферию. единого мнения нет - зависит от размера SoC и есть ли разбивка пинов на несколько PAD-MUX 7 hours ago, demidrol said: как было устроено документирование самого pinmux'а экзель -> csv -> adoc -> pdf собственно пример выглядит https://github.com/iDoka/asic-pinout-drawer/blob/master/example/pinout.adoc в общий asciidoc коннектится директивами инклюд. опять же про вкусовщину с числом таблиц, что писал выше определяется тем, как хочется чтобы в документации выглядела эта таблица заводить единственную таблицу неудобно тем, что не вмещаются на А4 по ширине все столбцы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
