Ich habe eine Zahl im Gray Code welche Ich umwandeln würde und dann eine Zahl im Zweierkomplement. Ist es schlauer beide mit dem Datentyp signed zu rechnen oder eher wenn Ich es in unsigned rechne oder was würdet ihr empfehlen ? Danke für die Hilfe
Hallo Mo, wenn deine Eingangszahlen immer positiv sind, gibt es keinen Grund für signed. Weiterhin gibt es keinen signed/unsigned Adder. Der typ signed oder unsigned wirkt sich nur darauf aus, wie ein Compiler/Syntheser (bei Vergleichen) oder ein Mensch eine Menge von Bits interpretiert. Tom
In der Aufgabe soll ein Eingang positiv sowie negativ sein. Der andere soll nur negativ sein. Und jetzt frage Ich mich wie Ich diese zwei addieren soll.
Mo schrieb: > In der Aufgabe soll ein Eingang positiv sowie negativ sein. > Der andere soll nur negativ sein. Und jetzt frage Ich mich wie Ich diese > zwei addieren soll. Dann zeig doch mal die Aufgabe oder wenigstens ein Blockdiagramm dazu.
Das hier ist die Aufgabe. Das ist das einzige Problem mit dem Ich nicht weiterkomme.
Mo schrieb: > Das hier ist die Aufgabe. Das ist das einzige Problem mit dem Ich nicht > weiterkomme. Du hast den Eingang A also schon vom Graycode in eine positive Binärzahl umgewandelt? Dann mach einfach ein resize() beider Eingangszahlen auf die Zielbreite (ein Bit mehr als der breiteste der beiden Eingangsvektoren) und addiere dann einfach beide Zahlen zusammen. Du erhältst eine Zahl, die du wieder als vorzeichenbehaftete Zweierkomplement-Zahl betrachtest. Fertig.
Könnte Ich einfach ein zwei neue Signale definieren die 5 Bit groß sind und dann so definieren: X<=(A(3)&A); Y<=(B(3)&B); und dann damit rechnen ?
Im Fall des unsigned Vektors doch wohl eher so: X <= '0'&A;
Eine Sache hab Ich da noch nicht ganz kapiert. Wenn mein Eingang der Gray Code eingibt und in positiven Vektor umrechne „1110“ ist und mein Eingang B „0101“ in dem Mode 1 ist wo y<=A+2B ist kommt ja 24 raus. Und y wäre dann „11000“ und wenn das als signed ist kommt ja wieder -8 raus was falsch wäre.
Bei A+2B hast du zwei Additionen: A+B+B und brauchst deshalb noch ein weiteres Bit vornedran, damit der Wertebereich nicht überschritten wird. Und dieses führende Bit ist hier '0', womit das Ergebnis wieder tadellos passt.
:
Bearbeitet durch Moderator
Ich hab jetzt kapiert wie Ich die Aufgabe behandeln muss und auch was Ich machen muss nur Ich weis jetzt nicht ganz wie Ich es umsetzte. Könnt Ihr mir einen Tipp geben wie Ich es am besten umsetzte ?
Mo schrieb: > Könnt Ihr mir einen Tipp geben wie Ich es am besten umsetzte ? Ich würde die Zahlen einfach in ausreichend "breite" Integer umwandeln und damit die gewünschten Berechungen machen und dementsprechend die LEDs ansteuern. Am Rande: Den S11, der als "Schiebetakt" dienen soll, darfst du nicht als "richtigen" Takt verwenden (mit rising_edge() oder 'event), sondern musst ihn einsynchronisieren und eine Flankenerkenung drauf machen.
Wenn Ich die Rechnung komplett in Integer rechne wird es einfach die LEDs anzusteuern, jedoch wie bekomme Ich die Digitalanzeige angesteuert. Im Anhang ist die Datei wie die Anzeige angesteuert wird. Mit einer Vier Bit Zahl würde Ich wissen wie es geht, aber nicht mit einer Zahl die länger als 4 Bit ist.
Mo schrieb: > Mit einer Vier Bit Zahl würde Ich wissen wie es geht, aber nicht mit > einer Zahl die länger als 4 Bit ist. Nimm die Konvertierungen und die Casts aus der numeric_std: http://www.lothar-miller.de/s9y/categories/16-Numeric_Std Damit koonvertierst du den Integer mit to_unsigned() zum 4 bit breiten Unsigned und castest diesen Unsigned zum Std_logic_vector und gibst den deinem Modul. Passt alles locker in 1 Zeile: ergebnisvektor <= std_logic_vector(to_unsigned(integerwert,4));
:
Bearbeitet durch Moderator
Also Ich gebe nur einen Teil des Vektors an den Umsetzer für die 7 Segment anzeige ? Wie steuer Ich dann zwei unterschiedliche 7 Segment Anzeigen an, die eine soll nur 10er und die andere nur 1er anzeigen?
Das ist jetzt erstmal was Ich alles geschrieben habe, aber mir angezeigt, dass Ich einen "Syntax error near t" habe und Ich weiß nicht wo der Fehler liegt.
Mo schrieb: > weiß nicht wo der Fehler liegt. Mach einfach mal das "begin" der Architecture vor die Zuweisungen... Und lass das "else null;" weg und gib den LEDs Defaultwerte, oder gib in diesem letzten "else" den LEDs auch noch Werte. Sonst bekommst du Latches. Und die Sache mit dem Absolutwert und dem extrahierten Vorzeichen musst du auch noch einbauen. Und diese kuriose Verwendung des CLK mitten im Nirgendwo wird dir auch noch Probleme bereiten. Sieh dir einfach mal an, wie alle anderen einen synchronen oder einen kombinatorischen Prozess beschreiben.
:
Bearbeitet durch Moderator
Ich habe jetzt mal versucht den ersten Modus nur mal als Rechnung zu versuchen. Die Simple Addition von zwei Zahlen. Wenn Eingänge und Ausgänge die gleiche Range haben kamen nur teilweise richtige Zahlen raus. Jetzt bekommen Ich einen Fehler weil sie eine unterschiedliche Range haben. Wie mach Ich damit die richtigen Zahlen rauskommen und die Eingänge nur 4 Bit groß bleiben ?
Das Programm für die simple Rechnung funktioniert jetzt so wie es soll außer wenn Ich in Mode 2 bin bei y=2A-B. Wenn A = "1111" und B ="1110" ist sollte ja y="0100 0000" sein. Es ist bei mir aber y= "0001 0000". Wie kann Ich das umsetzen ?
Mo schrieb: > Das Programm VHDL ist, wie das 'D' darin sagt, keine Programmiersprache, sondern eine Beschreibungssprache. Wenn du damit "programmierst", wirst du laufend Schiffbruch erleiden. > für die simple Rechnung funktioniert jetzt so wie es soll Wundert mich, denn das ist ja wohl nur für positive Zahlen richtig: "0000" & B Du musst hier den Vektor vorzeichenkorrekt erweitern: B(3)&B(3)&B(3)&B(3) & B Oder das eben mit dem bereits erwähnten resize(B,8) automatisieren. Und: übergib doch zur Klarheit den Wert von A als unsigned Vektor. Dann sparst du dir da die Konvertierung und weißt du auch in einem halben Jahr noch, was da tatsächlich übergeben wird. Mo schrieb: > Wenn A = "1111" und B ="1110" ist sollte ja y="0100 0000" sein. > Es ist bei mir aber y= "0001 0000". Bei mir weder, noch. Denn 2*15 - (-2) ergibt 32 und damit 0010_0000...
:
Bearbeitet durch Moderator
Dadurch konnte Ich die Rechnung verbessern. Danke für die Tipps Jetzt will Ich die 8-Bit Zahl in Zehner und einer Teilen, jedoch ist das Ergebnis bei der Simulation verschoben. Woran liegt das und wie kann Ich es ändern damit es nicht verschoben ist ?
Mo schrieb: > Woran liegt das Deine Sensitivliste ist falsch. Da gehört nicht O rein, sondern y. Und das ganze nennt sich "Delta-Cycle" Problem, denn auch die Zuweisung "y<=O" findet nur dann statt, wenn "O" sich ändert. Gleichzeitig wird dann auch der Prozess berechnet, aber eben noch mit dem alten "y". BTW, als Stichwort für die Suche mit Google: was du machen willst, ist eine Binär-nach-BCD Umwandlung. Sieh dazu mal den Beitrag "VHDL Grundlagen Binaer to BCD" und die Links darin an...
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.