krumme Frequenzen aus 50Mhz erzeugen

[Wolfram F. (mega-hz)]

Hallo,

ich brauche 5 verschiedene Frequenzen die aus einem FPGA mit 50Mhz 
erzeugt werden sollen, scheiter aber bereits bei der ersten:

1: 3.58Mhz
  bekomme:
  geteilt durch 14=3.57134 Mhz
  oder
  geteilt durch 13=3.846 Mhz
  (rechnerisch, Scope zeigt 4.1xx Mhz an!)

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

Meine Testroutine:

-- Start of the weird 'hello world' blink:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity blink01 is
port (
  clk  : in std_logic;  -- clock is on 17
  led0  : out std_logic; -- led on 3
  led1  : out std_logic; -- led on 7
  led2  : out std_logic; -- led on 9
  sw0  : in std_logic   -- switch on 114
);
end blink01;

architecture rtl of blink01 is
  constant CLK_FREQ : integer := 50000000;
  constant BLINK_FREQ : integer := 3580000-100000;
  constant CNT_MAX : integer := CLK_FREQ/BLINK_FREQ/2-1;
  
  signal cnt    : unsigned(24 downto 0);
  signal blink  : std_logic;
  
begin

  process(clk, sw0)
  
  begin
    if rising_edge(clk) then
    
        led1 <= '0';
    
      if cnt=CNT_MAX then
        cnt <= (others => '0');
        blink <= not blink;
      else
        cnt <= cnt + 1;
      end if;
    end if;
    
  end process;
  
  
  led0 <= blink;
  led2 <= not blink;
  
end rtl;

weiss jemand wie man so genaue Frequenzen erzeugen kann?

[Florian L. (muut)]

Fractional PLL

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> weiss jemand wie man so genaue Frequenzen erzeugen kann?

SI5351

Wird auch hier im Forum behandelt.

[Dergute W. (derguteweka)]

Moin,

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

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> 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

architecture rtl of blink01 is
  constant CLK_FREQ : integer := 50000000;
  constant A : integer := 709379;
  constant B : integer := 4194304;
  constant C : integer := 3290621;
  
  signal cnt    : unsigned(24 downto 0);
  signal blink  : std_logic;
  
begin
  process(clk, sw0)
  begin
  if rising_edge(clk) then
    
      if cnt >= B then
        cnt <= cnt - C;
        blink <= not blink;
      else
        cnt <= cnt + A;
      end if;
  end if;
  end process;
  led0 <= blink;
  led2 <= not blink;
end rtl;

Cool, das geht ja schonmal prima!
Wie kommt man nun aber auf die Werte für A/B/C ?

[Michael B. (laberkopp)]

Wolfram F. schrieb:
> scheiter aber bereits bei der ersten:

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.

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> Cool, das geht ja schonmal prima!

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.

Dergute W. schrieb:
> Jittert halt etwas...

Ja, a "bisserl" halt ....

[Wolfram F. (mega-hz)]

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

[Mark S. (voltwide)]

Mit 50MHz Abtastung kannst Du eben nur auf 20ns auflösen.
There is no free lunch...

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> Frequenz ist ansonsten stabil: 4.43351Mhz

Ja, das ist die Anzahl der Impulse pro Zeiteinheit. Korrekt
zählen und umschalten kann das FPGA ....

Wastl schrieb:
> Der Frequenzzähler mag ja die richtige Frequenz anzeigen, aber
> das ist auch schon das höchste der Gefühle.

Spektral betrachtet ist das kein Signal das auch nur irgendwie
zufrieden stellt. Ob es für irgendeine Anwendung reicht wage ich
nicht zu beurteilen.

[Wolfram F. (mega-hz)]

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

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> ich finde das signal sieht garnicht so schlecht aus...

Ein bisschen besser würde es aussehen wenn du das Händi
beim Fotographieren horizontal halten würdest.
Aber nicht viel ....

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Wolfram F. (mega-hz)]

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.

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> 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)

[Dergute W. (derguteweka)]

Moin,

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

[Dergute W. (derguteweka)]

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

Gruss
WK

[Kay-Uwe R. (dfias)]

Nebenbei: 50Mhz => 50 MHz

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

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> 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.

[Wolfram F. (mega-hz)]

Kay-Uwe R. schrieb:
> Nebenbei: 50Mhz => 50 MHz
>
> 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.

[Dergute W. (derguteweka)]

Moin,

Wolfram F. schrieb:
> Wenn Du den 400er loswerden möchtest,

Neeeneee, soweit isses noch nicht ;-)

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

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> Wolfram F. schrieb:
>> Wenn Du den 400er loswerden möchtest,
>
> Neeeneee, soweit isses noch nicht ;-)
>
> Wolfram F. schrieb:
>> 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?

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Wolfram F. (mega-hz)]

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

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Wolfram F. (mega-hz)]

nein, Y1 ist der Quarz für den Systemtakt, = 3.54MHz/2
Y2 ist der PAL Takt.

[Joe (Gast)]

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

[Dergute W. (derguteweka)]

Moin,

Wolfram F. schrieb:
> nein, Y1 ist der Quarz für den Systemtakt, = 3.54MHz/2
> Y2 ist der PAL Takt.

Da beschleichen mich starke Zweifel ob der Fehlerfreiheit des 
Schaltplans...

Gruss
WK

[Wolfram F. (mega-hz)]

hier noch ein anderes Bild vom Schaltplan...

[Dergute W. (derguteweka)]

