Подскажите, пожалуйста, есть ли в EE2007 такие утилиты для экспорта/импорта данных central library в/из HKP:

CellDB2HKP.exe
CompTypeDB2HKP.exe
JobPrefsDB2HKP.exe
LayoutDB2HKP.exe
LMCDB2HKP.exe
MaterialDB2HKP.exe
NetClassDB2HKP.exe
NetPropsDB2HKP.exe
PadstackDB2HKP.exe
PartsDB2HKP.exe

HKP2CellDB.exe
HKP2CompTypeDB.exe
HKP2JobPrefsDB.exe
HKP2LayoutDB.exe
HKP2LMCDB.exe
HKP2MaterialDB.exe
HKP2NetClassDB.exe
HKP2NetPropsDB.exe
HKP2PadstackDB.exe
HKP2PartsDB.exe

sorthkp.exe

есть, только не нашел

CompTypeDB2HKP.exe
HKP2CompTypeDB.exe

Спасибо, эти две вобщем-то и не нужны.

Делаю скрипты (Perl) для верификации и преобразования данных central library, так вот активно эти утилиты использую для экспорта всех данных в HKP, но хотел убедиться что и в EE2007 это будет работать

Если не секрет, почему Perl? Дело в том, что я сейчас пытаюсь изучать скриптовые языки, дык вот не знаю, на каком остановить свой выбор.

Потому что Perl заточен под обработку текста, что мне, собственно, и нужно (т.к. hkp - текстовый формат)
<конец оффтопика>

<продолжение оффтопика>
Не помню где вычитал, что впереди планеты всей в текстоизвращениях Python.
ЗЫ. А скриптик для массового создания компонентов-мелочевки - конденсаторов, резисторов 0805, 0603 ... случайно не писали?
<надеюсь, не конец оффтопика>

Ну, я за эту всю автоматизацию только взялся, вот дописываю скрипт для экспорта всей central library в отдельную папку. Т.е. например:
в output\lmc лежит hkp, сгенеренный из <central library>.lmc, в котором вся структура библиотеки
в output\pdb - лежат hkp разделов parts
в output\cel - hkp разделов cell
в output\psk - hkp padstack
в output\sym - скопированы символы из SymbolLibs\<symbol partition>\sym

т.е таким образом мы получаем все данные библиотеки, относящиеся к компонентам. А далее сделаю набор скриптов для верификации, экспорта и импорта этих данных.

Чтож до автоматизированного создания компонентов, то думаю что-то тоже будет. Тем более что в PCB Matrix LP Wizard V2008 обещают экспорт/импорт данных в xml, т.е. можно будет вбить в файл размеры кучи корпусов, скормить их Wizard'у и получить на выходе cell.hkp и padstack.hkp для Expedition.

Для создания символов и pinmapping компонентов с количеством ног от 4 до 4000 недавно начали использовать SymXpert, который также может экспортить данные в csv.

Так что, надеюсь, постепенно буду все это дело реализовывать, и скрипты после тестов также буду выкладывать.

По поводу Perl и Python:
http://en.wikipedia.org/wiki/Perl
http://en.wikipedia.org/wiki/Python_(programming_language)
http://www.michurin.com.ru/python-vs-perl.shtml

ИМХО Python больше для универсального, общего использования, а Perl создан для программ где "90% - это обработка текстов, а 10% - все остальное"

Я, имея хорошую базу в С, освоил Perl на достаточном мне уровне за 16 часов.

до чего же универсален российский инженер. он не только сам рисует схемы, ведет библиотеки, разводит платы, сам же программирует свой девайс, и еще и дописывает автоматизацию к тому пакету, на котором работает! Наверное еще и подготовку производства в CAM тоже сам.

Как говаривал Кот Матроскин "... я и на машинке вышивать умею"

Кто-нибудь пробовал писать на С/С++ утилиты для автоматизации?

Я давно уже задумал скрипт(программу?) для создания компонентов-рассыпухи, начал было даже писать на C++(заодно его осваивая), но погряз - хочется сделать хорошо, но на это уйдет много времени, и опыта программирования почти никакого(кроме HDL), осваивать нужно, да основная работа мешает Сейчас опять - очередной приступ, щупаю Python, вроде то, что нужно, вроде будет легче, чем с C++.

А че за утилитки (скрипты) вы пишите? Есть стандартный набор API под EE ? Или сгенеренный текстовый файл под свои требования переделываете?

