Frage zum Coding Style eines normalen RAMs mit Initialisierung

[Michael F. (mifi)]

Hallo zusammen,

ich versuche immer noch die LM32-CPU auf einem Altera FPGA zu portieren
wo auch das Debugging mit dem JTAG später möglich sein soll.

Im original Source wird z.B. ein Monitor RAM (lm32_monitor_ram.v) 
erwendet:

lm32_monitor_ram ram (
    // ----- Inputs -------
    .ClockA             (clk_i),
    .ClockB             (clk_i),
    .ResetA             (rst_i),
    .ResetB             (rst_i),
    .ClockEnA           (`TRUE),
    .ClockEnB           (`FALSE),
    .AddressA           (MON_ADR_I[10:2]),
    .AddressB           (9'b0),
    .DataInA            (write_data),
    .DataInB            (32'b0),
    .WrA                (write_enable),
    .WrB                (`FALSE),
    // ----- Outputs -------
    .QA                 (data),
    .QB                 (dataB)
    );

Weiterhin sind die Parameter wie folgt gesetzt:

CSDECODE_B   = "0b000" ;
CSDECODE_A   = "0b000" ;
WRITEMODE_B  = "NORMAL" ;
WRITEMODE_A  = "NORMAL" ;
GSR          = "ENABLED" ;
RESETMODE    = "SYNC" ;
REGMODE_B    = "NOREG" ;
REGMODE_A    = "NOREG" ;
DATA_WIDTH_B = 9 ;
DATA_WIDTH_A = 9 ;

Intern wird dies auf ein DP8KC Primitive abgebildet, 8K True Dual Port 
Block RAM. Für mich sieht das jetzt aber so aus als wenn hier die Dual
Port Funktion nicht verwendet wird, sondern nur ein einfaches RAM, kann
das sein?

Bei den Altera Beispielen habe ich die Möglichkeit
"Old Data Read-During-Write Behavior" oder
"New Data Read-During-Write Behavior" zu verwenden.

Old Data Read-During-Write Behavior

module single_clk_ram(
   output reg [7:0] q,
   input [7:0] d,
   input [6:0] write_address, read_address,
   input we, clk
);

reg [7:0] mem [127:0];
always @ (posedge clk) begin
   if (we)
      mem[write_address] <= d;
   q <= mem[read_address]; // q doesn't get d in this clock cycle
end

endmodule

New Data Read-During-Write Behavior

module single_clock_wr_ram(
   output reg [7:0] q,
   input [7:0] d,
   input [6:0] write_address, read_address,
   input we, clk
);

reg [7:0] mem [127:0];
always @ (posedge clk) begin
   if (we)
      mem[write_address] = d;
   q = mem[read_address]; // q does get d in this clock cycle if
                          // we is high
end

endmodule

Was ist hier nun die richtige Version?
Und das andere Problem, wie kann man das RAM vorher mit Daten 
initialisieren (siehe Anhang original lm32_monitor_ram)?

Viele Grüße,
Michael

[Michael F. (mifi)]

Hallo,

habe die Lösung gefunden.
Im Projekt "https://github.com/m-labs/lm32"; gibt es die Datei
"lm32_dp_ram.v" welche das Dual Port RAM entsprechend umsetzt.

Gruß,
Michael

[Daniel (Gast)]

Michael Fischer schrieb:
> Für mich sieht das jetzt aber so aus als wenn hier die Dual
> Port Funktion nicht verwendet wird, sondern nur ein einfaches RAM, kann
> das sein?
Ja. Der Port B wird hier nicht verwendet.

> Was ist hier nun die richtige Version?
http://www.latticesemi.com/~/media/Documents/UserManuals/EI/FPGALibrariesReferenceGuide31.pdf
Auf Seite 192 unten, sieht man die Möglichkeiten für WRITEMODE. Im 
Orignal wird "NORMAL" verwendet. Es gibt noch "WRITETHROUGH" und 
"READBEFORE". Dazu hast Du ja die Pendants für Altera schon gefunden.
Mir ist hier auch nicht klar, welches Verhalten für Lattice 'normal' 
ist.

Dieser Punkt spielt aber nur eine Rolle, wenn man auf einer Adresse 
gleichzeitig schreibt und liest. Dieser Fall ist mir bisher noch nicht 
begegnet.

Die dritte Frage hat sich ja schon erledigt.

Daniel

[Lattice User (Gast)]

Daniel schrieb:

> Mir ist hier auch nicht klar, welches Verhalten für Lattice 'normal'
> ist.
>

Aus dem ECP3 Handbuch:

In NORMAL mode, the output data does not change or get updated, during 
the write operation. This mode is supported for all data widths.

In WRITETHROUGH mode, the output data is updated with the input data 
during the write cycle. This mode is supported for all data widths.

In READBEFOREWRITE mode, the output data port is updated with the 
existing data stored in the write address, during a write cycle. This 
mode is supported for x9, x18 and x36 data widths.

[Daniel (Gast)]

Danke für die Aufklärung!

[Michael F. (mifi)]

Hallo,

Danke für die Info.

Was mir noch gefehlt hat war das lm32_monitor.mem File. Irgendwie habe
ich nicht verstanden wie ich das aus dem lm32_monitor_ram.v extrahieren
oder wieder herstellen kann.

Also habe ich es mal anderes versucht, und den Bereich 0x0 - 0x800 von
einem Lattice Evalboard ausgelesen. Dies wurde jetzt als
lm32_monitor.mem verwendet. Es sieht so aus als würde es immer noch
beim Original funktionieren. Mich wundert es aber schon etwas das der
ausgelesene Bereich fast voll ist. In der original Datei 
lm32_monitor_ram.v sieht es aber nicht so aus.

Gruß,
Michael

[Daniel (Gast)]

Michael Fischer schrieb:
> Mich wundert es aber schon etwas das der
> ausgelesene Bereich fast voll ist.
Womit voll? Mit 0xFF?

Daniel

[Lattice User (Gast)]

Michael Fischer schrieb:
> Hallo,
>
> Danke für die Info.
>
> Was mir noch gefehlt hat war das lm32_monitor.mem File. Irgendwie habe
> ich nicht verstanden wie ich das aus dem lm32_monitor_ram.v extrahieren
> oder wieder herstellen kann.

Ist auch nicht einfach, da das Mapping vom INIT_VAL zu den einzelnen 
Bits im RAM in den verschiedenen Konfigurationen nicht dokumentiert ist, 
zumindesten habe eine Docu besiher nicht gefunden :-(

[Michael F. (mifi)]

Hallo Daniel,

nicht mit 0xFF, schau mal in den Anhang.

Gruß,
Michael

[Daniel (Gast)]

Michael Fischer schrieb:
> lm32_monitor.mem
Das sind 512 * 4 Byte = 2048 Byte

In lm32_monitor_ram.v sind Varianten für alle Lattice-Chips drin.
Wenn man sich z.B. auf den MachXO2 beschränkt, sieht man das da
12 Zeilen á 40 Byte +
 1 Zeile mit 22 Byte
und das ganze 4 Mal gefüllt sind: (12 * 40 + 22) * 4 = 2008 Byte

stimmt also ganz gut überein (da sind ja auch ein paar Nullen am Ende).

Interessant wäre der .asm oder .c-Quelltext, um sich das mem-File selbst 
zu erzeugen bzw. um Anpassungen vornehmen zu können.

Daniel