mikrocontroller.net

Forum: FPGA, VHDL & Co. vhdl-richtlinien f. synthese?


Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen.
gibt es irgendwo coding-guidelines, wie man am besten synthesefreundlich 
programmiert? insbesondere auch, welche teile mit vhdl zwar beschrieben 
werden können, welche die synthese aber einfach nicht synthetisieren 
kann, würden mich interessieren. klar, "wait for"-statements machen 
dabei keinen sinn, aber da wird es wohl noch mehr geben?
gruss, seraphe

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

Bewertung
0 lesenswert
nicht lesenswert
Some User schrieb:
> klar, "wait for"-statements machen
> dabei keinen sinn, aber da wird es wohl noch mehr geben?
Wait for geht nicht, aber einige überraschende Sachen können 
Synthesetools durchaus:
http://www.lothar-miller.de/s9y/archives/47-wait-i...

Ich habe ein paar Postulate, die das Leben einfacher machen:
Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, 
der immer auf dieselbe Flanke aktiv ist. 
Es gibt keinen (und schon gar keinen asynchronen) Reset.
Externe Signale werden über 2 Flipflops einsynchronisiert.
Jede Abweichung von diesen Regeln muß fundiert begründet werden können.

Eigentlich die beliebteste Fehlerquelle ist (neben dem dem asynchronen 
Reset) das unzureichende einsynchronisieren von externen Signalen:
http://www.lothar-miller.de/s9y/categories/35-Eins...

Für Xilinx gibts den XST User Guide, in dem synthetisierbare 
VHDL-Beschreibungen definiert sind.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Xilimx gibt es die XST User Guide, dort steht drinnen welche VHDL 
Konstrukte unterstützt werden.

Ansonsten gibt es die allgemeine Norm IEEE 1076.6, welche Konstrukte 
definiert, die ein VHDL Compiler für die RTL Umsetzung beherrschen soll.

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich VHDL für Synthese schreibe, versuche ich mich so weit wie 
möglich an folgendes zu halten:

Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops 
(natürlich nicht jedes einzelne in einem Prozess, sondern ganze 
Registerbänke). Und da bin ich ziemlich kompromisslos. Ausser vielleicht 
bei einfachen Zählern - wobei - auch da versuche ich, mich daran zu 
halten.

Der Grund ist einfach der: Ich will von jedem Flipflop wissen, warum es 
da ist. Nur so kann ich ganz sicher verhindern, dass der Synti 
irgendwelches komisches Zeug macht, das eben nicht den klassischen 
Design-Regeln entspricht. Und wenn ich irgendwo ein FF entdecke, welches 
ich nicht in voller Absicht hingepflanzt habe, weiss ich, dass ich 
irgendwo 'nen groben Schnitzer gemacht habe.

Mir wurde schon erwidert, dass das für grosse Designs nicht praktikabel 
sei. Diese Meinung teile ich nicht.

Gruäss
Simon

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon Huwyler schrieb:

> Mir wurde schon erwidert, dass das für grosse Designs nicht praktikabel
> sei. Diese Meinung teile ich nicht.

Ich bin vollständig deiner Meinung, Simon. Ich lasse mich auch bei 
großem Designs nicht davon abschrecken, wissen zu wollen, wofür 
Flipflops da sind. Es freut mich sehr, dass es auch noch andere 
Aufrechte gibt.

@Lothar: Was meinst Du genau mit: "Es gibt keinen (und schon gar keinen 
asynchronen) Reset."?

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> Es freut mich sehr, dass es auch noch andere
>
> Aufrechte gibt.

Gleichfalls! :-)

Wegen dem (asynchronen) Reset: Das ist auch ein immer mal 
wiederkehrender Streitpunkt unter VHDL Designern.

Im ASIC Design ist klar, dass jedes FF resetted werden muss. Das mach in 
FPGAs (zumindest den RAM-basierten) keinen Sinn, da die FFs ja eh 
definierte Zustände haben, nachdem das Binary geladen worden ist.

