im Anhang habe ich euch das Projekt angehängt um das es geht. ich bin dabei eine Steuerung für mein bitseriellen Cordic zu implementieren allerdings bekomme ich eine Warnung die ich einfach nicht beheben kann. Zudem bin ich mir nicht wirklich sicher ob die Art und Weise wie ich meine FSM beschreibe überhaupt in ordnung ist. Mein Design orientiert sich an der traditionellen architektur mit 3 shiftregistern, einem rom und 3 1 bit Subb/Add rechenwerken. der Ablauf wird mittels einer FSM geregelt die unter anderem auch das Argument mit Y vergleicht und die SubADDSel leitung der addierer steuert um zu entscheiden ob addiert oder subtrahiert werden soll. Diesen Vergleich findet ihr ab Zeile 161 in der ich Die differenz berechne und das erste bit als Sign bit verwendet und an die addierer schicken. genau an dieser Stelle kommt aber auch die folgende Warnung: WARNING:HDLCompiler:871 - "C:\Users\D3XT3ER-Eee\Desktop\srcV1.2_Final\seriaAdder\SerialAdder.vhd" Line 66: Using initial value "0000000000000000" for serial_addersignal_z since it is never assigned WARNING:Xst:737 - Found 1-bit latch for signal <Cin>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems. WARNING:Xst:3002 - This design contains one or more registers/latches that are directly incompatible with the Spartan6 architecture. The two primary causes of this is either a register or latch described with both an asynchronous set and asynchronous reset, or a register or latch described with an asynchronous set or reset which however has an initialization value of the opposite polarity (i.e. asynchronous reset with an initialization value of 1). wenn ich jetzt allerdings Zeile 162, 163 oder 164 ausklammere, dann verschwindet diese Warnung. Weiss jemand Rat?
sergej schrieb: > Zeile 162, 163 oder 164 Welche sind das? Muss ich jetzt nachzählen? > dann verschwindet diese Warnung. Welche der drei angezeigten Warnungen ist "diese"? Noch ein Wort zum Sonntag (und evtl. zum angemeckerten Cin-Latch):
1 | Cin <= '0' when SubAddSell = '0' else |
2 | '1' when SubAddSell = '1'; |
Dir ist klar, das std_logic eine NEUNwertige Logik ist? Du verwendest zwei davon. Was passiert bei den anderen 7 Zuständen? Und warum schreibst du nicht einfach sowas:
1 | Cin <= SubAddSell; |
BTW: diese Zuweisung ist hier sinnlos: AngleOutput<= "ZZZZZZZZZZZZZZZZ"; Denn das Fehlen jeglicher Steuersignale legt nahe, dass da offenbar kein Tristate-Bus nach aussen hin tätig ist...
Lothar Miller schrieb: > sergej schrieb: >> Zeile 162, 163 oder 164 > Welche sind das? Muss ich jetzt nachzählen? Hallo Lothar, entschuldige, ich habe damit gerechnet, dass du den Code im Editor aufmachst um ihn dir anzusehen und könntest dann die Zeilennummern sehen. es geht um die Anweisungen >> dann verschwindet diese Warnung. > Welche der drei angezeigten Warnungen ist "diese"? > > Noch ein Wort zum Sonntag (und evtl. zum angemeckerten Cin-Latch):Cin > <= '0' when SubAddSell = '0' else > '1' when SubAddSell = '1'; > Dir ist klar, das std_logic eine NEUNwertige Logik ist? Du verwendest > zwei davon. Was passiert bei den anderen 7 Zuständen? > Und warum schreibst du nicht einfach sowas:Cin <= SubAddSell; Das ist mir im nachhinein auch aufgefallen, ich habe es geändert und nun scheinen auch die warnungen: WARNING:Xst:737 - Found 1-bit latch for signal <Cin>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems. WARNING:Xst:3002 - This design contains one or more registers/latches that are directly incompatible with the Spartan6 architecture. The two primary causes of this is either a register or latch described with both an asynchronous set and asynchronous reset, or a register or latch described with an asynchronous set or reset which however has an initialization value of the opposite polarity (i.e. asynchronous reset with an initialization value of 1). verschwunden zu sein. Ich habe allerdings nun ein anderes Problem. ich benötige bei jeder neuen Iteration den inhalt des RegistersY um ihn mit dem übergebenen Argument zu vergleichen. Den Inhalt hole ich mir im Moment so: TempOutputY <= signed(OutputSignalY) when CurrentSTATE = NEWITERATION and AddCounter = 0 else TempOutputY das soll bedeuten, wenn der Addcounter = 0 ist soll er den Wert übernehmen ansonsten seinen Wert beibehalten. JEtzt ist mir natürlich klar, dass ich damit ein LAtch verursache aber anders bekomme ich es einfach nicht gelöst. mit einem Process bekomme ich einen unnötigen taktdelay. Meine Konkrete frage ist jetzt, wie schaffe ich es einen Wert bei Addcounter= 0 zu übernehmen und ihn ansonsten unverändert zu lassen?
sergej schrieb: > mit einem Process bekomme ich einen unnötigen taktdelay. Deine Denkweise ist falsch. Es ist nicht der Prozess, der einen Takt Latency bringt, es ist der Takt an sich, der die Latency bringt. Du bekommst diese Latency auch dann, wenn du es so schreibst: TempOutputY <= signed(OutputSignalY) when rising_edge(Serial_Adder_CLK) and CurrentSTATE = NEWITERATION and AddCounter = 0; > aber anders bekomme ich es einfach nicht gelöst. Dein Problem ist, dass du das Schieberegister (das an sich ja schon speichert) so tief in einer Komponente vergraben hast, dass du diese Speicherfunktion nicht mehr nutzen kannst. Am einfachsten wäre es nämlich, nur dann zu Schieben, wenn alle Bedingungen erfüllt sind. Eine andere Möglichkeit ist, mit einem Flag nur die Gültigkeit des Wertes zu signalisieren, und das Speichern (wenn nötig) einer übergeordnetetn Instanz zu überlassen. Dann ist die nämlich dafür verantwortlich, wenn Latency auftritt. sergej schrieb: > Meine Konkrete frage ist jetzt, wie schaffe ich es einen Wert bei > Addcounter= 0 zu übernehmen und ihn ansonsten unverändert zu lassen? Was heißt für dich "bei Addcounter= 0 zu übernehmen"? Sobald ein Flipflop beteiligt ist, gibt es einen Eingang und einen Takt. Und der FF Ausgang übernimmt den Pegel vom Eingang mit einer Flanke am Takt. Du musst also an der Stelle, wo die Daten für den "nächsten Takt" berechnet werden, diese Daten in das "Ausgabgeregister" übernehmen. Das bedeutet eigentlich einfach, dass du "einen Takt vorausdenken" musst.
Lothar Miller schrieb: > Dein Problem ist, dass du das Schieberegister (das an sich ja schon > speichert) so tief in einer Komponente vergraben hast, dass du diese > Speicherfunktion nicht mehr nutzen kannst. Am einfachsten wäre es > nämlich, nur dann zu Schieben, wenn alle Bedingungen erfüllt sind. Ja ich würde es auch nicht noch einmal machen wenn ich wüsste dass es solche probleme gibt. > Was heißt für dich "bei Addcounter= 0 zu übernehmen"? > Sobald ein Flipflop beteiligt ist, gibt es einen Eingang und einen Takt. > Und der FF Ausgang übernimmt den Pegel vom Eingang mit einer Flanke am > Takt. Du musst also an der Stelle, wo die Daten für den "nächsten Takt" > berechnet werden, diese Daten in das "Ausgabgeregister" übernehmen. Das > bedeutet eigentlich einfach, dass du "einen Takt vorausdenken" musst. mit übernehmen meine ich, dass mein Signal TempOutputY den Registerinhalt bei Addcounter = 0 zugewiesen bekommt. ich habe ja eine Addition von 16 bit und dafür brauche ich ja auch 16 Takte. wenn ich jetzt aber ein Takt Delay zulasse, dann komme ich auf 17 und das möchte ich verhindern. So wie es aussieht komme ich nicht daran vorbei das Schieberegister entsprechend zu modifizieren. erst schieben wenn alle bedingungen erfüllt sind, ergibt ja das selbe problem wie mit dem Taktdelay. meine berechnung dauert dann länger als nötig.
sergej schrieb: > erst schieben wenn alle bedingungen erfüllt sind, ergibt ja das selbe > problem wie mit dem Taktdelay. meine berechnung dauert dann länger als > nötig. Nein. Das Signal zum Schieben kommt ja nicht überraschend irgendwann von aussen. Du selber weißt ja schon, was als Nächstes kommt, denn du selber löst den Vorgang ja aus. Und wenn du weißt, dass demnächst geschoben werden wird, kannst du die Signale entsprechend vorbereiten. Garantiert! Das Schieben an sich geht nur mit dem Takt und bringt natürlich einen Takt "Verzögerung"... > ich habe ja eine Addition von 16 bit und dafür brauche ich ja auch 16 > Takte. wenn ich jetzt aber ein Takt Delay zulasse, dann komme ich auf 17 > und das möchte ich verhindern. Du klemmst dich hier selber ein: du musst nicht immer erst den einen Zyklus fertig machen und erst dann den Nächsten anfangen. Du kannst mit dem letzten Takt schon die Daten für den nächsten Zyklus an das Schieberegister anlegen. Dann hast du, auch wenn du die Daten wie in meinem Codeschnipsel einfach synchron übernimmst, bestenfalls im ersten Durchlauf das Ergebnis einen Takt Latency. Aber ab dann bekommst du jeden 16. Takt ein neues Ergebnis...
Lothar Miller schrieb: > Du klemmst dich hier selber ein: du musst nicht immer erst den einen > Zyklus fertig machen und erst dann den Nächsten anfangen. Du kannst mit > dem letzten Takt schon die Daten für den nächsten Zyklus an das > Schieberegister anlegen. Dann hast du, auch wenn du die Daten wie in > meinem Codeschnipsel einfach synchron übernimmst, bestenfalls im ersten > Durchlauf das Ergebnis einen Takt Latency. Aber ab dann bekommst du > jeden 16. Takt ein neues Ergebnis... Ich verstehe glaube ich was du meinst aber wie ich das umsetzen muss weiß ich nicht. Ich weiß, dass mein Zyklus nach addcounter=15 zuende ist und ich beim nächsten Takt das angelgte Signal benötigen werde. Aber wie beschreibe ich es dass er Mir beim nächsten Takt das Signal anlegen soll?
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.