|
|
Forum: FPGA, VHDL & Co. Fehler bei der SyntheseHallo zusammen, warum bekomme ich so ein Fehler bei der Synthesis: The logic for ClkOut does not match a standard flip-flop? (FPGA: lattice XP2)
Neuling schrieb: > The logic for ClkOut does not match a standard flip-flop? Klar, du schreibst: Solange eine steigende Flanke da ist, solange soll ClkOut high sein, sonst aber low. Nur ist per Definition eine Flanke unendlich kurz. Also muss dein ClkOut eigentlich (abgesehen von unendlich kurzen Unterbrechungen) dauernd low sein. Das macht aber keinen Sinn, und das merkt das Synthesetool und sagt es dir... Auch beim Lattice ist es doch bestimmt sinnvoll, den Takt mit einem DDR-Register auszugeben, damit er nicht das schnelle Taktnetzwerk verlassen muss. Neuling schrieb: > Hallo zusammen,warum bekomme ich so ein Fehler bei der Synthesis: Mit einem solchen, manuellen Kontrukt, kann man immer nur (jeweils zur Taktflanke) ein Signal togglen und damit maximal die halbe Frequenz erzielen. Siehe JK-FF. Daher müsste man die doppelte Takt-Rate nehmen, um hinzukommen. Die einizige Möglichkeit in einem synchronen Design beim einfachen Takt zu bleiben und dennoch lokal die doppelte Rate zu haben, ist steigende und fallende Flanke zu nutzen und das geht eber nur mit einem DDR-FF. Manuelles rising und faling zu nutzen, was ja sehr gerne immer wieder gebaut wird, funktioniert nicht! Warum nicht einfach HW_CLK <= osc_int; dann würdest du deinen internen Takt einfach weitergeben oder was wolltest du damit anderes machen? Gustl Buheitel schrieb: > Warum nicht einfach > > HW_CLK <= osc_int; Wenn das auf einen I/O soll, ist das (zumindest bei Xilinx) nicht sinnvoll. Denn dann muss der gesamte Takt intern auf normalen Signal-Pfaden geroutet werden, was bei höheren Frequenzen und/oder Anfordertungen an Jitter und Skew schlechte Ergebnisse bringt. Daher den Takt an ein DDR-Ausgang-Flipflop anlegen, und die Dateneingänge fest verdrahten, somit kann man den Takt 1:1 oder invertiert ausgeben und intern kann er auf den schnellen Taktnetzen geführt werden. Ist sicherlich bei Lattice und Altera nicht viel anders. Ok, ich hatte da nie drüber nachgedacht, aber verstehe ich das richtig, dass dann der komplette Takt im FPGA schlechter wird nur weil man den an einer Stelle nach aussen führt? Ich hätte vermutet, dass da ein normales Taktnetz verwendet wird und eben an einer Stelle der Takt an einen Ausgang übergeben wird. Man lernt nie aus ... vielen Dank für die Antwort. an "osc_int" hängt eigentlich einen Quarz, und ist als normaler Input deklariert (und in Diamond mit LVCMOS33 konfiguriert). Wird das noch mit der Anfrage "if osc_int'event and osc_int='1' then " funktionieren? oder muss ich den Pin doch irgendwie als Clock_Input konfigurieren?
Angehängte Dateien:
Neuling schrieb: > an "osc_int" hängt eigentlich einen Quarz > Wird das ... funktionieren? Nur mit einem Quarz allein sicher nicht... > Wird das noch mit der Anfrage "if osc_int'event and osc_int='1' then" > funktionieren? Ja, es wird auf jeden Fall gehen. Du kannst aus dem Routing-Netzwerk auf die Taktnetze gehen. Im Anhang mal die Taktung eines MachXO. > oder muss ich den Pin doch irgendwie als Clock_Input konfigurieren? > ist als normaler Input deklariert Ist eine (Neben-)Funktion dieses Eingangs evtl. "Takteingang"? Dann müsste das Signal nicht erst noch umständlich mit zusätzlichem Jitter auf ein Taktnetz geroutet werden... Also: welches FPGA? Welcher Pin? Neuling schrieb: > PCLKT0_0 Das ist ein Takteingang, der bei Bedarf auch als normaler Eingang verwendet werden könnte. An solche Pins gehört der Takt angeschlossen. Du hättest natürlich auch sagen können, dass du z.B. das "LatticeXP Standard Evaluation Board" verwendest. Bei solchen Eval-Boards sind Taktquellen immer an Takteingänge angeschlossen. Sonst gehört der Designer gefeuert... Lothar Miller schrieb: > Neuling schrieb: >> The logic for ClkOut does not match a standard flip-flop? > Klar, du schreibst: > Solange eine steigende Flanke da ist, solange soll ClkOut high sein, > sonst aber low. Nur ist per Definition eine Flanke unendlich kurz. > Also muss dein ClkOut eigentlich (abgesehen von unendlich kurzen > Unterbrechungen) dauernd low sein. Hm, da osc_int in der Sensitivity list steht, sollte die IF-abfrage nur dann ausgewertete werden wenn auf dem Signal osc_int ein event passiert (es zugewiesen wird). Das heist im Normalfall das das IF nur bei Flanken von osc_int (osc_int'event) ausgewertet wird. Es sollte also (bei der Simu ein Signal clk_out) erzeugt werden, das bei osc_int wechsel auf "1" ebenfalls auf "1" wechselt und bei osc_int wechsel auf "0" ebenfalls auf "0" folgt und kein "Quasi-Low". Die Begründung von L.M. passt m.E. hier nicht. Das ist aber kein Standard-FF das auf beiden Flankenwechsel reagiert, sondern ein DDR-FF ... . MfG, Fpga Kuechle schrieb: > Hm, da osc_int in der Sensitivity list steht, sollte die IF-abfrage nur > dann ausgewertete werden wenn auf dem Signal osc_int ein event passiert > (es zugewiesen wird). Das heist im Normalfall das das IF nur bei Flanken > von osc_int (osc_int'event) ausgewertet wird. Die Sensitivliste interessiert allerdings allein und ausschliesslich nur den Simulator. Die Beschreibung würde also sogar augenscheinlich richtig simuliert, nur eben einfach nicht synthetisiert werden... > Die Begründung von L.M. passt m.E. hier nicht. Ich bin da vom Synthesizer ausgegangen. Der macht die Realität... ;-) (ganz oben steht schon XP2) kann ich von diesem Takt und mit der PLL einen 4 Vierfachen generieren und als Systemtakt(zum Synchronisieren der Prozesse) beutzen? Neuling schrieb: > kann ich von diesem Takt und mit der PLL einen 4 Vierfachen generieren > und als Systemtakt(zum Synchronisieren der Prozesse) beutzen? Ja. Aber warum denn überhaupt? Hast du sonst noch irgendwelche Engpässe? Wie schnell wäre denn der 4-fache Takt? Als Gedankenstütze: ein durchgängig mit 200MHz getaktetes Design ist für einen Neuling nicht machbar... Es ist unser eigenes Board, der Quarz hat 32768MHz. Ich brauche einen schnelleren Takt (2 Facher wird auch reichen) für die Prozesse. Die PLL generiere ich mit der IPExpress, als Component rufe ich sie in der Top Entity auf, und übergebe ich osc_int zu CLK, Stimmt das? oder habe ch was vergessen? Neuling schrieb: > 32768MHz Fast 33GigaHertz. Das ist mal wirklich schnell... :-o Aber 64MHz dürften auch für Anfänger problemlos machbar sein. > Ich brauche einen schnelleren Takt (2 Facher wird auch reichen) für die > Prozesse. Warum? > Die PLL generiere ich mit der IPExpress, als Component rufe ich sie in > der Top Entity auf Man ruft da nichts auf. Es werden komponenten instatiiert. In einem Schaltplan rufst du ja auch keine ICs auf, sondern du setzt sie ein und verdrahtest sie. Genau das selbe machst du mit VHDL... Weil der XP2 mit einem Pic32 seriel kommunizieren muss, die Datenübertragung soll so schnell laufen wie es möglich ist (der PIC32 kann (Theoretisch) bis 40MHz), parallell können Daten im EBR geschreiben und gelesen werden. Neuling schrieb: > Weil der XP2 mit einem Pic32 seriel kommunizieren muss, die > Datenübertragung soll so schnell laufen wie es möglich ist Dann muss also nur das Interface mit Vollgas laufen. Und seriell bedeutet für mich: der Rest vom Design kann auch schnarchlangsam laufen... > (der PIC32 kann (Theoretisch) bis 40MHz) Wo kann der so schnell? Ist das eine synchrone serielle Übertragung wie z.B. SPI? >Wo kann der so schnell? PBCLK (=SYSCLK/2) wenn der SysClk 80MHz ist >Ist das eine synchrone serielle Übertragung wie z.B. SPI? ja, es gibt Clk, SDI, SDO Leitungen Neuling schrieb: >>Ist das eine synchrone serielle Übertragung wie z.B. SPI? > ja, es gibt Clk, SDI, SDO Leitungen Dann mach nur den SPI so schnell. Und zwar mit einem lokalen Takt. Das geht ganz ohne Taktnetz locker so schnell... Die Datenübernahme machst du dann "langsam" in der 32MHz Domäne. Wie kann man die Datenübertragung sicherer machen, wenn ein Telegramm eine Länge von 150Bit hat? - Paritätsbit einfügen? - Die über SDI gesendte Bits wieder über SDO prüfen (FPGA bekommt über SDI '1' => FPGA gibt wieder '1' an SDO aus)? - Bessere Ideen? Neuling schrieb: > - Paritätsbit einfügen? Erkennt nur eine ungerade Anzahl von Fehlern... :-o > - Bessere Ideen? CRC erzeugen und übertragen > - Bessere Ideen?
Den Kanal fehlerfrei halten. SPI ist ja on-Board Kommunikation zwischen
zwei Chips, da sollte das möglich sein. Ist wohl etwas mit Kanonen auf
Spatzen geschossen, da Fehlerkorrektur einzubauen. Fehlerkorrektur
brauchts bei fehlerbehafteten Kanälen (lange Übertragungsstrecken,
Funktübertragung etc.)
Das mit dem CRC habe ich irgendwie vergessen, werde mich damit beschäftigen. Aber ist auch anwendbar wenn die Länge der gesendeten Daten nicht fest ist ( sagen wir mal zwischen 18 und 150)? @Peter K. Ja, die Leitungen sind Lang, und angesprochen werden mehrere FPGAs gleichzeitig. Eine FPGA_ID am Kopf des Telegramm bestimmt den angesprochenen. Also alle FPGAS bekommen das gleiche Telegramme nur einer darf aber ausführen, daher brauche ich die Sicherheit. Neuling schrieb: > Ja, die Leitungen sind Lang, und angesprochen werden mehrere FPGAs > gleichzeitig. Wie lang ist lang? Ich hoffe die Enden der Leitung gehen nicht direkt an die FPGA-Pins. Da gehören geeignete Leitungstreiber dazwischengeschaltet. Duke >Wie lang ist lang? ein paar cm (~7cm) >Ich hoffe die Enden der Leitung gehen nicht direkt an die FPGA-Pins. doch, 3,3V beide. Warum nicht? Neuling schrieb: >>Wie lang ist lang? > ein paar cm (~7cm) Dann wirst du bei halbwegs vernünftigem Layout auf dieser Übertragungsstrecke keine Fehler haben! Neuling schrieb: >>Wie lang ist lang? > ein paar cm (~7cm) Achso. Dann sollte es ok sein. >>Ich hoffe die Enden der Leitung gehen nicht direkt an die FPGA-Pins. > doch, 3,3V beide. Warum nicht? Ich hatte irgendwie wesentlich größere Entfernungen angenommen... Duke 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten