Hallo, anscheinend hab ich damals in der Schule nicht richtig aufgepasst und jetzt Recht sich das in Unwissenheit, deshalb hoffe ich hier auf eine Verständliche Antwort. Ich bekomme von einem Master Mikrocontroller 8Bit Werte mittels SPI Bus auf meinem CPLD gesendet. Zum Anfang möchte ich nur ein Schieberegister in den CPLD beschreiben und keine Daten zum Master zurueck senden. Die Beschreibung eines 8Bit Schieberegister ist nicht so schwer, aber in anderen Beiträgen habe ich gelesen, dass man eine Steigende / Fallende Flanke mittels doppelter Abtastfrequenz oder DDR Verfahren erkennen kann. Ich persönlich würde das DDR Verfahren nutzen, aber jeder bewältigt seine Probleme auf seine eigene Art. Wieso kann ich kein flankengesteuertes Flip Flop beschreiben? Er liesst doch erst das Bit bei Clock High ein und das Spiel beginnt von vorne. Ist es nur zur Sicherstellung, dass wenn die Clockleitung 1 = Idle ist eine richtige Erkennung erfolgt? Der AVR kann auch maximal eine Masterlock / 2 SPI Bus Freq. sampeln als SPI Slave, deshalb wird auch hier wohl eine Flankenerkennung genutzt. Liege ich mit meiner Vermutung richtig ?
Michael schrieb: > Hallo, anscheinend hab ich damals in der Schule nicht richtig aufgepasst > und jetzt Recht sich das in Unwissenheit Scheint ganz der Fall zu sein SCNR
Ok, ich hab eine Seite gefunden die eine Einsyncronisierung beschreibt und Anhand deren Beschreibung viel der Groschen. @Christoper D. Sinnvoller Post. Bedenke jeder fing mal an.
>Hallo, anscheinend hab ich damals in der Schule nicht richtig aufgepasst >und jetzt Recht sich das in Unwissenheit, deshalb hoffe ich hier auf Recht --> rächt Das war aber schon in der Grundschule der Fall! Gast4
>Ok, ich hab eine Seite gefunden die eine Einsyncronisierung beschreibt >und Anhand deren Beschreibung viel der Groschen > Michael kannst du mal bitte den Link zur dieser Seite schicken?
ftp://ftp.fh-konstanz.de/pub/ti/electronic_design_center/DSYS/Vorlesung/ KAPITEL_GDS.pdf vergessen.
> ftp://ftp.fh-konstanz.de/pub/ti/.... Insgesamt eine schöne und lesbare Aufstellung von Regeln. Aber die Regel 3 ist zumindest für Xilinx FPGAs suboptimal:
1 | Regel 3: Flipflops müssen mit externem Reset (rück-) setzbar sein |
2 | Alle Flipflops sollten von (möglichst) einem externen Resetsignal setzbar |
3 | oder rücksetzbar sein. |
4 | Im Betrieb kann dann durch eine "Power-on-Reset" - Schaltung ein kurzer |
5 | Resetimpuls erzeugt werden und das System befindet sich dann in einem |
6 | definierten Anfangszustand. |
Das wurde schon im Beitrag "Xilinx und die Resets" diskutiert.
Hallo, im Dateianhang hab ich eine Flankenerkennung im Internet als Lernhilfe gefunden und mir wird nach der Synthese ein 2 Bit Schieberegister angezeigt. Das Schieberegister entspricht auch meinen Erwartungen, aber das Design ist relativ langsam mit ~200MHz. In dem Angang weiter unten findet Ihr eine Flankenerkennung von mir mit knapp 500MHz und in der Simulation Verhalten sich beide Beschreibungen identisch, aber in meiner Beschreibung findet er 2 Multiplexer. Setze ich in der Case Abfrage die Snyc Signale (Sync_l und Sync_h) zusätzlich auf logisch 0, dann entfernt die Synthese beide Multiplexer und die Geschwindigkeit sinkt auf ~400MHz. Ist meine Case Anweisung nicht richtig beschrieben oder warum wird in meinem Design kein Schieberegister beschrieben? Welche Beschreibung ist die bessere oder sichere?
Angehängte Dateien:
-
MitMux.gif
7,3 KB
> Ist meine Case Anweisung nicht richtig beschrieben oder warum wird in > meinem Design kein Schieberegister beschrieben? Da ist doch ein Schieberegister drin (Screenshot: blau). Das geht dann auf die Select-Eingänge des MUX. > ~200MHz. ... 500MHz ... ~400MHz. Ich verwende einen Spartan3-400 Speedgrade -4. Das Originaldesign hat bei mir 260MHz. Dein gepostetes Design hat 367 MHz. Mit den aktivem synchronen Zurücksetzen (sync_l <= '0') dann noch 238 MHz. Die Geschwindigkeitsverluste kommen offenbar dadurch, dass in der Originalbeschreibung und in deiner "langsamn" Beschreibung FFs verwendet werden, die eine Kombinatorik vor dem synchronen Reset-Eingang haben. Ich habe mal die Originalfassung analysiert und auf diese Variante umgeschrieben:
1 | fast_sync1 : process(clk) |
2 | variable resync : std_logic_vector(1 to 3); |
3 | begin
|
4 | if rising_edge(clk) then |
5 | -- detect rising and falling edges.
|
6 | rise <= not resync(2) and resync(3); |
7 | fall <= not resync(3) and resync(2); |
8 | -- update history shifter.
|
9 | resync := not async_sig & resync(1 to 2); |
10 | end if; |
11 | end process; |
Hier ist keinerlei Kombinatorik mehr nötig (Screenshot im nächste Post), und das Ding ist mit 376 MHz am schnellsten ;-)
Angehängte Dateien:
-
MitMuxNoReset.gif
6 KB
Dass du auf die Zahlen der Synthese nicht allzuviel geben solltest, erkennst du, wenn du den synchronen Reset aus deinem Design herausnimmst. Es wird eigentlich der selbe RTL-Plan erzeugt, nur der Reset-Pin der FFs ist nicht angeschlossen (Screenshot). Deine "schnelle" Variante hat dann aber nur noch 294 Mhz (statt 367) :-o
Danke Lothar für die Hilfe! Die erklärung von Dir ist einleuchtend und für die Zukunft werde ich mehr die RTL's prüfen und mich nicht allein auf den Synthesereport verlassen.
Hi, sorry für diese Anfängerfrage, aber ich versuche mich gerade ( leider nur am WE ) in die Materie einzuarbeiten. Was genau sagen diese MHZ Zahlen aus? 1. Die Schaltung läuft auf einem idealem CLPD/FPGA in dieser Geschwindigkeit?? 2. Die Schaltung läuft auf einem neuen aktuellem CLPD in dieser Geschwindigkeit wenn die Taktrate stimmt ?? 3. Ganz was anderes ;-) bis dann, MaxMeise
Naja, die MHz nach der Synthese sind ziemlich obskur. Wichtig ist, was nach dem Fitting bzw. Place&Route rauskommt. Da richtet der sich aber nach deinen Vorgaben im UCF File, der Optimizer rechnet nur so lange wie nötig, wenn die Vorgabe erreicht ist, hört der auf.
> Was genau sagen diese MHZ Zahlen aus?
Es läuft ohne weitere Optimierungen auf dem angegebenen Spartan 3
Speedgrade -4 mit dieser Geschwindigkeit. Mit entsprechenden
Optimierungseinstllungen könnte das noch ein wenig schneller werden...
> Mit entsprechenden Optimierungseinstllungen könnte das noch ein wenig > schneller werden... Wenn man einen größeren Chip nimmt, mehr Logik hinzufügt oder mehr kombinatorische Tiefe einbaut kann es auch signifikant langsamer werden :-/ Also alles in allem: Die Zahlen sind nur ein grober Richtwert, solange man mit dem Design noch nicht endgültig fertig ist. Duke
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.