Dual-BRAM-Benutzung bei Xilinx undurchsichtig

[Bert (Gast)]

Ich habe Probleme, das Verhalten eines Block-RAMs bei Xilinx und Vivado 
zu simulieren. Es kann nichts hineingeschrieben oder herausgelesen 
werden.

Ich habe den Verdacht, dass etwas nicht richtig eingebunden ist, obwohl 
kein Fehler gemeldet wird. Die Komponente als solche ist da.

Ich erkläre am Besten die Architektur: Benuzt wird ein Dual-RAM der 
Grösse 24 Bit und 64k. Das entstehende VHO in der Liste sieht auch 
vielversprechend aus:

COMPONENT delay64k
  PORT (
    clka : IN STD_LOGIC;
    wea : IN STD_LOGIC_VECTOR(0 DOWNTO 0);
    addra : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
    dina : IN STD_LOGIC_VECTOR(23 DOWNTO 0);
    clkb : IN STD_LOGIC;
    addrb : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
    doutb : OUT STD_LOGIC_VECTOR(23 DOWNTO 0)
  );
END COMPONENT;

Ich schreibe auf A rein und lese mit 50.000 samples verzögert wieder 
aus. Es kommt aber nichts. Der Simulator zeigt auch nicht, das etwas 
geschrieben wäre.

Aufgefallen ist mir:

Es werden 44 RAMs benutzt, was ich seltsam finde. Mit keiner Kombination 
aus 32/36 und 16 sowie kann ich bei den gewünschten 24 Bit diese 44 RAMs 
erklären. Angeblich haben die 18Bit. Soweit ich es verstehe, hätte ich 
32+16 = 48 erwartet.

Ferner werden zwei Clock-Eingänge gezeigt, obwohl ich ein "simple dual 
port RAM" verwende mit "common clock".

Dann habe ich mir die Details angesehen und finde in den 
Simulationsdateien u.a. im "blk_mem_gen_v8_4.vhd" Dinge, die ich so 
nicht vorgegeben hatte:

1)  C_FAMILY                     : string := "virtex7";
    C_XDEVICEFAMILY              : string := "virtex7";

    
2)  C_AXI_TYPE                   : integer := 1;  

    
3)  C_WRITE_WIDTH_A              : integer := 9;
    C_READ_WIDTH_A               : integer := 9;
    C_WRITE_DEPTH_A              : integer := 2048;
    C_READ_DEPTH_A               : integer := 2048;

1) eingestellt war "Artix"!
2) eingestellt war "native" und nicht AXI!
3) passt irgendwie nicht zu den Breiten und Tiefen oben!

Stimmt das so oder produziert der Mist?

Ich habe das alles gelöscht, die Einstellungen wiederholt, erhalte aber 
das gleiche Ergebnis.

[Klakx (Gast)]

Wie sieht die testbench aus?
Reset am Anfang mindestens 100 ns?

[Duke Scarring (Gast)]

Klakx schrieb:
> Reset am Anfang mindestens 100 ns?
Reset am Block-RAM?
Seit wann gibt es das?
Doch maximal nur für ein Register hinter dem Ausgang.

Bert schrieb:
> Benuzt wird ein Dual-RAM der
> Grösse 24 Bit und 64k
Also 1572864 Bits. Das ergibt 48 RAMB36 á 16384 Bits (wenn die 
Paritybits nicht verwendet werden).

> Ich schreibe auf A rein und lese mit 50.000 samples verzögert wieder
> aus. Es kommt aber nichts. Der Simulator zeigt auch nicht, das etwas
> geschrieben wäre.
Bitte eine Testbench und den Signalverlauf zeigen...

Duke

[Christian R. (supachris)]

Reset ist am BRAM Fifo ganz wichtig und muss da mindestens 5 Takte des 
langsamsn Taktes anliegen.

Hast du vielleicht einen AXI BRAM? Da ist default der Reset negativ, 
schöne Falle.

Ansonsten kannst du den Dual Ported BRAM auch per VHDL beschreiben, ist 
meist übersichtlicher als ein Core. Dazu gibts Code Beispiele bei den 
Language Templates.

[Gustl B. (-gb-)]

Christian R. schrieb:
> BRAM Fifo

Also der Threadersteller schrieb nichts von FIFO. Klar, der FIFO braucht 
den Reset weil er ja mit Adressen zu tun hat und sich Dinge merkt, aber 
ein einzelner BRAM? Ich habe die bisher immer ohne Reset verwendet, auch 
dual-port.

[Christian R. (supachris)]

Gustl B. schrieb:
> Also der Threadersteller schrieb nichts von FIFO.

Klar. Das war immer noch darauf bezogen:

Klakx schrieb:
> Reset am Anfang mindestens 100 ns?

Hätte ich mit Zitat antworten sollen, richtig.

[Bert (Gast)]

Christian R. schrieb:
> Reset ist am BRAM Fifo ganz wichtig und muss da mindestens 5 Takte des
> langsamsn Taktes anliegen.

Das sind locker 10 Takte. Mich bewegt einfach die Frage, ob man dem 
Generatortool trauen kann. Sind das plausible Werte, wenn ich einen 
Artix einstelle und Virtex raus kommt?

Mittlerweile habe ich in weiteres files gefunden, dass es sich bei den 
BRAMs mit der kleinen Größe um kleine Blöckchen handelt, die er zu 
größeren Blöcken zusammenschaltet. Ich kapiere aber immer noch nicht, 
warum das 44 sind. Die Zahl scheint mir nicht plausibel.

An der Testbench kann es nicht liegen. Die schreibt nur ADR; DAT, EAN 
und fertig. läuft auch mit anderen RAMs wie Altera. Es werden auch keine 
Adressen eingeschränkt, dass die Synthese RAM Bereich weglöschen könnte.

[Gustl B. (-gb-)]

Also brams muss man eigentlich gar nicht explizit einbauen, die werden 
automagisch verwendet wenn man große arrays verbaut.
Ein Bram besteht aus 36kBit (4kByte) Speicher und lässt sich in zwei 
18kBit (2kByte) Speicher unterteilen. Eigentlich sind das 32kBit oder 
16kBit aber jedes Byte bekommt noch ein Paritätsbit dazu.
Virtex steht da weil der Artix iirc viel mit den Virtexen gemeinsam hat. 
Zumindest mehr mit den älteren Virtexen als den älteren Spartan. Ob das 
stimmt weiß ich aber nicht.
24Bit und 64k sind 3x64k=192kByte.
Also 192kByte/4kByte=48 brams mit 4kByte wenn die Paritätsbits nicht 
genutzt werden.
Oder 24x64k=1536kBit.
Also 1536kBit/36kBit=etwas über 42 also 43 Brams wenn die Paritätsbits 
verwendet werden.

[Stefan W. (Gast)]

zu 1): Das wird schon passen. Der Artix 7 hat die gleichen BlockRAMs wie 
der Virtex 7. Bestimmt ist "virtex7" als Synonym für "7series" gedacht.

zu 3): Dieser BlockRAM Generator wird ja irgendwelche Primitives 
instanziieren. Das heißt, entweder lauter RAMB36E1 (ein ganzer BlockRAM) 
oder lauter RAMB18E1 (ein halber BlockRAM) oder eine Mischung. Die von 
dir angegebenen Werte würden zu einem (einzigen) RAMB18E1 passen. 
Vielleicht hilft dir diese Info, den Code besser zu verstehen.

[Christian R. (supachris)]

Bert schrieb:
> Das sind locker 10 Takte.

Irgendwo im UG steht es versteckt in einer Fußnote:

Note: If the asynchronous reset is one slowest clock wide and the assertion happens very close to
the rising edge of slowest clock, then the reset detection may not happen properly causing unexpected behavior. To avoid such situations, it is always recommended to have the asynchronous reset asserted for at least 3 slowest clock cycles.

Immerhin haben die mittlerweile einen RST_BUSY Ausgang, da kann man eine 
FSM bauen.

[Michael W. (Gast)]

Christian R. schrieb:
> Immerhin haben die mittlerweile einen RST_BUSY Ausgang, da kann man eine
> FSM bauen.

Der ist laut FAE aber auch nur ein Dummy, der aus einem Zähler besteht 
und vorsorglich einige Takte zählt, egal was das Schaltwerk innen macht. 
Vorsorglich sollte man da aber trotzdem nicht versuchen, 
reinzuschreiben.

Das reset-Busy kann bei modernen Chips wie dem Ultrascale und dem Kintex 
schon mal eine weile dauern. Ich hatte kürzlich eine Grafik gesehen, wo 
es fast 20 Takte @300 MHz waren!