Taktausgang Spartan6

[Gustl B. (-gb-)]

Hallo,
ich bekomme von aussen 50MHz ins FPGA rein und will 65MHz wieder 
ausgaben für einen externen ADC.
Also Eingänge beschrieben:

entity blah is
port (CLK: in std_logic;
      ADC_Clock_out: out std_logic);
end blah;

Dann den Clockmanager generiert:

COMPONENT clk_65mhz is
port
 (-- Clock in ports
  clk           : in     std_logic;
  -- Clock out ports
  clk65          : out    std_logic;
  clk25          : out    std_logic
 );
END COMPONENT;

Den dann verdrahtet:

clk0: clk_65mhz PORT MAP(
  clk  => CLK,
  clk65 => ADC_Clock_out,
  clk25 => CLK25);

Und auch im .UCF (ISE) die Signale mit Pads verbunden:

NET "CLK" LOC = "P14"; #50MHz
NET "ADC_Clock_out" LOC = "P17";

Das FPGA ist ein XC6SLX9-2TQG144C, der Pin P17 ist laut Datenblatt des 
Modulherstellers (Bitrecords) ein "IO_L43P_GCLK23_3". Also ein Taktpin.

Lasse ich aber alles durchlaufen mit routen und so, dann bekomme ich 
einen Fehler:

ERROR:Place:1205 - This design contains a global buffer instance,
   <clk0/clkout1_buf>, driving the net, <ADC_Clock_out_OBUF>, that is driving
   the following (first 30) non-clock load pins off chip.
   < PIN: ADC_Clock_out.O; >
   This design practice, in Spartan-6, can lead to an unroutable situation due
   to limitations in the global routing. If the design does route there may be
   excessive delay or skew on this net. It is recommended to use a Clock
   Forwarding technique to create a reliable and repeatable low skew solution:
   instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
   Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
   .C1. If you wish to override this recommendation, you may use the
   CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
   this message to a WARNING and allow your design to continue. Although the net
   may still not route, you will be able to analyze the failure in FPGA_Editor.
   < PIN "clk0/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >

Wie umgehe ich das? Also wie schaffe ich es, dass der Takt direkt über 
ein Taktnetz auf das Pad geroutet wird? Ich hab schon viel dazu gesucht 
aber da finde ich nur Zeug zu Takteingängen ...

Danke!

[Achim S. (Gast)]

die übliche Lösung steht in der Fehlermeldung mit dabei:

Gustl B. schrieb:
> instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1
> pin to
>    Logic0; tie the clock net to be forwarded to .C0; tie the inverted
> clock to
>    .C1.

Du belässt den 65MHz-Takt also auf dem Taktnetz, und du taktest damit 
ein DDR-Ausgangsregister, das mit der steigenden Takflanke eine 1 und 
mit der fallenden Flanke eine 0 nach außen treibt.

[Lattice User (Gast)]

Gustl B. schrieb:

>
> Wie umgehe ich das? Also wie schaffe ich es, dass der Takt direkt über
> ein Taktnetz auf das Pad geroutet wird? Ich hab schon viel dazu gesucht
> aber da finde ich nur Zeug zu Takteingängen ...
>


Den Ausgang als ODDR konfigurieren. Auszugebende Daten "01" oder "10" je 
nach gewünschter Phase.

[J. S. (engineer)]

Das ist noch nicht die Lösung denke ich, denn Du treibst da nicht so, 
wie es physikalisch vorgesehen ist. Die saubere Mimik ist die Folgende:


Clock Capable Input Pin -> IBUF -> ClockInSig


1) ClockInSig -> BUFG -> Design, z.B. Reset-Schaltung

2a) ClockInSig -> ohne BUFG an PLL-INPUT 50MHz

oder

2b) ClockInSig an ODDR_p (mittels Inverter an ODDR_n)


Statt Version 2 auch so:

ClockInSig -> PLL-INPUT,   PLL´

Pll-Ouput -> BUFG  -> ClockSigBuffered

Pll-Ouput180 -> BUFG  -> ClockSigBufferedInv

ClockSigBuffered -> Design

ClockSigBuffered -> ODDR_P

ClockSigBufferedInv -> ODDR_N



Konkret bei Dir muss als Ausgang ein "normaler" Pin genommen werden. 
Dazu ein ODDR. "CC" nur für Eingänge

Und, man muss aufpassen ob man den CoreGen richtig gesetzt hat, ob er 
also Buffer hinzufügen soll oder nicht und ob man das bei der Synthes 
richtig eingeschaltet hat. Gfs kriegt man nämlich einen Buffer zu wenig 
oder einen zuviel.

[Gustl B. (-gb-)]

Ok, Danke! In meiner Vorstellung dachte ich man könnte das Taktnetz da 
direkt an einen Ausgang geben und muss dafür auch einen speziellen IO 
Pin verwenden. Aber gut, werde das mal anders probieren.

Edit:
Hab das jetzt so gemach:

clk0: clk_65mhz PORT MAP(
  clk  => CLK,
  clk65 => ADC_Clock_intern,
  clk25 => CLK25);
  
oddr2_inst : ODDR2
generic map (
DDR_ALIGNMENT  => "C0",
INIT           => '0',
SRTYPE         => "ASYNC")
port map
(D0             => '1',
D1             => '0',
C0             => ADC_Clock_intern,
C1             => not ADC_Clock_intern,
CE             => '1',
Q              => ADC_Clock_out,
R              => '0',
S              => '0');

Funktioniert, sieht am Oszi leicht anders aus wie vorher wo ich das oder 
das ODDR2 gemacht habe. Den Pin musste ich nicht wechseln.

[J. S. (engineer)]

Gustl B. schrieb:
> In meiner Vorstellung dachte ich man könnte das Taktnetz da
> direkt an einen Ausgang geben

Dies würde eine Verbindungsoption erfordern, die es in FPGAs nicht 
(mehr) gibt. Bei PLDs gibt (und bei den ersten FPGAs gab) es da keinen 
Unterschied. Man konnte munter gaten Takte verunden und verordern und 
quer durchs Design hin und her routen und auch ausgeben.

Bei hohen Taktfrequenzen erfordern synchrone Designs aber echte 
dedizierte FF-Architekturen mit gut balancierten Taktnetzbäumen. Da kann 
man nicht einfach irgendwie viel dranhängen und herumgaten. Mithin sind 
Taktnetze in einigen FPGAs / ASICs auch differenziell ausgelegt.

Ausgangspins lassen sich somit nur über Kombinatorik mit/ohne FF 
betreiben und die einzige Möglichkeit, ihn mit voller Taktfrequenz zu 
tooglen ist, ihn als DDR zu nutzen. Daher macht man das so. Wenn Du den 
Takt, mit dem Du das DDR-FF antreibst, aus einer PLL gewinnst, kannst Du 
die Phase beliegt zu den Daten verschieben, wie es der DAC braucht.

[Gustl B. (-gb-)]

Wieder was gelernt, vielen Dank!

[J. S. (engineer)]

Jürgen Schuhmacher schrieb:
> beliegt
Gemeint war natürlich "beliebig" verschieben.