Ein Prozessor muss ca. 1000 Bit Konfigurationsinformation in ein FPGA senden, wobei die Bits auf viele Komponenten im FPGA verteilt werden. Ich habe 2 Möglichkeiten: - Bitweise in ein Schieberegister takten - Über ein 16 Bit Memory Interface in Register schreiben Was ist die Resourcenschonendere Methode (Geschwindigkeit ist nebensächlich)
Michael S1. schrieb: > Was ist die Resourcenschonendere Methode Definiere "ressourcenschonend" Platz und Kupfer auf der Leiterplatte ist eine Ressource ebenso wie Speicherbedarf im konfigurierenden Prozessor und natürlich auch der Platzbedarf im FPGA. > wobei die Bits auf viele Komponenten im FPGA verteilt werden. Was tun die da? Musst du die Konfiguration partiell ändern, z.B. während der Laufzeit nur 1 Bit? Oder kannst du sicherstellen, dass während des Konfigurationsvorganges auf dem FPGA "nichts läuft"?
Michael S1. schrieb: > Ein Prozessor muss ca. 1000 Bit Konfigurationsinformation in ein FPGA > senden, wobei die Bits auf viele Komponenten im FPGA verteilt werden. > > Ich habe 2 Möglichkeiten: > - Bitweise in ein Schieberegister takten > - Über ein 16 Bit Memory Interface in Register schreiben > > Was ist die Resourcenschonendere Methode (Geschwindigkeit ist > nebensächlich) Der Verbrauch an FF sollte nahezu gleich sein (ca 1000) beim memory Interface werden noch ca 26 FF für die Bufferung desMem -IF hinzukommen (sollten IO-FF sein). Kombinatorik (LUTs) benötigt das Shiftregister kaum, für des Mem Interface brauchts einiges an adress decoding. An routing benötigt das Mem-IF einiges was quer über den FPGA gehen muß, das Shiftregistes sollte mit lokalen routingresourcen ausreichend versorgt sein. LUT's und FF sind in slices gruppiert. bei nahezu gleicher Anzahl von FF spart der Unterschid an LUT keine slices, der resourcenbedarf dürfte sich also kaum unterscheiden. Die Shift Variante dürfte höher takten, für debugging (ausprobieren unterschiedlicher Konfigs) ist natürlich der fein granulare Zugriff (16 bit statt 1000 bit) durch das MEM-If besser. Ein deutlicher Unterschied ist an der Zahl der benötigten Pins auszumachen: Ca. 2 gegen Ca. 26, das kann die Ausschussrate bei der Produktion beeinflußen, ist aber erst bei Hohen Stückzahlen signifikant. IMHO ist die Präferenz eines Lösung eher Geschmackssache als durch den Resourcenbedarf determiniert. MfG,
Karl Könner schrieb: > Der Verbrauch an FF sollte nahezu gleich sein (ca 1000) Nur wenn man es komplett als FF ausführt, was bei Ressourcenschonung sehr suboptimal ist. Da Geschwindigkeit nicht interessiert: - serielle Verbindung, 24-32 Bit als Paket - darin 16 Bit Daten, x Bit Adresse + 0-x Bit Steuerinformation beim Empfang aufteilen über Adresse an verschiedene Speicherbereiche, die entweder als FF, Distrubuted- oder Blockram ausgeführt sind. Vorteile: - geringer Ressourcenverbrauch - generisch zu schreiben (leicht pflegbar, wartbar) - gut erweiterbar Ich gehe einfach mal davon aus das du nicht alle 1000 Bit in einem Takt parallel brauchst, falls doch stimmt was Kollege Könner schreibt.
Schau doch wie's die anderen machen: Konfigurations-Daten werden in den meisten Fällen seriell in irgendwelche Chips geschrieben resp. Status-Daten seriell ausgelesen. Der Resourcenverbrauch auf dem Device ist (wie weiter oben schon erörtert) ähnlich und Du brauchst nur 2 (I2C), 4 (SPI) oder 3 Leitungen (SPI ohne MISO/Rückkanal) auf dem Board.
Erst mal danke für Eure Antworten. Hier noch ein paar Infos, die ich gleich hätte geben sollen: - Parameter werden nur in der Initialisierungsphase gesendet, dann gibt ein Startsignal die Komponenten, die Parameter benötigen frei. - Ein 16 Bit Memory Interface ist ohnehin schon da. Darüber werden Im laufenden Betrieb Daten mit ca. 10MByte/s gelesen. - Resourcenschonend bedeutet für mich: Möglichst wenige FPGA Resourcen und wohl auch möglichst einfache interne Verdrahtung für den Synthesizer. Deshalb dachte ich das Schieberegister wäre vielleicht besser. Zusatzfrage: könnte es Probleme mit der Verteilung des Schiebetakts über 1000 Bit geben?
Michael S1. schrieb: > Zusatzfrage: könnte es Probleme mit der Verteilung des Schiebetakts über > 1000 Bit geben? Nein. An so ein Taktnetz kann man viel mehr als 1000 FFs anschliessen...
Prinzipiell hätte ich auch die Variante mit dem Schieberegister vorgeschlagen, aber... Michael S1. schrieb: > - Ein 16 Bit Memory Interface ist ohnehin schon da. Dann würde ich dieses nehmen. Resourcenverbauch hin- oder her. Für den Anwender/Programmierer auf der anderen Seite der Schnittstelle, dürfte es einfacher sein ein schon vorhandenes Interface zu nutzen. Duke
Es ist jetzt über den 16 bit bus realisiert. Danke allerseits nochmal.
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.