Xilinx: IO Register im IOB

Feature, denn ein freies FF kann so verteilt werden, dass es genau in 
der Mitte des Pfades liegt, wenn es mit dem Routing knapp wird, während 
der Zwang zum IO dazu führen kann, dass man "unterwegs" nochmal eins 
braucht.

FFs in den IOs verbessern zieführend nur dann das timing, wenn man 
nochmal ein extra FF spendiert und sie führen zu koheränten Bussen.

Es bleibt Dir überlassen, ob du es nutzt, weil die Synthese das nicht 
allein entscheiden kann.

Mein Tipp: Baue von Anfang an immer ein Doppelregister ins Design, wenn 
nicht zwingende Gründe dagegen stehen und nimm sie am Ende der 
Entwicklung nur raus, wenn du musst. Du sparst Dir damit ständig etwas 
Synthesezeit.

Harald schrieb:
> FFs in den IOs verbessern zieführend nur dann das timing, wenn man
> nochmal ein extra FF spendiert und sie führen zu koheränten Bussen.

Ne, nix spendiert, dieses FF kriegst du geschenkt. Das ist ja der grosse 
Vorteil von FF im Out-Pin Pfad. Es gibt IMHO keinerlei Grund in einem 
solchen fall das FF nicht zu benutzen.

Im Input-Pfad eigentlich auch nicht. Falls der nächste Endpunkt wirklich 
soweit vom Input wegliegen sollte, das man das FF besser in die Tiefe 
des FPGA's legt, dann hast du mit dem Pin-(PCB)-Layout geschlampt.

Mir persönlich ist es noch nie vorgekommen, das ich ein FF aus dem Pad 
schieben musste, weil das timing nicht passte. Und ich habe schon 
zehtausende von IO-FF verlegt.

Mahlzeit,

Klaus Falser schrieb:
> Sie eignen sich aber nicht so gut oder überhaupt nicht dazu z.B. einen
> Zähler zu implementieren.

Da sie nur im IO-Pfad  (i-PAD -> D resp Q -> O-PAD) sind IO-PAD 
überhaupt nicht mit interner Logic Rückführbar. deshalb werden sie auch 
nicht zur Logic-Fabric gezählt.

Der Counter baut man aus "internen" FF. Sollen counterbits auch aus dem 
FPGA geführt werden, führt man eben die Q der zähl-FF nicht nur über die 
Inkrementier-Kombinatprik an die D der internen FF, sondern auch an D 
der IO-FF. Knallhartes IO-timing quasi geschenkt.

Paule Praxis schrieb:
> Ne, nix spendiert, dieses FF kriegst du geschenkt.

Du musst es im Design aber einbauen und daher verlierst du einen Takt!

Das heißt, bei einem Ausgang werden im Zweifelsfall zwei parallele FF 
benutzt: Ein "normales" für die Logik und das im IOB nur für den Pad?

Bronco schrieb:
> Das heißt, bei einem Ausgang werden im Zweifelsfall zwei parallele FF
> benutzt: Ein "normales" für die Logik und das im IOB nur für den Pad?

Es ist wohl gemeint das bei signalen die intern verwendet UND nach 
draussen gehen zwei parallel FF verwendet werden. Man buffert Ausgänge 
um extern (Pin+PCB) ein großes timingbudget zu haben. bei internen FF 
verschsendet man da schon wieder ein paar Nanoseconds. Da das FF eh im 
Pad vorhanden ist und nicht für interne Signale benutz werden kann 
bekommt man es für diesen zweck quasi geschenkt. Deshalb fordert i.d. 
Regel die Designspec das alle Outputs die IOB-FF nutzen müssen (steht in 
der regel im reportfile *.pin(?).

Schnipseltechnisch sieht das so aus:

1

Entity

2

..

3

Port(

4

..

5

count_oq: out std_logic_vector(7 downto 0),  -- IOB-ff

6

count_o:  out std_logic_vector(7 downto 0)  -- signal vom internen FF FF                                 

7

);

8

End of Entity;

9

Architecture behave ...

10

11

 signal count_increment: std_logic_vector(7 downto 0);

12

 signal count_q:         std_logic_vector(7 downto 0);

13

14

begin

15

 process(clk)

16

 ...

17

  if rising_edge(clk)

18

   count_q  <= count_increment;  -- internes FF

19

   count_oq <= count_increment;  -- paralles, im IOB platzierbares FF

20

  end if;

21

 ..

22

 end process;

23

24

 count_increment <= count_q + "00000001";  --Increment Logik an internen FF

25

 count_o         <= count_q;               --"Draht" vom internen FF nach draussen 

26

..

27

end architecture;

MfG