FPGA

Was mir auf den ersten Blick beim rasch rübergucken auffällt: Deine Resetbedingung wird nur ausgeführt, wenn (rising_edge(clk) and clken_4mhz = '1') erfüllt ist. Das ist (denke ich mal) nicht im Sinne des Erfinders.

Das zweite: Du kommst aus deinem "Idle" erst heraus, wenn dmx_in='0' ist. Ist das richtig?

Das dritte: Dein dmx_clk hat ein Duty-Cycle von 1/clk. (Das heißt du bekommst immer nur einen kurzen Highpegel und einen langen Low-Pegel auf dem dmx_clk). Stimmt das?

Einen genaueren Blick werfe ich jetzt nicht drauf. Ich habe Urlaub.

(Außerdem kapiere ich noch nicht ganz was das Ding machen soll. )

Erstmal zu deinem code oben:

1. Wie Arno schon schrieb kommst du aus dem Idle nur bei dmx_in = 0 raus. Ich sehe aber gerade gar nicht, wie du überhaupt wieder in den Idle Zustand kommen willst. Machst du nach nem ganzen Byte einfach nen Reset?

2. Du benutzt alle 16 Sample zur Auswertung und nicht nur drei in der Mitte, aber ich schätze das ist dir klar.

3. Du solltest das dmx_in noch synchronisieren, aber das kannst du natürlich auch ausserhalb dieses Blocks machen.

4. Noch ein Tip wie ich gerne Signale generiere, die nur eine Clock high sein sollen (in deinem Fall z.B. ser_clk): Zu Beginn des Prozesses auf 0 setzten (also hier direkt unter der Clockabfrage und noch vor der Idle abfrage) und dann wenn benötigt an der (den) entsprechenden Stelle(n) auf 1 setzen. Das erspart einem das man das Signal an allen anderen Stellen auf 0 setzten muss.

Zum Synchronen Design:

1. Was du hier entdeckt hast ist das Hold Time Problem. In der Tat ist das direkte Verbinden von FFs meist nicht möglich. Jedes (D-)FF hat eine Setup und eine Hold Time.
Setup gibt die Zeit an, die das Signal am D Eingang stabil anliegen muss bevor die Rising Clock Edge kommt, Hold gibt entsprechend die Zeit an, die das Signal nach der Clock Edge stabil sein muss.
D.h. man (bzw. die Software wie hier Xilinx) muss bei der Timing Analyse checken, dass a) keine Signalpfade zwischen FFs zu schnell sind (Hold Violation) und b) keine Signalpfade zwischen FFs zu langsam sind (Setupt Violation).
Die Holdtimes kann man durch Einfügen von Buffern fixen, bei den Setuptimes hilft nur mit der Taktfreq. runter zu gehen, bzw. der schlechteste Setup Pfad gibt dir deine max. Frequenz vor. Wie das jetzt bei FPGAs exakt ist weiss ich nicht, eventuell hat man da durch die LUTs und Leitungen auch so schon genug Delay, dasses für die Holdtime reicht.
Damit das ganze auch richtig funktioniert muss man dafür sorgen, dass die Clock bei allen FFs möglichst gleichzeitig ankommt. Das erreicht man mit entsprechendem Aufbau des sog. Clocktrees, d.h. z.B. in Baumform oder man muss die Clocksignallaufzeiten eben genau berechnen. Der max. Unterschied der Ankunftszeit der Clock wird Clock Skew genannt.
Übrigens, wenn Signale verschiedene Clockdomains überqueren (auch dein dmx_in ist so ein Fall, da es von einem Gerät ausserhalb mit eigener Clock generiert wird) ist es unmöglich die Setup und Hold Times der FFs einzuhalten. Wenn das passiert kann der FF in einen metastabilen Zustand gehen, d.h. er gibt irgendwas zwischen 0 und 1 aus.
Dieser Zustand legt sich schnell wieder, dauert aber deutlich länger als ein normaler Schaltvorgang.
Deshalb muss man das Signal mit Hilfe von mind. zwei direkt hintereinander geschalteten FFs (was halt mit der Holdtime minimal möglich ist)
synchronisieren. Man hoft da, dass das Timingbudget bis zur nächsten Clock lange genug ist, dass sich ein eventueller metastabiler Zustand
des ersten FFs gelegt hat. Ist das nicht so kann sich der metastabile Zustand in der ganzen Schaltung ausbreiten und diese zum Absturz bringen.
100% sicher kann man sich da nie sein, aber die Fehlerraten liegen bei heutiger Technologie bei vielen vielen Jahren bis zum ersten Fehler.

2. Wechselnde Clockflanken verwendet man normalerweise nicht (es gibt sicherlich Spezialfälle wo das Sinn macht). Du hättest ein Problem,
wenn du ein Schaltnetz hast, welches ein Signal aus dem Output von zwei invertiert geclockten FFs generiert.

3. Es macht absolut keinen Unterschied. Aber nur, weil du Signale verwendest. Hättest du im Bsp. 3 Variablen im Prozess würden dieses direkt übernommen.
Denk dir das so: Ein (sequenzieller) Prozess hat normalerweise immer ein paar Signale zum Eingang (Variablen sind ausserhalb von Prozessen ja nicht möglich)
und ein paar als Ausgang (die die er beschreibt). Wenn die Clock kommt friert er die Zustände aller Eingangssignale ein und berechnet die Ausgangssignale mit diesen Eingangssignalen.
Variablen hingegen sind eine Art der Abstraktion für die Beschreibung innerhalb eines Prozesses. Wenn du von ihnen liesst enthalten sie den im selben "Prozessdurchlauf" zuletzt geschrieben Wert.
Das lässt sich natürlich hardwaretechnisch nicht direkt abbilden (es geht ja nur um eine Clock), d.h. der Compiler baut daraus etwas, was nur aus "Signalen" besteht. Ich hoffe das kann man irgendwie verstehen.
In Kurzform:

b <= a;
c <= b;
d <= c;
e <= d;

und

e <= d;
d <= c;
c <= b;
b <= a;

sind Identisch im Fall von Signalen, aber nicht im Fall von Variablen.

Sorry für den langen Delay, aber is ja auch n komplexes Thema
Hab das ganze jetzt mal grob überflogen und sehe keinen prinzipiellen Fehler.
Nächster Schritt wäre jetzt eine Testbench zu erstellen und in Modelsim eine Behaviol Simulation zu machen ob die Kiste auch so tut wie se soll. Danach noch ne kleine Schaltun die Startbyte prüft, Bytes zählt und das ganze in nen Dual Port Memory schreibt. An die andere Seite von dem Mem hängste dann nen Prozessor und fertig is der Empfänger.

Es gibt ne freie Version von Modelsim die einfach bischen langsamer ist. Die 10000 Zeilen Code wirste so schnell sowiso nit erreichen:
http://www.mikrocontroller.net/articles/ModelSim
Klar sind die offiziellen Versionen von ModelSim unendlich teuer, schau dir mal an, wer die normalerweise benutzt...

Trenz Electronic macht auch noch solche Boards, hab da aber noch nie bestellt:
http://shop.trenz-electronic.de/catalog/product_info.php?products_id=178&osCsid=1661be96272bd8ee88a0aa39cf080538
Oder halt das Spartan Starterboard von Xilinx.
http://www.digilentinc.com/