Sefo

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

Для работы с последовательностью состояний можно использовать Sequence Property. Начните с просмотра разделов 16.7-16.9 и 16.13 IEEE Standard for SystemVerilog. Хотя глава 16 посвящена Assertions, то что касается Sequence Property применимо и для Coverage - в главах по Assertions иногда даже в примерах разбираются одновременно assert property и cover property. Вообще, для вашего запроса я бы порекомендовал повесить на шину монитор, который бы классифицировал все, что на ней происходит и записывал в массив из n элементов по принципу FIFO. Состояние этого массива через каждые n транзакций можно использовать для расчета покрытия последовательностей команд. Можно также считать покрытие по состоянию массива после каждой транзакции - тогда получится скользящее окно (применимо оно к вашему случаю или нет решать Вам). Классификация существенно сокращает количество возможных комбинаций - редко когда действительно необходимо, чтобы, скажем, адрес "пробежал" абсолютно по всем возможным значениям. Например, адреса можно классифицировать относительно предыдущей транзакции как {EQUAL, NEAR, FAR}. Ваш монитор обнаружив очередную транзакцию анализирует ее относительно предыдущей и сохраняет для расчета покрытия ее классификацию. Код команды сохраняется как есть, а вместо адреса сохраняется только его классификация. Как только в массиве набралось заданное количество транзакций вызываете sample() для вашей covergroup. Чтобы все это корректно работало Вам нужно продумать классификацию происходящего на шине и правильно описать covergroup.

Классная идея! :a14:

Реализация БПФ на ПЛИС

Я не даром написал "...и, в частности, UVM". Раздел верификации я начну с простых вещей. UVM на третье - кому не надо/не интересно может пропустить. Если вообще никому не надо, то не стану разбирать вовсе. Верно подмечено - дело в цели. Цель - исключительно познакомить слушателей с UVM и разобраться с основными элементами инфраструктуры. Не более того. Именно для этой цели, я считаю, самым подходящим является самый простой сценарий. Как Вы написали "плюнуть а, дождаться результата, проверить с b". Для начала (а курс для начинающих) достаточно, как в известном анекдоте, просто знать как расшифровывается аббревиатура UVM, какого цвета учебник, ну и может быть понимать чем sequence отличается от sequencer :). Еще один важный, на мой взгляд, нюанс. К моменту верификации слушатели уже будут знать БПФ вдоль и поперек и это позволит сосредоточиться целиком на особенностях верификации. Если взять что-то другое то необходимо будет сначала разобраться с тем как это работает, а потом еще по ходу отвлекаться на то, чтобы понять (или объяснить) почему в этой точке у этого модуля вот именно такие диаграммы. Замечу, что БПФ это только на 50% математика (бабочка, да умножитель). Остальные 50% это управление - откуда данные взять, какие коэффициенты подать, куда результат сложить, куда и когда подавать управляющие сигналы чтобы все пришло в нужное место в нужном такте и т.д. На отладку управления всегда уходить больше времени т.к. если там есть ошибки, то их сложнее локализовать. Вырожденные случаи не в счет.

Давайте заменим БПФ на банальный коммутатор, на банальный UART или I2C или что-то еще. Что меняется? Объясните, пожалуйста, за счет чего происходит превращение микроскопа в молоток?

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

Вообще, UVM полезная штука и много где приминим. Если рассматривать мелкие модули БПФ, то там может и нет смысла применять UVM, но если брать модуль БПФ целиком, то UVM вполне пригоден. Я считаю, что современный инженер, все же, должен иметь представление о UVM и хотя бы раз его опробовать. Я не предполагаю углубляться в UVM, но просто продемонстрировать его, чтобы слушатели получили о UVM представление. Я с удовольствием, но я не представляю как это организовать технически. Мне нужно видеть аудиторию и иметь обратную связь непосредственно во время лекции. Если кто-то сможет взять на себя решение этого вопроса я буду ему очень благодарен. Математический аппарат входит в то, что я назвал теоретические основы преобразования Фурье. :) Я планирую поговорить с ЛЭТИ и Политехом. Может там выделят аудиторию. Видеозапись делать можно. Да.

