Forum: FPGA, VHDL & Co. Handshake-Mechanismus


von Andreas P. (andreaspfau)


Lesenswert?

Hi Community,

ich bin zwar kein VHDL-Neuling mehr, aber mir gehen hier im Moment die 
Ideen aus. Ich würde gerne einen schnellen Handshake-Mechanismus 
beschreiben.

Kurzer Abriss: ich will den SRAM auf meinem DE1-Demoboard ansteuern (und 
keine IPs verwenden, sondern selber machen ^^). Dazu wäre es 
wünschenswert, die Daten mit so wenig Verzögerungen wie möglich 
reinschaufeln zu können. Nicht notwendig, aber wünschenswert. Übrigens 
verwende ich einen Altera Cyclone II mit Quartus 8.1 Web Edition.

Mir kommen prinzipiell zwei Ansätze: ein "Ready"-Signal oder ein 
"Acknowledge"-Signal. Das Problem bei beiden: angenommen, mein 
SRAM-Controller bekommt eine Schreibaufforderung. Dann kann er das 
Ready- bzw. Ack-Signal frühestens beim nächsten Takt ändern, aber bis 
die übergeordnete Logik diese Zustandsänderung mitbekommt vergeht ein 
weiterer Takt.

Nun, ein asynchrones Ready/Ack wäre eine Lösung, das habe ich auch 
schonmal gemacht, aberes ist keine schöne Variante.

Eine andere Möglichkeit wäre es, das Ready/Ack auf der fallenden Flanke 
zu erzeugen, während der Rest auf der steigenen Flanke arbeitet. Das ist 
mir so in den Sinn gekommen, aber ich habe gemerkt dass der Classic 
Timing Analyzer das nicht richtig erkennt (das Design müsste ja 
langsamer sein als eines, das nur auf einer Flanke arbeitet), außerdem 
ists auch keine schöne Lösung.

Nun, hat jemand von euch ne bessere Idee?

von Karl (Gast)


Lesenswert?

Hab im Studium mit dem DE1 mal den VGA Ausgang in Betrieb genommen und 
dazu das SRAM als Framebuffer verwendet. Der scanout für die VGA 
Signalerzeugung hatte Priorität über dem Beschreiben des Framebuffers. 
Folglich haben die Entsprechenden Module jeweils ein request Signal, 
Daten, Adresse und ein ack Signal bekommen. Also Adresse (und Daten beim 
schreiben) und request signalisieren und der Controller meldet dann ein 
ack im letzten Arbeitstakt zurück. Wenn also weiterer Bedarf zum Lesen 
besteht, kann der scanout Teil einfach den request stehen lassen und ggf 
die Adresse ändern. Macht 3 Takte fürs Lesen. Beim Schreiben sind es 4 
Takte, weil ich tSU einhalten muss (200 MHz Takt, bei weniger spart man 
sich einen Warte-Takt und kommt auch mit 3 Takten aus).

Eine andere Möglichkeit wäre es einen Puffer einzusetzen, der alles 
zwischenspeichert wenn ein Schreibvorgang ausgeführt wird und das Ready 
Signal noch nicht da angekommen ist, wo es hingehört.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.