Jump to content

    

Recommended Posts

имхо, что-то наподобие ChipScope от Xilinx - т.е. лазить внутри чипа и вытаскивать сигналы и подавать воздействия напрямую в чип

 

Identify software reduces your hardware debug time by providing an easy and fast RTL-based debug environment. For FPGA design or ASIC prototyping, Identify software provides the quickest way to find bugs in your hardware.

 

http://www.synplicity.com/products/identify/

Share this post


Link to post
Share on other sites
имхо, что-то наподобие ChipScope от Xilinx - т.е. лазить внутри чипа и вытаскивать сигналы и подавать воздействия напрямую в чип

 

Identify software reduces your hardware debug time by providing an easy and fast RTL-based debug environment. For FPGA design or ASIC prototyping, Identify software provides the quickest way to find bugs in your hardware.

 

http://www.synplicity.com/products/identify/

 

Да, интерено или оно действительно так полезн в реалной работе....

Кто-нить с этим работает ?

Share this post


Link to post
Share on other sites

ChipScope я много использовал как встроенный в ПЛИС логический анализатор, который может помочь в анализе работы ПЛИС при неизвестных априори входных воздействиях. Что же касается Identify - это средство более высокого уровня, которое позволяет отлаживать код проекта, ставить breakpointы и т.п. Но у меня пока такой надобности не возникало, поэтому вполне достаточно было ChipScope.

Share this post


Link to post
Share on other sites

Приходилось пользоваться Identify. Самым значительным преимуществом Identify, по сравнению со средствами подобными ChipScope, является то, что анализатор работает непосредственно с исходным кодом, то есть вся иерархия, сигналы и т.п. представлены в оригинальном виде. Средства, подобные ChipScope, работают с синтезированным "нетлистом", что зачастую очень затрудняет поиск нужных сигналов. Правда, если использовать Identify, то в качестве синтезатора придется использовать Synplify.

Share this post


Link to post
Share on other sites
Afair, нет. У них другая специализация...

 

Другая специализация ? В смысле ?

Они ведь идут лоб в лоб с Synplify со своим Precision..значит вроде ежели это предлагается Synplify значит и Ментор должны стараться предложить нечто подобное в своем Precision...

Share this post


Link to post
Share on other sites
а у Менторов подобный аналог есть?

 

На данный момент мне не известно средств других производителей подобных Synplicity Identify. Когда занимался этим вопросом, то было пару предложений, но их качество значительно уступало Identify. Возможно сейчас что-то и сдвинулось с места. Со стороны MG таких предложений не встречал и о планах разработки такого средства не слышал...

Share this post


Link to post
Share on other sites
Другая специализация ? В смысле ?

Они ведь идут лоб в лоб с Synplify со своим Precision..значит вроде ежели это предлагается Synplify значит и Ментор должны стараться предложить нечто подобное в своем Precision...

 

В том смысле, что менторы ориентированы на средства разработки, а не на средства отладки в железе. Поэтому есть аналогичных Synplify продукт Precision, а вот аналога Identify - нет.

Share this post


Link to post
Share on other sites
В том смысле, что менторы ориентированы на средства разработки, а не на средства отладки в железе. Поэтому есть аналогичных Synplify продукт Precision, а вот аналога Identify - нет.

 

Хмм, я всегда считал что средства разработки под железо должны сопровождаться средствами отладки...

Share this post


Link to post
Share on other sites
Хмм, я всегда считал что средства разработки под железо должны сопровождаться средствами отладки...

 

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

Share this post


Link to post
Share on other sites
Проблема отладки в железе может и не встать в полный рост, если выполнять проектирование с соблюдением всех требований и проводить моделирование на этапе разработки. Поэтому менторы и ориентируются на средства разработки и моделирования, что более правильно, чем ловить блох в неработающем на железе проекте и тратить время и деньги на перепроектирование (если повезло найти истинную причину возникших проблем).

+1

прям бальзам на душу :)

Share this post