Moin,

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.

Gruss
WK

[Dergute W. (derguteweka)]

Moin,

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

Googeln mit den "richtigen" Frequenzwerten liefert dann sowas wie hier:
https://forums.atariage.com/topic/354864-pal-3546895mhz-crystal-alternative-solutions/

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.

Gruss
WK

[Gustl B. (-gb-)]

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.

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> 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?

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Wolfram F. (mega-hz)]

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

Ansonsten evt. SiT3521.
>
> Gruss
> WK
Gruss,
Wolfram.

[Dergute W. (derguteweka)]

Moin,

Wolfram F. schrieb:
> Na was ich meine im Gegensatz zum PLD müssen FPGAs doch einen Takt
> haben.
Nee, wenns unbedingt sein muss, wuesst' ich nicht, warum man nicht ein 
FPGA auch nur mit reiner Kombinatorik vollstopfen koennte, voellig ohne 
Takt...

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

Wolfram F. schrieb:
> dann mal schauen wie bunt das Bild wird :-)
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

[Christoph Z. (christophz)]

Wastl schrieb:
> Ein bisschen besser würde es aussehen wenn du das Händi
> beim Fotographieren horizontal halten würdest.
> Aber nicht viel ....

Am besten sieht es aus, wenn man den auf dem Foto sichtbaren USB 
Anschluss verwendet. Spart auch ziemlich viel Speicherplatz...

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Moin,
>
> Wolfram F. schrieb:
>> Na was ich meine im Gegensatz zum PLD müssen FPGAs doch einen Takt
>> haben.
> Nee, wenns unbedingt sein muss, wuesst' ich nicht, warum man nicht ein
> FPGA auch nur mit reiner Kombinatorik vollstopfen koennte, voellig ohne
> Takt...
>
> Wolfram F. schrieb:
>> 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.
>
> Wolfram F. schrieb:
>> dann mal schauen wie bunt das Bild wird :-)
> 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!

[Dergute W. (derguteweka)]

Moin,

Hey, gute Neuigkeiten!
Wenns funktioniert, ist ja alles gut. Solange das Moiree nur auf den 
Photos ist und nicht in echt...

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

Gruss
WK

[Markus F. (mfro)]

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

[Wolfram F. (mega-hz)]

Markus F. schrieb:
> Wolfram F. schrieb:
>> 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?

[Markus F. (mfro)]

Wolfram F. schrieb:
> Da diese Chips ja inzwisschen abgekündigt bzw. von Intel nicht mehr
> unterstützt werden, kann ich auch nur Quartus 11 benutzen.

13.0 sp1 ist die letzte Quartus-Version, die das Board unterstützt.

[Wolfram F. (mega-hz)]

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?

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Christoph Z. (christophz)]

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

[Bernd G. (Gast)]

Christoph Z. schrieb:
> Programmierstecker und ein paar 0 Ohm Widerstände um beide Chips in eine
> Chain zu packen. Dann kannst du es ausprobieren.

... um dann zu sehen, dass entweder das Ausprobieren oder das Platzieren 
des zweiten Steckers Zeitverschwendung war (?)

[Rick D. (rickdangerus)]

Bernie schrieb:
> ... 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.

[Wolfram F. (mega-hz)]

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.

[Wolfram F. (mega-hz)]

Brauche Hilfe:

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.

-- PHI2 Taktverkürzung
  process(clk50, phi2)
  begin
    if rising_edge(clk50) then      
      if rising_edge(phi2) then
        phi2short <= '1';
      end if;
      if cnt6 >= 9 then -- 9x20ns = 180nS
        phi2short <= '0';
        cnt6 <= zero;
      else
        cnt6 <= cnt6 +1;
      end if;
    end if;
  end process;

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


bekomme folgende Fehlermeldungen:

Error (10821): HDL error at AtariMainboardFPGA.vhd(150): can't infer register for "phi2short" because its behavior does not match any supported register model
Error (10822): HDL error at AtariMainboardFPGA.vhd(150): couldn't implement registers for assignments on this clock edge
Error (10822): HDL error at AtariMainboardFPGA.vhd(151): couldn't implement registers for assignments on this clock edge
Error: Can't elaborate top-level user hierarchy

BTW: in diversen Harware-Erweiterungen wurde der PHI2 Takt mittels 
74LS123 verkürzt. Ich denke aber man kann das auch gleich im FPGA 
erzeugen.

[Dergute W. (derguteweka)]

Moin,

Wolfram F. schrieb:
> der verküzte Takt sollte ca.175ns Hi-Pegel
> haben.

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

Gruss
WK

[Wolfram F. (mega-hz)]

160ns wäre auch ok.

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?

Verstehe die Fehlermeldungen nicht ganz..

Wie würdest Du das schreiben?

[Dergute W. (derguteweka)]

Moin,

Naja, so ganz grob und fies:

if rising_edge(clk) then
      if cnt >= B then
        cnt <= cnt - C;
        blink <= 0;
      else
        cnt <= cnt + A;
        if (blink < 8) then
            blink <= blink + 1;
        end if;
      end if;
  end if;
phi2short <= not (blink(3));

Die Fehlermeldung besagt halt, dass er keine Wunderfitzregister 
synthetisieren kann.

Gruss
WK

[Wolfram F. (mega-hz)]

so passt das ja nicht. wenn phi2 auf hi geht, darf der ja erst anfangen 
zu zählen...

[Wolfram F. (mega-hz)]