Беларуский

Просто на данном этапе исторического развития моя задача - по максимуму автоматизировать процесс создания и верификации библиотек, т.к. мы не только делаем их для себя, но и для заказчиков, соответственно качество - превыше всего (а то из-за двух перепутанных пинов можно потерять миллионы евро)



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

прошу прощения, не обратил внимания



хорошие обороты у Вас, беларусских инженеров!

Непонятно, к кому вопрос. На всякий случай тоже отвечу.

Для Expedition еще не писал, но планирую. Типа берем даташит, например, на конденсаторы 0805 какой-либо серии какой-либо фирмы, и создаем текстовый файл в формате Part Number - Емкость, указывам общие для всех параметры, например Tolerance, Voltage Rating. Запускаем скрипт, и целая туча конденсаторов с одинаковыми Tolerance, Voltage Rating мгновенно готова к употреблению. А то надоело врукопашную.

Мне стыдно, но я не в курсе, ху ис API.

Тоже дело. При работе с библиотеками править текстовые файлы и импортировать в pdb зачастую удобнее, чем врукопашную заполнять таблицы в глючном Part Editor.


К сожалению, не у всех

http://en.wikipedia.org/wiki/API

Для этого используйте DxDatabook. В этом случае Part у Вас будет уникальным типоразмером (т.е. уникальной комбинацией symbol, cell, pinmapping), а все атрибуты, которые на типоразмер не влияют (value, tolerance etc) берутся из базы DxDatabook.

Во-первых, я в DC, а там не DxDatabook, а Part Manager. Во-вторых, Part Number мне нужен не

а такой, который в даташите изготовителя.

Тогда прошу прощения, про DC ничего сказать не могу.

Кстати, по поводу импорта/экспорта в ASCII, вот откуда появился мой изначальный вопрос:
http://forums.mugweb.org/showflat.php?Cat=...page=0#Post4407

Тут, наверное, вопрос к fill'у: собирается ли Ментор в будущих релизах полностью убрать импорт/экспорт ASCII или они отказались от этой страшной затеи?

Дык убрали уже. А потом в каком-то там окуре вернули в зад. Отказались, в общем. Наверное

Судя по тому, что ASCII был отключен только в одном 2007.1, а во всех последующих обновлениях (включая новый релиз 2007.2) ASCII работает в полном объеме, то волноваться уже нечего.

Спасибо, а то понаписал бы скриптов, а в новом релизе они бы оказались бесполезными. Сейчас главное чтобы Cadence не купил Mentor

Комментарий почему это вряд ли возможно
http://www.edadesignline.com/showArticle.j...cleID=208700069

fill не могли бы вы объяснить в несколько предложений, в чем там(Cadenсe vs. Mentor) фабула, а то все эти статьи слишком умные, суть понять сложно.
Спасибо.

Присоединяюсь. Они ведь еще и на английском

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

17 июня в ответ на предложение Cadence Ментор опубликовал пресс-релиз, в котором говорится, что совет директоров единогласно отклонил это предложение. Среди других причин указывается недостаточная стоимость предложения, возможное нарушение анти-трестовского законодательства с серьезными рисками для обеих компаний, стремление Ментора работать на рынке самостоятельно и др. причины.



Интересной деталью является то, что предложение Cadence последовало после того, как были опубликованы результаты по первому кварталу 2008 года, в соответствии с которыми оборот Cadence по сравнению с предыдущим кварталом упал почти на 40%. Соответственно по результатам первого квартала Synopsys вышел на первое место, опередив Cadence.



В результате этого предложения акции Ментора выросли на 20%.



Рассмотрены возможные плюсы\минусы слияния, что можно ожидать Cadenсe. Какие последствия.

Основная причина - сохранить потерянное первое место с некоторым запасом на некоторое время. Т.к. после слияния можно расчитывать на продажы Calibre (верификация ASIC), ExpeditionPCB+BoardStn и FPGA тракт - все это примерно 400млн. ежегодно, то выгода здесь только в сохранении первого места - время отыгривания вложений (1600млн.) слишком большое, слишком большие траты на содержание, дальнейшую совместную разработку и т.п.

Большая опасность нарваться на запреты монополизации рынка, большое ослабление финансовой безопасности компании и т.п. Короче в переспективе очень вероятно обратное отделение какого-то куска (такое не раз уже встречалось).