Synchronisation der Signale

[AL (Gast)]

Hallo,
ich habe hier ein Schematic vor mir wo viele "AND" und "OR" Gatters 
sind.
Das Problem ist das der Trigger(TrigX) zwar am Eingang ankommt aber 
nicht auslöst. Kann das sein das hier irgendein Synchrnonisationsfehler 
ist? unterschiedliche Signallaufzeiten?

Gruß

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[AL (Gast)]

Lothar Miller schrieb:
> AL schrieb:
>> aber nicht auslöst.
> Was heißt "nicht auslöst"?
> Was soll der Trigger "auslösen"?
mit dem Trigger sollen RAM Adressen generiert werden(Sync1.jpg 
rdadrCnt), mit dem Signal RdStep1 Werte vom RAM auslesen, und mit 
RdStep2 ausgeben.

> 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"!

> Sind SwTrig{11} und Lock{12} auf dem richtigen Pegel?
die sind interne Signale

> Mit/auf welcher Plattform ist das Ganze realisiert?
Lattice XP2 /Diammond

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

>> 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 (Gast)]

Lothar Miller schrieb:
> Das ist Designtechnik aus dem letzten Jahrtausend. Richtig?
- das stimmt auch

- Der Ausgang vom I460 wird schon High nach dem Trigger

>> Sind SwTrig{11} und Lock{12} auf dem richtigen Pegel?
- das werde ich noch prüfen, aber da der Ausgang vom I460 immer high 
wird nach dem Trigger, sind beide Signale schon ok.


- Sync1 ist nur eine andere Seite vom Design

- Kann man eigentlich neben dem Schematik auch VHDL Code schreiben und 
auf diese Signal (Clk_EN, Step0,..) zugreifen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[AL (Gast)]

Der externe Trigger ist ein Puls von 1ms, also nach 1ms ist er wieder 
low, und der nächste Puls kommt nach etwa 50ms..

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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 (Gast)]

d.h. Trigger und Clk-EN mit dem 32MHz Clock einsynchronisieren => werde 
ich morgen testen
Vielen Dank.

Wie sieht es aus wenn ich doch dieses Schematic mit VHDL erweitern 
möchte, kleine Funktionen, geht das(mischen von schematic und VHDL)? wie 
kann ich auf die internen Signale zugreifen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...   ;-)

[Christian R. (supachris)]

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 (Gast)]

Hallo,

bezüglich das mit dem Einsynchronisieren der Ext. Signale mit 2 FF 
(siehe Bild "Einsynchronisieren durch 2 FlipFlops" im 
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren )

Asynch_in ist der Externe Input und FF2_out ist das Signale was weiter 
verarbeitet wird, ds sieht aus nach nur einer Verzögerung, und die 
Problematisch der Gatterlaufzeiten werden weiter bestehen, oder habe ich 
das falsch verstanden?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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)"

[AL (Gast)]

Lothar Miller schrieb:
> 2. gleich alles in VHDL schreiben.
Das wollte ich auch seit langer Zeit tun, leider bis jetzt noch nicht 
geschafft, und soo gut kenne ich mich nocht nicht mit VHDL, komme aus 
der "C" Ecke.

Aber jetzt zum Konzept:
Das prinzip ist eigentlich ganz einfach:
- UC schickt Daten zum PLD
- PLD Speichert die Daten im RAM
- Nach dem Ext Trigger: PLD Liest die RAM Adressen nach Einander und 
gibt die Daten an bestimmten Outputs aus.

Für mich werden es drei Prozesse sein:
Proc_1: Organisiert die Serielle Kommunikation mit dem uC und bereitet 
die Daten für den RAM.

Proc_2: Daten im RAM schreiben und lesen

Proc_3: Bearbeitet den Ext. Trigger, Liest Daten vom RAM, und setzt die 
Outputs.


- Proc_1 und Proc_3 greifen beide auf Proc_2. Das muss irgendwie 
gehandelt werden, reichet es hier ein RamBusy Signal?, oder wie wird das 
allgemein gemacht?
- Die Kommunikation zwische Prozesse läuft über Signale in VHDL, stimmt?

Vielen Dank