Digitaltechnik: 3-Bit Ripple-Carry-Addierer

[pippo]

Hab grad ein Problem mit einem Ripple-Carry-Addierer, aufgebaut aus 3 Volladdierern. c0 ist auf 0 gesetzt.

http://www.fh-augsburg.de/~finki/3rca.jpg

Mir ist nicht ganz klar, wie diese Zwischenzustände entstehen und wie man sie vermeiden kann. Hier kennt sich doch bestimmt jemand mit aus

Das ganz ungruppiert:

http://www.fh-augsburg.de/~finki/3rcau.jpg


Der Timing Analyzer:

http://www.fh-augsburg.de/~finki/3rcat.jpg


Und das Schaltbild:

http://www.fh-augsburg.de/~finki/3rcav.jpg


Vielleicht weiß ja auch noch jemand, warum der Timing-Analyzer für die Verzögerung von z.B. A0 nach C3 2 verschiedene Werte angibt?

[Die_Allianz]

hmm...
was das? irgend son altera-teil, oder?
hab das schon ewig nicht mehr gesehen, hab auch nicht im kopf wie dieser addierer aufgebaut ist.
Aber: gibts da nicht so eine blockschaltbildansicht? und einen debug-mode, in dem man sich die signalzustände ansehen kann?

[pippo]

Ist mit Altera gemacht, ja. Hab bissal was geändert, vielleicht hilfts dir weiter

[Trap]

Das ist ein Hazard, der gehört bei einem Ripple-Carry-Addierer dazu.

Achso: Für solche Bilder .png benutzen und am besten nicht skalieren oder wenigstens gute Skaliermethoden benutzen

[tatarus]

Was du da siehst ist genau das Problem des Ripple Carry Adders. Das Ergebnis liegt erst mit großer Verzögerung stabil am Ausgang an. Das ganze liegt daran, dass sich auch die Gatterlaufzeiten in den Volladdierern summieren. Der folgende Volladdierer muss nämlich immer auf das stabile Carry des vorhergehenden warten und macht vorher Blödsinn. Durch die festgelegten Anfangsbedingungen in deiner Simulation funktioniert es beim ersten Rechenschritt. Hättest du 8 Bit, dann würde das noch länger dauern.

Unterschiedliche Angaben bei C3 können an der Laufzeit vom Addierer zum Pad liegen.

Ein besserer Addierer wäre übrigens der Carry Lookahead Adder. Er rechnet mit viel geringerer Verzögerung, ist aber auch schwerer zu verstehen.

[pancho]

Was du da siehst ist genau das Problem des Ripple Carry Adders.
Eigentlich ist es das Problem jeglicher Logik, bei der gewisse Randbedingungen erfüllt sind. (Rekonvergenz, mehrere Pfade mit unterschiedlicher Laufzeit, ungerade Anzahl Invertierungen, "On-Set" Situation der anderen Signale)


Ein besserer Addierer wäre übrigens der Carry Lookahead Adder. Er rechnet mit viel geringerer Verzögerung, ist aber auch schwerer zu verstehen.
"Besser" hängt immer von den Anforderungen ab. Ein RCA braucht einfach sensationell wenige Gatter. Bei großen CLA-Arrays sieht das schon anders aus. Abgesehen davon wählt der Synthesizer (wenn man es nicht anders wünscht) immer die Lösung, die mit minimalem Aufwand an Logik alle Constraints erfüllt. Und in diesem speziellen Fall würde der Einsatz eines CLA den Praktikumsversuch bei Prof. G. unterwandern. ;)

Lösung: Nur synchrone Schaltungen entwerfen und mit den Hazards leben.

[tatarus]

Wenn ich VHDL schreibe, dann habe ich immer einen netten CLA in der Hinterhand, damit mir nicht diese blöden RCAs (der Mist wird eigentlich immer synthetisiert) das schöne Timing versauen. Sein Design muß man sowieso immer an den Anforderungen nach Geschwindigkeit und an den Kosten fürs FPGA ausrichten. In der Uni war das noch anders. Da bekommt man bei Praktikumsversuchen wenigstens klare, wenn auch nicht immer sinnvolle, Vorgaben.

[pancho]

Wenn ich VHDL schreibe, dann habe ich immer einen netten CLA in der Hinterhand, damit mir nicht diese blöden RCAs (der Mist wird eigentlich immer synthetisiert) das schöne Timing versauen. Sein Design muß man sowieso immer an den Anforderungen nach Geschwindigkeit und an den Kosten fürs FPGA ausrichten. In der Uni war das noch anders. Da bekommt man bei Praktikumsversuchen wenigstens klare, wenn auch nicht immer sinnvolle, Vorgaben.
Hast du dir echt selber einen CLA gestrickt? Bei korrekt gesetztem timing-constraint sollte der synthesizer doch automatisch den passenden Addierer aus der library nehmen. Alternativ kann man über Pragmas die Art des Addierers vorgeben. Schneller wird es von Hand auch nicht mehr (in einem Takt).