Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

direct instantiation

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

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

 

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

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

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

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну да,...

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

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

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

Изменено пользователем FPGAz

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...