Spartan 3/6 welche Constraints braucht man

[Gottfried M. (gottfried_m)]

Ich bin gerade etwas ratlos welche constraints man wirklich selber 
setzen muss. Ich habe ein Design, in dem ein ADC von mir aus dem FPGA 
heraus mit einer 50MHz Clock versorgt wird. Diese 50MHz werden intern im 
Spartan 3 aus einer Referenzclock erzeugt. Damit wird jedes Entity auch 
versorgt.

Die Constraints für die DLL werden automatisch erzeugt, damit das 
Synthesetool weiß wie schnell das ist.

Die ADC Daten werden dann parallel wieder an den FPGA gegeben und dort 
werden die Daten verarbeitet. Meine Frage dazu lautet ob das 
Synthesetool weitestgehend alles automatisch macht, wenn man die 
Geschwindigkeit der Referenz definiert. Also werden die 16bit breiten 
ADC Datenleitungen intern nicht weit voneinander entfernt geroutet, 
sondern möglichst gleich lang um gleiche Latenz zu bekommen?

Wie sieht das mit einem SPI Master im FPGA aus? Muss ich hier 
irgendwelche Constraints manuell setzen?

[J. S. (engineer)]

Die maximale Toleranz der zeitlichen Varianz der Ausgänge gegenüber dem 
Takt.
Diese kommen aus den Setup- und Holdtime-Angaben im Datenblatt. Faktisch 
geht es im Wesentlichen darum, ob die Daten zur pos. oder neg. Flanke 
des Taktes anstehen müssen und wie lange um diesen Bereich herum die 
Daten stabil sein müssen. Gfs muss das für beide Flanken eingestellt 
werden, wenn du DDR taktest.

[Rick D. (rickdangerus)]

Gottfried M. schrieb:
> Ich bin gerade etwas ratlos welche constraints man wirklich selber
> setzen muss.
Prinzipiell erstmal alle, wobei in vielen Designs die Angabe der 
Taktfrequenz (und die Pinzuordnung) schon ausreicht.


> Ich habe ein Design, in dem ein ADC von mir aus dem FPGA
> heraus mit einer 50MHz Clock versorgt wird.
Kein gute Idee. Die im FPGA erzeugten Takte sind i.d.R. mit relativ 
hohen Jitter behaftet. Der Taktjitter wird vom ADC in einen 
Amplitudenfehler umgewandelt und äußert sich in erhöhtem Rauschen (außer 
man sampelt DC, aber dann braucht man keinen 50 MHz ADC).


> Die Constraints für die DLL werden automatisch erzeugt, damit das
> Synthesetool weiß wie schnell das ist.
Ja, die automatischen (Takt-)Constraints an DCM/PLLs funktionieren bei 
Xilinx/ISE ganz gut.


> Die ADC Daten werden dann parallel wieder an den FPGA gegeben und dort
> werden die Daten verarbeitet.
Der ADC hat eine gewisse Latenz zwischen der Taktflanke am Eingang und 
bis valide Daten auf den Leitungen anliegen. Diese Latenz steht im 
Datenblatt des ADC.
Zusätzlich spielt ggf. noch die Leitungslänge (Takt hin zum ADC, Daten 
zurück zum FPGA) eine Rolle.
In Summe muß das dem Synthesetool bekannt gemacht werden:

TIMEGRP "TG_ADC_DATA" OFFSET = IN x.y ns VALID z ns BEFORE "ADC_CLK";
NET ADC_DATA<0>    TNM = "TG_ADC_DATA";
NET ADC_DATA<1>    TNM = "TG_ADC_DATA";
NET ADC_DATA<2>    TNM = "TG_ADC_DATA";
...

> Wie sieht das mit einem SPI Master im FPGA aus? Muss ich hier
> irgendwelche Constraints manuell setzen?
Normalerweise nicht. SPI wird üblicherweise über chip select 
synchronisiert.
Die Signale vom Master (CLK, DO, CS) kommen i.d.R. alle aus der gleichen 
Taktdomäne und sind daher nur routing delays unterworfen. Die 
Unterschiede in den routing delays liegen (je nach Chip) in der 
Größenordnung unterhalb einer Nanosekunde und sind für SPI nicht 
relevant.
Wie schnell ist denn der SPI-Takt?

[DSGV-Violator (Gast)]

> Also werden die 16bit breiten
> ADC Datenleitungen intern nicht weit voneinander entfernt geroutet,
> sondern möglichst gleich lang um gleiche Latenz zu bekommen?

um eine Minimierung der Laufzeit zwischen den eizelnen Leitungen eines 
parallen Busses "kümmern" sich die Synthesetools nicht, da hat man mit 
den timing-constraints keinen Einfluß drauf.

Üblicherweise lässt man sich einen Report  für die einzelnen Leitungen 
ausgeben und wenn es passt, packt man (im fpga-Editor) ein Attribut 
"dedicated routing" drüber damit das in späteren Läufen nicht verändert 
wird.

Bei ADC Eingängen sorgt man dafür, das als erste FF im FPGA die FF in 
den IO-Pads genutzt werden und nicht welche tiefer in der logic-Fabric. 
Manchmal muss man deshalb den VHDL-Code umschreiben, bspw. um unnötige 
Resets von die genannten FF zu entfernen.

Man kann auch mit den IO-delay elementen einiges untereiannder zeitlich 
verschieben, aber das ab spartan-6 und weniger/garnicht im Spartan-3 .

https://opencores.org/websvn/filedetails?repname=openmsp430&path=%2Fopenmsp430%2Ftrunk%2Ffpga%2Fxilinx_avnet_lx9microbard%2Fdoc%2FSpartan-6_SelectIO_Resources_ug381.pdf

https://support.xilinx.com/s/question/0D52E00006hpTP3SAM/routing-delays-on-fpga-editor?language=en_US