mikrocontroller.net

Forum: FPGA, VHDL & Co. Fragen zum IDDR2


Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe ein LVDS Daten Signal, welches ich über einen IBUFDS in den 
FPGA bringe (Spartan 3A DSP) und einen LVDS Takt, den ich über ein 
IBUFGDS verarbeite.

Nun habe ich also einen normalen Takt und einen normalen seriellen 
Datenstrom. Die Daten welchseln mit jeder steigenden und fallenden 
Flanke (DDR). Nun habe ich mir im UG331 das Kapitel zum IDDR2 angeschaut 
und werde nicht so richtig schlau daraus.

Dort ist die Rede von zwei Takten, C0 und C1. Diese scheinen nach der 
Abbildung entgegengesetzt zu verlaufen. Muss ich mir diese beiden Takte 
erst aus dem Eingangstakt der Daten generieren? Oder wie genau kann ich 
mit Hilfe des einzelnen Taktes meine Daten entsprechend verarbeiten?

Ich erhalte ja dann zwei getrennte Datenströme an Q0 und Q1. Einer 
entspricht der steigenden Flanke, der andere der Fallenden. Kann ich 
diese Daten dann nacheinander (also immer abwechseln Q1 - Q0 - Q1 ...) 
und in der passenden Reihenfolge in ein Register speichern? Oder wäre es 
besser Q1 und Q0 getrennt zu speichern und dann in einem zweiten Schritt 
zu sortieren?

Gibt es irgendwo ein brauchbares und gutes HowTo, wie man Register 
anlegt und diese dann beschreibt? Vielleicht in Verbindung mit 
Chipscope, wo ich dann kontrollieren kann, ob meine LVDS Daten auch so 
gespeichert wurden, wie sie auch verschickt worden sind?

Vielen Dank!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also. Üblicherweise werden die Takte C0 und C1 über den DCM aus dem 
Eingangstakt gewonnen. Das steht ja auch so im User Guide (S. 327). Dann 
nimmst du den 0° und den 180° Takt. Bei Bedarf kannst du das dann noch 
über den Pahse-Shift zurecht schieben. Wenn dein Eingangstakt aber mit 
den Daten mitgeliefert wird, brauchst du das in der Regel nicht.

Die Daten kommen dann parallel aus dem IDDR2 FlipFlop, und zwar 
ausgerichtet an den beiden Takten C0 und C1. Willst du die auf die 
steigende Flanke ausgerichtet haben, musst du noch ein 2. FlipFlop 
hinter den Q1 Ausgang schalten. Das klappt, steht auch so im user Guide 
(S. 329), das sitzt dann direkt mit auf dem IO-Block und garantiert in 
den allermeisten Fällen, dass die setup-Zeit trotzdem eingehalten wird. 
Beim 3A kannst du glaube ich das Alignment Feature des IDDR2 
benutzen....

Tj,a und wie du die Daten dannverarbeitetst, musst du dir selbst 
ausdenken. Wenn du die eh hintereinander haben willst, brauchst du kein 
IDDR2 sondern kannst die mit dem doppelten Takt (über DCM generiert) 
direkt mit einem IFF einsammeln. Willst du die parallel verarbeiten, 
nimmst du das IDDR2 Register.

ChipScope kannst du natürlich dann benutzen, aber solche grundlegenden 
Sachen simuliert man vorher.

Autor: Andreas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bekomme den IDDR2 im Chip einfach nicht zum laufen.

In der Simulation funktioniert alles tadellos... aber wenn es es an der 
realen LVDS Quelle teste, kommen an den beiden Datenausgängen Q0 und Q1 
keine Daten heraus.

Ich habe mir den Data-In von dem IDDR2 auf einen Pin gelegt und die 
Daten kommen auch an, nur leider verschwindet dieses Signal im IDDR2. So 
viel kann man da doch gar nicht falsch machen, oder?

CE ist auf 1 fixiert, set ist auf 0 fixiert...

Könnte jemand mal mein Design anschauen und versuchen den Fehler zu 
finden?
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 LVDS_CLOCK_IN is
   Port (  AFE_CLK_P : in  STD_LOGIC;      --LVDS Clk pos.
          AFE_CLK_N : in  STD_LOGIC;       --LVDS Clk neg.
        AFE_DAT_P : in  STD_LOGIC;         --LVDS Daten pos.
        AFE_DAT_N : in  STD_LOGIC;         --LVDS Daten neg.
        DCM_RESET : in STD_LOGIC;          --DCM Reset (Taster)
        DATA_IN : out STD_LOGIC;           --IDDR2 Daten Eingang (Messpunkt)
        DDR_RESET : in STD_LOGIC;          --IDDR2 Reset (Taster)
--        SET_DDR : in STD_LOGIC;          --IDDR2 Set (Taster)
        CLOCK_OUT0 : out STD_LOGIC;        --DCM Clock Out (Messpunkt)
--        CLOCK_OUT180 : out STD_LOGIC;    --DCM Clock Out (Messpunkt)
        DATA_OUTQ0 : out STD_LOGIC;        --IDDR2 DATA Out (Messpunkt)
        DATA_OUTQ1 : out STD_LOGIC         --IDDR2 DATA Out (Messpunkt)
      );
end LVDS_CLOCK_IN;

architecture Behavioral of LVDS_CLOCK_IN is

signal CLOCK_INT : STD_LOGIC;             --LVDS Takt nach In-Buffer
signal CLOCK_OUT0_int : STD_LOGIC;        --LVDS Takt nach DCM
signal CLOCK_OUT180_int : STD_LOGIC;      --LVDS Takt nach DCM
--signal DCM_LOCK_int : STD_LOGIC;        --Takt-good DCM
signal DATA_OUTQ0_int : STD_LOGIC;        --Data out IDDR2
signal DATA_OUTQ1_int : STD_LOGIC;        --Data out IDDR2
signal CLKFB_in : STD_LOGIC;              --Feedback DMC
signal DATA_INT : STD_LOGIC;              --LVDS Daten nach in-Buffer

constant IDDR2_CE : STD_LOGIC := '1';
constant SET_DDR : STD_LOGIC := '0';

begin

A : IBUFGDS                              --Takteingabe
      port map (O => CLOCK_INT,
                I => AFE_CLK_P,
                IB => AFE_CLK_N);
              
B : IBUFDS                              --Dateneingabe
      port map (O => DATA_INT,
                I => AFE_DAT_P,
                IB => AFE_DAT_N);

C : BUFG                              --Takt 0° Ausgabe
      port map (I=>CLOCK_OUT0_int,
                O=>CLOCK_OUT0);

D : BUFG                              --Feedback DCM
      port map (I=>CLOCK_OUT0_int,
                O=>CLKFB_in);

--D1 : BUFG                              --Takt 180° Ausgabe
--      port map (I=>CLOCK_OUT180_int,
--                O=>CLOCK_OUT180);

D2 : BUF                              --Daten IDDR2-Q0 Ausgabe
      port map (I=>DATA_OUTQ0_int,
                O=>DATA_OUTQ0);

D3 : BUF                              --Daten IDDR2-Q1 Ausgabe
      port map (I=>DATA_OUTQ1_int,
                O=>DATA_OUTQ1);
           
D4 : BUF                              --Daten Eingang IDDR2 Ausgabe
      port map (I=>DATA_INT,
                O=>DATA_IN);

E : DCM_SP                              --DCM
   generic map (
      CLKDV_DIVIDE => 2.0, --  Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
                           --     7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
      CLKFX_DIVIDE => 2,   --  Can be any interger from 1 to 32
      CLKFX_MULTIPLY => 2, --  Can be any integer from 1 to 32
      CLKIN_DIVIDE_BY_2 => FALSE, --  TRUE/FALSE to enable CLKIN divide by two feature
      CLKIN_PERIOD => 6.25, --  Specify period of input clock
      CLKOUT_PHASE_SHIFT => "NONE", --  Specify phase shift of "NONE", "FIXED" or "VARIABLE" 
      CLK_FEEDBACK => "1X",         --  Specify clock feedback of "NONE", "1X" or "2X" 
      DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- "SOURCE_SYNCHRONOUS", "SYSTEM_SYNCHRONOUS" or
                                             --     an integer from 0 to 15
      DLL_FREQUENCY_MODE => "LOW",     -- "HIGH" or "LOW" frequency mode for DLL
      DUTY_CYCLE_CORRECTION => TRUE, --  Duty cycle correction, TRUE or FALSE
      PHASE_SHIFT => 0,        --  Amount of fixed phase shift from -255 to 255
      STARTUP_WAIT => FALSE) --  Delay configuration DONE until DCM_SP LOCK, TRUE/FALSE
   port map (
      CLK0 => CLOCK_OUT0_int,     -- 0 degree DCM CLK ouptput
      CLK180 => CLOCK_OUT180_int, -- 180 degree DCM CLK output
      CLK270 => open, -- 270 degree DCM CLK output
      CLK2X => open,   -- 2X DCM CLK output
      CLK2X180 => open, -- 2X, 180 degree DCM CLK out
      CLK90 => open,   -- 90 degree DCM CLK output
      CLKDV => open,   -- Divided DCM CLK out (CLKDV_DIVIDE)
      CLKFX => open,   -- DCM CLK synthesis out (M/D)
      CLKFX180 => open, -- 180 degree CLK synthesis out
      LOCKED => open, -- DCM LOCK status output
      PSDONE => open, -- Dynamic phase adjust done output
      STATUS => open, -- 8-bit DCM status bits output
      CLKFB => CLKFB_in,   -- DCM clock feedback
      CLKIN => CLOCK_INT,   -- Clock input (from IBUFG, BUFG or DCM)
      PSCLK => open,   -- Dynamic phase adjust clock input
      PSEN => open,     -- Dynamic phase adjust enable input
      PSINCDEC => open, -- Dynamic phase adjust increment/decrement
      RST => DCM_RESET        -- DCM asynchronous reset input
   );
  

  
F : IDDR2                              --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_OUTQ0_int, -- 1-bit output captured with C0 clock
   Q1 => DATA_OUTQ1_int, -- 1-bit output captured with C1 clock
   C0 => CLOCK_OUT0_int, -- 1-bit clock input
   C1 => CLOCK_OUT180_int, -- 1-bit clock input
   CE => IDDR2_CE, -- 1-bit clock enable input
   D => DATA_INT,   -- 1-bit DDR data input
   R => DDR_RESET,   -- 1-bit reset input
   S => SET_DDR    -- 1-bit set input
);

         
end Behavioral;

Was könnte noch eine Fehlerursache sein, dass es in der Simulation geht 
und in der Realität nicht?

VIELEN DANK!!!

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was macht denn "DCM_RESET" ? Hast du vielleicht in Hardware einen
dauerhaften Reset ?


SuperWilly

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie steht denn IDDR_Reset? Ist das auf 0? Und was sagt denn die 
Timing-Simulation? Und mal genau alle Warnungen beim Routen angeschaut? 
Speziell schauen, ob 653 dabei sind: Signal benutzt aber nicht 
zugewiesen -> wird auf Null gezogen. Übersieht man leicht, und dann 
läufts nicht.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und "DDR_RESET" ...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...bestimmt Low-Aktiv....ist ja bei externen Resets üblich.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der DCM Reset funktioniert. Da ich erst das Board und dann die LVDS 
Quelle einschalte, muss ich den DCM erst reseten bevor er seine Arbeit 
aufnimmt. Er spuckt ja auch einen plausiblen Takt aus.

Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke 
oder in Ruhe lasse...

Bei der ganzen Synthese, Implementierung usw habe ich keinerlei 
Warnungen oder Fehler. Alles läuft sauber durch.
Timing Simulation müßte ich nochmal machen... hab ich noch nie 
gebraucht, mal schauen wie und was ich da machen kann.

Ich habe alle unused Pins auf float gestellt, dass ich keine Gefahr 
laufe mir beim rumprobieren was zu zerschießen.

DANKE für die Hilfe, aber ich werde wohl weiter suchen und probieren 
müssen!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:

> Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke
> oder in Ruhe lasse...

Hat der denn einen Pull-Up bzw. Pull-Down Widerstand? Wie ist der Taster 
angeschlossen? Nach Masse oder nach VCC? Generell ist ein Taster am FPGA 
immer etwas mit Vorsicht zu genießen, speziell, wenn man auf synchronen 
Reset aus ist. Nagel mal das DDR_Reset auf 0 fest, das braucht man 
eigentlich sowieso nicht.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das habe ich gerade getan, also den Taster weggenommen und ihn 
fest auf 0 gelegt. Leider ohne Erfolg...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und es gibt überhaupt keine Warnungen beim Implement? Nicht mal, das 
"Instanciating Black Box Module...."? Das ist ja seltsam. Mach mal 
Timing-Simulation.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Timing Analyse fällt mir auf, dass ich noch gar keine Timing 
Contrains festgelegt habe, weil ich nie wußte, was da rein muss.

Die Analyse mach ich dann doch unter
Implement Design => Place & Route => Generate Post-Place & Rote Static 
Timing => Analyze Post-Place & Rote Static Timing ?

Denn da spuckt er mir nix aus... außer meinen LVDS Takt, den ich mit 
6,25ns Periode und 50% angegeben habe:

im ucf File:
NET "AFE_CLK_N" TNM_NET = AFE_CLK_N;
TIMESPEC TS_AFE_CLK_N = PERIOD "AFE_CLK_N" 6.25 ns HIGH 50%;
NET "AFE_CLK_P" TNM_NET = AFE_CLK_P;
TIMESPEC TS_AFE_CLK_P = PERIOD "AFE_CLK_P" 6.25 ns HIGH 50%;

Was genau fehlt mir noch, dass ich da eine Aussage treffen kann, mit der 
man was anfangen kann? Mal abgesehen davon, dass ich lediglich weiß, das 
mir die Analye die Zeiten angibt bzw. angeben soll, die die Signale vom 
Eingang zum Ausgang brauchen, also quasi die Laufzeiten in den Gattern 
ist das so korrekt?

MfG

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du sollst eine Timing-Simulation machen, keine statische Timing-Analyse. 
Da musst du in der ISE links oben auf Simulation umschalten, und dann 
auf "Post Route" stellen. Eventuell musst du die TestBench noch dem 
Projekt hinzufügen, wenn noch nicht geschehen. Das mit den Contraints 
sieht erst mal richtig aus, wenn dein Takt 160MHz ist. Nach dem Routen 
müsste dann in der Zusammenfassung stehen, ob er das Timing geschafft 
hat "All contraints met" wäre das dann.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hangel mich von Frage zu Frage, von Problem zu Problem und von 
Fehler zu Fehler. Sehr ernüchternd, wenn man nicht weiß, was man wie 
machen soll und welches Ergebnis man erwarten kann. Jetzt habe ich 
wieder im Netz gesucht und wieder nichts gefunden... wie lange will mir 
diese FPGA Welt noch so verschlossen bleiben?

Der Unterschied zwischen statischer Timing-Analyse und Timing-Simulation 
ist und war mir nicht bekannt, Verzeihung.

Ich habe nun oben links im ISE bei Sources for: auf Post-Route 
Simulation gestellt, bin dann ein Fenster weiter unten auf ModelSim 
Simulator gegangen und dann auf Simulate.

Nun bekomme ich fünf neue Warnungen, seit dem ich die Timing COntrains 
eingefügt habe.
WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT0_int = PERIOD
   "CLOCK_OUT0_int" TS_AFE_CLK_N HIGH 50%> is overridden by the constraint
   <TIMESPEC TS_CLOCK_OUT0_int = PERIOD "CLOCK_OUT0_int" TS_AFE_CLK_P HIGH 50%>.
WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT0_int = PERIOD
   "CLOCK_OUT0_int" TS_AFE_CLK_N HIGH 50%> is overridden by the constraint
   <TIMESPEC TS_CLOCK_OUT0_int = PERIOD "CLOCK_OUT0_int" TS_AFE_CLK_P HIGH 50%>.
WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD
   "CLOCK_OUT180_int" TS_AFE_CLK_N PHASE 3.125 ns HIGH 50%> is overridden by the
   constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD "CLOCK_OUT180_int"
   TS_AFE_CLK_P PHASE 3.125 ns HIGH 50%>.
WARNING:NgdBuild:1011 - The constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD
   "CLOCK_OUT180_int" TS_AFE_CLK_N PHASE 3.125 ns HIGH 50%> is overridden by the
   constraint <TIMESPEC TS_CLOCK_OUT180_int = PERIOD "CLOCK_OUT180_int"
   TS_AFE_CLK_P PHASE 3.125 ns HIGH 50%>.

WARNING:NetListWriters:674 - Mismatched property type detected - type S expected for property DESKEW_ADJUST:, but type integer detected, ignored.

Aber einen Satz wie "All contraints met" kann ich weder im ISE noch im 
Modelsim finden. Dann wirds wohl noch nicht so weit sein... dass alles 
passt.

Ich frage mich nur langsam, wie man solche Probleme alleine lösen 
kann/soll? Ich fühle mich langsam schlecht, dass ich immer wieder 
nachfragen muss... wiel mir diverse Internetliks und seitenlange 
Tutorials und Manuals nicht weiterhelfen.

Brauch ich für diese Art der Timing Analyse vielleicht wieder ein ISE 
Simulator Projekt? Das werde ich dann später gleich nochmal 
ausprobieren...

VIELEN VIELEN DANK!!!

Autor: Christian R. (supachris)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also zunächst mal lernt man sowas komplexes wie FPGA Design und 
Verifikation im Studium. Zumindest hab ich das da gelernt. Die Erfahrung 
kommt dann erst mit den Jahren im Job.

Naja, fangen wir vorn an. Ich hab mal ein Mini.Projekt mit deinem Code 
gemacht. S3 A DSP 1800.

Bild 1: Nach dem Implement Design. "All Constraints Met" steht auf der 
rechten Seite oben.

Bild 2: So muss das zur Timing-Simulation aussehen.

Die Warnungen sind OK, das kommt daher, dass er die Constraints, die du 
vorgegeben hast, quasi in den DCM rein zieht. Das passt schon so.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VIELEN VIELEN DANK!!!

Hat denn diese Meldung auch ihre Ursache im DCM?
>WARNING:NetListWriters:674 - Mismatched property type detected - type S >expected 
for property DESKEW_ADJUST:, but type integer detected, ignored.

Also dieses "All Constraints Met" steht nach dem Implement da. Sowohl 
oben rechts als auch unten links im Design Summary.

Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf 
deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied 
zur Behavioral Simulation feststellen.

Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere 
Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz 
festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns 
gesetzt habe. Wird denn dann automatisch überprüft, ob diese 
Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit 
eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus 
der Timing Analye herauslesen, was mir bisher noch nicht möglich ist.

DANKE!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> VIELEN VIELEN DANK!!!
>
> Hat denn diese Meldung auch ihre Ursache im DCM?
>>WARNING:NetListWriters:674 - Mismatched property type detected - type S 
>expected
> for property DESKEW_ADJUST:, but type integer detected, ignored.

Naja, da hast du irgendwie einen falschen Parameter angegeben. Mach doch 
den DCM am besten als IP core über den Core-Generator. Da kannst du auch 
gleich auf differenziellen Eingang stellen und sparst die ganze 
Buffer-Instaziierungs-Geschichte.

> Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf
> deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied
> zur Behavioral Simulation feststellen.

Dann ist an deiner Hardware was falsch. Die Timing-Simulation bildet 
sehr genau die Wirklichkeit ab. Da muss irgendwas grundlegendes sein...

> Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere
> Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz
> festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns
> gesetzt habe. Wird denn dann automatisch überprüft, ob diese
> Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit
> eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus
> der Timing Analye herauslesen, was mir bisher noch nicht möglich ist.

Nö, musst du nicht, der Takt wird ja eh von außen engelegt und bestimmt, 
was im FPGA passiert. Deine Angabe mit den 6,25ns besagt lediglich, dass 
du von außen einen 160MHz Takt anlegen willst, und dass der Router das 
möglichst so optimieren muss, dass er das schafft.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht 
weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und 
werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten 
ablege und parallel an irgendwelchen Pins zur Verfügung stelle.

Werde mir dazu mal CHipsScope anschauen, dass ich das Programm dann nach 
der Simulation auch im CHip noch nachvollziehen kann.

Vielen Dank für die ausdauernde Hilfe :)

Ich habe aber die Vermutung, dass es nicht mein letzter Thread gewesen 
sein wird.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht
> weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und
> werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten
> ablege und parallel an irgendwelchen Pins zur Verfügung stelle.

Tu dir was gutes und benutze dazu den Core-Generator. Mit deinem 
Kenntnisstand ist das das sinnvollste. Generische FIFO-Beschreibungen in 
VHDL würde ich einem Anfänger nicht anraten.

Hast du mal den DCM als IP-Core versucht einzubinden?

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja habe ich gemacht.
DCM als IP Core eingebunden, auf differentiell gestellt... hat alles 
geklappt. Nur leider wieder das gleiche Bild. Simulation funktioniert, 
in der Hardware dann nicht mehr. Sehr komisch.

Ich habe jetzt auch den FIFO als IP Core implementiert, nur scheint das 
etwas anders zu sein, als mit dem DCM. Zumindest kann ich den scheinbar 
nicht so einfach aufrufen in meinem Top-file.

Ich werde mich dann mal weiter einlesen... irgendwie muss es mal wieder 
voran gehen und ich brauche mal wieder ein Erfolgserlebnis. Sonst gebe 
ich noch auf :)

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Gedanken zum Wochenende:

Es könnte einen Versuch Wert sein, mit Chipscope dir relevante Signale
anzuschauen ... Vielleicht kannst du so herausfinden, ob es an einer
Stelle im Signal/Datenpfad zum Bruch kommt oder ob von vornherein nichts
Sinnvolles ins FPGA reinkommt.


SuperWilly

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.