Hallo Community,
die Frage mag jetzt vielleicht etwas laienhaft sein...
Ist es eigentlich möglich einen Hochgeschwindigkeit-Oszillator in VHDL
ohne die Verwendung von internen oder externen Oszillatoren zu machen?
Also mit der maximalen Schaltgeschwindigkeit (Umschaltung/Erkennung der
Logikelemente auf/von High oder Low) was der Ziel-FPGA hergibt? Die
Simulation des nachfolgenden recht simplen VHDL-Codes funktioniert ja in
GHDL, aber ist auch die Synthese für einen FPGA möglich? Also ohne dass
das Synthesetool etwas wegoptimiert?
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.all;
3
4
entityhsoscis
5
port(
6
EN:instd_logic;
7
CLK:outstd_logic
8
);
9
endhsosc;
10
11
architecturebehavofhsoscis
12
signalpre_clk:std_logic:='0';
13
14
begin
15
process(EN,pre_clk)
16
begin
17
if(EN='1')then
18
if(pre_clk='0')then
19
pre_clk<=notpre_clkafter1fs;
20
else
21
pre_clk<=notpre_clkafter1fs;
22
endif;
23
else
24
pre_clk<='0';
25
endif;
26
endprocess;
27
28
CLK<=pre_clk;
29
endbehav;
Von Jitter, EMV und dergleichen will ich jetzt mal nicht reden. Aber ist
das Vorhaben prinzipiell möglich?
Will eine simple PLL aus Lernzwecken in VHDL entwerfen. Die Umsetzung
von den anderen Komponenten (Control Logic, Counter, Multiplier, etc.)
der PLL ist nicht das Problem. Das Einzige was ich noch benötige ist ein
möglichst schneller Taktgeber.
Das wurde hier schonmal durchdiskutiert und auch Lothar Miller hat was
dazu.
Synthetisierbar ist es grundsätzlich, praktisch aber als Kette von
mehreren Invertern. Wenn man nur einen Inverter benutzt, hat man keine
sauberen Flanken mehr, was zu Problemen führt.
Ja, aber nicht so
Johannes K. schrieb:> if (pre_clk = '0') then> pre_clk <= not pre_clk after 1 fs;> else> pre_clk <= not pre_clk after 1 fs;> end if;
denn after TIME kann nicht synthetisiert werden.
Außerdem hast du die Abfrage if (pre_clk = '0') then drinnen, die
braucht es nicht als Fallunterscheidung weil pre_clk ja immer invertiert
werden soll.
Es für den maximalen Takt schreibst du einfach
1
process(EN,pre_clk)
2
begin
3
if(EN='1')then
4
pre_clk<=notpre_clk;
5
else
6
pre_clk<='0';
7
endif;
8
endprocess;
Das wird aber keinen sauberen Takt erzeugen weshalb man
Dussel schrieb:> praktisch aber als Kette von> mehreren Invertern.
verwenden sollte. Der Nachteil: Dadurch wird dann auch der Takt
geringer.
Dussel schrieb:> Das wurde hier schonmal durchdiskutiert und auch Lothar Miller hat was> dazu.
Habe leider hier bei meiner Suche direkt im Board im Moment nichts
gefunden. Zu mindestens habe ich anscheinend die falschen Suchbegriffe
verwendet.
Danke für die Info.
Gustl B. schrieb:> denn after TIME kann nicht synthetisiert werden.
Okay, ist mir klar. Umgekehrt kann es aber ohne dieser Schlüsselworte
nicht simuliert werden. Zu mindestens nicht in GHDL.
OT
Ist es eigentlich möglich in GHDL die generelle Schaltzeit von High auf
Low und umgekehrt anzugeben? Würde mir die "after TIME" Schlüsselwörter
dann ersparen.
> Außerdem hast du die Abfrage if (pre_clk = '0') then drinnen, die> braucht es nicht als Fallunterscheidung weil pre_clk ja immer invertiert> werden soll.
Okay, sollte eigentlich klar sein. Danke für die Information. Weiß nicht
was mir hier durch denn Kopf gehen hab lassen.
> Das wird aber keinen sauberen Takt erzeugen weshalb man>> Dussel schrieb:>> praktisch aber als Kette von>> mehreren Invertern.>> verwenden sollte. Der Nachteil: Dadurch wird dann auch der Takt> geringer.
Okay, aber ab einer gewissen Frequenz ist das erzeugte Signal IMHO (um
mich nicht zu weit aus dem Fenster zu lehnen) sowieso kein sauberes
Rechtecksignal mehr.
Wichtig wäre mir also nur, dass der nachfolgende Entwurf bzw. Schaltung
ein Low und High Signal unterscheiden kann.
Johannes K. schrieb:> OT> Ist es eigentlich möglich in GHDL die generelle Schaltzeit von High auf> Low und umgekehrt anzugeben? Würde mir die "after TIME" Schlüsselwörter> dann ersparen.
Das wäre tatsächlich interessant. Man könnte ja denken, dass die
minimale Zeiteinheit ein Simulationsschritt ist, aber leider gibt es
eine Fehlermeldung.
Johannes K. schrieb:> Okay, ist mir klar. Umgekehrt kann es aber ohne dieser Schlüsselworte> nicht simuliert werden.
Leider. Liegt vermutlich daran, dass der Simulator das FPGA nicht kennt.
So eine Post-implementation-simulation könnte das aber richtig machen.
Wenn man mit solchen Laufzeitoszillatoren auf einem FPGA
herumspielt, sollte man gelegentlich mal mit dem Finger
nach der Temperatur fuehlen.
Wenn da naemlich einige hundert LE involviert sind, wird
das Dingens dabei recht heiss.
Gustl B. schrieb:> Man könnte ja denken, dass die> minimale Zeiteinheit ein Simulationsschritt ist, aber leider gibt es> eine Fehlermeldung.
Die "minimale Zeiteinheit" ist ein sog. Delta-Zyklus: lang genug, um
eine eindeutige "Reihenfolge" der Schaltprozesse festzulegen. Aber
trotzdem so kurz, dass seine Dauer auf der Zeitachse der Simulation
nicht wahrnehmbar ist. So dass der Simulator in eine Endlosschleife
gezwungen wird, wenn das after-Statement in der kombinatorischen
Schleife weggelassen wird.
Johannes K. schrieb:> Umgekehrt kann es aber ohne dieser Schlüsselworte> nicht simuliert werden.
Du musst das after-statement für die Simulation verwenden. Aber du musst
dir bewusst sein, dass das Simulationsergebnis nicht mit dem
übereinstimmt, was dann ggf. in Hardware synthetisiert wird.
Da ich das schon lange mal vorhatte, habe ich es jetzt auf einem
MAX1000-Board mit MAX10M08 mal ausprobiert. Erstaunlicherweise scheint
es auch mit nur drei Invertern noch problemlos zu funktionieren. Das
erzeugte 'Takt'-Signal erzeugt durch 30 Flipflops runtergeteilt ein
schönes gleichmäßiges Blinken etwa im Sekundentakt.
Wenn ich da keinen Fehler gemacht habe, bedeutet das, dass das erzeugte
Signal mit etwa einem Gigahertz schwingt.
Das überrascht mich doch.
Ich traue mich aber nicht, das auf dem Zynq-Board auszuprobieren. :D
Dussel schrieb:> Ich traue mich aber nicht, das auf dem Zynq-Board auszuprobieren. :D
Kann ich aber mal machen. Habe das Zybo-Z7-20 als Board. Das hat ja
einen Kühlkörper am ZYNQ7000. Außerdem sollte das noch immer nicht
reichen habe ich auch den Lüfter dazu. :)
Achim S. schrieb:> Du musst das after-statement für die Simulation verwenden. Aber du musst> dir bewusst sein, dass das Simulationsergebnis nicht mit dem> übereinstimmt, was dann ggf. in Hardware synthetisiert wird.
Das ist allerdings klar. Da man in vielen Fällen nicht weiß, was das
Synthestool aus dem VHDL Code macht.
Aber das sehe ich als Aufgabe mit Messungen zum Herausfinden. Auch wird
es wahrscheinlich von FPGA zu FPGA unterschiedlich sein. Erstens vom
Hersteller vom jeweiligen FPGA und auch von den Fertigungstoleranzen
auch bei der gleichen FPGA Serie.
Ist ja bei normalen Quarzoszillatoren auch so, dass die Dinger nicht
immer exakt mit der gleichen Frequenz schwingen. Hatten deswegen in der
Firma bei einer speziellen Anwendung (Lawinenpieps) auch einen
Testaufbau bei dem die Quarze ausselektiert wurden.
Dussel schrieb:> Da ich das schon lange mal vorhatte, habe ich es jetzt auf einem> MAX1000-Board mit MAX10M08 mal ausprobiert.
Hab ich mir neulich auch besorgt. :)
> Wenn ich da keinen Fehler gemacht habe, bedeutet das, dass das erzeugte> Signal mit etwa einem Gigahertz schwingt.> Das überrascht mich doch.
Die 1Ghz würden für meine Zwecke schon vollständig ausreichen.
Aber wäre echt interessant zu wissen (bei gleichem VHDL Code), wie
unterschiedlich die Ausgangsgeschwindigkeit zwischen ZYNQ7000 und
MAX10M08 ist.
OT
Eigentlich sollte ich meinen Weihnachtsputz von meiner Wohnung weiter
machen. Aber das wäre interessanter zum Probieren. :)
Johannes K. schrieb:> Da man in vielen Fällen nicht weiß, was das> Synthestool aus dem VHDL Code macht.
Nicht deswegen. Sondern weil mit dem Ringoszillator eine nicht
kontrollierbare Timing-Basis genutzt wird.
Johannes K. schrieb:> Aber das sehe ich als Aufgabe mit Messungen zum Herausfinden.
Auch mit Messungen kannst du nur eine Momentaufnahme sehen. Bei einem
anderen Syntheselauf oder bei einer anderen Temperatur oder bei einem
anderen Mondstand kann die Sache andere Ergebnisse liefern - egal, was
du heute misst.
Johannes K. schrieb:> Ist ja bei normalen Quarzoszillatoren auch so, dass die Dinger nicht> immer exakt mit der gleichen Frequenz schwingen.
Da sehe ich einen fundamentalen Unterschied gegenüber der
Herangehensweise mit Ringoszillatoren im FPGA. Wenn der Quarzoszillator
im Rahmen seiner Spezifikation betrieben wird, dann wird er die richtige
Frequenz ausgeben (im Rahmen der spezifizierten Genauigkeit). Und wenn
das FPGA-Design sauber mit Constraints abgesichert wurde, dann wird es
auch immer die gleiche Funktion erfüllen - unabhängig vom Syntheselauf,
von Temperatur und anderen Einflüssen.
Bei deinen Lawinen-Piepsern mit empfindlich abgestimmten HF-Kreisen mag
die Sache anders sein. Bei FPGA-Designs, die aus kommerziellen
Quarz-Oszillatoren getaktet werden, kann man die gewünschte
Funktionalität aber sicherstellen.
Achim S. schrieb:> Johannes K. schrieb:> Nicht deswegen. Sondern weil mit dem Ringoszillator eine nicht> kontrollierbare Timing-Basis genutzt wird.
Die aber IMHO gegeben wäre, wenn die FPGA Hersteller die internen
Schaltzeiten von den Logikelementen angeben würden. Klar, kommen noch
andere Einflüsse wie Temperatur hinzu.
Aber so weit hab ich das Datenblatt noch nicht studiert. Kann also
durchaus sein, dass diese Information durchaus vorhanden sind.
Das Problem bei GHDL (eventuell auch bei anderen Simulatoren) ist IHMO,
dass man keine grundlegenden Schaltzeiten angeben kann. Für GHDL auch
wenn man die Option --time-resolution in der Simulation - dachte
jedenfalls vorher, dass diese Option das gewünschte Simulationsverhalten
macht - angibt trotzdem noch für solche Designs ein modifiziertes VHDL
Design nötig ist, da die logischen Operationen in der Simualtion ohne
Verzögerung schalten. Was für mich bei größeren Designs aber eine
zusätzliche Fehlerquelle ist. Es wäre für mich wünschenswert, wenn GHDL
hier nach jeder grundlegenden logischen Funktion ein Delay einfügen
würde. Auch wenn es nur 1fs ist, da eben im RL sehr wohl Schaltzeiten
wie bei einem normalen Transistor berücksichtigt werden müssen. Ab
welchen Pegel jetzt High als High interpretiert wird oder Low als Low,
sei mal dahingestellt. Das Ganze könnte man ziemlich ausführlich
gestalten...aber das würde vermutlich zu keinem Ende führen. Dazu müsste
GHDL schon zum Beispiel NGSpice verwenden.
Johannes K. schrieb:> Die aber IMHO gegeben wäre, wenn die FPGA Hersteller die internen> Schaltzeiten von den Logikelementen angeben würden.
da liegst du meiner Ansicht nach falsch.
Johannes K. schrieb:> Kann also> durchaus sein, dass diese Information durchaus vorhanden sind.
Die Hersteller geben detailliert an, welche Verzögerungen maximal
auftreten können. Welche Verzögerungen genau auftreten, geben sie nicht
an, weil sie das nicht innerhalb vernünftiger Fehlergrenzen können.
Johannes K. schrieb:> Das Problem bei GHDL (eventuell auch bei anderen Simulatoren) ist IHMO,> dass man keine grundlegenden Schaltzeiten angeben kann.
Du führst derzeit wohl eine Verhaltenssimulation durch - da gibt es
keine endlichen Schaltzeiten. Du simulierst das Verhalten deiner
Logikbeschreibung - unabhängig von einer Implementierung in eine
bestimmte Hardware. Und wenn du eine waveform mit "after 1 fs" angibst,
dann liefert dir die Verhaltenssimulation eben eine Flanke nach einer fs
- unabhängig davon, ob dies von einer bestimmten Hardware auch so
umsetzbar wäre.
Mit der Toolchain der Hersteller kannst du stattdessen aber auch
Timing-Simulationen durchführen, bei der die die Verzögerungen des
konkreten Designs "abgeschätzt" werden und in die Simulation einfließen.
Aber daraus kannst du trotzdem kein Design mit vernünftigem Timing
ableiten - weil die Ungenauigkeiten und externen Einflüsse viel zu groß
sind.
Was dagegen zuverlässig funktioniert ist der Standardansatz beim
FPGA-Entwurf: man gibt über Constraints vor, welches Timing man
benötigt. Und die Toolchain des Herstellers überprüft mit den worst-case
Verzögerungen, dass dieses Timing unter allen Umständen eingehalten
wird.
Achim S. schrieb:> Johannes K. schrieb:> Die Hersteller geben detailliert an, welche Verzögerungen maximal> auftreten können.
So weit hab ich die Datenblätter nicht studiert. Danke für die
Information!
> Johannes K. schrieb:>> Das Problem bei GHDL (eventuell auch bei anderen Simulatoren) ist IHMO,>> dass man keine grundlegenden Schaltzeiten angeben kann.>> Du führst derzeit wohl eine Verhaltenssimulation durch - da gibt es> keine endlichen Schaltzeiten.
Auch wenn es aus der Sicht eines Laien hart klingt. Aber das ist für
mich keine "echte" Simulation. Für mich sollte eine Simulation, damit
sie sich so nennen darf, so ziemlich alle Gegebenheiten was auftreten
abschätzen können. Sprich sie soll annähernd wie das echte Leben
funktionieren. Da es im echten Leben noch keine Marktreife Technologie
(Quanteninformationstechnik wäre vielleicht ein Kandidat) gibt die ohne
Delay schaltet, sollte sich die Simulation meiner Meinung schon an die
derzeitige Technologie halten.
Vielleicht ein blödes Beispiel:
Eine A-Stabile Kippstufe würde in einer Simulation, die keine
Bauteiltoleranzen berücksichtigt nicht funktionieren, weil eben das
Ganze erst durch die Toleranzen zum Schwingen anfängt (Irgendein
Transistor schaltet zuerst). Im schlimmsten Fall schwingt die Schaltung
auch nicht, wenn die Werte der Bauteile (Kondensator und Widerstand) und
die Schaltzeiten, Verstärkung etc. der Transistoren und auch die Länge
der Leiterbahnen und physikalischer Aufbau "exakt" gleich sind.
> Was dagegen zuverlässig funktioniert ist der Standardansatz beim> FPGA-Entwurf: man gibt über Constraints vor, welches Timing man> benötigt. Und die Toolchain des Herstellers überprüft mit den worst-case> Verzögerungen, dass dieses Timing unter allen Umständen eingehalten> wird.
Die Ganzen (Constraints) könnte man sich so einigermaßen ersparen, wenn
man zu mindestens die "worst-case" Schaltzeiten in der Simulation bei
fremden Tools (GHDL) angeben könnte.
Ich muss zugeben, ich mag die Herstellertools nicht ganz. Eben weil die
IDE's (wie zum Beispiel Vivado) sehr viel Ressourcen benötigen. Liegt
auch daran, dass ich teilweise ein OSS Fanboy bin und deswegen OSS
bevorzuge. GHDL in Verbindung mit GTKWave ist IMHO eine tolle Sache...
Was an meiner Idee mit zu mindestens der Angabe der grundlegenden
Schaltzeiten (worst-case) falsch sein sollte, würde ich gerne wissen:
Folgende Positivpunkte würden mir einfallen:
- Keine Komplexen Constraints (in der Simulation mit externen Tools)
mehr nötig
- Grundlegende Vermeidung von Designfehlern, da in der Simulation mit
externen Tools berücksichtigt
Gibt sicherlich mehr positiven Punkte. Vielleicht auch Negative, aber
fallen mir derzeit keine ein.
Johannes K. schrieb:> Auch wenn es aus der Sicht eines Laien hart klingt. Aber das ist für> mich keine "echte" Simulation. Für mich sollte eine Simulation, damit> sie sich so nennen darf, so ziemlich alle Gegebenheiten was auftreten> abschätzen können.
So habe ich früher auch gedacht, aber so funktioniert die
FPGA-Entwicklung im Allgemeinen nicht.
Johannes K. schrieb:> Die Ganzen (Constraints) könnte man sich so einigermaßen ersparen, wenn> man zu mindestens die "worst-case" Schaltzeiten in der Simulation bei> fremden Tools (GHDL) angeben könnte.
Könnte man, aber nicht sinnvoll. Dann müsste man für die Laufzeit jeden
Signals annehmen, dass es über den kompletten Chip geroutet wird.
Dadurch wäre das Worst-Case-Timing so langsam, dass man damit nichts
sinnvolles anfangen könnte.
Im FPGA beschreibt man im Allgemeinen digitale und zeitdiskrete Logik.
Man will eine Funktion beschreiben. In einer Simulation ohne Timing kann
man sehen, ob alles wie gewünscht funktioniert. Durch Angabe der
Constraints kann dann automatisch festgestellt werden, ob das
Beschriebene auch mit der Geschwindigkeit ausgeführt werden kann.
Eine Timingsimulation hat da keinen Nutzen. In einem Design hat man
locker tausende Signale. Willst du deren korrektes (ganz grob
geschätztes) Timing wirklich anhand einer Simulation nachweisen?
Ich kann deine Denkweise nachvollziehen, aber es hat schon einen Grund,
warum man die Logik ohne Timing simuliert und den Rest über Constraints
automatisch erledigt.
Dussel schrieb:> Johannes K. schrieb:>> Die Ganzen (Constraints) könnte man sich so einigermaßen ersparen, wenn>> man zu mindestens die "worst-case" Schaltzeiten in der Simulation bei>> fremden Tools (GHDL) angeben könnte.> Könnte man, aber nicht sinnvoll. Dann müsste man für die Laufzeit jeden> Signals annehmen, dass es über den kompletten Chip geroutet wird.> Dadurch wäre das Worst-Case-Timing so langsam, dass man damit nichts> sinnvolles anfangen könnte.
Die Signalzeit würde ich jetzt aber vernachlässigen, da die Spannung
sich ja annähernd mit Lichtgeschwindigkeit ausbreitet. Bei der
Entfernung zwischen Erde und Sonne sind es ja ungefähr 8 Minuten die das
Licht hierher braucht. So lang sind aber die Leitungen in einem FPGA
aber "vermutlich" nicht. Man könnte aber auch durchaus ein worst-case
angegeben.
Tut mir Leid, ich verstehe es einfach nicht warum man nicht mit den
worst-case Timings simuliert. Meiner Meinung hätte man dadurch
wenigstens ungefähr die minimale Geschwindigkeit was das Design
erreichen kann.
> Im FPGA beschreibt man im Allgemeinen digitale und zeitdiskrete Logik.> Man will eine Funktion beschreiben. In einer Simulation ohne Timing kann> man sehen, ob alles wie gewünscht funktioniert.
Was es eben in diesen nicht konventionellen Beispiel ohne
after-Statements nicht funktioniert.
> Durch Angabe der> Constraints kann dann automatisch festgestellt werden, ob das> Beschriebene auch mit der Geschwindigkeit ausgeführt werden kann.> Eine Timingsimulation hat da keinen Nutzen. In einem Design hat man> locker tausende Signale. Willst du deren korrektes (ganz grob> geschätztes) Timing wirklich anhand einer Simulation nachweisen?
Ja, warum nicht? Verstehe die Sichtweise ehrlich gesagt nicht. Ist ja
nicht so, dass man die Simulation, ganz frech gesagt, auf einen 8-Bit
Microcontroller laufen lässt. Hier wäre es tatsächlich nicht
praktikabel. Außerdem "sollten" ja die Synthesetools die Constraints
auch berücksichtigen. Wird ja auch mit den Worst-Case Timings simuliert.
Außer dass das Synthesetool die tatsächliche Implementation/Routing für
sich liegen hat.
Nachtrag
Ich finde man könnte hier unabhängig vom Hersteller ein Design
ausprobieren bzw. grundlegend testen. Man hätte dadurch (wenigstens für
Anfänger) eine Anhaltspunkt ob das Super-tolle Design prinzipiell
funktionieren würde.
Johannes K. schrieb:> Die Signalzeit würde ich jetzt aber vernachlässigen, da die Spannung> sich ja annähernd mit Lichtgeschwindigkeit ausbreitet.
mit der Einschätzung liegst du daneben. Das Routing-Delay kann
vergleichbar sein zum Logic-Delay, es kann deutlich kleiner sein, und es
kann deutlich größer sein - ja nach Signal und konkretem Design. In
einem typischen Design treten alle Varianten nebeneinander auf, und die
Herstellersoftware muss alle Einzelbeiträge zu den Verzögerungen für
jeden einzelnen Signalpfad bestimmen. Das durch eine simple "Schaltzeit"
auszudrücken funktioniert halt nicht. Schau dir die Anzahl der
unterschiedlichen Timing-Parameter an, die zu berücksichtigen sind
(z.B. "switching characteristics" in
https://www.xilinx.com/support/documentation/data_sheets/ds162.pdf)
Soll dein GHDL das genau so gut in einer Timing-Simu abbilden können wie
die Herstellersoftware, dann muss die dein GHDL am Ende das innere des
FPGAs genau so gut kennen und wird genau so umfangreich und
ressourcenfressend sein, wie die Herstellersoftware.
Johannes K. schrieb:> So lang sind aber die Leitungen in einem FPGA> aber "vermutlich" nicht. Man könnte aber auch durchaus ein worst-case> angegeben.
Du "vermutest" falsch.
Johannes K. schrieb:> Tut mir Leid, ich verstehe es einfach nicht warum man nicht mit den> worst-case Timings simuliert. Meiner Meinung hätte man dadurch> wenigstens ungefähr die minimale Geschwindigkeit was das Design> erreichen kann.
Weil man damit zu völlig unrealistischen Ergebnissen käme, die locker um
Größenordnungen neben dem liegen können, was sich mit der richtigen
Herangehensweise erreichen lässt. Was nützt es mir zu bestimmen, dass
das Design laut GHDL im worst case mit 500kHz funktionieren wird, wenn
ich ein 80MHz-Design möchte?
Versuche einfach mal wirklich ein paar echte Designs zu erzeugen und auf
Geschwindigkeit zu bringen statt zu theoretisieren, ohne konkrete Zahlen
zu kennen. (Ohne ressourcenfressende Hersteller-Toolchain geht das halt
leider nicht.) Dann wirst auch du sehen, dass dein momentaner Ansatz
(den wahrscheinlich viele zu Beginn ihrer Beschäftigung mit FPGAs im
Hinterkopf hatten) nicht zielführend ist.
Achim S. schrieb:> Johannes K. schrieb:> mit der Einschätzung liegst du daneben. Das Routing-Delay kann> vergleichbar sein zum Logic-Delay
Gut, der interne Aufbau (bzw. Schaltung) der Routing-Elemente insgesamt
der Aufbau der LUT's wird ein Hersteller-Geheimnis sein, aber im
allgemeinen werden es trotzdem Verbünde von Standard-Gatter sein.
> Soll dein GHDL das genau so gut in einer Timing-Simu abbilden können wie> die Herstellersoftware, dann muss die dein GHDL am Ende das innere des> FPGAs genau so gut kennen und wird genau so umfangreich und> ressourcenfressend sein, wie die Herstellersoftware.
Das was allerdings logisch ist. Aber, wie ich bereits geschrieben habe,
würden zum Anfang mal die grundlegenden Schaltzeiten der UND, ODER,
NOT-Gatter usw. reichen. Die schalten nur in der Theorie
verzögerungsfrei mit der jetzigen Technik. Man müsste ja nicht unbedingt
nur die Worst-Case Werte verwenden. Das könnte jeder selber entscheiden.
Beispiel drei Simulationen: Einmal mit Worst-Case, Mittelwert und
Best-Case. Man hätte dann viel abgedeckt.
Überspitzt geschrieben würde ich mal jetzt behaupten, dass GHDL
annähernd die gleiche Geschwindigkeit erreicht. Mir kommt nämlich
manchmal vor, dass der Simulator von Xilinx ein JAVA-Programm ist...
Gut, GHDL ist in ADA geschrieben. Müsste ich mich einlernen, dann würde
ich selber einen Patch mit der zusätzlichen Option veröffentlichen. Ist
mein Ernst. Ob der Patch allerdings von den Maintainern angenommen wird
ist fraglich...
> Johannes K. schrieb:>> So lang sind aber die Leitungen in einem FPGA>> aber "vermutlich" nicht. Man könnte aber auch durchaus ein worst-case>> angegeben.>> Du "vermutest" falsch.
So, mich würde aus Interesse echt interessieren, wie lang dann eine
Leitung auf einer DIE (Hausnummer 10mm*10mm) von einem Logikelement zum
Nächsten wirklich ist. Gut, ich habe keine Ahnung von ASIC-Design, aber
ich bezweifle irgendwie, dass hier eine ungefähre durchschnittliche
Länge von 149 Millionen Kilometer besteht. Kann schon sein, dass die
Routingsoftware die Leitung ein paar mal im Kreis laufen lässt (Ein
Grund warum ich keine Autorouter mag). Aber dann sicherlich nicht einmal
bei Designs im kHZ-Bereich und darüber. Weiß nicht, aber die jetzige
Logik die mit Elektronen arbeitet muss sich "eigentlich" auch an
physikalische Grenzen halten.
Nachtrag
Dass bei komplexen Schaltungen die Länge aller Leitungen insgesamt
länger sein kann ist mir schon klar. Aber ich bezweifle wirklich, dass
jetzt genauer von einem Element zum benachbarten Element, wenn diese
zusammen geschaltet sind , die Länge im Millionen Kilometer Bereich ist.
> Johannes K. schrieb:> Was nützt es mir zu bestimmen, dass> das Design laut GHDL im worst case mit 500kHz funktionieren wird, wenn> ich ein 80MHz-Design möchte?
Diese Denkweise mag im Consumer-Anwendungen der Fall sein. Bezweifle
aber stark, dass zum Beispiel im Medizintechnikbereich (sollten hier
FPGA's überhaupt erlaubt sein - genauer also Bereiche wo ein
Menschenleben abhängt) nicht vom Worst-Case ausgegangen wird.
Aber verstehe schon...Als Laie darf man halt keine möglichen
Verbesserungsvorschläge den Experten Nahe bringen...werden versucht mit
Totschlagargumenten zum Negativen zu wandeln. Ich kann mir die echten
Gründe allerdings eh denken...
Johannes K. schrieb:> Aber, wie ich bereits geschrieben habe,> würden zum Anfang mal die grundlegenden Schaltzeiten der UND, ODER,> NOT-Gatter usw. reichen
Solche Gatter gibt es in FPGAs nicht. Wenn dich das Thema interessiert,
dann schaue endlich in die konkreten Datenblätter statt aufgrund
falscher Annahmen zu theoretisieren.
Johannes K. schrieb:> Diese Denkweise mag im Consumer-Anwendungen der Fall sein. Bezweifle> aber stark, dass zum Beispiel im Medizintechnikbereich (sollten hier> FPGA's überhaupt erlaubt sein - genauer also Bereiche wo ein> Menschenleben abhängt) nicht vom Worst-Case ausgegangen wird.
Die Toolchain des Herstellers berechnet den worst case der tatsächlich
implementierten Pfade. Und passt das Design so an, dass die constraint
garantiert eingehalten werden (oder meldet, dass keine derartige Lösung
gefunden wurde und hilft bei der Suche nach den Ursachen).
Nach deinem Ansatz - ohne die konkrete Implementierung zu betrachten -
müsste aber jeweils der worst case des schlechtest denkbaren Pfads im
FPGA angenommen werden. Das generiert ein Ergebnis, das um
Größenordnungen falsch liegt.
Johannes K. schrieb:> Aber verstehe schon...Als Laie darf man halt keine möglichen> Verbesserungsvorschläge den Experten Nahe bringen...werden versucht mit> Totschlagargumenten zum Negativen zu wandeln. Ich kann mir die echten> Gründe allerdings eh denken...
Echt jetzt? Mehrere Leute beantworten deine Fragen, gehen auf deine
Missverständnisse ein und erklären dir, was stattdessen Sache ist. Und
in deinen Augen sind das Totschlagargumente, die nur verhindern sollen,
dass du deine "Verbesserungsvorschläge" umsetzt? Besten Dank für das
Feedback. Du darfst die Welt gerne weiter auf Basis falscher Annahmen
verbessern, ich werde dabei nicht weiter stören.
Achim S. schrieb:> Solche Gatter gibt es in FPGAs nicht. Wenn dich das Thema interessiert,> dann schaue endlich in die konkreten Datenblätter statt aufgrund> falscher Annahmen zu theoretisieren.
Ach tatsächlich? Dann sind solche Beschreibungen (hier Intel:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01003.pdf)
einer LUT also alle falsch, wo eindeutig Logik-Schaltsymbole erkennbar
sind? Und außerdem wie funktioniert denn ein einfaches UND-Gatter in
dieser LUT (sollte dieses vorhanden sein) ohne Transistor? Egal in
welcher Technologie (CMOS, etc.)?
Besitze durchaus Bücher wo der Aufbau der LUT's dargestellt wird. Sind
also alle falsch, echt interessant...
Deswegen mein vielleicht nicht gut gewählter abschließender Schlusssatz.
Ich mag zwar fast kein Wissen in FPGA-Technologien haben. Aber habe sehr
wohl Ahnung von grundlegender Schaltungstechnik. Kann nicht nur das
Logik-Symbol interpretieren, sondern auch mit herkömmlichen Bauteilen
(Transistoren) aufbauen. Mir fällt also ehrlich gesagt keine Lösung ohne
Transistor (ob bipolar oder unipolar) um ein ganz normales Gatter zu
entwerfen. Aber soweit ich dich verstanden habe funktioniert bei FPGA's
alles durch Magie.
Deswegen nochmal, auch ein Prozessor besteht aus einer großen Menge aus
Transistoren die alle Logik-Gatter, dann auf der höherwertigen Schicht
Addierer usw. nachbilden. Und ein FPGA verwendet also keine Transistoren
als Schaltelemente? Sorry, dazu muss ich sagen, dass jetzt für mich die
FPGA's durch Magie schalten.
Ihr könnt mich jetzt ruhig negativ bewerten, aber mich würde brennend
interessieren wie ein einem FPGA die Schaltungstechnik OHNE Transistoren
aufgebaut ist. Sind es Reed-Elemente, Relais oder was ist es? So und
jetzt steinigt mich...
Nachtrag
Ich verstehe außerdem nicht was daran (dass Transistoren Schaltzeiten
aufweisen) theoretischer Natur ist. Für mich zählt das eigentlich zur
Praxis, da die "normalen" Berechnungen (Schaltalgebra) (fast) immer vom
Idealfall (also keine Schaltzeit im Falle des Transistors) ausgehen.
Betreff ALM von der Intel Beschreibung...Hier sehe ich definitiv ein
D-Flip-Flop nahe vom Ausgang.
Hier eine mögliche Schaltung eines D-Flip-Flop mit CMOS-Technolgie von
Wikipedia:
https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#/media/File:True_single-phase_edge-triggered_flip-flop_with_reset.svg
Und die gleiche Funktion soll im FPGA ohne die Verwendung von
Transistoren funktionieren?
Aber so langsam wird es mir zu blöd um meine Grundidee zu erklären. Dass
es nicht exakt ähnlich wie mit dem Herstellertools sein wird ist auch
logisch. Aber es wäre aus meiner Sicht durchaus annähernd eine
korrektere Simulation aber herstellerunabhängig. Man könnte fast meinen,
dass GHDL als böse bezeichnet wird (vor allem weil hier die Rede von
MEIN GHDL war. Nein, GHDL habe ich nicht programmiert und besitze auch
keine Rechte für das Programm). Okay, verbleiben wir besser so: Ich als
praktischer Elektroniker weiß, dass es so etwas wie Schaltzeiten gibt.
Was reine theoretische Elektroniker meinen, die noch nie einen Lötkolben
in der Hand hatten und ein Oszilloskop bedienen können, ist mir ehrlich
gesagt jetzt egal. (Also Hardware auch nur von der Vorlesung kennen.
Habe leider in meinen damaligen Beruf genügend auf solche oft arroganten
Leute die alles im höheren Bereich besser wissen aber anscheinend keine
Ahnung mehr von den Grundlagen haben getroffen. Langsam wird es
unlustig. Ich will niemand der frisch von Uni kommt pauschalieren, aber
leider ist es zu mindestens in AT so der Fall, was ich als noch
"normaler" Geselle so miterlebt habe. Und ja tatsächlich, man hat früher
auch in der Entwicklung als nicht Hilfsarbeiter als Geselle arbeiten
können, wenn man ein Interesse für eine bestimmte Sache gezeigt hat und
meine damals entwickelten Sachen funktionieren auch noch heute. Ich weiß
nicht, der Begriff mag vielleicht für viele altmodisch Klingen, aber
Bücher mit den Grundlagen gab es auch damals. Ach richtig, die Lehrer
haben an der Berufsschule nicht geplante Obsoleszenz gelehrt... Gemein,
oder?)
Aber jetzt wird es zu OT und hat mit dem eigentlichen Thema nichts mehr
zu tun. Hoffe nur ein Moderator schließt den Thread noch nicht, möchte
nämlich noch gerne den Unterschied von Intel MAX-10 FPGA's und Xilinx
ZYNQ-7000 posten. Dürfte vielleicht doch jemanden interessieren, wo der
Oszillator jetzt schneller läuft. Auch wenn es mit Contraints bestimmt
werden kann. Ich bin ein praktisch veranlagter Mensch. Ich vertraue
hauptsächlich auf einer Messung mit Oszilloskop. Muss allerdings runter
dividieren da mein privates nur maximal 250MHz unterstützt, außerdem
wird vermutlich nicht die Ausgangslogik diese volle Geschwindigkeit
schaffen. Aber mal toll zu Wissen wo ungefähr die Frequenz mit drei
Invertern liegt.
Ein Design das flaechendeckend auf deinen
> "Verbesserungsvorschläge"
basiert, wuerde einen FPGA wenn keine thermischen Sicherungen
enthalten waeren, schlicht abbrennen lassen.
Schoen wenn so "Allerwelts"-FPGA ein mit 200 MHz getaktetes
Design am Laufen hat, wird ihm betraechtlich warm dabei.
Das so ein (3 LE-)Laufzeitoszillator ca. 1 GHz erzeugt,
deckt sich auch mit meinen Beobachtungen, statt MAX10
aber ein Cyclone-FPGA.
So etwas kann durchaus auch mal Versehen passieren,
etwa so:
Johannes K. schrieb:> Aber verstehe schon...Als Laie darf man halt keine möglichen> Verbesserungsvorschläge den Experten Nahe bringen...werden versucht mit> Totschlagargumenten zum Negativen zu wandeln. Ich kann mir die echten> Gründe allerdings eh denken...
Was soll das jetzt? Ich habe mich eben, als ich das Thema wieder
geöffnet habe, gefreut, dass es so einen anständigen Austausch gibt. Und
dann kommt sowas.
Johannes K. schrieb:> eine ungefähre durchschnittliche> Länge von 149 Millionen KilometerJohannes K. schrieb:> die Länge im Millionen Kilometer Bereich
Wenn das nicht spaßig übertrieben war, lässt das erahnen, dass du gar
keine Ahnung hast.
Mein letztes Design lief auf 450 MHz. Da geht es auch bei
Lichtgeschwindigkeit um etwa 70 cm, ohne Berücksichtigung der Setup-,
Hold- und Gatterschaltzeiten.
NK-Zeta schrieb:> Finde den Feler!
Fehler schreibt man mit h.
:-P
Meinst du das fehlerhafte Semikolon hinter process? Das sollte aber
schon vor der Timingsimulation auffallen. ;-)
Johannes K. schrieb:
> Die aber IMHO gegeben wäre, wenn die FPGA Hersteller die internen> Schaltzeiten von den Logikelementen angeben würden.
Ist logisch, dass die das nicht tun. Denn, die Angaben gelten fuer den
Temperatur und spannungbereich. Und der Hersteller mochte die Freiheit
haben, spater denselben Baustein mit modernerem Silikon, allenfalls
kleineren Strukturen neuaufzulegen. Weshalb sollte er sich diesen Weg
verbauen ?
Also besser die Haende weg von solchen Uebungen im Produktionsprojekt.
Es gibt programmierbare Singlechip Frequenzgeneratoren mit nahezu
beliebigen Frequenzbereichen.
Johannes K. schrieb:> Ich verstehe außerdem nicht was daran (dass Transistoren Schaltzeiten> aufweisen) theoretischer Natur ist.
Diese Betrachtungen sind insofern theoretischer Natur, als man sie sonst
konsequenterweise bis zur Quantenmechanik hinunter betrachten müsste.
Das ist aber für die tägliche Arbeit mit FPGAs in >99,99% der Fälle
nicht nötig.
> Für mich zählt das eigentlich zur Praxis, da die "normalen" Berechnungen> (Schaltalgebra) (fast) immer vom Idealfall (also keine Schaltzeit im> Falle des Transistors) ausgehen.
Mit derartig tiefgehenden Betrachtungen wirst du aber kein komplexes
FPGA-Design zum Laufen bekommen. Denn das ist wie wenn du in einem Wald
besonders die einzelnen Nadeln an einer Fichte oder die Blätter an einer
Buche betrachtest. So eine Nadel oder ein Blatt ist für den einzelnen
Baum absolut wichtig. Für den Wald an sich sind sie nebensächlich,
solange sie da sind und das tun, was sie sollen.
Für einen normalen Betrachter besteht ein Wald eben aus Bäumen. Es ist
ihm egal, ob ein Baum wiederum aus Wurzeln, Stamm, Ästen und
Blättern/Nadeln besteht, oder gar, ob diese Bestandteile dann aus
Ligninzellen und diese Zellen aus Atomen und diese aus Quanten bestehen.
Es ist für normale "Anwender" (Förster, Wanderer, Waldarbeiter,...) erst
mal ausreichend, den Wald als eine Ansammlung von Bäumen zu
betrachten.
Und genauso ist für den normalen "FPGA-Anwender" die Betrachtung eines
FPGAs als eine Ansammlung von LUTs und Flipflops ausreichend.
> aber mich würde brennend interessieren wie ein einem FPGA die> Schaltungstechnik OHNE Transistoren aufgebaut ist.
Das hat doch keiner hier behauptet. Es wurde nur gesagt, dass es in dem
Teil, den du im FPGA für dein Design verwenden kannst, kein 4-fach UND
oder 3-fach XOR oder 6-fach NOR gibt, sondern dass deine
Hardwarebeschreibung aus LUTs und Flipflops aufgebaut werden wird.
Und nur diese Denkweise wird dich beim FPGA-Design zum Ziel bringen.
Johannes K. schrieb:> Was an meiner Idee mit zu mindestens der Angabe der grundlegenden> Schaltzeiten (worst-case) falsch sein sollte, würde ich gerne wissen
Es macht den Code unleserlich, wenn hinter jeder Zuweisung eine unnötige
und zudem un den meisten Fällen (weil von Versorgungsspannung,
Temperatur, ... abhängig) sicher falsche "after xy ns" Zeitangabe steht.
>> Johannes K. schrieb:>>> Das Problem bei GHDL (eventuell auch bei anderen Simulatoren) ist IHMO,>>> dass man keine grundlegenden Schaltzeiten angeben kann.>> Du führst derzeit wohl eine Verhaltenssimulation durch - da gibt es>> keine endlichen Schaltzeiten.> Aber das ist für mich keine "echte" Simulation.
Der Witz dabei ist: die Simulation ist hinreichend, wenn man sich an
die Regeln für ein synchrones Design hält.
Es ist so wie beim Busfahren: es reicht dir, wenn du weißt, dass so wie
es im Fahrplan steht, der Bus in deiner Straße um 9:30 anhält und du
einsteigen kannst und dass du anschließend um 9:55 am Ziel aussteigen
wirst. Du musst im echten Leben nicht wissen, dass er dafür um 8:47 von
der Endhaltestelle abfahren und davor sowie dazwischen einige andere
Haltestellen rechtzeitig anfahren muss. Dich interessiert nur, dass er
möglichst pünktlich und keinsfall zu früh an deiner Abfahrtshaltestelle
abfährt und möglichst pünktlich, aber keinesfalls zu spät am Ziel
ankommt. Wenn das das ganze Jahr über bei deiner Haltestelle und bei der
Zielhaltestelle funktioniert, dann bist du glücklich.
Du musst nicht wissen und es interessiert dich nicht, wie ein Bus
funktioniert, wie der Treibstoff eingefüllt und der Fahrer bezahlt wird.
> "echte" Simulation.
Das ist (wie die Anführungszeichen nahelegen) sowieso ein Oxymoron.
Johannes K. schrieb:> Als Laie darf man halt keine möglichen Verbesserungsvorschläge den> Experten Nahe bringen...
Du hast halt für das Thema "FPGA-Design" derzeit den vollkommen falschen
Denkansatz. Und das ist, was die, die das schon länger machen (und
solche Anfängerbetrachtungen hinter sich gelassen haben) dir sagen
wollen.
> werden versucht mit Totschlagargumenten zum Negativen zu wandeln.
Ach, komm. Stell dich bitte nicht als Mobbing-Opfer hin. Denk besser
drüber nach, was die, die tatsächlich Erfahrung haben, zu deinem
fragmentierten Halbwissen beitragen können.
Wenn du tatsächlich die tiefste Interna solcher Bausteine kennenlernen
willst, dann musst du alte Dokumente und Patente ansehen und
nachvollziehen. Dieses Wissen wirst du aber wie gesagt nur in <0,01% der
Fälle brauchen.
Johannes K. schrieb:> Diese Denkweise mag im Consumer-Anwendungen der Fall sein. Bezweifle> aber stark, dass zum Beispiel im Medizintechnikbereich (sollten hier> FPGA's überhaupt erlaubt sein - genauer also Bereiche wo ein> Menschenleben abhängt) nicht vom Worst-Case ausgegangen wird.FPGAs können in Bereichen wo Menschenleben abhängen eingesetzt werden
und zugelassen werden (Been there, done that).
Natürlich werden dazu worst-case Betrachtungen gemacht
(Versorgungspannung, Temperatur, Strahlung, Herstellprozess) und
zusätzlich zu den "einfachen" Anwendungen werden in diesem Bereich auch
Post-Layout Simulationen durchgeführt.
Eine Post-Layout Simulation kommt deinem aktuellen Bedürfnis nach
"echter" Simulation wohl am nächsten. Nach dem die Toolchain dein ganzes
Design im FPGA implementiert hat, erzeugt die Toolchain ein
Simulationsmodell dieser Implementation (wieder in VHDL oder Verilog)
inkl. Zeitverzögerungen (im Standardisierten SDF Format).
Dieses Post-Layout Modell kannst du wieder Simulieren (sollte auch mit
GHDL gehen) und prüfen ob es immer noch das tut, was du von ihm
erwartest.
Bevor ein Design implementiert wird bzw. Post-Layout Simulationen
gemacht werden, wurde in vereinfachten Simulationen (Verhaltensmodel
ohne Zeitverzögerung) festgestellt, dass es das tut, was gefordert wird.
Bei Post-Layout Simulationen fühlt es sich dann so an, als wäre der
Simulator in Java geschrieben und wird auf einem 8-Bit Microcontroller
ausgeführt :-)
Purzel H. schrieb:> Johannes K. schrieb:>> Die aber IMHO gegeben wäre, wenn die FPGA Hersteller die internen>> Schaltzeiten von den Logikelementen angeben würden.>> Ist logisch, dass die das nicht tun. Denn, die Angaben gelten fuer den> Temperatur und spannungbereich. Und der Hersteller mochte die Freiheit> haben, spater denselben Baustein mit modernerem Silikon, allenfalls> kleineren Strukturen neuaufzulegen. Weshalb sollte er sich diesen Weg> verbauen ?>> Also besser die Haende weg von solchen Uebungen im Produktionsprojekt.> Es gibt programmierbare Singlechip Frequenzgeneratoren mit nahezu> beliebigen Frequenzbereichen.
also die Schaltzeiten müssten doch sogar auffindbar sein. Macht doch mal
eine Netzlisten-Simulation von P&R mit sdf-annotate. Dort müssten die
Schaltzeiten für den gewählten Corner drin sein. Stichwort Vitals.
Allgemein ist es im ASIC-Design usus, dass man für die Standardzellen
eine Library mit den kompletten Charakterisierten Timinginformationen
hat. Man baut auch dort Logik-Oszillatoren. Wenn die Library nicht
ausreicht, dann gehts auf Transistor-Modell-Ebene mit Spice. Aber das
macht man nur in Ausnahmefällen. Tja, nur schwanken die Dinger auch
schon bei alten Technologie sehr und in den neuen FPGAs ist es sicher
viel schlimmer. Was bringt ein Takt der um 80% schwankt? Von 1fs
Gatterlaufzeit bist du auch weit entfernt.
ich weiß auch gar nicht, was die ganze Diskussion soll. Einfach mal die
Resultate vom P&R simulieren.
Dussel schrieb:> Das wurde hier schonmal durchdiskutiert und auch Lothar Miller hat was> dazu.
Oh ja das wurde es und auch x-mal gemacht. Theoretisch geht es, aber
praktisch muss man zusehen, dass die delays lang genug werden, damit die
Rückkopplung lang genug ist und die Inverter-Ausgänge auch ausreichend
Amplitude haben und nicht nur minimal um den Mittelpunkt schwingen.
Schon bei FPGAs der Spartan 2 Serie mussten 5-7 Inverter her:
http://www.96khz.org/oldpages/digitalnoisegenerator.htm
Jürgen S. schrieb:> Schon bei FPGAs der Spartan 2 Serie mussten 5-7 Inverter her:
Und wie ich schrieb, sind es beim Max10 beim 3,3 V und Raumtemperatur 3.
Vielleicht setze ich mich mal hin und versuche irgendwie, die
Signalqualität zu analysieren.
Tim schrieb:> Allgemein ist es im ASIC-Design usus
Klar, dort natürlich. Dort ist auch der Entwickler für die sachgereche
Taktverteilung zuständig. Allerdings hat Johannes K. (krjdev) schon
explizit nach der Umsetzung solcher Oszillatoren in FPGAs gefragt.
Tim schrieb:> Tja, nur schwanken die Dinger auch schon bei alten Technologie sehr> Was bringt ein Takt der um 80% schwankt?
Ich habe diese Ringoszillatoren als brauchbar temperaturstabil und
jitterarm in Erinnerung.
> und in den neuen FPGAs ist es sicher viel schlimmer.
Warum sollte das so sein?
Lothar M. schrieb:> Tim schrieb:>> Tja, nur schwanken die Dinger auch schon bei alten Technologie sehr>> Was bringt ein Takt der um 80% schwankt?> Ich habe diese Ringoszillatoren als brauchbar temperaturstabil und> jitterarm in Erinnerung.
Es kommt auf die Technologie an. Je kleiner der Node desto größer werden
in der Regel die Schwankungen. Relativ zu den kürzeren Schaltzeiten ist
die Temperatur- und insbesondere auch die Abhängigkeit zum Prozess und
der Betriebsspannung größer.
Ich kenne Leute, die noch einen Trimmprozess fahren, nur damit sowas wie
UART funktioniert.
Trotzdem ist ein Ringoszillator weiterhin sinnvoll, da er klein und
relativ einfach herzustellen ist.
> und in den neuen FPGAs ist es sicher viel schlimmer.
Warum sollte das so sein?
Die FPGAs sind sozusagen Zugpferde für neue kleinere Technologieknoten
bzw. auch stark daran interessiert wegen der Integrationsdichte
(Spartan-6 45nm -> Virtex-7 US+ 14nm). Aufgrund obiger These komme ich
auf diesen Schluss.
Tim schrieb:> Ich kenne Leute, die noch einen Trimmprozess fahren, nur damit sowas wie> UART funktioniert.
Wenn ich in einem FPGA so einen Oszillator nähme und einen UART drauf
fahren müsste, dann würde ich dafür sorgen, dass ein UART-Frame mit
einem definierten Sync-Wort beginnt, damit ich was zum laufenden Nach-
und Neujustieren meines Takts habe.
Tim schrieb:> Je kleiner der Node desto größer werden in der Regel die Schwankungen.
Du meinst hier jetzt aber die Schwankungen von Bauteil zu Bauteil, oder?
Lothar M. schrieb:> und einen UART drauf> fahren müsste,
also ein richtiger UART braucht keinen hochstabilen Takt. Es ist ja ein
asynchrones Schaltwerk. Man braucht nur ungefähr den Takt und wer sollte
einen guten Faktor 3 höher sein, als das was kommt. Der Rest ist
Interpretation.
Thread beobachten
Seitenaufteilung abschalten