Link to post
Share on other sites
Проблема отладки в железе может и не встать в полный рост, если выполнять проектирование с соблюдением всех требований и проводить моделирование на этапе разработки. Поэтому менторы и ориентируются на средства разработки и моделирования, что более правильно, чем ловить блох в неработающем на железе проекте и тратить время и деньги на перепроектирование (если повезло найти истинную причину возникших проблем).

 

 

Ну это кажется в рамках утопии :) , проэктировщики десятки лет работают на созданием продуктов, вкладываются несметные $$$ в разработки и ессно предпинимаются все доступные методы моделирования, расчетов и т.д...и все равно..очень редко когда серьезная разработка начинает работать с первого пуша. Всегда есть debug. А debug это отнюдь не ловля блох, это весьма серьезный процесс.

Какой-бы ни был серьезен процесс разработки, симулирования и т.д., все-равно самолеты падают, электорстанции взрываются и т.д. и т.п....

Предоставление серьезных средств debugа есть очень весомый аргумент (это в общем, не обязательно касательно обсуждаемой темы с Synplify).

 

вы несколько мешаете понятие отладки и тестирования

 

Возможно я путаю русскоязычные термины..сорри ежели так, я не силен в русскоязычном техноческом языке.. :) , либо я не понял marcа.

Я имел ввиду моделирование со имплементации в hardware и соответственно debugging (он-же bring-up) спроэктированного hardware. IMHO, какое-бы ни было моделирование, всегда есть bring-up который включает обычно и debugging, а значит не приходится недооценивать debugging tools.

Конкретно в плане FPGA проэктов мне трудно что-то утверждать ибо пока в начале своей FPGA "карьеры", но 2 моих предыдущих места работы были в фирмах проэктирующих комплексные, весьма многофункциональные ASICи. Ессно фирмы работали с передовыми tools в проэктировании, моделировании и т.д. и т.п., много инженер-часов вкладывается в разработку чипа (занимает год-полтора а то и два), и все равно я не помню ни одного поколения чипов там (4 поколения на моем веку там) где бы все работало с первого запуска. Всегда есть проблемы, всегда нужно их debugить, ессно в конце концов рабочая версия идет в mass production. Я там не был в группах разработки, я был в backend, т.е. там где получают первые "ново-испеченные" образцы и начинают их гонять, выявлять проблемы...

Share this post


Link to post
Share on other sites
Я имел ввиду моделирование со имплементации в hardware и соответственно debugging (он-же bring-up) спроэктированного hardware. IMHO, какое-бы ни было моделирование, всегда есть bring-up который включает обычно и debugging, а значит не приходится недооценивать debugging tools.

Конкретно в плане FPGA проэктов мне трудно что-то утверждать ибо пока в начале своей FPGA "карьеры", но 2 моих предыдущих места работы были в фирмах проэктирующих комплексные, весьма многофункциональные ASICи. Ессно фирмы работали с передовыми tools в проэктировании, моделировании и т.д. и т.п., много инженер-часов вкладывается в разработку чипа (занимает год-полтора а то и два), и все равно я не помню ни одного поколения чипов там (4 поколения на моем веку там) где бы все работало с первого запуска. Всегда есть проблемы, всегда нужно их debugить, ессно в конце концов рабочая версия идет в mass production. Я там не был в группах разработки, я был в backend, т.е. там где получают первые "ново-испеченные" образцы и начинают их гонять, выявлять проблемы...

ПЛИС (FPGA/PLD) - это гобридный продукт между Standard IC и ASIC. технология производства кремния как у Standard IC, разработка конечного продукта ближе к заказным схемам. из-за того что сам кристалл это Standard IC физические показатели детерминированы (вы можете расчитать время расспространиения сигнала от одной(любой) точки схемы до другой(любой) при нормальных условиях эксплуатации чипа с очень высокой - близкой к 100% - точностью - т.е. представить некоторую мат. модель высокой точности для всего семейства). поэтому вы можете произвести верификацию продукта не в полевых условиях (в полевых цена обнаруженной ошибки гораздо выше чем цена ошибки обнаруженной в модели) а в модельных, и провести отладку продукта ещё до его производства.

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

вот такая мысля

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this