in C würde es so aussehen:

If rising edge(clk50)
  if rising edge (phi2)
    phi2short = '1'
    counter = 0
  endif
  if counter >= 9 // 180ns
    phi2short = '0'
  else
    counter = counter +1
  endif
endif

wie müsste das in VHDL aussehen?

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
>

> phi2short <= not (blink(3));

>
was bedeutet die 3 in Klammern?

[Wolfram F. (mega-hz)]

grrr...
auch dies funktioniert nicht:

  process(phi2)
  begin
      if rising_edge(phi2) then
        clock7 <= '1';
      end if;
  end process;
   phi2short <= clock7;

  process(clk50,phi2short)
  begin
      if rising_edge(clk50) and phi2short = '1' then      
        if cnt6 >= 9 then
          clock6 <= '0';
        else
          cnt6 <= cnt6 +1;
        end if;
      end if;
  end process;
   phi2short <= clock6;  



Error (10028): Can't resolve multiple constant drivers for net "phi2short" at AtariMainboardFPGA.vhd(166)
Error (10029): Constant driver at AtariMainboardFPGA.vhd(154)

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

Wolfram F. schrieb:
> if rising_edge(clk50) then
> ...
>   if rising_edge(phi2) then
Wie würde denn dieses Flipflop aussehen?
Das müsste eines der legendären Configurable-Dual-Clock-Flipflops 
sein...

Wolfram F. schrieb:
> 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 Hardware**beschreibungs**sprache 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.

[Wolfram F. (mega-hz)]

aber es sind doch zwei verschiedene Prozesse,

der eine setzt phi2short auf 1

und der andere auf 0.

mit einem 7474 bekomme ich das theoretisch hin,
wenn rising_edge(phi2) dann setzte den SET eingang.

wenn der zähler bis 9 gekommen ist, setze beim 7474 den CLR.

in ttl hardware also recht einfach

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

Wolfram F. schrieb:
> aber es sind doch zwei verschiedene Prozesse,
> der eine setzt phi2short auf 1
> und der andere auf 0.
Ja, und wie sieht das in der Hardware aus?
Richtig: einfach nur 2 aktive Treiber auf 1 Signal => Buskollision.

> der eine setzt phi2short auf 1
> und der andere auf 0.
> in ttl hardware also recht einfach
Wenn du sowas willst, dann musst du ein RS-Flipflop beschreiben. Das 
geht
1. nicht so einfach, wie du es da grade machst mit 2 Treibern auf 1 
Signal und
2. ist das im FPGA auch nicht ganz trivial, denn damit erzeugst du 
Rückkopplungen in der Logik. Niemand garantiert dir, welche Laufzeiten 
die hat.

Probier mal sowas.
Aber ich bin mir nicht sicher, ob der Synthesizer es schafft, da was 
sinnvolles draus zu machen:

signal q1 : std_logic := 0;
signal q2 : std_logic := 1;
:
:
q1 <= clock6 nand q2; -- RS-FF aus 2 NAND
q2 <= clock7 nand q1;
phi2sshort <= q1;

Du solltest dir hinterher den RTL-Schaltplan ansehen, ob der Synthesizer 
kapiert hat, was da gewollt war.

[Wolfram F. (mega-hz)]

hat er fehlerfrei compiliert.
Allerdings kann ich nicht EDA RTL Simulation aufrufen, ist wohl nicht 
installiert bei meiner Quartus 11 Installation.

Installiere 13.0sp1 jetzt, dann mal sehen

EDIT: Ich bekomme es nicht hin, den Schaltplan zu erzeugen....

[Wolfram F. (mega-hz)]

wie müsste ich denn vorgehen, damit das phi2short von zwei prozessen aus 
gesteuert wird?

[Wolfram F. (mega-hz)]

habe mal folgendes probiert:

  process(clk50,phi2)
  begin
      if rising_edge(phi2) then
        phi2short <= '1';
            wait for 180 ns;
        phi2short <= '0';
      end if;
  end process;

aber auch da bekomme ich eine fehlermeldung:

Error (10533): VHDL Wait Statement error at AtariMainboardFPGA.vhd(152): Wait Statement must contain condition clause with UNTIL keyword

[Wolfram F. (mega-hz)]

oh, nach etwas lesen scheint mir der wait-befehl nur für die simulation 
zu sein, oder?

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

Wolfram F. schrieb:
> Allerdings kann ich nicht EDA RTL Simulation aufrufen
Du sollst den RTL nicht simulieren, sondern den RTL-Schaltplan 
anschauen, ob die Bauteile verbaut wurden, die du da haben wolltest.

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

- http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

[Wolfram F. (mega-hz)]

Lothar M. schrieb:
> Wolfram F. schrieb:
>> Allerdings kann ich nicht EDA RTL Simulation aufrufen
> Du sollst den RTL nicht simulieren, sondern den RTL-Schaltplan
> anschauen, ob die Bauteile verbaut wurden, die du da haben wolltest.
wie und wo ist der eintrag im quartus, um den schaltplan zu sehen?

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

Wolfram F. schrieb:
> wie und wo ist der eintrag im quartus, um den schaltplan zu sehen?
Keine Ahnung, das musst du in der Doku zu dem Ding nachsehen.

Gibt sicher auch Anleitungen dazu:
- https://www.google.com/search?q=quartus+rtl+schematic+viewer

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.

[Wolfram F. (mega-hz)]

ahh, ok.

