Welche freien HDL Simulatoren erlauben die Simulation von Latches? GHDL und Yosys gehören leider nicht dazu. Wie sieht es mit Verilator oder Icarus Verilog aus? Konnte leider in einer ersten Websuche dazu keine Informationen finden.
Tim . schrieb: > Welche freien HDL Simulatoren erlauben die Simulation von Latches? Was willste den am Latcgh simulieren, was groß über Cycle-based simulation hinaus geht? modelsim sollte leve triggerung gut können und die kostenlosen versionenreichen für kleine designs. Wenn es um Simulationsprinzipien geht, dann mal in die Literatur reinschauen, allerdings fällt mir da spontan auch kein perfekte werk ein. Vielleicht ISBN:3-446-21288-4
Es geht eher darum, dass ich gerne Designs mit Latches simulieren will. Ich bastele an einem Synthesefluss für diskrete Logik (Beitrag "PCBFlow - Automatisches Generieren von PCB Layouts aus VHDL code (Work in Progress)"). Da wäre es wesentlich effizienter mit Latchbasierter Logik zu arbeiten. Leider kann ich diese bisher weder Synthetisieren noch als Digitaldesign simulieren, obwohl VHDL und Verilog so etwas problemlos beschreiben könnten.
Tim . schrieb: > Leider kann ich diese bisher weder Synthetisieren noch als Digitaldesign > simulieren, obwohl VHDL und Verilog so etwas problemlos beschreiben > könnten. I h kenne einige, die beschreiben, simulieren und synthetisieren Latches ohne es zu wollen. Tim . schrieb: > Welche freien HDL Simulatoren erlauben die Simulation von Latches? GHDL > und Yosys gehören leider nicht dazu. Sicher können die das. Welche Fehlermeldung(en) bekommst du mit welcher Toolchain? Zeig doch mal (d)eine HDL-Beschreibung, mit der das nicht geht.
Code unten. Was GHDL+Yosys (mit GHDL Plugin) daraus machen im Anhang. Aus dem Latch wird einfache eine Konstante. Anscheind unterstützt GHDL keine Latches: https://github.com/ghdl/ghdl/issues/938
1 | library ieee; |
2 | use ieee.std_logic_1164.all; |
3 | use ieee.numeric_std.all; |
4 | |
5 | entity gatesx is |
6 | port (inv_a: in std_logic; |
7 | inv_y: out std_logic; |
8 | |
9 | xor_a: in std_logic; |
10 | xor_b: in std_logic; |
11 | xor_y: out std_logic; |
12 | |
13 | and_a: in std_logic; |
14 | and_b: in std_logic; |
15 | and_y: out std_logic; |
16 | |
17 | d,clk: in std_logic; |
18 | q: out std_logic; |
19 | |
20 | ld,en: in std_logic; |
21 | lq: out std_logic |
22 | ); |
23 | end; |
24 | |
25 | architecture main of gatesx is |
26 | signal reg: std_logic; |
27 | signal latch: std_logic; |
28 | begin |
29 | process (clk) |
30 | begin |
31 | if rising_edge(clk) then |
32 | reg <= d; |
33 | end if; |
34 | end process; |
35 | |
36 | q <= reg; |
37 | |
38 | process(en,ld) |
39 | begin |
40 | if (en ='1') then |
41 | latch <= ld; |
42 | end if; |
43 | end process; |
44 | |
45 | lq <= latch; |
46 | |
47 | and_y <= and_a AND and_b; |
48 | xor_y <= xor_a XOR xor_b; |
49 | inv_y <= NOT inv_a; |
50 | end; |
Angehängte Dateien:
-
latch.PNG
43 KB
Hm.. es scheint wirklich an GHDL zu liegen. Mit Verilog+Yosys funktioniert es. Ich muss mich wohl an Verilog gewöhnen...
1 | module latch(D, EN, Q); |
2 | input D, EN; |
3 | output Q; |
4 | |
5 | reg latch; |
6 | |
7 | always @(EN, D) |
8 | begin |
9 | if ( EN == 1'b0 ) |
10 | latch <= D; |
11 | end |
12 | |
13 | assign Q = latch; |
14 | |
15 | endmodule |
Tim . schrieb: > Hm.. es scheint wirklich an GHDL zu liegen. Hast du das auch mal als Timing-Diagramm simuliert? Ein VHDL-Simulator, der kein Latch simulieren kann, wäre schlicht Müll. Denn es gibt ja durchaus Plattformen wie z.B. die 7er Serie von Xilinx (oder die alten Spartan 3 und deren Vorgänger), wo ich sogar jederzeit ein echtes transparentes Latch als Hardwarekomponente synthetisieren kann. Siehe dazu z.B. den Xilinx UG474.
Natuerlich kann GHDL Latches simulieren. Nur das Synthese-Plugin unterstuetzt es nicht. Das auch mit Grund, da Latches mit modernen FPGA-Primitiven bei komplexen Designs nur Probleme mit der Timing-Closure machen, es gibt auch Szenarien, mit denen man manche Tools in eine Endlos-Schleife beim Plazieren schicken kann (und dann sucht man ewig). Deswegen: Nicht machen, ausser, es geht um Austesten von destruktiven Szenarien, ansonsten gehoert es eigentlich 'verboten'. Achja...und es gab da schon einige Projekte, die sich mit asynchroner TTL-Logik an einem CPU-Design versucht haben. Aus den jekten wurden vor allem bleme :-)
Tim . schrieb: > Welche freien HDL Simulatoren erlauben die Simulation von Latches? GHDL > und Yosys gehören leider nicht dazu. Zunächst einmal unterscheiden wir synchrone und asynchrone Latches. Nur die letzteren sind bei FPGAs ein Problem und auch nur dann, wenn man ein strikt synchrones = isochron getaktetes design haben will. Simulieren kann man beides mit allen Simulatoren, die in der Lage sind, timings zu verarbeiten. Voraussetzung ist aber, dass du auch eine konkrete Implementierung mit Timings hast und eingibst, d.h. der Simulator braucht eine Netzliste mit Signal Delay File. Man muss das auch simulieren können: Solche asynchronen (auf den Systemtakt bezogen asynchronen) Architekturen kommen öfters vor, z.B. in selbstlaufenden Zählern. Die kann man sehr einfach funktionell simulieren, wenn man für jedes Signal z.b. eine 1ps Verzögerung ansetzt. Allerdings liefert das noch nicht das reale Timing und die sich ergebende Schaltfrequenz. Und wenn man keine sicher codierten FSMs / Gray counter nutzt, dann kriegt man sogar mitunter ein funktionell falsches Ergebnis, d.h. der Zähler zählt in der Simulation falsch. Weiters haben wir solche Strukturen auch bei der Simulation externer Logik von Chips. Ich habe erst kürzlich eine Schieberegisterkaskade so modelliert, damit ich die Umschaltung und die Totzeiten, bzw Delay für Sel und En optimal steuern konnte und es zu keinen Setup/Hold-Time Geschichten kommt und trotzdem das Maximale rauszuholen. Dabei werden die internen Takte, die an einem hochfrequenten Zähler hängen (5ns Raster) so getrimmt, dass sie zu den asynchronen Laufzeiten im Chip passen. Vollsynchron, als in "seinem2 Taktmass der rund 25MHz packt er Schaltvorgänge in 5 Takten. Takte ich ihn "asynchron" braucht er 3.
Tim . schrieb: > Es geht eher darum, dass ich gerne Designs mit Latches simulieren will. > Ich bastele an einem Synthesefluss für diskrete Logik > (Beitrag "PCBFlow - Automatisches Generieren von PCB Layouts aus VHDL code (Work in Progress)"). Da wäre es wesentlich > effizienter mit Latchbasierter Logik zu arbeiten. Ob 'latchbasierte Logik' der richtige Suchbegriff ist? Oder eher 'mixed signal Simulation' ? Oder wenn Du laufzeiten mit synthetisieren willst, dann klingt das nach asynchroner Logic. Das ist seit Jahrzehnten ein absolutes Nischenthema, da verwendet man statt Latches Kombinatorik, die selbst anzeigt, da sie fertig is, siehe "Muller C Gate" https://en.wikipedia.org/wiki/C-element https://tams.informatik.uni-hamburg.de/applets/hades/webdemos/16-flipflops/70-cgate/muller-cgate3.html https://en.wikipedia.org/wiki/AMULET_microprocessor Da gab es in den Neunzigern einer Arbeit aus dem UK, bei dem einer mit evolutionären Algos auf einen alteren Xilinx FPG eine Stimmerkennung-Schaltung basteln liess. Also nicht direkte Synthese oder Simulation, sondern Bitstream-'Mutation' und Evolution und Test in Echt ob das Ergebniss näher am gewünschten lag.
Tim . schrieb: > Es geht eher darum, dass ich gerne Designs mit Latches simulieren will. > Ich bastele an einem Synthesefluss für diskrete Logik Das ist der Knackpunkt: Simulation /= Synthese. Setzen wir den möglichen Sprachumfang von VHDL zu 100% (also alles, was die Sprache tatsächlich theoretisch bietet), dann kann der Simulator davon geschätzt 50% simulieren (allein wegen Speicherbeschränkungen usw...). Und von diesen 50% lassen sich dann je nach Architektur bestenfalls 5% synthetisieren (also grade mal 2% vom gesamten VHDL Sprachumfang). Schon die allereinfachste Beschreibung für ein Blinklicht "led <= not led after 500 ms;" simuliert tadellos, lässt sich aber nicht synthetisieren. Dein Problem dabei ist, dass du einen Simulator über ein "universelles" Plugin als Synthesizer für (d)eine spezielle Plattform verwenden willst. letztlich wirst du dieses Synthesizer-Plugin eben für deine Hardware anpassen müssen. Denn der Synthesizer sucht nach "Mustern" im Code und bildet die dann in die ihm bekannte Hardware ab. Weil aktuelle FPGAs vorrangig mit synchronen Designs befüllt werden, ist in das Synthese-Plugin das Muster "Latch" nicht einprogrammiert und kann somit auch nicht in Hardware umgesetzt werden.
Danke für den weiteren interessanten input :) Asynchrone Logik wollte ich eigentlich nicht verwenden. Im Prinzip geht es mir nur um folgendes: - Um in meinen Designs Transistoren einzusparen, würde ich gerne statt D-Flipflips Latches verwenden. Das ware vor 40 Jahren zu NMOS-Zeiten auch bei ICs so üblich, wie z.B. im 6502. - Ich verwende aktuell VHDL (mit GHDL) und möchte als Teil meines Designflows gerne mein Digital Design Simulieren (Verhaltenssimulation) und anschließend Synthetisieren. Mein aktuelles Verständis ist: - GHDL kann im Zusammenhang mit Yosys keine Latches synthetisieren. - GHDL kann evtl. Designs mit Latches simulieren. Das habe ich noch nicht getestet, ist aber ohne Synthese auch nur begrenzt von Nutzen. - Yosys alleine kann Latches synthetisieren, wenn Verilog als HDL genutzt wird. - Das Techmapping klappt inzwischen auch. Es gibt einige CPLDs mit integrierten Latches, die von Yosys bereits unterstützt werden* Aus pragmatischer Sicht bleibt mir wohl nur die Option, auf Verilog umzusteigen, die Synthese direkt mit Yosys vorzunehmen und zur Simulation entweder Yosys zu nutzen (ist neuerdings eingebaut) oder mich in Icarus/Verilator einzuarbeiten. Bezüglich mixed signal: In meinem Designflow nutze ich NGSpice, um die synthetisierte Schaltung nach layout zu simulieren. Das ist natürlich deutlich eingeschränkter als eine digitale Simulation, da ich z.B. keine Speichermodelle nutzen kann. *z.B. Hier: https://github.com/YosysHQ/yosys/blob/master/techlibs/greenpak4/cells_latch.v
Ich bin noch etwas skeptisch, ob du wirklich fuer ein stabiles (!) Design Transistoren einsparen kannst (bei NPN-Transistoren schenkt sich schon mal nix). Wo wir beim techmapping sind: Latches kannst du in yosys natuerlich als Blackbox-Primitiven instanzieren (auch aus VHDL heraus). Die Frage ist dann, wie das auf Gate resp. Transistor-Level fuer deine Technologie aussieht und ob du da wirklich was einsparst (Bei klassischen LUT/Registern sparst du nix). Poste doch mal das .dot-Resultat des Schrittes von DLATCH nach NMOS-Tech. Das grundsaetzliche Problem aber bleibt: Gegenueber synchroner FF-Logik glitcht dir das Zeug nur rum, sofern du nicht ganz strikt one-hot resp. gray-codierst, also: auch dann hast du noch das Problem mit der Latch-Totzeit (Level-Sensitivitaet), was dir mit hoher Sicherheit nicht erleichtert, 6502-Logik mit Latches zu emulieren. Dabei kann dir weder yosys noch next-pnr helfen, da sie v.a. auf FF/LUT-Architekturen ausgelegt sind. Unterm Strich: Entweder wird der Latch-Zoo so langsam gepulst, dass Timing kaum Rolle spielt, oder: Du muesstest das selber auf korrekte Funktion inkl. Delays (nach dem Mappen) semi-manuell durchsimulieren (allenfalls hilft PSL). Und: ja, du muesstest zur Simulation mindestens GHDL oder Icarus nehmen, weil du die eventgetriebene Simulation zwingend fuer ein korrektes Ergebnis brauchst, CXXRTL und Verilator fallen somit raus. Nur bleibt immer noch die Frage offen: Warum sollte man das tun, wenn's synchron viel weniger blutige Nase macht?
Fpgakuechle K. schrieb: > ondern Bitstream-'Mutation' und Evolution ist da bei etwas Sinnvolles heraus gekommen? Tim . schrieb: > - Um in meinen Designs Transistoren einzusparen, würde ich gerne statt > D-Flipflips Latches verwenden. Das ware vor 40 Jahren zu NMOS-Zeiten > auch bei ICs so üblich, wie z.B. im 6502. Damals war die Taktrate auch viel niedriger und die Schaltzeit wurde überwiegend von der Schaltgeschwindigkeit der Transistoren bestimmt. Die Laufzeit machte weniger Anteil. Das ist heute umgekehrt. Durch die winzigen Chipstrukturen verkleinert sich die Kapazität, um Faktor n*n während der Abstand zum Nächsten nur um n sinkt. Ergebnis: Die Laufzeiten sind relevant. (aus Deiner Sicht: die Transistoren sind schneller "getaktet"). Die natürliche, schaltzeitbedingte Taktung fällt also weg und es entsteht eine wirklich asynchrone Logik. Wie willst du das timen? Das geht nur in ASICs, wenn der Placer passend setzt. Beim FPGA gibt es nichts zu setzen, sondern nur auszuwählen. Da sind die Abstände nochmal größer. Und: Die Struktur ist viel langsamer, als im ASIC wegen der vielen komplexen interconnections.
Angehängte Dateien:
-
latch.PNG
30 KB
Martin S. schrieb: > Ich bin noch etwas skeptisch, ob du wirklich fuer ein stabiles (!) > Design Transistoren einsparen kannst (bei NPN-Transistoren schenkt sich > schon mal nix). > > Wo wir beim techmapping sind: Latches kannst du in yosys natuerlich als > Blackbox-Primitiven instanzieren (auch aus VHDL heraus). Die Frage ist Ah, natürlich! Daran habe ich noch gar nicht gedacht :) Das wäre natürlich ein Workaround, bei dem ich nicht auf GHDL verzichten müsste. > dann, wie das auf Gate resp. Transistor-Level fuer deine Technologie > aussieht und ob du da wirklich was einsparst (Bei klassischen > LUT/Registern sparst du nix). Poste doch mal das .dot-Resultat des > Schrittes von DLATCH nach NMOS-Tech. Aktuell nutze ich zwei Latches und einen Inverter, um ein DFF zu implementieren. Der Transistoraufwand für ein Latch reduziert sich damit um den Faktor 2. Ich nutze aktuell polarity-hold Latches, wie im Anhang. Die DFF exportiere ich als Blackbox und zerlege sie erst in meinem Placement-Tool in Transistoren und Einzelgates. > Das grundsaetzliche Problem aber bleibt: Gegenueber synchroner FF-Logik > glitcht dir das Zeug nur rum, sofern du nicht ganz strikt one-hot resp. > gray-codierst, also: auch dann hast du noch das Problem mit der Der klassiche weg wäre eine 2-phasen clock. Ich plane es aktuell etwas einfacher: Die Statemachine nutzt DFF und der Datenpfad Latches. Dadurch kann ich Glitches in den Enable-Signalen vermeiden. Die Statemachine muss natürlich dafür sorgen, das sich die Enable-signale von gekoppelten Latches nicht überlappen. Dazu kann man ggf. auch noch mit der Clock gaten. Ist für die Geschwindigkeit nicht so toll, aber immerhin sollte es einigermaßen robust sein. Auf Geschwindigkeit versuche ich aktuell sowieso nicht zu optimieren, eher auf Fläche.
Techniker schrieb: > Tim . schrieb: >> - Um in meinen Designs Transistoren einzusparen, würde ich gerne statt >> D-Flipflips Latches verwenden. Das ware vor 40 Jahren zu NMOS-Zeiten >> auch bei ICs so üblich, wie z.B. im 6502. > Damals war die Taktrate auch viel niedriger und die Schaltzeit wurde > überwiegend von der Schaltgeschwindigkeit der Transistoren bestimmt. Die > Laufzeit machte weniger Anteil. Hier geht es allerdings um Logik aus diskreten Transistoren. Siehe oben. > Das ist heute umgekehrt. Durch die winzigen Chipstrukturen verkleinert > sich die Kapazität, um Faktor n*n während der Abstand zum Nächsten nur > um n sinkt. Ergebnis: Die Laufzeiten sind relevant. (aus Deiner Sicht: > die Transistoren sind schneller "getaktet"). Ja, wenn ich nicht mit diskreter Logik, sondern modernen FPGAs oder sogar ASICs arbeiten würde, würde ich lieber auf die doch bewärten Methoden zurückgreifen :)
Tim . schrieb: > Aktuell nutze ich zwei Latches und einen Inverter, um ein DFF zu > implementieren. Der Transistoraufwand für ein Latch reduziert sich damit > um den Faktor 2. > Hmm, waeren das nach deinem NOR-Gate-Schema nicht auch schon mindestens 7 Transistoren? > Ich nutze aktuell polarity-hold Latches, wie im Anhang. Die DFF > exportiere ich als Blackbox und zerlege sie erst in meinem > Placement-Tool in Transistoren und Einzelgates. Verstehe ich das richtig, du haust ein klassisches synchrones Design durch yosys, und mapst danach die extrahierten DFF selber nach deinen 'Primitiven'? Wieso nicht per abc direkt auf deine Transistoren-Library? Aber gut, das einfachste waere demnach nach 'Trick Blackbox', dein DFF basierend auf deiner Architektur einmalig in Verilog zu beschreiben. Dann kannst du dein gesamtes auf Gate-Level reduziertes VHDL-Design (ohne explizite Beschreibung von Latches) nach Verilog exportieren und dein __DFF__-Blackbox-Modell inkl. Timing durch icarus jagen (solange Speicher reicht..). Hat sich hier als sehr effizient rausgestellt, allerdings mit myHDL als Top-Level-Dialekt um sich nicht mit V*-Arithmetik in den Fuss zu schiessen. Dazu gibt es auch fertige Container wo du im Jupyter NB mal eben gegen den Yosys-Output co-simulieren kannst.
Techniker schrieb: > Fpgakuechle K. schrieb: >> ondern Bitstream-'Mutation' und Evolution > ist da bei etwas Sinnvolles heraus gekommen? Laut Adrian Thompson aus Sussex der in den Neunzigern publizierte, hatte er wohl Schaltungen auf sehr kleinen FPGA's (Xilinx XC6216 ) die die gesprochenen Worte 'Go' und Stop' unterscheiden könnten, was für die Technik vor 25 Jahren revolutionär war.Dazu sollte die Schaltung dank 'Evolution' besonders sparsam und robust sein. https://www.elektormagazine.de/news/kurze-schaltung-evolution-der-hardware http://web.cecs.pdx.edu/~mperkows/CLASS_479/LECTURES479/PE014.XC6200Ahmad.pdf Ob die Ergebnisse auf andere Chips reproduzierbar sind, scheint aber fraglich. Was aber Anwender von Einzelexemplaren wie die NASA nicht abschreckt. Die NASA sponsort auch einiges im Bereich Evolable Hardware: https://en.wikipedia.org/wiki/Evolvable_hardware https://web.archive.org/web/20070207094344/http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/ahs/2006/2614/00/2614toc.xml
Martin S. schrieb: > Tim . schrieb: >> Aktuell nutze ich zwei Latches und einen Inverter, um ein DFF zu >> implementieren. Der Transistoraufwand für ein Latch reduziert sich damit >> um den Faktor 2. > > Hmm, waeren das nach deinem NOR-Gate-Schema nicht auch schon mindestens > 7 Transistoren? Genau, eine große Einsparung. >> Ich nutze aktuell polarity-hold Latches, wie im Anhang. Die DFF >> exportiere ich als Blackbox und zerlege sie erst in meinem >> Placement-Tool in Transistoren und Einzelgates. > > Verstehe ich das richtig, du haust ein klassisches synchrones Design > durch yosys, und mapst danach die extrahierten DFF selber nach deinen > 'Primitiven'? Wieso nicht per abc direkt auf deine Transistoren-Library? Verstehe ich nicht so ganz, vielleicht habe ich da etwas übersehen? ABC mappt nur kombinatorische Logik auf Standardzelle die in der Library beschrieben sind. Wie ich damit Transistoren beschreiben sollte ist mir nicht ganz klar. z.B. dass aus zwei Invertern auf Schaltungsebene ein NOR2 wird, kann man ABC m.E. nicht beibringen. Die DFF muss man auch mit einem getrennten Schritt extrahieren (dfflibmap). https://github.com/cpldcpu/PCBFlow/blob/main/20_SYNTH/flow_discrete_nmos.ys https://github.com/cpldcpu/PCBFlow/blob/main/20_SYNTH/discrete_RT_logic_liberty.lib Wenn Du hier Verbesserungsvorschlage hast, immer her damit :). Ich bin teilweise ziemlich daran verzweifelt, dass ich ABC nicht dazu bringen konnte, Logik so umzuwandeln, dass sie zu komplexeren Zellen passt. z.B. dass man aus einem MUX2 ein AND-Gate machen kann, könnte ABC eigentlich selbst erkennen. > Aber gut, das einfachste waere demnach nach 'Trick Blackbox', dein DFF > basierend auf deiner Architektur einmalig in Verilog zu beschreiben. > Dann kannst du dein gesamtes auf Gate-Level reduziertes VHDL-Design > (ohne explizite Beschreibung von Latches) nach Verilog exportieren und > dein __DFF__-Blackbox-Modell inkl. Timing durch icarus jagen (solange > Speicher reicht..). Wenn ich die Latches als Blockbox beschreibe kann ich sie ja für die Simulation auch als VHDL Modul einbinden? > Hat sich hier als sehr effizient rausgestellt, allerdings mit myHDL als > Top-Level-Dialekt um sich nicht mit V*-Arithmetik in den Fuss zu > schiessen. Dazu gibt es auch fertige Container wo du im Jupyter NB mal > eben gegen den Yosys-Output co-simulieren kannst.
Fpgakuechle K. schrieb: > Laut Adrian Thompson aus Sussex der in den Neunzigern publizierte, > hatte er wohl Schaltungen auf sehr kleinen FPGA's (Xilinx XC6216 ) die > die gesprochenen Worte 'Go' und Stop' unterscheiden könnten, was für die > Technik vor 25 Jahren revolutionär war.Dazu sollte die Schaltung dank > 'Evolution' besonders sparsam und robust sein. > > https://www.elektormagazine.de/news/kurze-schaltung-evolution-der-hardware > http://web.cecs.pdx.edu/~mperkows/CLASS_479/LECTURES479/PE014.XC6200Ahmad.pdf Ein interessantes Experiment. Eigentlich merkwürdig, dass das bisher niemand wieder aufgegriffen hat. Ist natürlich für reproduzierbare Design nur bedingt einsetzbar :)
Zum Thema Latches mit GHDL/yosys: Ich kann bestätigen, dass ein VHDL-Setup mit Latches und kombinatorischen Schleifen (beides plain behavioral VHDL, keine Primitives or Attributes) funktioniert. Zumindest auf einem Lattice iCE40 UltraPlus. Diese Module wird (unter anderem) synthetisiert und enthält die Latches und die kombinatorischen Schleifen: https://github.com/stnolting/neoTRNG Und hier ist der Synthese-Report (unter "Generate UPduino UP5KDemo bitstream reports): https://github.com/stnolting/neorv32/runs/4363420376?check_suite_focus=true
Tim . schrieb: >> https://www.elektormagazine.de/news/kurze-schaltung-evolution-der-hardware > Ein interessantes Experiment. Eigentlich merkwürdig, dass das bisher > niemand wieder aufgegriffen hat. das 'niemand' asynchrone und andere 'unkonventielle' Konzepte einsetzt würde ich nicht unwidersprochen gelten lassen. Die verschlossenen Cryptologen haben auch ein Interesse an Schaltungen mit geringer Abstrahlung und einem Rauschen-ähnlichen EMV-AbstrahlSpektrum, das daher nicht zu Seitenkanalattacken taugt. https://de.wikipedia.org/wiki/Seitenkanalattacke Aber wir schweifen ab.
> Verstehe ich nicht so ganz, vielleicht habe ich da etwas übersehen? ABC > mappt nur kombinatorische Logik auf Standardzelle die in der Library > beschrieben sind. Wie ich damit Transistoren beschreiben sollte ist mir > nicht ganz klar. z.B. dass aus zwei Invertern auf Schaltungsebene ein > NOR2 wird, kann man ABC m.E. nicht beibringen. Die DFF muss man auch mit > einem getrennten Schritt extrahieren (dfflibmap). > War eine dumme Frage meinerseits, vermutlich gibt es da eine Menge, was betreffend Standard-Technologien Sinn macht aber fuer deine 'lib' nicht passt. Waere nur mal interessant zu sehen, wie gut die FOSS-Tools beim Optimieren auf Transistor-Level sind. > Wenn Du hier Verbesserungsvorschlage hast, immer her damit :). Ich bin > teilweise ziemlich daran verzweifelt, dass ich ABC nicht dazu bringen > konnte, Logik so umzuwandeln, dass sie zu komplexeren Zellen passt. > abc habe ich nie angefasst, nur auf hoeherem Primitiven-Level mit yosys herumtransformiert. Vermutlich waere es auch viel einfacher, einfach ein spezifisches yosys-Plugin fuer deine 'Tech' zu machen, aber ev. sparst du da gegenueber deinem Plazieren auch nichts ein. > Wenn ich die Latches als Blockbox beschreibe kann ich sie ja für die > Simulation auch als VHDL Modul einbinden? > Du meinst zur Verifikation per GHDL? Mir ist dein Flow noch nicht ganz klar. Wenn Du eine (existierendes?) synchrones Design auf der Basis deiner DFF->Latch-Emulation verifizieren willst - mit entsprechendem Timing - musst du es ja erst mappen. Und da momentan nur Verilog-Ausgabe geht (VHDL back-end scheint zu pausieren), geht's per FOSS nur ueber icarus, der VHDL nicht versteht.
someone_like_you schrieb: > Zum Thema Latches mit GHDL/yosys: > > Ich kann bestätigen, dass ein VHDL-Setup mit Latches und > kombinatorischen Schleifen (beides plain behavioral VHDL, keine > Primitives or Attributes) funktioniert. Zumindest auf einem Lattice > iCE40 UltraPlus. > > Diese Module wird (unter anderem) synthetisiert und enthält die Latches > und die kombinatorischen Schleifen: https://github.com/stnolting/neoTRNG https://github.com/stnolting/neoTRNG/blob/838298b40171a6832673fdf1b60454eaec48ff0e/rtl/neoTRNG.vhd#L313 Das Latch ist Teil der Ringoscillators oder? > Und hier ist der Synthese-Report (unter "Generate UPduino UP5KDemo > bitstream reports): > https://github.com/stnolting/neorv3/runs/4363420376?check_suite_focus=true hm.. das Log ist relative lang und natürlich nicht auf den ersten Blick zu überschauen. Was mir auffällt ist das nirgendo "Latch" als Blackbox oder primitive auftaucht. Anscheinend werden die Latches GHDL und Yosys als kombinatorische Schleife untergejubelt?
Martin S. schrieb: > War eine dumme Frage meinerseits, vermutlich gibt es da eine Menge, was > betreffend Standard-Technologien Sinn macht aber fuer deine 'lib' nicht > passt. > Waere nur mal interessant zu sehen, wie gut die FOSS-Tools beim > Optimieren auf Transistor-Level sind. Naja, auch ein kommerzieller VLSI-Flow greift normalerweise auf Zellbibliotheken zurück und optimiert nicht auf Transistorlevel. Ich bin mir nicht sicher, ob es da andere Ansätze gibt. Martin S. schrieb: >> Wenn ich die Latches als Blockbox beschreibe kann ich sie ja für die >> Simulation auch als VHDL Modul einbinden? > > Du meinst zur Verifikation per GHDL? Ja, genau. > Mir ist dein Flow noch nicht ganz klar. Wenn Du eine (existierendes?) > synchrones Design auf der Basis deiner DFF->Latch-Emulation verifizieren > willst - mit entsprechendem Timing - musst du es ja erst mappen. > Und da momentan nur Verilog-Ausgabe geht (VHDL back-end scheint zu > pausieren), geht's per FOSS nur ueber icarus, der VHDL nicht versteht. Eine Übersicht des Flows gibt es hier: https://raw.githubusercontent.com/cpldcpu/PCBFlow/main/Images/flow_numbered.png Repo: https://github.com/cpldcpu/PCBFlow Aktuell kann ich an drei Stellen simulieren: 1) Simuluation des Digitaldesigns mit GHDL - ohne Timinginformationen 2) Analogsimulation mit NGSpice nach Synthese auf Transistorlevel 3) Analogsimulation mit NGSpicenach Layout mit extrahierten Mikrozellen (Transistoren) 2) und 3) sind äquivalent, wenn beim P&R kein Fehler aufgetreten sind. Aktuell bilde ich im Schritt 30 (Generation von Mikrozellen) alle DFF auf zwei Latches plus einen inverter (Master-Slave FF) ab. Das funktioniert auch sehr gut. Was nicht funktioniert, ist die Synthese von dedizierten Latches die nicht aus DFF generiert werden. Und da scheint GHDL das Problem darzustellen.
> Das Latch ist Teil der Ringoscillators oder? Das ist richtig. > hm.. das Log ist relative lang und natürlich nicht auf den ersten Blick > zu überschauen. Was mir auffällt ist das nirgendo "Latch" als Blackbox > oder primitive auftaucht. Das ist tatsächlich etws nervig. Ich suche gerade auch noch nach einer Möglichkeit zumindest die Ressourcen pro Entity anzeigen zu lassen. > Anscheinend werden die Latches GHDL und Yosys > als kombinatorische Schleife untergejubelt? Eigentlich ist es genau andersherum: Eine Kette aus Latches wird gebaut, um der Synthese die komb. Schleife "unterzujubeln".
someone_like_you schrieb: > Das ist tatsächlich etws nervig. Ich suche gerade auch noch nach einer > Möglichkeit zumindest die Ressourcen pro Entity anzeigen zu lassen. Die Ausgabe von "STAT" wäre interessant. Wenn ich (über Verilog) ein Latch Synthetisiere, dann kommt bei mir nach dem techmap mit interner library so etwas heraus:
1 | === latch === |
2 | |
3 | Number of wires: 4 |
4 | Number of wire bits: 4 |
5 | Number of public wires: 4 |
6 | Number of public wire bits: 4 |
7 | Number of memories: 0 |
8 | Number of memory bits: 0 |
9 | Number of processes: 0 |
10 | Number of cells: 1 |
11 | $_DLATCH_N_ 1 |
Input
1 | module latch(D, EN, Q); |
2 | input D, EN; |
3 | output Q; |
4 | |
5 | reg latch; |
6 | |
7 | always @* |
8 | begin |
9 | if ( EN == 1'b0 ) |
10 | latch <= D; |
11 | end |
12 | |
13 | assign Q = latch; |
14 | |
15 | endmodule |
Yosys script
1 | read_verilog latch.v |
2 | proc |
3 | techmap |
4 | opt |
5 | stat |
6 | techmap -map test_map.v |
7 | stat |
8 | show -format pdf -prefix 208_diagramm_after_mapping |
9 | write_spice out.sp |
Die gleiche Übung mit einem VHDL-Input über GHDL endet ohne Latch, wie oben schon gezeigt. Und übrigens muss ich das Latch als Workaround manuell extrahieren, das kann DFFLIBMAP noch nicht. Das ist allerdings im ICE40K flow schon eingebaut: https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/latches_map.v >Eigentlich ist es genau andersherum: Eine Kette aus Latches wird gebaut, >um der Synthese die komb. Schleife "unterzujubeln". Werden denn tatsächlich Latches synthetisiert?
> Werden denn tatsächlich Latches synthetisiert?
Ich habe leider gerade keine Möglichkeit die verwendeten Cells
durchzusehen. Die Schaltung funktioniert allerdings wie erwartet (was
ohne Latches nicht der Fall wäre).
Ein rueckgekoppelter Mux aka Latch laesst sich problemlos 'unterjubeln'. Wenn ich das in MyHDL mache (s.u.) kommt auch genau das raus. Kann man hier auch in der virtuellen Kiste per Binder austesten und in der RTL anzeigen: https://mybinder.org/v2/gh/hackfin/hdlplayground/master?urlpath=%2Ftree%2Fwork%2Few2021%2Fcosim.ipynb Da ist auch die Co-Simulation ('post map') per icarus mit drin.
1 | @block |
2 | def test(clk, a, b): |
3 | @always(clk) |
4 | def assign(): |
5 | if clk: |
6 | b.next = a |
7 | |
8 | return instances() |
yosys laesst den allerdings so wie er ist und erkennt ein Latch nur waehrend der 'proc_dlatch'-phase. Die nutzt das GHDL-Plugin nach meinem Stand nicht. Der obige ICE40-Techmap-Schritt sollte dann auch aus der $DLATCH-Primitive einen solchen Mux machen. Das Problem der Extraktion ist dann halt, dass du alle generierten Muxer auf Rueckkopplung abklopfen musst (per yosys Python-API oder C++-Plugin).
Thread beobachten
Seitenaufteilung abschalten
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.