I/O Constraints Intel

[Max M. (fpga_eth)]

Hallo zusammen

Ich habe einige asynchrone Input Signale welche ich gerne bez. des 
delays constrainen möchte. Alternativ ein default constraint für alle 
Inputs.

Also anders gesagt einen min/max delay von Pin zum ersten Sync register.

Nun ist es so, dass dies bei Quartus mit "set_input_delay -clock" in 
referenz zu einem Clk erfolgen muss. Das Problem dabei ist, dass ich 
einige Signale (z.B. SPI) mit 400MHz oversample. Eine referenzierung der 
langsamen CMOS I/O zu diesem CLK zerstört erwartungsgemäss das Timing. 
(Ist auch nicht so gewollt). Einen Delay Pin->Register von 0- ca. 10ns 
sollte ausreichend sein (sind aber bereits 4 clk Perioden des 
Registerclk).

Folgende Frage:

1. Wie constraint Ihr die Signale Pin -> 1. Sync FF?
2. Wie das gleiche mit dem Output wenn Sysclk > Geschwindigkeit I/O 
standart

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

Hm, kein vollständiges Wissen über SDF/SDC syntax vorhanden?

man muß lediglich anfang und endpunkt des Pfades passend definieren
https://www.intel.com/content/www/us/en/docs/programmable/683068/18-1/using-timing-constraints.html

Beispiel:

set_net_delay -from reg_a -to reg_c -max 20

> Alternativ ein default constraint für alle Inputs.

Also falls man den kleinsten/optimalen Pfad von Pad zum ersten FF 
vorgeben will, verlangt das i.d.R. das man das FF in der IO-Padzelle 
nutzt. Das erreicht man eher über map(placer)-constraints und checkt 
dann im io-report ob in der Spalte Pad-FF? yes steht (o.ä.) .

Eventuell muss man doch einen IP-Block für das IO nehmen:
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://cdrdv2-public.intel.com/705299/ug-altera-gpio-16.1-683136-705299.pdf

Ansonsten tatsächlich mal ne Schulung bzgl timing und constraints 
durcharbeiten.

* 
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://cdrdv2-public.intel.com/669829/an584-683145-669829.pdf
* 
https://www.intel.com/content/www/us/en/docs/programmable/813669/24-2-5-0-0/timing-constraints.html

[Max M. (fpga_eth)]

Bradward B. schrieb:
> Hm, kein vollständiges Wissen über SDF/SDC syntax vorhanden?

Nein, leider nicht, naja Async. Inputs hatte ich bisher immer 
angenommen, dass wenn er die Sync chain als solche entdeckt er 
automatisch immer das erste FF in der I/O Zelle nutzt. Habe ich erst 
kürzlich im Chiplan entdeckt dass dem nicht so ist (!?!).
Noch schlimmer er scheint random im ganzen chip verteilt das erste FF zu 
platzieren - daher meine Erkentnis der Notwendigkeit dies zu 
constrainen.

Bradward B. schrieb:
> man muß lediglich anfang und endpunkt des Pfades passend definieren

Ok, naja geht dies irgendwie automatisch mit TCL? Oder muss Manuell für 
jedes I/O aus dem RTL Viewever der Name des PIN sowie destination das 
erste dazugehörige FF entnommen werden?
Oder noch besser generell automatisch, Quartus erkennt ja dass es sync 
chains sind- daher besteht evtl die möglichkeit auf diese zu 
constrainen?

Bradward B. schrieb:
> Also falls man den kleinsten/optimalen Pfad von Pad zum ersten FF
> vorgeben will, verlangt das i.d.R. das man das FF in der IO-Padzelle
> nutzt. Das erreicht man eher über map(placer)-constraints und checkt
> dann im io-report ob in der Spalte Pad-FF? yes steht (o.ä.) .

Genau. Ja das ist eigentlich die offensichtlich ideale Wahl der FF 
Platzierung. Oder zumindest in dessen Nähe- nicht random über den ganzen 
Chip verteilt. Ist wie gesagt aktuell nicht der Fall.

Bradward B. schrieb:
> Eventuell muss man doch einen IP-Block für das IO nehmen:

Ok ja, shade, naja das ist evtl etwas overkill. Dann besser noch mit 
manuell aus RTL Viewer Netznamen raussuchen und ins SDC schreiben.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

wenn man den placer mit tcl steuern kann, dann kann man auch ein tcl 
script schreiben was das FF ins Pad drückt. Xilinx hat im Unterschied zu 
Altera tcl erst recht spät zur toolchainsteuerung eingebaut.

Sich mit Chipviewer anzuschauen, wo die FF gelandet sind, ist IMHO immer 
noch die sicherste Methode.

Manchmal kann das FF nicht in die IO-Pads platziert werden, weil vor dem 
D-Eingang eine LUT muß (die es nicht immer im IO-Pad gibt). Dann muss 
man sich die VHDL Beschreibung anschauen, warum da die Synthese eine LUT 
vor das FF "reinbastelt" (meist ein (unnötiger) synchroner SET/RESEST)). 
Oder ein anderes (enges timing) constraint sorgt dafür, das das FF "nach 
innen gezogen wird".

Pauschal lässt sich da keine Methode vorschlagen, um die FF in die Pad's 
zu verschieben. Am einfachsten könnte es noch bei reinen outputs sein, 
inout -pads dagegen sind meist "tricky" und verlangt das man 
"nachforscht" warum die Synthese doch direkt übern die Config-MUX 
datain_0 oder Datain_1 nimmt statt erst übers Input-FF und dann raus 
(siehe Anhang (intel Max10).

Manchmal kann es auch daran liegen, das die tools nicht den Takt aus dem 
inneren für die IOB-FF verwenden können, weil deren Taktnetzwerk schon 
durch ein anderes signal verwendet wird (bspw. "data strobe").