FIFO_DC spinnt

[Rick D. (rickdangerus)]

Ich habe mir von Lattice Diamond einen FIFO_DC generieren lassen.
Das DC steht für 'dual clock' aber bei mir kommen alle Signale aus einer 
Taktdomäne.

Nun schreibe ich einige Werte in's FIFO und will die langsam wieder 
auslesen.
In der Simulation passt auch alles.

Allerdings stimmt es nicht mehr im FPGA. Da werden die Werte 
eingeschrieben (rote Kurve) und ein Wert auch ausgelesen (blaue Kurve). 
Aber das FIFO-empty-Signal ist nur am Anfang mit der Simulation 
identisch. Nach ca. 23 µs signalisiert das FIFO plötzlich es wäre leer, 
obwohl da nix weiter gelesen wurde.

Hat jemand so ein Verhalten schon mal beobachtet?
Was tun? Wenn ich mich nicht auf die FIFO-Flags verlassen kann, kommt 
meine State-Machine ins Straucheln.
Bisher waren die von IPExpress generierten FIFOs alle unauffällig und 
haben wie gewünscht funktioniert...

[Andras H. (andras_h)]

Kommt vielleicht ein Reset?

[Martin S. (strubi)]

Da fallen mir noch folgende Check-Fragen ein:
- Wie gross ist dein FIFO?
- Ab welcher Position knallt's?
- LSE oder Synplify fuers Mapping?
- RTL-Mapping schon analysiert?

Ich erinnere mich dunkel an ein paar Kopfkratz-Scenarios, mir kam mal 
auf einem ECP3 was unter, wo es dann mit dem portablen Code und einem 
zusaetzlich eingefuegten Register ging, aber nur via Synplify. Leider 
sehr lange her, also kein hilfreiches Detail.

Manchmal hilft post-map Simulation, aber das muss man dann wieder in 
Verilog resp. mixed machen, weil einige VHDL-Primitivenmodelle fehlen.

[Rick D. (rickdangerus)]

Andras H. schrieb:
> Kommt vielleicht ein Reset?
Schau ich noch mal nach, unwahrscheinlich, da ich den nur einmal kurz am 
Anfang mache.

Martin S. schrieb:
> - Wie gross ist dein FIFO?
Die Tiefe ist 32.

> - Ab welcher Position knallt's?
9x schreiben und 1x lesen und da ist er der Meinung es wäre leer.
Im Timing-Report ist nix auffälliges, aber bei der Sysnthese:

Duplicate register/latch removal. send_i0/fifo_i0/FF_58 is a one-to-one match with send_i0/fifo_i0/FF_52.

Die Meldung kommt sehr (zu?) oft.

> - LSE oder Synplify fuers Mapping?
LSE. SYnplify geht gerade nicht, weil der die libxml2 nicht findet :(

> - RTL-Mapping schon analysiert?
Nein, hab ich für so einen Fall auch noch nicht gemacht, ist aber eine 
Idee.

Erstmal hab ich Diamond auf 3.14 gebracht, nutzt aber auch nix.

[Rick D. (rickdangerus)]

Gerade noch die Idee gehabt, mal etwas weniger in's FIFO zu schreiben, 
aber kurz nach dem letzten wren ist wieder Schluß. Ich muß doch näher 
auf den Reset und die restlichen Steuersignale schauen.

[Rick D. (rickdangerus)]

Reset ist ok und RPReset ist permanent auf '0'.

Ich habe im Generator von 'LUT based' auf 'EBR only' umgestellt und 
jetzt geht es!

Außerdem sind diese Warnungen verschwunden:

Duplicate register/latch removal. send_i0/fifo_i0/FF_66 is a one-to-one match with send_i0/fifo_i0/FF_60.
Duplicate register/latch removal. send_i0/fifo_i0/FF_48 is a one-to-one match with send_i0/fifo_i0/FF_42.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_66 is a one-to-one match with receive_i0/fifo_i0/FF_60.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_48 is a one-to-one match with receive_i0/fifo_i0/FF_42.
Duplicate register/latch removal. send_i0/fifo_i0/FF_66 is a one-to-one match with send_i0/fifo_i0/FF_60.
Duplicate register/latch removal. send_i0/fifo_i0/FF_48 is a one-to-one match with send_i0/fifo_i0/FF_42.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_66 is a one-to-one match with receive_i0/fifo_i0/FF_60.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_48 is a one-to-one match with receive_i0/fifo_i0/FF_42.
Duplicate register/latch removal. send_i0/fifo_i0/FF_66 is a one-to-one match with send_i0/fifo_i0/FF_60.
Duplicate register/latch removal. send_i0/fifo_i0/FF_48 is a one-to-one match with send_i0/fifo_i0/FF_42.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_66 is a one-to-one match with receive_i0/fifo_i0/FF_60.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_48 is a one-to-one match with receive_i0/fifo_i0/FF_42.
Duplicate register/latch removal. send_i0/fifo_i0/FF_66 is a one-to-one match with send_i0/fifo_i0/FF_60.
Duplicate register/latch removal. send_i0/fifo_i0/FF_48 is a one-to-one match with send_i0/fifo_i0/FF_42.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_66 is a one-to-one match with receive_i0/fifo_i0/FF_60.
Duplicate register/latch removal. receive_i0/fifo_i0/FF_48 is a one-to-one match with receive_i0/fifo_i0/FF_42.
Duplicate register/latch removal. send_i0/fifo_i0/FF_66 is a one-to-one match with send_i0/fifo_i0/FF_60.

Danke fÜr's miträtseln!

[Martin S. (strubi)]

Edit: Da ist irgendwie dein letzter Post bei mir durch die Luecken. 
Damit erklaert sich's wohl...

----

Hmm. 32 Woerter passen in einen EBR, da gibt's eigentlich keinen Grund 
fuer Aerger. Oder mappt LSE das auf LUTs? Was, wenn das FIFO groesser 
ist?

Die Meldung betr. doppelter Register klingt nach Normalfall, da man ja 
oefters mal redundante Logik erzeugt.
Mit LSE hatte ich oefters non-funktionale Logik aus VHDL bekommen. Von 
seiten Lattice-Support hiess es lapidar aus Indien: Nimm halt Verilog 
oder Synplify, an einem Bugfixing schien das Interesse zu gering.

Kompatibilitaeten-Aerger mit dem Diamond-Geraffel und spaeteren 
Toolchains vermeidet sich uebrigens gut per Docker-Installation (siehe 
auch https://github.com/Gekkio/docker-fpga).

[Rick D. (rickdangerus)]

Martin S. schrieb:
> 32 Woerter passen in einen EBR, da gibt's eigentlich keinen Grund
> fuer Aerger. Oder mappt LSE das auf LUTs?
Ob LUT oder EBR kann man sich raussuchen. Ich wollte für 32 Bytes 
eigentlich keinen EBR opfern.

> Mit LSE hatte ich oefters non-funktionale Logik aus VHDL bekommen. Von
> seiten Lattice-Support hiess es lapidar aus Indien: Nimm halt Verilog
> oder Synplify, an einem Bugfixing schien das Interesse zu gering.
Ja, diese Erfahrung mit dem Support habe ich auch schon gemacht. Trotz 
mitgeliefertem Minimalbeispiel.

[Martin S. (strubi)]

Rick D. schrieb:
> Ob LUT oder EBR kann man sich raussuchen. Ich wollte für 32 Bytes
> eigentlich keinen EBR opfern.

Zu spaet deinen screenshot angeschaut... tja.
Kann es leider nicht ad-hoc nachpruefen, ob der IPX in harte Primitiven 
instanziert, aber vermutlich tut er das, und LSE 'optimiert' dann.
Bei so MiniFIFOs hatte ich mit haendischer Implementierung und 
one-hot-up/down countern mehr Spass und Speed als mit IPX, wo ploetzlich 
nach dem Upgrade die generierten Cores nicht mehr wollten.