VHDL bidirektionalen Switch modellieren

[M. Н. (Gast)]

Guten Tag,

ich suche nach einer Möglichkeit einen bidirektionalen Switch in VHDL zu 
beschreiben.

In (System)Verilog würde ich bspw. für einen passiven Schalter Folgendes 
schreiben:

module tswitch (
    input control,
    inout a,
    inout b
);
    
    rtranif1(a, b, control);
endmodule

Was (siehe screenshot) auch vom simulator korrekt erkannt und umgesetzt 
wird.

Meine Frage ist nun: Gibt es eine Möglichkeit einen solchen 
bidirektionalen switch auch in VHDL zu beschreiben? Ich habe irgendwie 
nichts gefunden.

[Klaus K. (Gast)]

Erster Rückfrage, wozu brauchste das?

Für Simulation i.e. bidirektional externer Levelshifterist bidirektional 
OK, für SFPGA-Synthese eher nicht.

Zweite Rückfrage, welche VHDL version?

der klassische Weg geht über das keyword null ("Null transactions") zum 
signal driver ausschaulten, neuerer versionen unterstützen "disconnect".

[M. Н. (Gast)]

Klaus K. schrieb:
> wozu brauchste das?

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.

Klaus K. schrieb:
> Zweite Rückfrage, welche VHDL version?

Am liebsten 93... Neuere Versionen sind immer mit Vorsicht zu 
genießen...

Ich werde vermutlich aber einfach auf Verilog setzen. Eine VHDL Lösung 
würde mich aber aus Interesse trotzdem interessieren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

M. H. schrieb:
> Gibt es eine Möglichkeit einen solchen bidirektionalen switch auch in
> VHDL zu beschreiben?
Meine Versuche sehen so aus:
- http://www.lothar-miller.de/s9y/archives/91-Schalter-und-Bruecke.html

Allerdings tut sich mancher Simulator damit unverhofft schwer und der 
Synthesizer kann damit eh' nichts anfangen.

Wofür brauchst du sowas denn überhaupt?

[M. Н. (Gast)]

Lothar M. schrieb:
> Wofür brauchst du sowas denn überhaupt?

M. H. schrieb:
> 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

module my_special_via(
    inout a,
    inout b
);
    tran(a, b);
endmodule

[Klaus K. (Gast)]

> 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.

[J. S. (engineer)]

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.

[Rick D. (rickdangerus)]

M. H. schrieb:
> Am liebsten 93...
Warum nicht mit VHDL 1903?

> Neuere Versionen sind immer mit Vorsicht zu
> genießen...
Aha. Der letzte VHDL-Standard ist von 2008. Den sollten nach 15 Jahren 
die Tools beherrschen.

(Im Vergleich dazu ist der letzte C++-Standard von 2020...)

[M. Н. (Gast)]

Es ist immer wieder schön zu sehen, wie hier anstatt das Problem zu 
diskutieren irgendwelcher Mist im Kreis getrieben wird :)

Lediglich von Lothar kam ein sinnvoller Beitrag (und sogar mit einer 
Lösung. Nochmals danke dafür.)

J. S. schrieb:
> Ich nehme an, das so etwas
> simuliert werden soll?

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.

J. S. schrieb:
> Meistens sind diese
> Validierungen eigentlich durch reale Tests im FPGA abgedeckt.
Ich habe keinen FPGA...

J. S. schrieb:
> 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.

Klaus K. schrieb:
> Die meisten
> Halbleiterstrukturen vertragen es auf Dauer auch nicht, mit einem
> negativen Potential beaufschlagt zu werden.

Kennst du meinen Schaltplan?

Klaus K. schrieb:
> 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:
1) 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.

2) 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.

[Andreas U. (Gast)]

M. H. schrieb:
>> Meistens sind diese
>> Validierungen eigentlich durch reale Tests im FPGA abgedeckt.
> Ich habe keinen FPGA...

Du hast keinen FPGA und schreibst im FPGA-Forum?
Warum VHDL?

Aha, hier steht es:

M. H. schrieb:
> 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.

[M. Н. (Gast)]

Andi F. schrieb:
> 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.

Andi F. schrieb:
> 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.

Andi F. schrieb:
> Du könntest es in pSpice machen.

Könnte ich. Üblicherweise wird aber in einem Separaten run alles was 
analog designt ist, aber nur digital benutzt wird durch einen "Liberate 
Flow" automatisch charakterisiert und ein delay annotiertes Modell (lib 
file) automatisch erzeugt. Bspw: 
https://www.cadence.com/en_US/home/tools/custom-ic-analog-rf-design/library-characterization/liberate-trio-characterization-suite.html

[Rick D. (rickdangerus)]

M. H. schrieb:
> 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...

[M. Н. (Gast)]

Rick D. schrieb:
> M. H. schrieb:
>> 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.

[J. S. (engineer)]

Man kann das durchaus in VHDL forumilieren und ich habe oben auch 
detailliert beschrieben wie. Es kommt auf den Fokus an, den man hat:

1) 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".

2) 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.

[Klaus K. (Gast)]

> 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.

> 1) 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.

[M. Н. (Gast)]

Klaus K. schrieb:
> 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.

Klaus K. schrieb:
>> 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.

Klaus K. schrieb:
> 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.

Klaus K. schrieb:
> 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.

[M. Н. (Gast)]

Glücklicherweise habe ich im Internet einen Virtuoso Schaltplan eines 
Transmission Gates gefunden, damit ich das mal zeigen kann. Siehe Anhang 
oder 
(https://cmosedu.com/jbaker/courses/ee421L/f16/students/deignank/proj/proj.htm).

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.

[J. S. (engineer)]

Klaus K. schrieb:
> Und für Asic wurde schon vor 30 Jahren die "VHDL Initiative Towards ASIC
> Libraries",  kurz VITAL (IEEE 1076.4) erfunden.

... hinsichlich derer man die Kompatibilität seines Codes beim 
Compilieren testen lassen kann.-> "check Vital" beim ModelSim.

M. H. schrieb:
> 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.

M. H. schrieb:
> 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.

[M. Н. (Gast)]

J. S. schrieb:
> 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.

Und ich erkläre es dir jetzt nochmal zum

Ersten:

M. H. schrieb:
> 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?*

zweiten:

M. H. schrieb:
> 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

library ieee;
use ieee.std_logic_1164.all;

entity tgate is
    port (
        a       : in  std_logic;
        b       : out  std_logic;
        control : in std_logic);
end entity tgate;

architecture func_behav of tgate is

begin     
    b <= a when control = '1' else 'Z';
end architecture func_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:

module tswitch (
    input control,
    inout a,
    inout b
);
    rtranif1(a, b, control);
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.

[M. Н. (Gast)]

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.

[J. S. (engineer)]

M. H. schrieb:
> Und ich erkläre es dir jetzt nochmal zum
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?

M. H. schrieb:
> 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.


> oder ob VHDL dafür einfach ein level zu hoch ist
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.

M. H. schrieb:
> 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.

[M. Н. (Gast)]

J. S. schrieb:
> M. H. schrieb:
>> Und ich erkläre es dir jetzt nochmal zum
> 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...

J. S. schrieb:
>> 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?

J. S. schrieb:
> M. H. schrieb:
>> 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:
> 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:

p: process is
begin
    wait on A, B, control;
    A <= 'Z';
    B <= 'Z';
    wait for 0 ns;
    if control = '1' then
      A <= B;
      B <= A;
      wait for 0 ns;
    end if;
end process p;

[Klaus K. (Gast)]

> Die letzten 20 Posts ignorieren wir mal.

> Das folgende bringt leider nicht die erhoffte Lösung:
>

> p: process is
> begin

> end process p;
>

(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.

[M. Н. (Gast)]

Klaus K. schrieb:
> (1) Code bitte vollständig (hier fehlt signaldeklaration und
> Bibliothekseinbindung) und auch als file im Anhang posten.

Bitte sehr. Siehe Anhang.

Klaus K. schrieb:
> 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.

Klaus K. schrieb:
> 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.

Klaus K. schrieb:
> (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.

Klaus K. schrieb:
> dann bleib
> bei Verilog
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.

[Klaus K. (Gast)]

M. H. schrieb:
> 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.

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.

[Gustl B. (-gb-)]

a <= b when control = '1' else 'Z';
b <= a when control = '1' else 'Z';

Lässt sich wunderbar synthetisieren und funktioniert sogar innerhalb des 
FPGA also ohne echte Tristate Treiber.

[M. Н. (Gast)]

Klaus K. schrieb:
> 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:

`celldefine
module my_weird_asymmetric_and_gate(
  input in_a;
  input in_b;
  output o);

  specify
    (in_a => o) = 2;
    (in_b => o) = 4;
  endspecify
  
  assign o = in_a & in_b;

endmodule
`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.

[Gustl B. (-gb-)]

Soll natürlich

a <= b when control = '1' else 'Z';
b <= a when control = '0' else 'Z';

so sein.

[M. Н. (Gast)]

Gustl B. schrieb:
> Soll natürlich
>
> 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.

[Gustl B. (-gb-)]

M. H. schrieb:
> Das ist leider nicht das was ich brauche.

Dann nimm doch das was ich zuerst geschrieben hatte:

a <= b when control = '1' else 'Z';
b <= a when control = '1' else 'Z';

[M. Н. (Gast)]

Gustl B. schrieb:
> 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.

[J. S. (engineer)]

Gustl B. schrieb:
> a <= b when control = '1' else 'Z';
> b <= a when control = '1' else 'Z';
>
> Lässt sich wunderbar synthetisieren
Macht aber eine Rückkopplung.

Gustl B. schrieb:
> Soll natürlich
>
> a <= b when control = '1' else 'Z';
> b <= a when control = '0' else 'Z';
>
> so sein.
Das ist aber von der Schaltung nicht richtig. (?)

M. Н. schrieb:
> 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?

[Elvan M. (juuker)]

J. S. schrieb:
> 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.

M. Н. schrieb:
> Bitte sehr. Siehe Anhang.

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.

M. Н. schrieb:
> Tetramax

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.

[Gustl B. (gustl_b)]

J. S. schrieb:
> Gustl B. schrieb:
>> a <= b when control = '1' else 'Z';
>> b <= a when control = '1' else 'Z';
>> Lässt sich wunderbar synthetisieren
>
> Macht aber eine Rückkopplung.

Ja und?

J. S. schrieb:
> 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.

[John-eric K. (mockup)]

Moin.

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.

Die Frage ist in meinen Augen von Anfang an:
Gibt es für die Verilog Built-in Primitives wie rtranif1 ein VHDL 
Ersatz?
https://peterfab.com/ref/verilog/verilog_renerta/mobile/source/vrg00003.htm

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."

Zum Problem:
Ich habe keinen Plan, mir fiel aber auf:
Bei deinem Beispiel:
https://www.mikrocontroller.net/attachment/614111/tgate.vhd
Lothars:
http://www.lothar-miller.de/s9y/archives/91-Schalter-und-Bruecke.html
und dem von Lothar verlinktem:
http://systemverilog.us/zohm0_ea.vhd

Das du am process start nur die variablen aber nicht das until drinnen 
hast.
"wait on A, B, I until thentime /= now;"
Was auch immer das bewirkt.

[F. W. (frank_w21)]

@M.H.

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:

https://groups.google.com/g/comp.lang.verilog/c/KC8csRM1dS0

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.

[Elvan M. (juuker)]

John-eric K. schrieb:
> 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.

library ieee;
use ieee.std_logic_1164.all;

entity tgate is
    port (
        a       : inout std_logic;
        b       : inout std_logic;
        control : in    std_logic);
end entity tgate;

architecture func_behav of tgate is
begin

    p : process is
    begin
        A <= 'Z';
        B <= 'Z';
        wait for 0 ns; 
        if control = '1' then
            A <= B;
            B <= A;
            wait for 0 ns;
        elsif control = 'X' then
            A <= 'X';
            B <= 'X';
            wait for 0 ns;
        end if;
        wait on A, B, control; -- Alternativ durch sens Liste (a, b, control) ersetzen.
    end process p;

end architecture func_behav;

Gustl B. schrieb:
> 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.

[John-eric K. (mockup)]

Elvan M. schrieb:
> John-eric K. schrieb:
>> 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...

Danke für die Erklärung.

[J. S. (engineer)]

Gustl B. schrieb:
> J. S. schrieb:
>> 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.

[J. S. (engineer)]

Elvan M. schrieb:
> Muss hier immer gepöbelt werden?

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.

John-eric K. schrieb:
> 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:

John-eric K. schrieb:
> Darauf ging bis jetzt KEINER ein.
Falsche Aussage. Ich habe genau erklärt, was man machen muss.
1) Nachgucken in der LIB des Herstellers oder
2) Nachgucken bei FPGA Ports oder
3) Selberbauen durch Wahrheitstabelle

