Hallo zusammen, ich habe ein Design erstellt, wo schnell gerechnet werden soll. Für den Clock habe ich ein constraint angelegt und jetzt schlägt das Design fehl. Den Teil aus dem Log File habe ich angehängt. Wie muss ich das denn verstehen, wenn die Zeit hier negativ wird? Wenn man den Signalen folgt, dann betrifft das drei Signale, die aus einem BRAM an einen Addierer gehen. Wie kann ich da weiter vorgehen, um das so zu optimieren, dass die Zeiten eingehalten werden? Ich steh hier auf dem Schlauch und die Doku gibt da auch nichts weiter her. Danke euch! Grüße, Jens
Angehängte Dateien:
-
Timing_Errors.JPG
36 KB
Das Delay auf dem Pfad liegt bei 15,892 ns. Dein Constraint erfordert aber 15,892 ns - 5,946 ns, also vermutlich knapp über 100 MHz Takt. Was du da jetzt am bestens machst, ist ohne mehr Infos zum Datenpfad und FPGA nur schwer zu sagen. Vielleicht tut es schon ein zusätzliches Register zwischen BRAM und Addierer. Nutzt Du die DSP Module? Ist der FPGA sehr voll?
:
Bearbeitet durch User
Hallo Andreas, vielen Dank für deine Einschätzung. Das ist ein "Spiel-Projekt" von mir. Einfach nur zum üben. Da verwende ich einen Spartan 3. Der hat keinen DSP Block drin. Ich bin gerade unterwegs, daher kann ich dir leider kein Blockschaltbild machen. Ich versuche es zu beschreiben. Ich habe hier einen rudimentären Rechenkern drin, ähnlich wie bei einem µC. Aber wirklich nur ähnlich. Ich habe ein Opcode-Memory und da springe ich mit einem Programm Counter durch. Im Opcode ist codiert, was für die ALU (im Moment nur ein Addierer/Subtrahierer) die Eingangssignale sind und was die Operation selbst. Und genau der durchgereichte Opcode macht hier das Problem. Das scheint aus dem Memory zur Addierer-Einheit zu langsam sein. Die maximale Frequenz habe ich momentan mit 250MHz angegeben, man will ja flott rechnen ;-) In der Simulation funktioniert das auch prima, nur habe ich meine Zweifel, ob das auch so in der Schaltung die Geschwindigkeit erreicht. Das mit den Registern habe ich auch schon gelesen, dass das helfen soll. Wie oder was müsste ich denn da machen? Viele Grüße, Jens
> negativen Zeiten dazu fällt mir der alte Limerick ein Relativity. There was a young lady named Bright Whose speed was far faster than light; She set out one day In a relative way And returned on the previous night. https://quoteinvestigator.com/2013/12/19/lady-bright/ schon von 1923, Einsteins Relativitätstheorie war laut Wikipedia 1905/1916
Jens W. schrieb: > Die maximale Frequenz habe ich momentan mit 250MHz angegeben, man will > ja flott rechnen ;-) Da ist ein antiker Spartan 3 einfach die falsche Wahl. :-) Im Datenblatt (https://docs.amd.com/v/u/en-US/ds099) stehen die maximalen Delays für die verschiedenen Elemente des FPGAs, BRAM, Multiplizierer, etc... Das BRAM allein hat schon mindestens 0,43 + 2,09 = 2,52 ns Verzögerung, um ein Datum auszugeben. Da bleibt bei Deinen 4 ns pro Takt nicht mehr viel für Routing und CLBs übrig. Die 18 x 18 Bit Multiplizierer des Spartan brauchen auch über 5 ns für das höchstwertige Bit.
Hallo Andreas, Andreas H. schrieb: > Da ist ein antiker Spartan 3 einfach die falsche Wahl. :-) Da hast du sicher Recht! Das ist schon ein altes Teil. Aber da ich ja nur ein bisschen spielen will, steige ich nicht auf ein Spartan 7 um. Vor allem, da man die Gehäuse nur noch als BGA bekommt. Aber genau dafür ist die Erkenntnis ja gut, dass man versteht woran es nun liegt, dass man die maximale Taktrate aus dem Datenblatt nicht erreicht. Aber ich würde gerne nochmal auf das Register zurück kommen. So wie ich es verstanden habe ist das ein FF. Klar, damit wird das Signal synchron zum Takt verarbeitet, was beim Timing Vorteile bringt. Aber wird das Signal dadurch nicht auch verzögert? Wie geht das zusammen, dass das gesamte Design schneller wird, wenn das Signal selbst verzögert wird? Viele Grüße, Jens
Das Design wird durch Pipelining "schneller". Mal angenommen, du schaltest 2 Gatter hintereinander, die jeweils 100ns brauchen. Dann beträgt die Verzögerung insgesamt 200ns. Wenn du aber ein Register dazwischen machst, kannst du alle 100ns ein Datum durchschieben. Es kommt trotzdem erst nach 200ns raus, aber eben alle 100ns ein neues. Das verspricht doppelten Durchsatz. Die Gatter arbeiten sozusagen "parallel". mfg, Fooji
An den Spartan3 BRAMs gibt es schnell Verstopfung, wenn da noch Decoder-Logik haengt. Mit einem zusaetzlichen Ausgangsregister und Aufstueckeln in weitere Pipeline-Stages kriegt man das aufgeloest, aber 250 MHz klingen mir recht optimistisch. Im Timing-Report und Floorplanner muesstest du eigentlich sehr schnell auf die Ursache stossen.
Hallo Fooji, Hallo Martin, vielen Dank für die Aufklärung. Das leuchtet mir ein mit dem Pipelining. Ich möchte das gerne Stück für Stück versuchen. Wenn ich das mit einer Pipeline machen will, dann muss ich vermutlich recht viel an der Struktur ändern, dass das funktioniert. Der Pfad, der da klemmt, ist ja gerade der, der aus dem BRAM die ALU mit Daten versorgt. Ich möchte hier gerne erstmal ein Register ergänzen. Aber wie mache ich das richtig? Einfach ein FF hat nichts gebracht. Ich hänge mal die Implementierung von mir zum OpCode ROM. Wie muss das aussehen mit einem Register am Ausgang? Martin S. schrieb: > 250 MHz klingen mir recht optimistisch. Ja, das wird nicht erreichbar sein. Das ist in der Tat illusorisch. 90MHz sind mir aber auch ein bisschen zu wenig. Wenn ich in die Region 150MHz kommen würde, wäre ich auch mehr als zufrieden. Viele Grüße, Jens
Das einfachste Register wäre ja folgendes:
1 | entity registers_1 is |
2 | port(C, D : in std_logic; |
3 | Q : out std_logic); |
4 | end registers_1; |
5 | |
6 | architecture archi of registers_1 is |
7 | begin
|
8 | process (C) |
9 | begin
|
10 | if (C'event and C='1') then |
11 | Q <= D; |
12 | end if; |
13 | end process; |
14 | end archi; |
Das käme dem gleich wenn ich aus der Implementierung meine ROMs folgende Zeile
1 | Dout <= std_logic_vector(Parameter_Rom(RomAddr)); |
einfach in den Prozess reinschiebe. Aber das hat nichts gebracht am Timing. Ich verstehe nicht, wie oder wo ich das Register am Ausgang richtig setze. Grüße
Du musst wohl oder uebel die Logikverstopfung per detailliertem Timing-Report aufspueren und da entsprechend noch mehr Delay-Register einfuegen. Sonst ist das oben schon korrekt, wenn auch man kaum noch `(C'event and C='1')` in freier Wildbahn sieht :-) Aber was ganz anderes: Bevor du dich ins Hochschrauben auf maximale f_max stuerzt, koenntest du auch deinen Mikrocode auf besagtes Pipelining optimieren, also auf Eimerketten-Prinzip mit parallel arbeitenden Opcodes. Allerdings ist das nur fuer linear ablaufende Hardware-Schleifen ohne Spruenge trivial. Ich lese aus deinem Mikrocode allerdings einiges an IDLE-Zyklen, so dass sich das zumindest auf eine FSM-Pipeline Kombi runterkochen sollte und du mit realistischen 50 MHz f_max auf der entspannten Seite bist. Dann: Dein ROM braucht vermutlich zwei BRAM-Primitiven, da recht breit, mit Runterschrumpfen auf kompaktere Opcodes und einer Decoder-Stufe dazwischen holst du allenfalls auch noch etwas raus, mit nur einem BRAM-Block oder gar erzwungener Fabric/LUT-RAM-Umsetzung verteilt sich die Logik allenfalls besser. Das BRAM brauchst du ja nur, wenn du zur Laufzeit dein "Programm" aendern willst.
Nur mal so 'ne Hausnummer: Wir hatten damals Probleme einen Microblaze mit 100 MHz laufen zu lassen. Mit 90 MHz ging es. Kann mich aber nicht mehr erinnern, ob es ein Spartan 3 oder ein Spartan 3E war...
Hallo zusammen, vielen Dank für eure Hilfe! Rick D. schrieb: > Nur mal so 'ne Hausnummer: Wir hatten damals Probleme einen Microblaze > mit 100 MHz laufen zu lassen. Mit 90 MHz ging es. Kann mich aber nicht > mehr erinnern, ob es ein Spartan 3 oder ein Spartan 3E war... Ich komme auch immer mehr zu der Erkenntnis, dass ich mich von den Taktraten aus dem Datenblatt habe blenden lassen. Aber dafür ist es ja gut. Das ist die Erfahrung, die ich machen wollte. Das Pipelining werde ich mir noch näher anschauen. Das klingt für mich noch nach einer Option. Den Rest werde ich auf dem einfachen kleinen FPGA nicht umsetzen können. Wenn man genau in die Familie schaut, ist es schon ein Unterschied, ob man ein Spartan 3 oder ein Spartan 3E/A/AN nimmt. Die unterscheiden sich genau an dem BRAM. Die einen haben die Output Register mit integriert (und die DSP Slices), meines natürlich nicht. Ich werde mit den Zeiten leben müssen. Vielleicht komme ich von den 11ns auf 8ns runter, aber sicher nicht in die Region 5ns. Martin S. schrieb: > `(C'event and C='1')` in freier Wildbahn sieht :-) Da hast du wohl recht, das war aus dem XST User Guide herauskopiert. Das ist in die Jahre gekommen, da das FPGA das auch ist! ;-) Viele Grüße, Jens
Thread beobachten
Seitenaufteilung abschaltenBitte 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.