Schaltzeiten für LUTs

Gast #983000
Lesenswert?

Hallo,
ich versuche im Moment eine möglichst effiziente Kombination von Formeln 
und Look-up Tabellen unter Verilog zu realisieren.
Dazu muss ich aber wissen wie lange LUTs intern zum umschalten von einer 
Adresse zu einer anderen brauchen, im Verhältnis zur Menge der Werte die 
gespeichert sind. Also so etwas wie je größer die LUT ist, desto größer 
ist die Umschaltzeit.
Ich habe bereits alles nach solchen Angaben abgesucht, konnte aber 
nichts finden.
Ich bin dankbar für jede Hilfe.
#983058
Lesenswert?

Da solltest du ein Blick in die timing reports der Synthesetools werfen 
- dort bekommst du auf Wunsch fuer jedes Signal einzeln die Laufzeiten 
in jedem Gatter und jeder Verbindung aufgelistet.


Gatterschaltzeiten und Laufzeiten zwischen Gattern sind meist 40:60 bis 
60:40, ausgenommen sehr grosse Designs, bei dem die Laufzeiten noch 
groesser werden. (Virtex 4: ganz grob 1ns pro Gatter und Verbindung)
Moderator (Firma: Titel) Persönliche Seite #983142
Lesenswert?

> Also so etwas wie je größer die LUT ist...
LUTs sind hardwaremäßige Komponenten und immer gleich groß (z.B. Xilinx: 
4 Eingänge). Die genaue Durchlaufzeit durch eine LUT steht im DB.

Was du meinst ist eher, wieviele Logikebenen (LUTs) für welche 
Kombinatorik hintereinander geschaltet werden (z.B. für ein 10-fach 
OR-Gatter), und wie die Gesamtdurchlaufzeit ist. Das sagt dir der 
Synthesereport.
Allerdings mußt du die Durchlaufzeit im Routing auch noch dazurechnen.
Gast #983542
Lesenswert?

>ich versuche im Moment eine möglichst effiziente Kombination von Formeln
>und Look-up Tabellen unter Verilog zu realisieren.

Das scheint eben um sich zu greifen. Leider verstehen viele nicht, daß 
solche Optimierungsansätze extrem Techniologieabhängig sind.

Besser wäre es, parametrierbare Core zu bauen, die man NACH der Synthese 
ein bischen verbasteln kann, um die Randbedingungen zu verschieben. Die 
Synnthese ist in 99% der Fällen besser, als das manuell getrimmte.

Komischerweise gibt es immer noch Projektleiter, die so was gestatten, 
statt einfach eine Synopsislizenz zu kaufen ...
Gast #983711
Lesenswert?

>Besser wäre es, parametrierbare Core zu bauen, die man NACH der Synthese
>ein bischen verbasteln kann, um die Randbedingungen zu verschieben. Die
>Synnthese ist in 99% der Fällen besser, als das manuell getrimmte.

Das stimmt nicht ganz. Je nach Auslastung des FPGAs knallt dir die 
Synthese die Funktionsblöcke sonst wohin, dass man am Ende nur am 
Verzweifeln ist. Man kann sich zwar die Ergebnisse der Synthese 
anschauen, aber danach ist meist trotzdem Handarbeit angesagt. Wenn es 
um zeitkritische Designs geht ist die Handarbeit bei den Placement 
Constraints viel besser.
Moderator (Firma: Titel) Persönliche Seite #983877
Lesenswert?

> je nach Auslastung des FPGAs knallt dir die
> Synthese die Funktionsblöcke sonst wohin...
So ganz stimmt das nicht. Die Synthese knallt gar nichts irgendwo ins 
FPGA. Das machen Translate und Place&Route.

> Wenn es um zeitkritische Designs geht ist die Handarbeit
> bei den Placement Constraints viel besser.
Eine gute Beschreibung und richtige Timing-Constraints halten das Design 
portabler. Selten muss das komlette Design auf z.B. 300MHz laufen. Oft 
sind da Multicycle- und Pseudo-Pfade. Wenn die in den Timing-Constraints 
korrekt angegeben sind, kann P&R oft sehr einfach den schnellen Teil 
dicht plazieren und hat große Freiheiten bei den langsamen 
FPGA-Bereichen. Sobald ich aber mit Placement-Constraints anfange (oder 
anfangen muß) ist das Design auf ein FPGA festgenagelt.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren