Grenzen der Frequenzteilung?

[Xyz X. (Firma: xyz) (khmweb)]

Hallo,

bei meinen Übungen mit CPLD stellte sich mir eine Frage:
Gibt es bei der Frequenzteilung Grenzen oder kann bei einem 1MHz-Takt 
jede beliebige Frequenz zw. 1Hz und 1MHz an einem I/O-Ausgang erreicht 
werden?

Kann sein, ich hab da generell noch ein Verständnisproblem. Ich konnte 
nur bestimmte Frequenzen erreichen.

LG
Karl-Heinz

[lager (Gast)]

Ja.
PI Hz geht zum Beispiel nicht.

[Xyz X. (Firma: xyz) (khmweb)]

lager schrieb:
> PI Hz geht zum Beispiel nicht.

???

[P. K. (pek)]

Karl-Heinz M. schrieb:
> lager schrieb:
>> PI Hz geht zum Beispiel nicht.
>
> ???

Naja, ist kein endlicher Bruch, und kann also mit den DCM/PLL-Teilern 
nicht erreicht werden... ;-)

Was Du erreichen kannst, ist durch die Multiplizierer und Teiler (resp. 
deren Grösse) und der maximalen PLL-Frequenz Deiner Clock-Resourcen 
bestimmt.

[Christian R. (supachris)]

Hm, er hat ein CPLD, da gibts in der Regel weder DCM noch PLL.

Wie teilst du denn den Takt?

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

Karl-Heinz M. schrieb:
> Gibt es bei der Frequenzteilung Grenzen oder kann bei einem 1MHz-Takt
> jede beliebige Frequenz zw. 1Hz und 1MHz an einem I/O-Ausgang erreicht
> werden?
Nein. Spätestens bei 500kHz ist Schluss. Das sagen schon Shannon&Co in 
ihrem Abtasttheorem...

> Kann sein, ich hab da generell noch ein Verständnisproblem.
> Ich konnte nur bestimmte Frequenzen erreichen.
Such mal nach DDFS.
Aber du wirst auf jeden Fall bei hohen Frequenzen einen merklichen 
Jitter haben. Das musst du einfach mal auf einem Blatt Papier 
aufmalen....

[P. K. (pek)]

Christian R. schrieb:
> Hm, er hat ein CPLD, da gibts in der Regel weder DCM noch PLL.

Oops, ist mir voll durch die Lappen...

...in dem Fall ist das Teilverhälnis begrenzt durch die Anzahl FF's, 
welche Du für einen Zähler erübrigen kannst, welcher Dir das 
Clock-Enable für die "runtergeteilte" Domain generiert.

[Xyz X. (Firma: xyz) (khmweb)]

Christian R. schrieb:
> Wie teilst du denn den Takt?

Siehe hier:
Beitrag "Re: USBprog CPLD Starterkit Wie bauen?"

Egal, welche Werte ich da einstellte, es kamen immer nur bestimmte 
Frequenzen in Abhängigkeit meiner Einstellungen heraus. Zwischenwerte 
konnte ich nicht erreichen, da waren immer Sprünge von einer zur anderen 
Frequenz.

Ihr Spezis denkt da viell. aufgrund Eures Fachwissens viell. viel zu 
weit bei mir? Daher mal ein konkretes Bsp. für den XC95144XL:

entity frequ is
    Port ( clk : in STD_LOGIC;
           f_out: out STD_LOGIC);
end frequ;

architecture Behavioral of frequ is
   SIGNAL counter : integer range 0 to 1023 :=0;
  signal f_out_sig : STD_LOGIC :='0';
begin
   los_gehts: PROCESS (clk)
  BEGIN
     IF (RISING_EDGE(clk)) THEN
      counter <= counter + 1;
      IF (counter < 610) THEN
        f_out_sig <= '0';
      ELSE
        f_out_sig <= '1';
      END IF;
    END IF;
  END PROCESS los_gehts;
  f_out <= f_out_sig;
end Behavioral;

Und die ucf dazu:
NET "clk"  LOC = "p22" | BUFG = CLK; --1MHz
NET "f_out"  LOC = "p82" | SLEW = SLOW;

Mit 1023 als max. Range erreiche ich eine Frequenz von fast 1000 Hz an 
Pin 82. Ab 1024 erreiche ich eine Frequenz von ca. 500Hz. Tastverhältnis 
ca. 50%. Zwischen 500Hz und 1kHz ist der Sprung, den ich noch nicht 
nachvollziehen kann.

Ich glaub beim Schreiben haben sich noch Antworten gekreuzt, lese ich 
gleich sofort, danke.

[Xyz X. (Firma: xyz) (khmweb)]

Lothar Miller schrieb:
> Such mal nach DDFS.

http://www.lothar-miller.de/s9y/categories/31-DDFS

Klasse! Gefällt mir! Wird ausprobiert.

[Xyz X. (Firma: xyz) (khmweb)]

Peter K. schrieb:
> ...in dem Fall ist das Teilverhälnis begrenzt durch die Anzahl FF's,
> welche Du für einen Zähler erübrigen kannst, welcher Dir das
> Clock-Enable für die "runtergeteilte" Domain generiert.

Ja, wenn ichs richtig verstehe, die Frequenz ändert sich in Potenzen der 
Basis 2 bei der max. Range-Angabe. Viell. hab ich ein 
VHDL-Verständnisproblem.

[P. K. (pek)]

Karl-Heinz M. schrieb:
> Ja, wenn ichs richtig verstehe, die Frequenz ändert sich in Potenzen der
> Basis 2 bei der max. Range-Angabe.

Du musst Deinen Counter beim gewünschten Stand auf 0 zurücksetzen, sonst 
läuft er immer bis zum Wrap-Around, d.h. bis zur nächst höheren 
Zweierpotenz von Deiner Rangeangabe her gerechnet (i.e. wenn Du die 
Range 0 bis 1024 setzt wird der Zähler von 2047 auf 0 wrappen).
Das ist nicht etwa ein Fehler, aber der Synthesizer muss immer ganze 
FF's instanzieren, in Deinem Fall 11.

[Xyz X. (Firma: xyz) (khmweb)]

Peter K. schrieb:
> Du musst Deinen Counter beim gewünschten Stand auf 0 zurücksetzen, sonst
> läuft er immer bis zum Wrap-Around, d.h. bis zur nächst höheren
> Zweierpotenz von Deiner Rangeangabe her gerechnet (i.e. wenn Du die
> Range 0 bis 1024 setzt wird der Zähler von 2047 auf 0 wrappen).

Dank Dir Peter, das versuche ich.

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

Karl-Heinz M. schrieb:
> http://www.lothar-miller.de/s9y/categories/31-DDFS
> Klasse! Gefällt mir! Wird ausprobiert.
Ähm, für dich dürfte da aber nur der Teil (eigentlich nur die Zeile) mit 
dem Akku interessant sein, den Rest mit dem Sinus bekommst du sicher 
nicht in ein CPLD...

Deine DDFS beläuft sich also nur auf diese paar Zeilen:

 signal akku : unsigned (19 downto 0) := (others->'0');
 constant wunschfrequenz : unsigned (19 downto 0) := x"00001"; -- bezogen auf 2^20 = 1048576 !

 
 akku <= akku + wunschfrequenz when rising_edge(clk1MHz);      -- hochzählen
 ausgang <= akku[19];                                          -- das MSB ausgeben

[Xyz X. (Firma: xyz) (khmweb)]

Peter K. schrieb:
> Du musst Deinen Counter beim gewünschten Stand auf 0 zurücksetzen, sonst
> läuft er immer bis zum Wrap-Around, d.h. bis zur nächst höheren
> Zweierpotenz von Deiner Rangeangabe her gerechnet (i.e. wenn Du die
> Range 0 bis 1024 setzt wird der Zähler von 2047 auf 0 wrappen).
> Das ist nicht etwa ein Fehler, aber der Synthesizer muss immer ganze
> FF's instanzieren, in Deinem Fall 11.

Klappt wunderbar, danke! Es war ein VHDL-Verständnisproblem: Ich 
glaubte, dass die max. Range-Angabe auch nur bis zum angegebenen Wert 
läuft und danach von selbst auf 0 springt. Das aber zeigt mir, dass es 
eigentlich in diesem Fall egal ist, wie hoch ich diesen Wert setze, da 
ich ihn ja durch z. B.:

IF (counter = 1536) THEN
counter <= 0;
END IF;

vorzeitig rücksetze.

Mit 1536 erhalte ich, wie erwartet, 651Hz (1000000Hz / 1536 = 651Hz).

[Xyz X. (Firma: xyz) (khmweb)]

Lothar Miller schrieb:
> Ähm, für dich dürfte da aber nur der Teil (eigentlich nur die Zeile) mit
> dem Akku interessant sein, den Rest mit dem Sinus bekommst du sicher
> nicht in ein CPLD...

