sallador

О! Тут уже давали на мой гитхаб ссылку. В общем, если коротко - у меня почти платформонезависимая корка БПФ на любую длину. Radix-2 и 2-х параллелизм. Можно заменить узлы, где делается умножение и сложение на DSP48 узлах Xilinx на то, что есть в альтере - и оно заработает (главное задержки такие же соблюсти). Или тупо переписать код влоб, типа: X_RE = A_RE * W_RE - A_IM * W_IM; X_IM = A_RE * W_IM + A_IM * W_RE; Разумеется, эти операции лучше разбить на несколько стадий. И дать синтезатору указание разводить это не на логике, а на встроенных узлах DSP. Если АЦП не очень скоростная, то двухкратный параллелизм - избыточен. В таком случае нужно делать БПФ по схеме single path delay feedback - оно проще и легче.

Загляните сюда, например. Гуглится мгновенно: http://www.32x8.com/var5.html

Можно поступить так: В entity этого компонента, который мапите, присвоить входным сигналам исходное значение. Например: entity bla_bla_bla is port( aa : in std_logic_vector(N-1 downto 0):=(others=>'0'); bb : in std_logic:='0'; ... ); end bla_bla_bla; Тогда не надо входным портам присваивать значения. А про выходные уже ответили: либо вообще ничего не писать, либо => open. Условная запись: signal test : std_logic_vector(3 downto 0):="0000"; Не тратит логические ресурсы и триггеры совсем, если далее в коде значение сигнала нигде не меняется. А чтобы наверняка не менять это значение - вместо signal напишите constant и мапьте к компонентам константы значений.

Туда: 1ГБайт/c. Обратно: 1ГБайт/c. Потоки независимы.

Интересная тема. Такое ощущение, что в какой-то команде пожалели денег на разработчика. По теме: Всё реально. Реализовали SRIO на кристаллах Xilinx: V6, K7, сейчас делаем на KU. Например, для V6 скорость: 1ГБ/c туда, 1Гб/c обратно. Тесты обмена данными следующие: FPGA <> FPGA, FPGA <> DSP, FPGA <> HOST (компьютер). В первом варианте для V6 задействован SRIO SWITCH для обмена между удаленными друг от друга устройствами (т.к. на 1 плате - 1 ПЛИС, на скорость это не влияет). Для K7 свитча нет.

Есть еще составной буфер: IBUFGDS = связка IBUFDS + BUFG. Работает корректно :)

А кто-нибудь сталкивался со следующей проблемой при активации Training Credits после покупки софта от Xilinx? Мы недавно приобрели лицензию на Vivado и получили 30 training credits. Сегодня я попытался их активировать на странице XPA Training Credits. Выдает следующую проблему: То есть, лицензию с моего аккаунта дали купить месяц назад, санкций никаких не было. А обменять кредиты на курсы - нельзя. Интересно...

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

Вам правильно подсказали - делайте независимый синтез каждого узла и создавайте отдельно *.ngc блоки. А на верхнем уровне их подцепляйте как black-box. Тогда перекомпилировать придется только конкретный узел. Для Implementation в PlanAhead есть удобная штука: "Promote Partitions". Суть такая: 1) закрепляем в виде p-blocks нужные узлы, которые не будут изменяться. 2) разводим проект N раз и выбираем удовлетворяющую вас разводку. 3) разводку неизменных p-block оставляем с помощью "promote". 4) делаем сколько угодно другие изменения и разводим проект заново, с учетом уже разведенных блоков. 5) ... 6) PROFIT!!! Ну и как уже верно заметили - читать нужно Hier. design rules. Что-то типа такого: первый попавшийся юзергайд.

