DDR Daten ausgeben mit Takt

[Gustl B. (-gb-)]

Hallo,
ich habe einen DAC, der bekommt extern einen Takt. Dann gibt der einen 
leicht verschobenen Takt, der heißt DCO, zum FPGA. Und mit diesem Takt 
muss ich Daten zum DAC liefern. Und zwar DDR mit einem IQSelect.

Das habe ich mir als IP generieren lassen und funktioniert wunderbar, 
aber ... nur mit einem Takt von 125 MHz, also 250 MHz DDR. Und zwar weil 
die Setup Zeit nicht eingehalten wird. Aber gut, beim IP kann man ja 
noch ein IDELAY dazukonfigurieren, mit einem TAP Wert von 8 passt das in 
der Simulation. Sehr fein, sieht dann so aus:

component DAC_DDR
generic
 (-- width of the data for the system
  SYS_W       : integer := 16;
  -- width of the data for the device
  DEV_W       : integer := 32);
port
 (
  -- From the device out to the system
  data_out_from_device    : in    std_logic_vector(DEV_W-1 downto 0);
  data_out_to_pins        : out   std_logic_vector(SYS_W-1 downto 0);
  clk_to_pins             : out std_logic;

  delay_locked            : out   std_logic;                    -- Locked signal from IDELAYCTRL
  ref_clock               : in    std_logic;                    -- Reference Clock for IDELAYCTRL. Has to come from BUFG.
 
-- Clock and reset signals
  clk_in                  : in    std_logic;                    -- Single ended Fast clock from IOB
  clk_out                 : out   std_logic;
  clk_reset               : in    std_logic;                    -- Reset signal for Clock circuit
  io_reset                : in    std_logic);                   -- Reset signal for IO circuit
end component;

Ich habe das so verwendet:

Data_Out: DAC_DDR port map( 
  data_out_from_device => DAC1_D & DAC2_D,
  data_out_to_pins => D,
  clk_to_pins => IQSEL,
  delay_locked => open,
  ref_clock => CLK200,
  clk_in => DCO,                            
  clk_out => DCO_intern,
  clk_reset => IO_RST,
  io_reset => IO_RST);

Mit DCO_intern soll die Datenerzeugung für den DAC getaktet werden.
DCO ist der einzige Takt von extern.

Tja, aber da bekomme ich Warnungen:
[DRC PDRC-152] Routing conflict: Invalid IDELAYE2 usage: Cell 
AD9747_DAC/Data_Out/inst/idelaye2_clk IDATAIN pin is on net 
AD9747_DCO_IBUF with fanout >1 which causes a routing resource conflict. 
Either the associated ILOGIC IFF cell must register the ILOGIC site D or 
DDLY input or the net should be restructured to avoid driving fabric 
directly from IDELAYE2.

Wie kann ich das lösen? Wie ich das sehe muss ja ref_clock 200 MHz haben 
laut 
https://www.xilinx.com/support/documentation/ip_documentation/util_idelay_ctrl/v1_0/pb044-util-idelay-ctrl.pdf 
.

Ich habe also jetzt mal DCO erst auf ein BUFG gelegt und gehe von dort 
in den IP. Das baut auch ohne Warnungen, aber ... das Delay ist weg. 
Also etwas Delay kann ich sehen, aber egal welchen TAP Wert ich in der 
IP einstelle, das Delay bleibt in der Simulation unverändert.

Data_Out: DAC_DDR port map( 
  data_out_from_device => DAC1_D & DAC2_D,
  data_out_to_pins => D,
  clk_to_pins => IQSEL,
  delay_locked => open,
  ref_clock => refclk200,
  clk_in => DCO_buffer,                            
  clk_reset => IO_RST,
  io_reset => IO_RST);
  
BUFG_inst : BUFG port map(
O => DCO_buffer,
I => DCO);

Wie macht man das richtig?

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Um welchen Xilinx FPGA geht es? Da gibt es erhebliche Unterschiede, 
abhaengig von der Familie. Und am besten gleich noch die Pin Paare von 
Data und Clock gleich mitliefern.

[Gustl B. (-gb-)]

Das FPGA ist ein Spartan 7 XC7S50.

Die betreffenden Pins sind:

## AD9747
set_property PACKAGE_PIN D14 [get_ports {AD9747_D[0]}]
set_property PACKAGE_PIN D13 [get_ports {AD9747_D[1]}]
set_property PACKAGE_PIN C14 [get_ports {AD9747_D[2]}]
set_property PACKAGE_PIN B14 [get_ports {AD9747_D[3]}]
set_property PACKAGE_PIN B13 [get_ports {AD9747_D[4]}]
set_property PACKAGE_PIN A13 [get_ports {AD9747_D[5]}]
set_property PACKAGE_PIN F12 [get_ports {AD9747_D[6]}]
set_property PACKAGE_PIN E13 [get_ports {AD9747_D[7]}]
set_property PACKAGE_PIN E12 [get_ports {AD9747_D[8]}]
set_property PACKAGE_PIN F11 [get_ports {AD9747_D[9]}]
set_property PACKAGE_PIN A12 [get_ports {AD9747_D[10]}]
set_property PACKAGE_PIN C12 [get_ports {AD9747_D[11]}]
set_property PACKAGE_PIN D12 [get_ports {AD9747_D[12]}]
set_property PACKAGE_PIN E11 [get_ports {AD9747_D[13]}]
set_property PACKAGE_PIN A10 [get_ports {AD9747_D[14]}]
set_property PACKAGE_PIN G11 [get_ports {AD9747_D[15]}]
  set_property IOSTANDARD LVCMOS33 [get_ports AD9747_D]
set_property PACKAGE_PIN F13 [get_ports AD9747_IQSEL]
  set_property IOSTANDARD LVCMOS33 [get_ports AD9747_IQSEL]
set_property PACKAGE_PIN H13 [get_ports AD9747_DCO]
  set_property IOSTANDARD LVCMOS33 [get_ports AD9747_DCO]

Wobei DCO auf einen SRCC Pin geht.

Ich habe jetzt mal ein kleines Miniprojekt mit Testbench gemacht. Das 
ist genau so wie ich das will und das funktioniert auch in der 
Simulation, aber lässt sich nicht routen.

Edit und sorry. Ich hatte vorhin schonmal diesen Post angefangen zu 
editieren, oben das zweite .zip hochgelasen, aber mir ist da ein Fehler 
aufgefallen also habe ich das Browserfenster einfach geschlossen. Ich 
habe also NICHT auf "Beitrag veröffentlichen" geklickt - aber der Anhang 
ist trotzdem da. Nun, für mich ist das ein Bug. Egal, ich habe jetzt das 
Miniprojekt weiter gebaut, jetzt mit Constraints und auch dem MMCM, und 
siehe da, das baut ohne Fehler UND sieht in der Simulation gut aus. (Bis 
auf den Konflikt mit dem IO Reset, was könnte das denn sein?)
Ich lade das jetzt hier auch noch hoch als _ganzneu und versuche das in 
meinem Großprojekt nachzubauen.

[User (Gast)]

Eine Möglichkeit ist mit einer DDR-Zelle den Takt auch auszugeben, dabei 
einfach 1 und 0 an die Zelle anschließen.

[Gustl B. (-gb-)]

Naja der IP kann ja Clock Forwarding, das würde ich auch gerne nutzen.

Was habe ich als Bedingungen:

An den DAC kommt extern ein Takt (DACCLK) von 250 MHz. Der geht 
verzögert als DCO zum FPGA an einen SRCC Pin.
Vom FPGA gehen 16 Datenleitungen zum DAC und es geht das IQSEL zum DAC.

Was funktioniert?
Das IP bekommt DCO rein, gibt mir den DCO intern für Logik ins FPGA, das 
IP gibt die Daten synchron mit einer geforwardeten Clock (IQSEL) aus.
Das geht wunderbar, aber ... diese ausgegebenen Daten und IQSEL müssen 
zu dem externen Takt DACCLK der in den DAC geht bestimmte setup und hold 
Zeiten erfüllen.

Was geht nicht?
Ich würde gerne ebenfalls mit dieser IP, das kann man dort ja 
einstellen, den DCO reinbekommen, mit einem IDELAY verzögern, dann 
verzögert Daten und IQSEL ausgeben. Mit einem Tap von 7 oder 8 passen 
die Timings. Aber das geht eben nicht wegen Routing.

Was mir unklar ist:
Ist da dieser IP Block schuld und ich sollte die Hardwareblöcke 
händisch, also nicht über den Wizard verbinden?
Der Grund für den Fehler ist mir auch unklar.

Ich habe auch schon versucht DCO zuerst auf einen BUFG zu legen und dann 
intern an den IP zu geben - bringt auch Routingfehler.

