Problem mit IDDR2 und Schieberegister

[Andreas B. (loopy83)]

Hallo,

ich habe folgendes Problem.

Ich habe serielle LVDS Daten (8bit), die ich mittels eines 
Schieberegsiters parallelisiere. Das klappt so alleine wunderbar in der 
Simulation (SR_solo.png). Also die erste '1' wird auf Bit 0 des SRs 
eingelesen und geschiftet, alle weiteren Daten werden korrekt eingelesen 
und bei Full = '1' können sie dann ausgelesen werden.

Nun möchte ich aber die Daten auf der steigenden und fallenden Flanke 
des Taktes auslesen. Dazu verwende ich ein IDDR2, welches mittels eines 
DCM getaktet ist. Die Ausgänge Q0 und Q1 gehen jeweils auf zwei 
getrennte Schieberegister. Aber hier übernimmt das SR statt der '1' am 
Anfang eine '0' und dadurch stimmt die Ausgabe nicht mehr.

Ich habe nun testweise den Datenzweig der fallenden Flanke deaktiviert 
und will wie zuvor auch nur die Daten der steigenden Flanke auslesen. 
Diese Daten stammen aber diesmal von einem IDDR2, Ausgang Q0.
In dieser Konstellation tritt der Fehler auch auf... statt einer '1' 
wird eine '0' im ersten Takt auf Bit 0 des SRs gelesen. Auch folgende 
Takte stimmen teilweise nicht überein mit dem, was ich erwarte beim 
Dateneinlesen (SR_IDDR2.png).

Wo genau kann der Fehler liegen, wenn das Schieberegister wunderbar 
funktioniert, aber sobald ein IDDR2 dazwischen geschaltet wird, die 
Eingabe in das SR fehlerhaft ist? Muss ich in dem Zusammenhang noch 
etwas beachten?

Ich habe meine Quellen incl. der beiden Testbenches mit angehängt, 
vielleicht hilft es bei der Fehlersuche?!

TOPFILE.zip
  |---TOPFILE.vhd              => tb_TOPFILE_IDDR2.vhd
        |--DIFF_CLOCK_IN.vhd
        |--DIFF_DATA_IN.vhd
        |--schiebereg.vhd      => tb_schiebreg8bit.vhd

VIELEN DANK!!

[Andreas B. (loopy83)]

Ich habe gerade gesehen, dass das zweite SR, was ich aktuell noch 
auskommentiert hatte, funktioniert. Auch zusammen mit dem IDDR2.

Sie fallende Flanke funktioniert also, nur die steigende macht 
Probleme...

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;


entity S2P_1laneDATA is
Port ( CLOCK_IN_P : in  STD_LOGIC;       --LVDS Takt
       CLOCK_IN_N : in  STD_LOGIC;       --LVDS Takt
     RESET : in  STD_LOGIC;            --Schieberegister Reset
     RESET_DCM : in STD_LOGIC;         --DCM Reset
     FULL_ris : out  std_logic;      --schieberegister mit 8bit geladen
     FULL_fal : out  std_logic;      --schieberegister mit 8bit geladen
       DATA_IN_P : in  STD_LOGIC;        --serielle Daten Eingang
     DATA_IN_N : in  STD_LOGIC;        --serielle Daten Eingang
     DATA_OUT_ris : out STD_LOGIC_VECTOR (7 downto 0); --parallele Daten Ausgang steigende Flanke
     DATA_OUT_fal : out STD_LOGIC_VECTOR (7 downto 0); --parallele Daten Ausgang fallende Flanke
     SET_IDDR2 : in  STD_LOGIC
      );
end S2P_1laneDATA;

architecture Behavioral of S2P_1laneDATA is

COMPONENT DIFF_CLOCK_IN
  PORT(
    CLKIN_N_IN : IN std_logic;
    CLKIN_P_IN : IN std_logic;
    RST_IN : IN std_logic;          
    CLKIN_IBUFGDS_OUT : OUT std_logic;
    CLK0_OUT : OUT std_logic;
    CLK180_OUT : OUT std_logic;
    LOCKED_OUT : OUT std_logic
    );
  END COMPONENT;

COMPONENT DIFF_DATA_IN
  PORT(
    DATA_N : IN std_logic;
    DATA_P : IN std_logic;          
    DATA_OUT : OUT std_logic
    );
  END COMPONENT;

COMPONENT schiebereg8bit
  PORT(
    CLOCK_SR : IN std_logic;
    RESET_SR : IN std_logic;
    DATA_IN_SR : IN std_logic;          
    FULL : OUT std_logic;
    DATA_OUT_SR : OUT std_logic_vector(7 downto 0)
    );
  END COMPONENT;

signal CLOCK_IN_DCM0 : STD_LOGIC;
signal CLOCK_IN_DCM180 : STD_LOGIC;
signal DCM_DIFF_LOCK : STD_LOGIC;
signal CLOCK_IN : STD_LOGIC;
signal DATA_IN : STD_LOGIC;
signal DATA_IN_ris : STD_LOGIC;
signal DATA_IN_fal : STD_LOGIC;
signal DATA_READ_EN_ris : STD_LOGIC;
signal DATA_READ_EN_fal : STD_LOGIC;
signal DATA_OUT_INT_ris : STD_LOGIC_VECTOR (7 downto 0);
signal DATA_OUT_INT_fal : STD_LOGIC_VECTOR (7 downto 0);

constant IDDR2_CE : STD_LOGIC := '1';
  
begin

Inst_DIFF_CLOCK_IN: DIFF_CLOCK_IN PORT MAP(
    CLKIN_N_IN => CLOCK_IN_N,
    CLKIN_P_IN => CLOCK_IN_P,
    RST_IN => RESET_DCM,
    CLKIN_IBUFGDS_OUT => CLOCK_IN,
    CLK0_OUT => CLOCK_IN_DCM0,
    CLK180_OUT => CLOCK_IN_DCM180,
    LOCKED_OUT => DCM_DIFF_LOCK
  );

Inst_DIFF_DATA_IN: DIFF_DATA_IN PORT MAP(
    DATA_OUT => DATA_IN,
    DATA_N => DATA_IN_N,
    DATA_P => DATA_IN_P
  );

IDDR2_inst : IDDR2
generic map (
   DDR_ALIGNMENT => "NONE", -- Sets output alignment 
                            -- to "NONE", "C0" or "C1"
   INIT_Q0 => '0', -- Sets initial state of the Q0  
                   --   output to ?0? or ?1?
   INIT_Q1 => '0', -- Sets initial state of the Q1 
                   --   output to ?0? or ?1?
   SRTYPE => "SYNC") -- Specifies "SYNC" or "ASYNC" 
                      --   set/reset
port map (
   Q0 => DATA_IN_ris, -- 1-bit output captured with C0 clock
   Q1 => DATA_IN_fal, -- 1-bit output captured with C1 clock
   C0 => CLOCK_IN_DCM0, -- 1-bit clock input
   C1 => CLOCK_IN_DCM180, -- 1-bit clock input
   CE => IDDR2_CE, -- 1-bit clock enable input
   D => DATA_IN,   -- 1-bit DDR data input
   R => RESET,   -- 1-bit reset input
   S => SET_IDDR2    -- 1-bit set input
);


Inst_schiebereg8bit1: schiebereg8bit PORT MAP(
    CLOCK_SR => CLOCK_IN_DCM0,
    RESET_SR => RESET,
    DATA_IN_SR => DATA_IN_ris,
    FULL => DATA_READ_EN_ris,
    DATA_OUT_SR => DATA_OUT_INT_ris
  );

Inst_schiebereg8bit2: schiebereg8bit PORT MAP(
    CLOCK_SR => CLOCK_IN_DCM0,
    RESET_SR => RESET,
    DATA_IN_SR => DATA_IN_fal,
    FULL => DATA_READ_EN_fal,
    DATA_OUT_SR => DATA_OUT_INT_fal
  );
  
READ_EN : process (RESET, DATA_READ_EN_ris, DATA_READ_EN_fal, DATA_OUT_INT_ris, DATA_OUT_INT_fal)
begin
    if (RESET = '1') then
      DATA_OUT_ris <= (others => '0');
    elsif (DATA_READ_EN_ris = '1') then
      DATA_OUT_ris <= DATA_OUT_INT_ris;
    else
      DATA_OUT_ris <= (others => '0');
    end if;
    
    if (RESET = '1') then
      DATA_OUT_fal <= (others => '0');
    elsif (DATA_READ_EN_fal = '1') then
      DATA_OUT_fal <= DATA_OUT_INT_fal;
    else
      DATA_OUT_fal <= (others => '0');
    end if;
    
end process;

FULL_ris <= DATA_READ_EN_ris;
FULL_fal <= DATA_READ_EN_fal;


end Behavioral;

[Andreas B. (loopy83)]

Ich denke ich habe den Fehler gefunden.
Der IDDR2 erzeugt ein Delay im Datenzweig... der Takt ist laut 
Simulation 100ps eher da als die Daten und daher kann auch keine '1' 
übernommen werden.

Nun ist wieder die Frage: Wie kann ich die Daten synchron zum Takt 
schalten?

Kann ich den Takt irgendwie künstlich durch ein paar Gatter schicken, 
dass dieser die gleiche Laufzeit hat wie die Daten und beide wieder 
synchron am Eingang des SRs ankommen?

DANKE!!!

[Christian R. (supachris)]

Für genau diesen Anwendungsfall gibts doch den DCM. Da kannst du die 
Phasenlage aller Ausgangstakte zum Eingangstakt nochmal ganz fein 
einstellen, im ps-Stufen. Siehe Bild -> Phase Shift

In der Hardware kann das dann durchaus noch mehr als 100ps werden. Da 
musst du dann bestimmt nochmal am Delay drehen.

[Andreas B. (loopy83)]

Ach na klar... oh mann... die einfachsten Lösungen sieht man nicht...

Also stelle ich den Parameter CLKOUT_PHASE_SHIFT auf "FIXED", nur 
welcher Parameter legt fest, wie groß das Delay ist?

Ich würde nur sehr ungern einen neuen IPCore einbinden. Den vorhandenen 
editieren wäre mir fast lieber.

VIELEN DANK!!!

[Christian R. (supachris)]

Na gut, du könntest auch das Datenblatt des DCM oder im User Guide 
lesen, aber "PHASE_SHIFT = 5" wäre zum Beispiel eine Einstellung. 
Ausrechnen, wieviel das ist, musst du aber selbst, die Formel steht im 
Datenblatt.

[Andreas B. (loopy83)]

Hallo,

Kann man dieses Delay denn auch simulieren?

Ich habe nun doch einen neuen IP Core erzeugt und den VDHL Code kopiert 
und anschließend versucht zu simulieren. Egal ob Phaseshift => 0 oder => 
255, das Simulationsergebnis unterscheidet sich in keinster Weise. Auch 
im Größten Zoom ist kein Delay des DCM0 zum Eingangstakt sichtbar.

Das hier ist der erzeigte Code, den Phaseshift Parameter habe ich dann 
wahlweise verändert, nur leider ohne Ergebnis:

entity DIFF_CLOCK_IN is
   port ( CLKIN_N_IN        : in    std_logic; 
          CLKIN_P_IN        : in    std_logic; 
          RST_IN            : in    std_logic; 
          CLKIN_IBUFGDS_OUT : out   std_logic; 
          CLK0_OUT          : out   std_logic; 
          CLK180_OUT        : out   std_logic; 
          LOCKED_OUT        : out   std_logic);
end DIFF_CLOCK_IN;

architecture BEHAVIORAL of DIFF_CLOCK_IN is
   signal CLKFB_IN          : std_logic;
   signal CLKIN_IBUFGDS     : std_logic;
   signal CLK0_BUF          : std_logic;
   signal CLK180_BUF        : std_logic;
   signal GND_BIT           : std_logic;
begin
   GND_BIT <= '0';
   CLKIN_IBUFGDS_OUT <= CLKIN_IBUFGDS;
   CLK0_OUT <= CLKFB_IN;
   CLKIN_IBUFGDS_INST : IBUFGDS
      port map (I=>CLKIN_P_IN,
                IB=>CLKIN_N_IN,
                O=>CLKIN_IBUFGDS);
   
   CLK0_BUFG_INST : BUFG
      port map (I=>CLK0_BUF,
                O=>CLKFB_IN);
   
   CLK180_BUFG_INST : BUFG
      port map (I=>CLK180_BUF,
                O=>CLK180_OUT);
   
   DCM_SP_INST : DCM_SP
   generic map( CLK_FEEDBACK => "1X",
            CLKDV_DIVIDE => 2.0,
            CLKFX_DIVIDE => 1,
            CLKFX_MULTIPLY => 4,
            CLKIN_DIVIDE_BY_2 => FALSE,
            CLKIN_PERIOD => 6.250,
            CLKOUT_PHASE_SHIFT => "FIXED",
            DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
            DFS_FREQUENCY_MODE => "LOW",
            DLL_FREQUENCY_MODE => "LOW",
            DUTY_CYCLE_CORRECTION => TRUE,
            FACTORY_JF => x"C080",
            PHASE_SHIFT => 128,
            STARTUP_WAIT => FALSE)
      port map (CLKFB=>CLKFB_IN,
                CLKIN=>CLKIN_IBUFGDS,
                DSSEN=>GND_BIT,
                PSCLK=>GND_BIT,
                PSEN=>GND_BIT,
                PSINCDEC=>GND_BIT,
                RST=>RST_IN,
                CLKDV=>open,
                CLKFX=>open,
                CLKFX180=>open,
                CLK0=>CLK0_BUF,
                CLK2X=>open,
                CLK2X180=>open,
                CLK90=>open,
                CLK180=>CLK180_BUF,
                CLK270=>open,
                LOCKED=>LOCKED_OUT,
                PSDONE=>open,
                STATUS=>open);
   
end BEHAVIORAL;

VIELEN, VIELEN DANK!!!

[Christian R. (supachris)]

Ja kann man simulieren. Dazu muss die Simulations-Auflösung aber 1ps 
oder kleiner sein. Ich konnte den DCM bisher immer in der Simulation 
benutzen, allerdings instanziiere ich immer nur den Core, den der 
Core-Generator ausspuckt. Das machts übersichtlicher.

[Andreas B. (loopy83)]

Hab es jetz genauso gelöst, hab den Core direkt eingebunden. So kann man 
ja auch recht einfach direkt über den Wizzard das Delay einstellen.

Nur leider kann ich kein Delay erzeugen. Der Versatz zwischen Daten und 
Clock bleibt unverändert bei 100ps... keine Chance daran zu rütteln und 
das Design zu ner vernünftigen Funktion zu bewegen.

Im Modelsim kann ich bis zu einem Abstand von 1ps zoomen, also an der 
Auflösung sollte es nicht liegen. Zumal ich nun testweise das Delay auf 
2ns gestellt habe. Leider keine Veränderung :(

[Duke Scarring (Gast)]

@Andreas B.:
>Im Modelsim kann ich bis zu einem Abstand von 1ps zoomen,
Das reicht nicht.

Du mußt die Auflösung beim Simulieren anpassen:

vsim -t ps ...

Duke

[Andreas B. (loopy83)]

In der .fdo Datei steht schon folgendes drin:

vsim -t 1ps   -lib work tb_TOPFILE_DCM_DELAY

Reicht das aus, oder wie verwende ich den Befehl?

Hab ihn gerade versucht im mehreren Varianten einzugeben, leider 
resultiert bisher jeder Versuch in einer Fehlermeldung.

Ich starte das Modelsim direkt aus dem ISE...

DANKE

[Duke Scarring (Gast)]

@Andreas B:
Sieht eigentlich gut aus. Wie lautet denn die Fehlermaldung?
Laß mal die Zahl vor der Einheit weg:

vsim -t ps   -lib work tb_TOPFILE_DCM_DELAY

Duke

[Andreas B. (loopy83)]

vsim -t ps   -lib work tb_TOPFILE_DCM_DELAY

damit macht er was, hatte ich vorhin schon einmal probiert.
Nur leider verschwinden dann meine Simulationsergebnisse (Kurven) und 
ich habe ihm bis jetzt noch nicht beibringen können, wieder erneut zu 
starten.

weder "restart" noch "run 100000" bewirken etwas.

Wenn ich erneut "do {tb_TOPFILE_DCM_DELAY.fdo}" eingebe, wie von ISE 
ganz am Anfang einer jeden Simulation, wird scheinbar alles wieder 
zurückgesetzt und die einstellungen von vsim -t gehen wieder verloren. 
Zumindest unterscheidet sich das Simulationsergebniss nicht von dem 
davor... sofern die Auflösung der Grund für das nicht wirkende Delay des 
DCM ist...

VIELEN DANK!

[Christian R. (supachris)]

Naja, die Voreinstellung bei Xilinx ist schon 1ps Auflösung beim Start 
der Simulation. Aber um diesem allen aus dem Weg zu gehen, kommst du 
eventuell besser, wenn du dir im ModelSim eigene Projekte anlegst dafür. 
Das ist viel bequemer. Dann ein .do File, in dem die Befehle für die 
Simulation stehen:

vsim ...
add wave *
run 10000 ns

usw.

[Andreas B. (loopy83)]

Also das bedeutet so viel, wie es liegt nicht an der Auflösung, dass die 
100ps Delay weiterhin bestehen und ich meinen Ausgangstakt vom DCM nicht 
verzögern kann.

Das ist weniger gut. Ich hatte gehofft, dass es nur noch eine 
Einstellungssache ist.

Auch wenn ich den DCM stand-alone simuliere und Eingangstakt und 
Ausgangstakt vergleiche, sind diese identisch trotz eingestelltem 
Delay... ich verstehs nicht :(

Aber ohne diese Verzögerung kann ich zwar schauen, dass mein Design was 
auswirft, aber inwieweit sinnvoll das ist, kann ich dann nicht mehr 
beurteilen, wenn meine Daten schon falsch eingelesen werden. Somit kann 
ich nicht mal die logische Funktion nachweisen und muss mich dann dazu 
in der realen Hardware noch mit Timingsachen rumschlagen... eine 
schlechte Kombination. Ich hoffe ich finde noch eine Lösung. Ich werde 
es mal mit einem komplett neuen Projekt versuchen, in dem ich einfach 
nur den DCM simuliere, ohne irgendetwas drum herum.

MfG

[Andreas B. (loopy83)]

Als einzelner Core, aufgerufen in einem eigenen Topfile in einem eigenen 
Projekt funktioniert die Verzögerung des Ausgangstaktes auch nicht :(

[Andreas B. (loopy83)]

Könnte es was damit zu tun haben?

# WARNING: No extended dataflow License exists

[Christian R. (supachris)]

Sind denn die Simulationsmodelle aktuell? Da gibts ja immer mal neue von 
Xilinx. Es gab gerade beim DCM mal Probleme, da ging z.B. das LOCK nie 
auf 1.

Edit: Ich habs eben mal getestet. Du hast einen Spartan 3e, stimmts? Da 
scheint die Simulations-Lib einen Bug zu haben, da gehts tatsächlich 
nicht (wohl aber in Hardware). Ich hatte das bisher am Virtex 4 benutzt, 
und da klappts auch in der Simulation bestens. Ich weiß nicht, ob die 
aktuellen Libs von Modelsim XE 6.4b zur ISE 11.3 das beheben, kann sein. 
Ich arbeite noch mit 6.3c

[Andreas B. (loopy83)]

Ich habe einen Spartan 3A DSP XC3SD1800A-4FGG676C... bzw. das Starterkit 
dazu.

Ich teste den einfachen DCM einfach mal in der Hardware und versuche es 
zu messen... ich hoffe, dass ich hier in einem anderen Labor ein 
passendes Oszi auftreiben kann.

[Andreas B. (loopy83)]

Also ich kann es leider nicht genau messen.
Das Oszi was ich gefunden habe kann zwar angeblich 500MHz bei 5GT/s, 
aber naja... wenn ich die Messspitzen anders anfasse, sehen die Kurven 
anders aus. MIt 160MHz ist eben nicht zu scherzen, wenn man dann noch 
1-3ns auflösen will.

Könnte eine ChipScope Lizenz die ganze Sache bereinigen bzw. Licht ins 
Dunkel bringen, was der DCM in der Hardware macht?
Die kostenlose Version von CS wird bei mir leider nicht fehlerfrei 
installiert und somit habe ich auch nicht die Auswahl, unter New Source 
einen CS Core zu implementieren.

[Christian R. (supachris)]

ChipScope kann nur taktsynchron sampeln. Das bringt dir nix weiter. 
Klappt denn der Receiver in der Hardware auch nicht? Eventuell kommst du 
mit Constraints weiter, also mit "OFFSET IN BEFORE" dem ISE sagen, dass 
die Daten da x ns vor dem Takt anliegen müssen.

[Andreas B. (loopy83)]

Ok, also ist ChipScope der falsche Weg.

Der Reciever in der Hardware funktioniert. Also der DCM spuckt am 
Ausgang einen Takt aus, nur leider kann ich nicht exakt nachmessen, ob 
nun wirklich das parametrierte Delay eingehalten wird, da mir die 
Lokalisierung der steigenden und fallenden Flanken schwer fällt. Die 
Signale sind schon sehr verwaschen und alles andere als ein sauberes 
Rechteck (ist ja auch nicht zu erwarten). Ich habe die LVDS Signale eher 
stiefmütterlich an das Starterkit geführt, ohne Terminierung und alles. 
Auf meiner eigenen Hardware habe ich es ordentlich gemacht. Impedanzen 
von 100Ohm eingehalten und auch dementsprechend terminiert. Aber die ist 
eben noch nicht fertig, so muss ich vorerst auf das Starterkit 
zurückgreifen.

>Eventuell kommst du
>mit Constraints weiter, also mit "OFFSET IN BEFORE" dem ISE sagen, dass
>die Daten da x ns vor dem Takt anliegen müssen.

Das bedeutet, dass ich den Datenkanälen ein constraint zuweise, dass 
diese Daten meinetwegen 1ns vor der Taktflanke anliegen müssen? Also 
wird dann bei der Implementierung dem Clock automatisch ein Delay 
verpasst?
Die Variante schaue ich mir mal an.
Nur könnte ich da dann nicht Probleme mit meinem IDDR2 bekommen?
Die Daten kommen ja auf der fallenden und auf der steigenden Flanke des 
Taktes. Oder wird einfach eine komplette Phasenverschiebung des Taktes 
zu den Daten implementiert?

Constraints werden doch aber erst in der realen Hardware aktiv, bei der 
Simulation habe ich dadurch keinen Vorteil, richtig?

Vielen Dank!

[Andreas B. (loopy83)]

Ich hab gerade das appnote wp237 gefunden. Ich denke da steht alles 
drin, was es mit dem OFFSET IN BEFORE zu tun hat und es ist auch ein 
Bsp. für DDR gegeben.

Ich werde mich mal mit diesen Befehlen versuchen:

NET "CLKIN_IN_N" TNM_NET = CLKIN_IN_N;
TIMESPEC TS_CLKIN_IN_N = PERIOD "CLKIN_IN_N" 6.25 ns HIGH 50%;
NET "CLKIN_IN_P" TNM_NET = CLKIN_IN_P;
TIMESPEC TS_CLKIN_IN_P = PERIOD "CLKIN_IN_P" 6.25 ns HIGH 50%;

OFFSET = IN 1ns BEFORE CLKIN_IN_P;
OFFSET = IN -1ns BEFORE CLKIN_IN_P TIMEGRP falling_ffs_grp;

Bei differentiellen Signalen sollte es ja ausreichen, auf den positiven 
Zweig Bezug zu nehmen, oder?

MfG