Hallo, ich bin noch recht neu bei den FPGA / CPLD. Angefangen habe ich mit einem Arty A7-35T Developerboard. Beim Anschauen einiger anderer FPGA-Boards ist mir aufgefallen, dass die FPGAs ihren Code eigentlich immer von einem zweiten Speicherbaustein holen und sich sozusagen beim Start jedes Mal neu konfigurieren. Trotz Recherche im Internet finde ich leider keine konkrete Antwort auf meine Frage. Ist es nicht möglich, bei einem FPGA das Programm auf dem FPGA selbst zu speichern, wie es meines Wissens nach bei den CPLDs ist? Ich entwerfe mir gerade eine kleine Steuerung und der Platz ist sehr begrenzt, daher würde ich sehr gerne auf jeden unnötigen Baustein verzichten. Viele Grüße Manuel
Hallo, ich bin jetzt nicht der große FPGA Spezialist. Meine Designs mit Altera und Xilinx sind jetzt schon ca 6 Jahre her. Soweit ich weiß gibt es keine nennenswerte FPGA mit internem Flash, wie man es von Controllern her kennt. Dia haben alle einen externen Konfigurationsspeicher. Das ist aber in der Regel nur ein serieller Flash im SO8 Gehäuse. Xilinx wollte dazumal immer ihren "Spezial" Flash. Aber ein stinknormaler ging auch, der war dann im SO8 statt SO16 und kostetet nur 1€xx statt 5€.
Das FPGA funktioniert mit LUT aus Ram Zellen. Dazu noch RAM Blöcke. (ok aber das weißt du wahrscheinlich ja selber) Wenn man dann den nicht-flüchtigen Speicher noch mit auf den Chip packt, kostet das Platz. Es gibt schon FPGA mit embedded Flash woraus die LUT geladen werden. Actel Igloo oder Intel MAX10 z.B.
Manuel schrieb: > Ist es nicht möglich, bei einem FPGA das Programm auf dem > FPGA selbst zu speichern, wie es meines Wissens nach bei den CPLDs ist? Jein. Es gibt FPGAs, die das machen. Intels MAX10 Serie bspw. Da gibt es welche mit internem ROM. Diese haben quasi das ROM intern und booten dann daraus. Lattice hat auch nicht-flüchtige FPGAs. Allerdings direkt auf Flash-Basis (XP2 Serie bspw.). Bei diesen ist die LUT direkt als Flash-Zelle ausgeführt. Dadurch müssne die gar nicht booten und sind quasi "instant on" Der Grund, warum die High-End FPGAs das nicht haben wird in der Halbleiter-Technologie vergraben sein. Flash / andere nichtflüchtige Speicher erfordern spezielle Halbleiterprozesse. Das Problem daran ist, dass diese Prozesse häufig nicht besonders gut für High-Speed Logik sind etc. Deshalb setzen die FPGA Hersteller auf Performance optimierte CMOS Prozesse und lagern das Speicherproblem auf einen separaten Chip aus. Desweiteren braucht ein ROM relativ viel Chipfläche -> Hohe Kosten, Yield-Verlust etc. Eine Möglichkeit wäre es, den FPGA und ROM auf 2 Chips zu fertigen und im Package zusammenzubonden.
Manuel schrieb: > Trotz Recherche im Internet finde ich leider keine konkrete Antwort auf > meine Frage. Der Trick am Suchen ist das Finden. > Ist es nicht möglich, bei einem FPGA das Programm auf dem > FPGA selbst zu speichern, wie es meines Wissens nach bei den CPLDs ist? Doch. Jeder Hersteller hat solche Bauteile im Portfolio. Und wenn dann noch ein OnChip-RC-Oszillator wie z.B. bei den MachXO drauf ist, dann lassen sich echte Single-Chip Designs draus machen. > dass die FPGAs ihren Code eigentlich immer von einem zweiten > Speicherbaustein holen Vergleiche mal die Fertigungsprozesse bei SRAM und Flash. Du wirst sehen, dass man entweder das eine gut kann oder das andere. Aber es wird immer ein Kompromiss sein, wenn beides auf dem selben Die ist. Aus diesem Grund sagen die FPGA-Hersteller: wir können das mit den FPGAs gut. Lass diejenigen das mit dem Speicher machen, die das mit dem Speicher gut können. M. H. schrieb: > Lattice hat auch nicht-flüchtige FPGAs. Allerdings direkt auf > Flash-Basis (XP2 Serie bspw.). Bei diesen ist die LUT direkt als > Flash-Zelle ausgeführt. Nein. Schon seit der Jahrtausendwende gibt es keine solchen FPGAs mehr. Bei den Lattice-FPGAs sizt aber jeweils eine Flash-Zelle direkt bei einer SRAM-Zelle. Siehe z.B. dort die Punkte 5 und 6: http://www.latticesemi.com/en/Support/AnswerDatabase/2/4/242 Und dort ab Seite 33: http://www.petrex-bg.com/up/down/doc/Lattice_Non-volatile_Solutions_XO_XP.ppt Und deshalb kann man auch "nur" das FPGA mit einer neuen Konfiguration laden, die ist dann nach dem nächsten Powerup vergessen. Oder man kann die neue Konfiguration ins Flash laden, dann ist sie auf dem FPGA gespeichert.
:
Bearbeitet durch Moderator
Letzten Endes sind die FPGA-Hersteller wohl nur verwöhnt. Man schaue sich mal an, was die Microcontroller Hersteller alles können. Logik, Flash, ADC/DAC. Selbst bei neuen Mikroprozessoren mit ARM Kernen ist Flash On-Chip. Wird Zeit, dass die FPGA Hersteller hier mal vorwärts kommen.
Anarchist schrieb: > Selbst bei neuen Mikroprozessoren mit ARM Kernen ist Flash On-Chip. > Wird Zeit, dass die FPGA Hersteller hier mal vorwärts kommen. Naja. Die FPGA-Hersteller sind würde ich sagen in dem Punkt einfach weiter. In den Technologien, in denen Xilinx seine Artix7 etc. herstellt willst keinen Flash machen... Anarchist schrieb: > Man schaue sich mal an, was die Microcontroller Hersteller alles können. > Logik, Flash, ADC/DAC. "Logik"... Ein Mikrocontroller ist eine mehr oder weniger komplett autogeroutete Struktur, die relativ einfach ist. Ein FPGA mit seiner katastrophalen Routing-Matrix, verteilten RAM-Blöcken, Clock distribution, die was taugen soll, etc... ist da schon eine GANZ andere Hausnummer. da steckt auch noch deutlich mehr manuelle Arbeit dahinter. Mit 'ner halbwegs aktuellen Technologie routet sich ein Cortex M4 quasi von selbst. Gib Cadence 'ne Nacht auf 'nem Server und schwupp ist das Ding platziert. ADCs und DACs sind nicht die große Hürde. In einem CMOS Prozess, der noch nicht vollkommen zum 5 nm Fin-Fet verkommen ist, lässt sich ein ADC schon noch machen. Die Chipfläche für die Kondensatorbänke, die für einen SAR gebraucht werden, benötigen allerdings einiges an Platz. Aber Xilinx hat ja auch nen ADC mit auf seinen FPGAs.
Anarchist schrieb: > Selbst bei neuen Mikroprozessoren mit ARM Kernen ist Flash On-Chip. Das, was da On-Chip ist, reicht bei FPGAs nicht mal sooo arg weit: https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf Ein 7VX1140T braucht da immerhin 385,127,680 Bits bzw. knapp 48 MByte an Configdaten. > Wird Zeit, dass die FPGA Hersteller hier mal vorwärts kommen. Die Zielgruppe ist einfach komplett anders. Und wenn in einer Telekommunikationseinheit ein paar Monster-FPGAs draufsitzen, die sowieso nur dann gebootet werden, wenn es eine neue Firmware gibt, dann lohnt es sich nicht, auf jedes FPGA noch sicheres NOR-Flash zu basteln, wenn eine Speicherkarte mit billigem NAND-Flash die Arbeit auch erledigen kann oder die Konfiguration für alle Nodes sowieso zentral gespeichert und verteilt wird.
Grundsätzlich wurde eigentlich schon alles gesagt und stimmt so weit auch. Von meiner Seite nur kleine Korrekturen oder Ergänzungen: Lothar M. schrieb: > M. H. schrieb: >> Lattice hat auch nicht-flüchtige FPGAs. Allerdings direkt auf >> Flash-Basis (XP2 Serie bspw.). Bei diesen ist die LUT direkt als >> Flash-Zelle ausgeführt. > Nein. Schon seit der Jahrtausendwende gibt es keine solchen FPGAs mehr. > Bei den Lattice-FPGAs sizt aber jeweils eine Flash-Zelle direkt bei > einer SRAM-Zelle. > Siehe z.B. dort die Punkte 5 und 6: > http://www.latticesemi.com/en/Support/AnswerDatabase/2/4/242 Sehr richtig, dass ist der non-volatile Ansatz von Lattice, SRAM FPGA mit embedded Flash Zellen. Bei Microchip (aka Microsemi/Actel) ist es immer noch so, dass die FPGAs direkt mit non-volatile Speicherzellen anstatt SRAM gebaut werden. Früher Flash (z. B. ProAsic3) und heute in 28 nm mit sogenannten SONOS Zellen (RTG4, PolarFire). Wie man auch sieht, bei Microchip ist bei 28 nm Schluss und Xilinx ist bei 7 nm... Anarchist schrieb: > Letzten Endes sind die FPGA-Hersteller wohl nur verwöhnt. > Man schaue sich mal an, was die Microcontroller Hersteller alles können. > Logik, Flash, ADC/DAC. Man muss schon vergleichbare Eisen vergleichen. Ein Beispiel von 2011 herum, da war bei TI etwa bei 200 MHz schluss mit embedded Flash, alle schnelleren brauchten externen Programmspeicher. Lothar M. schrieb: >> Wird Zeit, dass die FPGA Hersteller hier mal vorwärts kommen. > Die Zielgruppe ist einfach komplett anders. > Und wenn in einer Telekommunikationseinheit ein paar Monster-FPGAs > draufsitzen, die sowieso nur dann gebootet werden, wenn es eine neue > Firmware gibt, dann lohnt es sich nicht, auf jedes FPGA noch sicheres > NOR-Flash zu basteln, wenn eine Speicherkarte mit billigem NAND-Flash > die Arbeit auch erledigen kann oder die Konfiguration für alle Nodes > sowieso zentral gespeichert und verteilt wird. Genau, die Zielgruppe macht es hier aus. Die grossen Monster-FPGA werden ja kaum eingesetzt ohne weitere Prozessoren oder gleich x86 Server. Da brauchts keinen externen Baustein weil sie eh vom Hostsystem immer mit dem aktuellsten Bitstream versorgt werden. Andere Hersteller bauen ganz bewusst kleinere FPGAs für andere Zielmärkte und wissen, dass es da von Vorteil ist, wenn die Konfiguration intern ist. Das macht gerade Lattice interessant für Industrieanwendungen. Microchip (aka Microsemi/Actel) könnte das auch, ist aber teurer als Lattice. Microchip kommt zum Zug, wenn Strahlungsfestigkeit, Resistenz gegen Sidechannelattacken oder andere Securityaspekte Relevant werden. Entsprechend sind sie Marktdominierend in Flugzeugen, Satelliten, Geldspielautomaten etc.
Es gibt Spartan3 mit internem Flash. Das ist ganz praktisch, wenn man den Aufwand niedrig halten will für eine kleine Anwendung. Ansonsten sind Anwendungen mit FPGA oft so aufwändig, dass ein externer Flash den Kuchen nicht fett macht.
Manuel schrieb: > Trotz Recherche im Internet finde ich leider keine konkrete Antwort auf > meine Frage. Ist es nicht möglich, bei einem FPGA das Programm auf dem > FPGA selbst zu speichern, wie es meines Wissens nach bei den CPLDs ist? Dann haste scheiße recherchiert: * Spartan3-an * Max10 * pOLARFIRE
:
Bearbeitet durch Admin
So einen kleinen 8-Beiner neben dem FPGA wird die Welt ja wohl verschmerzen koennen. Bet 48 MByte wird der wohl ein bisscher groesser ausfallen. Aber der FPGA ja wohl auch. Und wenn die integrierten ADs dann auch mal eine Wurst vom Teller ziehen koennten und nicht mit 200 ksps troedeln wuerden. Das waer dann schoen.
> Wird Zeit, dass die FPGA Hersteller hier mal vorwärts kommen. es gibt (im Low-Mid-Bereich) PLDs (mache sind intern FPGAs) u. FPGAs die das drauf haben
Ferkel schrieb: > Und wenn die integrierten ADs dann auch mal eine Wurst vom Teller ziehen > koennten und nicht mit 200 ksps troedeln wuerden. > Das waer dann schoen. Reichen 6 GSPS? https://www.xilinx.com/products/silicon-devices/soc/rfsoc.html Und Intel hat was mit 64 GSPS in der Pipeline https://www.intel.com/content/www/us/en/architecture-and-technology/programmable/analog-rf-fpga.html
> Reichen 6 GSPS? > 64 GSPS Jaja, zu teuer. Ich waer ja schon mit 100 Msps zufrieden wenn die nicht gerade eine grottige Linearitaet, missing Codes und aehnliches Unbill haetten. Bei AD kostet sowas ein paar Euro. Das waere im Rahmen.
Ferkel schrieb: > Jaja, zu teuer. Ich waer ja schon mit 100 Msps zufrieden wenn > die nicht gerade eine grottige Linearitaet, missing Codes und > aehnliches Unbill haetten. > Bei AD kostet sowas ein paar Euro. Das waere im Rahmen. Hier sind wir halt beim genau gleichen Thema wie mit dem Flash: Es gibt Chip-Herstellprozesse die optimiert sind auf schnelle Digitallogik, Analogschaltungen, Flash inklusive oder Stromsparen. Es gibt nicht alles gleichzeitig gleich gut.
Christoph Z. schrieb: > > Hier sind wir halt beim genau gleichen Thema wie mit dem Flash: > Es gibt Chip-Herstellprozesse die optimiert sind auf schnelle > Digitallogik, Analogschaltungen, Flash inklusive oder Stromsparen. Es > gibt nicht alles gleichzeitig gleich gut. Naja, desalb hat Xilinx ja auch den Spartan 3AN als 'stacked Die gefertigt, sprich unter einem Chipgehaüse einen FPGA und einen Flash-Die. Hat aber wohlnicht die kalkulierte Nachfrage ergeben, so dass man es wieder einstellte.
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.