[Plain 168]

Начнём с начала. Буфер 16 байт, запись в него пачками по 8 байт — ну т.е. методом дедукции, писать строго только тогда, когда та его половина вся прочитана, а потому свободна.

 

Или же, Вы умолчали, что пишущему без разницы, прочитано или нет,— он пишет, уничтожая данные.

[Mad_kvmg 0]

16 minutes ago, Plain said:

Начнём с начала. Буфер 16 байт, запись в него пачками по 8 байт — ну т.е. методом дедукции, писать строго только тогда, когда та его половина вся прочитана, а потому свободна.

 

Или же, Вы умолчали, что пишущему без разницы, прочитано или нет,— он пишет, уничтожая данные.

Естественно пишем только тогда, когда есть место для записи. 

Глобальная задача этой схемы, чтобы данные всегда были готовы к чтению. Но достичь этого с таргетом 250МГц не удалось, пришлось уже пожертвовать тактом,

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

[Plain 168]

Глубина буфера единица, они и не могли быть готовы, нужна ещё половина, т.е. всего 24 байт.

[Mad_kvmg 0]

Коды Rice, на одну запись в 8 байт может быть 8 чтений по одному байту, а может и все 8 байт будут прочитаны.  

[Plain 168]

Т.е. эту фразу нам считать Вашим доказательством достаточности для буфера 16-ти байт?

[RobFPGA 27]

Приветствую!

3 hours ago, Plain said:

Т.е. эту фразу нам считать Вашим доказательством достаточности для буфера 16-ти байт?

Опять же теоретически - достаточно иметь буфер как минимум на ширину входного слова  (при условии что максимальная ширина выходного слова не более 2x от входного). Увеличивая  ширину буферного регистра можно вроде как бы уменьшить простои  при потоковой записи/чтении. НО  при этом возрастут накладные на mux (ширина ведь больше) и то - это имеет смысл если  средняя скорость чтения равна скорости записи. Что в данном случае  явно не будет. 
Практически - буферный регистр в 2х от  входной ширины  вполне достаточен.

 

Удачи! Rob.

[Plain 168]

Скорость чтения здесь всегда больше скорости записи, 10 > 8.

[Mad_kvmg 0]

1 hour ago, Plain said:

Скорость чтения здесь всегда больше скорости записи, 10 > 8.

Это не так. Ширина слова (скорость) чтения переменная величина от 1 до 10 байт, зависящая от входных данных. Для каждого набора входных данных это распределение будет свое. 

[Plain 168]

Определите худший случай, он всегда в единственном числе, иначе задачу не решите никогда.

[des00 25]

14 hours ago, Plain said:

Начнём с начала. Буфер 16 байт, запись в него пачками по 8 байт — ну т.е. методом дедукции, писать строго только тогда, когда та его половина вся прочитана, а потому свободна.

Если эта парадигма верная, запись всегда 8 байт, а чтение произвольно от 1 до 10, то

module pipa (input iclk, iwrite, iread, bit [3 : 0] iread_num, bit [7 : 0] idat [8], output bit [7 : 0] odat[10], bit oval, ofull, oempty);

  wire write  = iwrite & !ofull;
  wire read   = iread  & !oempty;

  bit [4 : 0] cnt; // 24 used

  bit [7 : 0] buffer [24];

  assign ofull  = (cnt >= 16);
  assign oempty = (cnt < iread_num);

  always_ff @(posedge iclk) begin
    case ({write, read})
      2'b10 : cnt <= cnt + 8;
      2'b01 : cnt <= cnt - iread_num;
      2'b11 : cnt <= cnt + 8 - iread_num;
    endcase
    //
    if (write) begin
      for (int i = 0; i < 8; i++) buffer[i] <= idat[7-i];   // reverse order LSB first
      buffer[8  : 15] <= buffer[0 :  7];
      buffer[16 : 23] <= buffer[8 : 15];
    end
    //
    odat <= '{default : '1};
    if (read) begin
        for (int i = 0; i < iread_num; i++) begin
            odat[i] <= buffer[cnt-1-i];
        end
    end
    //
    oval <= read;
  end

endmodule


module tb;

  bit iclk, iwrite, iread;
  bit [3 : 0] iread_num;
  bit [7 : 0] idat [8];
  bit [7 : 0] odat[10];
  bit oval, ofull, oempty;

  pipa popa(.*);

  initial begin
    iclk <= 1'b0;
    #5ns forever #5ns iclk = !iclk;
  end


  initial begin
    int tmp, tmpr;
    //
    iwrite <= 1'b0;
    iread  <= 1'b0;
    //
    tmp = 0;
    tmpr = 1;
    iread_num <= tmpr;
    fork
      repeat (9) begin
        @(posedge iclk iff !ofull);
        iwrite <= 1'b1;
        for (int i = 0; i < 8; i++) begin
          idat[i] <= tmp + i;
        end
        tmp += 8;
        @(posedge iclk);
        iwrite <= 1'b0;
      end
      //
      forever begin
        repeat (4) @(posedge iclk);
        @(posedge iclk iff !oempty)
        iread <= 1'b1;
        iread_num <= tmpr;
        @(posedge iclk);
        iread <= 1'b0;
        tmpr++;
        if (tmpr > 10) tmpr = 1;
      end
    join
  end

endmodule

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

ЗЫ. маскирование выходных байт сделано для простоты наблюдения вейвформ. в итоговом коде можно убрать)

[RobFPGA 27]

Приветствую!

17 minutes ago, des00 said:

Если эта парадигма верная, запись всегда 8 байт, а чтение произвольно от 1 до 10, то

Не совсем -  запись пакетами произвольной дины  по шине 8 байт - соответственно последнее слово в пакете может иметь 1..8 байт. Чтение от 1 до 10 байт за такт.

Фактически это задача разбиение непрерывного потока байт (приходящих в виде пакетов произвольной длинны)  на поток сообщений длинна которых (в общем случае произвольна) и определяется по неким признакам в этом потоке байт.

 

Удачи! Rob.

P.S.  Так что задачка не о классическом бассейне с двумя трубами,  а о том как эффективнее черпать воду из оного  ведрами  

[des00 25]

23 minutes ago, RobFPGA said:

Не совсем -  запись пакетами произвольной дины  по шине 8 байт - соответственно последнее слово в пакете может иметь 1..8 байт. Чтение от 1 до 10 байт за такт.

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

[new123 0]

1 hour ago, des00 said:

, но по записи - обычный сдвиговый регистр)

спасибо, забрал в копилку такой подход, раньше не додумался =)

[des00 25]

On 6/15/2020 at 4:26 PM, new123 said:

спасибо, забрал в копилку такой подход, раньше не додумался =)

вообще в ЦОС делах сдвиговые регистры сила) Если задача последовательных вычислений, реализуется на сдвиговых регистрах, то экономим 1 такт на мультиплексировании (берем уже с регистра) и нет затыка по времянке (минимальное количество слоев логики в регистре). Да, есть перерасход регистров, но на современных архитектурах это не проблема)

[new123 0]

1 hour ago, des00 said:

вообще в ЦОС делах сдвиговые регистры сила)

я уже два дня хожу в ужасе, сколько кода мне нужно переделать, точнее заново отладить, с таким подходом =))