Hallo, FPGAs haben zur Konfiguration der Look Up Tables SRAM Speicher vorgesehen. Geht das aus mit DRAM? Herzlichen Dank.
Kegelstar schrieb: > Geht das aus mit DRAM? DRAMs müssen regelmäßig geschrieben werden. Das passiert automatisch mit beim Auslesen. Entweder Du hast eine Anwendung, die regelmäßig den Speicher ausliest (z.B. den Bildwiederholspeicher beim PC) oder Du aktivierst die Refresh-State-Maschine im DRAM-Controller bzw. heutzutage direkt im DRAM. Wie genau hast Du Dir vorgestellt, soll das im FPGA funktionieren? Zumal die Speicherzellen nicht in einer Ecke liegen, sondern im ganzen Chip verteilt sind... Duke
Kegelstar schrieb: > FPGAs haben zur Konfiguration der Look Up Tables SRAM Speicher > vorgesehen. > > Geht das aus mit DRAM? Geht schon, ist aber doof. Und genaugenommen ist die Darstellung oben blöde formuliert. Der SRAM ist nicht vorgesehen für die Look Up Tables, die LUT sind SRAM! Abgesehen stimmt das nicht für alle FPGA's (Antifuse).
Ford Focus schrieb: > LUT sind SRAM! Welche Funktionen werden denn üblicherweise in einer LUT gespeichert? Eher Grundfunktionen wie AND, OR mit 2 Eingängen und 4 Ausgängen bzw. bis zu 4 Eingängen mit 16 Ausgängen. (https://nandland.com/lesson-4-what-is-a-look-up-table-lut/) Also dann sind 4 bis 16 SRAM Speicher nötig pro LUT? Eine SRAM Zelle hat 6 Transistoren also 24 bis 96 Transistoren? Ford Focus schrieb: > FPGA's (Antifuse) Oh ja sogar anscheinend noch viel mehr FPGAs mit nichtflüchtigem Speicher basieren auf EEPROM-, Flash-Speicher (einige Familien von Lattice und Actel) oder AntiFuse- Technologie (Actel). Die sogenannten AntiFuse FPGAs sind nur einmalig programmierbar. Danke sehr :)
Kegelstar schrieb: > Ford Focus schrieb: >> LUT sind SRAM! > > Welche Funktionen werden denn üblicherweise in einer LUT gespeichert? > Eher Grundfunktionen wie AND, OR mit 2 Eingängen und 4 Ausgängen bzw. > bis zu 4 Eingängen mit 16 Ausgängen. Üblich ist alles. von einfach durchrouten (y = x_0) bis beliebige decodierfunktion. Uber der X7 und X8 Multiplexer kann man auch noch LUT#s zu Funktionen größrerm Fanon zusammenfassen. > Also dann sind 4 bis 16 SRAM Speicher nötig pro LUT? Zellen! Die weniger blöde Formulierung lautet SRAM-Zellen nicht -spreicher und eine Vierer-lut hat 2 hoch 4 (=16) Speicher-Zellen, eine 6er LUT 64 (2 hoch 6) Vor Jahrezehntenwar eine sogenannte 6T-Zelle üblich, also 6 Transistoren für ein bit, wohl die klassische Schaltungen eines bistabilen Multivibrators in CMOS-Technik. Ob das heute noch so fabriziert wird, ist mir unbekannt. > Eine SRAM Zelle hat 6 Transistoren also 24 bis 96 Transistoren? So berechnet man die Untergrenze (korrekt mit 16 und 64). Allgemein gibt man das Transisterverhältnis FPGA:ASIC mit 10 zu 1 ein. Also für die gleiche Logikfunktion braucht man in einem FPGA ca. Zehnmal soviel Transistoren/Fläche gegenüber einem nichtkonfigurierbaern IC.
Ford Focus schrieb: > So berechnet man die Untergrenze (korrekt mit 16 und 64). gemeint sind Zellen also auch mit der anzahl der Transistoren pro Zelle multiplizieren: -> 96 resp 384 Transistoren. Diese enormen Unterschiede im Transitorcount ASIC/FPGA sieht man auch gut in Die-Fotos beim Vergleich Hardcore Blöcke (bspw. CPU-Core) und Logic-Fabric: https://slideplayer.com/slide/14466640/90/images/17/Single-Chip+Microprocessor%2FFPGA+Platforms.jpg
Was der TO vermutlich wissen möchte ist weshalb die LUT in in S und nicht DRAM ausgeführt sind, da DRAM seiner meinung nach die Transistor Anzahl pro Zelle verringern möge. Die Transistor Anzahl pro LUT ist sehr gering ~100. Wenn diese jeweils als Dram ausgeführt werde man zwar diese Zahl um einen faktor 6-7 reduzieren, erkauft sich dies aber mit enormen nachteilen (refresh logik (weit über 100Transitoren), driver etc., dazu komplexeres timing). All dieser Aufwand ist angemessen, wenn es sich um einen grossen speicher handelt (mb), LUT jedoch nicht. Und dies wäre für jede LUT nötig. Eine "steuereinheit" für alle LUT ist offensichtlich nicht möglich. -> DRAM FPGA keine gute Idee OT: SRAM Zellen sind nachwievor 6T oder gar 7T (kann bei gewissen prozessen höhere dichte erreichen als 6T)
Donald schrieb: > Eine "steuereinheit" für alle LUT ist offensichtlich nicht > möglich. -> DRAM FPGA keine gute Idee Doch, das wäre schon baubar. Und alle LUTs und Fabric Configuration Bits zusammen sind ja viele Mb. nanoXplore hat in einem SRAM FPGA z. B. eine zentrale Einheit um den geladenen Bitstream zu prüfen und zu reparieren: "Embedded configuration memory scrubbing. Fast automatic configuration memory repair. Embedded bitstream integrity check (CMIC)." Quelle: https://nanoxplore.org/index.php/product/ng-medium/ Gibt wohl noch andere Gründe. Vielleicht z. B. das trench-DRAM Prozesse (45° Flanken) zwar Transistoren können, aber die nicht so effizient und/oder gross sind im vergleich zu ebenen Prozessen. Who knows :-)
Christoph Z. schrieb: > Doch, das wäre schon baubar. Und alle LUTs und Fabric Configuration Bits > zusammen sind ja viele Mb. Sehe nicht wie dies sinnvoll möglich sein soll. Ein DRAM prozess ist zudem übethaupt nicht auf Logikdichte optimiert. Delays der Zellen um ein vielfaches höher etc. Selbst moderne CPUs welche dutzende mb an L3 Cache haben nutzen 6/7T Zellen, obwohl dies zt. einen beachtlichen Anteil der Die Fläche benötigt. 7T kann dichter sein als 6T da identische Transistoren verwendet werden können. Meine Infos basieren jedoch auf planarer technologie. Evtl. ist es mit finfets einfacher innerhalb einer Zelle unterschiedliche anzahl finnen der Transistoren zu bauen -> 6T. (die FB Transistoren müssen schwächer sein, der 7. Transistor unterbricht das FB bei 7T Zellen)
:
Bearbeitet durch User
Donald schrieb: > Christoph Z. schrieb: >> Doch, das wäre schon baubar. Und alle LUTs und Fabric Configuration Bits >> zusammen sind ja viele Mb. > > Sehe nicht wie dies sinnvoll möglich sein soll. Ich habe ja auch nicht bestritten, ob es sinnvoll wäre oder nicht. Da es nicht mal jemand versucht, wird es gute Gründe haben wieso nicht. Meine Antwort, und so hatte ich versucht dich zu zitieren, hat sich nur auf die "steuereinheit" bezogen, die in einem DRAM FPGA nötig wäre, wo du gesagt hast, sowas wäre nicht baubar. Donald schrieb: > Ein DRAM prozess ist zudem übethaupt nicht auf Logikdichte optimiert. > Delays der Zellen um ein vielfaches höher etc. Ja, das deckt sich so mit meinem Halbwissen über Chip Herstellprozesse, darum liest man ja z. B. immer nur wieder von Compute-in-Memory Architekturen und dann kommen dann doch keine Produkte (bisher).
Christoph Z. schrieb: > darum liest man ja z. B. immer nur wieder von Compute-in-Memory > Architekturen und dann kommen dann doch keine Produkte (bisher). Das liegt wohl eher nicht in der Halbleiter Herstellungs-Technologie sondern an dem dämlichen Konzept "Compute-in-Memory". Zumindest, wenn man es auf klassischen pc-Hauptspeicher o.ä. anwendet. Compute in Memroy findet im FPGA/ASIC bereich schon längst statt, die 'reverse' Bezeichnung als "Memory in Compute" trifft es dort besser. Dank den embeded Speicherblöcke (BRAM) und integrierten Caches ist der Signalweg weit optimiert. Und natürlich kann man Speicher und Logik auf einen Chip kombinieren, der yield geht dabei runter. Das musste Hitachi vor 20 Jahren an ihrem embedded Prozessoren SH4/SH5und PCI-Bridges lernen. Vielleicht liegt es an den integrierten Kondensatoren die DRAM braucht. Infineon hat da mit der Tench technologie 'löcher' in den Kristall gebohrt, die dann wohl den Metallisierungsaufbau wie man sie bei Logic-chips braicht behindert. Kann man machen, ist aber nicht 'material/platz schonend'. https://de.wikipedia.org/wiki/Grabentechnik
Ford Focus schrieb: > Und natürlich kann man Speicher und Logik auf einen Chip kombinieren, > der yield geht dabei runter. Das ist für mich der Hauptaspekt! FPGAs bestehen überwiegend aus technisch und logisch gut optimierter Halbleiter-Schaltungstechnik, die sich vorwiegend in den Switches und Interconnections widerspiegelt. HL-Prozesse für Speicher sind von anderer Gestalt und haben andere Randbedingungen, daher ist das immer ein Problem, das unter einen Hut zu bringen. Man sieht ja, die Verrenkungen die es braucht um überhaupt Block-RAMs und / oder MRAM auf einen Chip zu bekommen, von DDR-Architekturen ganz zu schweigen. Daher gibt es ja FPGAs die in einem Gehäuse ihren DDR-Speicher an board haben (HBM). Für die Config gilt Dasselbe: Für DRAM basierte Speicher braucht es einen refresher, der erst einmal auf den Chip müsste, Platz, Geld und Strom frisst, nur um schnelle SRAM-Zellen durch noch schnellere DRAM-Zellen zu ersetzen, die aber gar nicht schnell sein müssen, weil sie keiner ändern will, zumindest nicht schnell. Daher ist DRAM immer getrennt von der FPGA-Technologie, maximal der Controller ist mit verbaut. Soweit es Config-RAM ist, macht es mehr Sinn ein NVM im FPGA-Gehäuse zu integrieren. Ich bin auch nicht sicher, ob es technisch nicht ein Rückschritt wäre, die SRAM-Config durch DRAM zu ersetzen, weil ich mir vorstellen kann, dass letzteres instabiler sein dürfte.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.