Aber ich habe eine Lösung, ist aber nicht schön.
Den externen Takt der zum DAC geht, DACCLK, den kann ich mir auch ins 
FPGA liefern lassen. Der kommt aus einem externen ClockIC mit 4 
Ausgängen, an einem hängt der ADC, an einem der DAC und an einem der 
FPGA. Ich kann also die Einstellungen im ClockIC für DAC und FPGA genau 
gleich einstellen und bekomme diesen Takt auch ins FPGA. Dort kann ich 
den mit einer PLL/MMCM verschieben und dann intern in die DDR-IP geben.
Daran stört mich aber, dass ich das nicht schön finde. Der DAC hat ja 
gerade den DCO damit man den verwendet. Ich würde also gerne genau das 
tun.

[Gustl B. (-gb-)]

Ich bastel gerade Folgendes:
DCO kommt rein, geht in einen MMCM, wird verschoben, geht in ein 
SelectIO IP und damit werden den DDR Daten ausgegeben. Dabei habe ich 
einen Bug? gefunden:

Ich habe im SelectIO eingestellt, dass der Takt von intern kommt, klar 
aus dem MMCM, und dass Clock Forwarding aktiv ist. Aber ich sehe am 
Ausgang
clk_to_pins => IQSEL,
nichts toggeln. Ist das bekannt?
Tja ... also werde ich die Clock über ein DDR FF ausgeben.

Und dann habe ich noch eine Frage:
Der DAC kann laut Datenblatt am Takteingang maximal 250 MHz. Aber zum 
Testen verwende ich niedrigere Takte die ich schön vom PC aus 
konfigurieren kann. Wenn ich dann im FPGA den Takt mit einem MMCM z. B. 
um 45° verschiebe, funktioniert das für alle Takte (50 MHz bis 250 MHz) 
oder funktioniert das nur für den Takt den ich der IP mitgeteilt habe 
und ich müsste die IP neu bauen wenn ich den Takt verändert habe?

Sorry für die Anhänge, ich teste gerade einen Forumsbug, der nur nicht 
in allen Unterforen funktioniert.

[Weltbester FPGA-Pongo (Gast)]

Gustl B. schrieb:
> Ich habe also jetzt mal DCO erst auf ein BUFG gelegt und gehe von dort
> in den IP.

Brrrrr.  Der wird doch von dem Chip geliefert und ist Folge des von dir 
vorgegebenen Takts? Du musst einzige das IO-Delay kompensieren, was die 
PLL mit feedback auf das externe Signal automatisch tut. Ich sehe keinen 
Grund das manuell einzustellen, wenn du einen solchen Takt bekommst.

[Gustl B. (gustl_b)]

Das mit dem Kompensieren habe ich nicht verstanden. Ich will clock oder 
eben IQSEL ausgeben, synchron dazu die Daten und beides soll einen Delay 
bekommen.

[Gustl B. (-gb-)]

Männo ...

1. Ich habe einen Fehler gemacht. Und zwar hatte ich DCO noch wo anders 
verwendet. Das hatte ich aber vergessen ... wenn ich das weglasse 
funktioniert das alles so wie ich möchte mit dem einen IP der das IDELAY 
drinnen hat und Clockforwarding kann. Sehr fein.

2. Ich hätte mal das Datenblatt lesen sollen. Der DAC macht maximal 250 
MSample/s, und wenn man die Daten nur über einen Port anliefert, dann 
müssen die als DDR angeliefert werden. Dann stehen da auch Setup und 
Hold Zeiten, ja die sind auch schaffbar, aber:

In dual-port mode, the data must be delivered at the sample rate (up to 
250 MSPS). In single-port mode, data must be delivered at twice the 
sample rate. Because the data inputs function only up to 250 MSPS, it is 
only practical to operate the DAC clock at up to 125 MHz in single-port 
mode.

Tja ... jetzt weiß ich auch warum ich da endlos verschiedene Delays 
durchtesten kann, denn mit vollen 250 MHz geht das bei einem Port 
schlicht nicht. Tja ... wieder was gelernt.

[Gustl B. (-gb-)]

So, letztes Update:
Es funktioniert. Mehr wie 10 MHz brauche ich sowieso nicht (der ADC auf 
der Platine kann nur 25 MSample/s) und die sehen recht brauchbar für 
Selbstbau aus.

So, jetzt muss ich mir irgendein schönes Interface mit Registern 
ausdenken mit dem ich dann einfach Frequenz, Amplitude, Offset, 
Signaltyp (Sin, Rect, Saw, Tri, Pulse, PWM), Modulation, ... einstellen 
kann (-: