EE2007 и утилиты экспорта в HKP, Есть ли в EE2007 утилиты LMCDB2HKP, PartsDB2HKP, CellDB2HKP, PadstackD Опции

[cioma]

Подскажите, пожалуйста, есть ли в 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

[avesat]

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

CompTypeDB2HKP.exe
HKP2CompTypeDB.exe

[cioma]

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

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

[Vadim]

Делаю скрипты (Perl) для верификации и преобразования данных central library...

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

[cioma]

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

[Vadim]

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

[cioma]

Ну, я за эту всю автоматизацию только взялся, вот дописываю скрипт для экспорта всей 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 часов.

[AlexN]

Ну, я за эту всю автоматизацию только взялся, вот дописываю скрипт для экспорта всей 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 тоже сам.

[timon_by]

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

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

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

[Vadim]

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

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

[avesat]

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

[cioma]

до чего же универсален российский инженер.

Беларуский

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

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

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

[AlexN]

Беларуский

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

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

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

[Vadim]

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

А че за утилитки (скрипты) вы пишите?

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

Есть стандартный набор API под EE ?

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

Или сгенеренный текстовый файл под свои требования переделываете?

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

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

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

[avesat]

... ху ис API.

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

[cioma]

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

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

[Vadim]

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

уникальным типоразмером (т.е. уникальной комбинацией symbol, cell, pinmapping)

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

[cioma]

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

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

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

[Vadim]

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

[fill]

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

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

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

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

[cioma]

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

[fill]

Сейчас главное чтобы Cadence не купил Mentor

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

[atlantic]

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

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

[Vadim]

...все эти статьи слишком умные, суть понять сложно.

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

[cioma]

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

[fill]

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



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



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

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

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

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

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