Xilinx hat einige Papers darüber geschrieben, dass asynchrone Resets in 
ihren Produkten oft sehr teuer sind, da ihre Zellen eben nicht dafür 
ausgelegt sind. Eben, weil man in einem FPGA in aller Regel kein Reset 
braucht.

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schonmal vielen dank für alle antworten! :)

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, von wegen Design-Regeln:

Bei der Namensgebung mache ich das so (das ist natürlich individuell):


Ein FF hat bei mir immer [signal] als Ausgang und [signal]_next als 
Eingang.

Also z.B.

someState
und
someState_next


In der Kombinatorik sehen dann State-Zuweisungen immer irgendwie so aus:

someState_next <= ....

Auf der Rechten Seite dürfen kene _next-Signale sein.

und im FF dann

someState <= someState_next


Wenn man strickt nach so einer Regel codet, merkt man jeweils sofort, 
wenn man gerade versucht ist, einen kombinatorischen Loop oder sonstwas 
Unheiliges zu generieren.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, ich weiß schon dass ich da päpstlicher bin als der Papst. Trotzdem 
wende ich auch bei allen meinen FPGA-Designs den ASIC-Designflow an. 
Wenn man den mal verinnerlicht hat, dann kann man gar nicht mehr anders, 
finde ich.

Aber trotzdem nochmal zum Reset. Ich weiß ja nicht, wie das bei Xilinx 
ist, aber bei Altera gibt es da eine tückische Stelle. Nach dem Laden 
der Konfiguration sind alle Flipflops 0. Wenn sich das Synthesetool aber 
entschlossen haben sollte, für ein Flipflop die inverse Funktion zu 
generieren, dann ist der Zustand des (logischen) Ausgangssignals nach 
der Konfiguration 1. Damit ist eine FSM zu Beginn möglicherweise in 
einem undefinierten Zustand. Wenn das passiert (not gate push-back), 
dann wird das zwar als Warnung gemeldet, aber liest schon alle 695 
Warnungen penibel durch? Gut, man kann diese Optimierung auch 
ausschalten, aber damit wird das Systheseergebnis schlechter. Ein 
externer Reset, natürlich einsynchroniert, ist daher meines Erachtens 
für alle FPGA-Design Pflicht.

Ich hätte jetzt angenommen, dass das bei Xilinx auch so ist, vielleicht 
kann ja einer der sehr erfahrenen Xilix-User etwas dazu sagen.

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

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> Was meinst Du genau mit:
> "Es gibt keinen (und schon gar keinen asynchronen) Reset."?
Du mußt dir grundlegend mal die Frage stellen (lassen):
Wofür brauchst du so einen Reset überhaupt? Für den Reset-Taster, um 
dein Design in einen "ordentlichen" Zustand zu bringen?

Sieh dir dazu das WP272 von Xilinx an. Im einzelnen im 
Beitrag "Xilinx und die Resets" ff.
Zusammengefasst:
FFs können bei Xilinx in 2 Modi konfiguriert werden: asynchron oder 
synchron. Und wenn ein asynchroner Reset verwendet ist, dann kostet ein 
synchroner Set (z.B. bei Zählern) zusätzliche Logik.

Speziell zum asynchronen "Generalreset", der von aussen kommt:
Das ist prinzipiell ein asynchrones Signal (das asynchronste überhaput)! 
Und asynchrone Signale gehören einsynchronisiert.
Denn: was passiert, wenn du zwar hübsch im Resetzustnad bist, dann aber 
asynchron den Reset verlässt? Ein paar FFs irgendeiner FSM sehen dann 
evtl. (abhängig von Laufzeiten im FPGA) noch einen Reset, die anderen 
legen schon mal los. Das kann böse ins Auge gehen: "Mein Design läuft 
nur jedes 2. oder 3. mal richtig an."
http://www.lothar-miller.de/s9y/archives/64-State-...

Und was sehr sehr böse ist: so ein asynchroner externer Reset reagiert 
u.U. recht eigenartig auf Störspitzen, die am Reset-Pin auftreten 
können. Wenn ein sehr kurzer Spike kommt, dann reicht dessen Dauer u.U. 
nur zum Reset von ein paar FFs, und du hast jedesmal ein anderes 
Fehlerbild.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lothar,

jetzt haben wir fast zeitgleich gepostet und reden knapp aneinander 
vorbei. Ein asynchroner Resets ist Gift, das steht fest. Aber zu deiner 
Frage:

> Du mußt dir grundlegend mal die Frage stellen (lassen):
> Wofür brauchst du so einen Reset überhaupt? Für den Reset-Taster, um
> dein Design in einen "ordentlichen" Zustand zu bringen?

1. Um Source-Level-Simulation und Gate-Level-Simulation und Reale Welt 
mit der gleichen Anfangssituation starten zu lassen.

2. Siehe Posting von vorhin (not gate push-back)

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Resets wurden hier schonmal recht ausfühlich diskutiert 
(Beitrag "Theoriefrage asynchroner Reset"). Die Xilinx-FPGAs wünschen 
sich einen synchronen Reset. Die kleinen Alteras (Cyclone) profitieren 
deutlich von einem asynchronen Reset, der aber tunlichst mit 2 FFs auf 
die Clockdomain einsynchronisiert werden sollte. Die Stratixe generieren 
für beide Varianten vergleichbare Designs.

Was die Resets (und andere Hardware-bezogene Empfehlungen) angeht, darf 
man auf keinen Fall reflexartig irgendwelche irgendwo gelesenen oder 
gelernten Dinge annehmen, sondern man muss sich mit der Zielplattform 
auseinandersetzen. Und Datenblätter/Whitepapers lesen. Und selber 
testen.
Die Aussage "Bei FPGAs muss der Reset immer xzy sein" ist definitiv 
falsch!

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

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> 1. Um Source-Level-Simulation und Gate-Level-Simulation und Reale Welt
> mit der gleichen Anfangssituation starten zu lassen.
Also eigentlich "nur" zur Entwicklung...
Das können Lattice und Xilinx zwischenzeitlich mit Defaultzuweisungen 
erledigen, weil bei SRAM-basierten FPGAs sowieso beim Startup jedes 
einzelne FF per Handschlag verabschiedet werden muß:
[vhdl]
signal b : std_logic := '1';
signal v : unsigned(7 downto 0) := x"12";
signal i : integer := 1234;
[/vdhl]

Ein Gast schrieb:
> Die Aussage
> "Bei FPGAs muss der Reset immer xzy sein" ist definitiv falsch!
Die Aussage
"Wenn kein Reset nötig ist, dann weglassen" ist aber definitiv richtig.
;-)
Und wie gesagt: gerade Anfänger denken eben nicht darüber nach, sondern 
"plappern" einfach das nach, was im Lehrbuch (des Professors) steht. Und 
das ist meist der Technologiestand von vor 10 Jahren...

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops

D.h. du trennst die Berechnung der neuen Werte auf in einen 
kombinatorischen Teil und den getakteten Prozess, der nur <=-Zuweisungen 
hat und kein if bzw. sonstige Berechnungen?

Das entspricht wohl grob der Art, die auch zB. Gaisler in seinen Codes 
(Leon) nutzt.

Ich finde den Stil jedenfalls grässlich und nur schwer lesbar. Die 
Absicht, jedes FF persönlich zu kennen, ist ja auch in Verilog 
zementiert mit den wires/registers, und da verstehe ich sie auch nicht, 
das hängt mir irgendwie zu tief an der HW. Ich nehme eine HDL doch 
deswegen, um von dem niedrigen Level etwas wegzukommen...

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

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Ich finde den Stil jedenfalls grässlich und nur schwer lesbar.
Zudem führt die 2-Prozess-Schreibweise bei Anfängern ganz gern zur 
kombinatorischen Schleife:
http://www.mikrocontroller.net/search?query=kombin...
http://www.lothar-miller.de/s9y/archives/42-Kombin...

Simon Huwyler schrieb:
> Der Grund ist einfach der: Ich will von jedem Flipflop wissen, warum es
> da ist.
Blöd nur, dass die Synthese die ganzen Dinger bei Bedarf sowieso einfach 
wegoptimiert bzw. zusammenfasst...
> Prozesse sind entweder rein kombinatorisch oder reine Flip-Flops
Von dieser Schreibweise hat VHDL seinen Ruf, eine "geschwätzige" 
Beschreibungssprache zu sein.

