[Вадим Н. 1]

Всем привет,

У меня задача: запрограммировать на GW2A18 определённый алгоритм управления устройством с обратной связью.

У кого есть опыт проектирования чего-то подобного, посмотрите пожалуйста.

 

Термины и названия блоков навеяны одной презентацией GoWin. См. скрин:

 

 

Надо сказать, что первая версия "дизайна" толком не работала, и блок-схема, нарисованная уже постфактум, (я её здесь не привожу) похожа на кашу из модулей.

По новой блок-схеме есть сомнения и вопросы:

"Буфер" - это модуль который накапливает актуальную телеметрию на случай если она понадобится для отправки по SPI. Как он реализуется я пока не знаю.

"Регистр настроек работы" - это вот главный вопрос. Вообще-то это массив. Где-нибудь 16x64. Не пойму: это должно быть реализовано как память, или можно реализовать и доступ по адресу, и непосредственный доступ к отдельным регистрам для параллельного чтения/записи.

Вот сценарий их использования:

• каждому регистру соответствует один писатель и много читателей
• всем модулям кроме SPI регистры нужны индивидуально
• SPI-модулю регистры нужны как массив

Может кто подскажет какие-нибудь образцы хорошего стиля на эту тему )

[stealthisname 7]

если считать, что MC управляет работой устройства через SPI controller и видит регистры настроек как память, то SPI controller может сформировать сигналы чтения/записи, сигналы адреса и данных

для МС помимо возможности записать настройки необходима возможность считать информацию о работе устройства, и самое главное - считать информацию о количестве данных в buffer, а значит в памяти помимо настроек для записи/чтения MC ещё должны быть регистры только для чтения

пример для меньшего количества регистров

module OSReg
(
    input       clk, rst,
    input       wr_en,
    input       rd_en,
    input       [2:0] addr,
    input       [15:0] wr_data,
    output reg  [15:0] rd_data,
    //
    output      [15:0] settings0,
    output      [15:0] settings1,
    output      [15:0] settings2,
    output      [15:0] settings3,
    input       [15:0] status0,
    input       [15:0] status1,
    input       [15:0] status2,
    input       [15:0] status3
);

reg  [15:0] settings_ram [0:3];

always @(posedge clk)
begin
    if (rst)
    begin
        settings_ram[0] <= 0;
        settings_ram[1] <= 0;
        settings_ram[2] <= 0;
        settings_ram[3] <= 0;
    end
    else
    begin
        if (wr_en) settings_ram[addr] <= wr_data;
    end
end

assign settings0 = settings_ram[0];
assign settings1 = settings_ram[1];
assign settings2 = settings_ram[2];
assign settings3 = settings_ram[3];

wire [15:0] settings_ram_rd [0:7];
assign settings_ram_rd[0] = settings0;
assign settings_ram_rd[1] = settings1;
assign settings_ram_rd[2] = settings2;
assign settings_ram_rd[3] = settings3;
assign settings_ram_rd[4] = status0;
assign settings_ram_rd[5] = status1;
assign settings_ram_rd[6] = status2;
assign settings_ram_rd[7] = status3;

always @(posedge clk)
begin
    if (rst)
    begin
        rd_data <= 0;
    end
    else
    begin
        if (rd_en) rd_data <= settings_ram_rd[addr];
    end
end

endmodule

 

в примере, если МС записывает данные, то SPI controller формирет wr_en, addr, wr_data
если МС считывает данные, то SPI controller формирет rd_en, addr и отправляет в MC  rd_data 

в примере  регистры с 0 по 3  - регистры на запись и чтение, с которых остальные блоки могут брать переданные с MC настройки работы , регистры с 4 по 7 - регистры только для чтения, куда остальные блоки могут сообщать для MC состояние своей работы и где будет храниться взятая с buffer информация о количестве данных, которые может считать MC через  SPI controller

[Maverick_ 15]

У процессора есть возможность подключения SRAM памяти?

