Привет Всем!
Подскажите пожалуйста, как обстоят дела с библиотеками для ПЛИС(в частности Altera) в Cadence?
Знающие люди говорят, что в Menthor Graphics все элементы ПЛИС есть, а в Cadence нужно ручками все делать.
Мне нужно элемент для Stratix V. Вот здесь нашел только старье:
http://www.altera.com/support/software/dow...nl-allegro.html

Прокладки бибилиотеки у каждого свои. Встроенными библиотеками я бы поостерегся пользоваться. Лучше нарисовать самому, с гарантированным результатом. Нарисовать недолго, есть куча средств, вручную тоже не самый плохой вариант.

Еще не мешало бы писать какая библиотека нужна - символ или корпус. Ну и Cadence контора большая - символ для OrCAD-a и символ для Concept HDL вещи разные.

Спасибо за своевременные отклики!
Согласен самому конечно написать всегда надежней, но когда там порядка 1000 ног - работа не легкая, да и ошибка возможна.
Я работаю в Concept HDL, нужны не просто УГО и footprint а полностью ячейка(cell) , ведь сопоставления логических ног, физическим - это основная работа при создании элемента. Но мой вопрос даже состоял не в том, как мне сделать этот элемент, а в том есть ли в Cadence Concept/allegro PCB грамотная поддержка библиотек изготовителей ПЛИС, потому что повторюсь в Menthor Graphics( насколько я выяснил - сообственно засомневался почмеу нет в Cadence) есть уже интегрированные библиотеки под ПЛИС Altera например.
Что получается Cadence изначально затачивался под то, что новые элементы нужно ручками делать??????

Выразитесь яснее, Вам нужен девайс-файл? Или Вы хотите быстро сделать УГО, в котором будут номера пинов и их названия?


Это где конкретно, что за библиотеки?
Может, речь об IOD? Так у кейденса есть тоже аналог, называется, вроде, FPGA System Planner.

Понятное дело, нужен cell, раз в концепте работаете. Только ведь создать его самому очень просто и быстро, а вероятность ошибки, на самом деле, минимальна, если конечно производитель чипа хоть как-то об этом позаботился
Идете на страницу http://www.altera.com/literature/lit-dp.js...p;WT.oss=pinout (для Альтеры). Скачиваете пинаут нужной Вам ПЛИСы. Редактируете его так, как Вам нужно и готово. А редактировать нужно так, чтобы получить таблицу эквивалентную таблице package в Part Developer - т.е. оставляете уникальные имена пинов, указываете их тип, делите на нужное число гейтов(functions в терминах концепта) - в общем адаптируете фирменную таблицу под требования парт девелопера и аллегро.
Нажмите для просмотра прикрепленного файла
Потом создаете новый cell, создаете в нем новый package, задаете нужное число слотов, в таблице Package Pin добавляете одну строку(CTRL-I) и скопировав подготовленную таблицу в буфер делаете в таблице парт девелопера CTRL-V.
Нажмите для просмотра прикрепленного файла
Все, компонент, а точнее его упаковка и таблца соответсвия пин-функция готовы. Дальше по стандарту - генерите символы и только редактируете расположение ног на этих символах. Советую вначале делать это в разделе Pin -> Global Modify, примерно распределив какие пины с какой стороны символа должны быть. Хотя при наличии лицензии Librarian XL это может быть не так уж и важно.
Да, понятное дело потом можно еще добить эквивалентность пинов(хотя реально не пользую свап пинов для ПЛИСы таким способом, есть более удобная метОда) и при необходимости лучше сразу на уровне cell задать Pin Delay(а вот это в высокоскоростных проектах реально необходимо).

Vitan, при проектировании в обоих маршрутах, хоть Оркад-РСВ, хоть Концепт-РСВ, девайс-файл не нужен. Он является эдаким костылем для поддержки сторонних схематиков с их нетлистами. И Оркад и Концепт при упаковке проекта берут инфо из библиотеки(из cell - в первую очередь), добавляют атрибуты определенные на уровне схемы и приписывают их указанному футпринту, создавая девайс уже в РСВ-проекте(файле).

ЗЫ Да, а готовых библиотек в экспедишне как-то тоже не припоминаю.

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


Что за метода? Я ползую пинсвап, но вот, когда много пинов, то сильно длинные строки получаются, утомляет.

