[SM 0]

Симуляцию во многих случаях никакими осциллографами и логическими анализаторами не заменишь в силу физических ограничений.

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

[Golikov 0]

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

 

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

[ViKo 1]

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

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

[SM 0]

по ощущениям чуть ли не больше половины модулей внутренних,

 

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

 

Вот, например, схема из головы: DDR2 RAM -> буфер предвыборки -> PCI интерфейс. Схема предвыборки, вроде бы как, наружу из ПЛИС сама и не выходит, но при всем том полностью и всеобъемлюще тестируется через PCI шину программно, и тест этого буфера по любому необходим при выходном контроле (мало ли, в ПЛИС ячейка битая, убилась от нагрева при пайке). В общем и целом, для таких тестов могут предусматриваться всякие там внутренние loopback-и, тест-режимы и т.п., которые позволяют протестировать этот кусок железа как и при разработке, так и при выходном контроле, и их, опять же, по любому делать, чтобы отсеивать подбитые ПЛИСы, производить ремонт быстро и эффективно... Например, для приведенной схемы, я бы добавил пару loopback-ов, на границе PCI и предвыборки, и на границе предвыборки и DDR, чтобы, если что, определить при выходном контроле после монтажа или ремонте, кто неисправен, память DDR или ПЛИС (конкретно - какую микруху поменять), а при разработке - просто помогло бы быстрее все оттестить.

 

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

[alexadmin 0]

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

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

[Jackov 1]

direct instantiation

Берём вот эту книжку и сравниваем.

Нельзя сказать что разница колоссальна, но тем не менее она есть.

 

 

[SM 0]

Берём вот эту книжку и сравниваем.

 

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

 

http://electronix.ru/forum/index.php?showt...t&p=1234513

http://electronix.ru/forum/index.php?showt...t&p=1234534

[fpgaz 0]

Но таких случаев один на сотню

Количество случаев на сотню зависит от специфики производства и цены возможной ошибки. :rolleyes:

 

тоже самое можно создать с меньшими трудозатратами программными воздействиями на железо из тест-софта

Вы имеете в виду тест-софт для АРМ и стендов?

 

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

Для этих целей у Xilinx есть ChipScope, а у Altera есть SignalTap. При отладке по JTAG можно получить кучу удобных плюшек и исходники не засоряются тестовыми выводами.

 

Если внутренний модуль недосягаем для внешних воздействий вообще, и не влияет на выходы, то зачем он нужен?

Да хотя бы фильтр какой-нибудь. Нужно принять данные от АЦП по SPI, разложить их по полочкам и скормить фильтру.

Фильтр выдает данные, которые нужно отдать модулю контролера какого-то другого интерфейса.

Вот чтобы не пихать интерфейсную часть в модуль фильтра сделано разделение.

Добраться до этого модуля можно элементарно, если ноги свободные есть. Но нужно ли?

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

 

 

[ViKo 1]

Для этих целей у Xilinx есть ChipScope, а у Altera есть SignalTap. При отладке по JTAG можно получить кучу удобных плюшек и исходники не засоряются тестовыми выводами.

Конечно. Только я JTAG не использую. Микроконтроллером записываю конфигурацию, по SPI.

[SM 0]

Вы имеете в виду тест-софт для АРМ и стендов?

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

 

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

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

[Golikov 0]

Ну да,...

 

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

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

 

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

 

А чип скоп мне не очень понравился, долго, слишком долго его вставлять, подключать, настраивать. В этом случае реально легче на ножку сигнал вывести и осциллографом тыкнуть. Но иногда он лучше осциллографа, конечно,...

[fpgaz 0]

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

Штука в том, что все зависит от специфики производства и наличия нужного оборудования.

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

Похоже, что у вас там c ASIC производство работает. :)

А ПО для тестирования на чем пишите?

 

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

То есть имеется возможность написать сколь угодно сложный тест для тест-стендов и покрыть весь функционал?

Изменено 10 февраля, 2014 пользователем FPGAz

[SM 0]

Похоже, что у вас там c ASIC производство работает. :)

К сожалению, последний ASIC давно делался...

 

А ПО для тестирование на чем пишите?

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

 

Для отладки пилотных образцов у меня не было под рукой таких инструментов

А какой там такой мегаинструмент нужен? Если в схеме с ПЛИС есть интерфейс к PC, то весь тест можно оформить через него просто софтом на PC. Иначе, можно сделать тест-порт какой то.

 

То есть имеется возможность написать сколь угодно сложный тест для тест-стендов и покрыть весь функционал?

Ну весь, не весь, но получается. Он ведь сам по себе такой получается, так как в процессе создания недр ПЛИСы, тест наполняется различными кусками, тестирующими разные модули ПЛИС, и в конце разработки получается и тест, покрывающий если не всю ее функциональность, то почти всю. В этом и прелесть такого тестирования "в живую", а не моделирования, так как на выходе получаем и ПЛИС, и тест, работающий с реальным железом, останется только стенд сделать под этот тест, а это, в 95% случаев просто PC, ну или сгенерирвоать .vcd-шку для стандартной тест-системы, если речь об ASIC.

[Pavia 0]

А кто какими симуляторами пользуется? И как ведет разработку? тестирование?

А то что-то квартус штука не торопливая особенно на атоме.

[SM 0]

А кто какими симуляторами пользуется? И как ведет разработку? тестирование?

 

Симуляторы - Modelsim, Synopsys VCS, нужны раз-два в году (если именно FPGA)

 

Разработку.... Ну как - пишу, синтезирую, гружу в ПЛИС, пишу/правлю тест, тестирую, пишу/правлю глюки, синтезирую,.... и так пока тест полностью не пройдет в том объеме, в котором считаю что тестирование необходимо.

 

Тестирование - использую какой либо интерфейс между PC и ПЛИС, от простого UART или JTAG, до PCI/PCIe/USB, смотря что внутри ПЛИС, и что за устрйоство вообще. Так как, пока что, всегда какой-то интерфейс к PC всегда в проектах был. Если интерфейса нет, то, как правило, процессор был внутри ПЛИС/ASIC, и тест делался его средствами, либо разрабатывалось какое-то тест-окружение, которое в последствии становилось тест-девайсом для приемки готовых устройств. В общем, на выходе после разработки, получалось две вещи - сама разработка и методика и система тестирования этого устройства для контроля, наладки и ремонта.

 

Симуляторы применяю или в сверхтяжелых случаях, когда уже совсем в тупик пришел с in system отладкой, или для генерации тест-векторов для тест-систем, но это уже совсем особые случаи для выходного контроля ASIC, собственно для FPGA такого пока не делалось, да и не предвидится.