-
Thread
Subtrahieren bei STD_LOGIC_VECTOR
wrap-around", soll heißen bei einem vector (17 downto 0) ist 0 dasselbe wie 2^18 und eine negative Zahl wird entsprechend auf eine "große" Zahl abgebildet, z.B. -1 auf 2^18-1, -2 auf 2^18-2 usw. > Vermutlich wird das > Ergebnis im zweierkomplement negativ wenn der subtrahend größer ist. Nein, denn
: Soweit es das Bitmuster betrifft, ist die Operation die selbe, soweit es die Interpretation als Zahl betrifft, eine andere. > Oh, habe ich die ursprüngliche Frage sooo falsch interpretiert ;-) Ich bitte tausendmal um Verzeihung, das hatte ich überlesen *schäm*
-
Thread
1-Bit-Komparator als Komponente für n-Bit-Komparator
architecture verhalten; Ab hier folgt nur noch Scheitern. Gedanklich finde ich das Ergebnis (Zahl A = Zahl B) am einfachsten, da ich im Prinzip den gestamten Vektor Eq(i) überprüfen muss, ob jede Stelle eine '1' ist. Aber hier scheitert es schon, weil ich es nicht gebacken kriege, jedes einzelne
vom MSB: Spuckt der 1-Bit-Comp. ein "größer", dann brich die Schleife direkt ab und gebe direkt "Zahl ist größer" aus. Spuckt er "kleiner", dann ist die Zahl kleiner. Spuckt er "gleich", dann springe zurück und vergleiche MSB-1. In einer For-Generate Schleife konnte ich das nicht tun, weil ich die
-
Thread
Bytefehler beim Schreiben ins DDR2
, weil der Zähler dort schnell wieder auf 0 zurückgesetzt wird und gar nicht erst in den hohen Bereich (FF00) kommt. Dass der Fehler vom Zähler kommt, kann ich eigentlich ausschließen, weil alles registriert ist.
Variante weder den gesamten Speicher durchläuft, noch den Zähler höher zählen lässt, also treten da die Fehler nicht auf. Sehr komplex und nervig das ganze... Ein weiteres Problem ist, dass deren Clock auf 66.666 MHz läuft (laut UCF zumindest), die nehmen den dann
-
Thread
Ausversehen Bit-Counter optimiert - Kann nicht erklären warum es funktioniert
Input Vektor mit 16 Bits die Anzahl der gesetzten Bits mit Hilfe einer Baumstruktur zu berechnen/zählen und eine bestimmte Zeit für den kritischen Pfad zu unterbieten. Die Aufgabe war schnell erledigt und ich habe noch weiter versucht die Zeit vom Wissenschaftlichen Mitarbeiter zu unterbieten, nur
Vektor mit 16 Bits > die Anzahl der gesetzten Bits mit Hilfe einer Baumstruktur > zu berechnen/zählen und eine bestimmte Zeit für den > kritischen Pfad zu unterbieten. Siehe http://www.lothar-miller.de/s9y/archives/86-Einsen-im-Vektor-zaehlen.html
-
Thread
VHDL, DFC77, riesen Problem!
<= timer_hh+1; end if; if(falling_edge(dcf)) then -- hier beginnen wir mit dem zaehlen timer_hh <= 0; elsif(rising_edge(dcf)) then -- zaehler stoppen und Zeit auswerten if(timer_hh = 200) then -- jetzt haben wir eine 1 bekommen sek_nr <= sek_nr
<= timer_hh+1; end if; if(falling_edge(dcf)) then -- hier beginnen wir mit dem zaehlen timer_hh <= 0; elsif(rising_edge(dcf)) then -- zaehler stoppen und Zeit auswerten if(timer_hh = 200) then -- jetzt haben wir eine 1 bekommen sek_nr <= sek_nr
-
Thread
Lauflicht mit individuellen Muster
separator between them [/pre] Da steht auch da, was er haben möchte: ein Leerzeichen zwischen Zahl und Einheit. [vhdl] constant clk_period : time := 10 ms; [/vhdl] Duke
spendieren im Takt-Prozess. Im realen Leben musst du noch ein paar Flipflops spendieren und einen Zähler aufbauen. Edith: Lothar war schneller...
-
Thread
Problem in Verilog: Simulation läuft,Fit gibt falsches Desi
ja nicht zu sein. wie wäre es statt dessen mit einer zustandsmaschine: 0: ruhezustand 1: normal zählen 2: beim nächsten takt zählen dann --->3 3: steuereingang low -->4 sonst -->3 4: steuereingang low -->4 sonst -->2 dann wäre dieser steuereingang gewissermaßen ein 2. takt für den zähler. takt
synthesefähiger code" gefunden Ich habe mal versucht etwas umzusetzen: kurze beschreibung: 19-bit zähler mit einem clk eingang und einem para-clk. dieser befördert die maschine nacheinander in 3 zustände (siehe oben) mode1 startet das zählen mit clk, mode2 das zählen mit clk2 module modul(adr, clk
-
Thread
Verilog vs VHDL
die ganzen Typenstrukturen etc. die man in VHDL machen kann, die dann aber doch auf ganz normale Einsen und Nullen umgesetzt werden müssen. Ausserdem fand ich das ganze Aufsetzen bei VHDL (mit den Bibliotheken und was es alles gibt) als Anfänger ziemlich bescheiden. Ist zwar toll, wenn es an grosse
die ganzen Typenstrukturen etc. die man in VHDL machen >kann, die dann aber doch auf ganz normale Einsen und Nullen umgesetzt >werden müssen. KANN, man muss aber nicht. Schon gar nicht als Anfänger. >Ausserdem fand ich das ganze Aufsetzen bei VHDL (mit den Bibliotheken >und was es alles gibt)
-
Thread
Problem bei VHDL-Klausur
wird nie auf 0 zurückgesetzt. D.h. bei jeder Änderung von y wird dem alten Tmp-Wert die Anzahl Einsen nochmals dazuaddiert. (Innerhalb vom definierten range) Schreibe mal nach der Zeile "Z <= Tmp;" noch ein " Tmp := 0; ".
einen Anfänger total. Ich hab hauptsächlich bei for-Schleifen, wie wandle ich z. B. eine integer Zahl in nen Vektor um etc.
-
Thread
Funkuhr in VHDL
Hallo zusammen, ich suche nach einem ansatz, um das dcf77 signal in logische nullen und einsen zu wandeln. Kann mir von euch jemand einen prinzipiellen ansatz dafür geben ? ich würde das ganze gerne in vhdl modellieren und keinen prozessor verwenden. grüsse markus
musst du nur bei der 59 sekunde. Mit VHDl ohne Kontroller musst du Dir nat^rlich erst mal einen Zâhler programmieren..
-
Thread
Ein wirklich blöder Fehler, den ich nicht sehe
machen, muss man aber nicht. Das ist eben eine der vielen möglichen Lösungen wie man einen Vektor mit Einsen befüllt.
Zähler und 8 für die LEDs.
-
Thread
Intensity Grading
sicher schon so dunkel, dass man sie nicht mehr sähe. Wie du selber sagst erreicht man diese extremen Zahlen nur mit "Tricks": Lattice User schrieb im Beitrag #3432318: > Der Trick ist, dass man die "Nachleuchtdauer" auf unendlich setzt. Und das Shading damit ausschaltet. Auch Oszi-Bauer kochen nur
so dunkel, > dass man sie nicht mehr sähe. Wie du selber sagst erreicht man diese > extremen Zahlen nur mit "Tricks": > Lattice User schrieb im Beitrag #3432318: >> Der Trick ist, dass man die "Nachleuchtdauer" auf unendlich setzt. > Und das Shading damit ausschaltet. Der Trick dient nur dazu
-
Thread
n Bit Decoder rekursiv
im Eingang vorhanden" Siehe dazu die Betrachtungen: http://www.lothar-miller.de/s9y/archives/86-Einsen-im-Vektor-zaehlen.html
-
Thread
VHDL Suche ein Modell
Sende- und Empfangssignal einer Übertragung. Nun soll ermittelt werden wie oft aufeinanderfolgende Einsen auftreten. Im Englischen "Runs". Also quasi Einzel-Bitfehler, Doppel-Bitfehler usw. zählen. Das Xor-te Signal (16bit): 1100100111010101 ---> 4 Einzelbit-Fehler, 1 Doppelbit-Fehler, 1 Dreifachbit-Fehler
-
Thread
externes Sram und/oder FPGA auf Defekt prüfen
Simultaneous_Switching_Noise_Signal_Integrity_Application_Note_AC263_V3.pdf Da es unter den Prinzahlen eher wenig gerade Zahlen gibt, wird die Datenleitung D[0] quasi garnicht getestet ...
Den RAM mit Nullen od. Einsen zu prüfen hat nur in 50% schnellen Erfolg gebracht. Manche Fehler fielen erst nach 3 Tagen Test mit Zufallszahlen auf. Wahrscheinlich ist der RAM schneller ausgelötet als gründlich geprüft? RAM-Fehler
-
Thread
Über Conditions loopen (VHDL)
[vhdl] trg <= '1' when a == "111111111111111"; [/vhdl] oder wenn man zu faul ist selbst die Einsen zu zählen: [vhdl] trg <= '1' when to_integer(a) == 2^15-1; [/vhdl] (Syntax möglicherweise fehlerhaft)
-
Thread
sidechannel analysis fpga
einigermaßen einfach sein. Aber in einem einzigen Takt die Höhe des Strompulses auszuwerten um auf die Zahl der schaltenden Register zu schließen, ist sehr anspruchsvoll. Dein Hauptproblem besteht darin, dass hinter deinem Messwiderstand noch viele, verteilte Kondensatoren am VCC_int Netz hängen (in Summe
dieses weg optimieren zu verhindern. OK, wenn der Synthesizer nichts davon weiß, dass da lauter Einsen reingeschreiben werden, kann da auch nichts optimiert werden...
-
Thread
CAS/RAS DRAM Refresh mit XC9536XL Problem - Glitch ?
Retentionfehler auf dem externen Bus mit 50% Wahrscheinlichkeit bei Lowpegel (obwohl es intern natürlich die Einsen sind, die wegsterben). Wenn dein Testprogramm den fehlerhaften Wert mehrfach ausliest kannst du prüfen, ob es nur ein Signalintegritätsproblem beim Lesen war oder beim Schreiben: Signalintegritätsprobleme
viele 10ms. Sollte ein Refresh verloren geht, macht das nix, weil bei CAS-before-RAS ein interner Zähler benutzt wird. D.h. da wird nicht mal eine Zeile vergessen. Verletzungen der Precharge-Time merkt man üblicherweise an dem Ausfall einer ganzen RAS-Zeile, da wackelt nicht nur ein Bit. Es könnte
-
Thread
Der Process soll sich selber ausschalten
ein Musterbeispiel für die Verwendung von Variablen: http://www.lothar-miller.de/s9y/archives/86-Einsen-im-Vektor-zaehlen.html Aber eine /speichernde Variable/ ist für mich von vorn herein suspekt.