Renom

При решении задачи соответствия проекта стандарту DO-254, Modelsim/Qustasim являются лишь одним из инструментов (обязательным, но недостаточным). Начинать надо с проверок того, что стиль написания кода соответствует DO-254, а тут Modelsim/Qustasim в принципе помочь не смогут. Для этих целей требуется линтер с пакетом правил на соответствие стандарту, как вариант ALDEC ALINT с 2мя пакетами правил (DO254.VHDL и DO254.VLOG).

Поделитесь опытом по лечению от жадности :) При использовании лекарств из закромов продолжает ругаться на отсутствие лицензии (пробовал как node-locked, так и float)

Это справедливо только для CPLD и простейших проектов для FPGA :)

Нормальные требования. А перечислять базовые требования когда ищется человек с опытом не имеет смысла - только плодить бессмысленный текст. По соотношению требования/зарплата найти на 90 т.р. чистых (при условии что будет соответствовать 50% требований) вполне реально. Можно найти и того кто будет удовлетворять 100%, но там будут другие запросы относительно з.п. (минимум от 150-180). P.s. Склярову привет :)

Флаг OVF на периферийном DMA появляется в ситуации когда канал DMA не может занять шину памяти для выгрузки данных набранных в буфер. Так как других DMA нет и судя по всему пропускная способность шины памяти не превышена, то скорее всего во время работы DMA вы усиленно пишите/читаете внутреннюю память ядром, а приоритеты доступа к памяти не меняли (по дефолтным настройкам приоритет у ядра и DMA ждет когда ядро освободит шину).

Лекарства нужны если планируете использовать JTAG-отладчики, в пробной лицензии они не поддерживаются.

Скорее всего у Вас компьютер и отлаживаемая плата сидят на разных землях и в итоге имеете 110В по земле, что естественно выжигает отладчик (в свое время так спалили пару штук).

Копайте в сторону допустимой нагрузки на пин :)

поиск в гугле по ключевым словам: Verilog, SysytemVerilog, VHDL, testbench

Правильная мысль - нажать на лампочку в ISE и посмотреть примеры кода на Verilog. Там есть описания всех основных конструкций.

Выложить проект нет возможности, а более подробное описание держите: Используемый софт: 1. ActiveHDL 9.1 - основной IDE 2. Synplify Pro F-2012.03 - HDL Syntesis 3. PlaneAhead 14.3 - Physical Syntesis 3. ISE 14.3 - Implimentation 2. TortoiseSVN 1.7 - контроль версий Структура проекта: автоматически генерируемые папки: src - исходники (hdl, FSM, Shematic) TestBench - исходники тестов + конфигурации к ним. post-syntesis, timing - автоматически генерируемые паки для временных симуляций проекта. ../xilinxcoregen - ip-cores Папки создаваемые пользователем: pdf - документация на проект в формате pdf include - файлы настроек, инициализации памяти и т.п. macro - скрипты для управления проектом. temp - временный хлам. sim_result - результаты симуляции (текстовые логи, бинарные файлы, иногда asdb). external -вспомогательные программы + внешние подключаемые модули. Список основных скриптов: Для генерации пользовательских папок и скачки с сервера необходимых модулей в папку external, список необходимых библиотек/модулей/программ берется из текстового файла. Так же производится линковка папок и файлов в проект. Комплект скриптов для сборки проекта (обычно используется несколько для сборки проекта с различными настройками Synplify и ISE). Симуляция проекта (комплект скриптов запускающих различные виды симуляции через ServerFarm и размещающий результаты симуляции в папке sim_result). Конвертация FSM и схематик в pdf (скрипт пробегает по папке src в посисках файлов с нужным расширением и запускает конвертацию в pdf с сохранением в папку pdf). Скрипт для создания релиза проекта: 1. Генерируется документация на модули (пробегается по папке проекта в поисках файлов с именем соответствующим списку содержащемуся в текстовом файле и расширением h,txt,ini + vhd содержащих только package). 2. По списку из текстовог файла производится скачивание с сервера двух библиотек - syntesis_block (синтезируемые самописные ядра) и sim_block (комплект тестбенчей для syntesis_block) и их обновление. 3. Обновленные библиотеки и документация заливаются на сервер. 4. Заливается сам проект (исходники, тесты, папка с ip-cores, скрипты, документация и файлы прошивок). Управление текущими версиями проекта осуществляется напрямую из ActiveHDL без использования скриптов. Для управления проектом достаточно окна Design Browser. На вкладке files видны исходники,тесты, скрипты и temp в который обычно кладутся черновики описаний к модулям и т.п. На вкладке Resources комплект папок для быстрой навигации по проекту: src: .......vhdl - линкуется на папку src с фильтрацией файлов по расширению. .......verilog - линкуется на папку src с фильтрацией файлов по расширению. .......FSM -линкуется на папку src с фильтрацией файлов по расширению. .......Shematic -линкуется на папку src с фильтрацией файлов по расширению. Logs: автоматически генерируемые логи и отчеты о синтезе и размещении проекта. Sim_result : результаты симуляций Memory : файлы инициализации памяти dll : внешние библиотеки. pdf : .......modules: -самописные блоки (линкуется на pdf) ..............name1 - содержит комплект документации на модуль name1 ..............name2 .......xilinxcoregen: - ip ядра (линкуется на xilinxcoregen) ..............name1 - содержит комплект документации на ядро name1 ..............name2 SVN : содержит текстовый файл с историей заливок на сервер. Сборка и симуляция проекта происходит на удаленной машине. p.s. Если возникнут какие-либо вопросы задавайте, постараюсь ответить.

