Pulse Generator nicht genau genug, brauche Hilfe

[Thorsten F. (tfol)]

Hallo,

ich habe versucht mit Xilinx ISE und VHDL einen Pulse Generator zu 
bauen.
Es funktioniert auch, ich kann 12 Pulse und die Pulsepausen definieren 
und die werden ausgegeben. Leider aber nicht so genau wie ich es 
benötige.
Ich habe extra einen Triggerausgang eingebaut, der beim ersten Pulse 
einen 100ns (100ms war Tippfehler) Trigger für mein Oszi ausgibt.

Kurze Pulse bis 200nS sehen noch gut aus, aber ein Pulse von 20µs hat 
schon eine Ungenauigkeit von bis zu 150ns und bei 100µs bin ich bei 
einer Ungenauigkeit von fast 250ns, was ja 10 Takte bedueutet.

Habe noch 2 Bilder gemacht.
Bild 1 ist oben der erste kurze Pulse und unten das Triggersignal.
Bild 2 ist der 4. Pulse (2,4µs), der vorne ungenau ist, bedingt durch 
die 3 Pulse vorher aber auch in der Pulselänge nicht genau ist.

Vielleicht könnt ihr mir ja sagen was an meinem Code falsch ist, das er 
so ungenau arbeitet oder wie ich ihn besser bekomme.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity SimulatorPod is
    Port ( USER_CLOCK: in  std_logic;  -- 40 MHz Clock, 25ns
        PMOD2_P1: out std_logic;    -- Pulse Ausgang 1
        PMOD2_P10: out std_logic  -- Pulse Ausgang 2      
        );
end SimulatorPod;

architecture Pulsausgabe of SimulatorPod is
  type PulseTyp is array(0 to 11) of std_logic_vector(11 downto 0);          -- 12 Pulse Speicher mit max. 12Bit für 102,4µs
    signal Pulse : PulseTyp := (x"006", x"020", x"040", x"060", x"000", x"000", x"000", x"000", x"000", x"000", x"000", x"000");

  type PulsePauseTyp is array(0 to 11) of std_logic_vector(15 downto 0);      -- 12 Pulsepausen mit max. 16Bit für 1,6ms
    signal PulsePause : PulsePauseTyp := (x"00FF",x"00FF",x"00FF",x"00FF",x"0000",x"0000",x"0000",x"0000",x"0000",x"0000",x"0000",x"0000");
  
  signal PulseZaehler: std_logic_vector(11 downto 0):= (others=>'0');        -- 12 Bit Pulsezähler
  signal PulsePausenZaehler: std_logic_vector(15 downto 0) := (others=>'0');    -- 16 Bit Pulsepausenzähler
    
  signal PulseOut: std_logic;              -- Pulse Ausgang
  signal PrePulseOut: std_logic;            -- Pulse Trigger Ausgang

  signal Pulsenr : integer range 0 to 12 := 0;    -- 12 Pulse können abgefahren werden

begin
  Prescaler: process(USER_CLOCK)
  begin
  -- Wenn Clock-Flanke ansteigt
    if rising_edge(USER_CLOCK) then

      -- Pulse ausgeben
          If PulseZaehler < Pulse(Pulsenr) then
            PulseZaehler <= PulseZaehler + 1;
            pulseout <= '1';
          else
            PulsePausenZaehler <= PulsePausenZaehler + 1;
            pulseout <= '0';      
          end if;      
          -- 1. PulsePause
          if PulsePausenZaehler >= PulsePause(Pulsenr) then
            PulseZaehler <= (others => '0');
            PulsePausenZaehler <= (others => '0');  
            Pulsenr <= Pulsenr +1;
          end if;
      --- Triggerausgang setzen
          if Pulsenr = 0 and Pulse(0) > "000" and PulseZaehler < 4 then
            PrePulseOut <= '1';
          else
            PrePulseOut <= '0';
          end if;
      --- Ist ein neuer Puls leer, dann wieder mit Pulse 0 beginnen    
          if Pulse(Pulsenr) = "000" then 
            pulsenr <=0;
          end if;
      --- Es können nur Pulse 0-11 gesetzt werden, beim 12. also zurück zur 0    
          if Pulsenr >= 12 then 
            Pulsenr <= 0;
          end if;    
      
    end if;
  end process Prescaler;
  
  -- Pins für PulseOut setzen

  PMOD2_P1 <= pulseout;
  PMOD2_P10 <= prepulseout;

end Pulsausgabe;

Gruß
Thorsten

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

Thorsten F. schrieb:
> Habe noch 2 Bilder gemacht. Bild 1 ist oben der erste kurze Pulse und
> unten das Triggersignal.
Da sehe ich viele überlagerte Pulse...
> Bild 2 ist der 4. Pulse (2,4µs), der vorne ungenau ist, bedingt durch
> die 3 Pulse vorher aber auch in der Pulselänge nicht genau ist.
Hä?
Was ist Ursache, was ist Wirkung? Wenn alles "Pulse" heißt (wobei 
"Pulse" immer die Mehrzahl vo "Puls" ist und sich daher EXTREM 
verwirrend liest!), dann kann man Puls nicht vom Puls unterscheiden...

> bei 100µs bin ich bei einer Ungenauigkeit von fast 250ns, was ja 10
> Takte bedueutet.
Weil ich nicht genau verstehe, was du willst, nur eine Frage:
hast du diesen Fehler auch in der Simulation?
Gerade dieses Design ist optimal einfach zu simulieren!

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

So, in der Pause mal kurz simuliert:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
 
ENTITY tb_pg IS
END tb_pg;
 
ARCHITECTURE behavior OF tb_pg IS 
    COMPONENT SimulatorPod
    PORT(
         USER_CLOCK : IN  std_logic;
         PMOD2_P1 : OUT  std_logic;
         PMOD2_P10 : OUT  std_logic
        );
    END COMPONENT;

   signal USER_CLOCK : std_logic := '0';
   signal PMOD2_P1 : std_logic;
   signal PMOD2_P10 : std_logic;
BEGIN
   uut: SimulatorPod PORT MAP (
          USER_CLOCK => USER_CLOCK,
          PMOD2_P1 => PMOD2_P1,
          PMOD2_P10 => PMOD2_P10
        );

   USER_CLOCK <= not USER_CLOCK after 12.5 ns;
END;

Fazit: die 2,4us passen hier ganz exakt. Dein Quarz liegt daneben oder 
deine Messung spinnt...

Thorsten F. schrieb:
> aber ein Pulse von 20µs hat schon eine Ungenauigkeit von bis zu 150ns
> und bei 100µs bin ich bei einer Ungenauigkeit von fast 250ns, was ja 10
> Takte bedueutet.
Solche langen Pulse tauchen mit der geposteten VHDL Beschreibung gar 
nicht auf...

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

Ich habe jetzt mal die Tabelle ein wenig geändert und komme damit 
exakt auf 51.2us:

    signal Pulse : PulseTyp := (x"006", x"020", x"040", x"800", x"000", x"000", x"000", x"000", x"000", x"000", x"000", x"000");

[Duke Scarring (Gast)]

Thorsten F. schrieb:
> ich habe versucht mit Xilinx ISE und VHDL einen Pulse Generator zu
> bauen.
Wie kurz und wie lang sollen die Pulse sein?
Welcher Jitter ist zulässig?
Mit welcher Granularität soll die Pulslänge auswählbar sein?
Wo kommt der Takt her?
Wie schnell ist dieser?
Wo schaust Du Dir die Signale an?
Was für Hardware ist zwschen dem FPGA-Pin und dem Eingang vom 
Oszilloskop? (Verstärker?, Kabellänge?)

Duke

[Thorsten F. (tfol)]

Hallo,

vielen Dank für die schnellen Antworten.
@Lothar:
Ich habe gehofft das du hier mitmachst, finde es super wie du dein 
Wissen hier weiter gibst.
Ich wollte es auch schon simulieren, nur stehe ich mit ISIM noch auf 
Kriegsfuß. Da nehme ich gleich ein Tutorial durch um das auch nutzen zu 
können.

Ich habe für 4 Pulse die Puls und Pausenzeiten drin und deine Simulation 
sieht gut aus. Wenn es so raus käme wäre ich glücklich.


@Duke
Ich weis auch nicht ob es ein Messfehler ist, ich habe ein
Spartan-6 LX9 MicroBoard und bin direkt an den Pins am messen, ohne was 
dazwischen.
Ich messe mit einem HAMEG HMO2524 und den beiliegenden Messspitzen.

Der kleinste Puls soll stäter 100ns sein, der längste 102µs
Die kleinste Pulsepause wird ca. 20µs werden, die längste 1,6ms

Ein Jitter von 50ns, was 2 Takte bedeutet würde ich noch hinnehmen.
Es ist ein Takt auf dem Board was ich momentan nutze, dazu habe ich 
folgendes gefunden:

The CDCE913 is a modular PLL-based low-cost, high-performance, 
programmable clock synthesizer, multiplier, and divider. It
can generate up to 3 output clocks from a single input frequency. Each 
output can be programmed via an SDA / SCL, SMBus /
I2C interface, for any clock frequency up to 230 MHz, using the 
integrated configurable PLL. The input crystal frequency on
the S6LX9 MicroBoard is 27 MHz. The following clock frequency outputs 
are pre-programmed into the CDCE913 during
factory configuration.

Thorsten

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

Thorsten F. schrieb:
> Da nehme ich gleich ein Tutorial durch um das auch nutzen zu können.
Geht ganz einfach:
http://www.lothar-miller.de/s9y/archives/81-Xilinx-ISE-Step-by-Step.html

> Es ist ein Takt auf dem Board
Miss mal nach, wie genau der ist...

[Thorsten F. (tfol)]

Lothar Miller schrieb:
> Ich habe jetzt mal die Tabelle ein wenig geändert und komme damit
> exakt auf 51.2us:
>

>     signal Pulse : PulseTyp := (x"006", x"020", x"040", x"800", x"000", 
> x"000", x"000", x"000", x"000", x"000", x"000", x"000");
>

800Hex sind 2048dez * 25ns sind exact 51,2µs
das passt, das macht die Schaltung auch, nur das ich diesen Jitter auf 
dem Scope sehe. Am Ende von dem Puls sind es sogar 300ns.

Thorsten

[Schlumpf (Gast)]

Wieso triggerst du auf Kanal 2 auf der letzten "Rille" dieses Peaks, 
wenn du das Signal auf Kanal 1 vermessen willst?

[Thorsten F. (tfol)]

Schlumpf schrieb:
> Wieso triggerst du auf Kanal 2 auf der letzten "Rille" dieses Peaks,
> wenn du das Signal auf Kanal 1 vermessen willst?

Weil an Kanal 2 das Triggersignal anliegt, was mit dem 1. Puls für 100ns 
ausgegeben ist, ich kann nicht Kanal 1 mit 4 unterschiedlichen Pulsen 
als Trigger auswählen, dann gibt es "Kuddelmuddel".

[Schlumpf (Gast)]

Ah okay. Oben hast du 100ms geschrieben.
Habe mich schon gewundert.

schonmal geprüft, ob der Refernzpuls zu dem Rest jittert?

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

Thorsten F. schrieb:
> ich kann nicht Kanal 1 mit 4 unterschiedlichen Pulsen als Trigger
> auswählen, dann gibt es "Kuddelmuddel".
Oh doch. Mit deinem Oszi kannst du garantiert auf "Pulsdauer" triggern.

> Weil an Kanal 2 das Triggersignal anliegt
Das Triggersignal ist dieser PrePulseOut?

[Thorsten F. (tfol)]

Schlumpf schrieb:
> Ah okay. Oben hast du 100ms geschrieben.
> Habe mich schon gewundert.
Oh, sorry. Habe es oben berichtigt.

> schonmal geprüft, ob der Refernzpuls zu dem Rest jittert?
Ich versuche gerade den 40MHz Takt zu finden, am Quarz kommt ein Sinus 
mit ca. 27MHz raus....

[Schlumpf (Gast)]

Thorsten F. schrieb:
> am Quarz kommt ein Sinus
> mit ca. 27MHz raus....

Autsch!
Einen Sinus am CLK-Eingang ist nicht gerade das, was die interne PLL 
sehen will.

[Schlumpf (Gast)]

Fällt mir noch was auf:
Setze mal deinen Trigger am Oszi auf "Rising Edge".
kurz nach der fallenden Flanke des Triggerpulses kommt noch ein 
Überschwinger, der eventuell ein zweites Triggern verursachen könnte

[Falk B. (falk)]

@ Schlumpf (Gast)

>> am Quarz kommt ein Sinus
>> mit ca. 27MHz raus....

>Autsch!
>Einen Sinus am CLK-Eingang ist nicht gerade das, was die interne PLL
>sehen will.

Ich wette, der OP mist mit einem 1:1 Tastkopf ;-)

Auch sonst sieht das nach einem ziemlichen Messproblem aus, wenn er 
nicht mal einfache Pulse sauber auf den Oszi kriegt.

[Thorsten F. (tfol)]

Falk Brunner schrieb:
> @ Schlumpf (Gast)
>
>>> am Quarz kommt ein Sinus
>>> mit ca. 27MHz raus....
>
>>Autsch!
>>Einen Sinus am CLK-Eingang ist nicht gerade das, was die interne PLL
>>sehen will.
>
> Ich wette, der OP mist mit einem 1:1 Tastkopf ;-)
>
> Auch sonst sieht das nach einem ziemlichen Messproblem aus, wenn er
> nicht mal einfache Pulse sauber auf den Oszi kriegt.

