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

goerki Gast #4421589
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Falk B. #4421623
Lesenswert?
• ▲
▼ 
@ 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 ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
berndl Gast #4421852
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
berndl Gast #4421903
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
FPGA Pongo Gast #4421990
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren