Latch wann gerechtfertigt ?

[Jost .. (jojocp)]

Guten Morgen,

Die Frage:

Generell soll ja in FPGAs von asynchronen Designs (wie z.B. Latches) 
abgesehen werden um Timing Probleme und Metastabilitäten zu vermeiden. 
Bei welchen speziellen Fällen kann eine Verwendung dieser eventuell 
dennoch legitim sein?

Der Hintergrund:

In meinem System befinden sich ein FPGA und ein Prozessor die 
miteinander über das External-Memory-Interface des Prozessors 
kommunizieren sollen.
Dazu muss der FPGA ein asynchrones NOR-Flash mit gemultiplextem Daten- / 
Addressbus emulieren.
Folgende Steuersignale stehen zur Verfügung:
Chip_Select,
Address_Valid,
Output_Enable,
Write_Enable

In wiefern ein Einsynchronisieren der Signale noch vor dem 
Zwischenspeichern möglich ist weiß ich nicht, da die Asynchronen Signale 
schon recht schnell ankommen und so eine sehr hohe Taktrate zum 
Eintakten nötig wäre.

Daher habe ich überlegt, das Zwischenspeichern der Addressen und Daten 
in einer asynchronen Prozedur in einem Latch zu realisieren. Dazu kann 
ich einfach die jeweiligen enable Signale (Adress_Valid / Write_Enable) 
als enable für das Latch nutzen. Nebenbei würde ich synchron zum 
Systemtakt den Chip_Select Eingang auf eine Flanke vom aktiven in den 
nicht aktiven Zustand überprüfen und in diesem Fall das im Latch 
gespeicherte Address- und Datenwort in ein Register übernehmen. Ab hier 
wäre dann alles wieder synchron zum Systemtakt.

Eine andere Möglichkeit wäre die Enable Signale (Address_Valid / 
Write_Enable) als Takt zu missbrauchen und bei einer Flanke vom aktiven 
in den nicht aktiven Zustand das anliegende Address- / Datenwort in 
einem Register zu speichern. Anschließend kommt wieder die Überprüfung 
der Flanken des Chip_Select Signals.

Beides eher unschöne Lösungen. Habt ihr bereits ähnliche Designs 
implementiert und wie habt ihr es gelöst?

Grüße

[Duke Scarring (Gast)]

Jost ... schrieb:
> Habt ihr bereits ähnliche Designs
> implementiert und wie habt ihr es gelöst?
Ja. Siehe "Capturing a Bus", Seite 29:
http://www.pldworld.com/_xilinx/html/training/10_fpga_dsgn_tech.pdf

und Seite 4:
http://web.stanford.edu/class/ee183/handouts_spr2003/synchronization_pres.pdf

In diesem Fall ist es o.k. Latches zu generieren, die enable Signale auf 
Takteingänge zu führen und chip select einzusynchronisieren.

Hilfreich ist es auch, sich die Bus-Timings mit dem LogicAnalyzer oder 
Chipscope anzuschauen. Da sieht man recht gut, ab wann z.B. die 
Adressleitungen stabil sind.

Duke

[Klaus F. (kfalser)]

Jost ... schrieb:
> Daher habe ich überlegt, das Zwischenspeichern der Addressen und Daten
> in einer asynchronen Prozedur in einem Latch zu realisieren.

Wieso muss es ein Latch sein?
Die Lösung 2 mit dem Enable/Write Signal als Takt ergibt FF's und ist 
somit sauber. Problem ist eigentlich nur, dass die Flanke eines solchen 
Signals möglicherweise nicht steil genug ist, und sich somit nicht als 
Taktsignal eignet.
In diesem Fall muss man einen internen Takt verwenden, die Signale damit 
abtasten und bei Erkennung von Enable/Write aktiv sich die Busdaten in 
einem separatem Signal merken (umkopieren).

[Lattice User (Gast)]

Habe ich auch schon gemacht.

Dazu habe ich nur CS einsynchronisiert, und den Rest davon abgezählt.
OE direkt mit den OE der Daten Pins des FPGA verbunden. Wenn die 
Holdzeit für die Daten dem Host nicht reicht, kann man ein Input IODelay 
am OE Pin konfigurieren.

Auf der Host Seite (Atmel SAM9) habe ich das Timing passend 
konfiguriert, damit es im Worstcase Fall sauber funktioniert.

[Schlumpf (Gast)]

Jost ... schrieb:
> Daher habe ich überlegt, das Zwischenspeichern der Addressen und Daten
> in einer asynchronen Prozedur in einem Latch zu realisieren. Dazu kann
> ich einfach die jeweiligen enable Signale (Adress_Valid / Write_Enable)
> als enable für das Latch nutzen. Nebenbei würde ich synchron zum
> Systemtakt den Chip_Select Eingang auf eine Flanke vom aktiven in den
> nicht aktiven Zustand überprüfen und in diesem Fall das im Latch
> gespeicherte Address- und Datenwort in ein Register übernehmen. Ab hier
> wäre dann alles wieder synchron zum Systemtakt.

Und wie funktioniert das dann beim Lesen?
Dann sind deine Adressen im FPGA ja erst dann gültig, wenn CS inaktiv 
ist.
Sprich: Erst bei inaktivem CS kann der FPGA die entsprechenden Daten auf 
den Datenbus legen. Aber das darf er ja dann natürlich nicht mehr.

Oder habe ich da was falsch verstanden?

Prinzipiell kann man aber den AD-Bus mit ALE asynchron latchen und dann 
die Latches intern synchronisieren.

[M. (Gast)]

Was spricht denn dagegen, ALE und Adressen einzutakten und dann Daten 
ungepuffert zu übernehmen? Das Schreiben kann doch verzögert erfolgen. 
Wichtig ist, dass der Bus wieder frei ist, wenn OE kommt.

[Martin K. (martinko)]

Hi,

Kann mir jemand erklären, was Xilinx da auf Seite 29 macht (Eintakten 
von Signalen kürzer als Clock Periode), warum so und wie man das in VHDL 
abbilden würde?

Danke
Martin

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Martin K. schrieb:
> (Eintakten von Signalen kürzer als Clock Periode)
Ohne die genaue Umsetzung dort gesehen zu haben, funktioniert das so: 
die Flanke eines externen Signals setzt ein Flipflop. Dessen Wert wird 
einsynchronisiert und das Flipflop (oder die Flipflops) danach 
zurückgesetzt.

> wie man das in VHDL abbilden würde?
Siehe 
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html

[FPGA-Pongo (Gast)]

Wieso muss man es rücksetzen? Es reicht doch, das togglen zu erkennen 
...

[Martin K. (martinko)]

Lothar Miller schrieb:
> Martin K. schrieb:
>> (Eintakten von Signalen kürzer als Clock Periode)
> Ohne die genaue Umsetzung dort gesehen zu haben, funktioniert das so:
> die Flanke eines externen Signals setzt ein Flipflop. Dessen Wert wird
> einsynchronisiert und das Flipflop (oder die Flipflops) danach
> zurückgesetzt.
>
>> wie man das in VHDL abbilden würde?
> Siehe
> 
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html

Hallo Lothar,

In deren Beispiel (xilinx) wird nur das erste FF wieder zurück gesetzt, 
und zwar mit "Eingangssignal not and Ausgangssignal" (wenn ich mich 
recht erinnere), das ist das was mich irritiert.

Gruß Martin

[Martin K. (martinko)]

FPGA-Pongo schrieb im Beitrag #4150052:
> Wieso muss man es rücksetzen? Es reicht doch, das togglen zu erkennen
> ...

Ich glaub ich habs soeben doch selbst erkannt. Die wollen eine steigende 
Flanke erkennen, die auch kleiner als ein Taktzyklus lang anliegen kann. 
Dazu wird die steigende Flanke des Signals als Clk fÜr das erste FF 
verwendet. Diese erkannte Flanke wird dann als '1' über zwei weitere FFs 
ganz normal einsynchronisiert. In deren Beispiel lassen die das erste FF 
solange auf '1' stehen, wie das Eingangssignal High ist oder das 
Ausgangssignal noch nicht und benutzen diese Bedingung zum zurück setzen 
des ersten FFs. Bedeutet aber auch, dass ein kurzes Einganssignal 
(Eingangsflanke) nach 2 Clk für 2 clk am Ausgang anliegt.


Danke schön und
Gruß Martin

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Martin K. schrieb:
> Ich glaub ich habs soeben doch selbst erkannt.
So ist es... ;-)

Und für mein dafürhalten ist es sinnvoller, die Flanke in einen (1) Puls 
mit 1 Taktzyklus Dauer umzuwandeln...

[Michael W. (Gast)]

Lothar Miller schrieb:
> Und für mein dafürhalten ist es sinnvoller, die Flanke in einen (1) Puls
> mit 1 Taktzyklus Dauer umzuwandeln...
Wie würde man das machen? Die Quelle weiss ja nicht unbedingt, wie 
schnell es in der Senke zugeht. Da geht nur tooglen und 
Flankendetektion, oder nicht?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Markus Wagner schrieb:
> Lothar Miller schrieb:
>> Und für mein dafürhalten ist es sinnvoller, die Flanke in einen (1) Puls
>> mit 1 Taktzyklus Dauer umzuwandeln...
> Wie würde man das machen?
Naja, so wie dort im 
Beitrag "Re: Latch wann gerechtfertigt ?" verlinkt: aus einem 
langen oder einem kurzen Puls wird ein einsynchronisierter Puls mit 1 
Taktzyklus...