mikrocontroller.net

Forum: FPGA, VHDL & Co. Init-Werte bei Xilinx


Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Bergmann (Firma: www.collion.de) (bergy) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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... :-/

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ottmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ottmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Bergmann (Firma: www.collion.de) (bergy) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ottmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ottmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Andreas Bergmann (Firma: www.collion.de) (bergy) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Wer mit einer State-Machine arbeitet hat in meinen Augen eh schon
> verloren.

aha ...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches Programm? Und warum muss der Rest im ASYNCHRONEN Reset sein? Da 
gibt doch gar keinen Grund dafür.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.