Хочу прочитать курс лекций для тех кто начинает осваивать HLD, ПЛИС и ЦОС в Санкт-Петербурге. Думаю назначить цену в 200 руб за 90 минутную лекцию с одного слушателя. Краткий план следующий. Начать с теоретических основ преобразования Фурье. Рассмотреть математические и радиотехнические особенности, способы реализации. Разобрать вопросы связанные с использованием чисел с фиксированной точкой и реализацией вычислений. Потом взяться за основы SystemVerilog и вообще основы описания "железа" на языках HDL. Затем на примере реализации БПФ изучить SV углубленно. Далее займемся верификацией и, в частности, UVM. Завершить курс синтезом проекта для какой-нибудь из отладочных плат c ПЛИС фирмы Altera/Xilinx и научиться работать с программными продуктами Altera/Xilinx. Хочу оценить с помощью опроса есть ли нынче у начинающих инженеров потребность в таком курсе. Всем спасибо!

Попробуйте удалить Байт Бластер из системы следующим образом: 1) отключите все байт бластеры 2) переведите Device Manager в режим отображения абсолютно всех устройств, в том числе и отключенных как это описано на странице Microsoft http://support.microsoft.com/kb/315539/EN-US 3) удалите драйвера Бластеров, при этом винда должна спросить не хотите ли удалить файлы драйвера с диска - соглашайтесь :) - удалится не оригинал, а копия, которую винда сохраняет в своих "недрах" (образец диалогового окна, к сожалению, сейчас привести не могу) 4а) обновите состояние Device Manager и если драйвер остался, то повторите п. 3 (если в системе было установлено несколько версий драйвера, то при выполнении п. 3 удаляется только последняя и ее подменяет предыдущая версия, поэтому нужно проделать несколько итераций до полного удаления драйверов с диска) 4б) подключите бластер и если винда автоматом поставит драйвер, то повторите п. 3 (значит не все версии драйвера удалились. Для уверенности, что драйвера беруться из "недр" винды, а не из каталога Квартуса можно переименоват каталог Квартуса с драйверами на время чистки) P.S. Пока писал ситуация изменилась, но надеюсь эта инструкция все равно кому-нибудь пригодится :)

Лучше всего начать с теоретической части, чтобы понять что вообще такое БПФ. Например почитайте 6 и 10 главы из книжки Рабинера Л. и Гоулда Б. "Теория и применение цифровой обработки сигналов". В интернете ее легко найти. Важное замечание: там есть примеры аппаратной реализации БПФ, так вот их лучше пропустить т.к. для ПЛИС это адаптировать совершенно нецелесообразно. Сразу могу сказать, что какой-то особой специфики у ПЛИС для БПФ нет. Самая главная специфика ПЛИС в том, что можно нагенерировать параллельно работающих вычислителей столько в ПЛИС влезет. БПФ хорошо параллелизуется. Бабочка, это всего лишь базовый элемент из которого строится БПФ. Только 2-х и 4-х точечная бабочка вычисляется исключительно с помощью сложения и вычитания. Все остальные уже требуют умножителей. Выходы бабочки всегда подключены умножителям, которые умножают данные с бабочки на доворачивающие множители. Так что, если нужно вычислить БПФ с количеством точек не равным 2 или 4, то без умножителей вы не обойдетесь. DSP блоки позволяют повысить тактовую частоту т.к. умножитель на логических ячейках работает медленнее, чем умножитель в DSP. Некоторые вопросы реализации довольно подробно обсуждались в этой теме: Реализация БПФ на ПЛИС. Но читать ее лучше после Рабинера и Гоулда. До амплитуд еще далеко. Вы получаете проекции вектора на оси комплексной плоскости. чтобы получить амплитуду нужно вычислить квадратный корень из суммы квадратов этих проекций: sqrt( Re(Xn)^2 + Im(Xn)^2) Этот квадратный корень есть хорошая такая ложка дегтя в бочке с медом при реализации БПФ на ПЛИС в том случае, если нельзя обойтись просто суммами квадратов для анализа учитывая, что корень квадратный функция монотонная.

Кому интересно - в прицепе плагин для подсветки синтаксиса в Visual Studio 2012 - 2013. Кроме подсветки синтаксиса ничего больше не делает. Пользоваться можно свободно, разумеется, на свой страх и риск :) Плагин автоматически активируется при открытии в Visual Studio файлов со следующими расширениями: *.v, *.sv, *.svi, *.sva, *.svh Многострочные комментарии (с началом "/*" на одной строке и концом "*/" на другой) не поддерживаются - как комментарий будет помечена только первая строка. Еще выделяется несколько ключевых слов UVM. Если найдете ошибки, пишите - исправлю. Если нужно, чтобы плагин загружался для других расширений, пишите - добавлю. Кому интересна подсветка UVM, присылайте список (по одному слову в строке) - добавлю. Для архива MD5 - 11074f8f1b7b84baf00fbdf7d56c9e7d, SHA256 - cf742e9d394ab303a13f0347cec3877b9721a4b80fdb685ba7c5ac86191dea7a SV_Keyword_Highlight.rar

