Hallo Leute! Ich hatte mal gelesen, dass Xilinx für die FPGAs empfliehlt, Init-Werte für die Synthese zu benutzen, da FPGAs SRAM basiert sind und vorgeladen werden. Heißt das, dass man ganz auf Resets verzichten könnte? Die nächste Frage wäre dann, wie es bei den CPLDs damit aussieht (z.B. CoolRunner II). Werden dort die Init-Werte genauso beim Power-Up angewendet wie bei FPGAs? Wo findet man genaue Dokumentation hierzu, habe schon gesucht aber nix gefunden :( Viele Grüße, Anguel
Hallo Anguel, Xilinx empfielt ausdrücklich zu überlegen ob und wo man wirklich resets benötigt. Wie schon gesagt, das FPGA hat eine interne Resetlogic, welche zum Initialisierungszeitraum die interne Initialisierung steuert und beim Laden des Bitstreams werden alle FF Elemente (mit einem definierten Zustand geladen). Die Initwerte von Distributed und Blockmemories können ebenfalls angegeben werden. Schau Dir bei Xilinx einmal folgendes Dokument an: wp272.pdf - Get smart about reset, think local not global Bei den CPLDs ist es etwas anderes, da grundsätzlich nur der Q Ausgang z.B. in Richtung Ausgang geht. Hier kann es zu Einschränkungen kommen. Eine Quelle von Dokumenten ausserhalb des jeweiligen Datenblattes in dem die Logikzellen ja meist dargestellt sind, kann ich allerdings auch nicht zu bieten... Gruß Andreas
> Xilinx empfielt ausdrücklich zu überlegen ob und wo man wirklich resets > benötigt. Insbesondere asynchrone Resets in einem synchronen Design sind mit äusserster Vorsicht zu geniessen. Wir hatten das schon im Beitrag "Re: Xilinx und die Resets" > Heißt das, dass man ganz auf Resets verzichten könnte? Ja, denn wer braucht in einem SRAM-FPGA den Reset? Nur der Entwickler: dass er einen Knopf hat, um sein amoklaufendes Design wieder zur Ruhe zu bringen... :-/
Anguel S. schrieb: > Die > nächste Frage wäre dann, wie es bei den CPLDs damit aussieht (z.B. > CoolRunner II). Werden dort die Init-Werte genauso beim Power-Up > angewendet wie bei FPGAs? Das Initialisieren von Registern funktioniert beim CPLDs genauso wie bei FPGAs. Ich hätte keinen Unterschied bemerkt. Die Register wachen mit dem gewünschten Wert auf.
Wenn du auf deiner xilinx insel bleibst und damit zufrieden bist begrenzt portierbaren code zu erzeugen, dann kanst du in der tat teilweise auf einen reset verzichten.
> Wenn du auf deiner xilinx insel bleibst und damit zufrieden bist > begrenzt portierbaren code zu erzeugen Ich sehe es eher so, dass auch die anderen FPGA-Hersteller dieses sehr praktische Feature implementieren werden. Denn ein SRAM-FPGA muß sowieso geladen werden, das sind schon 16 Bits für eine 4-fach Lut, dazu jede Menge Konfigurationsschalter und Muxer. Da machen die paar FFs den Kohl wirklich nicht mehr fett... Und so ein FPGA-Design einfach so auf ein ASIC zu portieren, da sind dann sowieso noch einige andere Ecken, an denen es klemmen wird.
Lothar Miller schrieb: > Und so ein FPGA-Design einfach so auf ein ASIC zu portieren, da sind > dann sowieso noch einige andere Ecken, an denen es klemmen wird. Ein gut geschriebener RTL-Code ist auf jede Technologie problemlos zu portieren. RTL-Code der sich auf Spezifika einer Technologie verlässt nicht. Auch wenn man bei SRAM-FPGA's bleibt kann es sehr leicht passieren das zukünftige Projekte aus Systemanforderungen heraus, die man nicht beeinflussen kann, einen Reset verwenden müssen. Das bedeutet funktionierenden code umschreiben. Also gleich alles resetten und der code kann heute, morgen und übermorgen verwendet werden.
Hallo Ottmar, deine Ansprache hat nur einen Haken: Ohne Nutzung herstellerspezifischer Feature lässt sich somanches anspruchsvolle Design gar nicht stemmen. In denen Fällen in denen es wiederum möglich ist, KÖNNEN höhere Kosten entstehen (grösseres FPGA, schnellerer Speedgrate). Beispiele: PLLs DLLs DCMs, Serdes, MGT, GTPs, DDR-IO, IO-Serialisation, ISP-Bootup and Reconfiguration,internes Monitoring (Temperatur) etc... Da hört dann die Portierbarkeit dann doch auf und der Entwickler oder gleich die ganze Company schiesst sich dann auf eine Zieltechnologie ein. Die Beispiele in denen Entwickler mal heute auf Xilinx, morgen Altera und übermorgen Atmel eingeschworen werden um in der nächsten Woche ASIC zu backen sind eher seltener bestellt... Gruß Andreas Bergmann
> Also gleich alles resetten und der code kann heute, morgen und > übermorgen verwendet werden. Ein schöner Traum, leider hat das bisher noch nie (so richtig) funktioniert: Vor gerade mal 10 Jahren gab es eine Phase, da war das synchrone Design auf FPGAs noch nicht so richtig verbreitet. Den Code von damals kann ich heute komplett in die Tonne werfen, weil das Timing auf den Bausteinen ganz anders ist. > Ein gut geschriebener RTL-Code ist auf jede Technologie problemlos zu > portieren. RTL-Code der sich auf Spezifika einer Technologie verlässt > nicht. Ich habe aber nun mal in einem FPGA Komponenten, die herstellerspezifisch sind (RAM, Controller, IO). Und spätestens da kann ich sowieso nicht mehr portieren. Ich lege mich also auf eine Technologie (und damit sehr weit auch auf einen Hersteller) fest. Und wenn der meint, Resets seien unnötig, dann sollte das schon mal einen Blick wert sein.
Ich danke allen für die Kommentare und Tipps! Ich freue mich, dass es in diesem Forum Leute gibt, die sich mit sowas gut auskennen. Anscheinend hat dieses Gebiet doch noch immer viel mit "Voodoo" zu tun, da beim Googlen doch nicht so viele nützliche Ergebnisse kommen. Dass ein Riese wie Xilinx keine vernünftige Dokumentation zu solchen Themen liefert, sogar teilweise widersprechende Empfehlungen gibt und die eigenen CPLDs in der aktuellen Dokumentation total vergisst ist ein anderes Thema. Wenn es nach Xilinx geht, sollten am liebsten wohl alle "mal eben" auf Spartan-6 und Virtex-6 umsteigen...
Hallo Andreas, genau aus diesem Grund habe ich auch von RTL-Code (der synthetisierbar ist) geredet und nicht von Technologie Instanzierungen. Hast du mein Projekt zu Projekt Beispiel gelesen? Anforderungen ändern sich auch wenn man die gleiche Technologie beibehält. Was würdet ihr von Applikations-SW Code halten der nur für Big-Endian Maschinen compilierbar/lauffähig ist? Gruß, Ottmar
Lothar Miller schrieb: > Ein schöner Traum, leider hat das bisher noch nie (so richtig) > funktioniert: Vor gerade mal 10 Jahren gab es eine Phase, da war das > synchrone Design auf FPGAs noch nicht so richtig verbreitet. Den Code > von damals kann ich heute komplett in die Tonne werfen, weil das Timing > auf den Bausteinen ganz anders ist. Ich hoffe du musst dich im jahr 2020 nicht über deinen reset freien code beschweren. Nur weil es jetzt so praktisch ist den reset wegzulassen. Das seiner Zeit praktizierte Asynchrone Design war für die Designer bestimmt auch sehr praktisch.
Ottmar schrieb: > Ich hoffe du musst dich im jahr 2020 nicht über deinen reset freien code > beschweren. Nur weil es jetzt so praktisch ist den reset wegzulassen. Allein die Hoffnung trägt uns weiter... ;-)
Hallo Ottmar, >genau aus diesem Grund habe ich auch von RTL-Code (der synthetisierbar ist) geredet und nicht von Technologie Instanzierungen. Nur,dass man sich mit seinem Design meist zwischen technologie abhängigen Bereichen bewegt. Wenn ich wiederum technologie unabhängige IP beschreibe, so geschieht dies meist ausserhalb eines konkreten Projektes. Mehrere Kunden (und nicht Projekte) im Hinterkopf. Aber auch hier können ggfls. technologieabhängige Optimierungen notwendig werden... Wenn es darum geht ein konktretes Projekt zum Fliegen zu bekommen, dann kann es z.B. sehr wohl einen Unterschied machen, ob Du z.B. ein Schieberegister mit einem Reset versorgst ( womit sich das Ding dann in einzelne Register zerlegt zerlegt wird) oder aber in einer einzigen LUT abgebildet werden kann. Ähnliche Beispiele welche sich z.B. direkt auf die Targetspeed auswirken gibt es viele. Deshalb ist bei mir der Ansatz, wenn ich keinen Reset benötige, dann modelliere ich den auch nicht. >Was würdet ihr von Applikations-SW Code halten der nur für Big-Endian Maschinen compilierbar/lauffähig ist? Hatten wir das nicht, bevor Apple auf Intelhardware umgestiegen ist? Hat eigentlich keinen gestört... Aber Scherz beiseite, auf Devicetreiberebene haben wir das Spielchen immer wieder mit der Endianess. Aber um dem Softwareentwickler zu helfen, können wir auf der FPGA Seite ja unseren Code so schreiben das wir die Endianess umschalten oder gar parallel halten können. Insoweit haben wir da ja dann auch "Portierbaren" Code...
Ich finde den expliziten Reset eigentlich recht praktisch. Die Zuweisung ist genau in dem Prozess, der das Signal treibt und nicht ein paar/viele Bildschirmseiten vorher. Man kann auch in der Testbench verschiedene Durchgänge "mit Aufwachen nach Reset" in einem Rutsch fahren, geht mit dem Init bei der Deklaration ja nicht. Und das mit den Resetnetzwerken wird eh überwertet. So gut wie keines meiner FPGAs hat einen Reseteingang. Im Toplevel wird das Resetsignal für alle Instanzen einfach auf 0 gesetzt. Damit gibt es kein Resetnetzwerk, die Synthese bekommt durch die "if reset...elsif risingedge"-Schablone aber aber mit, welche Initwerte ich will. > Vor gerade mal 10 Jahren gab es eine Phase, da war das > synchrone Design auf FPGAs noch nicht so richtig verbreitet. Echt? '93 mit Viewlogic-Schematic-Entry und meinem ersten XC3064 habe ich noch asynchron/TTL-Like rumgepfuscht. '96 mit Synopsys-VHDL und XC4010E war schon alles voll synchron...
Wenn ich das richtig sehe soll man auf einen Reset verzichten und lieber alles beim Starup initialisieren. Somit hat man einen definierten Ausgangszustand nach dem Laden des Programms in den FPGA. Jetzt möchte ich aber nicht das mein Programm gleich startet. Wenn ich dann einen Befehl von meiner PC-Software über eine Schnittstelle an den FPGA sende, dann soll das Programm starten. Bis jetzt habe ich das immer mit einem Reset gelöst. Jetzt denke ich da eher an einen CHIP_EN-Leitung. Jedoch bringt das wirklich den entscheidenen Vorteil gegenüber einer globalen Reset-Leitung. Das FANOUT ist sicherlich bei beiden Varianten genauso groß.
> Jetzt möchte ich aber nicht das mein Programm gleich startet. Wenn ich > dann einen Befehl von meiner PC-Software über eine Schnittstelle an den > FPGA sende, dann soll das Programm starten. Um disen Befehl zu empfangen muß dein FPGA aber doch schon rennen... :-o > Jetzt möchte ich aber nicht das mein Programm gleich startet. Dazu gibt es in der entsprechenden State-Machine dann üblicherweise einen IDLE-Zustand. >> '96 mit Synopsys-VHDL und XC4010E war schon alles voll synchron... Aber nicht bei Allen :-( Wir wollten da in 2005 mal einen fertigen Prozessor-IP kaufen, und bekamen dann ein Angebot für eine Neuentwicklung. Zusammen mit der Anmerkung, dass das "alte" Design (erstellt im Jahr 2000) nicht portierbar (weil teilweise asynchron) sei...
Wer mit einer State-Machine arbeitet hat in meinen Augen eh schon verloren. Außerdem muß beim FPGA alles im Reset-Modus sein bis auf das Interface, das benötigt wird um das FPGA-Programm zu starten.
Martin schrieb: > Wer mit einer State-Machine arbeitet hat in meinen Augen eh schon > verloren. aha ...
Welches Programm? Und warum muss der Rest im ASYNCHRONEN Reset sein? Da gibt doch gar keinen Grund dafür.
Martin schrieb:
> Wer mit einer State-Machine arbeitet hat in meinen Augen eh verloren.
Wie nennst du die Dinger? Zustandsautomat?
Man bedenke: schon ein ordinärer Zähler ist eine State-Machine (nur eben
als Wolf im Schafspelz verkleidet)... :-o
Thread beobachten
Seitenaufteilung abschaltenBitte 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.