Xilinx: IO Register im IOB

[Bronco (Gast)]

Hallo,

ich hab mal eine Frage zu dem Xilinx ISE MAP-Property "Pack I/O 
Registers/Latches into IOBs":
Wenn ich es richtig verstehe, besagt dieses Property, ob das "letzte" 
FlipFlop vor dem Pin in den IOB gemappt oder irgendwo anders.
Was macht es denn überhaupt für einen Sinn, dieses FlipFlop nicht in den 
IOB zu legen?
Laut Doku sollte dieses Property für meinen Spartan3S5000 defaultmäßig 
auf "For Inputs and Outputs" stehen, tatsächlich stellt es ISE13.4 und 
14.1 aber defaultmäßig auf "Off". Bug oder Feature?

[Harald (Gast)]

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.

[Paule Praxis (Gast)]

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 F. (kfalser)]

Bronco schrieb:
> Was macht es denn überhaupt für einen Sinn, dieses FlipFlop nicht in den
> IOB zu legen?

FF's in IOBs habe z.B. keine vorgeschaltete LUT, d.h. die IOB's takten 
am besten die Ausgangssignale nochmals sauber ab, damit sie alle schön 
synchron an den Pins auftauchen.
Sie eignen sich aber nicht so gut oder überhaupt nicht dazu z.B. einen 
Zähler zu implementieren.

[Paule Praxis (Gast)]

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.

[Harald (Gast)]

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

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

[Fritz J. (fritzjaeger)]

Harald schrieb:
> Paule Praxis schrieb:
>> Ne, nix spendiert, dieses FF kriegst du geschenkt.
>
> Du musst es im Design aber einbauen und daher verlierst du einen Takt!

Nö, man dupliziert einfach das interne Ziel-FF. Sollte es dabei zu 
Problemen kommen, das für das Ziel-FF das timing wg unrelated logik (LUT 
und FF nicht aus dem gleichen CLB), dupliziert man auch das Quell-FF 
samt Logik an Q. Nutzung des IO-FF als RS-FF statt D-FF kann auch 
helfen.

Wobei hier nicht die Frage gestellt wurde, ob man Ein- und ausgehende 
Signale beim Passieren der FPGA-Grenzen durch FF's führen sollte. 
Sondern ob man diese FF's in die Pads platziert oder in Logikblöcke. Ich 
sehe keinerlei Vorteile in einer Paltzierung weg vom Pin, nur Nachteile. 
(unterschiedliches Timing je nach laune des Placers, Enstehung 
Phasen-Skew zwischen logisch konsitenzen Signalen (bits in vector, 
strobe in), Propagierung von Skew auf dem PCB (track-länge, 
unterschiedliche Lötstellen, inhomogenes Epsilon des PCB-Materials 
(Charge, Nutzen)) aufwendigere STA, etc ...


MfG

[Bronco (Gast)]

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?

[Paule Praxis (Gast)]

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:

Entity
..
Port(
..
count_oq: out std_logic_vector(7 downto 0),  -- IOB-ff
count_o:  out std_logic_vector(7 downto 0)  -- signal vom internen FF FF                                 
);
End of Entity;
Architecture behave ...

 signal count_increment: std_logic_vector(7 downto 0);
 signal count_q:         std_logic_vector(7 downto 0);

begin
 process(clk)
 ...
  if rising_edge(clk)
   count_q  <= count_increment;  -- internes FF
   count_oq <= count_increment;  -- paralles, im IOB platzierbares FF
  end if;
 ..
 end process;

 count_increment <= count_q + "00000001";  --Increment Logik an internen FF
 count_o         <= count_q;               --"Draht" vom internen FF nach draussen 
..
end architecture;

MfG