Also der Sinus liegt am Quarz an, das ist normal für einen Quarz. Das 
ganze geht auf ein Clock IC CDCE913. Der macht darauf ein 40MHz Signal. 
Sieht allerdings auch nicht sehr rechteckig aus.

Und die Wette hast du verloren. Ich nutze das 10:1 Tastkopf HZ 350 von 
Hameg. Das kann bis 350MHz eingesetzt werden und wurde auch noch mal 
abgeglichen.

Thorsten

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

Thorsten F. schrieb:
> Sieht allerdings auch nicht sehr rechteckig aus.
Wo ist die Masse bei dieser Messung? Die darf nicht mehr als sagen wir 
mal 10mm neben dem Taktsignal abgegriffen werden.

[Lattice User (Gast)]

Schlumpf schrieb:
> Thorsten F. schrieb:
>> am Quarz kommt ein Sinus
>> mit ca. 27MHz raus....
>
> Autsch!
> Einen Sinus am CLK-Eingang ist nicht gerade das, was die interne PLL
> sehen will.

Wenn es eine externe Oscillatorschaltung gibt, wäre es in Ordnung.
An dieser Stelle ist ein Schaltplan angesagt!

[Lattice User (Gast)]

Übrigens wenn man alle 12 Pulse definiert

  type PulseTyp is array(0 to 11) of std_logic_vector(11 downto 0);          -- 12 Pulse Speicher mit max. 12Bit für 102,4µs
    signal Pulse : PulseTyp := (x"006", x"020", x"040", x"060", x"0FF", x"0FF", x"0FF", x"0FF", x"0FF", x"0FF", x"0FF", x"0FF");

  type PulsePauseTyp is array(0 to 11) of std_logic_vector(15 downto 0);      -- 12 Pulsepausen mit max. 16Bit für 1,6ms
    signal PulsePause : PulsePauseTyp := (x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF",x"00FF");

spukt Aldec-HDL einen Fehler aus:

run 500us
# RUNTIME: Fatal Error: RUNTIME_0047 pulsegen.vhd (35): Index 12 out of range (0 to 11).
# KERNEL: Time: 126412500 ps,  Iteration: 0,  Instance: /tb_pg/uut,  Process: Prescaler.
# KERNEL: stopped at delta: 0 at time 126412500 ps.
# Error: Fatal error occurred during simulation.

[Schlumpf (Gast)]

hat vermutlich nicht direkt mit deinem Problem was zu tun.
Aber unschön an deimem Code ist, dass du mit std_logic_vector "rechnest"
z.B.:

PulseZaehler <= PulseZaehler + 1;
oder
and PulseZaehler < 4 then

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

Schlumpf schrieb:
> Aber unschön an deimem Code ist, dass du mit std_logic_vector "rechnest"
Weil/Und du die alten Synopsys Libs verwendest...
Siehe den Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

[Thorsten F. (tfol)]

Lothar Miller schrieb:
> Schlumpf schrieb:
>> Aber unschön an deimem Code ist, dass du mit std_logic_vector "rechnest"
> Weil/Und du die alten Synopsys Libs verwendest...
> Siehe den Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

habe jetzt
use IEEE.STD_LOGIC_ARITH.ALL;
in
use IEEE.NUMERIC_STD.ALL;
geändert.
Das Signal sieht wie erwartet immer noch unschön aus.

Habe es aber hinbekommen mit der Simulation in ISMIM. Da sieht alles 
schön aus. Ich traue der Clock von dem Spartan-6 LX9 MicroBoard nicht. 
Die sieht auf dem Scope unschön aus und lässt sich nicht genau messen.
Werde morgen mal eine externe 40Mhz Clock da dran hängen und schauen wie 
es dann aussieht.

Vielen Dank schon mal bisher für die Hilfe.

Thorsten

[Lattice User (Gast)]

Thorsten F. schrieb:
> schön aus. Ich traue der Clock von dem Spartan-6 LX9 MicroBoard nicht.
> Die sieht auf dem Scope unschön aus und lässt sich nicht genau messen.


Wie klemmst du denn die Masse des Scope an, auch deine bisherigen Bilder 
sehen sehr hässlich aus. Bei einem 350 MHz Scope sollten Massefedern für 
die Probes beiliegen, verwende diese statt den Clips.

[Frank F. (frank_f49)]

Ich sehe  da  zwei  verschiedene  if-Anweisungen
in denen  irgendwelche Zähler entweder incrementiert
oder  resettet  werden.

Sollte  man  vielleicht besser  zu einer einzigen if Anweisung
zusammenfassen.

[Falk B. (falk)]

http://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen

Ich vermute auch, dass der Taktgenerator jittert. Wahrscheinlich ne 
miese PLL. Kann man leicht testen. Einfache einen 08/15, ähhh 
Binärzeäher mit 2^10 oder so takten lassen und das MSB anschauen, 
Trigger auf steigende Flanke, Zeitbasis aufdrehen, nächste fallende oder 
nachfolgende Flanken ansehen.

[Lattice User (Gast)]

Falk Brunner schrieb:
> 
http://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen
>
> Ich vermute auch, dass der Taktgenerator jittert. Wahrscheinlich ne
> miese PLL.

Das hier:
http://www.ti.com/lit/ds/symlink/cdce913.pdf
sieht nicht wie eine miese PLL aus.

Kan natürlich sein, dass Vctrl an einen DAC angeschlossen ist, und der 
DAC nicht auf die Mittenspannung für Vctrl eingestellt ist.

[Falk B. (falk)]

@ Lattice User (Gast)

>> Ich vermute auch, dass der Taktgenerator jittert. Wahrscheinlich ne
>> miese PLL.

>http://www.ti.com/lit/ds/symlink/cdce913.pdf
>sieht nicht wie eine miese PLL aus.

"PLL with SSC"

SSC Spread spectrum clock

Ausserdem kann auch ein guter IC durch falsche Beschaltung/Störung Mist 
machen.

>Kan natürlich sein, dass Vctrl an einen DAC angeschlossen ist, und der
>DAC nicht auf die Mittenspannung für Vctrl eingestellt ist.

Das macht aber keinen Jitter, nur einen Frequenzversatz.

[Achim S. (Gast)]

Schalte bitte mal die Kopplung des Triggers auf DC statt auf AC, damit 
sich der effektive Triggerpegel nicht in Abhängigkeit von der Pulsdauer 
verschiebt.

Außerdem wäre es gut, wenn du 10:1 Tastköpfe verwenden würdest und das 
auch am Oszi entsprechend einstellst: die angeblichen 200V/Kästchen sind 
ziemlich irritieren.

[Lattice User (Gast)]

Falk Brunner schrieb:
> @ Lattice User (Gast)
>
>>> Ich vermute auch, dass der Taktgenerator jittert. Wahrscheinlich ne
>>> miese PLL.
>
>>http://www.ti.com/lit/ds/symlink/cdce913.pdf
>>sieht nicht wie eine miese PLL aus.
>
> "PLL with SSC"
>
> SSC Spread spectrum clock

Hatte ich übersehen.
Wird über 3 Controlpins eingestellt, wenn diese mit dem FPGA verbunden 
sind und die entsprechenden Pins nicht auf GND eingestellt sind hat man 
+/-2% SSC.

Das ist sehr wahrscheinlich die Ursache.


>
> Ausserdem kann auch ein guter IC durch falsche Beschaltung/Störung Mist
> machen.

Auf einem Avnet Board? Eher nicht.


>
>>Kan natürlich sein, dass Vctrl an einen DAC angeschlossen ist, und der
>>DAC nicht auf die Mittenspannung für Vctrl eingestellt ist.
>
> Das macht aber keinen Jitter, nur einen Frequenzversatz.

Wenn es ausserhalb des Einstellbreiches ist, möglicherweise schon. Oder 
wenn der DAC wegen nicht angesteuerten Eingänge Mist ausgibt. Aber ich 
denke dass SSC der Grund ist.

[Thorsten F. (tfol)]

Lattice User schrieb:
>
> Wenn es ausserhalb des Einstellbreiches ist, möglicherweise schon. Oder
> wenn der DAC wegen nicht angesteuerten Eingänge Mist ausgibt. Aber ich
> denke dass SSC der Grund ist.

Die Beschaltung vom IC habe ich mal ausgeschnitten.
Masse nehme ich mit einem Extra Kabel ab von dem GND-Punkt auf dem 
Board, sonst ist da nichts in der Nähe, was ich nutzen könnte.

Was kann ich denn bei diesem Board machen bezüglich des "SSC-Problems"? 
Lieber gleich eine neue Clock basteln und dran hängen?

Gruß
Thorsten

[Lattice User (Gast)]

Thorsten F. schrieb:
>
> Die Beschaltung vom IC habe ich mal ausgeschnitten.
> Masse nehme ich mit einem Extra Kabel ab von dem GND-Punkt auf dem
> Board, sonst ist da nichts in der Nähe, was ich nutzen könnte.
>

GND Kabel ist schlecht und ist mit Sicherheit die Ursache für deine 
grausamen Oscibilder.


> Was kann ich denn bei diesem Board machen bezüglich des "SSC-Problems"?
> Lieber gleich eine neue Clock basteln und dran hängen?
>

Mit I2C die Register aus dem CDCE913 auslesen und überprüfen ob SSC im 
integrierten EEPROM des CDCE913 enabled wurde. 40 MHz ist ja auch nicht 
default, also wurde die Einstellung verändert.
Gibts es dafür ein Tool zu dem Board?

VCtrl hat einen Pullup auf 1.8V, und ist damit disabled, d.h. es kann 
nicht die Ursache sein.

[Falk B. (falk)]

@ Lattice User (Gast)

>> Die Beschaltung vom IC habe ich mal ausgeschnitten.
>> Masse nehme ich mit einem Extra Kabel ab von dem GND-Punkt auf dem
>> Board, sonst ist da nichts in der Nähe, was ich nutzen könnte.

>GND Kabel ist schlecht und ist mit Sicherheit die Ursache für deine
>grausamen Oscibilder.

AUA!

http://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen

"Everything is easy with the right tool. But a fool with a tool is still 
a fool."

[Lattice User (Gast)]

Falk Brunner schrieb:
> @ Lattice User (Gast)
>
>>> Die Beschaltung vom IC habe ich mal ausgeschnitten.
>>> Masse nehme ich mit einem Extra Kabel ab von dem GND-Punkt auf dem
>>> Board, sonst ist da nichts in der Nähe, was ich nutzen könnte.
>
>>GND Kabel ist schlecht und ist mit Sicherheit die Ursache für deine
>>grausamen Oscibilder.
>
> AUA!
>
> 
http://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen
>
> "Everything is easy with the right tool. But a fool with a tool is still
> a fool."

Du meinst also das GND Kabel ist die perfekte Methode?

[Thorsten F. (tfol)]

Lattice User schrieb:

> Mit I2C die Register aus dem CDCE913 auslesen und überprüfen ob SSC im
> integrierten EEPROM des CDCE913 enabled wurde. 40 MHz ist ja auch nicht
> default, also wurde die Einstellung verändert.
> Gibts es dafür ein Tool zu dem Board?


The following clock frequency outputs are pre-programmed into the 
CDCE913 during factory configuration.
Clock     CDCE913 Pin# Signal Name FPGA Pin#
40 MHz U1 pin 11 (Y1)   USER_CLOCK V10 (GCLK0)
66.7 MHz U1 pin 9 (Y2) CLOCK_Y2    K15 (GCLK9)
100 MHz U1 pin 8 (Y3)  CLOCK_Y3    C10 (GCLK13)

und diese Frequenzen habe ich auch nachgemessen, nur finde ich ist es 
nicht sehr exact und sauber.
Ich schaue morgen mal wie ich das Signal besser gemessen bekomme.

Gruß
Thorsten

[Ohh maahn (Gast)]

Thorsten F. schrieb:
> Bild1.jpg

Bevor man mit VHDL rum macht, könnte man sich erstmal elementare Dinge 
über Bildformate und Kompressionsalgorithmen zu Gemüte führen. JPG 
ist für Linien/Pixelgraphiken mit Farbpalette wirklich denkbar 
ungeeignet. Dafür wurde u.a. extra PNG entwickelt.

Ist das wirklich so schwer?

[Thorsten F. (tfol)]

Ohh maahn schrieb:
> Thorsten F. schrieb:
>> Bild1.jpg
>
> Bevor man mit VHDL rum macht, könnte man sich erstmal elementare Dinge
> über Bildformate und Kompressionsalgorithmen zu Gemüte führen. JPG
> ist für Linien/Pixelgraphiken mit Farbpalette wirklich denkbar
> ungeeignet. Dafür wurde u.a. extra PNG entwickelt.
>
> Ist das wirklich so schwer?

Geht es noch? Was hat das mit meinem Problem zu tun. Kauf dir eine 
Brille...
Das solche Typen in jedem Beitrag senfen müssen und dann noch feige als 
Gast... Habe es extra als kleines jpg angehängt um niemanden zu 
nerven...

Thorsten

[Thorsten F. (tfol)]

So, zurück zu den wichtigen Dingen.

Da ich hier die VHDL-Profis beisammen habe noch eine Frage:
Ich möchte die Array-Werte per SPI ändern können.
Dafür möchte ich ein serielles Wort rüber senden
1 Bit für Puls oder Pulspause = 1 für den Puls, 0 für die Pause
4 Bits für die PulseNr 0-11
und dann 16 Bits für meine Daten, wobei für den Puls nur die letzten 12 
benötigt werden.

Es sind also 21 Bit die ich rüberschieben muss um danach 2 Auswertungen 
zu machen um die Pulsedaten zu speichern.

Ich würde es gerne mit der SPI Anleitung von
http://www.lothar-miller.de/s9y/categories/26-SPI-Slave
machen, habe aber keine Ahnung ob ich einfach die 2 Arrays aus meiner 
Beschreibung oben erneut benennen kann und da drüberschreiben kann, wenn 
es in einer 2. vhd Datei liegt.

Ich versuche ja meine Probleme durch viel lesen und einverleiben von 
Büchern zu lösen, aber hier weis ich momentan nicht weiter.

Thorsten

[Falk B. (falk)]

@ Lattice User (Gast)

>Du meinst also das GND Kabel ist die perfekte Methode?

Natürlich nicht! Massefeder mit minimaler Länge! Wie im Link 
beschrieben!

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

Thorsten F. schrieb:
> habe aber keine Ahnung ob ich einfach die 2 Arrays aus meiner
> Beschreibung oben erneut benennen kann und da drüberschreiben kann, wenn
> es in einer 2. vhd Datei liegt.
Häh?
VHDL ist eine Hardwarebeschreibungssprache. Um etwas beschreiben zu 
können, muss man sich selbt ein Bild davon machen. Man küss such 
vorstellen, welche Hardware man damit bauen will.
Und jetzt nimm mal ein RAM und stell dir vor, du müsstest das mit VHDL 
beschreiben. Wie würde das wohl aussehen?

[Lattice User (Gast)]

Falk Brunner schrieb:
> @ Lattice User (Gast)
>
>>Du meinst also das GND Kabel ist die perfekte Methode?
>
> Natürlich nicht! Massefeder mit minimaler Länge! Wie im Link
> beschrieben!

Dann sind wir uns ja einig, hatte ich ja schon hier erwähnt:
Beitrag "Re: Pulse Generator nicht genau genug, brauche Hilfe"

Aus deinem Posting ging (zumindesten nicht für mich) hervor, ob du mir 
zustimmst oder widersprichst.

[Thorsten F. (tfol)]

Lothar Miller schrieb:
> Häh?
> VHDL ist eine Hardwarebeschreibungssprache. Um etwas beschreiben zu
> können, muss man sich selbt ein Bild davon machen. Man küss such
> vorstellen, welche Hardware man damit bauen will.
> Und jetzt nimm mal ein RAM und stell dir vor, du müsstest das mit VHDL
> beschreiben. Wie würde das wohl aussehen?

Die Frage ist halt ob ich da einfach noch mal parallel Adress- und 
Datenleitungen dran klemmen kann.
Ich habe halt die spi.vhd eingepflegt und weis jetzt nicht, wie ich die 
empfangenen Werte ins Array bekommen kann.

Thorsten

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

Thorsten F. schrieb:
> Die Frage ist halt ob ich da einfach noch mal parallel Adress- und
> Datenleitungen dran klemmen kann.
Nein. Sowas ergäbe im echten Leben eine Buskollision. Du wirst also 
einen Multiplexer brauchen, der die beiden "Teilnehmer" dem RAM 
zuordnet.

[Thorsten F. (tfol)]

Lothar Miller schrieb:
> Thorsten F. schrieb:
>> Die Frage ist halt ob ich da einfach noch mal parallel Adress- und
>> Datenleitungen dran klemmen kann.
> Nein. Sowas ergäbe im echten Leben eine Buskollision. Du wirst also
> einen Multiplexer brauchen, der die beiden "Teilnehmer" dem RAM
> zuordnet.

Also eine Art Umschalter?
Der bisherige Code liest ja nur aus dem Array, der SPI soll nur 
schreiben.

Ich wollte auch die Pulseausgabe stoppen, bevor über SPI gesendet wird 
und wenn die Arrays neu geschrieben wurden startet die Pulseausgabe 
wieder.
Dafür kommt noch ein extra PulseEnable Signal dazu.
Kann man sich dann den Multiplexer sparen?

Thorsten

[Christian R. (supachris)]

Beschreiben und Lesen muss schon im gleichen VHDL Modul passieren, einen 
echten RAM brauchst du dafür nicht, bei den paar Worten werden wohl die 
FlipFlops benutzt. Die Init-Werte überschreiben stellt kein Problem dar, 
nur kannst du Schreiben nur von einem Prozess aus, sonst gibts 
Kollision, und der Synthesizer schmeißt einen Fehler.

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

Thorsten F. schrieb:
> Der bisherige Code liest ja nur aus dem Array, der SPI soll nur
> schreiben.
Dann gibt das nicht wirklich ein RAM mit Adress- und Datenbus, sondern 
einfach nur ein paar Register, auf die beliebig lesend zugegriffen 
werden kann.

[Schlumpf (Gast)]

Wenn du das SPI von Lothar verwendest, musst du dir auch im Klaren 
darüber sein, dass dieses nicht synchron zu deinen Zielregistern ist.
Das heißt, dass im Moment der Datenübernahme (rising_edge(SS)) kann es 
werden deine Daten des Schieberegisters (doutsr) in das Register (Dout) 
übernommen.
Da die einzelnen Register von Dout nicht alle gleichzeitig umschalten 
und dein Zielregister (das, aus dem du dann den Wert für deine 
Pulsgenerierung übernimmst) aber mit einem anderen Takt arbeitet, kann 
es passieren, dass für einen Systemtakt irgendwelcher Unsinn in deinen 
Zielregistern steht.
Ergo: Es kann passieren, dass während der Umkonfiguration auch Pulse 
entstehen, die weder der alten noch der neuen Konfiguration entsprechen.

Wenn dich das nicht stört, kannst du den Code von Lothar so direkt 
übernehmen.

[Thorsten F. (tfol)]

Hi,

danke, dann werde ich probieren es mit in das Modul zu bauen.

Da ich die Pulseausgabe stoppe bevor ich über SPI Daten empfange/sende 
ist es egal ob da kurzfristig was falsches drin steht.
Die Pulsausgabe wird nach der SPI Übertragung mit Pulse(0) und 
zurückgesetzten Zählern neu gestartet.

Thorsten

[Thorsten F. (tfol)]

Zur Info:

Es liegt am Board. Das Spartan-6 LX9 MicroBoard erzeugt mit einem 
CDCE913 (a modular PLL-based low-cost, high-performance, programmable 
clock synthesizer) die Clock von 40Mhz, die ist aber sehr unsauber und 
nicht stabil.

Habe mit jetzt von ztex.de das FPGA Module 2.00: Spartan 6 FPGA Board
besorgt und damit läuft es sehr viel sauberer. Bisher nur mit 26Mhz, 
werden den Quarz aber gegen einen 40MHz tauschen.

Das Modul ist war etwas größer aber mit den Buchsenleisten kann ich es 
viel besser auf meiner Platine befestigen.

Vielen Dank Allen die mir geholfen haben.

Gruß
Thorsten

[Falk B. (falk)]

@ Thorsten F. (tfol)

>CDCE913 (a modular PLL-based low-cost, high-performance, programmable
>clock synthesizer) die Clock von 40Mhz, die ist aber sehr unsauber und
>nicht stabil.

Dazu mus DU erstmal ordentlich messen. Deine bisherige Beschreibung des 
Messaufbau läßt da nur Schlimmes ahnen.

Ich behaupte mal, dass der Taktgenerator schon ein ordentliches, 
jitterarmes Signal iefern kann, wenn er nicht kaputt ist, richtig 
konfiguriert und wenn richtig gemessen wird.

[Thorsten F. (tfol)]

Hi,

gleicher FPGA Inhalt, gleicher Messaufbau, gleiche Strippen und gleiches 
Oszi aber himmelweite Unterschiede am FPGA Ausgang. Da gibt es nicht 
mehr viel zum "schönmessen". Evtl. hat der Quarz auch einen weg, das 
Signal sieht schon nicht gut aus.
Ich werde mit dem neuen Board weiter machen, das andere kommt in den 
Schrank.

DONE

Thorsten

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

Thorsten F. schrieb:
> Ich werde mit dem neuen Board weiter machen, das andere kommt in den
> Schrank.
Mich würde da die Ursache interessieren. Eher morgen als übermorgen holt 
einen das Problem wieder ein...

[Falk B. (falk)]

@ Thorsten F. (tfol)

>gleicher FPGA Inhalt, gleicher Messaufbau, gleiche Strippen und gleiches
>Oszi aber himmelweite Unterschiede am FPGA Ausgang. Da gibt es nicht
>mehr viel zum "schönmessen".

Wenn man den Fehler nicht finden will, ist das logisch.

>Evtl. hat der Quarz auch einen weg, das
>Signal sieht schon nicht gut aus.

Weil deine Messung nichts taugt.

>DONE

Auch eine Lösung. Mein Ding wäre es nicht.

McMurphy is watching you!

[Tim R. (mugen)]

Thorsten F. schrieb:
> CDCE913

Das ist irgendwie total deprimierend, weil ich genau diesen Baustein 
einsetzen wollte um 100Mhz zu generieren. Kennt jemand eine andere 
Lösung für einen kleinen MAX V Baustein?

Wobei... Ich glaub nicht das es am PLL Baustein liegen wird.