:-( Zu früh gefreut... Trotzdem danke für Deine Hilfe.

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

Karl-Heinz M. schrieb:
> Zu früh gefreut...
Trotzdem kannst du dir das anschauen, weil bei der DDFS-Lösung kleine 
"Wunschfrequenzwerte" auch niedrigere Frequenzen ergeben. Das ist 
irgendwie intuitiver...

[Duke Scarring (Gast)]

Karl-Heinz M. schrieb:
>> Ähm, für dich dürfte da aber nur der Teil (eigentlich nur die Zeile) mit
>> dem Akku interessant sein, den Rest mit dem Sinus bekommst du sicher
>> nicht in ein CPLD...
>
> :-( Zu früh gefreut... Trotzdem danke für Deine Hilfe.
So wie ich das in den anderen Threads gesehen hatte, hat er einen 
95XL144 bzw. 95XL288 zur Verfügung. Da passt der DDFS von Lothar ohne 
Änderung rein:

cpldfit:  version O.76xd                            Xilinx Inc.
                                  Fitter Report
Design Name: DDFS                                Date: 10-17-2012, 10:12AM
Device Used: XC95144XL-10-TQ100
Fitting Status: Successful

*************************  Mapped Resource Summary  **************************

Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
41 /144 ( 28%) 493 /720  ( 68%) 188/432 ( 44%)   28 /144 ( 19%) 17 /81  ( 21%)

Abgesehen davon, könnte man auch den Sinus-ROM noch kleiner machen.

Duke

[Xyz X. (Firma: xyz) (khmweb)]

Duke Scarring schrieb:
> So wie ich das in den anderen Threads gesehen hatte, hat er einen
> 95XL144 bzw. 95XL288 zur Verfügung. Da passt der DDFS von Lothar ohne
> Änderung rein:

Danke Duke, ich probiere das dann bald mal, interessiert mich sehr, da 
ich gern niederfrequente Töne (hörbare) damit erzeugen möchte. Btw ich 
hab den XC9572 und den XC95144XL. Bei letzterem probiere ichs zuerst.

[Xyz X. (Firma: xyz) (khmweb)]

Karl-Heinz M. schrieb:
> SIGNAL counter : integer range 0 to 1023 :=0;

und

> IF (counter < 610) THEN

> Tastverhältnis ca. 50%.

war nicht korrekt. Korrekte Daten s. Screenshots.
f = 1000000Hz / 1023 = 977Hz (gerundet)

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

Duke Scarring schrieb:
> Da passt der DDFS von Lothar ohne Änderung rein:
Cool...  :-o

> Abgesehen davon, könnte man auch den Sinus-ROM noch kleiner machen.
Insbesondere, wenn man im Auge behält, dass ja nur ein Rechteck 
herauskommen muss...  ;-)

[Xyz X. (Firma: xyz) (khmweb)]

Lothar Miller schrieb:
> Insbesondere, wenn man im Auge behält, dass ja nur ein Rechteck
> herauskommen muss...  ;-)

Nö, muss nicht. Ist alles nur zu meiner Übung und Ideen für Anwendungen 
kommen mir dabei auch, welche ich erst einmal im Hinterkopf behalte und 
später umsetze. Möglicherweise auch hier vorstelle. Sinustöne hören sich 
freundlicher an, mal sehn.

[Xyz X. (Firma: xyz) (khmweb)]

http://www.lothar-miller.de/s9y/categories/31-DDFS

Davon hab ich mir das 1. Script oben kopiert. Ich bekomme einen Fehler:

[sinus01.ucf(2)]: NET "Dout" not found.  Please verify that:
   1. The specified design element actually exists in the original 
design.
   2. The specified object is spelled correctly in the constraint source 
file.

Mein UCF-File:

NET "CLK"  LOC = "p22";
NET "Dout"  LOC = "p82";

Dout ist aber da ?? Er ist erst zufrieden, wenn ichs im UCF 
auskommentiere. Macht dann aber wenig Sinn.
Achso, Freq_Data hab ich erst mal auskommentiert und so geändert:

Entity DDFS is
--------------------------------------------------
   Port ( CLK       : in  std_logic;
          --Freq_Data : in  std_logic_vector (7 downto 0);
          Dout      : out std_logic_vector (7 downto 0)
        );
   end DDFS;

--Accum <= Accum + unsigned(Freq_Data);
Accum <= Accum + 90;

[Xyz X. (Firma: xyz) (khmweb)]

Dout      : out std_logic_vector (7 downto 0)

wer lesen kann ist klar im Vorteil ;-)

Sorry.

[Duke Scarring (Gast)]

Karl-Heinz M. schrieb:
> NET "Dout"  LOC = "p82";

Karl-Heinz M. schrieb:
> Dout      : out std_logic_vector (7 downto 0)

Dout ist ein Vektor. Da muß Dein .ucf ungefähr so aussehen:

NET "Dout<0>"  LOC = "p82";
NET "Dout<1>"  LOC = "p81";
NET "Dout<2>"  LOC = "p80";
NET "Dout<3>"  LOC = "p83";
NET "Dout<4>"  LOC = "p84";
NET "Dout<5>"  LOC = "p85";
NET "Dout<6>"  LOC = "p86";
NET "Dout<7>"  LOC = "p87";

Duke

[Xyz X. (Firma: xyz) (khmweb)]

danke Duke, habs bemerkt, s. o., dauerte aber heut ziemlich lang ;-) Bin 
zu unkonzentriert.

Ich seh jetzt erst, dass die Daten an einen DA-Wandler gehen, hatte ich 
überlesen. Ich brech hier erst mal ab.

Hat aber in den XC95144XL rein gepasst.

[Xyz X. (Firma: xyz) (khmweb)]

Lothar Miller schrieb:
> den Rest mit dem Sinus bekommst du sicher
> nicht in ein CPLD...

Hat aber in den XC95144XL rein gepasst, den XC9572 hab ich nicht 
versucht.

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

Karl-Heinz M. schrieb:
> Hat aber in den XC95144XL rein gepasst.
Lothar Miller schrieb:
> Cool...  :-o
Immer noch...

[Duke Scarring (Gast)]

Karl-Heinz M. schrieb:
> Ich seh jetzt erst, dass die Daten an einen DA-Wandler gehen, hatte ich
> überlesen. Ich brech hier erst mal ab.
Schau Dir mal das MSB auf Deinem Oszi an...

Karl-Heinz M. schrieb:
> Hat aber in den XC95144XL rein gepasst, den XC9572 hab ich nicht
> versucht.
In den 72er passt es so erstmal nicht rein.

Duke

[Xyz X. (Firma: xyz) (khmweb)]

Lothar Miller schrieb:
> Karl-Heinz M. schrieb:
>> Hat aber in den XC95144XL rein gepasst.
> Lothar Miller schrieb:
>> Cool...  :-o
> Immer noch...

Duke hatte es wohl probiert und festgestellt, ich habs später erst 
probiert.

[Duke Scarring (Gast)]

Wenn man den Fitter auf Fläche optimieren läßt (-optimize density), dann 
passt es auch in den 72er:

cpldfit:  version O.76xd                            Xilinx Inc.
                                  Fitter Report
Design Name: DDFS                                Date: 10-17-2012,  1:26PM
Device Used: XC9572XL-10-VQ64
Fitting Status: Successful

*************************  Mapped Resource Summary  **************************

Macrocells     Product Terms    Function Block   Registers      Pins           
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot       
51 /72  ( 71%) 150 /360  ( 42%) 99 /216 ( 46%)   28 /72  ( 39%) 17 /52  ( 33%)

Duke

[Xyz X. (Firma: xyz) (khmweb)]

Duke Scarring schrieb:
> Schau Dir mal das MSB auf Deinem Oszi an...

D7 schaut bei mir so aus..

Man müsste sich einen 8- oder gar 16-Kanal-Multiplexer bauen. Hatte ich 
mal von Elektor nachgebaut für den damals nur 1-Strahl-Oszi von Hameg.

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

Duke Scarring schrieb:
> dann passt es auch in den 72er:
So langsam wirds extrem...   ;-)
Ich finde es stark, dass der Synthesizer die Tabelle tatsächlich so 
kompakt in Produktterme umgesetzt bekommt. Man lernt nie aus.

[Xyz X. (Firma: xyz) (khmweb)]

...man wird alt wie eine Kuh und lernt immer noch dazu ;-)

Euer Karl-Heinz Muh ;-))

[Xyz X. (Firma: xyz) (khmweb)]

Duke Scarring schrieb:
> Schau Dir mal das MSB auf Deinem Oszi an...

Tastgrad 50%.
Wie beim Sinus, positive, negative Halbwelle. Passt. Sieht gut aus. Nun 
bräuchte man einen DA-Wandler.

[Falk B. (falk)]

@  Karl-Heinz M. (Firma: www.khmweb.de) (khmweb)

>Wie beim Sinus, positive, negative Halbwelle. Passt. Sieht gut aus. Nun
>bräuchte man einen DA-Wandler.

Welchen man problemlos aus ein paar Widerständen testhalber 
zusammenbauen kann. Stichwort R2R DAC.

[Xyz X. (Firma: xyz) (khmweb)]

Falk Brunner schrieb:
> Welchen man problemlos aus ein paar Widerständen testhalber
> zusammenbauen kann. Stichwort R2R DAC.

Danke, kommt auch noch. Hab grad was andres beim Wickel.