[AlexZabr 0]

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

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

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

 

Ну да, не могу не согласиться...

[dxp 32]

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

Имхо, не следует сравнивать средства моделирования и верификации со средствами аппаратной отладки - это в достаточной степени перпендикулярные вещи. Да, потроха ПЛИС зачастую можно в достаточной степени отладить в симуляторе, но вот при запуске системы, состоящей из ПЛИС, процессора, памяти, АЦП и т.д., могут возникать нюансы, которые при моделировании просто не воспроизвести хотя бы потому, что реально возникающая ситуация может оказаться весьма неожиданной, вследствие чего и в голову не придет ее моделировать в симуляторе. Средства аппаратной отладки позволяют отлавливать подобные моменты и производить поиск решения "зряче", а не на ощупь.

 

Да вы и сами писали, что много пользовались ChipScop'ом - наверное, не от безделья. :)

 

Т.ч. средства разные нужны, средства разные важны.

[makc 192]

Имхо, не следует сравнивать средства моделирования и верификации со средствами аппаратной отладки - это в достаточной степени перпендикулярные вещи. Да, потроха ПЛИС зачастую можно в достаточной степени отладить в симуляторе, но вот при запуске системы, состоящей из ПЛИС, процессора, памяти, АЦП и т.д., могут возникать нюансы, которые при моделировании просто не воспроизвести хотя бы потому, что реально возникающая ситуация может оказаться весьма неожиданной, вследствие чего и в голову не придет ее моделировать в симуляторе. Средства аппаратной отладки позволяют отлавливать подобные моменты и производить поиск решения "зряче", а не на ощупь.

 

Я это понимаю, но говорил о другой ситуации, при которой некто хочет отлаживать свой проект в ПЛИС с помощью аппаратного отладчика Identify вместо того, чтобы верифицировать его с помощью моделирования. Я не отрицаю, что аппаратный отладчик (логический анализатор, осциллограф и т.п.) может понадобиться в процессе запуска опытных образцов, поскольку могут возникнуть "непонятные" проблемы обусловленные нетипичным поведением отдельных узлов устройства. Но при правильном проектировании подобные проблемы должны возникать лишь на уровне межузловых интерфейсов, для отладки которых и нужны упомянутые средства. И установить подобные проблемы обычно не сложно по косвенным признакам.

 

Да вы и сами писали, что много пользовались ChipScop'ом - наверное, не от безделья. :)

 

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

Мне он пригодился, например, когда на начальных фазах инициализации PCI-моста PLX 9052 (PLX 9030) BIOS одной нетипичной системы отказывался инициализировать EBAR ядра. В этом случае ChipScope использовался как логический анализатор (я ставил в параллельный слот макет со Spartan-3), с помощью которого я наблюдал транзакции на шине PCI. С помощью ChipScope удалось установить, что в том BIOS'e была ошибка, в результате которой он пытался инициализировать EBAR как BAR для IO space в случае, если в младшем разряде EBAR была 1 (эта единица была предписана документацией на мост и была, как выяснилось, не обязательна).

 

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

 

Т.ч. средства разные нужны, средства разные важны.

 

С этим я не спорю. :)

Чтобы иначе пояснить то, о чем я говорю, приведу цитату из книги Linux Device Drivers:

Многие читатели могут быть удивлены, что ядро (Linux) не имеет более продвинутого специального отладчика. Ответ на этот вопрос очень прост – Линус (создатель Linux) не доверяет интерактивным отладчикам. Он боится, что это приведет к исправлению симптомов, а не ошибок, которые их вызывают. Поэтому, в ядре нет встроенного отладчика.

 

Так и здесь - интерактивный отладчик (Identify) может способствовать исправлению симптомов, а не поиску причин (в силу ограниченности своих возможностей). В то время как развитые средства моделирования и тестирования наоборот - способствуют поиску причин, а не исправлению симптомов (при правильном наборе test cases). К тому же Identify может и не поймать определенные ошибки, т.к. практическое тестирование (в железе) обычно не позволяет с легкостью обеспечить все возможные воздействия на тестируемое устройство. Для этого нужно моделирование и развитые тестовые наборы входных воздействий.

 

 

Имхо, не следует сравнивать средства моделирования и верификации со средствами аппаратной отладки - это в достаточной степени перпендикулярные вещи. Да, потроха ПЛИС зачастую можно в достаточной степени отладить в симуляторе, но вот при запуске системы, состоящей из ПЛИС, процессора, памяти, АЦП и т.д., могут возникать нюансы, которые при моделировании просто не воспроизвести хотя бы потому, что реально возникающая ситуация может оказаться весьма неожиданной, вследствие чего и в голову не придет ее моделировать в симуляторе. Средства аппаратной отладки позволяют отлавливать подобные моменты и производить поиск решения "зряче", а не на ощупь.

 

