flammmable

Большое спасибо, ваш пример заработал. Тем, кто столкнется с похожей проблемой и зайдет через годы в эту тему я бы рекомендовал обратить внимание на версию Квартуса - Pro/Standard/Lite. А затем поставить Lite со всеми настройками по умолчанию. Могли бы вы меня проконсультировать по самому UFM и модулю altera_onchip_flash_block ? Или указать, где прочитать об этом? 1) После начала тактирования drclk и стробирования по drshft выход из модуля drout висит в единице. Но после двух тактов по arclk (на каждые 64 такта drclk) при высоком arshft выход drout выдает некий, весьма длинный код (9 слов по 16 бит). Что это за код? Почему arclk = 64 х drclk ? 2) Первую четверть от всего времени передачи пакета данных arshft висит в единице - drout после выдачи кода молчит (в нуле). Вторую четверть arshft висит в нуле - drout снова молчит (в нуле). Затем в начале третей четверти появляются записанные в UFM данные (arshft продолжает висеть в нуле), которые передаются до конца пакета. Что arshft столько времени делает в единице? 3) На вход ardin подается фиксированное значение {{22{1'b1}},1'b0}. Причем вместо 1'b0 можно поставить некое внешние соединение. Если же вместо других 22 бит попробовать подставить что-либо - компиляция не пройдет. Предположу, что ardin - это вход сдвигового регистра адреса. Предположу, что регистр позволяет сдвигать данные пока arshft в единице и автоинкрементирует себя, если arshft в нуле. Почему нельзя за десять тактов arclk поместить в регистр адреса значение "512" и начать чтение сразу? Возможен ли произвольный переход по адресам внутри UFM или же допустимо только последовательное чтение?

Большое спасибо! Похоже, что модуль altera_onchip_flash_block максимально близок к железу и в нем отсутствуют любые связи с шиной Avalon. Может быть вы могли бы еще кое-что рассказать? У данного модуля есть параметр .INIT_FILENAME . Однако, при записи туда заведомо некорректного пути сборка проекта всё равно происходит без ошибок. А при записи корректного - в *.pof, генерирующийся автоматически, не заносятся данные из указанного *.mif . Это видно при побитном сравнении с *.pof, который был сгенерирован при помощи Convert Programming Files из *.sof и *.mif . Зачем нужен параметр .INIT_FILENAME и как автоматически в ходе компиляции генерировать *.pof с внедренным в него *.mif ?

Похоже, что всё таки нет ((( Документ Replacing Serial EEPROMs with User Flash Memory in Altera MAX Series говорит, что ALTUFM_NONE в MAX-10 "Not supported".

Возможно ли на MAX-10 задействовать встроенную пользовательскую флеш-память UFM без использования шины Avalon?

В даташитах на DDR/DDR2/DDR3/DDR4 существует множество вариантов чтения и записи. Стандартные контроллеры памяти абстрагируют программиста от этих вариантов, сглаживая при помощи FIFO неравномерности потока данных при закрытие/открытие банков в случае необходимости обновления памяти, а также на стыках этих банков. Приходилось ли вам писать свои контроллеры памяти? Чем это было вызвано? Просматриваются ли наиболее типичные сценарии использования DDR для которых стандартный контроллер с парой FIFO был бы не оптимален?

Чертовски любопытные симуляции.

Спасибо!

Конденсаторы по питанию ставятся максимально близко к потребителям как некие резервуары заряда потому, что длинный проводник обладает большой индуктивностью и не способен обеспечить стабильное напряжение питания при быстром изменении уровня потребления тока. Правда для истечения тока из конденсатора также есть препятствия: "у каждого пикофарада есть свой наногенри" (с). Поэтому зачастую ставят параллельно несколько отдельных конденсаторов. Или не отдельных, а объединенных в конденсаторную сборку. Например на остров терминирующего напряжения для DDR. Однако существуют конденсаторы в корпусах, где контакты расположены по длинным сторонам. Например LLL185R71H222MA01L. В чем разница между конденсаторной сборкой и длинным одиночным конденсатором? Каковы преимущества и недостатки одного и другого?

Спасибо!

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

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

Вопрос по стилю написания кода. Я написал код на SystemVerilog, выдающий из ПЛИСа видеосигнал HDMI через трансивер TFP410. В трансивер заходят сигналы DE, HSYNC, VSYNC, R[7:0], G[7:0], B[7:0] и ряд дополнительных сигналов, специфичных для TFP410. Сами сигналы DE, HSYNC, VSYNC формируются исходя из стандартных таймингов (с учетом всяких front porch, back porch, sync width и т.д.). Тестовый видеосигнал (заливка цветом) выдается четкий и устойчивый. Но весь код пока написан в одном модуле. Вопрос: как лучше/правильнее разбить код по модулям для повторного использования в будущем? Будет ли лучше его разбить на нижний модуль для TFP410; средний для формирования стандартных таймингов; и верхний, выдающий координату точки, принимающий цвет данной точки и пробрасывающий через себя интерфейс от нижнего модуля TFP410 на выходы ПЛИСа? Как лучше организовать выбор стандартных таймингов: группами параметров, которые можно переключать при ifdef и глобального дефайна? Или можно сделать какой-нибудь входной параметр для среднего модуля, формирующего SYNC-и и им выбирать группы параметров? Или еще как-нибудь?

Точнее сказать так. У некоторых FPGA одного из их производителей есть TMDS выходы, причем несмотря на их наличие, на некоторых демоплатах (например, Atlys Board) после этих выходов всё равно ставят повторители TMDS сигнала (например, на Atlys Board стоят TMDS141). А у большинства FPGA выходов TMDS нет. Также. У некоторых FPGA стоят внутренние тактовые генераторы, а у большинства - нет. У некоторых FPGA есть внутренние LDO, позволяющие питать и Vdd_core и Vdd_io от одного напряжения, а у большинства - нет. В тоже время у большинства FPGA есть выходы LVDS. Мой вопрос относится к общему случаю: что делать в общем случае, если нужно вывести сигнал DVI-D, а выходные драйверы не поддерживают TMDS? О, спасибо! Есть еще одно классное IP позволяющее сократить рассыпуху: Altera modular ADC core. Можно просто добавить его в проект на нужные пины и обойтись без внешних АЦП.

Есть желание выдать с ПЛИСа видеосигнал. Хотелось бы это сделать при помощи популярного протокола DVI или HDMI. Есть известная статья Марсохода "Реализация HDMI в ПЛИС". В ней применяется плата Марсоход3бис, где выводы LVDS идут прямо на разъем HDMI. Однако на данном форуме, в теме "TMDS - LVDS" говорится, что линии HDMI (TMDS) относятся к типу дифференциального сигнала CML, который скорее всего не потянут драйверы LVDS самого ПЛИСа. У Texas Instruments имеется трансивер TFP410, преобразующий параллельные сигналы цвета и управления CMOS в необходимую для DVI последовательность дифференциальных сигналов TMDS. На Маузере он стоит около 10$. Однако при его использовании задействуется большое количество выводов, при том, что сигналы TMDS по скорости вполне приемлемы для исполнения самим ПЛИСом. При возникновении вопроса как преобразовать LVDS в DVI, техасцы отвечают что-то типа "десериализировать LVDS в параллельный CMOS чем-нибудь типа DS90C386, а затем сериализировать CMOS при помощи того же TFP410". В итоге предполагается потратить площадь печатной платы на кучу параллельных проводников и купить сразу две микросхемы. У Lattice похожий подход. У ITE есть микросхема-конвертор LVDS в HDMI - IT6263. Её нет на Маузере, да и вообще она выглядит странно. Также имеется одиночный преобразователь LVDS-CML от того же Texas Instruments - SN65CML100. На Маузере стоит около 8$. Для 4-х линий потребуется 32$. И высокоскоростной компаратор с выходом CML от Analog Devices - ADCMP606. Катушкой по 3000шт. стоит 4,5$. Для 4-х линий потребуется 18$. Теперь вопросы: 1) Каков самый правильный способ вывода сигнала HDMI с ПЛИСа? 2) Почему у того же Maxim Integrated или ON Semiconductor нет своих преобразователей CMOS-в-HDMI и LVDS-в-CML? 3) Почему одиночный преобразователь LVDS-в-CML стоит почти как TFP410, набитый сериализаторами, системой тактирования, настройками через I2C и четырьмя выходами TMDS ?

Модуль вычисления CRC: module main #( parameter IS_CRC_REVERSED = 1, parameter IS_DATA_REVERSED = 1, parameter DATA_SIZE = 8, parameter CRC_SIZE = 16, parameter START_VALUE = 'hFFFF, parameter POLYNOME = 'h8005) ( input clk, input n_reset, input [DATA_SIZE-1:0]data_in, output reg [CRC_SIZE-1 :0]crc_out); reg [CRC_SIZE-1 :0]crc_internal; reg [DATA_SIZE-1:0]data_internal; reg msb; reg [CRC_SIZE-1 :0]crc_shift; reg [CRC_SIZE-1 :0]crc_lfsr; always @(posedge clk) begin if(n_reset) begin // data reverse if(IS_DATA_REVERSED) begin for(int i = 0; i < DATA_SIZE; i++) begin data_internal[i] = data_in[DATA_SIZE - 1 - i]; end end else begin data_internal = data_in; end // CRC calculating crc_shift = crc_internal ^ (data_internal << (CRC_SIZE - DATA_SIZE)); for(int data_index = 0; data_index < DATA_SIZE; data_index++) begin msb = crc_shift[CRC_SIZE-1]; crc_lfsr = (crc_shift << 1); crc_lfsr = crc_lfsr ^ ({CRC_SIZE{msb}} & POLYNOME); crc_lfsr[0] = msb; crc_shift = crc_lfsr; end crc_internal = crc_shift; // CRC reverse if(IS_CRC_REVERSED) begin for(int i = 0; i < CRC_SIZE; i++) begin crc_out[i] = crc_shift[CRC_SIZE - 1 - i]; end end else begin crc_out = crc_shift; end end else begin crc_internal = START_VALUE; end end endmodule Тестбенч к нему: `timescale 1ns/1ns module main_tb(); reg clk; reg n_reset; reg [7:0]data; wire [15:0]crc; main crc16( .clk (clk), .n_reset (n_reset), .data_in (data), .crc_out (crc)); initial begin #10; clk <= 0; while(1) begin #5 clk <= ~clk; end end initial begin #18; n_reset <= 0; #14 n_reset <= 1; #87 n_reset <= 0; end initial begin #31; data <= 'h12; #10 data <= 'h34; #10 data <= 'h56; #10 data <= 'h78; #10 data <= 'h90; #10 data <= 'hAB; #10 data <= 'hCD; #10 data <= 'hEF; #10 data <= 'hAA; #10 data <= 'h55; end endmodule Контрольная сумма из этого калькулятора для CRC-16 MODBUS и данных hex-1234567890ABCDEFAA совпадает с контрольной суммой, выдаваемой модулем.