Удобная штука. Пример: в зависимости от какого-нибудь числа каналов нужно сделать 1, 2, 4, 8, 16 и т.д. сигналов валидности. signal Nchan_valid : std_logic_vector(Nchan-1 downto 0) Если канал 1 - то так и получится (0 downto 0); А про остальное - Вам уже верно ответили. Xilinx для памяти любит делать такие шины. Зачем и почему? Лезем в библиотеку unisim и unimacro, и смотрим, как у них конфигурируются какие-нибудь примитивы памяти типа BRAM_TDP_MACRO, RAMB16_S1_S1, RAMB36E1 и т.д.

Unknown identifier "current_simbol". Замените на цифру - 1, 2, 3... - все работает.

Конечно. Плюс я смотрю уже результат после стадии PAR, а там он уже точно делает после всех оптимизаций окончательный вариант. Вчера очень долго читал даташиты. Похоже, что нельзя инициализировать RAMB36E как ROM 72x512 таким способом. Остается вариант - либо делать через CoreGEN, либо unimacro подключать. Первое не устраивает, второе еще терпимо.

Для уменьшения кода я написал без процесса. С процессом тоже пробовал, суть та же. Результаты одинаковые. Ладно, попробую через примитив из unimacro, где можно определенным образом задать INIT векторы. Хм. Ничего не понимаю. ROM не хочет делать, а RAM влегкую. Такие дела, переписал код: удалил инициализацию, добавил порт для записи в память. Итого, RAM 512x64 он сделал без проблем на 1 RAMB36. Пруф из FPGA_Editor: Чудеса.

Нет, это не влияет. Ура. Удалось сделать не на рассыпухе, а на 2 блоках RAMB36. Причем, без атрибутов ram_style. Но все равно он не хочет в 1 блок упихивать. Код такой: library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity rams_21b is generic ( Data_w : integer:=64; Data_d : integer:=512 ); port ( CLK : in std_logic; EN : in std_logic; ADDR : in std_logic_vector(8 downto 0); DATA : out std_logic_vector(Data_w-1 downto 0) ); end rams_21b; architecture syn of rams_21b is type rom_type is array (Data_d-1 downto 0) of std_logic_vector (Data_w-1 downto 0); signal ROM : rom_type:= ( ТУТ 512 ОТСЧЕТОВ ); signal rdata : std_logic_vector(Data_w-1 downto 0); begin rdata <= ROM(conv_integer(ADDR)); process (CLK) begin if (CLK'event and CLK = '1') then if (EN = '1') then DATA <= rdata; end if; end if; end process; end syn;

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

У вас dual-port, а мне нужен single-port. Например, в Aldec Active-HDL из Language Assistance для single port RAM предлагается такой код: process (clk) variable ram : ram_t; begin if clk'event and clk = '1' then if wr_en = '1' then ram(conv_integer(addr)) := data_in; end if; data_out <= ram(conv_integer(addr)); end if; end process; Что совпадает с моими желаниями, за исключением того, что мне не нужна запись, т.к. я делаю ROM. Добавлено: для Template language из ISE - код практически идентичный.

Потому что я хочу сделать параметризируемый блок ROM разной глубины. В зависимости от условий, он может быть 64х1к, 64х8к или, например 64х128к... Делать кучу корок - не хочется совсем. Хочется понять, как заставить XST не умничать. P.S. примечательно то, что если я делаю разрядность данных не 64, а например 44, то он делает на 1 RAMB36 и 1 RAMB18. В FPGA Editore - вижу, что сделал на RAMB, но режимы выставил им TDP, а не SDP. Зачем ему лишний RAMB18 понадобился, не пойму. Но это не решает проблему для разрядности данных = 64.

Есть вот такой кусочек кода: type std_logic_array_64xNN is array (511 downto 0) of std_logic_vector(63 downto 0); -- Инициализирую массив 512х64 функцией read_ini_file. constant const_init : std_logic_array_64xNN:=read_ini_file(stage_num); attribute RAM_STYLE : string; attribute RAM_STYLE of d_out : signal is "block"; begin -- адрес = выход обычного счетчика addr <= cnt(stage_num-2 downto 0); -- здесь я пытаюсь сделать ROM 512х64 на BRAM: d_out <= const_init(conv_integer(addr)) when rising_edge(clk); Хочу: чтобы синтезатор сделал Simple dual-port ROM на одном примитиве RAMB36E1. Из даташита на 7 серию: Each 36 Kb block RAM can be configured as a ... 512 x 72 in simple dual-port mode. То есть теоретически это реально, но синтезатор ни в какую не хочет задействовать примитив и делает на рассыпухе. Причем, атрибуты он игнорирует. XST пишет следующее: Но асинхронного чтения нет, все по клоку. Да и возможности BRAM из 7 серии позволяют использовать режим SDP 512x72. Пробовал расширять разрядность до 72 - безрезультатно! Использовать coregenerator не хочу, вставлять напрямую библиотеку unisim/unimacro - тоже. Как быть? Почему XST тупит?

Не знаю, как на verilog, а на VHDL мне помогло атрибут прописать не для сигнала, а для entity, в котором сделал обычный сумматор как отдельный компонент. attribute use_dsp48 : string; attribute use_dsp48 of add_example : entity is "yes";

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

Что еще пишет? Причин может быть несколько: 1) В корегенераторе установили не Spartan6, 2) Не скопировали (не создался) NGC вместе с HDL-файлом, (можно еще проверить в самом файле, что установлено в "family") 3) В самом проекте установлен не Spartan6.

