Hallo, im Rahmen eines Seminarprojektes habe ich einen AVR Atmega128 zyklengenau implementiert (vollständiges Instruktionset) und auch einiges an Peripherie identisch nachgeschrieben. Dazu gehören zb UART, GPIO, UART. 8bit/16bit Timer. Alles ist vollständig kompatibel zum original Atmega128 (auch die Interrupts). Leider darf ich den den Core nicht veröffentlichen. Meine Frage ist jetzt ob es Interesse an der Peripherie gibt. Ich weiß nicht inwiefern die mit anderen AVR-Klonen verwendbar ist, aber wenn sie jemand gebrauchen kann, würde ich sie nach Abschluss des Projektes hochladen. Sprache ist VHDL.
Für welche FPGA-Familie (getestet) ? Für welches board ? Kannst du einen NET-Core draus machen, den man einsetzen kann? > GPIO, UART. 8bit/16bit Timer Warum darfst du die hochladen und den Core nicht?
Udo schrieb: > Für welche FPGA-Familie (getestet) ? Getestet wurde es auf einem Spartan3. Es ist aber so generisch aufgebaut, dass auch eine ASIC Synthese möglich ist (welche auch durchgeführt und simuliert wurde). > Für welches board ? Wenn es nicht als Werbung aufgefasst wird, für das hier: http://demotag.iaik.tugraz.at/index.php/DemoTag_Overview Ebenfalls von mir entwickelt. Pinbelegung lässt sich aber ohnehin per .ucf File beliebig ändern, sollte von daher nicht relevant sien. > Kannst du einen NET-Core draus machen, den man einsetzen kann? Da muss ich mich erst erkunden, vermute aber eher ein. > Warum darfst du die hochladen und den Core nicht? Weil im Core Teile eines anderen Projektes enthalten sind, welches nicht von mir stammt.
Hallo, mich würde die maximale Geschwindigkeit Deines Cores in einem Spartan-3 interessieren.
Thomas schrieb: > Hallo, > > im Rahmen eines Seminarprojektes habe ich einen AVR Atmega128 > zyklengenau implementiert (vollständiges Instruktionset) und auch > einiges an Peripherie identisch nachgeschrieben. Dazu gehören zb UART, > GPIO, UART. 8bit/16bit Timer. > Alles ist vollständig kompatibel zum original Atmega128 (auch die > Interrupts). I2C würde mich interessieren, das habe ich noch nicht.
Xenu schrieb: > Hallo, > > mich würde die maximale Geschwindigkeit Deines Cores in einem Spartan-3 > interessieren. Das Design wurde für ASIC und Größe optimiert (4500GEs benötigt der Minimal-Core), deshalb ist der kritische Pfad ziemlich lang geworden. Ohne Multiplizierer und dem IO-Mapping von den GPRs und SREG komme ich noch auf etwa 35Mhz nach dem P&R. Mit Multiplizierer und wirklich vollständiger Kompatibilität nurmehr auf 24MHz (Speedgrade -4). Also da gibt es sicher deutlich bessere Varianten. Von der Gatteranzahl in einem ASIC meine ich aber ziemlich gut aufgestellt zu sein, wenn man bedenkt, dass alleine die GPRs schon etwa 1500 GEs fressen. > I2C würde mich interessieren, das habe ich noch nicht. Das steht nicht auf meinem Plan. Aber JTAG wenn sichs noch ausgeht. Momentan hab ich noch ein Bootloader ROM was per UART auf ein RAM schreibt.
Kannst Du ein Bitfile bereitstellen, dass in das Trenzmodul passt? Dann hätte man einen plugable AVR-
Thomas schrieb: > Das Design wurde für ASIC und Größe optimiert (4500GEs benötigt der > Minimal-Core), deshalb ist der kritische Pfad ziemlich lang geworden. > Ohne Multiplizierer und dem IO-Mapping von den GPRs und SREG komme ich > noch auf etwa 35Mhz nach dem P&R. > Mit Multiplizierer und wirklich vollständiger Kompatibilität nurmehr auf > 24MHz (Speedgrade -4). Also da gibt es sicher deutlich bessere > Varianten. Von der Gatteranzahl in einem ASIC meine ich aber ziemlich > gut aufgestellt zu sein, wenn man bedenkt, dass alleine die GPRs schon > etwa 1500 GEs fressen. Klingt nicht gerade berauschend, wenn man bedenkt, das es nur ein 8-Bit-Core ist. Die ZPU rennt mit 75 MHz [1] auf einem Spartan 3 und hat 32 Bit. >> I2C würde mich interessieren, das habe ich noch nicht. Gibt's (funktionierend) bei open cores ;-) [1] http://repo.or.cz/w/zpu.git/blob_plain/HEAD:/zpu/docs/zpu_arch.html#performance
Duke Scarring schrieb: > Klingt nicht gerade berauschend, wenn man bedenkt, das es nur ein > 8-Bit-Core ist. Die ZPU rennt mit 75 MHz [1] auf einem Spartan 3 und hat > 32 Bit. Naja zeig mir einen zyklengenauen AVR der schneller ist. Natürlich kann man alleine durch Umstrukturierung und Pipelining viel herausholen, aber dann kann man Echtzeitanwendungen nicht 1:1 übernehmen. Der AVR-Core hat einige Features die sich ziemlich böse auf den kritischen Pfad auswirken. Für mein Project (RFID) zählt Größe und Kompatibilität und dafür meine ich einiges geleistet zu haben. > Kannst Du ein Bitfile bereitstellen, dass in das Trenzmodul passt? Vorraussichtlich nächste Woche bekomme ich Bescheid ob ich eine Netzliste vom Core veröffentlichen darf. Wenn das nicht geht, kann ich leider auch kein vollständiges Bitfile hochladen.
Thomas schrieb: > Naja zeig mir einen zyklengenauen AVR der schneller ist. Wenn ich zyklengenaue Sotware schreibe, hab ich irgendwas verkehrt gemacht. Für genaues Timing nutze ich eine Statemaschine im FPGA. Es mag sicher einen guten Grund für Deinen/Euren Aufwand geben. Für mich müssen Controller-Cores austauschbar bleiben. Duke
Duke Scarring schrieb: > Thomas schrieb: >> Naja zeig mir einen zyklengenauen AVR der schneller ist. > Wenn ich zyklengenaue Sotware schreibe, hab ich irgendwas verkehrt > gemacht. Noch keine Echtzeitanwendung ohne FPGA entwickelt?
Duke Scarring schrieb: > Thomas schrieb: >> Noch keine Echtzeitanwendung ohne FPGA entwickelt? > Nein. Nur mit ;-) Na den Luxus hab ich leider nicht immer :) Ist auf jedenfall sehr praktisch, wenn man solche Projekte dann auch gleich 1:1 übernehmen kann. Wenn man Zeit hat, wird man die zeitkritischen Teile, dann natürlich in Hardware gießen.
>> Mit Multiplizierer und wirklich vollständiger Kompatibilität nurmehr auf >> 24MHz (Speedgrade -4). Also da gibt es sicher deutlich bessere >> Varianten. Von der Gatteranzahl in einem ASIC meine ich aber ziemlich >> gut aufgestellt zu sein, wenn man bedenkt, dass alleine die GPRs schon >> etwa 1500 GEs fressen. > Klingt nicht gerade berauschend, wenn man bedenkt, das es nur ein > 8-Bit-Core ist. Die ZPU rennt mit 75 MHz [1] auf einem Spartan 3 und hat > 32 Bit. > Ich hätte auch 40MHz auf einen Spartan3 erwartet. Testweise hatte ich mir einen C51 angeschaut und der lief mit 45Mhz. Der hat aber für einen Befehl mehrere Takte benötigt. >>> I2C würde mich interessieren, das habe ich noch nicht. > Gibt's (funktionierend) bei open cores ;-) Ich weiss habich aber mir noch nicht angeschaut. Realtime ist nicht von der gleichen Zyklenzahl abhängig. Die Interrupts müssen nur schnell genug abgearbeitet werden.
René D. schrieb: > Realtime ist nicht von der gleichen Zyklenzahl abhängig. Die Interrupts > müssen nur schnell genug abgearbeitet werden. So pauschale Aussagen sind selten korrekt. Wenn du einen genauen Abtastzeitpunkt erreichen willst, zählt jeder Cycle. Siehe Anticollision Sequenz von ISO14443A. Da muss die Interruptlatenz genau passen, als auch die Zyklenanzahl der einzelnen Befehle. Wenn man überhaupt noch mit Interrupts arbeiten kann. In sehr kritischen Fällen ist dessen Ausführungszeit zu lange. > Welches sind denn die kritischen Pfade? Auf die Schnelle fällt mir ein: - Postincrement/-decrement Load/Pop in 2 Cycles (das Addierergebnis kann so [ohne zusätzlichem Pipelining] nicht in einem Register gepuffert werden bevor die Adresse angelegt wird) - Mapping von IO-Bus in den Datenbus (IO-Bus erlaubt asynchrones lesen) - Direktes Setzen von Bits in IO Registern und Skipbefehle auf IO Register - Memory mapping von internen Registern (GPR, SREG, SP, RAMPZ) - Decode,Execute, Store sind nicht gepipelined (Instruction fetch hingegen schon). Mit Pipelining lassen sich die originalen Ausführungszeiten von Branch- oder Skip-Instructions kaum einhalten.
Thomas schrieb: > - Postincrement/-decrement Load/Pop in 2 Cycles PREincrement-/decrement war natürlich gemeint.
Gut die Diskussion über Sinn oder Unsinn eines zyklengenauen AVRs ist vom Tisch. Ich darf auch keine Netzliste hochladen. Kann also leider nur die Peripherie anbieten.
tomb schrieb: > Kann also leider nur die Peripherie anbieten. Also: Thomas schrieb: > UART, > GPIO, UART. 8bit/16bit Timer. Vielleicht machst Du bei opencores, github oder hier [1] ein Projekt draus. Dann wird man ja sehen, was sich so ergibt... Duke [1] http://www.mikrocontroller.net/svn/list
Auf Opencores würde wohl nur ein vollständiges Projekt Sinn machen. Aber ich werde nach Abschluss der Arbeit die Files dann einfach hier, in diesem Thread, zum Download anbieten.
@Thomas Kannst Du schon abschätzen, wann das Projekt abgeschlossen ist und Du die Dateien zur Verfügung stellen würdest? Ich plane, den AVR-Core von opencores.org von ATmega103 auf ATmega8035 bzw. ATmega16 zu erweitern. Dabei wäre die UART vom ATmega128 und ggf. weitere Peripherie natürlich schon mal ein großer Schritt. BTW: Weiß jemand zufällig, ob man den geänderten AVR-Core so einfach auf einem anderen Repository (z.B. GitHub) wieder veröffentlichen kann? Das wäre zwar primär nur für mich, um die Daten zwischen verschieden Standorten austauschen zu können, aber trotzdem wären die Daten jederman zugänglich. Gruß, PataMat
PataMap schrieb: > @Thomas > > Kannst Du schon abschätzen, wann das Projekt abgeschlossen ist und Du > die Dateien zur Verfügung stellen würdest? > Gruß, > PataMat Geplant war der Abschluss in zwei Wochen. Ich kann es aber eigentlich eh gleich morgen hochladen. An der Peripherie wird sich vermutlich nichts mehr ändern. JTAG schaff ich leider nicht mehr. Ich stell dann auch mein top.vhdl zu Verfügung damit man noch sieht wie es verdrahtet wird.
tomb schrieb: > Ich kann es aber eigentlich eh > gleich morgen hochladen. Das wäre echt super. > JTAG schaff ich leider nicht mehr. JTAG ist für mich erst einmal nicht so wichtig. Mir kommt es auf die UART, genauer gesagt USART, an. Wenn mal alles im FPGA läuft, dann werde ich mir mal JTAG anschauen. Evtl. kann ich dann dazu auch noch etwas beitragen. > Ich stell dann auch mein top.vhdl zu Verfügung damit man noch sieht wie > es verdrahtet wird. Das ist eine gute Idee - spart auch wieder einiges an Arbeit. Gruß, PataMat
Anbei nun das Projekt ohne dem AVR core: http://www.file-upload.net/download-4152128/avr.zip.html Externe Clock bei UART und Timer wird allerdings (noch) nicht unterstützt. Ansonsten sollten die IO-Module alle Modi des ATmega128 unterstützen. Mit dabei auch ein kleiner Bootloader und ein Loader Programm für Linux, damit man nicht für jedes Program neu synthetisieren muss. Adressen der IO-Register lassen sich im config.vhdl ändern.
tomb schrieb: > Anbei nun das Projekt ohne dem AVR core: > http://www.file-upload.net/download-4152128/avr.zip.html Funktioniert bei mir nicht... Lad die Datei doch bitte hier im Forum hoch.
alarm schrieb: > tomb schrieb: >> Anbei nun das Projekt ohne dem AVR core: >> http://www.file-upload.net/download-4152128/avr.zip.html > Funktioniert bei mir nicht... Lad die Datei doch bitte hier im Forum > hoch. Was genau funtioniert denn nicht? Ich leg die Dateien lieber dort ab, wo ich sie schnell und einfach wieder entfernen kann.
alarm schrieb: > Funktioniert bei mir nicht... Bei mir hat's funktioniert. Man muss nur auf den kleinen Download-Button mit dem noch kleineren grünen Pfeil klicken. Die großen Download-Button führen nur auf falsche Fährten... @tomb Hab' mal grob darüber geschaut. Sieht ordentlich aus! Besonders gefällt mir schon mal die Konfiguration der Registeradressen. Die Anbindung an den AVR-Core von opencores.org halte ich auf den ersten Blick durchaus für möglich, zumal Dein Core mit weniger Signalen auszukommen scheint. Gruß, PataMat
Pat a Mat schrieb: > alarm schrieb: >> Funktioniert bei mir nicht... > > Bei mir hat's funktioniert. Man muss nur auf den kleinen Download-Button > mit dem noch kleineren grünen Pfeil klicken. Die großen Download-Button > führen nur auf falsche Fährten... Ah sorry, wegen AdBlock ist mir das noch garnicht aufgefallen. Ziemlich nervige Seite, eigentlich... > @tomb > Hab' mal grob darüber geschaut. Sieht ordentlich aus! Besonders gefällt > mir schon mal die Konfiguration der Registeradressen. Die Anbindung an > den AVR-Core von opencores.org halte ich auf den ersten Blick durchaus > für möglich, zumal Dein Core mit weniger Signalen auszukommen scheint. Danke, würde mich natürlich freuen, wenn noch jemand etwas damit anfangen kann.
@tomb Vermutlich habe ich einen kleinen Typo in der Komponente 'timer16bit.vhd' entdeckt:
1 | -- Zeile 155
|
2 | elsif addr = OCRCH_ADDR then -- OCRCH_ADDR |
3 | IO_DataOutxDO <= OCRAxDP(15 downto 8); |
Sollte es nicht besser so lauten:
1 | IO_DataOutxDO <= OCRCxDP(15 downto 8); |
Ist mir aufgefallen, weil der ATmega16 keinen TIMER3 hat ;-) BTW: Den AVR-Core von opencores.org habe ich schon über einen Wrapper eingebunden. Die Ports funktionieren damit schon mal. Jetzt bin ich an der übrigen Peripherie. Gruß PataMat
Pat a Mat schrieb: > Vermutlich habe ich einen kleinen Typo in der Komponente > 'timer16bit.vhd' entdeckt: > -- Zeile 155 > elsif addr = OCRCH_ADDR then -- OCRCH_ADDR > IO_DataOutxDO <= OCRAxDP(15 downto 8); > > Sollte es nicht besser so lauten: > IO_DataOutxDO <= OCRCxDP(15 downto 8); Danke, ja das ist wieder mal so ein typischer Copy-Paste Fehler. Freut mich, dass sich schon was verwenden lässt.
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.