Echtzeitdaten speichern bis Transmitter bereits ist

[Christian B. (chrizbee)]

Allgemeine Info
Mein Design besteht aus zwei IP-Cores: Einem Receiver und einem 
Transmitter.
Beide nutzen dieselbe Byteclock, d.h. CDC wird nicht benötigt.
Die Daten kommen am Receiver rein und bestehen aus Paket-Header und 
-Payload.
Meine Aufgabe ist es, nur den Header der Pakete anzupassen und die Daten 
an den Transmitter weiterzugeben, sobald dieser bereit ist.

Ablauf (siehe Bild)
1. Auf data_detect des Receivers warten
2. Header und Payload auslesen und ggf. verändern (kombinatorisch)
3. Im Transmitter enable setzen
4. Auf ready des Transmitters warten
5. Im Transmitter payload_en zusammen mit Header und Payload setzen

Die payload ist 64 bit breit, also kann das n im Bild wie folgt 
berechnet werden:

$$n = wc \cdot \frac{8}{64} byte$$

Fragen
Was ist die beste Vorgehensweise um die Daten zu verzögern, bis der 
Transmitter bereit ist?
- Einfache Schieberegister (schieben bis ready)?
- In EBR oder SPRAM speichern?
- Ein FIFO (/mehrere FIFOs) verwenden?

Und wie sieht die Umsetzung hier üblicherweise aus (bei den im Bild 
gegebenen Signalen)?

[Samuel C. (neoexacun)]

Einfach einen FIFO dazwischen setzen. Und so wie es aussieht scheinen 
sowohl Receiver als auch Transmitter ein einfaches FIFO-Interface zu 
nutzen. Sollte also ohne größere Probleme direkt anflanschbar sein.

[Christian B. (chrizbee)]

Sowohl Header als auch Payload in ein FIFO, oder mehrere FIFOs für die 
einzelnen Signale verwenden?

[Samuel C. (neoexacun)]

Alles zusammen in einen FIFO.

[Tim (Gast)]

Das ist Gang und Gebe im Stream-Design mit FPGAs.
Ich würde den Stream sogar zu einem AXI-Stream machen. Die Handhabung 
mit Valid und Ready brauchst du ja anscheinend sowieso. Ein FIFO, das 
mit einem Miniwrapper zu einem AXI-Stream FIFO wird, verschafft dir die 
Zeit.

Ansonsten kann man mit dem ready auch seine Quelle gezielt stoppen, wenn 
diese das unterstützt und mag :)

[Samuel C. (neoexacun)]

Im Prinzip ist das ein AXI-Stream. Die Signale heißen nur anders und es 
gibt keine Zusatzsignale wie TUSER oder TLAST. Und letztendlich ist ein 
AXI-Stream-Interface auch nichts anderes als ein simples FIFO-Interface.

[Christian B. (chrizbee)]

Erstmal danke für die Antworten!
Das mit dem Axi-Stream ist ein echt gutes Stichwort, das werde ich mir 
demnächst mal ansehen. Leider hat Lattice dafür keinen IP Core.

Beim Beschreiben meiner FSM habe ich mir jetzt noch überlegt, nur die 
Payload ins FIFO zu schreiben und den Header einfach auf Register zu 
geben. Dadurch könnte ich die Größe des FIFOs verkleinern. Das sollte 
klappen, weil die Header-Daten sowieso immer bis zum nächsten 
data_detect anliegen (siehe Bild). Ich könnte den Header also synchron 
bei ready ins Register schreiben und von da an den Transmitter 
weitergeben.

Grund dafür ist, dass ich auch Sync-Packets habe, die ausschließlich aus 
einem Header bestehen. Für die Pakete könnte ich mir dann das FIFO 
sparen.

Macht das Sinn, oder würdet ihr trotzdem alles ins FIFO reinpacken?

[Samuel C. (neoexacun)]

Das würde ich von den Breiten von Header und Daten abhängig machen.

Du könntest den Header auch als Datenwort in den FIFO packen und mit 
einem zusätzlichen Bit markieren. Dafür sollten Header und Daten aber 
ähnlich breit sein.

Du könntest für die Header auch einen eigenen FIFO machen, solltest dann 
aber ganz genau schauen, dass die beiden FIFOs niemals auseinanderlaufen 
können.

So oder so, wenn du die Daten in einen FIFO packst, müssen auch die 
Header in irgendeine Art von FIFO. Sonst kannst du dir die Header unter 
Umständen nicht lange genug puffern.