Spartan 3 ISE Clock Defnition

Ich würde eine ucf-Datei ablegen und zum Projekt hinzufügen:
https://www.mikrocontroller.net/articles/UCF-Dateien

Heinz W. schrieb:
> Ich habe hier einen Spartan 3 und der User Contraint Editor sagt mir
> immer "no clocks defined".

Da hat man sich nicht wirklich mit der GUI beschäftigt, ansonsten wäre 
das Icon ganz rechts (Glühbirne?) aufgefallen unter dem sich die 
'Language templates verbergen. Siehe Anhang.


> Ich finde aber auch keinen Dialog wo ich
> meine Eingangsclock definieren kann, damit das synthesetool eine
> Referenz hat um constraints einzuhalten.

Genaugenommen kennt das Synthesetool keine timing constraints, weil die 
Synthese lediglichdie Hochsprache in eine Netzliste transformiert. 
Deshalb wird das user constraint file (ucf) erst nach der Synthese 
eingelesen (ngdbuilt). Die tools 'map' und 'Place&route' dagegen führten 
trimingrelevante Transformationen aus.

Manche Synthesetools prahlen zwar damit das sie unter 'physical 
synthesis' auch frühzeitig timings beachten würden, der zur Webpack-Ise 
gehörende xst macht das aber eher nicht. Das ucf steuert die STA  und 
der user sollte dann anhand des STA-reports (timing constraint not meet) 
sich nen Kopf machen, wo er eingreifen muss das es die Toolchain doch 
noch packt.

PS: Sorry für die doppelten Anhänge, ist ein Bug des Forums. Die 
Darstellung der Toolchain ist aus UG658

Heinz W. schrieb:
> Ich habe hier einen Spartan 3 und der User Contraint Editor sagt mir
> immer "no clocks defined". Ich finde aber auch keinen Dialog wo ich
> meine Eingangsclock definieren kann,

Neben den Textbasierten .ucf kann man sich natürlich auch vom 
CoreGenerator (tools->Coregenerator) ein komplettes clock subsystem 
generieren lassen. Der CG spuckt neben den *.vhd und so auch ein *.ucf 
aus, das man eben dem Projekt hinzufügt.

Fpgakuechle K. schrieb:
> Heinz W. schrieb:
>> Ich habe hier einen Spartan 3 und der User Contraint Editor sagt mir
>> immer "no clocks defined". Ich finde aber auch keinen Dialog wo ich
>> meine Eingangsclock definieren kann,
>
> Neben den Textbasierten .ucf kann man sich natürlich auch vom
> CoreGenerator (tools->Coregenerator) ein komplettes clock subsystem
> generieren lassen. Der CG spuckt neben den *.vhd und so auch ein *.ucf
> aus, das man eben dem Projekt hinzufügt.

Ok danke. Jetzt habe ich meine Eingangsclock auf 20MHz definiert und 
mache mit der DCM 50 MHz und gebe das einfach mal nur auf einen Pin aus. 
Da gibt er mir Warnungen, dass Component Switching limits erreicht sind. 
50MHz auf einem einzigen Pin sind schon für dieses Gurkending zu viel?

Christian R. schrieb:
> Hein W. schrieb:
>> und gebe das einfach mal nur auf einen Pin aus.
>
> Takt-Ausgabe muss man bei Xilinx mit einem ODDR
> Flipflop machen.

Genau genommen mit einem OFDDRRSE, siehe UG607 
https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/spartan3_hdl.pdf 
S. 138

IMHO geht das am am besten mit einer direkten Instanzierung mit der auf 
der Folgeseite genannten Primitive:

1

-- OFDDRRSE: Double Data Rate Input Register with Sync. Clear, Sync. Preset

2

-- and Clock Enable.

3

-- Spartan-3

4

-- Xilinx HDL Libraries Guide, version 14.7

5

OFDDRRSE_inst : OFDDRRSE port map (

6

   Q => Q,  -- Data output (connect directly to top-level port)

7

  C0 => C0, -- 0 degree clock input

8

  C1 => C1, -- 180 degree clock input

9

  CE => CE, -- Clock enable input

10

  D0 => D0, -- Posedge data input

11

  D1 => D1, -- Negedge data input

12

  R  => R,  -- Synchronous reset input

13

  S  => S   -- Synchronous preset input

14

);

die phasenverschoben Clocks holt man sich aus einer DCM, siehe Anhang 
ein paar posts oben drüber. DO und D1 klemmt man auf '0' und '1'.

Sollte das synthesetool das nicht selbst schaffen? Ich habe zum test mit 
den 50Mhz einen process erstellt und einfach mal ein eingangspin auf ein 
ausgangspin gegeben also getaktet. Dann beschwert es sich über switching 
limits am DCM clkfx, clkdv. Im wizard habe ich 50Mhz ausgangstakt 
konfiguriert und das nicht manuell gemacht.

Heinz W. schrieb:
> Sollte das synthesetool das nicht selbst schaffen?

Die Toolchain kann nicht Gedanken resp. 'Wünsche' lesen.

Wenn man mit einer direkten Pinzuweisung von den Tools einen 'Draht' zum 
Pin verlangt, dann machen die tools auch ein einfaches (Draht-) routing 
und kein (jitterarmes) Output-FF nah an den Pads. Vielleicht willste ja 
direktes routing um etwas Power zu sparen?!. Woher soll das das Tool das 
Wissen? Und timing-constraints sind für den Statischen timing analyzer 
und nicht für das synthesetool.

FPGA ist eben Hardwareentwurf, da muss man den Tools die Hardware 
benennen/Beschreiben, die man haben möchte. Und schon aus Gründen der 
Compilezeit sollte man nicht zuviel 'Optimierung' von den Tools 
verlangen. Weil Optimierung ist letztlich auch nur ausprobieren für die 
Tools.

> Dann beschwert es sich über switching limits am DCM clkfx, clkdv.

Die sollte man mal im Datenblatt nachlesen, dann kommt man vielleicht 
auf die Stelle die man falsch 'vercodet' (bspw. LF statt HF Mode) hat. 
DS099 https://www.xilinx.com/support/documentation/data_sheets/ds099.pdf 
(Auszug im Anhang)

Und Xilinx hat extra für die DCM-Problematik eine Extra App-Note 
(XAPP462): 
http://uglyduck.vajn.icu/PDF/Xilinx/Spartan3/appnotes/xapp462.pdf

Ich verstehe es nicht. Ich gehe mit 20MHz auf die DCM Einheit und 
erzeuge 50MHz. Was ist da außerhalb der Spezifikation?

Heinz W. schrieb:
> Ich verstehe es nicht.

Ich auch nicht.

Vielleicht solltest du mal die Fehlermeldung im Original zitieren 
(screenshoot). Oder mal den Source zum Referenzcompilieren hier (als 
Anhang) einstellen. So ist das nur Kaffeesatzleserei. Vielleicht haste 
ja den nötigen BUFG als 'Eintrittspunkt' für das Taktnetzwerk vergessen.

Anhang aus UG331.

Folgende Warnung:

 Component Switching Limit Checks: TS_CLK = PERIOD TIMEGRP "CLK" 50 ns 
HIGH 50%;
 ------------------------------------------------------------------------ 
--------
 Slack: 2.779ns (max period limit - period)
   Period: 25.000ns
   Max period limit: 27.779ns (35.998MHz) (Tdcmpco)
   Physical resource: Clock_Generator0/DCM_INST/CLK2X
   Logical resource: Clock_Generator0/DCM_INST/CLK2X
   Location pin: DCM_X0Y0.CLK2X
   Clock network: Clock_Generator0/CLK2X_BUF
 ------------------------------------------------------------------------ 
--------
 Slack: 5.557ns (max period limit - period)
   Period: 50.000ns
   Max period limit: 55.557ns (18.000MHz) (Tdcmpc)
   Physical resource: Clock_Generator0/DCM_INST/CLKIN
   Logical resource: Clock_Generator0/DCM_INST/CLKIN
   Location pin: DCM_X0Y0.CLKIN
   Clock network: Clock_Generator0/CLKIN_IBUFG
 ------------------------------------------------------------------------ 
--------
 Slack: 15.239ns (period - min period limit)
   Period: 20.000ns
   Min period limit: 4.761ns (210.040MHz) (Tdcmpfx)
   Physical resource: Clock_Generator0/DCM_INST/CLKFX
   Logical resource: Clock_Generator0/DCM_INST/CLKFX
   Location pin: DCM_X0Y0.CLKFX
   Clock network: Clock_Generator0/CLKFX_BUF

