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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

p.s.

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

Изменено пользователем Aleх

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@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 на каждую сторону вайрбонда).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 по ширине все столбцы

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...