Nagisa

Огромное спасибо за развернутый ответ! буду делать макетку для обкатки

Странного хочется: хочу облегчить процедуру обновления прошивок на железке, и вижу такой путь: у меня есть на плате STM32 с MicroSD карточкой, что соответственно позволяет хранить прошивку для ПЛИС (циклон2) и есть время при старте на прошивку (2секунды). Подозреваю, что я не первый озадачился таким путем, но вот что-то не нашел описаний подобного. Интересно: - протокол - особенности реализации на STM32, подводные камни - надо ли как-то переформатировать прошивку *.sof для заливки ? и если есть какие-то ccылки / примеры будет супер

отвечаю самому себе это 3 регистра а не 8 - те в индексе идет перечисление а не диапазон бит reg [12:0] pre_reg_az_mem[2:0];

дабы не плодить темы про индексы спрошу снова вот у меня массив reg [12:0] pre_reg_az_mem[2:0]; те это 8 регистров по 13bit каждый - всё верно ? соответственно в кейсе хочу занести туда данные always @ * begin case (SMK_MODE) 4'b0111: // Start - используется для запуска, пересылки данных на БК10 и RAM-BIOS'ом (он - всегда в 0-й странице); begin pre_reg_az_mem[3'd7]<=13'o112; pre_reg_az_mem[3'd6]<=13'o112; pre_reg_az_mem[3'd5]<={6'b000001,SMK_PAGE,3'd1}; // 6+4+3=13bit pre_reg_az_mem[3'd4]<={6'b000001,SMK_PAGE,3'd0}; но получаю матюг: методом тыка обнаружил что 0 1 2 - прокатывают, а 3 уже за пределами хотя 3бита = 8 значений что я делаю не так ?

источник STM32F407, тестирование показало, что он меняет состояние на порту за 1 такт внутренней частоты 162MHz (понятное дело, что есть оговорки) конечно, в идеале надо было использовать SPI и не парится с костылями, но что есть то есть. да, добавка safe полностью решила проблему, и сейчас тест оперативки идет даже на 162MHz (при заявленных 133).

это я в курсе, тут задача в том, что надо сразу отреагировать на изменение (1 такт) а полноценный CDC даст отставание на 2 такта

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

так для того и автомат, дабы синхронизировать вылечил так reg [2:0] state_stm /* synthesis syn_encoding="safe,gray" */; reg [2:0] next_state_stm /* synthesis syn_encoding="safe,gray" */;

Странная проблема с автоматом состояний localparam STATE_STM_WAIT = 3'd0; // ждем =0 на STM_U_QBUS_IN_L localparam STATE_STM_CLANK1= 3'd1; // антизвон localparam STATE_STM_CLANK2= 3'd2; // антизвон localparam STATE_STM_CLANK3= 3'd3; // антизвон localparam STATE_STM_FLAG = 3'd4; // ждем установки флагов операции localparam STATE_STM_DATA = 3'd5; // запоминаем данные для команды localparam STATE_STM_OPER = 3'd6; // выполняем операцию localparam STATE_STM_END = 3'd7; // ждем завершения - снятия синка reg [2:0] state_stm; reg [2:0] next_state_stm; always @ (posedge CLK) begin state_stm<=next_state_stm; end always @ * begin case (state_stm) STATE_STM_WAIT: if(STM_U_QBUS_IN_L==0) next_state_stm=STATE_STM_CLANK1; else next_state_stm=STATE_STM_WAIT; STATE_STM_CLANK1: next_state_stm=STATE_STM_CLANK2; STATE_STM_CLANK2: next_state_stm=STATE_STM_CLANK3; STATE_STM_CLANK3: next_state_stm=STATE_STM_FLAG; STATE_STM_FLAG: if( stm_sync==1)// есть команда next_state_stm=STATE_STM_DATA; else if (STM_U_QBUS_IN_L==1) next_state_stm=STATE_STM_WAIT; else next_state_stm=STATE_STM_FLAG; STATE_STM_DATA: next_state_stm=STATE_STM_OPER; STATE_STM_OPER: next_state_stm=STATE_STM_END; STATE_STM_END: if( stm_sync==0 || STM_U_QBUS_IN_L==1) next_state_stm=STATE_STM_WAIT; else next_state_stm=STATE_STM_END; default: next_state_stm=STATE_STM_WAIT; endcase end соответственно на определенные состояния привязаны действия вообщем обычный автомат который понимает квартус (которых в проекте куча и все работают нормально) но засада в том, что он висит на STATE_STM_WAIT и игнорирует STM_U_QBUS_IN_L который регулярно падает в 0 (смотрю сигналтапом) поведение странное, те при определенном схождении звезд может получится рабочая сборка, но в большинстве своем не рабочая. проблема гарантированно лечится выводом на любой пин любой части регистра state_stm, что явно переключает оптимизатор автомата вопрос первый - в чем причина ? что не нравится оптимизатору, что он делает нерабочий автомат ? и второй - как лечить ? те может какой-то хинт есть дабы объяснить оптимизатору оставить state_stm регистром ?

Cпасибо!

Прошу подсказать: хочу сделать так reg [12:0] reg_az_mem[3:0]; // массив регистров мапирования wire [3:0] hi_az_addr = QBUS_ADDR[15:12]; wire [23:0] pre_addr = {reg_mem[12:0][hi_addr],DA_IN[11:1]}; те у меня есть массив регистров из которых составляется адрес pre_addr номер регистра я хочу выбирать на основании hi_addr как правильно описать данную конструкцию ? сделать always-case где по hi_addr выбирать нужный регистр ? или есть более простые конструкции ?

никто не объяснил как мне обойтись без него ;-) согласно ТЗ мне необходимо читать видеопоток со скоростью 11796480 слов в секунду , иначе говоря по одному слову за ~84нс цикл с памятью получается минимум 8 операций с частотой 92MHz - те ~86нс те я в принципе не успею даже на VGA выплюнуть поток, а мне еще надо облуживать 2 системы которые тоже хотят читать и писать в память (можно перейти на CL2 это даст экономию но проблемы не решит) если же я использую bust то необходимые 256 слов на строку я читаю в 4 захода по 32 слова и трачу на все это ~3,5мкс против ~22мкс если бы это было одиночное чтение, и успеваю с минимальными задержками обслуживать других абонентов на счет сильно усложняет - я минимизировал изменение логики - те отличие только в длине цикла + времени подачи команды BURST_TERMINATE

так а как без него-то ?

в итоге все переехало в автоматы пришлось правда один сигнал управления протаскивать через global clock таки 2й циклон достаточно медленный..... burst заработал как надо, контроллер получился 3х режимный - те одиночная запись, одиночное чтение и пакетное чтение. (режим пакетного чтения на самом деле включен всегда, просто при одночном чтении торможение идет почти стазу, а в пакетном по нужной длине. )

в итоге продвинулся вперед, а именно сделал: 1. автоматы на каждую операцию применительно к абоненту - чтение, запись 2. приоритетный шифратор (всего получается 6 операций) 3. автомат операции для общения с контроллером SDRAM 4. автомат с переменной длиной в непосредственном контроллере SDRAM сейчас прикручиваю VGA и кусок ниже мне мешает однако есть глупый вопрос вот у меня кусок always @(posedge dout_en or posedge B_SYNC_L) begin if (dout_en==1 ) begin DA_OUT<=drd; // данные с SDRAM на шину selbus<=1; // управление шиной - направлением - включаем на выдачу end else begin selbus<=0; // управление шиной - направлением - выключаем end end // dout_en идет с контроллера SDRAM и появляется синхронно с данными (опаздывает на 1/2такта дабы данные установились) // B_SYNC_L - завершение обмена по шине те чистая асинхронщина вопрос - как же сделать правильно ? да, dout_en имеет длительность в несколько тактов - те длиной в бурст, в данном случае он работает как фронт по которому будет взято слово переключить шину обратно надо не ранее B_SYNC_L=1 мне приходит в голову только автомат, но правильно ли так ?