Не первый год использую в качестве основной IDE ActiveHDL. Основные причины которыми был обусловлен выбор: 1. Автоматическое структурирование проекта (сорцы отдельно, документация отдельно, тестбенчи отдельно и т.д.). 2. Прямая интеграция с системами контроля версий. 3. Приличный симулятор. 4. Полное управление проктом с помощью скриптов. p.s. убогость текстового редактора - даже не смешно, подключается любой внешний.

перетащить мышкой все что надо в wave а потом сделать экспорт в do файл, который уже в свою очередь подключить к основному макро-файлу :)

Почитал все вышенаписанное и не совсем понял основную массу высказывавшихся. Для такой задачи использовать FPGA+PCI-E это как из пушки по воробьям. Берется ADSP-BF548, настраивается один 24 битный PPI на частоту 100 МГц, полученный поток 240 Мбит/сек выкидывается в USB 2.0 в режиме bulk transfer (используя для этого предложенный AD проект получаются скорости по USB 320-350 мбит/сек, а если немного его переписать,то достигается 440 мбит/сек). PPI настраивается в режим работы по DMA со списком дескрипторов для автоматического переключения 2х буферов записи. А дальше работает класическая схема один буфер заполняется, второй скачивается. Буферы разносятся по разным sub-bank для снижения нагрузки на внутренние шины. p.s. В свое время делал похожую систему, только на поток данных 320 мбит/сек Blackfin вытягивает без проблем.

К сожалению пока в ПЛИС используются КМОП-транзисторы и не отменены законы сохранения энергии ваше утверждение из разряда фантастики. В предложеном вами варианте используются: счетчик+автомат+выработка сигнала разрешения работы автомата, в том варианте что я Вам предлагаю логика выработки разрешающего сигнала отсутствует, как и сам разрешающий сигнал. Для проверки сделал маленький тест. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity test is Port ( clk : in STD_LOGIC; din: in std_logic_vector(3 downto 0); dout: out std_logic_vector(3 downto 0) ); end test; architecture Behavioral of test is signal cnt: std_logic_vector(5 downto 0):=(others=>'0'); begin process (clk) begin if rising_edge(clk) then cnt<=cnt+1; -- if (cnt(2 downto 0)="100") then -- case (cnt(5 downto 4)) is -- when "00" => -- dout<=din; -- when "01" => -- dout<=not(din); -- when "10" => -- dout<=din(1)&din(2)&din(0)&din(3); -- when "11" => -- dout<=not(din(1)&din(2)&din(0)&din(3)); -- when others => -- dout<=din(1)&din(2)&din(1)&din(0); -- end case; -- end if; end if; end process; -- process (cnt(2)) -- begin -- if (falling_edge(cnt(2))) then -- case (cnt(5 downto 4)) is -- when "00" => -- dout<=din; -- when "01" => -- dout<=not(din); -- when "10" => -- dout<=din(1)&din(2)&din(0)&din(3); -- when "11" => -- dout<=not(din(1)&din(2)&din(0)&din(3)); -- when others => -- dout<=din(1)&din(2)&din(1)&din(0); -- end case; -- end if; -- end process; end Behavioral; Первй процесс иллюстрирует ваш вариант, второй то,что я предлагаю вам сделать. Попробуйте собрать проект 2 раза: первый раз сняв коментарии в первом процессе, второй раз раскоментировав второй процесс и вернув коментарии в первом и сравните их потребление и занимаемые ресурсы.

