Forum: FPGA, VHDL & Co. Tool zur Zaehleroptimierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Martin S. (strubi)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Stephan (Gast)


Lesenswert?

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 ;)

von Martin S. (strubi)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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?

von Martin S. (strubi)


Lesenswert?

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.

von Michael K. (brutzel)


Lesenswert?

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.

von Kay-Uwe R. (dfias)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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?

von Wf88 (wf88)


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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.

von A. F. (chefdesigner)


Lesenswert?

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?

von Martin S. (strubi)


Lesenswert?

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.

von A. F. (chefdesigner)


Lesenswert?

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 :-)

von Kay-Uwe R. (dfias)


Lesenswert?

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

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
Noch kein Account? Hier anmelden.