Das ist meine instanzierung:

Clock_Generator0 : entity work.Clock0 port map (
  RST_IN     => reset,
  CLKIN_IN   => CLK,
  CLKFX_OUT  => clk50mhz,
  LOCKED_OUT => clock_system_locked
);

clk50mhz nutze ich um einen Prozess zu takten

Da sind zwei verschiedene DCM-Ausgänge.

Lt. Instanziierung verwendest du vom Taktsynthesizer CLK_FX, angemeckert 
wird aber das Netz am CLK_2X.
Und das ist auf 40 MHz constraint. 50 MHz sehe ich nur im letzem period 
timings.

Kurz, da sind 'Scheiben' von zwei unterschiedlichen 'Salamis', die ich 
nicht zusammenkriege. Vielleicht schaust du mal im Fpga-editor nach den 
DCM Verschalteung.

Das Problem ist, dass auch schon CLKIN angemeckert wird.

Ich habe gerade mal folgende constraint einfach auskommentiert:

NET "CLK" TNM_NET = "CLK";
#TIMESPEC "TS_CLK" = PERIOD "CLK" 50 ns HIGH 50%;

Danach kommen keine Fehler mehr. Kann es sein, dass so ein Synthesetool 
doch mehr kann und die COnstraints aus der DCM übernommen werden?

Christian R. schrieb:
> Ja in der Regel bringen die DCM und MMCM ihre Constraints dann mit
> wenn
> sie über den CoreGen erzeugt wurden. Da muss man das nicht extra noch
> definieren. Aber eigentlich sollte das auch nicht schaden.

Solbald ich aber folgendes habe:

NET "CLK" TNM_NET = "CLK";
TIMESPEC "TS_CLK" = PERIOD "CLK" 50 ns HIGH 50%;

Also das Eingangssignal auf 20MHz festlege wird wieder gemeckert.

Ich habe den Eindruck, deine Warnungen entstehen, weil Teile deines DCMs 
dem unteren Ende der erlaubten Geschwindigkeit nahe kommen (also zu 
langsam - max period limit), nicht weil etwas zu schnell wäre.

Häng zur Not halt mal dein ganzes Design hier rein statt jeweils nur 
Teile davon zu zeigen.

Achim S. schrieb:
> Ich habe den Eindruck, deine Warnungen entstehen, weil Teile
> deines DCMs
> dem unteren Ende der erlaubten Geschwindigkeit nahe kommen (also zu
> langsam - max period limit), nicht weil etwas zu schnell wäre.
>
> Häng zur Not halt mal dein ganzes Design hier rein statt jeweils nur
> Teile davon zu zeigen.

Ich habe mal ein Bild angehängt wie das verdrahtet ist. Außerdem hier 
die Konfiguration:

CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 2,
CLKFX_MULTIPLY => 5,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 50.000,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SOURCE_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"8080",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE

Es wird immer absurder. Wenn ich in den settings bei Palace and Route 
die advanced timing Analyse einschalten kommen auch mit constraint keine 
Warnungen. Diese FPGAs und ihre toolchains sind doch massives gefrickel.

dann mal anders: kann es sein, dass deine ISE überhaupt nichts anmeckert 
und dir gar keine Timing-Warnungen gibt. Sondern dass du einfach liest, 
dass die gewünschten Timings erreicht werden, und die Detailangaben dazu 
als Warnung fehlinterpretierst? Findest du irgendwo in den 
Timing-Reports tatsächlich das Wort "Warning" oder "Error" oder 
"Constraint not met"

Wenn ich das von dir oben beschriebene Minimaldesign für einen Spartan 3 
implementiere (20MHZ Takt am Eingang, per DCM 50MHz erzeugen und diese 
mit einem ODDR ausgeben, 20MHz-Contraint auf den Eingangstakt), dann 
läuft das bei mir jedenfalls ohne Probleme oder Warnungen durch.

Heinz W. schrieb:
> Ich habe gerade mal folgende constraint einfach auskommentiert:
>
> NET "CLK" TNM_NET = "CLK";
> #TIMESPEC "TS_CLK" = PERIOD "CLK" 50 ns HIGH 50%;
>
> Danach kommen keine Fehler mehr.

Ja klar, so funktionieren timing constraints eben. Das sind keine 
'Settings' die irgendwas einstellen, sondern eben Randbedingungen, also 
Größenrelationen in Bezug auf die Signallaufzeit. Gibt man kein period 
constraint an, hat die statische timing analysis nicht zu überprüfen und 
es wird kein Fehler gemeldet.

> Kann es sein, dass so ein Synthesetool
> doch mehr kann und die COnstraints aus der DCM übernommen werden?

Von welchen Synthesetool sprechen wir überhaupt?

>Ich habe den Eindruck, deine Warnungen entstehen, weil Teile deines DCMs
>dem unteren Ende der erlaubten Geschwindigkeit nahe kommen (also zu
>langsam - max period limit),

Hm, nach dem bisher bekannten (Mode LF Eingangsfrequenz 20 MHz) sollte 
es passen, da die Grenze bei 18 MHz liegt, die  Verdrahtung sieht auch 
OK aus. Eventuell kann man ja mal das Feedback auf 2x legen 
(CLK_FEEDBACK => "2X").

Gustl B. schrieb:
> Ich würde das gerne mal mit ISE nachvollziehen, aber dazu wäre dein
> Code/Projekt sinnvoll.

Code (*.vhd/*.v/*.xaw/.xco/*.xcf/*.ucf/..) wird micht ausreichen, weil 
die settings der tools nicht bekannt sind und der TO wahrscheinlich 
diese nach Beliben verändert hat. Screenshoots von den PullDown-Menus 
ist auch müßig, da wäre es sinnvoll die logdateien zu schicken. 
Allerdings steht zu Bezweifeln das die Logs/reports mit den richtigen 
Optionen erzeugt worden.

Vorschlag: räume zuerst das projekt auf (Cleanup-project), dann erzeuge 
ein Archive (Zip-Datei) mit dem ISE-Menu Project-> Archive (siehe 
Anhang). das solltekannst du dann hier als Anhang zu deinem Post 
verteilen.
Gut wäre es, wenn 'deine' Ise von der selben Version ist. Ich benutze 
hier 14.7, Gustl mglw auch.

> Aus den wenigen Informationen wird die
> Ferndiagnose schwierig und ungenau.
Das Kernproblem ist, das der TO wohl nur mangelnde Kenntniss vom 
Designflow für FPGA's hat, Kenntnisse über das Digitaldesign (DCM, 
kritischer Pfad, timing closure, set/hold) könnten auch besser sein. Ein 
Grundkurs ISE dauert in der Regel drei Tage, das sollte man nicht 
unterschätzen. Ein Einstieg könnte sein, sich mit den command line 
options der einzelenen tools zu informieren. 
https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/xilinx14_7/devref.pdf
Nicht das man gleich die ISE-GUI mit einem makefile ersetzen könnte, 
aber dann wird klarer was da überhaupt passiert. Ebenso sollte man den 
Synthese/Simulation Guide kennen: 
https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/xilinx14_7/sim.pdf

>  Diese FPGAs und ihre toolchains sind doch massives gefrickel.
Naja, ist halt wie bei 'Fishermans friend': "Sind sie zu stark, bist du 
zu weich" https://www.youtube.com/watch?v=HbowXGPg5_Y ;-)

Wie gesagt bei einschalten der advanced analysis kommt auch mit 
constraint nichts. Irgendwo im report steht dann wirklich all constraint 
met.

Heinz W. schrieb:
> Wie gesagt bei einschalten der advanced analysis kommt auch mit
> constraint nichts. Irgendwo im report steht dann wirklich all constraint
> met.

Na dann passt es ja.

Im Standardreport bekommst du für eine gewisse Zahl (in deinem Fall: 3) 
Pfade detaillierte Timingangaben. Die hast du als Warnungen 
interpretiert, was sie aber nicht waren. Alle drei haben beschrieben, 
dass das jeweils betrachtete Timing passt (ein positiver Slack übrig 
ist). Ein paar Zeilen über den vermeintlichen Warnungen hättest du 
wahrscheinlich folgenden Satz finden können: "0 timing errors detected. 
(0 component switching limit errors)"

Alle weiteren Beteiligten haben dann nach möglichen Gründen für 
angebliche Warnungen gesucht. Die aber nicht gefunden werden konnten, 
weil es gar keine Warnungen gab. Dass in deinem Report ein 40MHz-Takt 
auftaucht, von dem ansonsten nicht die Rede war, hat zusätzlich 
verwirrt.