Du nimmst ein Register her und da addierst du mit jedem 50MHz clk entweder eine Konstante A drauf, es sei denn, der Wert in deinem Register ist groesser oder gleich als die Konstante B. Wenn dem so ist, dann ziehst du die Konstante C ab, anstatt A zu addieren und toggelst deinen Ausgang.
Beispiel fuer den PAL Farbhilfstraeger:
A=709379
B=0x400000
C=3290621
Du nimmst ein Register her und da addierst du mit jedem 50MHz clk
entweder eine Konstante A drauf, es sei denn, der Wert in deinem
Register ist groesser oder gleich als die Konstante B. Wenn dem so ist,
dann ziehst du die Konstante C ab, anstatt A zu addieren und toggelst
deinen Ausgang.
Beispiel fuer den PAL Farbhilfstraeger:
A=709379
B=0x400000
C=3290621
Jittert halt etwas...
Gruss
WK
1
architecturertlofblink01is
2
constantCLK_FREQ:integer:=50000000;
3
constantA:integer:=709379;
4
constantB:integer:=4194304;
5
constantC:integer:=3290621;
6
7
signalcnt:unsigned(24downto0);
8
signalblink:std_logic;
9
10
begin
11
process(clk,sw0)
12
begin
13
ifrising_edge(clk)then
14
15
ifcnt>=Bthen
16
cnt<=cnt-C;
17
blink<=notblink;
18
else
19
cnt<=cnt+A;
20
endif;
21
endif;
22
endprocess;
23
led0<=blink;
24
led2<=notblink;
25
endrtl;
Cool, das geht ja schonmal prima!
Wie kommt man nun aber auf die Werte für A/B/C ?
Mit einem starken Jitter kannst du jede erzeugen, DDS nach Bresenham.
Ohne relevanten Jitter nur in dem du einen DDS gesteuerten Sinusgenerator baust und dessen Nulldurchgänge durch einen Komparator wieder in Digitalsignale zurückwandelst, also durch hinzufügen von Analogtechnik.
Der Frequenzzähler mag ja die richtige Frequenz anzeigen, aber
das ist auch schon das höchste der Gefühle. Digitalinskis mag
das zufriedenstellen, Analogies nicht.
woarn liegt der Jitter?
theoretisch müsste es doch immer dasselbe ergebnis liefern.
Ich messe hier eine Abweichung von 20.4nS.
Frequenz ist ansonsten stabil: 4.43351Mhz
ich finde das signal sieht garnicht so schlecht aus...
immerhin sind die takte auf der originalen hardware (aus den 70ern) extrem schlecht und haben garnix mehr mit rechteck zutun, trotzdem läuft es...
Interessant wäre jetzt zu wissen: stört der 20ns Jitter beim PAL Takt?
Würde man das auf der TV/Monitor Ausgabe sehen?
Die anderen Takte sind recht unproblematisch...
PS: das scope WAR mal ein 50MHz, ist umgerüstet auf 100MHz...
Interessant wäre jetzt zu wissen: stört der 20ns Jitter beim PAL Takt?
Würde man das auf der TV/Monitor Ausgabe sehen?
Wenn du bei einer analogen FBAS Erzeugung so ein Signal statt dem Originaltakt einspeisen wuerdest, wuerde das sicher fuerchterlich aussehen.
Aber natuerlich kann man ein wunderschoenes, voellig normkonformes PAL-Signal aus 50MHz erzeugen. Sogar aus 27MHz. Millionen Settopboxen und wahrscheinlich auch DVD-Player zeigen das.
Was soll denn das ganze werden, wenns fertig ist?
Ich bin ein Fan von den uralten 8 Bit ATARI Computer...
Ich entwerfe gerade ein neues Mainboard für den 800XL.
Dort kommt ein FPGA drauf um diverse TTLs zu ersetzen.
Daher wäre naheliegend, von diesem auch gleich die Takte zu erzeugen.
Du nimmst ein Register her und da addierst du mit jedem 50MHz clk
entweder eine Konstante A drauf, es sei denn, der Wert in deinem
Register ist groesser oder gleich als die Konstante B. Wenn dem so ist,
dann ziehst du die Konstante C ab, anstatt A zu addieren und toggelst
deinen Ausgang.
Beispiel fuer den PAL Farbhilfstraeger:
A=709379
B=0x400000
C=3290621
Jittert halt etwas...
Gruss
WK
Kannst Du mir die Formel nennen wie man A/B/C berechnet?
(Für andere Frequenzen)
Hehe, hier fliegt noch ein Atari400 'rum. Der hat noch Folientastatur. Muesst' ich auch mal wieder auspacken...
Willst du den ganzen Digitalkram, also CPU, ANTIC und was es da sonst noch so gab, ins FPGA bringen oder "nur" die Takterzeugung?
Kannst Du mir die Formel nennen wie man A/B/C berechnet?
(Für andere Frequenzen)
Axo, klar:
Guck dir mal den Wert A+C an. Und dann A/(A+C).
Sind hier z.b. 5.63873...
So, und wenn du 50MHz durch 5.63873.. teilst, kommt die doppelte PAL-FHT Frequenz raus. Durch das Toggeln deines Ausgangs wird das dann nochmal durch 2 geteilt.
B muss einfach groesser sein als A+C. Und es wird weniger Gatter im FPGA brauchen, wenn B "guenstig" (also eine 2er Potenz) ist.
Den Jitter könntest du halbieren, indem du von den 50 MHz beide Taktflanken auswertest (sollte bestenfalls bei 50 % Tastverhältnis liegen). Erfordert zwei Prozesse und noch etwas Kombinatorik für das Ausgangssignal und das Zusammenspiel der beiden Prozesse (geeignetes Reset-Signal u. a.).
Hehe, hier fliegt noch ein Atari400 'rum. Der hat noch Folientastatur.
Muesst' ich auch mal wieder auspacken...
Willst du den ganzen Digitalkram, also CPU, ANTIC und was es da sonst
noch so gab, ins FPGA bringen oder "nur" die Takterzeugung?
Gruss
WK
Nein, ich weiss das es möglich ist, einen kompletten Atari im FPGA zu haben,
gibt es schon einige.
Mir geht es nur darum, eine originale Platine zu erstellen mit einigen Erweiterungen und Verbesserungen.
Die alten Atari-Chips bleiben.
Wenn Du den 400er loswerden möchtest,
in unserem Club www.abbuc.de gibt es bestimmt Interessenten!
Ich werde morgen mal den FPGA-PAL Takt in den Atari einspeisen und schauen, wie das Bild sich verhält.
Den Jitter könntest du halbieren, indem du von den 50 MHz beide
Taktflanken auswertest (sollte bestenfalls bei 50 % Tastverhältnis
liegen). Erfordert zwei Prozesse und noch etwas Kombinatorik für das
Ausgangssignal und das Zusammenspiel der beiden Prozesse (geeignetes
Reset-Signal u. a.).
halbieren. ok.
ich verstehe aber immer noch nicht, wodurch diese Abweichungen entstehen!
aus der Logik her finde ich keine Gründe das die Frequenz ziemlich präzise abweicht.
Ich werde morgen mal den FPGA-PAL Takt in den Atari einspeisen und
schauen, wie das Bild sich verhält.
Das wird wahrscheinlich arg gruselig. Aber jenachdem wie die Originalschaltung aussieht, wird man da sicher ein brauchbareres Signal per DDS, primitv-DAC und nem Tiefpass basteln koennen.
Ich werde morgen mal den FPGA-PAL Takt in den Atari einspeisen und
schauen, wie das Bild sich verhält.
Das wird wahrscheinlich arg gruselig. Aber jenachdem wie die
Originalschaltung aussieht, wird man da sicher ein brauchbareres Signal
per DDS, primitv-DAC und nem Tiefpass basteln koennen.
Gruss
WK
Das Pal Signal wird so wie im bild erzeugt.
Wie sind denn die Erfahrungen mit diesen programmierbaren Quarzoszillatoren?
Hat die jemand schon erfolgreich im Einsatz?
ich verstehe aber immer noch nicht, wodurch diese Abweichungen
entstehen!
Stell dir eine z.B. Gasheizung vor. Da ist der Brenner entweder an oder halt aus.
Bei real existierenden Gasheizungen ist's kein Problem, eine gemuetliche Zimmertemperatur von z.b. dauerhaft exakt 21°C zu erreichen, wenn der Brenner zu "beliebigen" Zeitpunkten z.b. von einem Thermostat gesteuert an- und abgeschaltet werden kann.
Wenn du jetzt aber sagst: Der Brenner kann immer nur 1x pro Tag an- oder abgeschaltet werden, z.b. immer genau um 20.15Uhr dann wirst du im Mittel immernoch irgendwie die 21°C erreichen, kann aber passieren, dass die Bude doch gegen 20.14 ziemlich ausgekuehlt ist und am naechsten Tag gegen 20.14 dafuer ziemlich heiss, weil der Brenner ja 24h an war.
Genau sowas hast du in deinem FPGA. Du kannst das 4.43 MHz Signal am FPGA-Ausgang nicht zu beliebigen Zeitpunkten schalten, sondern nur alle 20ns. Daher der Jitter.
Genau sowas hast du in deinem FPGA. Du kannst das 4.43 MHz Signal am
FPGA-Ausgang nicht zu beliebigen Zeitpunkten schalten, sondern nur alle
20ns. Daher der Jitter.
Gruss
WK
also wenn ich dem fpga anstatt 50Mhz nun 200Mhz spendieren würde, wäre der Jitter auch kleiner,oder?
also wenn ich dem fpga anstatt 50Mhz nun 200Mhz spendieren würde, wäre
der Jitter auch kleiner,oder?
Kannst auch per FPGA interner PLL deinen Takt erhoehen. Ist halt grad bei den Farbhilfstraegern etwas knifflig, weil die mit Absicht so krumme Frequenzen haben.
Aus der Schaltung werd' ich nicht so recht schlau. Der Y1 muesste ja dann ein 17.7x (also 4xPAL) Quarz sein, und die Schaltung um Y2/Q6 kommt mir vor, wie ein Bandfilter...
Genau sowas hast du in deinem FPGA. Du kannst das 4.43 MHz Signal am
FPGA-Ausgang nicht zu beliebigen Zeitpunkten schalten, sondern nur alle
20ns. Daher der Jitter.
Gruss
WK
also wenn ich dem fpga anstatt 50Mhz nun 200Mhz spendieren würde, wäre
der Jitter auch kleiner,oder?
Am besten nachmessen. Das richtig hinzubekommen, dürfte evtl. schwieriger als das Ausgangsproblem sein. Eine sehr stabile externe Freqenzbasis wäre schonmal nötig, dann: https://github.com/dgatf/logic_analyzer_rp2040
Noch besser: Mach´ dir erstmal Gedanken wie genau es sein muss. Spart erheblich Arbeit!
OK, aber das ist fuer mich immernoch kein richtiger Oszillator. Da schwingt doch nix von alleine, das wird bestenfalls von dem anderen Takt (NTSC?) geteilt durch 4 angestossen. Da musste dir mal die Frequenz und den Kurvenverlauf am Collector vom Q6 angucken.
Und mal schauen, ob beide Takte phasenstarr zueinander sind.
Koennten ein Verhaeltnis von 4:5 untereinander haben. Aber dann ist mindestens einer der Farbhilfstraeger schon heftig daneben.
Sowas, wie da gemacht wird, ist kein guter Kandidat, um's in ein FPGA zu giessen.
So, mit Kaffee im Kopp und Backwaren in der Plauze daemmerts mir so langsam.
Ich erinnere mich dunkel an Latrinengeruechte von damals (Das Atari-Zeugs war bei mir so vor 40 Jahren), dass die PAL Ataris etwas langsamer sein sollten als die NTSC Ataris.
Und da scheint mir tatsaechlich auch was dranzusein.
Da wird anscheinend an den Stellen im Atari, wo im (NTSC)Original mit der NTSC-Farbhilfstraegerfrequenz gearbeitet wird, mit PAL-FHT Frequenz mal 0.8 gearbeitet. Das liegt in der Naehe vom NTSC, aber ein bisschen drunter.
Also sollte der Y1 Quarz in deinem 1. Schaltbild 3.546895MHz haben.
Das wird dann im 74LS74 durch 4 auf 886.72375kHz runtergeteilt und mit der Schaltung um Y2/Q6/L8/C111 wieder verfuenffacht. Dann ist's der PAL-FHT mit idealerweise 4.43361875MHz (Die vielen Nachkommastellen schreibe ich nicht aus Spass an der Freud').
Ich waere da ganz vorsichtig mit so "Verbesserungen" von Originalschaltungen, insbesondere, wenn sie eben so historische Hintergruende haben, die nicht jedem (insbesondere z.B. mir) auf Anhieb klar sind.
Wenns unbedingt sein muss, wuerde ich gucken, dass ich mit so einem 28.37516MHz Quarz/Oszillator in's FPGA reingehe, die Frequenz per FPGA interner PLL ggf. noch vervielfache und dann daraus die anderen Frequenzen ableite.
Nur seh' ich da eh nicht soviel Bonus, denn was du da an TTL-Gattern durchs FPGA einsparst, wirst du doch durch Pegelwandler wieder drauflegen muessen...
Das ist doch alles noch 5V Logik, die kann doch kein normales FPGA.
Programmierbare Oszillatoren wie den Si570 gibt es, kann man kaufen, funktioniert.
Man kann extern einen Quarz passender Frequenz bestücken und die normale interne PLL erzeugt die gesuchten Frequenzen.
Man kann 50 MHz und eine fractional PLL nehmen, sowas haben manche FPGAs eingebaut, gibt es aber auch extern als Baustein.
Man kann die 50 MHz extern nehmen und intern mit der PLL vervielfachen. Wenn man dann 500 MHz hat im FPGA kann man wie hier diskutiert den Takt mit deutlich kleinerem Fehler/Jitter erzeugen.
Man kann mehrere Quarze verbauen die die passenden Frequenzen liefern. Das ist vielleicht günstiger als ein FPGA mit fractional PLL oder eine externe PLL die das kann. Aber das ist dann nicht phasenstarr.
So, mit Kaffee im Kopp und Backwaren in der Plauze daemmerts mir so
langsam.
Ich erinnere mich dunkel an Latrinengeruechte von damals (Das
Atari-Zeugs war bei mir so vor 40 Jahren), dass die PAL Ataris etwas
langsamer sein sollten als die NTSC Ataris.
ja das stimmt, die NTSC Ataris laufen mit 1.79Mhz CPU Takt,
die PAL/SECAM Geräte laufen mit 1.77MHz.
Bin noch nicht dazu gekommen, die Takte am echten Atari zu probieren.
Konnte aber schonmal alle benötigten Takte erzeugen.
Nun noch eine Sache:
Da auf meinem neuen Atari800XL Layout bereits ein 9572 PLD für MMU/ROM Sachen drauf ist, wäre es natürlich ideal, wenn dieses PLD die Takterzeugung erledigen könnte.
Da PLDs jedoch keinen eigenen Takt haben, müsste ich die 50MHz doch einfach nur einspeisen, oder?
Da PLDs jedoch keinen eigenen Takt haben, müsste ich die 50MHz doch
einfach nur einspeisen, oder?
Aeeeh - auch FPGAs haben keinen (fuer dich hier nutzbaren) "eigenen Takt".
Da musst du genauso einspeisen. FPGAs haben aber oft PLLs, die dir in Sachen Jitterarmut weiterhelfen koennten.
Ich wuerde aber vorher noch mal stark in mich bzw. in die Unterlagen/Plaene zum Atari gehen und mal nicht nur die "rohen" Frequenzen rausfinden, die du gerne erzeugen willst, sondern auch deren interen Zusammenhaenge (wer muss mit wem in welcher Phasenbeziehung stehen), max/min dutycycle und wo irgend moeglich jitteranforderungen. (Geheimtip: Da bei PAL und NTSC die Farbe ueber die Phasenlage des FHT uebertragen wird, sollten die moeglichst wenig jittern).
Erst dann gucken, aus welchen Frequenzen mit welchen Chipsen du die erzeugen kannst.
Moin,
Aeeeh - auch FPGAs haben keinen (fuer dich hier nutzbaren) "eigenen
Takt".
Na was ich meine im Gegensatz zum PLD müssen FPGAs doch einen Takt haben.
Da musst du genauso einspeisen. FPGAs haben aber oft PLLs, die dir in
Sachen Jitterarmut weiterhelfen koennten.
mit PLLs im FPGA hab ich noch nie was gemacht, klingt interessant.
Ich wuerde aber vorher noch mal stark in mich bzw. in die
Unterlagen/Plaene zum Atari gehen und mal nicht nur die "rohen"
Frequenzen rausfinden, die du gerne erzeugen willst, sondern auch deren
interen Zusammenhaenge (wer muss mit wem in welcher Phasenbeziehung
stehen), max/min dutycycle und wo irgend moeglich jitteranforderungen.
(Geheimtip: Da bei PAL und NTSC die Farbe ueber die Phasenlage des FHT
uebertragen wird, sollten die moeglichst wenig jittern).
Sollten die beiden Takte für PAL und für den Systemtakt - wenn sie beide aus dem FPGA kommen - nicht synchron sein?
Erst dann gucken, aus welchen Frequenzen mit welchen Chipsen du die
erzeugen kannst.
Ich habe gestern erstmal einen 800XL in original Zustand aufgebaut,
vielleicht komme ich heute noch dazu, die beiden Takte da einzuspeisen,
dann mal schauen wie bunt das Bild wird :-)
Sollten die beiden Takte für PAL und für den Systemtakt - wenn sie beide
aus dem FPGA kommen - nicht synchron sein?
Naja, so ganz synchron ists schwierig. Ich wuerde halt schauen, den PAL-FHT eben moeglichst "glatt" aus einem Quarztakt/einer PLL zu teilen. Beim Systemtakt waere mutmasslich ein Jitter nicht so schnell sichtbar.
Ich wuerde mal prophezeien, dass du da bei der Darstellung von grossen, bunten Flaechen irgendwelche komischen Muster drinnen sehen wirst und nicht eine gleichmaessig farbige Flaeche.
Kannst ja mal Foddo machen und hier reinstellen, wenns "interessant" aussieht ;-)
Sollten die beiden Takte für PAL und für den Systemtakt - wenn sie beide
aus dem FPGA kommen - nicht synchron sein?
Naja, so ganz synchron ists schwierig. Ich wuerde halt schauen, den
PAL-FHT eben moeglichst "glatt" aus einem Quarztakt/einer PLL zu teilen.
Beim Systemtakt waere mutmasslich ein Jitter nicht so schnell sichtbar.
Ich wuerde mal prophezeien, dass du da bei der Darstellung von grossen,
bunten Flaechen irgendwelche komischen Muster drinnen sehen wirst und
nicht eine gleichmaessig farbige Flaeche.
Kannst ja mal Foddo machen und hier reinstellen, wenns "interessant"
aussieht ;-)
Gruss
WK
WOW :-)
Habe gerade beide Takte auf dem Atari getrennt und die neuen vom FPGA eingespeist: Das Bild ist absolut sauber, sogar von der Farbe her völlig exakt! Selbst wenn ich den Systemtakt noch etwas höher lege (bis knapp unter 2Mhz CPU Takt) ist das Bild noch sauber.
Ist natürlich nicht Sinn und Zweck den hochzutakten...
Das schwarz-weiss Foto ist mit FPGA-Systemtakt und ATARI-PAL Takt,
, die laufen da dann wohl nicht synchron.
Die farbigen Bilder sind mit beiden Takten vom FPGA.
Klasse!
Blöd nur, das mein kleines FPGA Board nicht ins EEPROM speichert, wie war das nochmal bei Quartus? (Lange her...)
WK: ich danke vor allem Dir für die super Hilfe!
freu mich!
Blöd nur, das mein kleines FPGA Board nicht ins EEPROM speichert, wie
war das nochmal bei Quartus? (Lange her...)
Same here - iirc kamen da ausm Quartus 2 verschiedene Fileformate, und fuer's flashen wurde das FPGA so konfiguriert, dass das Config-EEPROM irgendwie via JTAG uebers FPGA beschreibbar war...
Als ich damit gewerkelt habe, hiess Raider zwar schon Twix, aber Altera noch nicht Intel.
Viel Erfolg :-)
Blöd nur, das mein kleines FPGA Board nicht ins EEPROM speichert, wie
war das nochmal bei Quartus? (Lange her...)
aus der Erinnerung: dazu muss dein USB-Blaster Kabel in den anderen Wannenstecker.
Dann im Programmer die Config-Methode auf Active Serial. Der Rest sollte sich ergeben...
Blöd nur, das mein kleines FPGA Board nicht ins EEPROM speichert, wie
war das nochmal bei Quartus? (Lange her...)
aus der Erinnerung: dazu muss dein USB-Blaster Kabel in den anderen
Wannenstecker.
Dann im Programmer die Config-Methode auf Active Serial. Der Rest sollte
sich ergeben...
Ja das funktioniert.
Mich wundert es nur etwas, habe mal ein eigenes FPGA Board entwickelt auch mit einem alten Altera plus EEPROM da kann ich immer per JTAG programmieren und es bleibt.
Da diese Chips ja inzwisschen abgekündigt bzw. von Intel nicht mehr unterstützt werden, kann ich auch nur Quartus 11 benutzen.
WK: Als ich damit gewerkelt habe, hiess Raider zwar schon Twix, aber Altera
noch nicht Intel.
Raider war auch viel leckerer :-)
Ist das evt. eine Einstellung im Code oder im Quartus selber?
gibt es denn Unterschiede von 11 zu 13 die es lohnen, zu wechseln?
Ich denke ich werde das geplante 9572 auf dem neuen Atari Board gleich von vorneherein duch ein Altera FPGA ersetzen. Habe Zeiwfel das alles an Logik und Takterzeugung da reinpassen wird...
Ist denn eine JTAG-Daysi-Chain mit einem 95144 und einem Altera auch möglich oder besser 2 Programmier-Anschlüsse verwenden?
Ist denn eine JTAG-Daysi-Chain mit einem 95144 und einem Altera auch
möglich oder besser 2 Programmier-Anschlüsse verwenden?
Ich war mal mutig und hatte 2 CycloneIII hintereinander in einer JTAG-Daisychain ohne Probleme.
Aber fuer Firmenuebergreifend waere ich nicht mutig genug...
Ist denn eine JTAG-Daysi-Chain mit einem 95144 und einem Altera auch
möglich oder besser 2 Programmier-Anschlüsse verwenden?
Du kannst ja mal beides auf deinem Layout vorsehen. Also zwei Programmierstecker und ein paar 0 Ohm Widerstände um beide Chips in eine Chain zu packen. Dann kannst du es ausprobieren.
Theoretisch sollte es ja klappen...
Habe das mal gemacht mit einem Lattice MachXO und einem TI TMS320C28... Der TI DSP brauchte einen extra Pull-(weiss nicht mehr) Widerstand an einem Programmierpin, damit er überhaupt im JTAG Modus war und so auf Bypass gestellt werden konnte.
... um dann zu sehen, dass entweder das Ausprobieren oder das Platzieren
des zweiten Steckers Zeitverschwendung war (?)
Eine selten dämliche Antwort.
Kein Hersteller garantiert dir, das JTAG funktioniert, wenn das noch Fremd-Devices in der Kette stecken.
Außerdem scheitert JTAG nach meiner Erfahrung nicht an der Hardware, sondern an der Software. Praktischerweise unterstützt jeder Hersteller nur sein eigenes Programmierinterface. Und die muß dann spezifischerweise so konfiguriert werden, das die Fremd-Devices auf bypass gestellt werden.
Von daher würde ich es ganz genauso machen: Erstmal eine JTAG-Chain mit 0-Ohm-Widerständen und wenn das nicht klappt, kommen die runter und der zweite Stecker drauf. Solche Alternativbestückungen sind bei Entwicklungsmustern gang und gäbe.
ich werde es so machen:
Das Xilinx PLD bekommt sein eignen JTAG Anschluss
und das Altera FPGA bekommt seine 10pol. Wannenstiftleiste.
So ist es garantiert, daß meine Steckverbindungen vom Xilinx Programmer und vom USBBLASTER passen.
Sonst müsste ich für eine Chain sogar ca. 25cm lange Leiterbahnen von Chip2Chip ziehen. Wer weiss, ob es dann schon wieder andere Probleme wegen der Länge geben könnte.
Um moderne Chips wie z.B. ein SRAM im alten Atari richtig zu betreiben,
muss bei Schreibzugriffen der Systemtakt PHI2 verkürzt werden.
Der originale Takt hat 260ns, der verküzte Takt sollte ca.175ns Hi-Pegel haben.
Dazu hab ich eine Routine fürs FPGA geschrieben, leider gibt es Fehlermeldungen.
1
--PHI2Taktverkürzung
2
process(clk50,phi2)
3
begin
4
ifrising_edge(clk50)then
5
ifrising_edge(phi2)then
6
phi2short<='1';
7
endif;
8
ifcnt6>=9then--9x20ns=180nS
9
phi2short<='0';
10
cnt6<=zero;
11
else
12
cnt6<=cnt6+1;
13
endif;
14
endif;
15
endprocess;
Wenn der Takt vom 50Mhz Osc am FPGA high wird...
wenn der Takt PHI2 high wird...
setze den Ausgang phi2short auf HI
endif
wenn der Zähler cnt6 >= 9 ist (sind 180ns vergangen)
setze den ausgang phi2short auf LOW
setze den Zähler cnt6 auf 0
ansonsten erhöhe den zähle cnt6 um 1
175ns ist natuerlich nicht so pralle, wenn du mit 1/50MHz =20ns Zeitaufloesung arbeitest...
Ein weiterer Grund, dich mal mit den PLLs im FPGA anzufreunden.
Aber wenn du auch mit z.b. 160ns leben koenntest, dann wuerde das ja 8 clocks entsprechen.
Also aenderst du bei deinem entsprechenden "krummen" Teiler die Signalerzeugung halt dahingehend, dass du nicht mit der doppelten Frequenz eine toggle-bit rumschubbern laesst, sondern jeweils, wenn nicht die eine krumme Zahl addiert wird, sondern die andere krumme Zahl subtrahiert wird, du z.b. eine 2. "Variable" auf 0 setzt, die ansonsten immer eins hochzaehlt, solange sie z.b. >= 8 ist. Und solange sie <8 ist, ist phi2short halt nun hi, sonst low...
Was soll aus 2 geschachtelten "if rising_edge(ruelps_clk) bla" denn fuer ein Wunderfitzflipflop synthetisiert werden?
Und auch 74LS123 lassen sich ganz schlecht synthetisieren...
Aber muss ich das ganze nicht in einer schleife mit "if rising edge(clk50)" laufen lassen?
Sonst würde der Zähler doch nur mit PHI2 erhöht werden, oder?
phi2short <= clock7;
...
phi2short <= clock6;
...
Can't resolve multiple constant drivers for net "phi2short"
"Ja, welche von den beiden Zuweisungen gilt denn nun?" will der Synthesizer damit sagen.
Mein Vorschlag: denk dir eine Schaltung aus mit Logik und Flipflops, die das macht, was du willst. Und dann beschreibe diese Schaltung mit der Hardwarebeschreibungssprache VHDL.
Oder andersrum: VHDL ist nicht ein "ich wünsche mir" und der Synthesizer macht das dann. Sondern man darf damit nur Hardware beschreiben, die der Synthesizer auch umsetzen kann. Mehr dazu steht im Synthesizer Users Manual der Toolchain.
oh, nach etwas lesen scheint mir der wait-befehl nur für die simulation
zu sein, oder?
Ja, denn wie gesagt: es gibt nur Logik (LUTs) und Flipflops, aber keine frei konfigurierbaren Verzögerungsglieder in einem FPGA. Von 100% VHDL kannst du höchstens 10% tatsächlich auf Hardware abbilden.
Wenn du auf meiner HP ein wenig herumklickst, dann siehst schnell, warum der RTL-Schaltplan so wichtig ist: du bekommst da schnell einen Überblick, ob der Synthesizer deine Schaltungsbeschreibung so verstanden hat, wie du sie gemeint hast.
Wenn du auf meiner HP ein wenig herumklickst, dann siehst schnell, warum
der RTL-Schaltplan so wichtig ist: du bekommst da schnell einen
Überblick, ob der Synthesizer deine Schaltungsbeschreibung so verstanden
hat, wie du sie gemeint hast.
Was mir hier so ein bisschen aufgefallen ist - ganz allgemein:
Beim Design von so Zeugs im FPGA vs. mit einem Haufen TTL/CMOS-Chips gibts ein paar essentielle Unterschiede.
Einer davon ist z.b. dass man im FPGA mit moeglichst wenig "echten" Clock-Signalen auskommen muss/soll. Dafuer viel mehr mit so Clock-enable-artigen Signalen arbeitet. Die "echten" Clk-Signale werden im FPGA ja auch in ganz anderen "Leitungsstraengen" geroutet. Von denen gibts auch viel weniger.
In TTL/CMOS-Logik kannst du z.b. prima irgendwelche elendig langen ripple-carry-counter basteln, ohne dass das zu Problemem fuehren muss, siehe z.b. 4040,4024,4060,...
Im FPGA ists ziemlich unmoeglich/unpraktisch/bescheuert, einfach so den Ausgang des einen T-Flipflops als clk-signal fuer das naechste herzunehmen. Da nimmt man eher an beiden Flipflops den selben clk und am 2. Flipflop ein zusaetzliches "clk-enable" aus dem 1. Flipflop, usw.
Was mir hier so ein bisschen aufgefallen ist - ganz allgemein:
Beim Design von so Zeugs im FPGA vs. mit einem Haufen TTL/CMOS-Chips
gibts ein paar essentielle Unterschiede.
Einer davon ist z.b. dass man im FPGA mit moeglichst wenig "echten"
Clock-Signalen auskommen muss/soll. Dafuer viel mehr mit so
Clock-enable-artigen Signalen arbeitet. Die "echten" Clk-Signale werden
im FPGA ja auch in ganz anderen "Leitungsstraengen" geroutet. Von denen
gibts auch viel weniger.
In TTL/CMOS-Logik kannst du z.b. prima irgendwelche elendig langen
ripple-carry-counter basteln, ohne dass das zu Problemem fuehren muss,
siehe z.b. 4040,4024,4060,...
Im FPGA ists ziemlich unmoeglich/unpraktisch/bescheuert, einfach so den
Ausgang des einen T-Flipflops als clk-signal fuer das naechste
herzunehmen. Da nimmt man eher an beiden Flipflops den selben clk und am
2. Flipflop ein zusaetzliches "clk-enable" aus dem 1. Flipflop, usw.
Gruss
WK
Ich verstehe so viel noch nicht vom VHDL, daher habt bitte Verständnis.
Ich gebe mir ja Mühe das alles zu verstehen, aber manche Dinge erscheinen mir nicht so logisch. Mehrere Clocks?
Ich würd mal sagen, das FPGA hat nur einen echten Clock, clk50.
Das PHI2 nun in meinem Falle auch ein Takt ist, ist fürs FPGA nicht relevant, das sollte nur einen wechselnden Eingang auswerten.
Es ist wirklich nicht einfach, wenn man nur Basic/Assembler/C++/Python und Gal-Programmierung kann. Ohne Anderen Leuten die einem Hilfestellung geben, kommt man mit VHDL nicht voran. Nur lesen bringt hier nicht so viel wie bei anderen Programmiersprachen.
In meinem Besipiel wäre es z.B. ideal, wenn man
if rising_edge(clk50) then
if rising_edge(PHI2) then
...
schreiben könnte. Die Lösung mit
if phi2 = '1' ist nicht optimal...
Mehrere Clocks?
Ich würd mal sagen, das FPGA hat nur einen echten Clock, clk50.
Das PHI2 nun in meinem Falle auch ein Takt ist, ist fürs FPGA nicht
relevant, das sollte nur einen wechselnden Eingang auswerten.
Ein paar "richtige" Clks koennen schon in einem FPGA vorkommen.
Aber dann hast du das ja schon mal prinzipiell richtig erkannt.
Das habe ich ja total übersehen!
Ja DAS funktioniert wie es soll !
Super! Grade mit dem originalen Takt aus dem Atari erzeugt und gemessen: 188ns ! Damit kann man was machen.
Müssen nur noch ein paar 47R Serienwiderstände an die 3 Ausgänge (3.54MHz Systemtakt, 4.433Mhz PAL Takt und PHI2short Takt) denn die überschwinger sind schon heftig.
Danke Dir! Jetzt verstehe ich die Logik auch, hatte ähnlich gedacht aber invertiert, geodert und um 3 Ecken :-)
Bin mir nicht sicher, ob ich folgendes aus den bisherigen Posts herausgelesen habe:
clk50 und phi2 sind asynchron? Dann muss sichergestellt werden, dass phi2 einsynchronisiert und auch nicht repliziert wird, also alle Zählerbits von counter sowie phishort das gleiche Signal phi2 sehen.
Ich würde dazu ein phi2_50 auf die 50 MHz synchronisieren mit zusätzlichem Attribut gegen Replikation und in obigem Prozess anstelle von phi2 als Enable nehmen.
Wichtig auch, Replikation zu vermeiden! Das stand hier bislang nicht.
Bin mir nicht sicher, ob ich folgendes aus den bisherigen Posts
herausgelesen habe:
clk50 und phi2 sind asynchron? Dann muss sichergestellt werden, dass
phi2 einsynchronisiert und auch nicht repliziert wird, also alle
Zählerbits von counter sowie phishort das gleiche Signal phi2 sehen.
Ich würde dazu ein phi2_50 auf die 50 MHz synchronisieren mit
zusätzlichem Attribut gegen Replikation und in obigem Prozess anstelle
von phi2 als Enable nehmen.
Wichtig auch, Replikation zu vermeiden! Das stand hier bislang nicht.
Es ist so:
Das FPGA erzeugt aus dem 50MHz Takt zum einen den PAL Takt von 4.433Mhz sowie den Systemtakt von 3.54MHz. Dieser Systemtakt geht in den Grafikchip vom Atari und wird als PHI0 dort wieder ausgegeben.
Die 6502 bekommt diesen 3.54MHz PHI0 Takt und teilt ihn intern, raus kommt dann PHI2.
Somit müsste PHI2 synchron mit den 50MHz sein.
Zu dem Jitter auf beiden Takten:
Da der Jitter in regelmäßigen Abständen auftritt, müsste man doch quasi mitzählen und beim "Jitter-Moment" den Takt um 20ns verkürzen, oder würde das neue anderes Jittern erzeugen?
(Das Jittern stört in diesem Falle nicht, schön ist es trotzdem nicht)
Weiss jemand:
gibt es einen FPGA Recompiler?
Also FPGA auslesen und in Code umwandeln?
Radio Jerewan schrieb:
Im Prinzip ja, aber ...
Wenn das Auslesen möglich ist, kannst du aus einer so erhaltenen (unleserlichen) Spaghetti-Netzliste oder -EDIF auch (unleserlichen) Spaghetti-VHDL-Code erzeugen. Alle Signale, Labels etc. werden durchnummeriert. Was hättest du davon? Source-Code kommt jedenfalls nicht heraus. Das ist eine Einbahnstraße.
Das Verfahren findet aber schon seine Anwendung. Wenn du eine Netz- oder EDIF-Liste zurück in z. B. VHDL wandelst, kannst du diesen neu erzeugten scheinbaren Quellcode deinem Kunden ausliefern ohne die originären Sourcen aus dem Haus zu geben. Man benötigt nur noch einen lesbaren Wrapper sowie ein Package für das Interface, damit der Kunde das in seine Gesamtanwendung einbinden kann.
Man kann auch alles aufwändig verkrypten, wenn man Bedenken hat, dass der Kunde dieses Ungetüm in eine geeignete Source bringen kann. Wenn er das hinbekommt, könnte er den Core aber auch gleich selbst entwickeln.
Ich verstehe so viel noch nicht vom VHDL, daher habt bitte Verständnis.
Wir haben alle mal klein angefangen...
Hallo Rick,
hast Du evt. ne Idde um das Jittern zu entfernen?
Da der Jitter in regelmäßigen Abständen auftritt, müsste man doch quasi
mitzählen und beim "Jitter-Moment" den Takt um 20ns verkürzen, oder
würde das neue anderes Jittern erzeugen?
(Das Jittern stört in diesem Falle nicht, schön ist es trotzdem nicht)
beim "Jitter-Moment" den Takt um 20ns verkürzen, oder
würde das neue anderes Jittern erzeugen?
Wenn du jeden "Jitter-Moment" um 20ns verkürzt, dann wirste irgendwann mal mit der Frequenz daneben liegen. Die Frequenz stimmt ja nur deshalb im langfristigen Mittel, /weil/ manche Perioden des Signals kuerzer oder laenger sind.
Wenns ohne neue HW gehen soll, nimm eine (oder 2 der FPGA-internen) PLL(s in serie), vervielfache damit die 50MHz, und teile dann den erhoehten Takt um entsprechend mehr wieder runter.
So kommste ohne Schaltungsaenderung von deinen 20ns auf weniger.
Wie hoch könnte man denn den internen Takt erhöhen?
Kommt ganz stark drauf an
welches FPGA?
welcher Speedgrade (mach mal ein Foto auf dem man die Beschriftung auf dem FPGA lesen kann)?
wie viel Logik zwischen den Registern durchlaufen werden soll in einem Takt. Mit nur einem kurzen Zähler und wenig Logik sind da auch in alten FPGAs teilweise 200 MHz und mehr möglich. Aber das sagt dir ja auch Quartus. Lass das Design bauen und gucke was da als f_max reportet wird. Du kannst auch die Designeinstellungen auf Speed optimieren. Und dann kannst du deinen Takt mal constrainen und gucken bis zu welchem Takt dein FPGA das Timing schafft. Wenn du hier dein Design als .zip anhängst oder mir per Mail schickst, dann mache ich das gerne für dich.
Du hättest auch einfach dein Projekt als .zip anhängen können, aber das wäre wohl zu einfach gewesen.
Jedenfalls schafft das Design mit PLL 168 MHz. Es limitiert eben der 24 Bit Zähler/Akku von dem subtrahiert und zu dem addiert wird. Man könnte natürlich auch einen IP dafür verwenden, ja die nutzen dann die DSP Elemente, aber wieviel das bringt weiß ich nicht. Teste ich vielleicht die Tage mal. Jedenfalls sind sehr einfach 150 MHz machbar.
Du hättest auch einfach dein Projekt als .zip anhängen können, aber das
wäre wohl zu einfach gewesen.
Ja stimmt, jetzt wo Du's sagst...
Jedenfalls schafft das Design mit PLL 168 MHz. Es limitiert eben der 24
Bit Zähler/Akku von dem subtrahiert und zu dem addiert wird. Man könnte
natürlich auch einen IP dafür verwenden, ja die nutzen dann die DSP
Elemente, aber wieviel das bringt weiß ich nicht. Teste ich vielleicht
die Tage mal. Jedenfalls sind sehr einfach 150 MHz machbar.
das bedeutet bei 150MHz intern ist das Jittern nicht 20ns sondern nur 6.6ns?
Und wenn ich dem FPGA anstatt nen 50MHz Oszillator einen 200MHz spendiere?
Schafft der das? Dann müssten intern 600MHz und das Jittern nur noch 1.6ns sein oder kann man das so nicht berechnen?
Nein. Du hast da ja Logik drinnen die den PAL Takt erzeugt. Das ist ein 24 Bit breiter Zähler/Akku. So eine Logik braucht eine gewisse minimale Zeit um zu funktionieren. Da kommt also eine Taktflanke, es wird addiert oder subtrahiert und das muss bis zur nächsten Taktflanke abgeschlossen sein. Und das dauert eben und bestimmt den minimalen Abstand von zwei Taktflanken. Bei diesem FPGA und dieser Logik sind das 168 MHz. Schneller geht der Zähler nicht. Egal wo der Takt herkommt.
Man kann das vielleicht schneller machen indem man DSP Slices verwendet, man kann das schneller machen indem man den Zähler kürzer macht, z. B. 16 Bits statt 24, aber das wird dann eben auch ungenauer. Ist eine Abwägung. Wo der Takt herkommt ist egal. Du kannst extern 168 MHz einspeisen oder intern erzeugen. 150 MHz hatte ich verwendet weil das einfach Faktor 3 ist. Jedenfalls wird der Zähler nicht mit 200 MHz laufen, egal woher die kommen.
Aber hey, es ist eine PLL. Damit kannst du zwar nicht den PAL Takt direkt generieren, aber vermutlich kannst du damit einen ganzzahligen vielfachen Takt generieren der gut genug ist. Es wäre also interessant wie genau der Takt für das PAL am Ende sein muss.
Es wäre also interessant
wie genau der Takt für das PAL am Ende sein muss.
Dieses PAL ist keine Progammable Array Logic, sondern eine Phase Alternate Line. Und da ist's gerade der Trick, dass da die Frequenz "saukrumm" gewaehlt ist und auf wenige Hz genau eingehalten werden sollte :-)
ich brauche 5 verschiedene Frequenzen die aus einem FPGA mit 50Mhz
erzeugt werden sollen,
1: 3.58Mhz
bekomme:
geteilt durch 14=3.57134 Mhz
oder
geteilt durch 13=3.846 Mhz
(rechnerisch, Scope zeigt 4.1xx Mhz an!)
Das Oszilloskop als Frequenzzähler? Da wäre ich vorsichtig.
2: 14.18757 Mhz noch nicht probiert
3: 4.33618 MHz noch nicht probiert
4: 1.77Mhz noch nicht probiert
5: 1.79 Mhz noch nicht probiert
Hast Du mal versucht mit dem MegaWizard eine ALTPLL mit den Wunschfrequenzen zu generieren? Ich hier ein Screenshot, wie das bei einem Cyclone3 aussieht. Ich kenne die Unterschiede zur PLL des Cyclone2 nicht.
Mit der Cyclon3-PLL lassen sich alle Deine Wunschfrequenzen ausreichend genau erzeugen.
Du kannst ja evtl. die 2. PLL für die restlichen Takte nutzen.
Ich wollte es heute mal probieren mit den PLL Takten anstelle der Zähler
dabei ist mir aufgefallen, daß es bei jeden der krummen Frquenzen Fehlermeldungen gibt!
1
CannotimplementtherequestedPLL
2
Cause:Requestedmult/divfactorsnotachievable
Dann hab ich zum testen mal auf ein Cyclone IV umgestellt da geht es!
Die kleinste Frequenz mit dem Cyclone II scheint bei 9.375 Mhz zu sein.
Konnte keine Frequen kleiner einstellen!
Was mich etwas wundert: 1GHz kann er anscheinend erzeugen!
Jedenfalls kommt da keine Fehlermeldung!
EDIT: doch, beim compilieren kommt ne Meldung daß der Cyclone II
max. 250MHz bei 50MHz clkin erzeugen kann.
Hast Du die Möglichkeit bei deinem Cyclone IV mal den PLL Ausgangstakt zu messen ob da auch das Jittern ist?
Cannot implement the requested PLL
Cause: Requested mult/div factors not achievable
Ja, beim Cyclone 2 sind die möglichen Teilerbreiten etwas eingeschränkt, im Vergleich zum 3er oder 4er.
Die kleinste Frequenz mit dem Cyclone II scheint bei 9.375 Mhz zu sein.
Konnte keine Frequen kleiner einstellen!
Die kleinste VCO-Frequenz ist 300 MHz. 300 MHz/32 = 9,375 MHz. Kleinere Takte muß man sich dann außerhalb der PLL erzeugen (z.B. mit einem Ringzähler).
Was mich etwas wundert: 1GHz kann er anscheinend erzeugen!
Das ist ja auch die maximale VCO-Frequenz. Nur wirst du damit nicht viel takten können. Auch wird man diese Frequenz so nicht auf die I/Os routen können.
Hast Du die Möglichkeit bei deinem Cyclone IV mal den PLL Ausgangstakt
zu messen ob da auch das Jittern ist?
Jitter messen kann ich, aber der Cyclone ist im Feld verbaut und vom Evalboard wurde nur eins beschafft. Sonst bin ich eher mit Lattice und Xilinx unterwegs...
OK, alzont mal fuer 4.43...MHz Ausgang mit 50MHz Eingang und Primfaktorzerlegung der Multiplikations- und Teilerfaktoren:
Allgemein:
1
4.43361875MHz = 50 MHz * (11 * 64489) / (2⁹ * 5⁶)
Jitter machen die Faktoren "oben" im Bruch, also 11 und 64489.
64489 kann die PLL nicht, aber 11.
Also wuerde ich die PLL so betreiben, dass die die 50MHz Eingangstakt erstmal ver 11facht, d.h. der VCO auf 550MHz schwingt.
Dann noch moeglichst "viel" wieder innerhalb der PLL teilen, also z.b. durch 5².
Kommen also 22MHz aus der PLL raus.
Dann den Rest, also
1
64489 / (2⁹ * 5⁴)
wieder mit einer Konstruktion, wie in meinem 1. Post hier im Thread, erschlagen.
Das jittert nicht nur "etwas" sondern ist für eine genae Frequenz völlig ungeignet. Da müsste erst noch ein Filter und eine analoge PLL dahinter und die verträgt nicht allzuviel jitter, ohne aus dem Tritt zu kommen.
Das jittert nicht nur "etwas" sondern ist für eine genae Frequenz völlig
ungeignet.
Im Mittel ist die Frequenz schon genau. Und ob der Jitter stört, hängt ja wohl immer noch von der Anwendung ab.
Manche machen sogar noch zusätzlich Jitter drauf und das Marketing verkauft es als SSC:
https://de.wikipedia.org/wiki/Spread_Spectrum_Clocking
Naja wäre ja auch nur mal interessant gewesen zu sehen, ob die PLL genauso jittern würde. Ist aber nicht so wichtig,
denn mit WK's 24Bit Zählstufen läuft es genau genug.
Ist wie mit Röhrenverstärkern, auf dem Scope grausig, auf dem Ohr gut.
ach, da hab ich noch eine Frage:
In meinem MMU-Teil sind einige ähnliche Abfragen drin...
Nun könnte man diese Abfragen auch optimiert schreiben,
habe sie jedoch jeweils einzelnd geschrieben wegen der Übersichtlichkeit.
Erkennt der Compiler dies und optimiert das sowieso oder hab ich am Ende doch mehr LUTs usw. verbraucht als nötig?
Ich hab mal aus Spass ChatGPT aufgefordert mir den Clock-Code zu schreiben:
Erste Version ergab einen ungefähren Takt von 4.433...MHz.
Mit DDS soll es wohl ziemlich genau und mit wenig Jitter sein:
Die PLLs lassen sich kaskadieren, um auf die gewünschten Frequenzen zu kommen. Sie müssen natürlich trotzdem ganzzahlig zu erreichen sein. Da braucht es gfs parallele Zweige und es muss natürlich mathematisch aufgehen. Es braucht also das KGV aller Frequenzen. Wurde oben ja schon angedeutet.
Wenn das nicht passt, muss man die Frequenzen hoch oder runterregeln. Das passiert z.B. in FPGAs durch Einsetzen eines rotierenden IO-Delays im Ausgangspfad. Hat man das nicht, baut man eine Doppelinverterkette mit Abgriffpunkt, wie ich es hhier gezeigt habe:
http://www.96khz.org/oldpages/frequencyshifter2.htm
Durch permanentes Rotieren in eine Richung kann man den Takt beschleunigen und bremsen. Ich benutze das, um aus einem 25MHz-Quarz einen perfekten ausgeregelten S/PDIF-Takt zu erzeugen. Die grobe Vorteilung erfolgt mit 25 MHz * 29 / 59 = 12.288 MHz , die alleine schon auf einige ppm stimmen.
Das ist zwar auch nicht pefekt, jittert aber so gut wie nicht. Mit den IO-Delays in FPGAs kann man das auf unter 50ps-Schritten machen.
Mit DDS soll es wohl ziemlich genau und mit wenig Jitter sein:
Die Verwendung eines DDS (Direct Digital Synthesis) kann
dazu beitragen, Jitter zu reduzieren, da es eine präzisere Steuerung
der Ausgangsfrequenz ermöglicht im Vergleich zu einem einfachen Clock
Divider.
Chat-Blödsinn! Eine DDS springt mehr oder weniger schnell zwischen 2 Frequenzen hin und her und hat maximalen Jitter! Im Vergleich wozu soll sie den reduzieren? Chat führt als Vergleich den Devider an, der gar keinen erzeugt! Der Unterschied zwischen Devider und DDS ist, das mittelfristig genaue Treffen der Zielfrequenz.
Eine sinnvolle Aussage des Chats wäre gewesen, in den Phasenvektor zusätzlichen Jitter einzuspeisen - konkret, diesen zu verrauschen - um zu sich sehr schnell ändernden Phasensprüngen zu gelangen, die sich besser filtern lassen.
Erkennt der Compiler dies und optimiert das sowieso oder hab ich am Ende
doch mehr LUTs usw. verbraucht als nötig?
Du kannst das Ergebnis vom Synthesizer ja ansehen als RTL Schema oder einen Schritt weiter (nach dem Mapping) als LUTs, logic-elements oder was auch immer in der Zieltechnologie halt vorhanden ist.
Bei deinem Adressdecoder würde ich mal im Synthesizerreport nachsehen, ob er da 16 bit Vergleicher findet (wegen den kleiner/grösser als) oder ob er da eine Logik draus baut. 16 parallele 16 bit Vergleicher wäre sehr gross.
Ich würde das ganze so schreiben, dass ich von der Adresse nur den relevanten Teil prüfe pro Abfrage. So in etwa so:
Ich hab da noch ein kleines Problemchen mit einem Signal:
mehrere Chips setzen das Signal auf LOW, wird sonst per Pullup HIGH gehalten.
Im FPGA muss ich dieses Signal ebenfalls lesen und schreiben.
Der Ausgang ist als Z definiert.
Nun kann ich ja aber keinen einfachen RR Spannungsteiler davor setzen um aus den 5V 3.3V zu machen, zum nur-lesen wäre das ja ok, aber ich muss den Pin auch LOW schalten können.
Jemand eine Idee wie man das ohne großartike LevelShifter ICs hinbekommen kann? Oder würde ein z.B.47R Serienwiderstand reichen um das FPGA zu schützen? Die FPGAs haben doch sicher an jedem IO ableit-dioden dran, oder?
Hmm, 2 IOs wäre nicht gut.
Gibt es da keine andere Möglichkeit?
Wichtig ist auch, das der Ausgang vom FPGA NUR auf LOW ziehen darf,
wenn der Ausgang HIGH ist, darf das nicht auf das Signal.
Wogegen beim lesen des Signals muss HIGH und LOW gelesen werden.
Vielleicht mit dioden? Mosfets? Logik-Gattern?
Da gibts so ne olle Schaltung mit FET zum Levelshift bei I2C-Bus Signalen. Oder gleich einen entsprechenden Chip dafuer. Dann kriegste sogar umsonst und gratis einen 2. Levelshifter dazu.
Aber ob das dann noch schnell genug ist fuer deinen Bedarf musste selber gucken.
Dieses PAL ist keine Progammable Array Logic, sondern eine Phase
Alternate Line.
Weder, noch.
"PAL" steht für jeden Wissenden nur und ausschliesslich für das Grundprinzip
"PAL-Feld", das eine der effektivsten Tarnvorrichtungen im Universum darstellt.
Das Problem-Anderer-Leute Feld (kurz: PAL-Feld) kann also Dinge aus der Wahrnehmung der Menschen ausblenden. Es beruht auf der angeborenen Neigung der Leute, nichts zu sehen, was sie nicht sehen wollen, nicht erwartet haben oder nicht erklären können. Sie erklären es einfach zum Problem anderer Leute und nehmen es daher einfach nicht wahr. Das PAL-Feld ist durch den natürlichen Hang der Menschen, in allem ein Problem anderer Leute zu sehen, viel einfacher und wirkungsvoller als ein normales Unsichtbarkeitsfeld (und kann obendrein über Jahre hinweg mit einer einfachen Taschenlampen-Batterie betrieben werden).
