Hallo, guten Tag. Wenn ich so einen Speicherbereich anlege für meinem DE1 mit VHDL, wo werden eigentlich die Daten im DE1 gespeichert? SRAM, SDRAM oder Flash ? Danke. Gruss ---------------------------------- signal sram8_32768 : mem8(32768 downto 0); ---------------------------------
:
Bearbeitet durch User
Wenn du mit VHDL ein Array erzeugst und dann daraus einen Speicher baust, also ein Array von Arrays, dann ist das immer intern im FPGA. Jedes Bit braucht dann ein FlipFlop. Was genau mem8 bei dir hier oben für ein Datentyp ist, weiß ich nicht.
Ich möchte das als Byte. Was heißt bitte "intern im FPGA"? Irgendwo muß doch der Speicherbereich geklaut werden. Wann weiß ich denn das dieser Speicher im FPGA erschöpft ist bzw von wo kann ich den Verbrauch runterrechnen? Danke. Gruss
Intern heißt intern. Ein FPGA ist kein Microcontroller. Wenn du ein Array mit 32768 * 8 Bit anlegst und verschaltest, wird der Synthesizer erst mal 262144 FlipFlops dafür nehmen müssen. Es gibt je nach Hersteller verschiedene Sprachkonstrukte, sowas auf den BRAM abbilden zu lassen, bei Xilinx muss dafür die Leseadresse getaktet werden. Ist bei Altera sicherlich auch so. Dann wird der BRAM des FPGA (falls vorhanden) genutzt. Die Auslastung siehst du in den Tools nach der Synthese bzw. nach dem Routing. Denk immer dran. Mit VHDL beschreibst du lediglich einen Schaltplan in Textform. Nicht mehr und nicht weniger. Wenn du den SRAM oder SDRAM oder Flash benutzen willst, brauchst du dafür einen Controller. http://www.lothar-miller.de/s9y/categories/20-RAMFIFO
:
Bearbeitet durch User
Jup danke. Andere Denkweise.... Danke. Gruss
Peter Bierbach schrieb: > > Andere Denkweise.... > Und deswegen weissen Lothar und andere immier wieder darauf hin, dass VHDL keine Programmiersprache ist. Dass man damit Dateien erzeugt mit denen man dann einen FPGA bzw CPLD "programmiert" spielt dabei keine Rolle. Es ist jederzeit möglich einen Synthesizer zu bauen basierend auf 74er Bausteinen einen Schaltplan aus der VHDL Beschreibung erstellt, auch im Eagle,Altium etc Format. (Vielleicht hat sich das ja schon jemand angetan) Das Handbuch um Cyclone II gibt es hier: www.altera.com/literature/hb/cyc2/cyc2_cii5v1.pdf
Lattice User schrieb: > Es ist jederzeit möglich einen Synthesizer zu bauen basierend auf 74er > Bausteinen einen Schaltplan aus der VHDL Beschreibung erstellt Auf jeden Fall besser als andersrum: Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"
Ich möchte hier keinesfalls eine Grundsatzdiskussion entfachen, aber angesichts der Unbedarftheit von Neuforennutzer Bierbach muss ich doch etwas einwerfen: Christian R. schrieb: > Denk immer dran. Mit VHDL beschreibst du lediglich einen Schaltplan in > Textform. Nicht mehr und nicht weniger. Das stimmt so nicht, wenn Du genauer nachdenkst. Einige VHDL-Befehle becheiben zwar Hardwarestrukuren, einige aber auch Softwarestukturen, also die Funktion einer Hardware. Und es ist wirklich die Funktion, ohne genaue Vorgaben. Das RAM ist doch das Beste Beispiel: Je nach Grösse werden es am Ende ein ROM-Tabellen, also ein LUT-GRAB, ein FF-Array oder eben ein echtes BlockRAM. Beschrieben wurde es nur als Kombinatorik mit einem Takt, fertig. Lattice User schrieb: > Und deswegen weissen Lothar und andere immier wieder darauf hin, dass > VHDL keine Programmiersprache ist. Wofür kein Anlass besteht, wenn man sich von der Vorstellung verabschiedet, dass "Programmieren" unbedingt etwas mit realen Prozessen zu tun haben muss, die auf realen Controllern laufen. Wir sind längst viel weiter und programmieren virtuelle Prozesse auf virtuellen Maschinen. > Dass man damit Dateien erzeugt mit > denen man dann einen FPGA bzw CPLD "programmiert" spielt dabei keine > Rolle. Das ist richtig, aber kein Wiederspruch zum Programmieren und damit kein Anlass, es nicht so zu nennen. Die Programmierung, die der VHDL-Entwickler vornimmt, bezieht sich nämlich nicht (oder nicht allein) auf den FPGA, sondern auf einen Software. VHDL ist ein Sript, das eine Software steuert, nämlich die Synthesesoftware. Wenn man so denkt, dann wird auch einem Neuling klar, dass nur deshalb, weil man in diesem Script solche Sachen wie Schleifen und Spreicher = Variablen benutzt, noch lange keine Speicher im FPGA entstehen müssen und schon gar keine Schleifen, die dann hinterher ausgeführt werden müssen.
Thomas Ulrich schrieb: > Einige VHDL-Befehle > becheiben zwar Hardwarestrukuren Genau, einige wenige. Vielleicht 5% von VHDL. Und eben nur diese einige wenige lassen sich synthetisieren. Ich bleibe dabei, VHDL ist texturierter Schaltplan. Klar kann man da vieles eleganter machen als mit Schaltplänen, aber es ist was grundsätzlich anderes als eine Programmiersprache in der man den sequenziellen Ablauf durch das sequenzielle Aufschreiben der Befehle erreicht. Du hast die Antwort ja selber gegeben: ROM, RAM, LUT usw kann entstehen, das sind aber alles Hardware-Elemente, keine Software. Die Abkürzung HDL ist da ausnahmsweise mal präzise passend.
Christian R. schrieb: > Genau, einige wenige. Vielleicht 5% von VHDL. Und eben nur diese einige > wenige lassen sich synthetisieren. Was für ein VHDL verwendest Du ????? Und wenn es so wäre, dann wären ja 95% Software(?) Wieviel sich synthestisieren lässt ist auch nicht der Aufhänger, wie man das, womit man es beschreibt, nennen soll. Das, was Du beschreibst, ist eine Software (VHDL), die in eine Software (Synthese) hineingegeben wird, die praktisch ein Parser ist. Du programmierst / kommandierst also eine Software. Und dabei ist es egal, ob diese Software dann ein Programmierfile rauswirf, einen C-Code, eine Hardware oder eine Mechanik. > Ich bleibe dabei, VHDL ist texturierter Schaltplan. Nein, es ist die Funktion des Schaltplans. Es ist eine Anweisungskette an einen virtuellen Schaltplandesigner. Ein Schaltplan wird nur beschrieben, wenn Du echte Logikgatter, UND, OR und soweiter ausdrücklich hinschreibst. Das ist aber vorbei. Heute wird eine Funktion beschrieben und diese dann von dem Tool in einen Schaltplan umgesetzt. Du programmierst die Funktion der Schaltung. Nicht die Schaltung. Beim Schaltplan "programmierst", malst, definierst Du tatsächlich die Verschaltung. Die Funktion wird nicht direkt beschrieben und ist nur dadurch vorhanden, dass die Funktion der Chips bekannt ist. Wohlgemerkt, ich hebe nicht darauf ab, dass EDA heute am PC passiert, also Softdaten als Gerber produziert werden etc, sondern auf das, was rauskommt: Eine Funktionsbeschreibung. Keine Strukturbeschreibung. Eine Beschreibung wie: "wait on rising_edge" ist definitiv eine Funktion. Und dies, obwohl sie synthetisierbar sit. Ob diese dann zu FFs führt oder nicht, hängt davon ab, wie das noch zusammengefasst wird. Genaugenommen, weiss Du nicht, wie die Schaltung aussieht, die Du beschreibst. Je nach LUT-grösse und Resourcen sieht die vollständig anders aus. > Programmiersprache in der man den sequenziellen Ablauf durch das > sequenzielle Aufschreiben der Befehle erreicht. 1. Du engst wieder ein, dass Programmiersprachen sequenzielle Befehle sind / zu einem sequentiellen Ablauf führen. Das hat nichts miteinander zu tun. Es gibt sequenzielle Software, die sich auf HW bezieht, z.B. Anweisung für Dehmaschinen und umgekehrt auch nicht-sequenzielle Programmiersprachen, die sich rein auf Software beziehen, wie C++. 2. Auch wenn es sequentiell / nicht sequentiell abgearbeitet wird, widerspricht dies nicht der Vorstellung der Hardwarebeschreibung, denn faktisch wird VHDL sequentiell abgearbeitet und zwar von einer Software. Diese aber interpretiert wie bei C++ die einzelnen Strukturen parallel und simuliert sie auch so. Das ist ja gerade der Grund, warum objektorientierter C++ Entwurf und VHDL so eng miteinander zusammenhängen. Bei der Synthese läuft die per VHDL programmierte Synthesesoftware daher quasiparallel ab und erzeugt die vorgeschriebenen Strukturen gemäss den Anweisungen. Was aber sind diese Anweisungsketten anderes, als ein Programm? VHDL steht auf derselben Stufe wie C++. Es hat aber eben auch die Strukturkomponenten der Hardware, also ein DSP Element oder ein ausdrücklich instanziiertes BRAM. Die werden bei der Synthese eben 1:1 an die tieferen Werkzeuge übergeben. "Hardwarebeschreibung" und "Programmierung" sind keine Gegensätze. Mit VHDL wird die Funktion einer Hardware beschrieben. Wie sie aussieht, weiss man nicht so genau. Das ist u.a. von den Constraints, der Resourcenverteilung und dem FPGA-Typ abhängig. Und: Es ist von der Softwareversion des Herstellertools abhängig!
Thomas Ulrich schrieb: > Christian R. schrieb: >> Genau, einige wenige. Vielleicht 5% von VHDL. Und eben nur diese einige >> wenige lassen sich synthetisieren. > Was für ein VHDL verwendest Du ????? > Und wenn es so wäre, dann wären ja 95% Software(?) Ja, genau. Diese 95% sind nur nutzbar in einer Softwareumgebung nähmlich dem Simulator, haben also ganz direkt nichts mit FPGA oder ASIC Entwicklung zu tun. > Wieviel sich synthestisieren lässt ist auch nicht der Aufhänger, wie man > das, womit man es beschreibt, nennen soll. Das, was Du beschreibst, ist > eine Software (VHDL), die in eine Software (Synthese) hineingegeben > wird, die praktisch ein Parser ist. Du programmierst / kommandierst also > eine Software. Und dabei ist es egal, ob diese Software dann ein > Programmierfile rauswirf, einen C-Code, eine Hardware oder eine > Mechanik. Von Standpunkt der Theoretischen Informatik (Als Fachgebiet der Mathematik) ist es egal, was hinten herauskommt, richtig. In der Praxis unterscheidet sich aber die Wahl der Tools/Sprache, das Entwicklungsvorgehen und der strukturelle Aufbau der Beschreibung massiv, je nach gewünschtem Endergebnis. Wir reden hier von Hardwarebeschreibung weil das gewünschte Ergebnis (FPGA Programmierfile, ASIC Floorplan) und der übliche Prozess am Schluss eine Hardware ist. Ob ich jetzt dazwischen 20 verschiedene Softwaretools habe, die mir meinen Source Code interpretiert, verarbeitet, optimiert und umwandelt ist egal. Thomas Ulrich schrieb: > Wir sind längst > viel weiter und programmieren virtuelle Prozesse auf virtuellen > Maschinen. Ja, eigentlich sind wir vom Denken und der Theorie her viel weiter.Ein paar Leute hier verstehen auch, was damit gemeint ist. Und jetzt erkläre mal in einfachen Worten einem Neuling der gerade erfolgreich ein paar kleine AVR Programme geschrieben hat und erfolgreich auf einem FPGA ein paar LEDs blinken lassen konnte was du damit sagen willst. Thomas Ulrich schrieb: > "Hardwarebeschreibung" und "Programmierung" sind keine Gegensätze. Mit > VHDL wird die Funktion einer Hardware beschrieben. Wie sie aussieht, > weiss man nicht so genau. Das ist u.a. von den Constraints, der > Resourcenverteilung und dem FPGA-Typ abhängig. Sehr richtig. Ich mache mal den gleichen Abschnitt für C++: Mit C++ wir die Funktion einer Software beschrieben. Wie sie aussieht, weiss man nicht so genau. Das ist u.a. vom Compiler, der Prozessorarchitektur und dem Betriebssystem abhängig.
Christoph Z. schrieb: > Wir reden hier von Hardwarebeschreibung weil das gewünschte Ergebnis > (FPGA Programmierfile, ASIC Floorplan) und der übliche Prozess am > Schluss eine Hardware ist. Ein FPGA-Programmierfile ist aber eine Software und dein (Floor)-PLAN ganz besonders. Das sind beides theoretische weiche Dinge, die man duplizieren, archivieren und mehrfach anwenden kann. Eindeutig Software. Ich sehe das auch so, dass VHDL eine Sprache ist, mit der die Erzeugersoftware eine Konfigurationssoftware erzeugt. Die Hardware ist einzig der FPGA. Es ist indirekt eine Form der Hardwareentwicklung durch Programmierung. Wo ist das Problem?
Christoph Z. schrieb: > Mit C++ wir die Funktion einer Software beschrieben. Nein, es wird die Funktion eines Systems beschrieben. Das ist ja der Unterschied zum alten C wo das noch untergeordnet vorkam. Es werden Objekte beschrieben, so, als wären sie real existent. Und zusätzlich wird das Verhalten von Objekten durch z.B. Methoden beschrieben. Und genau das macht VHDL auch. Es gibt Beschreibungen von Strukturen und Beschreibungen von Verhalten, ohne näher auf Strukturen. Welche tatsächlichen Strukturen das später werden, sucht sich der Compiler aus. Das ist sogar viel offener, als im C/C++. Eigentlich ist VHDL noch abstrakter. >Ja, genau. Diese 95% sind nur nutzbar in einer Softwareumgebung nämlich dem Simulator, Nein, sie sind eben auch in der Synthese nutzbar. Das Meiste, was mit synthesefähigem VHDL gemacht wird, ist sogar Verhaltensbeschreibung. Es sind umgekehrt 5%, die nur in der Simulation verwendet werden können. 95% der Codemasse wird später zur Hardware, aber nicht dadurch, dass sie konkret definiert wurde, sondern dadurch dass die Funktion definiert wurde, die gebraucht wird. Das meiste in VHDL sagt "baue mir was, was so und so funktioniert und stelle sicher, dass das Timing passt".
schlechtes Beispiel schrieb: > Ich sehe das auch so, dass VHDL eine Sprache ist, mit der die > Erzeugersoftware eine Konfigurationssoftware erzeugt Also doch VHPL, oder wie? Man kann natürlich zu einer VHDL Beschreibung auch mal "Code" sagen, aber es bleibt dabei: ich muss vorher wissen, ob der Synthesizer etwas auf die verfügbare Hardware abbilden kann. Und dazu mache ich mir vorher ein "Bild" meiner Hardware und beschreibe das dann mit der Beschreibungssprache VHDL.
Lothar Miller schrieb: > Man kann natürlich zu einer VHDL Beschreibung auch mal "Code" sagen, > aber es bleibt dabei: ich muss vorher wissen, ob der Synthesizer etwas > auf die verfügbare Hardware abbilden kann. Und dazu mache ich mir vorher > ein "Bild" meiner Hardware und beschreibe das dann mit der > Beschreibungssprache VHDL. sehe ich genauso und das ist kein Vergleich mit einer Hochsprache für einen uC/PC/etc.. in VHDL bedeutet nunmal, dass jede Signalzuweisung in einer rising_edge(clock) if-Anweisung in FlipFlops resultiert, und zwar in genauso viele FF, wie das Signal bzw. Vektor breit ist. Hier ist gar nichts virtuell etc. Das ist in jedem FPGA gleich. Ein Komparator sind XNOR. Etc. in FPGAs eben LUTs. Bei jeder Zeile VHDL was ich hinschreibe, habe ich im Hinterkopf, was der Synthesizer grundsätzlich versucht zu machen. Wie dann nun die boolesche Gleichung dazu aussieht ist eine Detailfrage. Die Kunst mit FPGAs zu Arbeiten ist es eben, dass man sich in die Hardware hineinversetzt und in LUTs und FFs denkt. Solange das man nicht macht, hat man keine Chance einen FPGA gut zu beschreiben. Spezielle Hardcores wie PLL, BlockRAMs, Transceiver, I/O Logik dienen meistens nur der Performance. Jeder Speicher muss nicht in BlockRAMs rein, sie können auch in FF abgebildet werden. Aber das Verhalten ist absolut identisch, sofern die Beschreibung dafür identisch ist. Mein Word zum Wochenende. Ich freue mich schon auf Woche 3 oder 4 mit Hr. Bierbach - langsam finde ich es sehr amüsant, wie wenig Ehrgeiz jmd hat bzw. wie beratungsresistent manche Leute sind. Nichts für ungut.
lulu schrieb: > in VHDL bedeutet nunmal, dass jede Signalzuweisung in einer > rising_edge(clock) if-Anweisung in FlipFlops resultiert, und zwar in > genauso viele FF, wie das Signal bzw. Vektor breit ist. Hier ist gar > nichts virtuell Noch viel extremer ist 1 komplizierte if-Abfrage, die ja z.B. für ein 32 Bit Wort u.U. 32 mal in Hardware (LUTs) gegossen wird. Und eben nicht nur 1 einziges Mal, wie das bei sequenzieller Software der Fall ist.
Lothar Miller schrieb: > Noch viel extremer ist 1 komplizierte if-Abfrage, die ja z.B. für ein 32 > Bit Wort u.U. 32 mal in Hardware (LUTs) gegossen wird. Und eben /nicht/ > nur 1 einziges Mal, wie das bei sequenzieller Software der Fall ist. Ich bezweifle hier aber ernsthaft, dass irgendjemand wirklich "vor Augen" hat, wie das aussieht, wenn er die IF-THENs zusammenbaut. Ich schon mal nicht :-)
Ich schon. Und ich seh mir das gern auch mal im RTL Schaltplan an. Genau so wie ich mir bei einem Prozessor zwischendurch mal den Assembler-Output des Compilers ansehe...
ich halte es mir bei timing-kritischen Sachen immer vor Augen. Wie sonst hat man eine Chance ein Design auf Ressourcen oder Timing zu optimieren, wenn man nicht weiß, was aus seiner eigenen Beschreibung rauskommt?! Klar ist es am Anfang schwierig bei einer Hochsprachensyntax wie VHDL oder Verilog in Gatter zu denken. Grundsätzlich ist es ja auch nicht schwer. Die ganzen Konstrukte resultieren in FF, MUX, Komparator etc. die Steuerung einer FSM ist meistens ein Konstrukt aus FF, Komparator und LUTs (zum generieren des nächsten State-Vektor), die Ausgangslogik einer FSM werden meist MUX oder kombinatorische Logik sein. Aber genau das ist der Punkt wo sich die "Programmierung" von einem FPGA mit einem uC/CPU/etc. unterscheidet!
Lothar Miller schrieb: > Ich schon. Und ich seh mir das gern auch mal im RTL Schaltplan an. Genau > so wie ich mir bei einem Prozessor zwischendurch mal den > Assembler-Output des Compilers ansehe... Lothar, RTL ist doch auch nur eine andere, theoretische Darstellung, die nicht der Realität entspricht, weil es diese Schaltplanelemente so im FPGA nicht gibt. Schon mal ein "Oder" mit 7 Eingängen gesehen? Sicher muss man wissen, dass man keine elendig langen IF-THENs verwendet sondern dazwischen enabled und registriert um mehr, als z.B. 200 MHz zu packen, aber LUTs vorausahnen? Das Timing voraussehen? Das Eizige, was man sinnvollerweise tun kann, ist, das REGs bereitzustellen, enge constraints zu setzen und das timing automatisch prüfen zu lassen. Die für das Gelingen des timings nötige Verschiebung von LUTs in günstigere Positionen muss er selber packen. Eine derartig detailreiche Optimierung ist doch garnicht mehr zu bezahlen. Dann müsste ich auch ständig post route timing-Simulationen machen. Macht man schon lange nicht mehr. Wenn es um die funktionellen Elemente im FPGA geht, sind das in erster Linie state machines, deren Verhalten schiefgehen kann und die deshalb simuliert werden müssen, ansonsten ist es das Verhalten zur Aussenwelt, weil von draussen ein bischen was anders kommt, als im Datenblatt erkennbar war. Der Rest ist schnöde Verschaltung von CoreGen Objekten und auf die habe ich eh keinen Einfluss. Was will ich da noch auf mikroskopischer Ebene optimieren indem ich es anders beschreibe? Mit VHDL wird doch bei Power-Apps (und die brauchen das gute Timing wegen des Tempos) kaum noch was anderes beschrieben, als die Verknüpfung von CoreObjekten. Das ist freilich eine Schaltung, unbestritten. Aber eine, die am Gesamtdesign mengenmässig einige %te an LUTs ausmacht im Vergleich zu den grossen Broken, die aus den Cores kommen. Wenn ich einen PLDA-PCIe einbaue, wo will ich da am timing was schrauben und LUTs nachgucken und was verbessern? Das geht alles per constraints, also das Setzen von Rahmenbedingungen. Wir zweckentfremden aber das Thema. Wenn Peter das jetzt liest, kommt er bestimmt auf die Idee, auch mal mit constraints zu spielen und einen PCIe einzubauen.
Weltbester-FPGA-Pongo schrieb: > weil es diese Schaltplanelemente so im FPGA nicht gibt. Schon mal ein > "Oder" mit 7 Eingängen gesehen? Es ist sehr wertvoll, wenn ich weiss, dass es so etwas nicht gibt. Ich würde sagen: RTL ist wie Assembler, denn auch in Assembler die dann mit genauerem Nachsehen unterschiedlich aufwendig und komplex sind. Das letzte und hardwarenächste Hilfsmittel ist dann die Technology Schematic und der Floorplaner. Weltbester-FPGA-Pongo schrieb: > Mit VHDL wird doch bei Power-Apps (und die brauchen das gute Timing > wegen des Tempos) kaum noch was anderes beschrieben, als die Verknüpfung > von CoreObjekten. Das ist freilich eine Schaltung, unbestritten. Aber > eine, die am Gesamtdesign mengenmässig einige %te an LUTs ausmacht im > Vergleich zu den grossen Broken, die aus den Cores kommen. Das ist auch eine andere Sicht der Hardware. Auf dieser Abtraktionsebene bewegen wir uns hier nicht...
Also ich hab das jetzt mal gelesen und sehe das so: VHDL beschreibt eine Funktion. Und diese wird dann auf die verfügbare Hardware abgebildet. Die Hardware ändert sich natürlich nicht, das FPGA wird ja nicht umgebaut oder so, aber wie es sich verhalt das ändert sich und lässt sich beschreiben. Auch ist VHDL nicht eindeutig, oft kann man VHDL Beschreibungen mit unterschiedlichen Schaltungen umsetzen.
Gustl Buheitel schrieb: > das FPGA wird ja nicht umgebaut oder so, aber wie es sich verhalt das > ändert sich Ich würde da gern mal das Stichwort ASIC in den Ring werfen... ;-)
Genau! ASIC und FPGA sind gleich, also beides Hardware die sich nicht ändert. Aber im FPGA kann man Schaltungen abbilden, das erlaubt diese Form der Hardware, so dass es von aussen so aussieht, als könnte man den Chip umbauen.
:
Bearbeitet durch User
Kann mir der Verantwortliche bitte die negative Bewertung erklären? Hier glaubt doch hoffentlich Niemand, dass in einem FPGA tatsächliche Hardware verändert wird, also im Sinne von physikalischen Veränderungen an dem Baustein?!
Gustl Buheitel schrieb: > Genau! ASIC und FPGA sind gleich, also beides Hardware die sich nicht > ändert. In dem Punkt sind sie gleich, nur in diesem Punkt. > Aber im FPGA kann man Schaltungen abbilden, das erlaubt diese > Form der Hardware, so dass es von aussen so aussieht, als könnte man den > Chip umbauen. In dem Punkt sind sie vordergründig nicht gleich, richtig - genau genommen aber doch, da auch im ASIC Schaltungen abgebildet werden und zwar im semi custom Etnwurf mit Standwarzellen - dies eben zur Entwurfszeit. FPGAs sind zur Laufeit programmierbar - ASICS sind zur Entwurfzeit. FPGAS sind damit sogar ähnlicher den Mikrocomputern. Und doch ist es etwas anderes. Und obendrein ist das wieder eine Untersheidung, die nicht eigentlich klarstellt, was dann eine Hardwareentwicklung ist. Denn auch ein Mikrocontroller ist "hart" und programmierbar. Es geht ja um die Benennung der Entwurfmethodik und nicht das Objekt auf das es sich irgendwann mal bezieht. Wann ist etwas Hardwareentwicklung und wann ist es Softwareentwicklung.
Ja also für mich sind alle Chips da draussen unveränderliche Hardware. FPGAs haben aber die Eigenschaft, dass deren Hardware so aufgebaut ist, dass man dort Dinge speichern kann, die die Funktionsweise (von aussen betrachtet) verändern. VHDL ist für mich natürlich Hardwarebeschreibung, klar. Man beschreibt die Funktionsweise einer Hardware. Diese wird dann übersetzt in eine Hardwareschaltung, die man auch physikalisch bauen könnte. Verwendet man dann ein FPGA wird diese Hardwareschaltung aber nicht physikalisch gebaut, sondern auf schon vorhandene Bauelemente abgebildet. Wenn man das dann in das FPGA lädt, dann wird das so konfiguriert, dass es sich so verhält wie man die Schaltung beschrieben hat. Ein Mikrocontroller ist natürlich auch nur ein ASIC. Und programmierbar. Weil der hat ein ROM und da kann man Bits speichern. Also beim FPGA ist das meist SRAM das da geladen wird und dann bestimmt welche Funktion der Stein hat. Ich möchte beides aber nicht vergleichen, weil Programme im uC etwas ganz anderes sind als abgebildete Schaltungen im FPGA. Aber es sind alles irgendwie ASICs, physikalisch ändert sich da nix, ausser der Ladung an stellen wo Bits gespeichert sind. Wie es sich nach aussen hin verhält, das kann man mit VHDL beschreiben oder beim uC programmieren. Aber angenommen man hat jetzt einen unbekannten Chip. Kann man da feststelen ob das ein FPGA, oder ein uC oder ein single-purpose-ASIC ist? Also ohne aufschleifen und so, sondern nur an Hand dessen was man an den Beinchen messen kann. Ich frage weil das was ein uC macht, kann man oft auch im FPGA machen und manchmal auch umgekehrt wenn es nicht zu schnell wird.
:
Bearbeitet durch User
Die Volksfront von Judäa sagt dazu: Nodum in scirpo quaerere.
>Die Volksfront von Judäa sagt dazu: Nodum in scirpo quaerere.
Die Juden konnten keine Lateinisch! Wenn, war das einer der Römer.
Schwanzus Logus hätte gesagt: Schuss jetzt ihr Pösen!
Au...man , ist das schön : Hier ist auch ein Kindergarten ! Dann ist ja das "Soll" welches von der Bundesregierung gefordert wurde bald erfüllt. Macht weiter so... Gruss
Das sagt der Richtige! Beitrag "FPGA reagiert nicht auf Programm, nur Rauschen auf Pins" Entschuldigung, aber das musste mal sein!
Weltbester FPGA Pongo schrieb im Beitrag #3631514: > Ich bezweifle hier aber ernsthaft, dass irgendjemand wirklich "vor > Augen" hat, wie das aussieht, wenn er die IF-THENs zusammenbaut. Hallo! Also wenn ich ein if irgendwas in VHDL hinschreibe, dann habe ich schon so ein paar Sachen im Hinterkopf: 1.) Ist in irgendwas fliegende Logik oder sind das FF-Ausgaenge 2.) 4/6 Eingaenge kann ich ohne Kosten in einer LUT abbilden, bei mehr wird's eine 2. LUT und die braucht auch noch evlt. (je nach Architektur) Verdrahtung (und die ist im FPGA richtig teuer!) Man sollte schon eine Vorstellung haben, wie das was man da so gedankenlos hinschreibt auch auf HW gemappt werden kann
Bitflüsterer schrieb: > Die Volksfront von Judäa sagt dazu: Nodum in scirpo quaerere. Vlt. eher "Romanum eunt domus"...
Gustl Buheitel schrieb: > Aber angenommen man hat jetzt einen unbekannten Chip. Kann man da > feststelen ob das ein FPGA, oder ein uC oder ein single-purpose-ASIC > ist? Also ohne aufschleifen und so, sondern nur an Hand dessen was man > an den Beinchen messen kann. Ich frage weil das was ein uC macht, kann > man oft auch im FPGA machen und manchmal auch umgekehrt wenn es nicht zu > schnell wird. So generell würde ich sagen, das kann man durch Messungen an den Pins aussen nicht herausfinden. Wie du ja richtig schreibtst, wenn dir jemand ein Pflichtenheft in die Hand drückt kannst du das oft mit allen drei Bausteinen lösen. Meistens kannst du die Antwort ganz ohne Messungen finden: Herausfinden was das Gerät alles kann, herausfinden was das Geräte gekostet hat (am besten in der Herstellung und nicht für den Endkunden), abschätzen wie viele dieser Geräte pro Jahr gebaut werden, abschätzen mit welchen Bauelementen diese Produktionskosten erreicht werden können. Die Lösung mit den tiefsten Kosten ist warscheinlich die, die du im Gerät auch findest.
:
Bearbeitet durch User
Lattice User schrieb: > Es ist jederzeit möglich einen Synthesizer zu bauen basierend auf 74er > Bausteinen einen Schaltplan aus der VHDL Beschreibung erstellt, auch im > Eagle,Altium etc Format. (Vielleicht hat sich das ja schon jemand > angetan) Umgekehrt. Ich habe einen Schaltplan genommen und statt dem einem D100D [1] folgenden Code verwendet:
1 | entity d100d is |
2 | port ( |
3 | a : in std_ulogic; |
4 | b : in std_ulogic; |
5 | y : out std_ulogic |
6 | );
|
7 | end entity; |
8 | |
9 | architecture behave of d100d is |
10 | begin
|
11 | y <= not( a and b); |
12 | end architecture; |
Thomas Ulrich schrieb: >> Ich bleibe dabei, VHDL ist texturierter Schaltplan. > Nein, es ist die Funktion des Schaltplans. Streitet Euch nicht, Ihr habt beide Recht. VHDL kann verschiedene Aspekte des Y-Diagramm abbilden [2]. Duke [1] http://www-user.tu-chemnitz.de/~heha/bastelecke/Konsumg%C3%BCter-Bastelei/DDR-Halbleiter/d100 [2] http://de.wikipedia.org/wiki/Y-Diagramm
Nein, ich lasse mich keineswegs vom Streiten abbringen. VHDL beschreibt die Funktion eines Schaltplanes und die Netzliste, also das was dann da rausfällt, das ist der Schaltplan. Nach dem P&R wird daraus dann wieder etwas das den Schaltplan auf real verfügbare Hardware abbildet. Wenn ich mit VHDL etwas beschreibe, irgendwelche 74er Steine oder so, dann wird das am Ende in LUTs abgebildet und in FFs. Also in Hardware die ich garnicht gemeint habe, aber die die Funktion besitzt.
:
Bearbeitet durch User
Immer wieder erheiternd, die Diskussion um das "Programmieren" rund um FPGAs. Ich habe zu dem Thema schon soviel geschrieben, in Foren gepostet sowie hier im Wiki und auf Wikipedia eingetragen, dass man meinen sollte, es sei langsam klar :-) Trotzdem scheint es immer noch welche zu geben, die den Umfang und Mächtigkeit von VHDL sowie die Komplexität des FPGA-Themas unterschätzen und nur Teilbereiche sehen. Die (meist alten) Hardwareleute sehen es nach wie vor oft nur als Schaltungsentwicklung und sehen immer wieder ein Schaltplantool vor Augen, während die (meist jungen) Softwareleute die Prozesse sehen und in virtuellen Landschaften denken. Beide Sichtweisen sind irgenwo richtig aber unvollständig. Auch hier in der Dikussion sieht man das wieder prächtig: Gustl Buheitel schrieb: > VHDL beschreibt die Funktion eines Schaltplanes und die Netzliste, also > das was dann da rausfällt, das ist der Schaltplan. Ja, funktionelles VHDL ist eine (reine) Funktionsbeschreibung ohne direkte Vorgaben für die Schaltung. Es gibt in VHDL aber auch Stuktur- und Objektanweisungen und die sind "hart". Und: Es gibt praktisch kein VHDL-Projekt in dem nicht beides massig vorkommt. berndl schrieb: > Hallo! Also wenn ich ein if irgendwas in VHDL hinschreibe, dann habe ich > schon so ein paar Sachen im Hinterkopf: > 1.) Ist in irgendwas fliegende Logik oder sind das FF-Ausgaenge > 2.) 4/6 Eingaenge kann ich ohne Kosten in einer LUT abbilden, bei mehr > wird's eine 2. LUT und die braucht auch noch evlt. (je nach Architektur) > Verdrahtung (und die ist im FPGA richtig teuer!) Das ist alles schon irgendwie richtig, aber wer bedenkt denn bitte die genaue LUT-Verwendung und wie will man darauf im Detail reagieren? Es ist doch im Gegenteil so, dass man VHDL verwendet, um es mal auf völlig andere Strukturen übertragen zu können, Thema ASIC wurde ja genannt. Ausserdem: Spätestens wenn man solche Synthese-Anweisungen wie "Register Balancing" und "Multiplexer Extraction" verwendet, geht jeder Zusammenhang zwischen scheinbar beschriebener und tatsächlich erzeugter Hardware komlett verloren. Kombinatorische Logik aus einer Zeitebene vor einer FF-Bank wird dann teilweise mit der hinter der FF-Bank verheiratet und zusammengekürzt. Umgekehrt werden Register eingefügt, um das funktionelle Timing zu halten, damit die Rechnungen noch stimmen. Das weiteren werden Register eingefügt und Parallelzweige aufgemacht, um das logische Timing zu halten und die Frequenzanforderung zu packen. Und das alles macht die Synthese meist sehr effektiv und zuverlässig. Gerade deshalb sollte man sich dort, wo es nicht absolut unbedingt angezeigt ist, von der Vorstellung verabschieden, die Hardware eines FPGAs bis ins letzte Detail ansehen zu wollen, um dann das optimale VHDL dafür schreiben zu können. Das ist lange vorbei. LUTs oder CLBs aussuchen und verplanen haben wir vor 20 Jahren gemacht. Lothar Miller schrieb: > Und ich seh mir das gern auch mal im RTL Schaltplan an. Freilich ist es interessant, sich das (z.b. im FPGA Editor) mal anzusehen, aber die Ergebnisse wären auch nur dort steuerbar, bzw mit den entsprechenden constraints. Mit VHDL lässt sich da prkatisch nichts machen, es sei denn, jemand setzt jede LUT und FF-location einzeln :-) Wir entfernen uns aber zu weit vom Thema. Peter Bierbach wollte ja wissen, wie die Daten in seinen FPGA kommen. Soweit das noch nicht beantwortet worden ist: Bei Altera beschreibt man am Besten kein RAM und hofft auf Erkennung desselben wie es bei Xilinx klappt, sondern setzt es ausdrücklich als Funktionsblock rein und schließt es auf unterster Ebene im VHDL an. Die Daten für das RAM können während der Programmierung des FPGA schon defaultmässig eingesetzt werden. Dazu muss man ein binary file der Daten definieren und es in den Programmierdatenstrom einbinden lassen. Mit dem Altera Megazizzard kann man das bei der Erstellung des RAMs miterledigen.
Jürgen Schuhmacher schrieb: > Bei Altera beschreibt man am Besten kein RAM und hofft auf Erkennung > desselben wie es bei Xilinx klappt Inferred RAM funktioniert bei ALTERA genauso gut wie bei Xilinx. Man kann durchaus portablen code schreiben welcher in beiden Welten ohne Anpassung dasselbe verhalten hat und die vorhandenen BRAM nutzt.
Also ich hatte da schon Fälle, wo ich kein BRAM bekommen habe sondern Register erzeugt wurden. Ist aber eine Version so um 2006 gewesen.
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.