а что мешает сделать процесс по falling_edge(counter_data(2)) и в нем каждый такт отрабатывать автомат управления?

Если сравнивать степень полинома с числом найденных корней,то это эквивалентно порогу в (число проверочных символов)/2, что в свою очередь приводит, в зависимости от параметров кода, к вероятности ложного срабатывания вплодь до 10^(-4), что является во многих случаях недопустимо большой величиной,поэтому и рекомендуется ставить порог на декодирование ниже реально допустимого для кода. Отстут на 1 снижает вероятность ложного срабатывания примерно на 10^6

Читайте теорию кодов Рида-Соломона,тогда 3/4 вопросов отпадут :) 1. При работе без стираний (явного указания декодеру позиции ошибки) количество обнаруживаемых и исправляемых символов составляет (чмсло проверочных символов)/ 2. Но этой величиной оперировать нельзя, т.к. при превышении этого порога степень локатора все равно равна порогу обнаружения. Плюс данный код имеет вероятность ложного обнаружения зависящую от размера поля,числа информационных и проверочных символов. Поэтому имеет смысл ставить после подсчета локатора решающее устройство у которого идет проверка степени полинома локатора, при нулевой и превышающей ((чмсло проверочных символов)/2-1) дальнейший декодер не запускается- в первом случае блок принят без ошибок и дальнейшее декодирование не имеет смысла,во втором ошибок слишком много.

Если привести все написанное вами в порядок,то это будет так: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; use IEEE.STD_LOGIC_ARITH.ALL; entity mem4x64 is Port ( clk : in STD_LOGIC; addr : in STD_LOGIC_VECTOR (5 downto 0); oe : in STD_LOGIC; data : inout STD_LOGIC_VECTOR (3 downto 0); data2 : inout STD_LOGIC_VECTOR (3 downto 0) ); end mem4x64; architecture Behavioral of mem4x64 is type mem256 is array (63 downto 0) of STD_LOGIC_VECTOR(3 downto 0); subtype int64 is INTEGER range 0 to 63; signal RAM,RAM2: mem256; signal outp: std_logic_vector(3 downto 0); begin data<= RAM(conv_integer(addr)) when oe='1' else (others=>'Z'); data2<= outp when oe='1' else (others=>'Z'); Distrib_RAM: process (clk) begin if (rising_edge(clk)) then RAM(conv_integer(addr))<=data; end if; end process; Block_RAM: process (CLK) begin if (rising_edge(clk)) then if oe = '0' then RAM2(conv_integer(ADDR)) <= data2; end if; outp <= RAM2(conv_integer(ADDR)); end if; end process; end Behavioral;

SPI DMA в 533 работает прекрасно, читаем datasheet и ищем ошибки в программе.

Грубо говоря: Имеется 16 источников прерываний, соответственно 16ти разрядный регистр прерываний, где за каджым источником прерываний закреплен определенный бит, CPU считывает состояние этого регистра и ищет в нем 1 начиная с младшего разряда, как только встречается 1, этот бит сбрасывается и начинается обслуживание данного прерывания (источник прерывания определяется по позиции 1).

Затем, что если Вы почитаете документацию на данный USB контроллер,то узнаете, что в нем имеется 51е ядро, которое и конфигурит его работу :)

Между огбычным Verilog и VHDL разницы в принципе в качестве разводки проектов нет. p.s. Код не выложу по одной простой прицине: Начальство уволит :)

Достаточно большие и сложные проекты пока с SV компилятся заметно хуже, чем описанные на vhdl (получается разница в заполнении кристала около 20% и в быстродействии около 15%). Так что если место или быстродействие критичны пока использовать SV не получается....

Достаточно часто использую фильтры сделанные в в FIR Compiler, пока проблем не было ни разу.