Jump to content

    

про мультиплексирование падов

Как правило, в корпусах ножки -- ограниченный ресурс, и поэтому приходится так или иначе их мультиплексировать (скажем, uart.tx, spi.sck и gpio). В целом, для маленьких корпусов написать мультиплексоры вручную -- не проблема, но когда их количество приближается к сотне-другой -- становится страшно что-то перепутать. Ну, и тесты пропорционально разбухают.

Вопрос к знатокам -- а не придумало ли человечество какого-нибудь способа описывать такие вот мультиплексоры на ногах микросхем? Мол, у первой ножки -- функции такие-то, переключаются они таким-то битом в таком-то регистре.  Да вот даже какой-нибудь XML?

Профит очевиден -- из xml-подобного описания можно было бы сгенерировать как HDL для синтеза, так и BSDL-файл для скан-тестирования, так и заголовочные файлы для софта. Велосипед изобретать уж очень не хочется.

Share this post


Link to post
Share on other sites

за человечество не скажу - я писал awk скрипт для генерации верилога и h-файла из csv (excel), но это очень давно и кода уже нет

предположу, что сейчас проще взять питон и написать самому, чем разбираться с чужим кодом

для генерации софта (c, h) у frescale есть и отдельные программы и экселевские макросы и т.д. (и хранят эти генераторы инфу обычно в xml - почему, для меня загадка, наверно из-за любви к халявным парсерам :)

для генерации HDL вряд ли кто-то будет заморачиваться созданием GUI и мануалов. но генераторы, скорее всего, пишут

 

 

Share this post


Link to post
Share on other sites

Тоже приходилось писать парсер csv в схожей задаче (таблица с порядком падов в вайрбонд корпусе -> размещение на флорплане), скрипт писал на тикле. Думаю, это оптимальный маршрут, потому что в экселе очень удобно с исходной информацией работать.

p.s.

лучше не мультиплексировать клоки и данные - сильно усложняет констрейнты и имплементацию

Edited by Aleх

Share this post


Link to post
Share on other sites

спасибо отписавшимся! Понятно, будем велосипедить.

А между прочим, в целях повышения уровня сознательности — не осталось ли у вас примерной "рыбы" экселевского файла? Понятно, что задачи у всех разные, но все же...

Share this post


Link to post
Share on other sites

Ничего не осталось. Общий принцип следующий: чем больше эксель похож на полноценную документацию, тем сложнее будет парсер. И наоборот - конструкции целевого формата можно заложить в эксель сразу так, что парсер и не нужен.

У меня была таблица, где в строке было указано - название сигнала в документации, сигнала в rtl, название инстанса пада (филлера, корнерселла, клампа и т.д.), название селла, размеры пада, ориентация, сторона на кристалле, и текст с описанием. Парсер читал файл построчно, бил строку на слова, и слова с определенной позицией сохранялись в переменные, потом по этой информации я делал автоматический плейс на флорплан. Очень удобно, когда падов много, или они в несколько рядов. Сам же эксель был универсальной докой на согласование с - разработчиками корпуса, ртль-щиками, и бэкендом. Любое изменение (конструкторами, ртль-щиками) в этой доке я моментально переносил на флорплан с помощью парсера/скриптов.Исключительно удобно.

В Вашем случае, если парсер писать неохота, можете сразу в эксель конструкции верилога закладывать. Так, чтобы при конвертации в csv получался готовый код на верилоге.

Share this post


Link to post
Share on other sites

@demidrol

давно ходят идеи законтрибьютить генерилку PAD-MUX, но поскольку с разаработкой SoC сейчас не связан - трудно оправдать "нецелевое" использование времени.

поделюсь некоторыми идеями, дабы после тейпаута не было мучительно больно:

 

1. Самое главное: 

  1. аккуратно выписать сценарии применения SoC - т.е. в таком сценарии такое-то кол-во таких-то интерфейсов.
  2. взять wosrt case сценарий и посчитать пролезаем ли по пинам в текущую спеку из ТЗ (например) с учётом % пинов, которые будут заняты землей/питанием/ddr/дебагом/etc
  3. внимательно посмотреть на выписанные сценарии и понять как можно оптимизировать их число - какие можно объединить/от каких онтерфейсов отказаться, чтобы объединить сценарии
  4. далее весьма творческая работа по раскидыванию сценариев (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 на каждую сторону вайрбонда).

 

Share this post


Link to post
Share on other sites

классно, спасибо!

Есть только пара "но"

1. Я так понял, что у вас не было вариантов разварки (т.е. все пады всегда выводились наружу)

2. А как было устроено документирование самого pinmux'а? Т.е. были ли у вас переназначаемые или многофункциональные пины, а если да -- то как указывались источники сигналов для мультиплексоров (сигнал ли это с выделенного пада или внутренний регистр, управляемый процессором).

Share this post


Link to post
Share on other sites
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 по ширине все столбцы

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now