Увы, не поможет. Если проблемы с таймингом, то защититься невозможно - ошибки совершенно непредсказуемы в общем случае. А если и предсказуемы, то практически не поправимы. Ничего кроме устранения проблем с таймингом путем изменения Place & Route, дизайна (например, введение pipeline) или понижения тактовой частоты не поможет. 1) Автомат может оказаться не в том состоянии в самом начале - если не используется сигнал сброса и нет указаний синтезатору обеспечить строго определенное состояние триггеров этого автомата 2) Автомат может оказаться не в том состоянии если он неправильно описан. Все, что находится внутри case и влияет на состояние автомата, в конечном счете, преобразуется в некую комбинаторную логику. Выходом этой логики является значение следующего состояния автомата, которое защелкивается регистрами. Входами для этой логики являются: текущее значение состояния автомата + все сигналы, которые определяют направление перехода (управляющие сигналы). В общем случае, на выходе этой логики может появиться любая комбинация нулей и единиц. Если есть ошибки в описании автомата или "соседняя" логика формирования управляющих сигналов работает с ошибкой, то автомат может попасть как просто в неправильное состояние (т.е. определенное, но не то в которое он должен бы был перейти) так и в неопределенное (в вашем примере State получит, скажем значение 11). Если автомат попал в неопределенное состояние, то дальнейшие переходы будут определяться этой самой комбинаторной логикой, поэтому не зная что там точно насинтезировалось осмысленно предсказать поведение не удасться. "Чтобы продать что-нибудь ненужное, сначала надо купить что-нибудь ненужное, а у нас денег нет" :). Чтобы исправить ошибку ее надо сначала найти. Если ее найти и исправить, то код "восстановления" будет только лишнее место занимать т.к. ничего восстанавливать не потребуется т.к. ошибки не будет. Условия эксплуатации и воздействия, которые должен выдерживать прибор должны быть заранее определены. В рамках этих условий и воздействий нужно обеспечить надежность, стабильность и т.д. и методы обеспечения подбираются под эти условия и воздействия. Когда эти условия и воздейтвия будут выходить за допустимые рамки, то ваш автомат будет далеко не единственным местом сбоя. Подозреваю, что default следовал после всех возможных состояний. В этом случае экономии быть и не должно - доп. состояние требует доп. логики. Вы попробуйте объединить default с каким-нибудь "нейтральным" состоянием, типа IDLE. Вот тогда объем логики должен уменьшится.

А это потому, что конструкция SV, а Вы компилируете ваш файл как Verilog (что, в принципе, соответствует его расширению). :smile3046: Поменяйте настройки компиляции так, чтобы StatisticModule_v3_00.v ISE компилировал как SystemVerilog и будет Вам счастье. :) Дело в том, что конструкция должна быть именно size'( expression ) - т.е. последние скобки обязательны. Если size тоже выражение, то и его придется заключить в скобки.

Конструкция легальная. В ISE не пробовал, а Квартус не жалуется - правда желаемый результат выдает только с последними 2-мя вариантами. Покажите тестовый код и сообщение об ошибке - может действительно где-нибудь ошибка случайно вышла...

Теоретически, должна работать следующая конструкция: assign R = ( (N*2)'(A*B) ) >> N; Но Квартус, к примеру, ее синтезирует в 0. Для Квартуса годится конструкция подлиннее: assign R = ((N*2)'(A) * (N*2)'(B)) >> N; Есть еще вариант с временной переменной, но в одну строчку: input [15:0] A, B; output [15:0] R; logic [15:0] T; assign {R,T} = (A * B);

Напрасно Вы так ограничиваете концепцию UVM. Вот пара выдержек из user guid UVM 1.1: 5. Using the Register Layer Classes 5.1 Overview The UVMregister layer classesare used to create a high-level, object-oriented model for memory-mapped registers and memories in a design under verification (DUV). The UVMregister layerdefines several base classes that, when properly extended, abstract the read/write operations to registers and memories in a DUV. ... A register model is typically composed of a hierarchy of blocks that map to the design hierarchy. Blocks can contain registers, register files and memories, as well as other blocks. The register layer classes support front-door and back-door access to provide redundant paths to the registerand memory implementation, and verify the correctness of the decoding and access paths, as well as increased performance after the physical access paths have been verified. Designs with multiple physical interfaces, as well as registers, register files, and memories shared across multiple interfaces, are also supported. 5.6 Back-door Access Back-door access to registers and memory locations is an important tool for efficiently verifying their correct operation. A back-door access can uncover bugs that may be hidden because write and read cycles are performed using the same access path. For example, ifthe wrong memory is accessed or the data bits are reversed, whatever bug is introduced on the way in (during the write cycle) will be undone on the way out (during the read cycle). Могу предложить попробовать использовать Back-door Access. Т.е. драйвер и секвенсер выполняют определенные действия, включая ожидания определенных состояний DUT, но не они решают все ли идет по плану. Монитор отслеживает изменения в состоянии DUT и "отчет" передает в scoreboard и scoreboard решает все ли идет как надо или нет. Например, scoreboard проверяет, что фактически после получения транзакции с ошибкой соответствующий флаг был выставлен вовремя, вовремя был сброшен и следующая транзакция началась после сброса флага. В этом случае, scoreboard должна знать только то, что произошла транзакция с ошибкой и должна получить данные о том, как менялось состояние DUT - какое-либо управление ей передавать не надо.

Приведите, пожалуйста, примеры таких симуляторов каждого вида. Я думаю, что Вы путаете виды моделей с самими симуляторами. Есть cycle-accurate модель и timing-accurate модель чего-нибудь (например DSP-ядра). Причем, эта модель может быть написана как на языке программирования, так и на HDL-языке. Мы ограничимся вопросами симуляции и синтеза того, что написано на HDL-языке (тот факт, что воздействия для DUT могут формироваться с использованием таких языков, как С или SystemC сути не меняет). Есть модуль написанный на Verilog, SV или VHDL и его мы синтезируем и симулируем. Мне не интересны однозначные ответы - мне интересно увидеть развернутое мнение/рассуждение. Мои вопросы о том, что на один и тот же код синтезаторы и симуляторы "смотрят" с совершенно разных точек зрения.

В соседней теме (http://electronix.ru/forum/index.php?showtopic=120411) я задал одному из участников 5 вопросов про разницу между синтезом и симуляцией: 1) Всякую ли и всегда ли синтаксически правильную конструкцию синтезатор сможет воплотить физически в FPGA/ASIC? 2) Всякую ли и всегда ли синтаксически правильную конструкцию симулятор сможет просимулировать? 3) Зачем синтезатору нужно "уметь" код типа always @(posedge CLK) A <= B; интерпретировать как регистр? 4) Зачем симулятору нужно "уметь" код типа always @(posedge CLK) A <= B; интерпретировать как регистр? 5) В чем, на ваш взгляд, заключается разница между задачей синтеза и моделирования (симуляции)? Интересно, а как бы ответели Вы?. Хочу собрать разные мнения по этим вопросам. Просьба, отвечать развернуто и аргументировано на каждый вопрос.

Покажите ка код, который у вас получился. У вас обычная память, которая описывается в "3 строчки". Наличие конечного автомата меня очень сильно смущает - он тут совершенно не нужен! Поэтому, скорее всего вы опять перемудрили. Есть разница между кодом для моделирования и кодом для синтеза. Вы модуль, предназначенный для синтеза описываете кодом, который подходит для моделирования. При синтезе у вас получаются защелки, а не регистры (еще раз повторю, на всякий случай: reg не означает регистр). Синхронным дизайном здесь и не пахнет и clk у вас не используется. Неужели вас не насторожило то, что clk не используется? Это ведь однозначно говорит о том, что никакой синхронности относительно клока быть не может. Во первых, у вас все равно память описана неправильно - т.е. она и не должна правильно работать. Во вторых, вы, скорее всего, симулируете исходный код - поэтому при симуляции все нормально т.к. у симулятора нет информации о реальных задержках сигналов и он не может промоделировать те задержки и гонки, которые возникают в реальной ПЛИС. Если вы возьмете нетлист после синтеза и P&R, информацию о реальном тайминге, которую генарирует Quartus и вот это все подадите на симулятор, то тогда результаты симуляции совпадут с реальной работой в ПЛИС. Во всяком случае, правильно это работать не будет и в симуляторе. Нет, ПЛИС позволяет реализовывать как синхронные, так и асинхронные цифровые устройства. И это зависит от способа описания модуля. Код автора темы говорит о том, что разницу между синтезом и симуляцией надо знать не только для зачета и чтобы недопустить самоутверждения препода :) Всетаки от этого есть практическая польза и без осознания разницы ерунда выходит и куча потерянного времени.

Интересно, сколько раз нужно написать, что reg A; reg B; reg C; и пр. с присвоением или без - ОБЪЯВЛЕНИЕМ РЕГИСТРА НЕ ЯВЛЯЮТСЯ ПОТОМУ, ЧТО reg в Verilog НЕ ОЗНАЧАЕТ РЕГИСТР (ТРИГГЕР) !!! Кстати, а куда изчез автор темы? Где код-то, который мы так активно обсуждаем?

Незачет :smile3009: На первый вопрос Вы ответили правильно. На следующие два - совершенно неверно! Любопытно, почему Вы не смогли ответить на 4-ый и 5-ый вопросы? Вы имеете весьма категоричные, ничем не обоснованные и неправильные суждения по тем вопросам, по которым Вы не владеете достаточным количеством информации. Я Вам дам совет: Для начала, поверьте моему утверждению, что симулятор даже не пытается интерпретировать always @(posedge iCLK) oDONE <= А; как регистр. Поверьте, просто потому, что я имею достаточно большой опыт. Затем, используя вопросы с 1-го по 5-й как подсказки, постарайтесь догадаться, почему симулятор не интерпретирует always @(posedge iCLK) oDONE <= А; как регистр. Удачи! :cheers:

Хотелось бы увидеть развернутую аргументацию почему Вы считаете, что я ошибаюсь. Ответьте, пожалуйста, на несколько простых вопросов: 1) Всякую ли и всегда ли синтаксически правильную конструкцию синтезатор сможет воплотить физически в FPGA/ASIC? 2) Всякую ли и всегда ли синтаксически правильную конструкцию симулятор сможет просимулировать? 3) Зачем синтезатору нужно "уметь" код типа always @(posedge iCLK) oDONE <= А; интерпретировать как регистр? 4) Зачем симулятору нужно "уметь" код типа always @(posedge iCLK) oDONE <= А; интерпретировать как регистр? 5) В чем, на ваш взгляд, заключается разница между задачей синтеза и моделирования (симуляции)? 6) Вы все еще считаете, что я ошибаюсь?