Georg A. schrieb:
> Ich nehme eine HDL doch deswegen, um von dem niedrigen Level
> etwas wegzukommen...
Ich auch.
Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe 
später irgendwie in LUTs und FFs abgebildet werden muß.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn schon viel über den Reset gesagt wurde, möchte ich noch einen 
Aspekt anführen. Wer eine digitale Schaltung in einer 
Hardwarebeschreibungssprache modelliert, der sollte portablen Code 
schreiben, sofern das keinen unzumutbaren Mehraufwand darstellt. Ich 
schreibe ja auch keinen Software-Algorithmus, der nur auf dem Prozessor 
XYZ läuft. Algorithmen und Modelle sollten IMHO lösgelöst von der 
ausführenden Architektur sein. Natürlich geht das nicht immer, aber man 
sollte es zumindest versuchen.Und wenn Xilinx einen Weg weiß, wie man 
Xilinx FPGA ohne Reset betreibt, dann ist das ja ganz hübsch, aber 
leider ohne Relevanz.

Für das Modell einer digitalen Schaltung heißt das aber nicht, dass ich 
mich von dem entfernen darf, was Hardware an sich ist. Zitat von Lothar: 
Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe 
später irgendwie in LUTs und FFs abgebildet werden muß. Zitat Ende. 
Zustimmung! Besser kann man das nicht sagen.

Doch nochmal zurück zum Reset: Es gibt überhaupt keinen sinnvollen 
Grund, bei einem digitalen Design den Reset-Pin wegzulassen. Unstrittig 
ist wohl, dass der Reset-Pin nicht an die asynchronen Reset-Eingänge der 
Flipflops gelegt werden darf. Das Signal am Reset-Pin muss 
einsynchronisiert und am besten noch mit einem Filter beaufschlagt 
werden, das mehrere Takte lang eine Reset-Anforderug erkennen muss, 
bevor es diese an die Flipflops des Design weitergibt. Solche Sachen 
müssen sein. Aber ein Design ohne Reset-Pin? Da läuft die Source-Level 
Simulation keine zwei Takte weit! Und vor der Implementierung steht die 
Simulation.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach meine entities auch immer mit ansychronem Reset. Der geht dann 
die ganze Hierarchie durch und wird in der Simulation auch getrieben. In 
der Synthese wird der Wert dann "oben" einfach auf 0 gesetzt, der ganze 
Resetbaum selbst fällt weg, aber die initialen Werte bleiben übrig. 
Einen echten Resetpin habe ich lustigerweise noch nie gebraucht. Keine 
Ahnung, was ich da falsch mache, allerdings mache ich nur FPGAs ;)

Ich finde den expliziten Reset im Prozess auch irgendwie schöner und 
"konzentrierter" als die Zuweisung bei der Signaldefinition, die ja 
meistens recht weit weg ist.

Soweit möglich versuche ich auch, identisch getaktete, aber eigentlich 
separate Funktionen in einer Architecture in einzelne Prozesse 
aufzusplitten, das bringt die Initialisierung noch näher an den Code 
ran.

Aber ist halt wie in anderen Sprachen auch, der eigene Codingstyle ist 
der Beste und der des anderen ist immer Mist...

Aber man könnte sich auf einen Worst-Case-Style einigen, wie man es gar 
nicht machen sollte :) Da ist IMO der Code von diversen Xilinx-IP-Cores 
auf Platz 1 der Kraut&Rüben-Hitliste. Selten sowas Unlesbares gesehen. 
Kapselung jeder Winz-Funktion in Entites mit unzähligen Generics, daraus 
tieeeefe Hierarchien, bestehend hauptsächlich aus Umverdrahtung der port 
maps, belang/inhaltslose Ewigkeitskommentare ala "Signal and Type 
Declarations". Toll, hätte ich jetzt nach dem architecture-Keyword gar 
nicht erwartet ;)

Autor: Florian V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> ... Unstrittig
> ist wohl, dass der Reset-Pin nicht an die asynchronen Reset-Eingänge der
> Flipflops gelegt werden darf. Das Signal am Reset-Pin muss
> einsynchronisiert und am besten noch mit einem Filter beaufschlagt
> werden, das mehrere Takte lang eine Reset-Anforderug erkennen muss,
> bevor es diese an die Flipflops des Design weitergibt.

Aber nach dem Filtern und einsynchronisieren darf ich das Signal an den 
asynchronen Reseteingang legen. Bei Architekturen, bei denen die 
FlipFlops neben dem synchronen Eingang (der normalerweise an der LUT 
hängt) noch einen asynchronen Eingang haben, kann ich so wertvolle 
Resourcen sparen. Hier muss das Resetsignal nicht durch die LUT und 
verbraucht keine wertvollen Eingänge derselben.
Dass es auch Architekturen gibt, bei denen das keinen Vorteil bringt, 
ist ein anderer Punkt...

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> Auch wenn schon viel über den Reset gesagt wurde, möchte ich noch einen
> Aspekt anführen. Wer eine digitale Schaltung in einer
> Hardwarebeschreibungssprache modelliert, der sollte portablen Code
> schreiben, sofern das keinen unzumutbaren Mehraufwand darstellt.

Spätestens wenn FPGA spezifische Komponenten einsetzt ist der Code nicht 
mehr portabel. In den meisten Firmen werden ohnehin nur FPGAs von einem 
Hersteller eingesetzt. Sodass es gar nicht nötig ist, dass man portablen 
Code erstellen muss.

Ich
> schreibe ja auch keinen Software-Algorithmus, der nur auf dem Prozessor
> XYZ läuft. Algorithmen und Modelle sollten IMHO lösgelöst von der
> ausführenden Architektur sein. Natürlich geht das nicht immer, aber man
> sollte es zumindest versuchen.
Warum? Es kostet nur Zeit und FPGA-Ressourcen. Vor allem setzt es 
voraus, dass man sich im Vorfeld darum kümmert, welche 
Funktionen/Eigenschaften  auf einer anderen Plattform nicht zur 
Verfügung stehen. Das ist fernab jeglicher Realität.

> Und wenn Xilinx einen Weg weiß, wie man
> Xilinx FPGA ohne Reset betreibt, dann ist das ja ganz hübsch, aber
> leider ohne Relevanz.
>
> Für das Modell einer digitalen Schaltung heißt das aber nicht, dass ich
> mich von dem entfernen darf, was Hardware an sich ist. Zitat von Lothar:
> Allerdings habe ich immer im Hinterkopf, dass alles, was ich da schreibe
> später irgendwie in LUTs und FFs abgebildet werden muß. Zitat Ende.
> Zustimmung! Besser kann man das nicht sagen.

Richtig. Ich habe mich mal hingesetzt und ein mittleres Design für einen 
Spartan3 von Signal-Initialisierungen auf ein synchrones Reset 
umgestellt. In der Art
process (clk)
begin
  if rising_edge (clk) then
    if reset = '1' then
      Initialisierungen
    else
       FSMs und alles weitere
    end if
  end if
end process

Das hatte einen deutlich höheren Logikaufwand zur Folge. Da das Reset 
als zusätzliches Signal in jede Logikfunktion mit eingeht. Wenn es 
dadurch mehr als vier Signale (Spartan3) für eine Funktion werden, ist 
eine weitere LUT notwendig.
Das Reset habe ich vom Lock der DCM abgeleitet.

>
> Doch nochmal zurück zum Reset: Es gibt überhaupt keinen sinnvollen
> Grund, bei einem digitalen Design den Reset-Pin wegzulassen.
Wozu braucht man ein Reset-*Pin*? Bei Prozessoren nur dann, wenn der 
Programmierer so doof ist und sein Programm in eine endlos-Schleife 
laufen lässt.
Wenn du also nicht in der Lage bist eine Logik zu beschreiben, die nicht 
in Endlos-Schleifen läuft, dann brauchst du ein externes Reset-Pin, 
sonst nicht.

