[krux 8]

поясните ваше видение работы авторефреша для начала. для максимальной производительности это очень важно. для исключения глюков с физической стороны, а не со стороны вашего видения алгоритма.

[Nagisa 0]

1 hour ago, Flip-fl0p said:

Подумайте вот над чем. Нужен ли Вам Burst. Ибо никакого преимущества скорости он не дает. 

он жизненно важен - ибо у меня не только обслуживание процессора, но и VGA контроллер.

Соответственно в начале каждой строки я читаю bust-ом из SDRAM в памяти самой ПЛИС строку и потом уже ее вывожу

вот и получается у меня 3 режима работы. причем если на чтение процу я могу сказать - подожди, те выдать RPLY позднее, то с записью все плохо - я должен ее как минимум сохранить ее в регистр и потом записать в память.

59 minutes ago, krux said:

поясните ваше видение работы авторефреша для начала. для максимальной производительности это очень важно. для исключения глюков с физической стороны, а не со стороны вашего видения алгоритма.

запросы на строку burst-ом идут пусть 768 раз в секунду, те есть время на рефреш. немного съест работа проца, но он медленный, те авторефреша должно хватить с большим запасом.

[krux 8]

5 minutes ago, Nagisa said:

запросы на строку burst-ом идут пусть 768 раз в секунду, те есть время на рефреш. немного съест работа проца, но он медленный, те авторефреша должно хватить с большим запасом.

это неправильный подход. авторефреш на то и авторефреш, что вы должны организовать таймер и запускать этот процесс по таймеру, не реже.

Исключение может быть только одно - если вы делаете нечто, по сути похожее на RAMDAC и у вас запись в память идёт циклом постоянно.

[Nagisa 0]

1 hour ago, krux said:

это неправильный подход. авторефреш на то и авторефреш, что вы должны организовать таймер и запускать этот процесс по таймеру, не реже.

Исключение может быть только одно - если вы делаете нечто, по сути похожее на RAMDAC и у вас запись в память идёт циклом постоянно.

согласно даташита, модуль, требует 4096 циклов автоматической регенерации каждые 64мс; выполнение команды автоматической регенерации каждые 15625мкс необходимо и достаточно для полной регенерации. альтернативный вариант - 4096 циклов каждые 64мс.

у меня строка 20.67мкс, кадр 15.87мс

считывание в буфер строки 1.1мкс

максимальная интенсивность работы процессора по загрузке памяти - 1 запрос за 2.5мкс, в длинном цикле у меня уйдет 123нс на обслуживание 1 запроса.

получается, что память будет занята ~2.2мкс, а 18.55мкс будет заниматься авторефрешем - те 2400 циклов рефреша на каждые 20.67мкс, что полностью закрывает требования памяти по рефрешу.

PS: данные исходя из 130MHz

 

 

[Flip-fl0p 4]

2 часа назад, Nagisa сказал:

он жизненно важен - ибо у меня не только обслуживание процессора, но и VGA контроллер.

Соответственно в начале каждой строки я читаю bust-ом из SDRAM в памяти самой ПЛИС строку и потом уже ее вывожу

вот и получается у меня 3 режима работы. причем если на чтение процу я могу сказать - подожди, те выдать RPLY позднее, то с записью все плохо - я должен ее как минимум сохранить ее в регистр и потом записать в память.

запросы на строку burst-ом идут пусть 768 раз в секунду, те есть время на рефреш. немного съест работа проца, но он медленный, те авторефреша должно хватить с большим запасом.

Да нет такой необходимости в burst-режиме. Просто контроллер SDRAM получает команду прочитать с какого-то определенного адреса, количество слов, равное длине строки. Поймите же. burst-режим никак не ускоряет работу с памятью. Просто за одну команду к памяти вы получите\запишите не одно слово данных, а количество слов равное длине burst. 

В VGA - активные данные (Date enable - '1') всегда снабжены back_porch и front_porch. Соответственно на вычитывание строки есть время равное back_porch + front_porch. 

Более того, за время между последним активным пикселем прошлого кадра и первым активным пикселем нового кадра обычно проходит достаточно времени, чтобы процессор записал новую картинку. Если кто-то не успевает то в работу включается алгоритм тройной буфферизации. 

Обратите внимание, что обычно, когда SDRAM контроллер постоянно занят обслуживанием VGA, то рефреш памяти скорее всего не нужен. Особенно, когда вы делаете precharge для всех банков ( адрес A[10] = '1' при выдаче команды precharge).

Ещё раз рекомендую обратить внимание на следующий интерфес работы с SDRAM 

----------------------------- Командный интерфейс-----------------------------------------------------------
cmd_addres              : in     std_logic_vector(bank_width + row_width + colums_width - 1 downto 0);  -- стартовый адрес откуда начать работу             
cmd_num_words           : in     std_logic_vector(bank_width + row_width + colums_width - 1 downto 0);  -- сколько слов надо отработать 
cmd_write_req           : in     std_logic;                                                             -- Тип запроса 
cmd_ready               : out    std_logic;                                                             -- Готовность отработать новый запрос 
cmd_valid               : in     std_logic;                                                             -- Валидность команды запроса 

Контроллер SDRAM - получает задание на запись\чтение определенного количества слов, с начального адреса (смещение). Генерацией адресации занимается сам контроллер. 

[Nagisa 0]

44 minutes ago, Flip-fl0p said:

Да нет такой необходимости в burst-режиме. Просто контроллер SDRAM получает команду прочитать с какого-то определенного адреса, количество слов, равное длине строки. Поймите же. burst-режим никак не ускоряет работу с памятью. Просто за одну команду к памяти вы получите\запишите не одно слово данных, а количество слов равное длине burst. 

ну так это мне и нужно - те быстро считать в буфер всю строку которую я буду выводить потом на экран

на частоте в 130MHz у меня уйдет на это ~1.1мкс в худшем случае - те всего 72 клока VGA (всего у меня их 320 на это)

44 minutes ago, Flip-fl0p said:

В VGA - активные данные (Date enable - '1') всегда снабжены back_porch и front_porch. Соответственно на вычитывание строки есть время равное back_porch + front_porch. 

именно

и я собираюсь в это время считать строку в буфер

 

 

44 minutes ago, Flip-fl0p said:

Более того, за время между последним активным пикселем прошлого кадра и первым активным пикселем нового кадра обычно проходит достаточно времени, чтобы процессор записал новую картинку. Если кто-то не успевает то в работу включается алгоритм тройной буфферизации. 

Обратите внимание, что обычно, когда SDRAM контроллер постоянно занят обслуживанием VGA, то рефреш памяти скорее всего не нужен. Особенно, когда вы делаете precharge для всех банков ( адрес A[10] = '1' при выдаче команды precharge).

Ещё раз рекомендую обратить внимание на следующий интерфес работы с SDRAM 

----------------------------- Командный интерфейс-----------------------------------------------------------
cmd_addres              : in     std_logic_vector(bank_width + row_width + colums_width - 1 downto 0);  -- стартовый адрес откуда начать работу             
cmd_num_words           : in     std_logic_vector(bank_width + row_width + colums_width - 1 downto 0);  -- сколько слов надо отработать 
cmd_write_req           : in     std_logic;                                                             -- Тип запроса 
cmd_ready               : out    std_logic;                                                             -- Готовность отработать новый запрос 
cmd_valid               : in     std_logic;                                                             -- Валидность команды запроса 

Контроллер SDRAM - получает задание на запись\чтение определенного количества слов, с начального адреса (смещение). Генерацией адресации занимается сам контроллер. 

обязательно посмотрю

 

сейчас думаю переделать контроллер введя унификацию - те запись 1 слово, а вот чтение всегда 32 слова, для чтения строки я это буду повторять через цикл обслуживания шины - те 4 раза.

получится всего два режима, что явно проще текущей ситуации где 3 режима.

 

[krux 8]

а чтение обратно в процессор не производится?

а то организоавть очередь на 32 слова на запись какбы вообще не проблема, даже с учетом рефреша.

и исходя из того, что запись в память все же выборочная, не циклическая, и непонятно в какую часть памяти - от авторефреша вам отказываться нельзя. причем привязывать его лучше к окончанию очереди записи.

пустая очередь? меньше четверти таймаута до рефраша? следующий барст на чтение до конца рефреша не придёт? уходим на авторефреш, сбрасываем таймаут

имхо

[des00 25]

18 hours ago, RobFPGA said:

Это  не эквивалентные описания  соответственно и результат после  синтеза  будет другим.

более того, там еще и защелки. run_cmd не определен в половине случаев))

[des00 25]

8 hours ago, Nagisa said:

сейчас думаю переделать контроллер введя унификацию - те запись 1 слово, а вот чтение всегда 32 слова, для чтения строки я это буду повторять через цикл обслуживания шины - те 4 раза.

получится всего два режима, что явно проще текущей ситуации где 3 режима.

ИМХО зря вы все в одном ядре пытатетесь решить. @Flip-fl0p дело гуторит. Сделайте быстрый контроллер SDRAM и к нему контроллер ваших очередей. Получится функционально, расширяемо и надежно.

[Nagisa 0]

в итоге продвинулся вперед, а именно сделал:

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

 

мне приходит в голову только автомат, но правильно ли так ?

 

[Nagisa 0]

в итоге все переехало в автоматы

пришлось правда один сигнал управления протаскивать через global clock

таки 2й циклон достаточно медленный.....

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

[Flip-fl0p 4]

21 час назад, Nagisa сказал:

в итоге все переехало в автоматы

пришлось правда один сигнал управления протаскивать через global clock

таки 2й циклон достаточно медленный.....

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

А Вы упорный товарищ. Всё-же оставили режим burst. И стоило столько времени убивать на его поддержку ?

[Nagisa 0]

On 3/22/2021 at 6:39 PM, Flip-fl0p said:

А Вы упорный товарищ. Всё-же оставили режим burst. И стоило столько времени убивать на его поддержку ?

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

[Flip-fl0p 4]

12 часов назад, Nagisa сказал:

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

Ещё проще, чем с ним ). Вам же уже объясняли, что burst никак не ускоряет работу с памятью.  А поддержка этого режима сильно усложняет логику работой контроллера. 

[Nagisa 0]

On 3/24/2021 at 12:03 PM, Flip-fl0p said:

Ещё проще, чем с ним ). Вам же уже объясняли, что burst никак не ускоряет работу с памятью.  А поддержка этого режима сильно усложняет логику работой контроллера. 

никто не объяснил как мне обойтись без него ;-)

согласно ТЗ мне необходимо читать видеопоток со скоростью 11796480 слов в секунду , иначе говоря по одному слову за ~84нс

цикл с памятью получается минимум 8 операций с частотой 92MHz - те ~86нс

те я в принципе не успею даже на VGA выплюнуть поток, а мне еще надо облуживать 2 системы которые тоже хотят читать и писать в память (можно перейти на CL2 это даст экономию но проблемы не решит)

если же я использую bust то необходимые 256 слов на строку я читаю в 4 захода по 32 слова и трачу на все это ~3,5мкс  против ~22мкс если бы это было одиночное чтение, и успеваю с минимальными задержками обслуживать других абонентов

 

на счет сильно усложняет - я минимизировал изменение логики - те отличие только в длине цикла + времени подачи команды BURST_TERMINATE