VHDL: RMII und CRS_DV

[Zero V. (Firma: Freelancer) (gnd)]

Hallo Community,

ich versuche gerade RMII in VHDL umzusetzen (GHDL und Gtkwave).
Dabei bin ich gerade über etwas gestolpert, bei dem ich aufgrund meiner
noch fehlenden Expertise gar nicht weiß ob das überhaupt möglich ist.

Also ich möchte aus dem RMII Signal CRS_DV (Rev 1.2) das Signal RX_DV
extrahieren (wie im Bild).

Eine Lösung wäre erst nach der letzten fallenden Flanke von CRS_DV (Rev
1.2) die nächste fallende Flanke von REF_CLK abzuwarten und dann dort
auszuwerten ob

if falling_edge(REF_CLK) then
   if (CRS = '0') AND (CRS_DV = '0') AND (DIBIT = das richtige) then
     RX_DV <= '0';
   end if;
end if;

Damit wäre aber RX_DV synchron zur fallenden Flanke von REF_CLK und 
damit einen halben Takt zu spät.

Damit ich nun RX_DV wirklich synchron zur steigenden Flanke von REF_CLK
setzen kann (wie im Bild), müsste ich zeitgleich bei der steigenden
Flanke von REF_CLK prüfen ob CRS_DV gerade auch eine steigende Flanke 
hat.

Ist das möglich? Oder gibt es eine andere Lösung?

PS: RMII Spezifikation habe ich voll verstanden nur alle Möglichkeiten
von VHDL sind mir noch unklar :-)
PS2: Aus den RXD Daten oder der Anzahl der Bits kann man keine 
Rückschlüsse
ziehen, es könnten auch noch viele weitere Flanken beim CRS_DV folgen.


Vielen Dank im Voraus.

[User (Gast)]

Das DV (rdv_qq) Signal lässt sich zurückgewinnen indem man folgendes 
macht

   process(clk_i)
   begin
      if rising_edge(clk_i) then
            crsdv_q     <= crsdv_i;
            crsdv_qq    <= crsdv_q;
            crsdv_qqq   <= crsdv_qq;
         end if;
      end if;
   end process;

   rdv_qq <= (crsdv_q or crsdv_qq) and (crsdv_qq or crsdv_qqq);
   crs_qq <= (crsdv_q and crsdv_qq) or (crsdv_qq and crsdv_qqq);

die crs_qq und rdv_qq Signale sind jetzt um 2 Takte verschoben, somit 
müssen die Daten auch um 2 Takte verzögert werden damit alle Signale zur 
Verfügung stehen.

[Zero V. (Firma: Freelancer) (gnd)]

User schrieb:
> jetzt um 2 Takte verschoben

Das macht es ja leider nur schlimmer.

[User (Gast)]

Und die Daten auch um 2 Takte zu verzögern ist nicht möglich?

[René D. (Firma: www.dossmatik.de) (dose)]

Was willst du simulieren Senden oder Empfangen?

CRS ist Carrier sense und ist asynchron und wird nur bei Halbduplex 
benötigt ob der Transportweg blockiert ist. Bei einem LAN Kabel ist 
alles Duplex.
Es sei du willst eine Eindraht oder Funkübertragung realisieren.

[Zero V. (Firma: Freelancer) (gnd)]

User schrieb:
> Und die Daten auch um 2 Takte zu verzögern ist nicht möglich?

Es geht mir nur derzeit darum ob es theoretisch überhaupt möglich ist.

[Zero V. (Firma: Freelancer) (gnd)]

René D. schrieb:
> Was willst du simulieren Senden oder Empfangen?
>
> CRS ist Carrier sense und ist asynchron und wird nur bei Halbduplex
> benötigt ob der Transportweg blockiert ist. Bei einem LAN Kabel ist
> alles Duplex.
> Es sei du willst eine Eindraht oder Funkübertragung realisieren.

Es geht mir doch gar nicht um CRS.
Laut IEEE 802.3 existiert Half-Duplex auch für 100BASE-TX (auch wenn es 
nur in Spezialfällen verwendet wird.
Zudem kommt bald 10BASE-T1S:
"Supporting point-to-point half-duplex operation over the 15 m link 
segment"

[Zero V. (Firma: Freelancer) (gnd)]

Ich denke ich habe die Lösung gefunden:

if rising_edge(REF_CLK) then
   if (CRS = '0') AND (CRS_DV = '0') AND (RXD = "00") AND (dibit_counter = "01") then
     RX_DV <= '0';
   end if;
end if;

Das hatte ich mehrfach überlesen:
" RXD[1:0] shall be “00” to indicate idle when CRS_DV is deasserted"