Lies meine Beiträge und du wirst das finden.

[J. S. (engineer)]

... du wirst dann auch das hier finden:

F. W. schrieb:
> 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)

Elvan M. schrieb:
> 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.

[J. S. (engineer)]

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.

[Elvan M. (juuker)]

J. S. schrieb:
> 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.

J. S. schrieb:
> Nachgucken in der LIB des Herstellers oder

J. S. schrieb:
> 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.

[Marcus H. (mharnisch)]

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ß.

[Klaus K. (Gast)]

> J. S. schrieb:
>> Nachgucken in der LIB des Herstellers oder
>
> In welcher Library soll er nachschauen?

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.

https://en.wikipedia.org/wiki/Full_custom
https://en.wikipedia.org/wiki/Application-specific_integrated_circuit

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".

https://personalpages.hs-kempten.de/~vollratj/Microelectronics/2017_04_24_06_Micro_DesignRules.html

[Andreas U. (Gast)]

M. Н. schrieb:
> *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.

[Klaus K. (Gast)]

A. F. schrieb:
> M. Н. schrieb:

>> 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 ...

[F. W. (frank_w21)]

So... hier noch das ver- bzw. besprochene Paper.

[Klaus K. (Gast)]

F. W. schrieb:
> So... hier noch das ver- bzw. besprochene Paper.

Soso, von 1989, also 4 Jahre vor Einführung des Typs std_logic 
(mehrwertige Logic mit tristate Zustand 'Z') in den VHDL - 
Sprachgebrauch ... .

[J. S. (engineer)]

F. W. schrieb:
> hier noch das ver- bzw. besprochene Paper.

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 ...


Klaus K. schrieb:
> Dunkel wars, der Mond schien helle ...
... 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.

[M. N. (bmbl2)]

Klaus K. schrieb:
> 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.

J. S. schrieb:
> ... neu war das alte Verilog,
> als ein ASIC rasend schnelle -
> langsam um die Ecke bog
> ...

Sehr schön :). Gefällt mir. Werde mir das abspeichern.

Bis auf das mit dem Alu... Das ist schon ne Weile out bei den meisten 
Prozessen.

Klaus K. schrieb:
>> J. S. schrieb:
>>> Nachgucken in der LIB des Herstellers oder
>>
>> In welcher Library soll er nachschauen?
>
> 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.

Klaus K. schrieb:
> 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 
;)

Klaus K. schrieb:
> 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.

[Andreas U. (Gast)]

M. H. schrieb:
> 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?

[M. N. (bmbl2)]

A. F. schrieb:
>> 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.

https://www.synopsys.com/implementation-and-signoff/test-automation/testmax-dft.html

Dem Ding sind Timings vollkommen egal.

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.

[Andreas U. (Gast)]

M. N. schrieb:
> Um die Frage noch zu beantworten:

Danke, sehr informativ!