allerdings gibt es bei deiner routine noch einen fehler:

  process(clk)
  begin
     q1 <= clock6 nand q2; -- RS-FF aus 2 NAND
     q2 <= clock7 nand q1;
     phi2sshort <= q1;
    end process;

Error (10327): VHDL error at blink01.vhd(150): can't determine definition of operator ""nand"" -- found 0 possible definitions

[Wolfram F. (mega-hz)]

ah, hatte q1 und q2 als integer, nun std_logic..
Nun hat das compilieren funktioniert und ich bekomme dieses Ergebnis im 
Schaltplan, siehe bild.

[Wolfram F. (mega-hz)]

wenn ich eine der anderen Taktroutinen einfüge, sieht es schon anders 
aus

[Wolfram F. (mega-hz)]

Lothar M. schrieb:
> 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.
Super Webseite !

[Wolfram F. (mega-hz)]

dies könnte funktionieren:

  process(clk)
  begin
  if rising_edge(clk) then
  if phi2 = '1' then
     temp1 <= '1';
  end if;
  temp2 <= '1';
    if counter >= 9 then
      counter <= 0;
      temp2 <= '0';
    else
      counter <= counter + 1;
    end if;
  end if;
   end process;
   phi2short <= temp1 nand temp2;

[Gustl B. (gustl_b)]

phi2 wird nirgends gesetzt sondern nur abgefragt.
Simuliere deine Schaltung.

[Wolfram F. (mega-hz)]

phi2 ist ein eingang mit 1.77MHz Takt.
Dieser soll auf 180ns verkürzt und als phi2short ausgegeben werden.

noch etwas angepasst:

  
clk50    : in std_logic;  -- IO17 clock 50MHz
phi2      : in std_logic;  -- PHI2 clock 1.77MHz
phi2short : out std_logic; -- PHI2 shorted clock 1.77MHz
signal temp1  : std_logic;
signal temp2  : std_logic;
signal counter : integer;

  process(clk50)
  begin
  if rising_edge(clk50) then
  if phi2 = '1' then
     temp1 <= '1';
   else
     temp1 <= '0';
  end if;
  temp2 <= '1';
    if counter >= 9 then
      counter <= 0;
      temp2 <= '0';
    else
      counter <= counter + 1;
    end if;
  end if;
   end process;
   phi2short <= temp1 and temp2;

[Dergute W. (derguteweka)]

Mahlzeit,

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

[Rick D. (rickdangerus)]

Wolfram F. schrieb:
> phi2 ist ein eingang mit 1.77MHz Takt.
>
> noch etwas angepasst:
Ich habe den Kram mal in die Simulation gesteckt, um zu sehen ob das 
klappt.

> Dieser soll auf 180ns verkürzt und als phi2short ausgegeben werden.
Sieht nicht so aus...

[Rick D. (rickdangerus)]

Wolfram F. schrieb:
> phi2 ist ein eingang mit 1.77MHz Takt.
> Dieser soll auf 180ns verkürzt und als phi2short ausgegeben werden.

Versuch es mal so:

library ieee;
use ieee.std_logic_1164.all;

entity taktteiler is
port
(
    clk50     : in  std_logic;     -- IO17 clock 50MHz
    phi2      : in  std_logic;     -- PHI2 clock 1.77MHz
    --
    phi2short : out std_logic      -- PHI2 shorted clock 1.77MHz
);
end entity taktteiler;

architecture rtl of taktteiler is

    signal counter  : natural range 0 to 9;

begin

    process(clk50)
    begin
        if rising_edge(clk50) then

            phi2short   <= '0';

            if phi2 = '1' then
                if counter < 9 then
                    counter     <= counter + 1;
                    phi2short   <= '1';
                end if;
            else
                counter <= 0;
            end if;

        end if;
   end process;

end architecture rtl;

[Wolfram F. (mega-hz)]

Rick D. schrieb:
> Wolfram F. schrieb:
>> phi2 ist ein eingang mit 1.77MHz Takt.
>>
>> noch etwas angepasst:
> Ich habe den Kram mal in die Simulation gesteckt, um zu sehen ob das
> klappt.
>
>> Dieser soll auf 180ns verkürzt und als phi2short ausgegeben werden.
> Sieht nicht so aus...

Hmm, fast..
die 2. If schleife muss wohl in die erste mit einbezogen werden...
Kannst Du folgendes mal simulieren?

clk50    : in std_logic;  -- IO17 clock 50MHz

phi2      : in std_logic;  -- PHI2 clock 1.77MHz

phi2short : out std_logic; -- PHI2 shorted clock 1.77MHz

signal temp1  : std_logic;

signal temp2  : std_logic;

signal counter : integer;

  process(clk50)
  begin
  if rising_edge(clk50) then
  if phi2 = '1' then
     temp1 <= '1';
    temp2 <= '1';
    if counter >= 9 then
      counter <= 0;
      temp2 <= '0';
    else
      counter <= counter + 1;
    end if;
   else
     temp1 <= '0';
  end if;
  end if;
   end process;
   phi2short <= temp1 and temp2;

Verstehe nicht, warum man keine 2 "if rising_edge" verschachteln 
kann....

[Wolfram F. (mega-hz)]

Dergute W. schrieb:
> Mahlzeit,
>
> 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...

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> die 2. If schleife muss wohl in die erste mit einbezogen werden...

Hier sind ja wieder mal absolute Fachleute unterwegs.

http://www.if-schleife.de/

