Besteht Interesse an AVR-Peripherie?

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.

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?

Thomas schrieb:
> Noch keine Echtzeitanwendung ohne FPGA entwickelt?
Nein. Nur mit ;-)

Duke

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.

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.

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.

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.

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.