Kennt jemand aus der ASIC-Ecke ein Synthese- oder Konversions-tool, was Ripple-Counter automatisch in Gray- oder in gewissen Faellen LFSR-Counter inferiert oder sogar konvertiert (so, dass es es in die Simulation gesteckt werden kann)? Da es sich um Legacy-Verilog-Code handelt, fallen leider Hacks mit VHDL-Datentypen weg und eine Komplett-Portierung oder manuelle Bearbeitung faellt eher weg. Mit yosys koennte es allenfalls auch machbar sein, aber waere eine weitere Baustelle.
Wenn ich einen Graycounter brauche, dann instanziiere ich einen. Wenn der Counter eine FSM bedient, dann koennte man die Auswahl auch gleich der Toolchain ueberlassen. Die weiss es ja am besten.
Martin S. schrieb: > Ripple-Counter automatisch in Gray- k.A. -hab Deine kryptische Anfrage halbwegs dekodiert und die Suchmaschine spuckte das aus - aber wahrscheinlich haste das selbst schon gelesen https://electronics.stackexchange.com/questions/299460/can-you-make-a-ripple-counter-count-in-gray-code nix für ungut, "inferiert" war mir neu - hab ich gerade assimilliert ;)
Nochmal, ich suche ein Tool, was das fuer einen hinterlassenen Verilog-Code-Wust, der (sic!) keine Zaehler-Abstraktion eingebaut hat, hinbekommt. Den Code moechte ich moeglichst nicht modifizieren, sondern nur per Annotation vom Tool identifizierte counter auf jeweilige Architektur optimieren. Experimente mit xst und Synopsys habe ich durch. Ist auch bei den LFSR-Zaehlern dann nicht mehr ganz trivial (da wuerde ich gerne die Polynome selber angeben). Mit einem Budget-Hammer bzw. hohem Aufwand wird bereits gerechnet, gehe aber auch davon aus, dass das fuer ASIC-Leute ein taegliches Thema ist (Thema Stromverbrauch). Ich hoffe noch auf einen eleganten yosys-Hack. Nebenbei: Inferiert habe ich aus 'inferred' eingedeutscht, also das, was die Synthese aus einer funktionalen Beschreibung macht.
Martin S. schrieb: > Inferiert habe ich aus 'inferred' eingedeutscht Der Begriff ist schon richtig. Ist aber ein passives Wort, d.h. im aktuellen aktiven Sprachschatz der deutschen Sprache kaum verwendet. In AT hört man das aber oft. Der Begriff passt auch auf das Thema FSM, weil man - egal wie man den Ablauf angibt - eben den Ablauf, also die Funktion beschreibt und die Umsetzung unabhängig davon steuert. Für welchen compiler ist das denn? Das machen die doch heute genau so automatisch, wie es z.B. Xilinx auch tut. Die FSM wird decodiert und dann nach Vorgabe umgewandelt. "LFSR-Zaehlern" das wird er nicht mehr erkennen können, nehme ich an. Oder geht es um das Erzeugen?
Synthetisiert werden soll das schlussendlich mit Cadence, soweit ich weiss. Prototyp im FPGA waere aber da erste proof of concept. Fuer FSM werden die schon one-hot optimiert, aber es handelt sich hier um relativ beliebig verdrahtete einfache Ripple-Zaehler, die zumindest meine FPGA-Toolchain so laesst wie sie sind. Ich will also eine Annotations-Liste vorgeben a la `wandle(Unit_x, Unit_x.Signal_v, nach = Zaehlertyp(LFSR, parameter))` Der Wunsch also: `v <= v + 1`-Konstrukte entsprechend in eine explizite Zaehler-Instanz wandeln und in synthetisierbares Verilog ausgeben. Weitere Experimente mit yosys helfen aber, zumindest Zaehler zu identifizieren. Vermutlich kann man mit CXXRTL dann auch gleich noch die Simulation des Stromverbrauchs elegant mit erschlagen.
Martin S. schrieb: > Nebenbei: Inferiert habe ich aus 'inferred' eingedeutscht, also das, > was die Synthese aus einer funktionalen Beschreibung macht. [OT] Ich kenne nur "inferieren aus ..." im Sinne von "folgern" oder "ableiten". Der Gebauch als "in etwas inferieren" war mir bisher nicht bekannt und funktioniert im Deutschen vermutlich auch nicht (im Sinne von "inferred" wie z.B. in "inferred type"). Hier müsste man wohl "abgeleitet" o.ä. verwenden. Aber ich bin wahrlich kein Germanist und kann mich irren.
Hallo, eine Frage zum Begriff Ripple-Counter: Ist damit der Klassiker mit hintereinandergeschalteten T-FFs gemeint? Also ohne synchronen Clock für alle Bits, nur das LSB hat einen Takteingang, toggelt und wirft beim zweiten Mal das nächste Bit um usw.? Ripple-Counter wurden früher gerne benutzt, um lange Zeiten mit wenig Aufwand zu erzeugen, bei denen aber immer nur das MSB ausgewertet wurde - da es halt ´rippelt´. Das wird kaum jemand in Verilog oder VHDL geschrieben haben, weil man für jedes einzelne Bit einen eigenen Prozess benötigt. Gray-Code ist eine andere Geschichte. Der wird zur Synchronisierung von zu einander asynchronen Clock-Domains benutzt, z. B. bei FIFOs. Dazu stellt jede Seite einen aus einem Binärzähler abgeleiteten Gray-Code mit reiner Kombinatorik der anderen Seite zur Verfügung. Es ´wackelt´ dann maximal ein Bit bei der Abfrage. Die Gegenseite wandelt wieder zurück auf binäre Darstellung zur Weiterverarbeitung. Ein recht bekanntes Schema mit etlichen XORs und ohne Vermaschung benötigt man ein Vielfaches an Gattern. Ich kann mir nicht vorstellen, dass ein Tool einen Ripple-Counter erkennen oder gar in einen synchronen Zähler ummappen kann. Dazu müsste ein verwendbarer Clock aus dem restlichen System als geeignet erkannt werden, was ohne die Architektur zu kennen kaum möglich sein wird.
Kay-Uwe R. schrieb: > Ich kann mir nicht vorstellen, dass ein Tool einen Ripple-Counter > erkennen oder gar in einen synchronen Zähler ummappen kann. Dazu müsste > ein verwendbarer Clock aus dem restlichen System als geeignet erkannt > werden, was ohne die Architektur zu kennen kaum möglich sein wird. Machen die Tools doch, wenn 'one hot' im Zusammenhang mit FSM erforderlich ist. Wenn er so in der Source vorliegt, kann man ihn einfach erkennen:
1 | a <= a + 1 |
Hart codierte Ripple-Carry-Ketten zu detektieren wuerde aufwendiger, geht aber prinzipiell per yosys-RTLIL auch. Damit ist die Frage nach dem Klassiker auch beantwortet, oder?
Kay-Uwe R. schrieb: > Ripple-Counter wurden früher gerne > benutzt, um lange Zeiten mit wenig Aufwand zu erzeugen, bei denen aber > immer nur das MSB ausgewertet wurde - da es halt ´rippelt´. Nicht ausschliesslich. Sieht man hin und wieder in den billigen 18V-NiCd-Schrauber-Ladegeräten (Mannesmann etc). Die 40xx Nummer habe ich nicht mehr im Kopf. Taktgeber + Ripplecounter in einem Chip, Einstellung per RC. Da werden mehrere Bits abgegriffen: Ladezeit durchlaufen + und Notabschaltung 1-2 Bits höher. Einen so realisierten "Watchdog+DCDC" habe ich auch schon gesehen. Wenn, der Akku kaum noch Strom aufnimmt oder der Temperatur Sensor aus dem Akku meckert, dann hält der Watchdog den DCDC-Converter an (bzw gibt keinen Takt mehr dafür aus). Die einfachen 18V Lader mit 40xx eignen sich wunderbar als Treppenhausautomat an 12V. R durch Poti+R ersetzen, Trigger-Eingang finden, Taster+Lampe anschliessen.
Was der Akkuschrauber mit Zaehlerarchitektur zu tun hat ist mir schleierhaft, aber ok, ich habe herzlich gelacht. Eine Bemerkung laesst sich nicht verkneifen: Es spricht deutlich fuer die Lesekompetenz der betreffenden "Fachkraefte". Ich bin raus.
Martin S. schrieb: > Was der Akkuschrauber mit Zaehlerarchitektur zu tun hat ist mir > schleierhaft, Lesefähigkeiten einsetzen: Er antwortet auf den Beitrag zuvor und schweift ab, indem er ein Beispiel bringt, wie man Zeitglieder baut, als Gegenaussage zu dem Beitrag, wie man ripple counter einsetzt. Wir wissen jetzt, wie billige Zeitsteurungen arbeiten und dass man mehr Bits als nur das obere nutzen kann. Was ich jetzt noch gern wissen würde: Martin S. schrieb: > Hart codierte Ripple-Carry-Ketten zu detektieren wuerde aufwendiger, > geht aber prinzipiell per yosys-RTLIL auch. Beispiel für eine solche detektion?
A. F. schrieb: > Martin S. schrieb: >> Was der Akkuschrauber mit Zaehlerarchitektur zu tun hat ist mir >> schleierhaft, > > Lesefähigkeiten einsetzen: Er antwortet auf den Beitrag zuvor und > schweift ab, indem er ein Beispiel bringt, wie man Zeitglieder baut, als > Gegenaussage zu dem Beitrag, wie man ripple counter einsetzt. Dir ist schon klar, dass eine Detektion von Ripples an einem Motor mit einem digitalen Ripple-Counter so rein gar nichts zu tun hat? Also, der war gut. Auch, wenn man kein Englisch kann. > Martin S. schrieb: >> Hart codierte Ripple-Carry-Ketten zu detektieren wuerde aufwendiger, >> geht aber prinzipiell per yosys-RTLIL auch. > Beispiel für eine solche detektion? Man identifiziert die instanzierten Halb-Addierer, Compares und rekonstruiert daraus die Zaehlerarchitektur. Geht per pyosys-API. Nach dieser Offtopic-Bloedelei ist allerdings das Thema fuer mich definitiv abgeschlossen.
Martin S. schrieb: > Dir ist schon klar, dass eine Detektion von Ripples an einem Motor mit > einem digitalen Ripple-Counter so rein gar nichts zu tun hat? Mir das das alles klar :-) Nur dem OT-Werdenden nicht so ganz wie mir scheint :-)
Martin S. schrieb: > Wenn er so in der Source vorliegt, kann man ihn einfach erkennen: >
1 | a <= a + 1 |
Das wird ein Synchronzähler. Ein Ripple Counter ist ein Asynchronzähler. > Damit ist die Frage nach dem Klassiker auch beantwortet, oder? Irgendwie nicht. Bitte hier schauen: https://de.wikipedia.org/wiki/Asynchronz%C3%A4hler
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.