Еще раз - внешний девайс-файл, это именно костыль. В сквозном маршруте проектирования от Кэйденс эти файлы не нужны. РСВ эдитор создает эти типы внутри РСВ-файла, во внутренней базе проекта, на основании информации в упаковке, куда она попадает из библиотек cell.

Нажмите для просмотра прикрепленного файла

Используемая метода для пинсвапа реализуема только в Концепт ХДЛ. В ДИксДизайнере Вы ее использовать не сможете.

Хорошо, т.е. нетлист в этом случае не используется? Или используется, но эта информация уже в нем содержится?


Откуда такая уверенность? Раз уж начали разговор, так могли бы и объяснить...

Нетлист, в каком-то виде, используется в любом случае. Это самом собой. Просто в маршрутах Кэйденс он назвается упаковкой и является не одним файлом, а целым комплектом, каждый из которых содержит разную инфу о проекте:

Нажмите для просмотра прикрепленного файла

Эта упаковка генерится на основании схем и информации из библиотек(те самые cell). При импорте всего этого хозяйства в РСВ ничего, кроме собственно футпринтов(.psm файлов), уже не нужно, все необходимое записано в этих файлах.
Вот собственно из хэлпа: "You need device files only when you are passing the electrical configuration to the layout editor with a third-party netlist, and you are not using Concept for schematic entry."

А со свапом все просто: я не делаю свап на РСВ, а делаю его в схеме. Ведь все ругаются, что схематики только меняют номера пинов, но не меняют текст/название, из-за чего схема подключения ПЛИС становится нечитабельной(название пина одно, а номер пина другой). Вот при "свапе" в схеме эта проблема замечательно решается.
Как: частично вывожу трассы из-под ПЛИСы, подвожу ответные со второй стороны - получаю что-то незаконченное и перепутанное. Потом делается текстовый список как подключены сигналы сейчас(физически, на плате) и как их нужно там подсоединить. Типа такого:
Есть Нужно
NET1 Net2
Net2 Net1
Net3 Net4
Net4 Net3

Потом список цепей из правого столбца вбивается одной операцией в концепте:

Нажмите для просмотра прикрепленного файла

И вот такой возможности, вписывания имен цепей списком я не видел ни в одном софте, кроме Концепт ХДЛ. Потому и написал, что этот способ только для него. Да, ну и еще потому, что РСВ эдитор при изменении цепей не удаляет уже проложенные трассы, иначе это все не имело бы смысла.

Ммм... Не понял проблему. Вот нарисовал я УГО плисины. Там есть пин, например, Data0 и номер у него AB21. После свапа в PCB у него номер, допустим, поменялся, стал AB12. Зачем название менять и почему схема нечитабельна?

Ну обычно потому, что на пине АВ12, на самом деле, сигнал ADDR14 например
Для пинов типа просто IO это на самом деле не важно. А вот когда это пины двойного-тройного назначения, и они уже оказались просваплены в РСВ - схему прочитать невозможно. Ну вот, классический случай:

Нажмите для просмотра прикрепленного файла

А теперь представьте, что эти пины уже просваплены в РСВ Как будем проверять схему?

Опять не понял. Как там может оказаться сигнал ADDR14, если в схеме изначально был нарисован пин Data0 с номером AB12, и к нему шел проводок с надписью DATA0? У Вас свопятся названия подключенных проводников, что ли, а не номера пинов?

Вот именно, что номера.
По даташиту:
имя_пина номер пада имя цепи
DATA0 AB12 DATA0
Фактически после свопа:
имя_пина номер пада имя цепи
DATA0 AB21 DATA0

Пин АВ21 вроде как тоже в группе DATA<31..0>, но не DATA0. Изменился номер пина и схема подключения цепей перестала отвечать распиновке по даташиту.

Че-то никак не догнать. Что за распиновка такая по даташиту? Как в даташите на плисину можно прописать название пина в смысле функциональности? Ну, окромя спец. пинов, конечно. Она же не определена изначально!

Полностью не определена, но частично - да. У Вас никогда не было ПЛИСин, у которых некоторые банки сразу заточены под некоторые интерфейсы, например под ту же память? Вот эти пины могут быть только данными, причем байт-группы уже предопределены, эти адресами, а эти и адресами и клоками. И тут начинается веселье, потому как свап возможен, но ограничений куча. И если сделать такой свап классически, из РСВ в схему с заменой номеров пинов - схема становится нечитаемой, точнее непроверяемой. Потому как названия пинов не соответствуют их номерам. Я же прикрепил скриншот, на котором ПЛИСа с такими пинами. Вот если на ней поперебрасывать только номера пинов, проверка останется только одна - загонять пинаут и компилить проект это ПЛИСины, пока все не сойдется...
А так конечно да, если сгналы совершенно разные и все пины испльзуются как IO - никаких проблем не будет.

Хоть убей, не могу понять, в чем трудности. Ну и что, что предопределены байт-группы, адреса и данные? Наоборот, проще рисовать УГО. Если есть несколько групп, то рисуется одно УГО на все гейты сразу и проводится своп гейтов (функций). Номера пинов меняются, но никак не ухудшают читаемость схемы, т.к. гейты эквивалентны. Обычный подход...

Скриншот я смотрел-смотрел, и опять не понял... Если это исходное состояние такое, то тут, имхо, что есть своп, что нет, все равно ничего ничему не соответствует. Вот первый же пин IO_L36_M3DQ9_3. На него подключен нет SRAM_Q<19>. Где тут соответствие? Общая только буква Q. Как это проверять?

Ну и вообще, зачем проверять распиновку после свопа? Если своп правильно разрешен (для действительно эквивалентных пинов), то остальное делает САПР. У меня ни разу не было каких либо ошибок. Да, мне немного не по себе после свопа, и я проверяю вручную 1-2 пина, но не более. Все-то зачем проверять?

Я спросил про это все просто потому, что у плисин обычно много ног, и получается сильно длинная строка PINSWAP. Думал, может, есть получше методы...

А в DxD тоже можно спокойно именовать цепи из файлов, списков и т.п. Я на нем и остановился в свое время из-за того, что посчитал наиболее продвинутым. Правда, в HDL недолго поработал, ни одного проекта живьем так в нем и не сделал.

Ну беда... видимо не смог объяснить. На скрине пример ПЛИСы с многофункциональными пинами. Подключенный там интерфейс в данном случае значения не имеет, просто этот дизайн под рукой был.
Эээ... не понял - что значит Ваше "...остальное делает САПР"? Надеюсь не автосвап имелся в виду???
А проблем со строками PINSWAP в Кэйденс нет по определению, ввиду отсутствия таковых Все задается в таблице распиновки, в Парт Девелопере. Как оно записано в файле chips посмотреть можно, только незачем.

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


Остальное - это сама замена номеров пинов в схеме после свопинга в плате. Не автосвап, конечно, нет.

Дело в том, что реально невозможно полностью прописать ограничения по свопу пинов. Смотрите, один банк:
- все пины IO - одна эквивалентность
- те же пины разбиты по парам _P _N - замена диффпар(худший случай менять пару на два пина с одиночными сигналами) - какая тут эквивалентность должна быть?
- те же пины поддерживают DDR - байт группы, стробы, клоки, адреса - третий вариант свапа?
- те же пины QDR - байт группы, клоки, адреса(без стробов) - наверно тот же третий, хотя не факт
- те же пины, глобальные входы/выходы клоков - четвертый?

А вот теперь вопрос - как все варианты собрать вместе, и как после свапа на схеме увидеть, что сигналы хотя бы примерно попали на нужные пины, если точно известно, что имя пина, в котором обозначены варианты его функциональности, с номером не совпадает? Теоретически можно прописать уникальную эквивалентность для данного проекта, НО! - приписывать ее нужно УЖЕ зная какой сигнал куда будет подключен В общем очень непростой на самом деле вопрос.

Я поэтому использую генерацию УГО с помощью IOD. Это, в общем-то, и есть прописывание уникальных настроек свопа для проекта. Если та же плисина будет применяться в другом проекте, то для нее будет создано свое УГО, в котором прописаны те самые строки PINSWAP.
В общем, я это делаю на уровне УГО, а как там в нативном варианте с DE-HDL не знаю, конечно. Наверно, там тоже можно что-то подобное найти...
И таких компонентов с разными УГО у меня много, причем есть не только плисины. Бывает, что и простые буферы какие-нибудь удобно то так, то эдак рисовать в зависимости от проекта, и PINSWAP на каждом УГО разный. Соответствие компонента и УГО ведется в базе данных, а не во встроенных бибилиотекарях, поэтому проблем с этим нет. Вот как-то так решена задача...

Да создавать уникальные компоненты со своим свапом под каждый проект не проблема. Равно как и любое кол-во УГО, все это поддерживается. Ну время разве что на это уходит...
Но проблемы прописывания свопа по уже известной распиновке это не решает.