Это уже в настройках синтеза и имплемента можно поставить. Но мне не нужно весь проект переводить строго на синхронный или асинхронный сброс. :) Так я и читал отчет синтеза, имплемента и в FPGA Editor смотрел. И пока не добился засовывания PREG внутрь - он всегда писал, что Used 32 Flip-flops...

Бинго! Причем, а) Если так сделать для разводки только одного компонента счетчтика он триггеры помещает в IOBы :) б) Если так сделать для разводки полного проекта - то видит PREG для счетчика! Все заработало. Проблема решена, спасибо. Более того, удалось для выражения: data <= data_a * data_b + data_с after td; Задействовать PREG и MREG.

1) да, синтезирует в DSP48 блок, но без PREG. 2) after td - чисто для моделирования, оно выбрасывается синтезатором (проверено 100% на всех проектах, которые я делал) 3) ena - убирал, результат тот же. 4) попробую - о результатах сообщу.

Добрый день, уважаемые коллеги! В нашем узком кругу разработчиков на ПЛИС возникла необходимость сразу в нескольких вещах. 1) Регламент и правила для описания компонентов VHDL в процессе разработки. Каким образом именовать те или иные сигналы, порты, компоненты, как делать описание шапки файла и т.д. В интернете на эту тему очень много документов, например: а) https://wiki.electroniciens.cnrs.fr/images/...oding_style.pdf б) http://www.irtc-hq.com/wp-content/uploads/...-2014-02-05.pdf Интересует, как это сделано у форумчан в ваших командах? 2) Сопроводительная документация к компонентам и законченным узлам. Дабы не плодить огромный зоопарк однотипных компонентов и узлов, хотелось бы сопровождать код краткой документацией. В настоящий момент мы не пишем документацию к блокам, но активно пользуемся SVN и VSS. В идеале хотим разработать правило, которое гласит: "компонент RTL считается законченным только тогда, когда на него написана сопроводительная документация". В документации хотим видеть как минимум а) таблицу портов из entity, с направлением и описанием. б) временную диаграмму в разных режимах работы. (По аналогии с тем, как сделано в даташитах у Xilinx). Может быть, еще RTL-компонент сопровождать тестбенчем. Каким образом сопровождаете RTL-компоненты вы? Поделитесь опытом. :smile3046: P.S. бонусный вопрос - пользутесь ли вы doxygen для документации vhdl? (на первых порах хотим применить у себя, но боимся, что потратим время впустую).