Кроме того, что в силу того, что это совершенно разные понятия, я имел ввиду еще и следующее. Когда Вы пишите, что объявили A регистром, то это значит, что А является регистром в силу объявления, а не в силу использования. Например, когда Вы объявляете А как integer, то Вы не сможете присвоить А ничего, что не может быть преобразовано к integer. В Verilog нет такого типа, как регистр. Именно поэтому объявить что-то регистром невозможно. Начинающие очень часто считают что reg в Verilog означает регистр и поэтому "reg A;" считают за объявление регистра. Однако, это не так. Будет А регистром или нет определяется использованием, а не объявлением. И в вашем примере регистр oDONE появится на свет только благодаря тому, что есть always @(posedge iCLK) Причем, регистр будет называться oDONE только в силу того, что практически все синтезаторы используют примерно одинаковый алгоритм наименования синтезируемых примитивов. При обсуждении кода инженеры тоже назовут oDONE регистром, опираясь на смысл кода, а не на строчку с объявлением (ну, во всяком случае такой логике будут придерживаться опытные инженеры). Еще необходимо понимать, что код always @(posedge iCLK) oDONE <= ... только для синтезатора является регистром, а вот симулятор этот код так не интерпретирует. При этом, поведение при симуляции полностью совпадает с поведением регистра, но, повторюсь, симулятор не считает это регистром. Например, в VHDL шаблон описания регистра несколько иной. В VHDL если в списке чувствительности process не указать клок, то для синтезатора это не будет проблемой - он "понимает", что описан регистр по другим "признакам" - синтезатор поставит регистр. Зато при симуляции регистр ни разу не сработает, если список чувствительности у process отсутствует.

Да, попутал чего-то. Я, видимо, с Timing Analyzer перепутал - его они бесповоротно на TimeQuest Timing Analyzer заменили