Für Simulation. Genauer Zweck: Beahvior-Simulation eines Trasnmission Gates, das leider im digitalen Datenpfad liegt. Da ist leider onchip ein "echter" digitaler Bus mit mehreren Treibern, abgekoppelt durch trasnmission gates gebaut worden.
Beahvior-Simulation eines Trasnmission
Gates, das leider im digitalen Datenpfad liegt. Da ist leider onchip ein
"echter" digitaler Bus mit mehreren Treibern, abgekoppelt durch
trasnmission gates gebaut worden.
Gut. Dann sehe ich, dass das in VHDL offenbar keinen Spaß macht.
Dann wird das ein Systemverilog Modell.
Danke für die Hilfe.
Dans gleiche Problem hätte ich besipielsweise auch bei einem speziellen VIA:
Wenn im Asic-Schaltplan bestimmte digitale Signale durch spezielle VIA-Zellen die Metallalage wechseln, dann packt virtuoso beim Netzlisten da logischerweise diese via-Zelle mit rein. Und die braucht dann auch ein Modell, das in der Digital-Simulation das Signal korrekt durchpropagiert und an der Stelle nicht offen ist. In Verilog schreibt man da einfach ein
Dans gleiche Problem hätte ich besipielsweise auch bei einem speziellen
VIA:
Wenn im Asic-Schaltplan bestimmte digitale Signale durch spezielle
VIA-Zellen die Metallalage wechseln, dann packt virtuoso beim Netzlisten
da logischerweise diese via-Zelle mit rein. Und die braucht dann auch
ein Modell, das in der Digital-Simulation das Signal korrekt
durchpropagiert und an der Stelle nicht offen ist. In Verilog schreibt
man da einfach ein
Naja, üblicherweise simuliert man nur das Verhalten, das in der Realität vorliegt. Und in der Realität einer digitalen Schaltung sind 99,9999% der Leitungen uni- und nicht bidirektional. Die meisten Halbleiterstrukturen vertragen es auf Dauer auch nicht, mit einem negativen Potential beaufschlagt zu werden.
Natürlich kann man beim fehlenden Arsch in der Hose, sich vor der Entscheidung drücken, eine Richtung festzulegen. Clever ist das nicht, frisst unnötig Rechenzeit und Speicherplatz.
Das ist irgendwie nicht logisch: Eine Verhaltensimulation, die es ja sein soll, braucht einfach nur einen Schalter in Vorwärtsrichtung des Signals, gfs. mit Delay. Es gibt ja keine Rückwaertsrichtung. Oder doch?
Alles andere auf FPGA-Elektronik-Ebene lässt sich mit physischer Simulation erledigen, wenn man den wire von 2 Seiten besaftet und (hier) das Weitergeben an die andere Seite jeweils gated. Jeder "Draht" hat dann 2 Eingänge und 2 Ausgänge, jeweils von links und rechts.
Ist Dasselbe wie ein Port-Ausgang. Der kann auch von innen und außen getrieben werden - was halt kollidieren kann. Ich nehme an, das so etwas simuliert werden soll?
Um das sinnvoll zu machen, empfiehlt es sich, die Informationsweitergabe an das andere Leitungsende mit 10 ps / cm zu gestalten. Das löst automatisch timing-Konflikte auf. Bei deinem Gate dürfen es auch gerne diese 10 ps sein. Wäre dann in etwa auch gleich die Schaltzeit.
Du musst dir natürlich überlegen, was passiert, wenn eine Kollision auftritt und gegensinnig getrieben wird. Ich habe in meinen Modellen dann nach 10ps ein X drin, das bei einem Port dann auch auf den Leseeingang weitergegeben wird.
In den Analogmodellen habe ich einen Strom der getrieben wird aus dem ich eine Spannung mache, die dann per Schmitttriggerentscheidung in einen Logikpegel geht.
Das sind aber Sachen, die man nur braucht, wenn man das Umschaltverhalten der Ports und der Mimik davor im Zusammenspiel mit äußerer Elektronik simulieren und nachweisen will. Meistens sind diese Validierungen eigentlich durch reale Tests im FPGA abgedeckt.
Nein soll es nicht. Siehe die vorherigen Beiträge. Das ist aber an sich auch irrelevant, was genau simuliert werden soll. Aber da es offenbar für alle wichtig ist, kann ich das ja mal im Detail erläutern.
Das ist irgendwie nicht logisch: Eine Verhaltensimulation, die es ja
sein soll, braucht einfach nur einen Schalter in Vorwärtsrichtung des
Signals, gfs. mit Delay. Es gibt ja keine Rückwaertsrichtung. Oder doch?
Jein. Je nachdem. In diesem Fall tatsächlich weil über Transmission Gates ein digitales Signal von mehereren Quellen auf eine Leitung gelegt wird und dann woanders reingeht. Das ist eben so. Da war laut Layoutern kein Platz mehr um einen richtigen Digitalen Testbus mit Gattern und Muxen zu verlegen.
Natürlich kann man beim fehlenden Arsch in der Hose, sich vor der
Entscheidung drücken, eine Richtung festzulegen. Clever ist das nicht,
frisst unnötig Rechenzeit und Speicherplatz.
In einer richtigen Netzliste taucht eben mehr auf als reiner RTL Digitalkram...
Bei Compile-Times von mehreren Tagen und Simulationsdauern von Wochen, machen die paar Transmission Gates auch nichts mehr aus...
Anhand eines Vias, kann ich das Ganze mal erläutern. Das ist jetzt ein Beispiel, besitzt aber das gleiche "Problem":
Ich habe einen Asic. Dieser besitzt bspw. einen Haupt-Digitalteil. Dieser wurde bspw. mit einem Synopsys DCNXT oder so synthetisiert und bspw. mit dem Synopsys IC Compiler in ein Layout gegossen. Diesen kann ich vollumfänglich mit seinem RTL code (schnell) oder der synthetisierten Netzliste (langsam) oder dem echten Trasnistor-Level Schaltplan (unerträglich langsam) simulieren.
Ich habe jetzt bspw. Noch einen ADC oder ein anderes analog/digital gemischtes etwas im System. Dieser beinhaltet einen out-of-context synthetisierten und platzierten Digitalteil für die ganze Logik und Filter und was man so halt macht in einem ADC. Diser Digitalteil besitzt zum Haupt-Digitalteil ein Bus Interface. Bspw. einen APB, AXI, Wishbone, OCP etc.
Jetzt läuft das Ganze so, dass im Schaltplan dieser ADC an den Digitalteil anverkabelt wird. Für den ADC hat man ein Modell und für den Digitalteil ja den RTL Code bzw. die Gatter-Netzliste.
Jetzt gibt es zwei Möglichkeiten, wie man das simuliert:
Man baut sich ein "Dummy"-Toplevel und bildet diese Verdrahtungen etc. mittels RTL ab. Dann kann man simulieren und alles ist gut. Ist aber nicht optimal, da man nicht das reale Design simuliert. Wenn im Schaltplan etwas falsch angeschlossen wurde, würde man das nicht sehen. So fängt man eben an, ist aber für die finale Verifikation etc. nicht besonders zielführend.
Man lässt sich von Virtuoso den Schaltplan netzlisten und simuliert diesen. Dann braucht man jetzt eben für alle Teile (wenn man eine AMS/DMS Simulation machen will) oder zumindest für die Teile, die digitale Signale propagieren (für rein digitale Tests) Modelle von den Zellen.
In diesem gedachten Fall ist jetzt bspw. eine spezielle via-Zelle im Schaltplan, die Metalllage 1 und Metalllage 2 verbindet. Wenn diese im Schaltplan als Symbol eingefügt ist, um bspw. den Lagenübergang zwingend zu forcieren, weil man da später vielleicht noch mit einem FIB oder einem Metal-Fix der oberen Lage rankommen will, dann benötigt diese Zelle ein hinterliegendes Modell, damit da keine Blackbox den Signalfluss unterbricht.
Da dieses Via aber für beide Richtungen benutzt werden kann, von Lage 1 auf 2 oder andersrum von Lage 2 auf Lage 1, muss das Simulationsmodell auch beide Signalrichtungen unterstützen. Eine Instanz des Modells führt dann natürlich nur in eine Richtung. Aber die verschiedenen Instanzen können Signale in verschiedene Richtungen haben.
Daher das Problem. Mit einer Verilog Netzliste ist das auch alles kein Problem.
Ich hatte nun eben die Frage, ob das auch mit VHDL irgendwie geht, um eben an vielen Stellen die Unsicherheit von Verilog rauszubekommen.
Ich hatte nun eben die Frage, ob das auch mit VHDL irgendwie geht
VHDL ist zur Beschreibung und Simulation von digitalen Schaltungen gedacht. Solche Schalteffekte kannst du da nur unzureichend abbilden. Mehr als "geht durch" oder "geht nicht durch" wird da kuma gehen.
Für solche Fälle wie deinen braucht es einen Mixed-AD Simulator.
Du könntest es in pSpice machen.
Du hast keinen FPGA und schreibst im FPGA-Forum?
Warum VHDL?
Aha, hier steht es:
Oh mann. Das ist doch auch ein VHDL Subforum. Und meine Frage war gekapselt einfach nur:
Kann ich ein Verilog "rtranif1" Intrinsic auch irgendwie in VHDL abbilden?
Diese Frage ist in sich schon abgeschlossen. Aber alle wollen ja immer wissen wofür, obwohl das nicht von Belang ist. Und wenn man dann schreibt wofür man das braucht fangen alle an dir zu erklären, dass das was du machst keinen Sinn ergibt, obwohl sie keine Ahnung haben. Es ist schon lustig hier. Es gibt eben auch Sachen die in VHDL und Verilog gemacht werden, die über die rein digitale FPGA Synthese hinausgehen.
VHDL ist zur Beschreibung und Simulation von digitalen Schaltungen
gedacht. Solche Schalteffekte kannst du da nur unzureichend abbilden.
Mehr als "geht durch" oder "geht nicht durch" wird da kuma gehen.
Reicht doch. Mehr macht das rtranif1 in Verilog auch nicht und das war ja eben die Frage.
Ich hatte nun eben die Frage, ob das auch mit VHDL irgendwie geht,
Prinzipiell schon, aber wie genau, sollte im Design-Guide des
Toolherstellers stehen.
P.S.: Es nützt Dir ja nix, wenn zwar das VHDL richtig ist, aber das Tool
Dir am Ende einen bidirektionalen Treiber einbaut...
Es geht ja nicht um Synthese, sondern Simulation. Das Trasnmissiongate ist ja im Schaltplan da. Es geht nur darum, einem digitalen Simulator einen bidirektionalen Switch beizubringen, da ich am Ende des Tages nicht weiß, von welchem Ende aus in das Modell ein Wert reingetrieben wird.
Die Antwort von Lothar funktioniert zwar, aber tatsächlich scheint mir die Verilogvariante in diesem Fall sinnvoller, da sie leichter zu verstehen und im Schematic-Trace des Debuggers besser ersichtlich ist.
Man kann das durchaus in VHDL forumilieren und ich habe oben auch detailliert beschrieben wie. Es kommt auf den Fokus an, den man hat:
Simuliert man die Logik gibt es nur ein beschränktes Modell: Ein Transmission-Gate hat diesbezüglich eben die beiden Funktionen "Durchgang" und "Zeitverzögerung".
Simuliert man die komplette Physik, kommen mindestens mal "slew rate" und "level shift" hinzu.
Auch das kann man sehr wohl in VHDL machen und das auch recht effektiv. Dazu gibt es VHDL-AMS, oder eben die händische Abwandung, die man sich selber definieren kann. Mit dem, was ich mir geschrieben habe, simuliere ich komplette Filterstrukturen und Operationsverstärker.
Ansonsten geht es über Simulink, wenn man neben der Elektrik, die so simuliert wird auch noch die Mechanik oder Motoren reinhängen will. Auch dafür lohnt ein FPGA, weil der nämlich als Beschleuniger der Berechnung dienen kann. Die gesamte Simulation wird in VHDL übersetzt und in den FPGA geladen.
Zuletzt bleibt noch die Erwähnung, dass Modelsim erheblich schneller simuliert, als z.B. MATLAB.
Lediglich von Lothar kam ein sinnvoller Beitrag (und sogar mit einer
Lösung. Nochmals danke dafür.)
Nope, so ziemlich jeder Beitrag ist sinnvoll, was du aber nicht anerkennen magst, weil Du dann einen Großteil Deiner Grundannahmen als "falsch" erkennen müsstest. Und "Lothars Lösung" krankt an mindestens zwei Stellen.
Man baut sich ein "Dummy"-Toplevel und bildet diese Verdrahtungen
etc. mittels RTL ab. Dann kann man simulieren und alles ist gut. Ist
aber nicht optimal, da man nicht das reale Design simuliert. Wenn im
Schaltplan etwas falsch angeschlossen wurde, würde man das nicht sehen.
Wenn man bidirektionale Ports verwendet, wo keine nötig sind, kann man falsch angeschlossene Signale nicht erkennen.
Verwendet man unidirektionale Signale, knallt schon die Compilephase die Fehler von out auf out oder in auf in um die Ohren.
Ich hatte nun eben die Frage, ob das auch mit VHDL irgendwie geht, um
eben an vielen Stellen die Unsicherheit von Verilog rauszubekommen.
Dann verwendet auch "sicheres" VHDL, also unidirektionale Signale und unresolved signals (bspw.: std_ulogic statt std_logic.)
Und für Asic wurde schon vor 30 Jahren die "VHDL Initiative Towards ASIC Libraries", kurz VITAL (IEEE 1076.4) erfunden.
Nope, so ziemlich jeder Beitrag ist sinnvoll, was du aber nicht
anerkennen magst, weil Du dann einen Großteil Deiner Grundannahmen als
"falsch" erkennen müsstest. Und "Lothars Lösung" krankt an mindestens
zwei Stellen.
Nein sind sie nicht. Dass die "Lösung" krankt, sehe ich selbst. Schön ist das nicht.
Nochmal: Es geht darum einen bestehenden Schaltplan aus Cadence Virtuoso so zu netzlisten, dass er funktional(!) digital simulierbar ist.
Es geht nicht darum eine DMS oder AMS Simulation zu machen. Diese wird natürlich auch gemacht, ist aber hier nicht das Ziel!
Es geht konkret darum, dass eben digitale Signale durch analog gelayoutete Strukturen gehen. Dafür benötige ich ein funktionales(!) Modell, damit die ATPG Generierung, die die Scan patterns der Logik generiert die komplette Verdrahtung kennt. Diese Generierung basiert auf rein digitalen Netzlisten. Diese analogen Transmission Gates liegen nunmal in einer Kette, die wie alle digitale Logik durch Scan-Ketten getestet wird.
Und da ich nicht weiß, wie rum man diese transmission gates eingelayoutet hat, ob Port a der Eingang oder Port b der Eingang ist, muss das Modell, dass für alle Instanzen das selbe ist, natürlich auch beide Richtungen unterstützen.
Ich hatte nun eben die Frage, ob das auch mit VHDL irgendwie geht, um
eben an vielen Stellen die Unsicherheit von Verilog rauszubekommen.
Dann verwendet auch "sicheres" VHDL, also unidirektionale Signale und
unresolved signals (bspw.: std_ulogic statt std_logic.)
Bringt nichts. Das würde ja etwaige Schaltplanfehler verscheleirn. Die würde man dann später zwar bei einer richtigen DMS Simulation sehen, aber es ist ja der Sinn mit low Effort schon früh Dinge zu finden. Wenn einem die finale Simulation 3 Wochen vor dem Tapeout um die Ohren fliegt bringt das auch nichts.
Konkret wäre für mich bei VHDL interessant gewesen, dass es range-Checks macht und ich einen 4 bit port nicht auf einen 5 bit port verdrahten kann, was leider in Verilog einwandfrei geht.
Verwendet man unidirektionale Signale, knallt schon die Compilephase die
Fehler von out auf out oder in auf in um die Ohren.
Da die synthetisierten Netzlisten in Verilog sind und auch die genetzlisteten Schaltpläne in Verilog sind, knallt da erstmal absolut gar nichts. Verilog hat kein Problem damit wild über alle in/out/inout grenzen hinweg Zeug zu treiben. Das sind alles nur Drähte. Und wenn da ein paar mal x auftaucht ist das ja sehr praktisch, weil dann offenbar was falsch wäre.
Und für Asic wurde schon vor 30 Jahren die "VHDL Initiative Towards ASIC
Libraries", kurz VITAL (IEEE 1076.4) erfunden.
Ist seit 2009 zurückgezogen. Wenn du schon Leuten ihre Arbeit erklären willst, dann lies es vorher selbst mal. Und VHDL stöößt leider bei den ASIC-Playern auf taube Ohren... Wie gesagt. VHDL 93 macht teilweise auch noch Probleme. Da gibt es schonmal den ein oder anderen Synthese Fehler, der dann manuell in der Netzliste gepatcht werden muss.
Es geht hier nicht darum, ob das, was ich mache, sinnvoll ist oder nicht. Das ist das normale Industriestandard Vorhegen. Das machen alle genau so: ST, AD, TI (mehr habe ich noch nicht von innen gesehen) und die Toolhersteller Synopsys, Cadence legen ihr Tooling auch genau darauf aus. Und das funktioniert auch.
Die Zelle, die mir vorliegt sieht quasi identisch aus, außer, dass die zwei Gate Signale intern durch 2 Inverter erzeugt werden. Man sieht die hexagonförmigen Ports an den Ein-/Ausgängen? Das sind bidirektionale Ports in Virtuoso. Also MUSS das Modell auch bidirektionale Ports im Verilog-Modell haben. Das geht einfach nicht anders. Hier sind die jetzt mit in / out bezeichnet. Bei mir eben nur mit A und B. Eingesetzt wird die Zelle in beide Richtungen.
muss das Modell, dass für alle Instanzen das selbe ist, natürlich auch
beide Richtungen unterstützen.
Ich erkläre jetzt hier kein drittes mal, wie man das macht.
*PS Du bist nicht der erste, der Mixed-AD-Sim macht. Das kann sowohl der digitale Simulator mit anlogisierten Modellen, als auch der pSPICE mit digitalisieren Modellen.
Also MUSS das Modell auch bidirektionale Ports im
Verilog-Modell haben.
Wo ist das konkrete Problem?
Du weist nicht, in welche Richtung der tatsächliche Signalfluss läuft, also musst du es komplett formulieren: 2 Eingänge <-> 2 Ausgänge. Einmal von links, einmal von rechts und die Weitergabe nur dann wenn "enable" = "ausreichend 1".
Entweder hast du das enable als Spannung -> Komparator -> "If input > X" oder es liegt als digitales Signal vor.
Das was du da brauchst ist am Ende nur ein kleiner Teil eines FPGA-ports, nämlich den output-Driver mit seinem enable und den Leseeingang. 2 davon schaltet man gegensinnig zusammen. Entweder selber formulieren oder sich das Verilog-Model eines Pins vom FPGA klauen und verknüpfen.
jetzt habe ich es doch noch ein 3.tes mal erklärt.
Ich erkläre jetzt hier kein drittes mal, wie man das macht.
*PS Du bist nicht der erste, der Mixed-AD-Sim macht. Das kann sowohl der
digitale Simulator mit anlogisierten Modellen, als auch der pSPICE mit
digitalisieren Modellen.
Nochmal: Es geht darum einen bestehenden Schaltplan aus Cadence Virtuoso
so zu netzlisten, dass er funktional(!) digital simulierbar ist.
dritten Mal:
Ich fange mit einer mixed signal Simulation nichts an! Das kann ich auch ohne den Handstand mit einem VHDL Modell. Das brauche ich an diesem Punkt nicht. Für eine mixed Signalsimulation kann ich das Gate ja als Schaltplan lassen. Die Transistoren haben ja simulierbare Modelle...
Mich interessiert eine VHDL Alternative zu den Verilog Instrinsics:
rtranif0 / rtranif1
tranif0 / tranif1
aus folgendem Grund: Ich habe digitale Signale, die durch Transmission Gates gehen. Wenn die konstant in einer Richtung eingebaut worden wären, sprich Port A ist der Eingang und Port B der Ausgnag hätte ich diese Zelle einfach durch ein
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entitytgateis
5
port(
6
a:instd_logic;
7
b:outstd_logic;
8
control:instd_logic);
9
endentitytgate;
10
11
architecturefunc_behavoftgateis
12
13
begin
14
b<=awhencontrol='1'else'Z';
15
endarchitecturefunc_behav;
ersetzen können.
Jetzt ist dieses Ding aber beispielsweise 2000 mal instanziiert und leider die Hälfte der Zeit einfach andersrum eingebaut. Sprich von Port B wird zu Port A getrieben.
Lösung in (System)-Verilog:
1
module tswitch (
2
input control,
3
inout a,
4
inout b
5
);
6
rtranif1(a, b, control);
7
endmodule
Da die Netzliste automatisch erzeugt wird, wird eben an allen Stellen wo dieses Gate drin ist auch immer dasselbe Modell instanziiert. Sprich das selbe Modell muss beide Signalrichtungen beherrschen.
Und da es offebar immernoch nicht angekommen ist: Ich brauche das NICHT für eine klassische Simulation, sondern akut konkret für den Flow, der Mittels Synopsys Tetramax / Testmax etc. die Scanpatterns generiert, um die Logik zu testen. Und leider ist der Pfad dieser Signale im zu- scannenden Logikteil und kann nicht einfach durch eine Scan-Isolation abgekoppelt werden. Und dieser Flow fängt mit einer mixed signals Simulation absolut nichts an.
Es wäre abschließend doch noch ganz schön, wenn jemand mit Ahnung einfach beantworten kann, ob es eine VHDL Variante der Verilog Intrinsics rtranif1 / tranif1 gibt, oder ob VHDL dafür einfach ein level zu hoch ist und das nur mit dem oben von Lothar verlinkten "Workaround" geht.
Dann können wir den Thread auch zumachen.
Ich habe vergeblich versucht zu erklären, wofür ich das VHDL gerne hätte, aber hier wird einem ja erzählt, dass der Prozess, wie bereits zehntausende Asics auf diesem Planeten designt wurden, komplett unsinnig wäre.
Wenn keiner eine interessante Idee hat, die ich mal ausprobieren kann, dann bleibt das eben, wie die letzten 30 Jahre schon, bei Verilog.
Du musst nichts erklären, sondern einfach die von mir vorgeschlagene Lösung verwenden, nämlich den Signalfluss von 2 Seiten aufbauen. Das ist nämlich das, was ein Gate tut. Was ist denn daran so schwer, das einfach zu machen?
Es wäre abschließend doch noch ganz schön, wenn jemand mit Ahnung
"Ahnung" haben wir hier durchaus. Wir haben sogar Wissen. Ich z.B. habe bereits mehrfach VHDL und Verilog für eben solche ASIC-Entwicklungen verfasst, seien es MEMS-Auswerte-Chips oder Bildverarbeitungs-ASICs - zur Erstellung und auch Verifikation. Solche physikalischen Elemente bricht man genau so runter auf ihre rudimentäre Logikfunktion, wenn man nur diese simulieren möchte.
ob es eine VHDL Variante der Verilog Intrinsics rtranif1 / tranif1 gibt,
Diese und andere hat jeder Hersteller in seiner Library, der in seinem Prozess solche Teile verwendet und sie simulieren möchte, weil er nämlich wie ich und andere, die gleiche Aufgabe täglich gestellt bekommt. Natürlich hat sich irgendwann mal jemand hingesetzt, und sie geschrieben.
Das scheint mir hier auch das Problem zu sein: Du möchtest sie irgendwo laden, ohne zu verstehen wie es funktioniert, statt dich einfach hinzusetzen und die Funktion kurz abzubilden. Dazu würde ich aber raten, dich damit zu befassen, weil es möglicherweise noch öfters vorkommt, dass der böse Compiler dir "analoge" Schaltelemente in den Weg wirft.
Beim SoC-Entwurf gibt es z.B. solche netten Effekte, wie Busse die auf das gleiche RAM zugreifen und die DMA machen sollen, allerdings nicht gegeneinander treiben. Da tauchen dann wieder die bidirektionalen Signale auf, die wir in FPGAs schon seit 30 Jahren nicht mehr haben.
VHDL ist funktionstechnisch und sprachlich auf genau demselben Level wie Verilog. Da gibt es keine andere Ebene. Es ist an der Stelle Geschmacksfrage, was man nimmt. Beide, VHDL und Verilog, liefern neben den reinen Logikpegeln auch schon physikalisch vordefinierte Pegel wie Weak, Low und High, mit denen man direkt pull down und pull up realisieren kann.
Einen TG-Schalter zu formulieren ist etwa Seminaraufgabe im 3. Semester, zweite Vorlesung. Wie erklärt, gibt es 2 Signalflussrichtungen, so wie man das auch bei einem Datenbus auflöst, der Außen bidirektional ist. Das wirst du in deiner 2000-Gates großen Schaltung vermutlich auch irgendwo haben und funktioniert nach derselben Mimik.
Aber da du schon SysVl eingeführt hast, darfst du folgende Wahrheitstabelle bilden und dir überlegen, was passiert:
Es 3 Pins LEFT, RIGHT und G, die die Zustände 1,H , 0,L und Z haben können. Macht eine Anzahl Fälle, von denen zunächst nur 2 interessant sind, wenn nämlich G=1 und Pin 1 und Pin 2 gegenläufig treiben -> Kollisionsfall
Dann beschreibt man die beiden Durchschalt-Fälle, in denen nur ein Eingang treibt:
If ( (Left != Right) and (Left != "Z") and (G = '1' or G="H") ) then Right <= Left;
und den Gegenfall.
Im Fall einer gültigen Diskrepanz zwischen Left und right wird der Simulator aktiv und treibt die Information rüber. Ab dann sieht der Simulator den ->Equivalenzfall dass LINKS und RECHTS das gleiche steht und macht nichts mehr.
Der Compiler, der das übersetzt, ist in der Lage, die Simulation zu optimieren und erkennt, wo anhand der möglichen Fälle welche Funktion wegoptimiert werden kann. Fälle die nicht vorkommen, weil es den Pegel nicht gibt, oder die Verschaltung dort nichts anliefert, werden nicht realisiert und später auch nicht gerechnet. Das doppelte Formulieren kostet also nicht einmal Simulationszeit.
Ich empfehle
"Hardware, Software Codesign" (Gessler)
"Abstrakte Modellierung digitaler Schaltungen" (Ten Hagen)
oder einfach die Digitaltechnikvorlesung an unserer Uni.
Du musst nichts erklären, sondern einfach die von mir vorgeschlagene
Lösung verwenden, nämlich den Signalfluss von 2 Seiten aufbauen. Das ist
nämlich das, was ein Gate tut. Was ist denn daran so schwer, das einfach
zu machen?
Okay. Da haben wir jetzt glaube ich den Knackpunkt gefunden. Ich verstehe offen und ehrlich nicht, was du meinst. Es fiel sooft das Wort Mixed-Signal Simulation und pSpice, dass ich mir nicht sicher bin, was du denkst, was ich machen will.
Alle Versuche das in VHDL abzubilden, ohne es so zu machen, wie Lothar gepostet hatte, indem die Prozesse die Zeit speichern und erst wieder zu einem neuen Zeitschritt aktiv werden, führten dazu, dass sich das irgendwann in einer Dauerschleife weggehängt hat, bzw ein bestehendes X nicht mehr verschwindet.
Und das "richtige" Simulationsmodell für eine Mixed-Signal Analyse kann ich nicht nutzen, da ich an dieser Stelle keine mixed Signal Analyse mache. Bzw genaugenommen gar keine klasssische Simulation mache...
ob es eine VHDL Variante der Verilog Intrinsics rtranif1 / tranif1 gibt,
Diese und andere hat jeder Hersteller in seiner Library, der in seinem
Prozess solche Teile verwendet und sie simulieren möchte, weil er
nämlich wie ich und andere, die gleiche Aufgabe täglich gestellt
bekommt. Natürlich hat sich irgendwann mal jemand hingesetzt, und sie
geschrieben.
Das verstehe ich nicht. rtranif1 / tranif1 haben nichts mit "dem Hersteller" zu tun. Das sind Schlüsselwörter in Verilog. Die sind intrinsisch in der Sprache implementiert. Was meinst du hiermit?
dass der Prozess, wie bereits
zehntausende Asics auf diesem Planeten designt wurden, komplett unsinnig
wäre.
Ich sehe nirgends eine Aussage in dieser Richtung von irgendjemandem
hier - auch nicht von mir.
Bspw:
Klaus K. schrieb im Beitrag #7528806:
Nope, so ziemlich jeder Beitrag ist sinnvoll, was du aber nicht
anerkennen magst, weil Du dann einen Großteil Deiner Grundannahmen als
"falsch" erkennen müsstest.
Nochmals abschließend:
Ich habe einen funktionierenden Veriloghaufen (siehe Eingangspost). Es wäre jetzt aber schön etwas äquivalentes in VHDL zu haben, da ich kein Verilog-Fan bin. Die letzten 20 Posts ignorieren wir mal.
Wie würde man das sinnvollerweise in VHDL implementieren?
Delays werden nicht benötigt. Die kommen später wieder aus autogenerierten Verilog specify Blöcken.
Das folgende bringt leider nicht die erhoffte Lösung:
Das folgende bringt leider nicht die erhoffte Lösung:
1
>p:processis
2
>begin
3
4
5
>endprocessp;
6
>
(1) Code bitte vollständig (hier fehlt signaldeklaration und Bibliothekseinbindung) und auch als file im Anhang posten. Korrekte Wiedergabe des compile-logs und der diesem Post initial voranstehenden Fehlermeldung ist auch hilfreich. Die Signaldeklaration ist hier insbesonders relevant, weil es hier auch um den Problemkreis, mehrere Treiber gleichzeitig und damit der "resolution function" geht.
(2) wer bei einem thread aus 21 posts die letzten 20 ignoriert hat jeglichen 'Anspruch' auf Forumsunterstützung verspielt.
Warum soll man einem Lernresistenten die richtigen Antworten mundgerecht zuspielen wenn er diese selbstgefällig und mit Ansage ignoriert?!
(3) wenn es dir um mehr Sicherheit bei Verilog geht, dann mach dich in Richtung Codestyle und 'Lint' (Static source analysis)) schlau. Ein IC-Designer sollte auch in der Lage sein, ein (Python-) script zu schreiben, was nach kritischen Stellen/Verletzung des style guides parst.
(4)"Schuster bleibt bei deinen leisten". Wenn du nicht bereit bist, Dich in VHDL für die tägliche ASIC-Desing-Arbeit einzuarbeiten, dann bleib bei Verilog. Fertigungshansel und Automatenbediener brauchen ohnehin kein Wissen über den Chipentwurf.
(5) Nein, auch ich schreibe Dir hier nicht die korrekte Lösung deines Problems, du hast genug Hinweise(signal driver disable, null transaction, signal resolution) erhalten. Wende dich lieber an einen FAE des Toolherstellers, der wird dafür entlohnt, Kunden für den effektiven Umgang mit seinen Produkten zu qualifizieren.
Warum soll man einem Lernresistenten die richtigen Antworten mundgerecht
zuspielen wenn er diese selbstgefällig und mit Ansage ignoriert?!
Eine für mich klar ersichtliche Antwort war leider nicht dabei. Es wurde alles abgehandelt, von wie man einen externen Bus simuliert bis hin zu einer mixed signals Simulation mit pspice.
Ich muss zugeben, dass ich einfach nicht verstanden habe, wo das alles herkam, obwohl die Frage "einfach" nur war:
Ich habe ein Verilog rtranif1 in einem Modul. Wie kann ich in VHDL '93 eine (halbwegs) äquivalente Beschreibung realisieren?
Mein Versuch ist jetzt im Anhang mit kleier TB. Hier funktioniert das erstmal auch. Leider sehe ich, und das muss ich noch debuggen, woran das liegt,irgendwann im Final eingebauten Zustand Xe an beiden Ports, obwohl keine anderen Treiber aktiv sind. Wenn ich den VHDL Block wieder durch ein Verilog rtranif1 ersetze geht alles. Da kann ich aber leider erst morgen tiefer reinschauen, ob da irgendein Verilog / VHDL Mischmasch Delta-Cycle Problem an einer Stelle entsteht und es sich deswegen verspult.
Mit dem Zero Ohm Switch den Lothar verlinkt hatte, geht es aber. Also ist da noch was vergraben.
wenn es dir um mehr Sicherheit bei Verilog geht, dann mach dich in
Richtung Codestyle und 'Lint' (Static source analysis)) schlau. Ein
IC-Designer sollte auch in der Lage sein, ein (Python-) script zu
schreiben, was nach kritischen Stellen/Verletzung des style guides
parst.
Genau das meinte ich. Es werden immer mehr Infos erfragt und dann wird sich an sowas festgebissen. Ich erwähnte, dass ich lieber VHDL verwende, weil ich das für die schönere Sprache halte, unter anderem weil es eben implizit mehr Sicherheit bringt. Wie ich mein Linting mache, ist doch ehrlich gesagt für eine VHDL Frage irrelevant. Dank Synopsys Spyglass muss ich zum Glück keine händischen Skripte schreiben.
(4)"Schuster bleibt bei deinen leisten". Wenn du nicht bereit bist, Dich
in VHDL für die tägliche ASIC-Desing-Arbeit einzuarbeiten, dann bleib
bei Verilog. Fertigungshansel und Automatenbediener brauchen ohnehin
kein Wissen über den Chipentwurf.
Bezeichnest du deine Kollegen in der Fertigung (falls ihr sowas habt), auf der Arbeit auch als Fertigungshansel? Die brauchen teilweise durchaus Wissen, wie das halbwegs tut. Ich bin froh darüber, dass die bei uns nicht blind einfach nen Knopf drücken, sondern, wenn da mal was komisch aussieht das erstens erkennen und auch anrufen. Da hat man schon die ein oder anderen Problemchen gefunden.
Das muss ich leider an vielen Stellen tatsächlich machen, weil das Tooling an einigen stellen den VHDL Support komplett vermissen lässt. Gibt es eine ein VHDL Äquivalent zu Verilogs specifiy Blöcken, um das Timing eines Moduls zu definieren?
https://www.hdlworks.com/hdl_corner/verilog_ref/items/Specify.htm
Das ist eine ernstgemeinte Frage. Ich habe da in VHDL noch nie was gesehen.
Das ist eine ernstgemeinte Frage. Ich habe da in VHDL noch nie was
gesehen.
Was hast du überhaupt von VHDL gesehen? Oder, was hast Du gesehen und nicht gleich aus reiner Anmaßung verworfen, wie der Hinweis auf VITAL?!
Klar kann VHDL auch timings definieren und bietet Möglichkeiten zu Verifizierung an, einfach mal Signal Laufzeit models nachschlagen (inertial, transport). Oder die Attribute 'delayed 'stable etc benutzen.
Anbei ein Auszug aus einem deutschsprachigen Lehrbuch (ISBN: 3-89959-163-1) zu dem Thema. Wenn Du ernsthaft VHDL einsetzen willst wirst Du um's Studium solcher Fachliteratur nicht umhin kommen.
Was hast du überhaupt von VHDL gesehen? Oder, was hast Du gesehen und
nicht gleich aus reiner Anmaßung verworfen, wie der Hinweis auf VITAL?!
Klar kann VHDL auch timings definieren und bietet Möglichkeiten zu
Verifizierung an, einfach mal Signal Laufzeit models nachschlagen
Okay. Ich gehe mal davon aus, dass ich mich mal wieder falsch ausgedrückt habe. Wie ich in vhdl ein Delay schreibe, ist mir durchaus bewusst. Ebenso kenne ich die Schlüsselwörter transport, after etc.
Meine Frage war konkret: Gibt es eine Möglichkeit das Timing eines Moduls auf seiner Entity Basis, ohne das darin enthaltene VHDL zu simulieren, zu annotieren.
Sämtliche Timing Flows, fangen nämlich mit delays in den Modulen, weder bei Verilog noch bei VHDL etwas an. In Verilog kann ich beispielsweise schreiben:
1
`celldefine
2
module my_weird_asymmetric_and_gate(
3
input in_a;
4
input in_b;
5
output o);
6
7
specify
8
(in_a => o) = 2;
9
(in_b => o) = 4;
10
endspecify
11
12
assign o = in_a & in_b;
13
14
endmodule
15
`endcelldefine
Das simuliert auf code Basis ohne Delay, wird aber von der STA korrekt betrachtet bei der Timing Analyse. Gibt es hier in VHDL auch gerne aktuelle Standards eine Möglichkeit?
Die einzige Möglichkeit, die ich kenne, wäre das and gate normal in VHDL zu beschreiben und der STA mittels eines liberty files Das Timing modell separat einzuflößen.
a <= b when control = '1' else 'Z';
b <= a when control = '0' else 'Z';
so sein.
Das ist leider nicht das was ich brauche. Ich habe nach einem VHDL Ersatz für einen Verilog "rtranif1" gesucht. Sprich:
control = '0': a und b werden als 'Z' "getrieben". Keine Kopplung zwischen a und b
control = '1' a wird nach b und b nach a getrieben. Resolution gemäß den Regeln, die im std_logic definiert sind.
Ich habe ja mittlerweile Dank Lothars Beitrag etwas zusammengebastelt bekommen, was aber offenbar im Großen und Ganzen noch irgendwo ein Delta-Cycle-Problem an einer Stelle generiert.
Dann nimm doch das was ich zuerst geschrieben hatte:
a <= b when control = '1' else 'Z';
b <= a when control = '1' else 'Z';
Was zwar schön wäre. Aber so leider nicht funktioniert.
Wenn ich control = '1' treibe, a auf '0' treibe und 'b' auf 'z' treibe, dann sind sowohl a, als auch b 'X' anstatt '0', weil er sich im selben Deltacycle einmal im Kreis in den Schwanz gebissen hat, weil davor der Wert auf 1 getrieben war.
Testbench ist die selbe wie im Beitrag weiter oben.
Was zwar schön wäre. Aber so leider nicht funktioniert.
.. und auch nicht funktionieren kann: Selbst wenn man mit den realen 10ps Verzögerung arbeitet, wird das System pendeln, wenn man nicht den Ausgang des Signals von den dessen Input trennt. Das Lesen und Interpretieren der Seiten, die getrieben wird, muss exklusiv passieren und das eben auf jeder Seite.
Daher geht es auch hier nicht, wie sonst in ModelSim einfach eine Leitung von mehreren Stellen im Design zu treiben, was ja grundsätzlich der erste Ansatz für ein Bussignal wäre. Es muss eine räumliche Abgrenzung geben, während es im ModelSim-Fall nur eine zeitliche braucht, um Kollisionen auszuschließen.
Beim Zuweisen muss die Richtung exklusiv behandelt werden, daher ist zu prüfen, ob eine Leitung von links oder von rechts getrieben wird. Das bekommt man nur über die explizite Verknüpfung aller Kombinationen in der Wahrheitstabelle heraus und der ausdrücklichen Behandlung derselben.
Ich finde das unverständlich dass das diskutiert werden muss, weil das doch genau der Grundlagenvorlesungstoff ist, der in der Digitaltechnik zuerst behandelt wird. Offenbar wird das aber übersprungen und sofort in die Hochsprachen hinein gehüpft, wodurch den Studenten ein Denkbaustein verloren geht.
Darf ich raten? Du bist entweder kein Student der Elektrotechnik, bzw hast keine Digitaltechnik gehabt, oder warst an einer FH oder bist U40.
Richtig?
Darf ich raten? Du bist entweder kein Student der Elektrotechnik, bzw
hast keine Digitaltechnik gehabt, oder warst an einer FH oder bist U40.
Richtig?
Muss hier immer gepöbelt werden? Ich beispielsweise bin unter 40 (noch), habe in E-Technik fast promoviert. Musste leider abbrechen und hatte Digitaltechnik.
Und ich konnte auch viele Jahre keinen Centimeter VHDL, da bei uns ausschliesslich Verilog gelehrt wurde. Liegt vielleicht daran, dass ich aus der Schweiz komme.
Das sieht doch gut aus. Ich würde nur das wait on am Anfang an das Ende des Prozesses schieben was es soweit ich weiss identisch zu einer Sensitivity-Liste macht.
Auf diese Art sind die Treiber im Prozess beim Simulationsstart bereits gelaufen und du bekommst das 'U' weg, was bestehen bleiben würde, wenn control unassigned bliebe.
Da ist mein Wissen rar gesät. Aber wenn das noch so ist wie vor 10 Jahren, dann hast du zwar nun eine simulierbare Beschreibung, aber Tetramax erkennt imho das nicht am Verhalten sondern an der statischen Verdrahtung, die es analysiert hat. Die Verilog Gatter Primitiven wie rtranif0 und tran taten da aber auf jeden Fall. Zu meiner Zeit konnte das nicht mal integer in den Portlisten. Ich hoffe wenigstens das geht jetzt.
Beim Zuweisen muss die Richtung exklusiv behandelt werden, daher ist zu
prüfen, ob eine Leitung von links oder von rechts getrieben wird.
Warum muss das so? Jeder mechanische Schalter verbindet zwei Leitungen ohne was zu prüfen. Aus meiner Sicht ist das ein Problem des Benutzers wenn der gleichzeitig von beiden Seiten treibt.
Ich habe nach dem Studium (leider) fast nichts mehr mit FPGAs gemacht. Davor und Mittendrin aber recht viel und fand das Thema hier deshalb interessant. Ihr seit mir Meilenweit vorraus.
Was mich an allen hier etwas stört und weswegen antworte ich. Auf die wirklich einfache Frage des TOs die von Anfang an im Raum steht hat niemand "konkret" geantwortet.
Darauf ging bis jetzt KEINER ein. Aussage war dann: Bau es dir doch selber.
Klar kann man machen. In C ist es aber auch sinvoll Standardfunktionen zu nutzen die schon millionenfach getestet sind und nicht alles neu zu erfinden.
Weil mich das Interessiert hat. Habe ich nach Recherche folgendes gefunden:
https://www.fpga4student.com/2017/08/verilog-vs-vhdl-explain-by-example.html
"In fact, Verilog has built-in primitives or low-level logic gates so that designers can instantiate the primitives in Verilog code while VHDL does not have it."
Ich beschäftige mich oft mit der Simulation und Konvertierung
von obsoleten ICs, in denen Transmission Gates noch eine große Rolle
spielten.
Ich kann Dir keine Lösung für VHDL präsentieren; aber vielleicht hilft
Dir das folgende Verilog Lösung weiter? Die Umsetzung in VHDL sollte
keine Schwierigkeiten bereiten:
Im wesentlichen werden die zwei - durch EIN Transmission Gate - verbundenen
Busse aufgesplittet in jeweils einen Input und Output Pfad.
Ich denke das Beispiel erklärt sich von selbst - alles andere im Link?!
PS: Für kompliziertere Bus-Topologien funktioniert das nicht.
PPS: Ich habe noch irgendwo einen Artikel und Ausschnitt in einem Fachbuch,
wo eine recht aufwendige Lösung mit einer Statemachine zu dem Thema
enthalten ist - samt Nachweis der Korrektheit; bei Bedarf suche ich Dir
das raus.
Das du am process start nur die variablen aber nicht das until drinnen
hast.
"wait on A, B, I until thentime /= now;"
Das bewirkt, dass der Prozess durch die Signaländerungen, die er selbst produziert nicht nochmal feuert.
Das hat der TO in seinem Code durch den weiteren delta cycle "wait for 0 ns;" am Ende ersetzt, was imho auch die bessere Lösung ist, weil ohne Variable...
Sein Code müsste eigentlich schon funktionieren. Und das scheint er ja auch, wenn man seiner Simulation glaubt.
Er scheint jetzt nur das Problem zu haben, dass er Verilog durch VHDL ersetzt hat, was komplett anders simuliert wird und jetzt hat er im zusammenspiel mit verilog und anderen VHDL Komponenten irgendwo ein Delta-Cycle Problem. Das ist aber nicht ungewöhnlich und lösbar.
Das wäre mein Vorschlag:
Dann werden a und be gleich am afang mit z getrieben und man geht den Resolution Problemen des 'U's aus dem Weg.
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entitytgateis
5
port(
6
a:inoutstd_logic;
7
b:inoutstd_logic;
8
control:instd_logic);
9
endentitytgate;
10
11
architecturefunc_behavoftgateis
12
begin
13
14
p:processis
15
begin
16
A<='Z';
17
B<='Z';
18
waitfor0ns;
19
ifcontrol='1'then
20
A<=B;
21
B<=A;
22
waitfor0ns;
23
elsifcontrol='X'then
24
A<='X';
25
B<='X';
26
waitfor0ns;
27
endif;
28
waitonA,B,control;-- Alternativ durch sens Liste (a, b, control) ersetzen.
Warum muss das so? Jeder mechanische Schalter verbindet zwei Leitungen
ohne was zu prüfen. Aus meiner Sicht ist das ein Problem des Benutzers
wenn der gleichzeitig von beiden Seiten treibt.
Das Problem an deiner Lösung ist, dass sie auch nicht funktioniert, wenn man von aussen nur an einer Seite treibt, da das Modell von innen immer gegentreibt. Das funktioniert einmal und dann geht alles auf X bei jeder Signaländerung bis control, wieder auf 0 geht.
Das du am process start nur die variablen aber nicht das until drinnen
hast.
"wait on A, B, I until thentime /= now;"
Das bewirkt, dass der Prozess durch die Signaländerungen, die er selbst
produziert nicht nochmal feuert.
Das hat der TO in seinem Code durch den weiteren delta cycle "wait for 0
ns;" am Ende ersetzt, was imho auch die bessere Lösung ist, weil ohne
Variable...
Beim Zuweisen muss die Richtung exklusiv behandelt werden, daher ist zu
prüfen, ob eine Leitung von links oder von rechts getrieben wird.
Warum muss das so? Jeder mechanische Schalter verbindet zwei Leitungen
ohne was zu prüfen.
Weil das Problem hier eine Ebene höher gelagert ist: Es geht darum, das ein und dasselbe Element zweimal in unterschiedlicher Konfiguration benutzt wird, einmal links nach rechts und einmal rechts nach links schaltend.
Ein Draht ist immer da und arbeitet immer in beide Richtungen.
Im Fall "Draht" ist die Schaltung dementsprechend, dass sie damit funktioniert, folglich hat der Simulator kein Problem damit. Nur der User hat ein Problem, wenn er seine Simulation nicht richtig aufsetzt, oder die Schaltung so wäre, dass sie gegeneinander treibt.
Das ist hier aber nicht der Fall, sondern:
Der Benutzer möchte ein Bautteil, das er überall verbauen kann, obwohl das bidirektionale Schalten NICHT! von der Schaltung berücksichtig wird, weil es in der Praxis technisch nicht vorkommt. Oben kommt es funktionell nicht vor.
Man muss also zu einem Trick greifen und den Simulator befähigen, nur jeweils einen der formulierten Pfade zu verwenden, je nachdem wie rum das Signal an Ort und Stelle läuft. Wie er ja beschreibt, geht das nicht pauschal, weil die Gates mal so und mal so herum eingebaut worden sind.
Dieses (das Mitteilen was der Simulator machen soll) kann man wiederum dadurch, dass man:
a) die Formulierung so wählt, dass der Compiler den nicht benutzten Ast wegoptmiert, was man dadurch machen kann dass man die Bedingungen ausdrücklich setzt, oder die Sensitivity liste entsprechend schreibt
b) beide Pfade zwar drin bleiben, aber beim Ausführen dafür gesorgt wird, dass nur eine von beiden Richtungen aktiv bearbeitet wird. Also ein IF THEN mit Exklusiver Funktion.
Nein es ging um die sachliche Nachfrage, warum dieser Baustein nicht beim TE vorhanden ist. Ich möchte verstehen, wieso dieser einfache Mechanismus nicht angewendet wird. Zu meiner Zeit haben wir einfach eine Wahrheitstabelle aufgestellt, Mealy und Moore appliziert und damit automatisch rausbekommen, was zu tun ist.
Was mich an allen hier etwas stört und weswegen antworte ich. Auf die
wirklich einfache Frage des TOs die von Anfang an im Raum steht hat
niemand "konkret" geantwortet.
DOCH! Ich habe sehr genau beschrieben wie man das machen muss, wenn du das noch mal lesen möchtest. Ich beschrieb von Anfang an die doppellösung mit 2 Pfaden und getrenntem Input und Output. Und ich zog den Vergleich zu einem IO-Port in einem FPGA, wo das nämlich ganz genau so gemacht wird, / werden muss, um die beiden Fälle des a) von innen getriebenen Ausgangs und b) des von Außen, also von der Leitung getriebenen Ausgangs zu unterscheiden. Das braucht man überall, wo ein Port BIDIR ist.
Wenn man das natürlich überliest und ignoriert, dann ist diese "Wertung" deinerseits natürlich nachvollziehbar:
Im wesentlichen werden die zwei - durch EIN Transmission Gate -
verbundenen
Busse aufgesplittet in jeweils einen Input und Output Pfad.
So ist es. Und ich füge nochmal hinzu, dass es eben eine funktionielle und damit räumliche Trennung sein muss (mehrere Signale), im Gegensatz zur rein zeitlichen, wie bei einem Draht (ein Signal zu unterschiedlichen Zeiten getrieben)
Das hat der TO in seinem Code durch den weiteren delta cycle "wait for 0
ns;" am Ende ersetzt, was imho auch die bessere Lösung ist, weil ohne
Variable...
Sein Code müsste eigentlich schon funktionieren.
Ob er einen 0ps Delta oder eine echte Zeit einsetzt, ist egal. Solange er dafür sorgt, dass das einmal gesetzte Signal nicht zu einem erneuten Auslösen des Prozesses führt, um dann wieder rückgespeist zu werden, funktioniert beides.
Das aber muss per Bedingung passieren und geschieht eben nicht automatisch, weil der Compiler / Simulator nicht weiß, dass er nur einen Pfad verfolgen darf. Sonst hat man immer einen Kurzschluss. Einfach rückkoppen reicht also nicht. Das ist zwar das was in der Realität passiert, wenn die beiden Seiten getrieben würden, das würde dann aber fälschlich so simuliert, weil die Realität die ist, dass nur eine Seite getrieben wird.
Das ist hier die entscheidende Erkenntnis!
Als Folge muss man eben genau das abbilden, was dort passiert und kann nicht einfach auf etwas Vorhandenes zurückgreifen, ohne es entweder geschickt einschränkend zu nutzen oder es strukturell einschränkend umzu ändern.
Fazit:
Entweder baue ich die Tolologie exakt nach und ermittle händisch durch Abfragen der Bewegung der beiden Seiten, ob links-rechts oder die andere Richtung vorliegt, oder aber ich baue die gewünschte Funktion einfach per Wahrheitstabelle nach, in der ich exklusiv nur die Fälle behandle, die nötig sind und die anderen, die es bei einem Draht gibt, weglasse.
Wenn man das nicht im Nachhinein reinschmeißen müsste, weil es verbummelt wurde, vorzusehen und alles in einer Richtung gebaut wäre, dann würde man es wenn man das selber in der Hand hätte wohl mit einem GENERATE lösen. Das ist -> Gustl , auch eine "Ebene" höher und baut nur das, was gebraucht wird.
Selber bauen
Das Entscheidende ist, dass man selber denkt. :-)
Wenn das Nutzen von Simulatoren im Bezug auf komplizierte Strukturen ein Problem ist, dann eben bitte einfach mal ein Buch nehmen. Es ist ja nicht so, dass das Wissen nicht vorhanden wäre. Leider lese ich hier aber immer wider von "Ich habe länger nichts mehr mit FPGAs gemacht, aber habe folgende Idee" und "Ich habe das bbisher so und so gemacht, und deshalb folgende Meinung".
Mir scheint das ein Generationenproblem zu sein. Zuviel facebook-Argumentation. Hat man verlernt Bücher zu benutzen? Ich hatte oben Literatur angeführt. Einfach mal Buch gucken. :-)
Gerade mit dem geschickten Nutzen der Sensitivity-Liste kann man sehr komplexe Signalzüge entwickeln und sehr einfach auch absolut komplizierte Abläufe zwischen zwei Datenverarbeitern abbilden. Man denke mal an Busse, mit mehr als drei Teilnehmern ... der "dritte Mann" will dann auch noch mitmischen ...
Hausaufgabe für die Experten:
Man definiere das digitale Modell eines Pull-up-Widerstandes und dessen Funktion in einer digitalen Schaltung.
Lösung: Der Widerstand hat 2 Ein- und Ausgänge "schaut nach", ob das Signal getrieben wird, um dann zu entscheiden, ob er ein nicht getriebenes Signal nach 1ps selber treiben muss oder nicht und in welche Richtung. Sobald von vorne oder hinten (der R ist ja nur der "dritte Mann" und das Signal selber hat schon zwei Teilnehmer) getrieben wird, schaltet der Widerstand das Signal des Treibers durch. Damit gibt es keine "1"+"Z"-Kollision, die vom Model nicht verarbeitet werden konnte.
Bei gegenläufigem Treiben, definiert er gemäß seiner "Kraft" ob er treibt oder nicht, je nachdem wie die Ausgänge stomtechnisch treiben. Damit ist sogar der Fehlerfall abbildbar, der in diesem Fall vorkommen durfte und der Simulator meckert nicht einfach mit "X" sondern liefert eine Lösung.
Damit braucht so man keine Analogsimulation und packt es in hohem Tempo mit ModelSim.
DOCH! Ich habe sehr genau beschrieben wie man das machen muss, wenn du
das noch mal lesen möchtest. Ich beschrieb von Anfang an die
doppellösung mit 2 Pfaden und getrenntem Input und Output.
Ehrlich gesagt verstehe ich das gerade selber auch nicht. Was genau meinst du? Ein Modell was statt einem inout auf beiden Seiten 2 Ports in und out hat? Zumindest verstehe ich das so, was aber an dieser Stelle ja nicht einsetzbar ist.
Ich kann deinen Ausführungen selbst nicht folgen fürchte ich. Ich habe damit folgendes Problem:
Da das Modul ja grundsätzlich in beide Richtungen raustreiben können muss, baut mir der Simulator auch an jeden Port einen Treiber ein. Damit ich aber "unbehelligt" den Zustand von aussen einlesen kann, muss ich selbst ein 'Z' treiben, damit mir der Wert nicht durch die Resolution kaputt gemacht wird.
Sobald da einmal was durchgelaufen ist, liest das Gate ja das was es selbst geschrieben hat wieder ein bzw die entsprechnede Resolution auf dem entsprechenden Port. Somit kann ich nicht durch reine kombinatorische Lookups einen Ausgangswert ableiten. Ich muss doch durch einfügen von Delta Cycles erst den Knoten an den Signalen unterbrechen:
Der TO hat das ja jetzt offenbar so gelöst mit Hilfe des Beitrags vom Herrn Miller, dass er erkennt, wenn etwas passiert (wait on). Dann setzt er das Gate auf 'Z' und löst ein Delta delay aus. Dadurch wird der Simulator die Input ports auflösen und man bekommt die reinen Werte, die von aussen kommen, da alles mit Z verknüpft sich selbst ergibt. Dann wird a nach b und b nach a getrieben und ein weiterer Delta cycle ausgelöst, um alles an den Ports zu resolven und drauf nicht nochmal selbst zu triggern.
Nein es ging um die sachliche Nachfrage, warum dieser Baustein nicht
beim TE vorhanden ist.
In welcher Library soll er nachschauen? So wie ich das verstanden habe, haben die das Gate selbst gelayoutet, was nicht unüblich ist. Vorallem, wenn es beengt ist, wie er geschrieben hatte. Es gab bereits das rtranif1 basierte Verilog Modell, dass er ja mitgeliefert hatte. Er hatte, soweit ich das jetzt sehe, einfach nur gefragt, wie man das bestehende Verilog durch ein VHDL ersetzen könnte, weil ihm VHDL besser gefalle.
Und anstatt ihm eine Lösung zu vermitteln, sprich mit einem Beispiel, wurde ihm alles an den Kopf geworfen bis hin zur absoluten Unfähigkeit. Ich selbst bin auch kein VHDL-Experte und konnte mit deinen Ausführungen ehrlich gesagt auch nicht viel anfangen. Ich habe damit noch nie etwas gemacht, was rein simulativ war. Sprich ausschliesslich RTL. Somit kenne ich viele Teile der Sprache selbst auch nicht, weil ich diese nie gebraucht habe. UAs deiner Beschreiung wäre ich jetzt spontan auch nicht fähig etwas zu schreiben. Wenn es nicht viel ist, kannst du das ja selbst mal als Beispiel zeigen. Warum hast du das bisher nicht einfach gemacht, da du offenbar, und das ist ehrlich gemeint, durchaus Ahnung besitzt? Es wäre mir zu aufwendig gewesen das alles 5 mal zu erzählen :)
Aber jetzt scheint man ja eine Lösung zu haben. Ich habe das obige RTL selbst mal mit xcelium simuliert und es scheint zu tun im Simulator. Ich fürchte nur, dass ihm das in seiner Anwendung nichts bringt, weil er ja das Ganze irgendwie dem Pattern-Generator eines Synopsys DfT Flows vermitteln möchte und keine Simulation im Simulator machen will. Da würde ich persönlich grundsätzlich auf Verilog setzen. Das haben die Tools einfach besser auf dem Schirm und man wird vom Support nicht mit grossen Augen angeschaut.
EDIT: Abgesehen von dem sinnlosen hin und her, hat mir selbst dieser Thread jetzt auf jeden Fall auch noch gefallen. Ich habe wieder etwas neues gelernt bezüglich VHDL und delta cycles.
Die Antwort: Mir ist keine Lösung in VHDL bekannt, die exakt die Verilog Primitive nachbilden würde.
Mit Verlaub, ich würde mir das nicht antun, eine funktionierende Verilog Lösung durch VHDL zu ersetzen, nur weil mir die Sprache besser gefällt. Spyglass hast du ja offenbar eh schon in der Werkzeugkiste, und mir bekannte Verilog Compiler geben einige Hinweise, wie z.B. unterschiedliche Portbreiten, als Warnung aus.
Die subtilen Unterschiede beider Sprachen im jeweiligen Zeitmodell hast du ja bereits erwähnt. Es müssen zwangsläufig Informationen zwischen den beiden Enden des TG ausgetauscht werden, was stets irgendwelche Delta-Zyklen zur Folge haben muss. Die Gefahr, sich irgendwelche subtilen Fehler einzuhandeln, ist einfach zu groß.
In der mit dem Simulationsmodellen für die standard cells wie transmission gate und line driver.
So wie ich das verstanden habe,
haben die das Gate selbst gelayoutet, was nicht unüblich ist.
Im Gegenteil, 'full custom' ist nicht zuletzt wegen der hohen NRE-Costs und langen Durchlaufzeiten von mehrerern Wochen sehr unüblich. Und selbst wenn hier maßgeschneiderte Silizumlandschaften gemalt wurden, muss dafür auch ein passendess behavioral Simulationsmodell mitgegeben werden. Weil, mixed signal simulation wie auf die erste Aufgabenbeschreibung des TO erforderlich vorgeschlagen, mag ja der TO nicht.
Das macht eigentlich nur die Fab selbst, weil nur die Fab die Prozess-parameter kennen, deren Beachtung beim "Layout" essentiell für den yield ist.
Allein die Verwendung des gleichen Begriffs "Layout" für zwei unterschiedliche Entwurfsprozesse (Masken/Dotierungsprofilerstellung für IC-Lithographie versus PCB copper track routing) grenzt schon an sträflicher "Verharmlosung".
Kann ich ein Verilog "rtranif1" Intrinsic auch irgendwie in VHDL
abbilden?
Grundsätzlich kann man alles in VHDL übersetzen, oft auch automatisch.
Die Infragestellung meinerseits, wozu das im FPGA-Forum gepostet wird, bezog sich darauf, dass du behauptest, keinen FPGA zu haben.
Aber alle wollen ja immer
wissen wofür, obwohl das nicht von Belang ist.
Ich finde es schon interessant. Du wirst ja einen Grund haben.
Wenn du eine Komponente schon in Verilog hast, brauchst du sie nicht in VHDL - es sei denn, es wäre intern vorgeschrieben, nur VHDL zu benutzen. Das ist bei meinem Kunden z.B. der Fall.
Aber alle wollen ja immer
wissen wofür, obwohl das nicht von Belang ist.
Ich finde es schon interessant. Du wirst ja einen Grund haben.
Wenn du eine Komponente schon in Verilog hast, brauchst du sie nicht in
VHDL - es sei denn, es wäre intern vorgeschrieben, nur VHDL zu benutzen.
Das ist bei meinem Kunden z.B. der Fall.
Naja der TO hat hier ne reichlich schizophren anmutende Argumentationsweise benutzt.
Erst fordert er nach einem VHDL-Ersatz von Verilog und wenn man ihn dann einen liefert heisst es, das das nicht nach Verilog ausschaut. So ganz nach dem Motte "Wasch mich, aber mach mich nicht naß."
Meine Frage war konkret: Gibt es eine Möglichkeit das Timing eines
Moduls auf seiner Entity Basis, ohne das darin enthaltene VHDL zu
simulieren, zu annotieren.
Sämtliche Timing Flows, fangen nämlich mit delays in den Modulen, weder
bei Verilog noch bei VHDL etwas an. In Verilog kann ich beispielsweise
schreiben:
Also VHDL schreiben ohne VHDL zu simulieren. Und ein Verilog geschriebenes Beispiel, wie man ohne Verilog auskommt... Dunkel wars, der Mond schien helle ...
Worüber man doch in der Anfangszeit der Simulation auf breiter Front doch so alles ein paper machen konnte ... ich bin entzückt. Wir haben uns 1991 als Teil des Studiums solche Sachen im Rahmen des Digitaltechnikpraktikums ausgedacht und in die Sun Workstation gestopft. Das wurde einfach als Standes der Technik angesehen. Hätten wir auch papers machen sollen?
Zum Inhalt: Der entscheidende Satz ist "what do we want to model". Das dort ist nicht ganz die Aufgabe, die hier ansteht, wodurch sich der reale Aufwand doch erheblich verkürzen sollte. Aber egal ...
... neu war das alte Verilog,
als ein ASIC rasend schnelle -
langsam um die Ecke bog
Die Oberfläche matt und blitzend -
mit Alu plastisch metallisiert -
wurde er durch organisiertes Scrum
von beginnenden Experten simuliert.
Die Sprache war das leichte Schwere
eine Lösung überall und nirgends
im kleinen Internet war große Leere
und scheinbar niemand bringt es ...
Zu modellieren den lahmen Treiber
(der Ingenieur war längst im Bett)
saßen laufend neue Schreiber
im Mikrocontroller nett.
Achtung: Wechsel der Reimform "Transmission-Göth":
Der Entwickler baute, so schnell wie es geht
simuliert das transmittierende, ächzende Gate-
das Layout erreicht die Fab mit Mühe und Not;
doch der ASIC in seiner Schaltung war tot.
Naja der TO hat hier ne reichlich schizophren anmutende
Argumentationsweise benutzt.
Erst fordert er nach einem VHDL-Ersatz von Verilog und wenn man ihn dann
einen liefert heisst es, das das nicht nach Verilog ausschaut. So ganz
nach dem Motte "Wasch mich, aber mach mich nicht naß."
Ja. Das habe ich wohl, weil für mich nicht nur die reine Simulierbarkeit im Vordergrund steht, sondern auch, dass gewisse Asic Toolflows das korrekt erkennen müssen. Da stößt man leider oft auf Verilog-only Geschichten.
Aus anderen Gründen ist hier jetzt im Endeffekt gar keine VHDL Läsung möglich, weil ein anderes, intern entwickeltes Tool, an dieser Stelle Verilog erfordert, weil das auch kein VHDL kann.
In der mit dem Simulationsmodellen für die standard cells wie
transmission gate und line driver.
So wie ich das verstanden habe,
haben die das Gate selbst gelayoutet, was nicht unüblich ist.
Im Gegenteil, 'full custom' ist nicht zuletzt wegen der hohen NRE-Costs
und langen Durchlaufzeiten von mehrerern Wochen sehr unüblich. Und
selbst wenn hier maßgeschneiderte Silizumlandschaften gemalt wurden,
muss dafür auch ein passendess behavioral Simulationsmodell mitgegeben
werden. Weil, mixed signal simulation wie auf die erste
Aufgabenbeschreibung des TO erforderlich vorgeschlagen, mag ja der TO
nicht.
Aber genau so ist es. Es handelt sich um ein Full custom design.
Allein die Verwendung des gleichen Begriffs "Layout" für zwei
unterschiedliche Entwurfsprozesse (Masken/Dotierungsprofilerstellung für
IC-Lithographie versus PCB copper track routing) grenzt schon an
sträflicher "Verharmlosung".
Sind beides mal nur Formen, die man in lustigen Farben übereinander malt ;)
Das macht eigentlich nur die Fab selbst, weil nur die Fab die
Prozess-parameter kennen, deren Beachtung beim "Layout" essentiell für
den yield ist.
Das ist falsch. Es gibt hier grundsätzlich zwei Seiten. Zum einen das Digitaldesign: Da stimmt deine Aussage soweit. Für eine bestimmte Technologie, bekommst du von der Fab einen Standardzellensatz für bspw. Synopsys Tools. Sprich die Beschreibungen für die Synthese inklusive Timing Daten und die layouts bzw die lef files (Essentiell nur eine blackbox mit infos, wie groß die Zelle ist und wo die Pins hängen. Ist einfacher zu jonglieren, als immer die vollen Zellen rumzuschleppen.)
Der digitale Haufen wird dann topografisch synthetisiert ( bspw mit Synopsys DCNXT). Die entstehende Netzliste aus Standardgattern wird dann vom Place and Route Flow (bspw. Synopsys IC Compiler) gemäß eines vorher definierten Floorplans geroutet.
Wie du bereits anmerktest, sind hier hohe Runtimed von Wochen und manuelle Nacharbeit im Layout nicht unüblich. Am Ende hat man dann alles was man für digital braucht: Netzliste, Timing Daten, Layout, Schaltplan.
Für das analog Design sieht es anders aus. Das macht definitiv nicht nur die Fab. Der Hersteller liefert dir ein PDK ( Process Design Kit) für Cadence Virtuoso. Dieses enthält alles, womit dich der Hersteller unterstützen kann. Sprich Transistormodelle, vorgefertigte Standadzellen, wie bandgap referenzen, temperatursensoren und solche Dinge. Im optimalfall sind dann noch für alle Modelle die entsprechenden Streuungen für Monte Carlo Simulation hinterlegt. Fabs wie TSMC, GF, aber auch TI und ST haben von aööen eingefahreren Prozessen top-notch Modelle und Daten. So ein PDK ist schnell auch mal hunderte Gigabyte groß und mit viel Schmerzen und DOEs auf Herstellerseite erstellt worden.
Aber mit diesem PDK ist es möglich beliebige Dinge selbst zu bauen. Transistormodelle sind bspw nicht fix, sondern sind parametrisierbar in gewissen Grenzen. Bspw, ist für jeden Transistor eine Gate Länge und Weite einstellbar. Das Modell passt sich bei der Simulation an die eingegebenen Werte an. Ebenso kann Virtuoso daraus ein entsprechendes Layout generieren.
Es wäre tatsächlich auch möglich den Transistor im Layout roh von Hand mitteös Polygonen in den entsprechenden Layern zu zeichnen. Der Layout vs Schematic (LVS) flow von virtuoso würde diesen dann automatisch erkennen und gegen den Schaltplan prüfen. Es erkennt quasi vereinfacht: Wenn polysilizium eine p diffusion kreuzt, dann ist da ein N-Kanal Transistorgate. Und dann schait er, ob er das irgendwie im Schaltplan matchen kann. Ebenso wird natürlich auf DRC Regeln geprüft. Ähnlich wie beim PCB design.
Siehe den obigen screenshot des schaltplans. Darin stehen in Orange die gateweiten und Längen der Transistoren bspw. drin.
In diesem Fall ist es tatsächlich so, dass das Transmission Gate besonders klein ist und im Schaltplan aus 2 kleinen Transistoren mit geringer Gateweite zusammengebaut wurde. Aber für die Anwendung reicht es, weil an dieser Stelle nur wenige hundert Nanometer zwischen zwei Schaltungsblöcken frei sind um mehrere dieser Gates zu platzieren.
Für eine AMS Simulation, die du mir ja immerwieder andrehen willst, reichen die Transistormodelle des PDKs aus. Diese kann der Analogsimulator korrekt simulieren. Es ist also nicht notwendig das Gate separat zu modellieren um es in einer mixed Signal simulation zu verwenden. Nachdem das Layout fertig ist, wird dann in aller Regel noch die Parasitenextraktion gemacht und der Schaltplan wird automatisch mit parasitären Kapazitäten und Widerständen aufgebohrt. Damit kann man dann sehr gut arbeiten.
Es war nur nötig eine rein digitale funktionale (ohne delay ohne alles) Beschreibung dafür zu haben, weil der manuell aus polygonen zusammengelayoutete Pfad im scan Pfad der Logik liegt. Sprich, beim scan testing der digitallogik, wird dieser pfad mitbespaßt. Damit das Tooling, das die Scanpatterns generiert, weiß, was da in diesem Pfad abgeht, wird dieses Modell benötigt. Ich hatte da jetzt keinen Zugzwang, da ja ein Verilog modell mit rtranif1 existiert, weil ich es ja selbst getippselt habe.. Ich finde aber persönlich VHDLsympathischer und lote in unseren Prozessen gerne aus, wie weit man da mit VHDL kommt. Und da ich spontan nocht in der Lage war, ein VHDL Modul zu schreiben, was das tat, habe ich nachgefragt.
Es war nur nötig eine rein digitale funktionale (ohne delay ohne alles)
Beschreibung dafür zu haben, weil der manuell aus polygonen
zusammengelayoutete Pfad im scan Pfad der Logik liegt.
Du meinst hier den Prüfpfad zum Test in der Herstellung oder den späteren Pfad zum Test im PCB mit JTAG?
Und da reicht ein reines Schaltermodel?? Da sind doch Taktzeiten wichtig, die eingehalten werden müssen. Wer prüft die im Herstellungsprozess?
Es war nur nötig eine rein digitale funktionale (ohne delay ohne alles)
Beschreibung dafür zu haben, weil der manuell aus polygonen
zusammengelayoutete Pfad im scan Pfad der Logik liegt.
Du meinst hier den Prüfpfad zum Test in der Herstellung oder den
späteren Pfad zum Test im PCB mit JTAG?
Und da reicht ein reines Schaltermodel?? Da sind doch Taktzeiten
wichtig, die eingehalten werden müssen. Wer prüft die im
Herstellungsprozess?
Um die Frage noch zu beantworten:
Es handelt sich um den Test in der Produktion.
Es reicht ein reines Schaltermodell. Mit dem Hintergrund: Die Scan Ketten werden auf rein funktionaler Sicht ohne delays analysiert und zusammengestöpselt. Da hat bspw Synopsys die test MAX / Tetra MAx tools. Für die generierung der Scan PAtterns ist ein Delay ja auch gar nicht wichtig.
Das Timing wird separat, bei uns mittels primetime (weiteres komplett getrenntes synopsys tool) analysiert. Das lädt dann von allen Komponenten die Timing Informationen und prüft die Pfade.
Dafür muss in dem Schaltermodell kein Timing beschrieben sein. Primetime lädt ausschließlich die Netzliste und die dazugehörigen Delay-Modelle.
Das delay-Modell eines solchen Trasnmission Gates wird bspw. mittels eines Cadence liberate flows erzeugt. Dazu fährt das Tool die Zelle automatisiert ab und macht analoge Simulationen um daraus ein NLDM (non linear delay modell) zu schreiben. Das kann dann über 2 Ecken wieder in ein Synopsys db file konvertiert werden und wandert so in die Timing-Analyse.
Auf diese Weise kommen dann zum Beispiel auch die Leitungen mit rein. Die werden wieder getrennt über eine Parasiten-Extraktion (bspw. mit einem Cadence Tool) und die entsprechenden TLUplus Modelle herausgeschrieben und finden dann auch ihren Weg in die Timing Analyse.
tswitch.png
(2,1 KB)
