komische Syntheseergenisse

[hi tec ing (Gast)]

Habe ein Design auf Virtex6, Spartan6 und Kintex7 erzeugt und folgende 
Fakten vorgefunden (jeweils nach Synthese und realer Implementierung):

Komisch ist das Verhältnis von Regs/Slices beim Spartan sowie die 
schlechten Ergebnisse beim Virtex. Dort musste ich am meisten 
Zusatzregister einbauen, um das Timing zu erreichen. Die Einstellungen 
und Strategiefiles waren identisch und es wurden keine slices in BRAMs 
verschoben.

Kann sich das jemand erklären?

Synthese
                    v6        s6        k7

slice registers    123      120      120
look up tables     109       99       99
DSP48E1s             7                7
DSP48As                      12
BRAMS                0        0        0
fmax reported      13 MHz     32 MHz     86 MHz


Implementation
                    v6        s6        k7

slice registers    140      138      137
look up tables      99      112       81
occupied slices     61       29       48
DSP48E1s             7                7
DSP48As                      12
BRAMS                0        0        0
Timing 75 MHz     not met    not met    met


Implementation for timing 75 MHz
                    v6        s6        k7

slice registers    187      161      137
look up tables     127      121       81
occupied slices     85       36       48
DSP48E1s             7                7
DSP48As                     12
BRAMS                0        0        0
Timing  75 MHz     met      met      met

[Duke Scarring (Gast)]

hi tec ing schrieb:
> Kann sich das jemand erklären?
32 MHz auf dem Spartan6?
Das klingt nach einem vermuksten Design mit ewig langen kombinatorischen 
Pfaden. Waren bei der Umsetzung Informatiker am Werk? Oder will da 
jemand ins Bitcoin-Mining einsteigen?

Duke

[hi tec ing (Gast)]

Es ist die Kombinatorik einer verketteten Rechung mit mehreren 
Multiplieren und Addieren, die passend registriert werden, damit 
möglichst wenig Latzenz entsteht. Ich will ja nicht mehr Register 
spendieren, als nötig. Offenkundig kommt man beim Kintex mit wesentlich 
weniger Registern aus.

[user (Gast)]

Die Register sind GRATIS! Jede LUT hat auch ein Register und ob du das 
nimmst oder nicht ändert nichts an der Resourcennutzung

[Marius W. (mw1987)]

user schrieb:
> Die Register sind GRATIS!

Aber nur, wenn man das Kleingedruckte nicht liest. Ein Register hat als 
"Kosten" immer eine Latenz von einem Takt. Da muss man dann ein bisschen 
Grips in die Pipeline stecken.

Gruß
Marius

[Michael W. (Gast)]

Ich glaube, hier geht es darum, dass er zusätzliche Register einsetzen 
muss, um das timing zu kriegen. Die Zahl der slices ist ja auch 
angestiegen.

[Oli (Gast)]

hi tec ing schrieb:
> Komisch ist das Verhältnis von Regs/Slices beim Spartan sowie die
> schlechten Ergebnisse beim Virtex. Dort musste ich am meisten
> Zusatzregister einbauen, um das Timing zu erreichen.
Ist das nur bei dem design so, oder auch bei anderen?

Der Virtex ist doch der bessere Baustein, war das vielleicht der 4er?

[high tec ing (Gast)]

ja, ich musste zusätzliche Register einsetzen, um das Timing zu 
erreichen und zwar erstaunlch viele.

>Der Virtex ist doch der bessere Baustein, war das vielleicht der 4er?
Nein, war schon der angegebene.

[Christoph (Gast)]

Die Anzahl der eingesetzten Register und LUTs ist vergleichbar für die 
verschiedenen Bausteine. (Wenn sich meine Erinnerung nicht täuscht sind 
auch alles 6-Input LUT Bausteine).

Daher ist meine Vermutung, dass sich der Aufbau eines Slice beim V6, S6 
und K7 stark unterscheiden. Schau mal ins Datenblatt, da müsste es je 
ein Blockdiagramm des Slice geben.


Meine Annahme ist, dass der S6 ein komplexeres Slice hat als der V6 (aus 
deinen Zahlen geschlossen). Dein Design scheint diese komplexeren Slices 
ausnutzen zu können und so entsteht weniger zusätzliche Routinglatenz 
zwischen den Slices (was beim V6 diese zusätzliche Zeit kostet).

Ist mal ein Schuss ins Blaue :-)

[high tec ing (Gast)]

Das klingt plausibel, ja.

[daniel__m (Gast)]

hi tec ing schrieb:
> Komisch ist das Verhältnis von Regs/Slices

Das ist so nicht verwunderlich. Die Toolchain versucht nicht, die Slices 
optimal auszulasten, sondern verteilt "über den ganzen Chip". Erst wenn 
die freien Slices gegen Null tendieren, wird optimiert.

Evtl. ist der V6 deutlich größer als der S6, so dass sich die Toolchain 
(mal wieder) selbst im Wege ist. Beim K7 kann ich mir vorstellen, dass 
die Routing- und/oder DSP48E1-Delays deutlich kleiner sind, und es so 
besser aussieht.

Ein anderer Grund kann sein, dass der V6 DSP48E1s und der S6 DSP48As 
haben. Die E's können (grundsätzlich) mehr (preadder, mult, adder), was 
aber bei nicht optimaler Verwendung ein Hindernis ist, da sie höhere 
Durchlaufzeiten haben. Die A's haben meines Wissens keine Preadder.

Grüße