если есть то лучше сделать - fpga имитирует работу SRAM памяти - процессор видит fpga как внешнюю SRAM память

тогда берете двухклоковую память один порт заводите на на логику имитирующую SRAM память второй порт на Вашу логику

+ 1-2 сигнала от процессора (GPIO) для квітірования операций (готовность данних, какие-то команди)

В случае с SPI тоже самое процессор мастер. FPGA слейв. Есть протокол общения. Логика FPGA декодирует протокол.

В зависимости например данние или команди пишет в блочную память (двухклоковую и двухпортовую) по определенним адресам команди/данние

И дает сигнал квитирования дальнейшей логике для дальнейшей обработки...

по 1-2 сигнала от процессора (GPIO) для квітірования операций - логика понимает по каким адресам надо считать 

Для процессора наоборот - логика пишет в память и квитирует по gpio (возможно на преривание для процессора)

Таким образом можно передавать информацию размером в несколько сотен байт/слов  

Можно организовать даблбуффер в FPGA  для обмена...

пришла команда с процессора дай мне такие то данние - мастер видает N байт/слов(главное клок SPI) - логика слейва видает нужную информацию

 

[Вадим Н. 1]

On 7/6/2024 at 2:25 PM, stealthisname said:

а значит в памяти помимо настроек для записи/чтения MC ещё должны быть регистры только для чтения

- ну да, так всё и планируется. в ближайшее время сделаю примерчик в подтверждение концепции и закину сюда. надеюсь ))

 

On 7/6/2024 at 5:08 PM, Maverick_ said:

тогда берете двухклоковую память один порт заводите на на логику имитирующую SRAM память второй порт на Вашу логику

+ 1-2 сигнала от процессора

Про Dual Port SRAM - красиво, но у нас пока точно будет SPI.

 

 

[Maverick_ 15]

On 7/8/2024 at 1:52 PM, Вадим Н. said:

- ну да, так всё и планируется. в ближайшее время сделаю примерчик в подтверждение концепции и закину сюда. надеюсь ))

 

Про Dual Port SRAM - красиво, но у нас пока точно будет SPI.

 

 

Память внутри fpga с помощью нее можно правильно организовать обмен

[Вадим Н. 1]

вот прототип.
не сказать, что это прям концепт-пруф.
не могу понять, почему не проходит тест под iverilog хотя под Modelsim вроде бы норм.

собирается под quartus и gowin. В обоих случаях занимает примерно одинаковое число д-триггеров. Число не сильно отличается от <число бит в слове> ** 2 * <число бит в шине адреса> - <не используемая часть см. gen_notused.v>

SRAM-память, понятно, не выводится из такого описания.

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

не уверен что этого достаточно чтобы однозначно сделать выбор в пользу такой схемы а не нормальной памяти.
Подкупает возможность произвольно читать регистры. и не морочиться в каждом модуле-читателе с интерфейсом к SRAM.
 

Минусы такие что
1. можно упереться в ресурсы и потом всё же придётся переписывать всё с нормальным доступом к SRAM.
2. может в реальных условиях эта схема вообще не заработает.
а ещё будет смешно если окажется что обмен с памятью операция на столько простая что вообще нечего было разводить вот это всё.

М.б. сделаю ещё примерчик пригодный для заливки на макетку вот такую.

test_conf.7z

[Maverick_ 15]

я не вижу предварительной буферизации перед записью в память; арбитра доступа нет...

[Вадим Н. 1]

33 minutes ago, Maverick_ said:

я не вижу предварительной буферизации перед записью в память; арбитра доступа нет...

[stealthisname 7]

  

9 часов назад, Вадим Н. сказал:

2. может в реальных условиях эта схема вообще не заработает.

если [собирается под quartus и gowin] означает синтез и имплементацию, то откуда подозрения, что может не заработать?

[sazh 5]

Просто прогнал. Вопрос:

module do_sum 
            sum <= foo + bar + baz;

Все входные и выходные данные 32р. Выходные должны быть  с расширением разрядной сетки = 34р. Иль переноса у такого сумматора никогда не будет ?

[Вадим Н. 1]

18 hours ago, sazh said:

Просто прогнал. ...переноса у такого сумматора никогда не будет ?

это просто тест. можно подобрать входные данные. С реальной задачей тут перекликается только структура, но не какие-то расчёты. там сумматор, сдвиг и т.п. это просто чтобы что-то было: читатели-писатели регистров настроек.

остался мелкий вопрос:  почему этот колхоз не заработал под icarus-verilog? (Icarus Verilog version 12.0) вот сижу вчитываюсь в IEEE Standard Verilog 2001 раздел 5.3 The stratified event queue. Мне кажется, собака именно здесь зарыта. 

ну и основной вопрос: надо придумать пример, прототип, где настройки, все регистры настроек хранятся во встроенной SRAM. И ответить на вопрос: на сколько это удобно в плане разработки. Т.е., к примеру, очередной модуль подключить к этим настройкам чтобы он читал-писал. Где-то будет "арбитр доступ к памяти" ))

On 7/22/2024 at 3:53 PM, Maverick_ said:

я не вижу предварительной буферизации перед записью в память; арбитра доступа нет...

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

[Вадим Н. 1]

20 hours ago, stealthisname said:

  если [собирается под quartus и gowin] означает синтез и имплементацию, то откуда подозрения, что может не заработать?

не знаю. просто допускаю такое.

нужен пример, такой действующий образец. думаю половину ПЛИС задействовать под SPI-мастер который будет просто гонять тестовые данные изображая из себя внешний процессор,, а другую часть ПЛИС чисто проводами подключить, чтобы там SPI-слейв был и все вот эти модули - читатели-писатели настроек. Не знаю. если сделаю - сюда закину.

[sazh 5]

initial wr = 0;
output reg [W_CONF-1:0] avr = 0,
output reg [W_CONF-1:0] stop = 0
output reg [W_CONF-1:0] sum = 0
Это не подлежит имплементации в железо и служит для целей моделирования, имитация железа по включению питания, если плис на базе статической ячейки

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

Наверно лучше внести сигнал ресет, и это точно никогда памятью не станет.

У Вас очень оригинально расписан проект верхнего уровня. Без RTL просмотрщика трудно что то воспринять и это наверняка причина почему не заработало в другой среде.

Вот это каким то образом в Квартусе накладывается на проект

    gen_notused #(
        CBM,
        CBW_NOTUSED
    ) genn (
        conf_bus[CBM:CBW_NOTUSED]
    );
 

Хотя если это убрать - проект синтезируется и моделируется с Вашим тестбенчем в квесте.

Переделайте по рабоче крестьянскому, уверен помучаетесь.

do_sum do_sum_inst
(
    .clk(clk_sig) ,    // input  clk_sig
    .foo(foo_sig) ,    // input [W_CONF-1:0] foo_sig
    .bar(bar_sig) ,    // input [W_CONF-1:0] bar_sig
    .baz(baz_sig) ,    // input [W_CONF-1:0] baz_sig
    .sum(sum_sig)     // output [W_CONF-1:0] sum_sig
);

defparam do_sum_inst.W_CONF = 3;

gen_notused gen_notused_inst
(
    .conf_bus(conf_bus_sig)     // output [CBM:CBW_NOTUSED] conf_bus_sig
);

defparam gen_notused_inst.CBM = 23;
defparam gen_notused_inst.CBW_NOTUSED = 21;
 

Не знаю, кому сейчас это нужно в плане разработки. Сейчас интерфейсы с периферийными устройствами разрабатывают под систему на кристалле,

которые объединяются с помощью системной шины ( у кого какая). Львиную долю разработки собирают из кубиков и встраивают в адресное пространство

любимого производителя.