Ich sehe ein, dass man ein Signal für einen einmaligen definierten 
Anlauf nach dem Power-Up braucht. Aber eine gutes FPGA-Design braucht 
kein externes Reset. Wer sollte das auch im normalen Betrieb betätigen?

Guten Morgen


Tom

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian V. schrieb:

> Aber nach dem Filtern und einsynchronisieren darf ich das Signal an den
> asynchronen Reseteingang legen. Bei Architekturen, bei denen die
> FlipFlops neben dem synchronen Eingang (der normalerweise an der LUT
> hängt) noch einen asynchronen Eingang haben, kann ich so wertvolle
> Resourcen sparen. Hier muss das Resetsignal nicht durch die LUT und
> verbraucht keine wertvollen Eingänge derselben.
> Dass es auch Architekturen gibt, bei denen das keinen Vorteil bringt,
> ist ein anderer Punkt..

... und er hat damit schon Recht, aber leider gibt es wieder ein Aber. 
Wenn Du die Logik mit einem asynchronen Reset modellierst und die 
verwendete FPGA-Familie keinen asynchronen Reset bietet, dann erzeugt 
der Synthesizer eine zusätzliche Schaltung am Ausgang des Flipflops, die 
das Signal bis zum nächsten Clock auf den Resetzustand hält. Das ist 
auch nicht gerade optimal.
Daher modelliere ich immer mit synchronem Reset, und nur wenn das Timing 
nicht hinhaut, dann schaue ich mir die kritischen Pfade an, ändere die 
Modellierung an wenigen Stellen ab, und schreibe das als Kommentar in 
das Modell.

Thomas Reinemann schrieb:

> Spätestens wenn FPGA spezifische Komponenten einsetzt ist der Code nicht
> mehr portabel. In den meisten Firmen werden ohnehin nur FPGAs von einem
> Hersteller eingesetzt. Sodass es gar nicht nötig ist, dass man portablen
> Code erstellen muss.

Auch das ist selbstredend korrekt. Für mich aber kein Grund, meinen Pfad 
der Tugend zu verlassen. Um jede spezifische Komponente wird bei mir ein 
Wrapper gewickelt, sodass man leicht die Komponente darin auswechseln 
kann. Alle IP-Anbieter gehen diesen Weg, ASIC-Entwickler ohnehin, und 
ich nutze diese professionelle Methode eben auch im FPGA-Design.

Von Softwerkern wird heute verlangt, dass sie ihre Algorithmen auch auf 
neuen Architekturen zum laufen bringen. Alle Welt stürzt sich derzeit 
auf Cortex. Sogar uC Hersteller mit eigenen Rechnerarchitekturen 
springen auf den Zug auf, und die Entwickler müssen folgen. Ich denke, 
das wird auch mal bei den FPGAs passieren. Es könnte die Notwendigkeit 
kommen, die geschriebenen Modelle in einer anderen FPGA-Familie zum 
laufen zu bringen, weil irgendwer irgendwas entschieden hat.

Thomas Reinemann schrieb zum architekturunabhängigen Modellieren:

> Warum? Es kostet nur Zeit und FPGA-Ressourcen. Vor allem setzt es
> voraus, dass man sich im Vorfeld darum kümmert, welche
> Funktionen/Eigenschaften  auf einer anderen Plattform nicht zur
> Verfügung stehen. Das ist fernab jeglicher Realität.

Ob ein Design jetzt 13900 oder 14000 Logikelemente braucht, ist ja nur 
dann wichtig, wenn die Anzahl verfügbarere LE genau dazwischen liegt, 
also eher selten. Und, völlig klar, man kann sich nicht vorab die 
Implementierung in allen möglichen FPGA-Familien überlegen. So weltfremd 
bin ich nicht. Aber eines gibt es immer: kombinatorische Elemente und 
Register. Das reicht.

Thomas Reinemann schrieb dann noch:
> Ich sehe ein, dass man ein Signal für einen einmaligen definierten
> Anlauf nach dem Power-Up braucht. Aber eine gutes FPGA-Design braucht
> kein externes Reset. Wer sollte das auch im normalen Betrieb betätigen?

Zustimmung! Was anderes hab ich nie behauptet.

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.