Dual Ported RAM funktioniert in der Simulation, aber nicht auf der Hardware, Altera

[goerki (Gast)]

Hallo,
Ich lese den Dual Ported RAM 5 mal hintereinander aus. Das "rden" bleibt 
dabei die ganze Zeit 1. Nach 3 Taktflanken erhalte ich die 1. Daten, 
welche korrekt sind, setze die "rdaddress" neu. Nach 3 Taktflanken 
erhalte ich weitere korrekte Daten und setze die "rdaddress" neu. Doch 
nach weiteren 3 Taktflanken erhalte ich seltsame Daten. Dies wiederholt 
sich bei jeden Setzen von "rden".
In der Simulation funktioniert es, auf der Hardware aber nicht. Die 
Taktfrequenz beträgt 40 mHz.

Wo könnte der Fehler liegen?

Danke goerki

[Falk B. (falk)]

Möglicherweise sind sie Eingangssignale in der Simulation "falsch", 
sprich, die Steuersignale wechseln EXAKT mit dem Takt. Das ist ein 
verbreiteter Fehler. Steuersignale müssen IMMER einen Tick vor oder nach 
dem Takt wechseln!

[FPGA Pongo (Gast)]

Seit wann denn das?? BRAMs sind doch voll synchron.

[Falk B. (falk)]

@ FPGA Pongo (Gast)

>Seit wann denn das??

War schon immer so.

> BRAMs sind doch voll synchron.

Das hat auch keiner bezweifelt. Wenn man aber eine Testbench generiert, 
welche die Eingangssignale EXAKT gleich mit dem Takt verändert, dann 
werden diese erst einen Takt später wirksam, auch wenn es auf dem 
Simulator anders dargestellt wird. Das war zumindest mein Fehler vor 
vieeeeelen Jahren ;-)

[berndl (Gast)]

zum Glueck habe ich meistens mit synchronen Designs mit nur einem Takt 
zu tun :o)
Ich aendere (seit vielen Jahren) die Stimuli in der Testbench wenns geht 
immer bei "75% der Periode". Damit simuliere ich z.B. auch die Laufzeit 
externer Komponenten, und gleichzeitig sehe ich (wenn ich die Waveform 
anschaue) auch sofort, dass das etwas "von aussen" ist und muss nicht 
lange ueberlegen wann/wo/wie das jetzt im internen FF landet

Kann also Falks Hinweis nur unterstuetzen...

[FPGA Pongo (Gast)]

Wenn man die TB synchron schreibt, also alle innerhalb eines Taktes NACH 
dem rising_edge , dann passt das auch.

[berndl (Gast)]

ja klar passt das. Aber wenn du am FPGA an der einen Seite z.B. einen uC 
haengen hast, der mit 50MHz laueft, dein FPGA laeuft mit 100MHz, und ein 
"Target" redet mit deinem FPGA z.B. ueber eine 5MHz SPI, dann hat es 
durchaus einen Sinn, sich ueber die Zeiten der Stimuli in einer TB 
Gedanken zu machen.
Eine gute Erfahrung meinerseits: Schau, dass da nie "gerade Teiler" bei 
rauskommen. Also den uC lieber mit 21ns anstatt 20ns laufen lassen, die 
SPI des Targets lieber mit 197ns anstatt 200ns laufen lassen...
Das gibt dir schlicht und einfach eine gute Testabdeckung, weil du halt 
mal zu spaet und auch mal zu frueh dran bist. Ein bisschen Hirnschmalz 
in die TB zu stecken zahlt sich eigentlich immer aus. Sauereien in HW 
rauszusuchen dauert meist laenger...

[FPGA Pongo (Gast)]

berndl schrieb:
> Eine gute Erfahrung meinerseits: Schau, dass da nie "gerade Teiler" bei
> rauskommen.

Das hilft nicht über das Problem, weil die Schwierigkeit in der 
Simulation der minimale timestep ist, wo er sich verrennt (der 
diskutierte Fehler) und in der Realität es unabhäng von den Takten immer 
zu dem Zustand der überlappenden Takte vorkommen können (von Dir neu 
eingeführt).

In der Realität hast du zudem noch den Jitter. Da muss man eben 
entsprechend designen.

[goerki (Gast)]

Danke, hat geholfen