VHDL: synchrones und asynchrones Design mischen

Die meisten Signale werden ja "asynchron" geschrieben, da sie aus
Kombinatorik stammen und laufen auseinander. Das Problem hebt sich,
durch die setup-time. Entscheidend ist, ob ein Zeitbezug zum
triggernden Signal hergestellt werden kann. Wenn die speisenden Signale
letztlich aus FFs stammen, ist das kein Problem, da Generatinsrate und
Abtastrate ja übereinstimmen. Man muss nur die Laufzeit beachten.

Wenn aber, wie Du es vermutlich meinst, ein von einem Port irgendwann
zufällig eintreffender Vektor erfasst werden muss und man keinen
Datentakt hat, auf den man sich beziehen- und damit Annahmen über den
Zeitpunkt stabiler Signale machen kann, wird es problematisch:

Das bekannte Einsynchronisieren über 2 FFs reicht dann nicht: Man
müsste erkennen, wann sich die Mehrheit der Signale ändern kann, also
eine Art von Taktrekonstruktion betreiben.

Was ist denn der physikalische Trigger deines asynchronen Vektors?

Also ein uC schreibt üeber ein "Daten-Bus" (5 Datenleitungen und
CS-Signal) ein Vector in CPLD.
Dieser wird einfach in einem Latch gespeichert (asynchrones prozess).
In CPLD muss dann dieser Vector als PWM-Taskgrad verwendet werden
(synchrones Prozess, selbstverständlich).

Sollte ich wahrscheinlich einfach in dem synchronem Prozess ein Signal
als zwischenspeicher für PWM-Taskgrad verwenden, und dieser Signal mit
jedem clock'event aus dem Latch aktualisieren, allerding nur dann wenn
CS nicht aktiv ist. Würde diese "Einsynchronisierung" funktionieren?
Gibt es andere, bessere, Möglichkeiten?

Oder ist es besser, in dem synchronen Prozess zwei werte nacheinander
vergleichen, und wenn diese übereinstimmen, dann für PWM-Taskgrad
verwenden?

Wie du richtig erkannt hast, ändern sich die Zuständen auf den Steuer
und Datenleitungen praktisch nicht gleichzeitig. Daher werden immer nur
die Steuerleitungen einsynchronisiert. Die Datenleitungen braucht man
nicht mehr einsynchronisieren, da sie sowieso gleichzeitig oder länger
als ein Steuersignal "Data available" anliegen müssen.

Wenn ich das richtig lese, dient hier die CS-Leitung als Indiz für
valide Daten. Dieses wäre das enable für das erste Latch des
Datenwortes. Dann braucht es einen Prozess, der die PWM generiert.
Dieser sollte ein eigenes Datenregister haben, daß nur zu bestimmmten
Zeiten - wenn es von Seiten des PWM-generierenden Prozesses sinnvoll
und möglich ist - aus dem ersten Register aktualisiert wird, z.B: nach
jedem vollständigen Datenzyklus. DAnn gibt es keine Dateninkonsistenzen
infolge eines umgünstigen Schreibezeitpunktes durch den uC.