Synchronisation der Signale

AL schrieb:
> aber nicht auslöst.
Was heißt "nicht auslöst"?
Was soll der Trigger "auslösen"?
Wird der Trigger im I460 gespeichert?
Sind SwTrig{11} und Lock{12} auf dem richtigen Pegel?
Mit/auf welcher Plattform ist das Ganze realisiert?

>> Wird der Trigger im I460 gespeichert?
> der Eingang vom Flipflop ist dauern auf High, d.h mit der Flanke des
> Trigger geht Q auf "1"!
Ich fragte nicht "wie" der gespeichert wird (das ist mir klar), sondern 
"ob" er gespeichert wird. Wird der Ausgang von I460 nach einer 
Triggerflanke high?

>> Sind SwTrig{11} und Lock{12} auf dem richtigen Pegel?
> die sind interne Signale
Das ist nicht die Antwrt auf meine Frage.
Meine Frage war: Haben diese Signale den richtigen Pegel?
Mit einer statischen '1' auf einer der beiden Leitungen kann kein 
Trigger erkannt werden.


Was soll das Bild Sync1.jpg aussagen?


BTW:
Das Design ist ein recht Übles, denn den Clk_En des Flipflops wird 
direkt komplett asynchron angesteuert. Das ist Designtechnik aus dem 
letzten Jahrtausend. Richtig?

AL schrieb:
> da der Ausgang vom I460 immer high
> wird nach dem Trigger, sind beide Signale schon ok.
Ja, korrekt.

Und wie setzt du den Trigger zurück?
Normalerweise müsste er ja asynchron durch den I671 zurückgesetzt 
werden.

Okokok, mit "Trigger" meinte ich das Speicherflipflop I460. Das sollte 
eigentlich durch den 32MHz Takt recht schnell (nach 30-60 ns) wieder 
zurückgesetzt werden...

Aber wie gesagt: das Design ist unsauber, weil zumindest die 
Clock-Enable-Setupzeit der Zählerflipflops verletzt werden wird. 
Normalerweise sollte der Trigger einsynchronisiert und dann auf das 
synchrone Signal eine Flankenerkennung aufgesetzt werden.

AL schrieb:
> Wie sieht es aus wenn ich doch dieses Schematic mit VHDL erweitern
> möchte, kleine Funktionen, geht das(mischen von schematic und VHDL)?
Ja, das geht. Dabei werden einfach die Ports der VHDL-Beschreibung auf 
ein Schaltplansymbol gemappt und dann im Schaltplan angeschlossen.

Das wird z.B. gern im Top-Level gemacht, um nicht die ganzen Map-Listen 
schreiben zu müssen. Wie das geht, weiß ich aber nicht, weil ich 
selber noch nie die Schematic-Eingabe verwendet habe...   ;-)

Du kanst dir ein VHDL Modul schreiben und dann "Generate Schematic 
Symbol" dann erscheint das als Schaltplan Symbol in deiner Library. Aber 
das ist alles großer Murks, wenn du an den Ports mal was änderst, passt 
das Symbol nicht mehr und du musst alles neu verstrippen. Lass den 
Quatsch sein und schreib einfach alles in VHDL, das geht viel schneller 
und ist deutlich wartungsfreundlicher.

AL schrieb:
> oder habe ich das falsch verstanden?
Ja.

> Asynch_in ist der Externe Input und FF2_out ist das Signale was weiter
> verarbeitet wird
Und clock ist der 32768kHz-Takt!
> ds sieht aus nach nur einer Verzögerung, und die Problematisch der
> Gatterlaufzeiten werden weiter bestehen,
Es geht darum, dass nach dem Einsynchronisieren im FPGA alles nur noch 
mit dem einen einzigen FPGA-Takt läuft (hier 32MHz). Und dass nach jedem 
Takt die Logik und das Routing zusammen knapp 30ns Zeit zum Berechnen 
neuer Werte und deren Weiterleitung an das nachfolgende Flipflop haben.

Und ob die Laufzeiten ausreichen, das kann die Toolchain ganz einfach 
ausrechnen. Man muss ihr nur mit einem Timing-Constraint auf den Takt 
sagen, dass das Design mit 32MHz laufen soll...

Ich weiß nicht wie groß das Schaltplan-Design ist, aber ich würde es
1. auf ein richtig synchrones Design umstellen  und
2. gleich alles in VHDL schreiben.
Wenn du z.B. 30 Seiten solcher Schaltungen wie oben hast, dann gibt das 
bestenfalls 3 Seiten VHDL!
Zumindest, wenn ich das schreibe...  ;-)
Siehe den Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"