Я это понимаю, но говорил о другой ситуации, при которой некто хочет отлаживать свой проект в ПЛИС с помощью аппаратного отладчика Identify вместо того, чтобы верифицировать его с помощью моделирования. Я не отрицаю, что аппаратный отладчик (логический анализатор, осциллограф и т.п.) может понадобиться в процессе запуска опытных образцов, поскольку могут возникнуть "непонятные" проблемы обусловленные нетипичным поведением отдельных узлов устройства. Но при правильном проектировании подобные проблемы должны возникать лишь на уровне межузловых интерфейсов, для отладки которых и нужны упомянутые средства. И установить подобные проблемы обычно не сложно по косвенным признакам.

 

Да вы и сами писали, что много пользовались ChipScop'ом - наверное, не от безделья. :)

 

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

Мне он пригодился, например, когда на начальных фазах инициализации PCI-моста PLX 9052 (PLX 9030) BIOS одной нетипичной системы отказывался инициализировать EBAR ядра. В этом случае ChipScope использовался как логический анализатор (я ставил в параллельный слот макет со Spartan-3), с помощью которого я наблюдал транзакции на шине PCI. С помощью ChipScope удалось установить, что в том BIOS'e была ошибка, в результате которой он пытался инициализировать EBAR как BAR для IO space в случае, если в младшем разряде EBAR была 1 (эта единица была предписана документацией на мост и была, как выяснилось, не обязательна).

 

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

 

Т.ч. средства разные нужны, средства разные важны.

 

С этим я не спорю. :)

Чтобы иначе пояснить то, о чем я говорю, приведу цитату из книги Linux Device Drivers:

Многие читатели могут быть удивлены, что ядро (Linux) не имеет более продвинутого специального отладчика. Ответ на этот вопрос очень прост – Линус (создатель Linux) не доверяет интерактивным отладчикам. Он боится, что это приведет к исправлению симптомов, а не ошибок, которые их вызывают. Поэтому, в ядре нет встроенного отладчика.

 

Так и здесь - интерактивный отладчик (Identify) может способствовать исправлению симптомов, а не поиску причин (в силу ограниченности своих возможностей). В то время как развитые средства моделирования и тестирования наоборот - способствуют поиску причин, а не исправлению симптомов (при правильном наборе test cases). К тому же Identify может и не поймать определенные ошибки, т.к. практическое тестирование (в железе) обычно не позволяет с легкостью обеспечить все возможные воздействия на тестируемое устройство. Для этого нужно моделирование и развитые тестовые наборы входных воздействий.

[a123-flex 0]

Так и здесь - интерактивный отладчик (Identify) может способствовать исправлению симптомов, а не поиску причин (в силу ограниченности своих возможностей). В то время как развитые средства моделирования и тестирования наоборот - способствуют поиску причин, а не исправлению симптомов (при правильном наборе test cases). К тому же Identify может и не поймать определенные ошибки, т.к. практическое тестирование (в железе) обычно не позволяет с легкостью обеспечить все возможные воздействия на тестируемое устройство. Для этого нужно моделирование и развитые тестовые наборы входных воздействий.

 

Судя по Вашим постам, разрабатываемые Вами системы сложнее моих.

Тем более не могу понять Вашего предложения о "развитых тестовых наборах".

Я для своей системы описывал бы все возможные тесты на протяжении нескольких лет, думаю.

[makc 192]

Судя по Вашим постам, разрабатываемые Вами системы сложнее моих.

Тем более не могу понять Вашего предложения о "развитых тестовых наборах".

 

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

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

 

Я для своей системы описывал бы все возможные тесты на протяжении нескольких лет, думаю.

 

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

[a123-flex 0]

Я это понимаю, но говорил о другой ситуации, при которой некто хочет отлаживать свой проект в ПЛИС с помощью аппаратного отладчика Identify вместо того, чтобы верифицировать его с помощью моделирования.

на кого ето Вы намекаете ? :rolleyes:

 

На самом деле я и сам пришел к мысли о необходимости полного покрытия тестами проекта. Фрагмент инструкции для студентов- неделю назад написал:

4. Каждый проект отлаживается 2 раза - первый раз в идеальной модели, второй раз в железе.

5. Каждая новая feature проекта должна быть проверена на идеальной модели.

 

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

 

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

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

 

Но "загадочные эффекты" иногда обусловлены различием в модели для моделирования и синтеза. В частности Xil. Тупое фифо ведет себя по разному в модели и синтезированное. И как отладить такое на модели ?

Identify я ценю за то, что /для моих систем/ он дает возможность видеть ВСЕ в любой интересующий момент. Пусть с пятой сборки, но проект на 300-500 сигналов в реальном времени можно просмотреть.

 

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

 

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

 

