Hallo Leute Ich muss in einem Design, welches eigentlich für ein möglichst kleines FPGA gedacht war, nun mehrere lookup-tables einbauen welche nach kurzer Überschlagsrechnung die zur Verfügung stehenden Resourcen empfindlich verknappen könnten. Es geht um insgesamt 8 Tabellen mit 4096 Einträgen zu je 8 bit - also 12 bit rein, 8 raus. Da bei vielen der Tabellen sehr viele Nullen vorkommen würde es sich anbieten die Tabellen als Truth Tables zu verstehen und diese dann möglichst weit zu vereinfachen. Ich frage mich jetzt, ob sich der Aufwand hierfür überhaupt lohnt, oder ob das Synthese Tool nicht eine lookup-Tabelle schon selbständig so weit wie möglich eindampft. Und wenn ja, welches die geeignete Form ist in der der Synthese die Tabellen übergeben werden sollten. Die momentane Implementierung erfolgt in Verilog als ein großes case statement mit 4096 cases und pro case je einem 8-bit Ausgabewert. Ist dies eine Form mit der das Tool klar kommt? Wäre es besser die vielen Null-Bytes vorher durch ein einziges default zu ersetzen? Die Synthese erfolgt mit Altera Quartus oder u.U. mit dem entsprechenden Tool von Latice (der FPGA-Typ steht bislang noch nicht fest) Wer hat diesbezüglich irgendwelche Erfahrungen beizusteuern? Andere Alternativen die ich gerade verfolge: * Block-Ram (32k Bytes dürfen für kleine FPGAs schon viel sein) - nur wie kommen die Daten da rein? Kann das FPGA beim booten RAMs gleich laden? * externes (Flash-/EP-)ROM mit den Tabellen (könnte vom I/O pincount knapp werden und ist ein extra Bauteil) * Sonst noch welche???
@ andi6510 (Gast) >verknappen könnten. Es geht um insgesamt 8 Tabellen mit 4096 Einträgen >zu je 8 bit - also 12 bit rein, 8 raus. BRAM, ggf. kann man zwei Tabellen in einen BRAM stecken und die beiden Ports unabhängig voneinander nutzen. Wenn es das Timing und FPGA erlaubt kann man auch mehr Tabellen in einen BRAM stecken und den Zugriff multiplexen. >Da bei vielen der Tabellen sehr viele Nullen vorkommen würde es sich >anbieten die Tabellen als Truth Tables zu verstehen und diese dann >möglichst weit zu vereinfachen. Das macht dir der Synthesizer allein, das muss man nicht manuell machen. >Ich frage mich jetzt, ob sich der Aufwand hierfür überhaupt lohnt, Nein. > oder >ob das Synthese Tool nicht eine lookup-Tabelle schon selbständig so weit >wie möglich eindampft. Ja. >Und wenn ja, welches die geeignete Form ist in >der der Synthese die Tabellen übergeben werden sollten. Ist egal. Welche dir besser gefällt. https://www.mikrocontroller.net/articles/TTL74185 >Die momentane Implementierung erfolgt in Verilog als ein großes case >statement mit 4096 cases und pro case je einem 8-bit Ausgabewert. Ist >dies eine Form mit der das Tool klar kommt? Sicher. warum hast du es nicht einfach mal probiert? > Wäre es besser die vielen >Null-Bytes vorher durch ein einziges default zu ersetzen? Ist dem Tool egal, aber ggf. besser lesbar, weil es deutlich kürzer ist. >* Block-Ram (32k Bytes dürfen für kleine FPGAs schon viel sein) - nur >wie kommen die Daten da rein? Kann das FPGA beim booten RAMs gleich >laden? Jeder BRAM wird IMMER initialisiert, diese Daten sind Bestandteil des Bitstreams. >* externes (Flash-/EP-)ROM mit den Tabellen (könnte vom I/O pincount >knapp werden und ist ein extra Bauteil) Es gibt serielle Flashs mit SPI.
Beschreibe einfach einen ROM, die Synthese optimiert das dann. Solange die Lese-Adresse nicht getaktet ist, wird Logik draus, bei getaktetem Lesen wird ein Block RAM(ROM) draus. Das kann man aber auch noch individuell steuern. Nach der Synthese ist das eh nur noch Verdrahtung, da gehen die höchstens irgendwann die Routing Ressourcen aus. Und ja, Block RAM genauso wie ditributed RAM kann man gleich passend intialisieren. Entweder direkt im Code wie bei normalen Signalen auch, oder mit einer Funktion aus einem File.
Danke für die schnellen Antworten! Ich denke, ich werde es dann wohl einfach der Synthese überlassen. Da das FPGA noch nicht feststeht habe ich die Synthese noch nicht am laufen - so kann ich es nicht kurz mal ausprobieren. Ich bin noch vollständig in der RTL-Simulationsphase. Aber wenn klarer wird, welches FPGA es sein wird, werde ich es einfach mal ausprobieren. Manchmal möchte man Probleme lösen, die man noch gar nicht hat ;-) (Und klaro BLOCK-Ram wird natürlich am Anfang mit initialisiert. Hab ich irgendwie verdängt.)
Noch ein kleiner Tipp: Ich habe auch eine FSM mit mehreren tausend States, die jeweils einen n-bit Vektor ausgeben. Falls die Synthese dann plötzlich mehrere Stunden dauern sollte, dann einfach mal Quartus "safe state machine" (oder so ähnlich) ausschalten. Das sollte die Synthese dann auf eine Minute verkürzen.
Gustavo F. schrieb: > Noch ein kleiner Tipp: Ich habe auch eine FSM mit mehreren tausend > States, die jeweils einen n-bit Vektor ausgeben. Falls die Synthese dann > plötzlich mehrere Stunden dauern sollte, dann einfach mal Quartus "safe > state machine" (oder so ähnlich) ausschalten. Das sollte die Synthese > dann auf eine Minute verkürzen. Gerade die erste VHDL Vorlesung besucht? FSM != ROM/RAM
MicroMaik schrieb: > Gerade die erste VHDL Vorlesung besucht? > FSM != ROM/RAM Wenn das ROM/RAM auf sich selbst zurück gekoppelt wird, dann wird mit ein wenig Geschick wieder eine FSM draus...
Was Gustavo schreibt stimmt schon, jede FSM hat massenhaft Kombinatorik. Ein Tipp noch: Man sollte noch solche Sachen wie "extract state machines" ausschalten, wenn man ständig synthetisiert. Erst am Ende eine massive Optimierung ansetzen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.