MachXO2 - Ausgang schwingt

[Günter (. (dl4mea)]

Hallo alle,

ich mache gerade einen ersten Versuch mit einem MachXO2 Pico Board, auf 
diesem befindet sich ein MachXO2 im BGA-Gehäuse. Ich verwende den vom 
USB-Chip abgezweigten 12MHz-Takt, der an Pin A7 "PT12A/PCLKT0_1" 
eingespeist wird. Auch versuchshalber mal die PLL als Clock-Regenerator 
benutzt hat auch nichts geändert.

Problem: Eine Situation im MachXO2 gebe ich als Puls mit einem Takt 
Länge auf einem Pin auf der Steckerleiste aus. Den Pin habe ich schon 
gewechselt, alle verhalten sich gleich: Es ist kein schöner Impuls 
sondern ein heftiges Schwingen bei ca. 80MHz. Siehe Bild, oben mein 
Puls, unten der PLL-regenerierte Takt auf einen Ausgang gelegt.
Gleiches Verhalten auch wenn ich in der Pinkonfiguration verschiedene 
Modis einstelle, z.B. Pullup/-down eingestellt. Das Bild ist mit 
LVCMOS33 auf Pin D1 "PL3B/PCLKC3_2" aufgenommen.

Oszi ist ein HP54615B und Tastkopf PML711A (500MHz) von PMK. Ich kann 
andere Signale ohne Probleme messen, an diesen Teilen liegt es also 
nicht.

Was muß ich tun um hier einen halbwegs sauberen Puls zu bekommen?

Danke für jede Hilfe, Günter

[Schlumpf (Gast)]

Günter (dl4mea) schrieb:
> Was muß ich tun um hier einen halbwegs sauberen Puls zu bekommen?

Den Fehler finden :-)

Ne, im Ernst:

Du kannst deinen PLL-Ausgang auf einen beliebigen Pin ausgeben und alles 
sieht erwartungsgemäß aus?
Du kannst deinen Impuls auf einen beliebigen Pin ausgeben und er sieht 
schrecklich aus?

Dann würde ich jetzt erstmal vermuten, dass es an der Art und Weise 
liegt, wie du diesen Puls generierst. An der Hardware wird es eher nicht 
liegen, wenn du den PLL Takt ausgeben kannst.

Daher wäre es hilfreich, wennn du deinen Code mal postest.

Oder es könnte noch am Messaufbau liegen.
Alle Massen richtig angeschlossen?

[Fpgakuechle K. (Gast)]

Günter (dl4mea) schrieb:

Stellt man die SLEWRATE für die outputs auf FAST kommt es zu 
Über/Unter-schwingern. Versuch es mal mit SLEWRATE=SLOW.

http://www.latticesemi.com/~/media/Documents/ApplicationNotes/MO/MachXO2sysIOUsageGuide.pdf 
S.9

Treiberstärke runter stellen könnte auch helfen. (S.12)

MfG,

[Günter (. (dl4mea)]

Hallo Schlumpf,

offenbar hast du den Punkt getroffen. Da ich meinen Original-Code nicht 
posten wollte habe ich kurz eine Demo aufgesetzt (siehe unten) und da 
kommt ein schöner Puls raus. Siehe erster Screenshot.

Im zweiten hab ich mit der PLL mal 144MHz gemacht um den Puls kürzer zu 
machen. Zweiter Screenshot. Und weils gerade Spaß gemacht hat, aber 
eigentlich nichts mit dem Problem zu tun hat, die 144MHz am 
Spektrumanalyzer angeschaut. Drittes Bild.

Im Original wird ein Pattern detektiert und über Kombinatorik (außerhalb 
des Taktes) erkannt. Scheinbar ist da der Fehler zu suchen. Jetzt weiß 
ich wenigstens wo ich ansetzen muß. Die Simulation schaut hier aber 
total gut aus...

Danke für deine Hilfe. Den Demo-Code poste ich auch mal, vielleicht 
hilfts dem einen oder anderen auch.

Schönen Sonntag noch, Günter

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;    -- for unsigned, integer, conversions

LIBRARY lattice;
USE lattice.components.all;

--------------------------------------------------------------------------------------

ENTITY Clock_Demo IS
    PORT
    (
        clk_in    : in  std_logic;
        clk_out   : out std_logic;
        pulse_out : out std_logic
    );      
  
END Clock_Demo;

--------------------------------------------------------------------------------------

ARCHITECTURE behavior OF Clock_Demo IS

signal  clk   : std_logic;
signal  count : natural range 0 to 11 := 0;

BEGIN

  -- Additional Components --
  ---------------------------

    myPLL : entity work.pll_12in144out (Structure)
    port map
    (
        clki  => clk_in,
        clkop => clk
    );

    
PROCESS (clk) BEGIN   
        
    -- Interconnection Signals that are routed to output pins
    clk_out   <= clk;

    IF rising_edge(clk) then               
            
        -- clock phase counter  
        if count < 11 then
            count <= count + 1;
        else
            count <= 0;
        end if;
      
    end if;
            
END PROCESS;
  
    pulse_out <= '1' when count=0 else '0';
    
END behavior;

[Lattice User (Gast)]

Günter (dl4mea) schrieb:
>
> Im Original wird ein Pattern detektiert und über Kombinatorik (außerhalb
> des Taktes) erkannt. Scheinbar ist da der Fehler zu suchen. Jetzt weiß
> ich wenigstens wo ich ansetzen muß. Die Simulation schaut hier aber
> total gut aus...
>

Vermutlich hast du eine combinitorische Loop gebaut (bzw Latch). Da 
deren Verhalten von Signallaufzeiten abhängt sieht man es in einer 
functionalen Simulation eventuell nicht.
In einer Post P&R Simulation sollte es jedoch zu sehen sein.

Combinitorische Loops und Latches produzieren jede menge Warnungen, 
schau dir den Syntheserepoert genau an.

Verwende Massefedern an deinen Probes statt die Masseclips irgendwo 
anzuschliessen. Das vermeidet dass sich hier manche an den hässlichen 
Überschwingern stören.

[Schlumpf (Gast)]

Hallo Günter,

gerne geschehen.

Kannst ja mal deinen Synthese-Report nach dem Stichwort (Warning) 
"Combinatorial Loop" durchsuchen.

Könnte sein, dass du synchron zum Takt ein Signal erzeugst, welches 
einen Takt lang gültig ist.
Mit diesem Signal gehst du in eine Kombinatorik (deine 
Patternauswertung).

Und eventuell geht einer der Ausgänge dieses kombinatorischen Teils 
wieder als Eingang zurück in die Kombinatorik.

Ganz simples Beispiel hierfür wäre:

Ein NAND an dem ein Eingang an ein synchrones Steuersignal verbunden ist 
und der andere Eingang mit dem Ausgang des NAND verbunden ist.

Dann schwingt das Teil, solange das synchrone Steuersignal High ist.

Schätze mal, dass du sowas in der Art gebaut hast.

[Günter (. (dl4mea)]

Hallo Schlumpf,

ich hab noch gesucht nach der Slewrate. Aber ich vermute fast die ist 
bei 3.3V VCCIO nicht einstellbar.

Um es 'richtig' zu machen habe ich im Spreadsheet-View bei den Global 
Preferences Bank VCCIO auf 3.300 eingestellt - und in den Port 
Assignements dann LVTTL33 oder LVCMOS33. Zuvor waren da 2.5V 
eingestellt, und da gibt es dann in den Port Assignments eine 
Möglichkeit für Slew Rate, die es bei 3.3V nicht mehr gibt. Fühl mich 
aber mit der 3.3V-Einstellung irgendwie wohler...

Übrigens ändert sich am Ausgang nichts egal ob ich LVTTL33 oder LVCMOS33 
einstelle, die Überschwinger bleiben.

Und wegen der kombinatorischen Loop: Ich erinnere mich dass da irgendwo 
eine Fehlermeldung war :) Finde das aber jetzt auf die schnelle nicht 
mehr. Wenn sie wieder kommt, werd ich sie gebührend begrüssen.

VG Günter

[Günter (. (dl4mea)]

Schlumpf schrieb:
> Ein NAND an dem ein Eingang an ein synchrones Steuersignal verbunden ist
> und der andere Eingang mit dem Ausgang des NAND verbunden ist.

Pretty simple: Edge Detector, aber die Zuweisung ans <signal>_tm1 stand 
nicht unter dem Clock-Prozess...

[Lattice User (Gast)]

Günter (dl4mea) schrieb:

>
> Übrigens ändert sich am Ausgang nichts egal ob ich LVTTL33 oder LVCMOS33
> einstelle, die Überschwinger bleiben.

Liegt zu 99% daran wie due die Masse der Probes verbindest. Nochmal, 
verwende Massefedern zum Aufstecken auf die Probespitze, und greife die 
Masse möglichst nah am zu messenden Signal ab.

[Schlumpf (Gast)]

Günter (dl4mea) schrieb:
> ich hab noch gesucht nach der Slewrate.

Die Slewrate ist definitiv nicht dein Problem..

Günter (dl4mea) schrieb:
> Und wegen der kombinatorischen Loop: Ich erinnere mich dass da irgendwo
> eine Fehlermeldung war :)

Lagen Lattice User und ich offensichtlich nicht ganz daneben ;-)

Günter (dl4mea) schrieb:
> Pretty simple: Edge Detector, aber die Zuweisung ans <signal>_tm1 stand
> nicht unter dem Clock-Prozess...

Heißt jetzt konkret was?

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

Günter (dl4mea) schrieb:
> Und wegen der kombinatorischen Loop: Ich erinnere mich dass da irgendwo
> eine Fehlermeldung war :)
Das wäre ein absolutes KO für das Design. So eine kombinatorische 
Schleife versteckt sich auch gern mal hinter einem Latch: 
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html

[Günter (. (dl4mea)]

Hallo,

schreib es mal meiner Unerfahrenheit zu daß in der C++-Programmierung 
häufig Warnings einfach ignoriert werden (naja, nicht ganz...)

Also es war folgendes (falsch):

     -- edge detection capabilites
     pattern_detected_tm1 <= preamble_detected;

     -- decode the pattern
     pattern_detected :=     ...pattern_condition_1...
                         and ...pattern_condition_2...
                         and ...pattern_condition_3...
                         and not pattern_detected_tm1;

     IF rising_edge(clk) then               
            
         -- debounce input
         in_port_tm1 <= in_port;
         in <= in_port_tm1;

Richtigerweise gehört das edge detection halt einfach einen Clock später

     -- decode the pattern
     pattern_detected :=     ...pattern_condition_1...
                         and ...pattern_condition_2...
                         and ...pattern_condition_3...
                         and not pattern_detected_tm1;

     IF rising_edge(clk) then               
            
         -- edge detection capabilites
         pattern_detected_tm1 <= preamble_detected;

         -- debounce input
         in_port_tm1 <= in_port;
         in <= in_port_tm1;

Ganz klar die von Schlumpf beschriebene Schleife um ein NAND-Gatter.
In der Simulation hab ich das nicht gesehen.
Und wie schon geschrieben, das entsprechende Warning übersehen.

Lessons learned halt eben.

Schönen Sonntag noch, Günter

[Schlumpf (Gast)]

Auch wenn ich in dem von dir geposteten Codeschnipsel keine 
Combinatorial Loop erkennen kann, wenn der Hinweis geholfen hat, dann 
ist ja gut ;-)

[Fpgakuechle K. (Gast)]

Günter (dl4mea) schrieb:

> Richtigerweise gehört das edge detection halt einfach einen Clock später
>
>

>          -- debounce input
>          in_port_tm1 <= in_port;
>          in <= in_port_tm1;
>

Nebenbemerkung: Bitte keine Schlüsselwörter als identifier verwenden. Im 
source oben ist das für die Portrichtung reservierte Wort "in" als 
Signal- oder port-name benutzt. Auch wenn das kein Fehler ist, es bringt 
den Syntaxhighlight und style-checker durcheinander.

MfG

[Fpgakuechle K. (Gast)]

Günter (dl4mea) schrieb:

>

> ENTITY Clock_Demo IS
>     PORT
>     (
>         clk_in    : in  std_logic;
>         clk_out   : out std_logic;
>         pulse_out : out std_logic
>     );
> END Clock_Demo;

> PROCESS (clk) BEGIN
> 
>     -- Interconnection Signals that are routed to output pins
>     clk_out   <= clk; --!!!!MISSPLACED
> 
>     IF rising_edge(clk) then
>         -- clock phase counter
>         if count < 11 then
>             count <= count + 1;
>         else
>             count <= 0;
>         end if;
>     end if;
> END PROCESS;

>

Die Signalzuseisung "clk_out <= clk;" innerhalb eines Process gehört da 
nicht hin.

MfG,

[Günter (. (dl4mea)]

Fpga Kuechle schrieb:
> Die Signalzuseisung "clk_out <= clk;" innerhalb eines Process gehört da
> nicht hin.

Sorry wenn ich jetzt frage: Wohin dann?

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

Günter (dl4mea) schrieb:
> Sorry wenn ich jetzt frage: Wohin dann?
Einfach Concurrent irgendwo hin:

-- hierhin
clk_out <= clk;

PROCESS (clk) BEGIN   
        
    IF rising_edge(clk) then  -- nur die Taktabfrage gehört in einen getakteten Prozess
                              -- und allerhöchstens noch ein zugehöriger asynchroner Reset            
        -- clock phase counter  
        if count < 11 then
            count <= count + 1;
        else
            count <= 0;
        end if;
      
    end if;
            
END PROCESS;

-- oder hierhin
clk_out <= clk;
  
pulse_out <= '1' when count=0 else '0';

-- oder hierhin
clk_out <= clk;