Я подозреваю, что Ваше очевидное превосходство в методологии разработки связано просто с гораздо большим, чем у меня, опытом. Cappuccino занимается разработкой 7 лет, и Ваши слова ему бальзам. Ето означает, что /если исходить из предположения что скорость познания его и Ваша не очень сильно различается/ что и Вы имеете опыт существенно больший моего. Мой Hello word светодиод замигал 4 года назад))

[dvladim 0]

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

 

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

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

Например,у Кэйденса в ncverilog-е есть поддержка.

 

Но "загадочные эффекты" иногда обусловлены различием в модели для моделирования и синтеза. В частности Xil. Тупое фифо ведет себя по разному в модели и синтезированное. И как отладить такое на модели ?

Значит модель не адекватна. Но не нужно считать что моделирование в этом случае непригодно.

[andrew_b 14]

Но "загадочные эффекты" иногда обусловлены различием в модели для моделирования и синтеза. В частности Xil. Тупое фифо ведет себя по разному в модели и синтезированное. И как отладить такое на модели ?

В таких случаях ngc, полученный в Coregen, я перегоняю в низкоуровневый vhdl с помощью netgen, и этот нетлист использую при моделировании.

[makc 192]

на кого ето Вы намекаете ? :rolleyes:

 

Ни на кого конкретно. В мире много разных людей...

 

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

 

ModelSim/QuestaSim. В них есть такая возможность. В официальной поставке она требует отдельной feature. Но если брать полную лицензию, то проблем не будет. ;)

 

 

Но "загадочные эффекты" иногда обусловлены различием в модели для моделирования и синтеза. В частности Xil. Тупое фифо ведет себя по разному в модели и синтезированное. И как отладить такое на модели ?

 

Моделировать не исходный VHDL/Verilog проект, а Post-Synthesis нетлист, оттранслированный обратно в VHDL/Verilog. Да, это не очень удобно, но это работает и дает возможность оценить корректность работы схемы на реальном железе (в терминах базовых элементов ПЛИС). Вы, конечно, можете сказать, что ПЛИС может быть неисправна и гипотетический проект может начать некорректно работать на этом конкретном кристалле. Но и в этом случае Identify/Chipscope не не помогут. Т.к. они тоже могут начать дурить.

 

Identify я ценю за то, что /для моих систем/ он дает возможность видеть ВСЕ в любой интересующий момент. Пусть с пятой сборки, но проект на 300-500 сигналов в реальном времени можно просмотреть.

 

Вы пробовали подсчитать, сколько времени уходит на эти пересборки и итерации отладки?

 

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

 

См. выше.

 

Я подозреваю, что Ваше очевидное превосходство в методологии разработки связано просто с гораздо большим, чем у меня, опытом. Cappuccino занимается разработкой 7 лет, и Ваши слова ему бальзам. Ето означает, что /если исходить из предположения что скорость познания его и Ваша не очень сильно различается/ что и Вы имеете опыт существенно больший моего. Мой Hello word светодиод замигал 4 года назад))

 

Я этим занимаюсь уже лет 8-9. :)

[des00 25]

Я подозреваю, что Ваше очевидное превосходство в методологии разработки связано просто с гораздо большим, чем у меня, опытом. Cappuccino занимается разработкой 7 лет, и Ваши слова ему бальзам. Ето означает, что /если исходить из предположения что скорость познания его и Ваша не очень сильно различается/ что и Вы имеете опыт существенно больший моего. Мой Hello word светодиод замигал 4 года назад))

далеко не аргумент, я освоил симуляторы с покрытием кода на 2 ой год плисоводства. Так что всё зависит от целей и желания, кому то осцилл, лоджик аналайзер, сигнал тап, а кто то в симуляторе всё косяки правит, а железо с "полпинка" работает %)

[a123-flex 0]

далеко не аргумент, я освоил симуляторы с покрытием кода на 2 ой год плисоводства. Так что всё зависит от целей и желания, кому то осцилл, лоджик аналайзер, сигнал тап, а кто то в симуляторе всё косяки правит, а железо с "полпинка" работает %)

 

 

круто быть гением :rolleyes:

 

но не всем так повезло в этой жизни(

 

ModelSim/QuestaSim. В них есть такая возможность. В официальной поставке она требует отдельной feature. Но если брать полную лицензию, то проблем не будет. ;)

 

премного благодарен. Щаз дикая запара, чуть откидаюсь и займусь скиллом... буду задавать много дурацких вопросов)))

 

 

Моделировать не исходный VHDL/Verilog проект, а Post-Synthesis нетлист, оттранслированный обратно в VHDL/Verilog. Да, это не очень удобно, но это работает и дает возможность оценить корректность работы схемы на реальном железе (в терминах базовых элементов ПЛИС).

 

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

[des00 25]

круто быть гением :rolleyes:

вы мне льстите %)

но не всем так повезло в этой жизни(

никакого везения, просто посчитайте потерю денег на аппаратную отладку и на изучение симулятора и вычтите одно из другого %)