[Dergute W. (derguteweka)]

Moin,

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

Wolfram F. schrieb:
> Es ist wirklich nicht einfach, wenn man nur Basic/Assembler/...
Weiss ich, ist/war bei mir auch so; ich will/kann nichtmal c++ :-)

Wolfram F. schrieb:
> Die Lösung mit
> if phi2 = '1' ist nicht optimal...
Yep.
Wie waers' mit so einem Konstrukt innerhalb einer if rising_edge(clk50) 
"schleife" (;-) ):

phi2alt <= phi2;
if (phi2 = '1' and phi2alt = '0') then ...

blafasel;

endif

Sowas springt dann einmal an, wenn dein phi2 eine "steigende Flanke" 
hat.

Gruss
WK

[Wolfram F. (mega-hz)]

Rick D. schrieb:
> Wolfram F. schrieb:
>> phi2 ist ein eingang mit 1.77MHz Takt.
>> Dieser soll auf 180ns verkürzt und als phi2short ausgegeben werden.
>
> Versuch es mal so:
>

> library ieee;
> use ieee.std_logic_1164.all;
> 
> entity taktteiler is
> port
> (
>     clk50     : in  std_logic;     -- IO17 clock 50MHz
>     phi2      : in  std_logic;     -- PHI2 clock 1.77MHz
>     --
>     phi2short : out std_logic      -- PHI2 shorted clock 1.77MHz
> );
> end entity taktteiler;
> 
> architecture rtl of taktteiler is
> 
>     signal counter  : natural range 0 to 9;
> 
> begin
> 
>     process(clk50)
>     begin
>         if rising_edge(clk50) then
> 
>             phi2short   <= '0';
> 
>             if phi2 = '1' then
>                 if counter < 9 then
>                     counter     <= counter + 1;
>                     phi2short   <= '1';
>                 end if;
>             else
>                 counter <= 0;
>             end if;
> 
>         end if;
>    end process;
> 
> end architecture rtl;
>

    process(clk50)
    begin
        if rising_edge(clk50) then
            phi2short   <= '0';
            if phi2 = '1' then
                if counter < 9 then
                    counter     <= counter + 1;
                    phi2short   <= '1';
                end if;
            else
                counter <= 0;
            end if;
        end if;
   end process;

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 :-)

[Kay-Uwe R. (dfias)]

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.

[Rick D. (rickdangerus)]

Wolfram F. schrieb:
> Danke Dir! Jetzt verstehe ich die Logik auch, hatte ähnlich gedacht aber
> invertiert, geodert und um 3 Ecken :-)
Alles gut, schön das es klappt.

Wolfram F. schrieb:
> Ich verstehe so viel noch nicht vom VHDL, daher habt bitte Verständnis.
Wir haben alle mal klein angefangen...

[Wolfram F. (mega-hz)]

Kay-Uwe R. schrieb:
> 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)

[Wolfram F. (mega-hz)]

Weiss jemand:
gibt es einen FPGA Recompiler?
Also FPGA auslesen und in Code umwandeln?

[Kay-Uwe R. (dfias)]

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

[Wolfram F. (mega-hz)]

dachte ich mir fast.
Wie bei den GAL ReCompilern...
Da war es aber noch übersichtlich.

[Kay-Uwe R. (dfias)]

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.

[Wolfram F. (mega-hz)]

soweit geht es wohl nicht.
habe keinen Kunden nur SelfInteresse

[Wolfram F. (mega-hz)]

Rick D. schrieb:
> Wolfram F. schrieb:
>> Danke Dir! Jetzt verstehe ich die Logik auch, hatte ähnlich gedacht aber
>> invertiert, geodert und um 3 Ecken :-)
> Alles gut, schön das es klappt.
>
> Wolfram F. schrieb:
>> 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)

[Wastl (hartundweichware)]

Wolfram F. schrieb:
> schön ist es trotzdem nicht

Wastl schrieb:
> SI5351

Mit einem SI5351 oder einem DDS oder einem ADF4351 wäre dir
das nicht passiert.

Sogar mit einem "Arduino-AD9850" wäre das noch besser ....

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Wolfram F. (mega-hz)]

Puh, mit den PLLs hab ich noch nie was gemacht...
Wie hoch könnte man denn den internen Takt erhöhen?

[Gustl B. (-gb-)]

Wolfram F. schrieb:
> Puh, mit den PLLs hab ich noch nie was gemacht...

Ist nicht schwer, es gibt da einen IP Wizzard.

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

[Wolfram F. (mega-hz)]

Total combinational functions  206 / 4,608 ( 4 % )  Flow Status 
Successful - Mon Feb 05 18:53:17 2024
Dedicated logic registers  109 / 4,608 ( 2 % )  Quartus II Version  11.0 
Build 157 04/27/2011 SJ Web Edition
Revision Name  AtariMainboardFPGA
Top-level Entity Name  AtariMainboardFPGA
Family  Cyclone II
Device  EP2C5T144C8
Timing Models  Final
Total logic elements  206 / 4,608 ( 4 % )
Total registers  109
Total pins  76 / 89 ( 85 % )
Total virtual pins  0
Total memory bits  0 / 119,808 ( 0 % )
Embedded Multiplier 9-bit elements  0 / 26 ( 0 % )
Total PLLs  0 / 2 ( 0 % )

Fmax 101,35MHz bei 50MHz Quarz
Ist im SLOW-Mode (?)

Mail ist unterwegs...

[Wolfram F. (mega-hz)]

====================================

set_location_assignment PIN_100 -to adress_dir

set_location_assignment PIN_99 -to adress_en

set_location_assignment PIN_101 -to adr[15]

set_location_assignment PIN_103 -to adr[14]

set_location_assignment PIN_104 -to adr[13]

set_location_assignment PIN_113 -to adr[11]

set_location_assignment PIN_112 -to adr[12]

set_location_assignment PIN_114 -to adr[10]

set_location_assignment PIN_115 -to adr[9]

set_location_assignment PIN_118 -to adr[8]

set_location_assignment PIN_119 -to adr[7]

set_location_assignment PIN_120 -to adr[6]

set_location_assignment PIN_121 -to adr[5]

set_location_assignment PIN_122 -to adr[4]

set_location_assignment PIN_125 -to adr[3]

set_location_assignment PIN_126 -to adr[2]

set_location_assignment PIN_129 -to adr[1]

set_location_assignment PIN_132 -to adr[0]

set_location_assignment PIN_133 -to data_en

set_location_assignment PIN_134 -to data_dir

set_location_assignment PIN_135 -to data[0]

set_location_assignment PIN_136 -to data[1]

set_location_assignment PIN_137 -to data[2]

set_location_assignment PIN_139 -to data[3]

set_location_assignment PIN_141 -to data[4]

set_location_assignment PIN_142 -to data[5]

set_location_assignment PIN_143 -to data[6]

set_location_assignment PIN_144 -to data[7]

set_location_assignment PIN_53 -to ram_rw

set_location_assignment PIN_55 -to ram_oe

set_location_assignment PIN_24 -to os_rom_a14

set_location_assignment PIN_25 -to os_rom_a15

set_location_assignment PIN_26 -to os_rom_a16

set_location_assignment PIN_27 -to os_rom_a17

set_location_assignment PIN_28 -to os_rom_a18

set_location_assignment PIN_40 -to F_cart_emu_enbl

set_location_assignment PIN_41 -to F_stereo_enbl

set_location_assignment PIN_42 -to F_ramdisk_enbl

set_location_assignment PIN_43 -to F_oldos_enbl

set_location_assignment PIN_32 -to F_flash_we_enbl

set_location_assignment PIN_44 -to basic_rom_a14

set_location_assignment PIN_45 -to basic_rom_a13

set_location_assignment PIN_47 -to basic_rom_a15

set_location_assignment PIN_48 -to basic_rom_a16

set_location_assignment PIN_51 -to basic_rom_a17

set_location_assignment PIN_52 -to basic_rom_a18

set_location_assignment PIN_96 -to basic_rom_oe

set_location_assignment PIN_9 -to bios_ram_a16

set_location_assignment PIN_4 -to bios_rom_oe

set_location_assignment PIN_7 -to bios_rom_we

set_location_assignment PIN_8 -to bios_rom_a14

set_location_assignment PIN_31 -to os_rom_oe

set_location_assignment PIN_17 -to clk50

set_location_assignment PIN_74 -to cctl

set_location_assignment PIN_70 -to gtia_cs

set_location_assignment PIN_71 -to pia_cs

set_location_assignment PIN_72 -to pokey1_cs

set_location_assignment PIN_73 -to pokey2_cs

set_location_assignment PIN_81 -to mpd

set_location_assignment PIN_80 -to rd5

set_location_assignment PIN_79 -to rd4

set_location_assignment PIN_75 -to s4

set_location_assignment PIN_93 -to s5

set_location_assignment PIN_87 -to be

set_location_assignment PIN_86 -to ren

set_location_assignment PIN_92 -to selftest

set_location_assignment PIN_3 -to osc

set_location_assignment PIN_30 -to pal

set_location_assignment PIN_18 -to phi2

set_location_assignment PIN_57 -to refresh

set_location_assignment PIN_58 -to rdy

set_location_assignment PIN_59 -to rw

set_location_assignment PIN_60 -to phi2short

set_instance_assignment -name PARTITION_HIERARCHY root_partition -to |

-section_id Top

set_global_assignment -name FAMILY "Cyclone II"

set_global_assignment -name DEVICE EP2C5T144C8

set_global_assignment -name TOP_LEVEL_ENTITY AtariMainboardFPGA

set_global_assignment -name ORIGINAL_QUARTUS_VERSION "13.0 SP1"

set_global_assignment -name PROJECT_CREATION_TIME_DATE "00:21:24  JULY

21, 2016"

set_global_assignment -name LAST_QUARTUS_VERSION 11.0

set_global_assignment -name PROJECT_OUTPUT_DIRECTORY output_files

set_global_assignment -name MIN_CORE_JUNCTION_TEMP 0

set_global_assignment -name MAX_CORE_JUNCTION_TEMP 85

set_global_assignment -name DEVICE_FILTER_PACKAGE TQFP

set_global_assignment -name DEVICE_FILTER_PIN_COUNT 144

set_global_assignment -name ERROR_CHECK_FREQUENCY_DIVISOR 1

set_global_assignment -name EDA_SIMULATION_TOOL "ModelSim-Altera (VHDL)"

set_global_assignment -name EDA_OUTPUT_DATA_FORMAT VHDL -section_id

eda_simulation

set_global_assignment -name USE_CONFIGURATION_DEVICE ON

set_global_assignment -name GENERATE_RBF_FILE ON

set_global_assignment -name RESERVE_ALL_UNUSED_PINS "AS INPUT

TRI-STATED"

set_global_assignment -name STRATIX_DEVICE_IO_STANDARD "3.3-V LVCMOS"

set_global_assignment -name RESERVE_ALL_UNUSED_PINS_NO_OUTPUT_GND "AS

INPUT TRI-STATED"

set_global_assignment -name POWER_PRESET_COOLING_SOLUTION "23 MM HEAT

SINK WITH 200 LFPM AIRFLOW"

set_global_assignment -name POWER_BOARD_THERMAL_MODEL "NONE

(CONSERVATIVE)"

set_global_assignment -name PARTITION_NETLIST_TYPE SOURCE -section_id

Top

set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL

PLACEMENT_AND_ROUTING -section_id Top

set_global_assignment -name PARTITION_COLOR 16764057 -section_id Top

set_global_assignment -name VHDL_FILE AtariMainboard.vhd

set_global_assignment -name VHDL_FILE AtariMainboardFPGA.vhd

set_global_assignment -name OPTIMIZE_HOLD_TIMING "IO PATHS AND MINIMUM

TPD PATHS"

set_global_assignment -name FITTER_EFFORT "STANDARD FIT"

====================================

[Gustl B. (-gb-)]

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.

[Wolfram F. (mega-hz)]

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

[Gustl B. (gustl_b)]

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.

[Dergute W. (derguteweka)]

Moin,

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

Gruss
WK

[Rick D. (rickdangerus)]

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

[Wolfram F. (mega-hz)]

nein, habe ich noch nicht versucht.
ich kenn mich da noch nicht so aus, werds mir aber mal anschauen.

Wiegesagt die Takte sind tadellos in diesem Fall,
keine Bild- ode Farbstörungen...
Nur auf dem Scope siehts nicht schön aus.

Gehe ich richtig in der Annahme das der vom PLL erzeugte Takt nicht 
zwingend an einem IO sondern an einem internen Signal erzeugt werden 
kann?

[Wolfram F. (mega-hz)]

ich habs nun probiert:
Sieht aus wie bei Dir, allerdings sind nur 3 Outputs möglich
und den 3.54Mhz Takt kann er anscheinend nicht:

  altpll_component : altpll
  GENERIC MAP (
    clk0_divide_by => 5000000,
    clk0_duty_cycle => 50,
    clk0_multiply_by => 1418757,
    clk0_phase_shift => "0",
    clk1_divide_by => 50000000,
    clk1_duty_cycle => 50,
    clk1_multiply_by => 4336179,
    clk1_phase_shift => "0",
    clk2_divide_by => 62500,
    clk2_duty_cycle => 50,
    clk2_multiply_by => 4471, <<<<<<<<<<<<<<### ???
    clk2_phase_shift => "0",
    compensate_clock => "CLK0",
    inclk0_input_frequency => 20000,
    intended_device_family => "Cyclone II",
    lpm_hint => "CBX_MODULE_PREFIX=pll",
    lpm_type => "altpll",

[Rick D. (rickdangerus)]

Wolfram F. schrieb:
> Gehe ich richtig in der Annahme das der vom PLL erzeugte Takt nicht
> zwingend an einem IO sondern an einem internen Signal erzeugt werden
> kann?
Die Frage verstehe ich nicht. Aber ja, üblicherweise werden die von 
einer PLL erzeugten Takte eher intern im FPGA verwendet.

Wolfram F. schrieb:
> allerdings sind nur 3 Outputs möglich
Ok, dann hat eine PLL im Cyclone2 nur 3 Ausgänge.

> und den 3.54Mhz Takt kann er anscheinend nicht:
>    clk2_divide_by => 62500,
>    clk2_multiply_by => 4471,
Da kommen 3,5768 MHz raus:
50000000 / 62500 * 4471 = 3576800
Das ist eine Abweichung von ca. 1 %.

Wolfram F. schrieb:
> Total PLLs  0 / 2 ( 0 % )
Du kannst ja evtl. die 2. PLL für die restlichen Takte nutzen.

[Wolfram F. (mega-hz)]

Rick D. schrieb:
> Wolfram F. schrieb:
>> Gehe ich richtig in der Annahme das der vom PLL erzeugte Takt nicht
>> zwingend an einem IO sondern an einem internen Signal erzeugt werden
>> kann?
> Die Frage verstehe ich nicht. Aber ja, üblicherweise werden die von
> einer PLL erzeugten Takte eher intern im FPGA verwendet.
>
> Wolfram F. schrieb:
>> allerdings sind nur 3 Outputs möglich
> Ok, dann hat eine PLL im Cyclone2 nur 3 Ausgänge.
>
>> und den 3.54Mhz Takt kann er anscheinend nicht:
>>    clk2_divide_by => 62500,
>>    clk2_multiply_by => 4471,
> Da kommen 3,5768 MHz raus:
> 50000000 / 62500 * 4471 = 3576800
> Das ist eine Abweichung von ca. 1 %.
>
> Wolfram F. schrieb:
>> Total PLLs  0 / 2 ( 0 % )
> 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!

Cannot implement the requested PLL
Cause: Requested mult/div factors not achievable

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?

[Rick D. (rickdangerus)]

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

[Dergute W. (derguteweka)]

Moin,

OK, alzont mal fuer 4.43...MHz Ausgang mit 50MHz Eingang und 
Primfaktorzerlegung der Multiplikations- und Teilerfaktoren:

Allgemein:

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

64489 / (2⁹ * 5⁴)

wieder mit einer Konstruktion, wie in meinem 1. Post hier im Thread, 
erschlagen.

Gruss
WK

[Bernd G. (Gast)]

Dergute W. schrieb:
> wieder mit einer Konstruktion, wie in meinem 1. Post hier im Thread,
> erschlagen.

Du meinst das hier?

Dergute W. schrieb:
> Jittert halt etwas...
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.

Dann lieber eine anloge PLL mit Regelung.

[Dergute W. (derguteweka)]

Moin,

Naja, die einen sagen so:

Bernie-Bär🐻 schrieb:
> Das jittert nicht nur "etwas" sondern ist für eine genae Frequenz völlig
> ungeignet.

die anderen sagen halt so:

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

Schoenheit und Frequenzgenauigkeit liegen im Auge des Betrachters...

Gruss
WK

[Rick D. (rickdangerus)]

🐻 Bernie - Bär schrieb:
> 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

[Wolfram F. (mega-hz)]

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.

[Wolfram F. (mega-hz)]

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?

Beim PLD oder GAL war der Verbrauch höher.

  if (adr >= x"8000" and adr <= x"9FFF") and rd4 = '1' and refresh = '1' then 
      CI <= '0';
  elsif (adr >= x"A000" and adr <= x"BFFF") and rd5 = '1' and refresh = '1' then
      CI <= '0';
  elsif (adr >= x"A000" and adr <= x"BFFF") and rd5 = '0' and be = '0' and refresh = '1' then 
      CI <= '0';
  elsif (adr >= x"C000" and adr <= x"CFFF") and ren = '1' and refresh = '1' then
      CI <= '0';
  elsif (adr >= x"E000" and adr <= x"FFFF") and ren = '1' and refresh = '1' then
      CI <= '0';
  elsif (adr >= x"5000" and adr <= x"57FF") and ren = '1' and selftest = '0' and refresh = '1' then
      CI <= '0';
  elsif (adr >= x"D000" and adr <= x"D7FF") and refresh = '1' then
      CI <= '0';
  elsif (adr >= x"D800" and adr <= x"DFFF") and ren = '1' and mpd = '1' and refresh = '1' then 
      CI <= '0';
  elsif refresh = '0' then
      CI <= '0';
  else
     CI <= '1';
  end if;

[Wolfram F. (mega-hz)]

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 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. DDS-Technologien sind darauf ausgelegt, stabile und genaue Ausgangsfrequenzen zu erzeugen, und bieten in der Regel eine höhere Genauigkeit und geringeres Jitter im Vergleich zu einfachen Dividern.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity DDS_ClockDivider is
    port (
        clkin : in std_logic;
        reset : in std_logic;
        out   : out std_logic
    );
end entity DDS_ClockDivider;

architecture Behavioral of DDS_ClockDivider is
    constant CLKIN_FREQ : integer := 50000000;  -- Eingangsfrequenz (50MHz)
    constant CLKOUT_FREQ : real := 443361875.0;  -- Ausgangsfrequenz (4.43361875MHz)
    
    constant PHASE_BITS : integer := 32;  -- Anzahl der Phasenbits
    constant PHASE_MAX : integer := 2**PHASE_BITS - 1;
    constant PHASE_INCREMENT : integer := integer(round((CLKOUT_FREQ / CLKIN_FREQ) * PHASE_MAX));
    
    signal phase_accumulator : unsigned(PHASE_BITS - 1 downto 0) := (others => '0');
    signal phase_out : std_logic := '0';
begin
    process(clkin, reset)
    begin
        if reset = '1' then
            phase_accumulator <= (others => '0');
            phase_out <= '0';
        elsif rising_edge(clkin) then
            phase_accumulator <= phase_accumulator + to_unsigned(PHASE_INCREMENT, PHASE_BITS);
            if phase_accumulator(PHASE_BITS - 1) = '1' then
                phase_out <= not phase_out;
            end if;
        end if;
    end process;
    
    out <= phase_out;
end architecture Behavioral;

Sollte ich das mal probieren? :-)

[Gustl B. (-gb-)]

Das ist eine mit 50 MHz getaktete Schaltung. Was erwartest du? Das hat 
nunmal eine Zeitauflösung von 20 ns. Die wirst du so nicht los.

[J. S. (engineer)]

Mal generell:

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.

[J. S. (engineer)]

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

Bildliche Darstellung:

http://www.96khz.org/oldpages/limitsofdds.htm

[Christoph Z. (christophz)]

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

  if (adr(15 downto 12) = x"8" or adr(15 downto 12) = x"9") and rd4 = '1' and refresh = '1' then CI <= '0';

Und dann danach im RTL Schema beide Versionen vergleichen.

[Wolfram F. (mega-hz)]

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?

[Rick D. (rickdangerus)]

Wolfram F. schrieb:
> Im FPGA muss ich dieses Signal ebenfalls lesen und schreiben.
> Der Ausgang ist als Z definiert.
Dann nimm zwei I/O-Pins:
- eins zum Lesen (z.B. mit Spannungsteiler davor) und
- eins gibst du auf die Basis von einem NPN-Transistor (mit 
Vorwiderstand) um das externe Signal bei Bedarf auf low zu ziehen

[Wolfram F. (mega-hz)]

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?

[Dergute W. (derguteweka)]

Moin,

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.

Gruss
WK

[Bernd G. (Gast)]

Diode und pullup Widerstand.

[Markus F. (mfro)]

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