TOP2049 programmer opensource software

[Michael B. (mb_)]

Hi,

Ich habe mir soeben einen TOP2049 programmer gekauft. Nun funktioniert 
der auch soweit einwandfrei mit der mitgeliefterten Windows Software. 
Jedoch moechte ich eine Linux (bzw plattformunabhaengige) Software 
dafuer haben. Bleibt wohl nur selbermachen. Also ran ans Werk...

Also erstmal das Ding aufgeschraubt:
Es befindet sich ein FPGA, ein Mikrocontroller und ein PDIUSBD12 im 
Geraet. Des FPGA kann man soweit ich das sehe per USB programmieren. Mit 
der Win Software werden diverse *.BIT Dateien mitgeliefert. In diesen 
Dateien befindet sich wohl der Code fuer den FPGA. Die Dateien werden 
mehr oder weniger unmodifiziert beim "Typwechsel" per USB in das Geraet 
geladen.

Soweit so gut. Aus dem USB Protokoll werde ich zwar noch nicht so ganz 
schlau, aber wir werden sehen... :)
Wenn jemand interessiert ist am Reverse Engineering mitzuarbeiten, 
stelle ich auch gerne USB Dumps zur verfuegung. Diese kann aber auch 
jeder ganz einfach selber machen mit QEMU (siehe unten).

Hat jemand vielleicht einen TOP2007 programmer und kann damit einen USB 
dump anfertigen?
Dumps mache ich mit QEMU und folgendem patch: 
http://bu3sch.de/patches/misc/qemu-usb-dump.patch

Das Projekt kann hier verfolgt werden: 
http://bu3sch.de/gitweb?p=toprammer.git;a=summary
(Derzeit noch nicht viel interessantes drin. Ein parser fuer die BIT 
files und einige USB initialisierungen...)

[Thomas R. (tinman)]

Hi,

dir ist schon klar das die .bit nur eine Seite der Medaille sind, oder ?

Die sind nur um die hardware zu configen (i/o, spannung). Der "rest" 
wird über die topwinX.exe gesteuert (wobei topwin6 endlich mit Vista/W7 
geht ohne das ich eigene windrv verwenden muss)

Die ist zwar Delphi compiled, was schon die reverse engineering 
erleichtert, denoch sind es einige algorithmen die implementiert werden 
müssen.

Den top2049 zu clonen (hardware), oder ISP port enablen, das hab ich 
schon gemacht. Auch software "leicht" angepasst (ISP funktion, CPLD 
feature enablen). Aber software neu schreiben ist schon eine sportliche 
aufgabe, alleine wegen den 2000+ devices (gut, vllt nicht "wirklich" 
2000) deren algos implementiert werden müssen ... und dann noch timings 
beachten.

[Michael B. (mb_)]

Thomas R. schrieb:
> dir ist schon klar das die .bit nur eine Seite der Medaille sind, oder ?

Natuerlich.

> feature enablen). Aber software neu schreiben ist schon eine sportliche
> aufgabe, alleine wegen den 2000+ devices (gut, vllt nicht "wirklich"
> 2000) deren algos implementiert werden müssen ... und dann noch timings
> beachten.

Ich habe nichts von 2k devices gesagt. Wenn ich meine 3-4 Geraete drin 
habe, dann reicht mir das. Warum sollte ich auch algorithmen fuer 
Geraete implementieren, die ich vermutlich niemals verwenden werde?
Ausserdem ist es opensource. Das heisst, wenn was fehlt, kann jemand 
anders das machen.

Im Moment geht es mir eigentlich nur darum das USB Protokoll 
herauszufinden.
Ich vermute, dass es ein Layer direkt um das FPGA JTAG ist. Jedoch finde 
ich keinen wirklichen Zusammenhang zwischen dem JTAG Protokoll und dem 
verwendeten USB Protokoll...

[Michael B. (mb_)]

So, mittlerweile funktioniert die Software soweit um einen AtMega8 
korrekt auszulesen.
Das Reverse-Engineering der Versorgungs- und Programmierspannungen ist 
abgeschlossen. Als naechstes kommt dann die Ansteuerung des 
programmierten FPGAs. Diese Programmteile sind momentan nur als "blobs" 
implementiert.

Um nochmal auf meine Frage vom Ausgangsposting zurueckzukommen: Wenn 
jemand einen TOP2007 hat, dann wuerde ich davon sehr gerne ein paar USB 
dumps bekommen um die grundsaetzlichen Unterschiede zwischen TOP2049 and 
TOP2007 einschaetzen zu koennen.

Danke. :)

[Thomas K. (muetze1)]

Ich habe einen TOP2007, aber ich muss nun erstmal schauen und mich mit 
dem Patch und QEMU durchwursteln. Ich werde mir das zumindest mal auf 
meine ToDo Liste setzen.

[Thomas R. (tinman)]

Michael Buesch schrieb:
> Das Reverse-Engineering der Versorgungs- und Programmierspannungen ist
> abgeschlossen. Als naechstes kommt dann die Ansteuerung des
> programmierten FPGAs. Diese Programmteile sind momentan nur als "blobs"
> implementiert.
>

nett.

> Um nochmal auf meine Frage vom Ausgangsposting zurueckzukommen: Wenn
> jemand einen TOP2007 hat, dann wuerde ich davon sehr gerne ein paar USB
> dumps bekommen um die grundsaetzlichen Unterschiede zwischen TOP2049 and
> TOP2007 einschaetzen zu koennen.
>


mein top3100 ist unterwegs seit ein paar tagen, sobald ich es habe mache 
die dumps - falls interessiert. Soll auch ganz neue hardware sein, 
allerdings grossteils noch kompatibel, naja, mal sehen was drin ist.

[Michael B. (mb_)]

Sehr schoen, ich danke euch. Fotos vom geoeffneten Geraet waeren auch 
sehr hilfreich. (Es ist sowieso ratsam es erstmal zu oeffnen und die 
Loetreste incl Zinnspritzer zu entfernen, bevor man das Geraet in 
Betrieb nimmt :) )

[Guest (Gast)]

Hi, interessantes Projekt.
In TopWin 6.20 hat sich eine Verilogdatei unter die bit files gemischt:

module pic17dip40std(d,ale,wr,rd,osc12m,pin,RXT,TXT);
    inout [7:0] d;
    input ale;
    input wr;
    input rd;
    input osc12m;
   inout [48:1] pin;
   output TXT;
   input RXT;
assign TXT=RXT || osc12m;

reg  [7:0] sel_in;
wire [15:0] cy; 
reg [7:0] addr;

always @(negedge ale)
begin
addr=d;
end
wire AlwaysLo;
assign AlwaysLo=1'b0; 
assign AlwaysLo= 1'b0;  //AlwaysLo always=0

assign cy[0]=(addr==0+16+128);
assign cy[1]=(addr==1+16+128);
assign cy[2]=(addr==2+16+128);
assign cy[3]=(addr==3+16+128);
assign cy[4]=(addr==4+16+128);
assign cy[5]=(addr==5+16+128);
assign cy[6]=(addr==6+16+128);
assign cy[7]=(addr==7+16+128);
assign cy[8]=(addr==8+16+128);
assign cy[9]=(addr==9+16+128);
assign cy[10]=(addr==10+16+128);
assign cy[11]=(addr==11+16+128);
assign cy[12]=(addr==12+16+128);
assign cy[13]=(addr==13+16+128);
assign cy[14]=(addr==14+16+128);
reg RA0,RA1,OE,en_osc;
reg [7:0] rb,rc;


/*reg [2:0] dev;
always @(posedge osc12m)
begin
dev=dev+1;
end*/
 
always @(posedge wr)
begin
    if(cy[0]) rb = d;
    if(cy[1]) rc = d;

//    if(cy[2] && d[6:0]==1) TEST=d[7];
    if(cy[2] && d[6:0]==2) RA0=d[7];
    if(cy[2] && d[6:0]==3) RA1=d[7];
    if(cy[2] && d[6:0]==4) OE=d[7];
    if(cy[2] && d[6:0]==5) en_osc=d[7];
//    if(cy[10]) sel_osc = d;
    if(cy[11]) sel_in = d;
    //--------------------------------add...
  //up active
end
wire tp;
assign tp=sel_in[5];  

bufif0 (pin[21],GND,!AlwaysLo);
bufif0 (pin[22],1'b1,tp);   //ra4 =1
bufif0 (pin[23],GND,tp);    //ra3=0
bufif0 (pin[24],GND,tp);    //ra2=0
bufif0 (pin[25],RA1,tp);
bufif0 (pin[26],RA0,tp);
bufif0 (pin[27],1'b1,tp);  //test=1
bufif0 (pin[28],GND,!AlwaysLo);
bufif0 (pin[29],GND,!AlwaysLo);
bufif0 (pin[30],GND,!AlwaysLo);
bufif0 (pin[31],GND,tp); //gnd  
bufif0 (pin[32],GND,tp);  //vpp
bufif0 (pin[33],GND,!AlwaysLo);
bufif0 (pin[34],GND,!AlwaysLo); 
bufif0 (pin[35],GND,!AlwaysLo);
bufif0 (pin[36],GND,!AlwaysLo);
bufif0 (pin[37],GND,!AlwaysLo);
bufif0 (pin[38],GND,!AlwaysLo);
bufif0 (pin[39],GND,!AlwaysLo);
bufif0 (pin[40],GND,!AlwaysLo);
bufif0 (pin[1],GND,tp); //vdd
bufif0 (pin[2],rc[0],tp|| !OE );
bufif0 (pin[3],rc[1],tp|| !OE );
bufif0 (pin[4],rc[2],tp|| !OE );
bufif0 (pin[5],rc[3],tp|| !OE );
bufif0 (pin[6],rc[4],tp|| !OE );
bufif0 (pin[7],rc[5],tp|| !OE );
bufif0 (pin[8],rc[6],tp|| !OE );
bufif0 (pin[9],rc[7],tp|| !OE );
bufif0 (pin[10],GND,tp);  //gnd
bufif0 (pin[11],rb[0],tp|| !OE);
bufif0 (pin[12],rb[1],tp|| !OE);
bufif0 (pin[13],rb[2],tp|| !OE);
bufif0 (pin[14],rb[3],tp|| !OE);
bufif0 (pin[15],rb[4],tp|| !OE);
bufif0 (pin[16],rb[5],tp|| !OE);
bufif0 (pin[17],rb[6],tp|| !OE);
bufif0 (pin[18],rb[7],tp|| !OE);
bufif0 (pin[19],ale,!en_osc);
bufif0 (pin[20],GND,!AlwaysLo);

//-------------------------------add...
reg [7:0] inpin;
always @(rd or cy or pin)
begin
    if(cy[0]) inpin=pin[18:11];
    else if(cy[1]) inpin=pin[9:2];

    else if(cy[6]) inpin=pin[8:1];
    else if(cy[7]) inpin=pin[16:9];
    else if(cy[8]) inpin=pin[24:17];
    else if(cy[9]) inpin=pin[32:25];
    else if(cy[10])inpin=pin[40:33];
end

wire chip_ce;
assign chip_ce=!rd && addr[7]; 

bufif1 (d[0],inpin[0],chip_ce);
bufif1 (d[1],inpin[1],chip_ce);
bufif1 (d[2],inpin[2],chip_ce);
bufif1 (d[3],inpin[3],chip_ce);
bufif1 (d[4],inpin[4],chip_ce);
bufif1 (d[5],inpin[5],chip_ce);
bufif1 (d[6],inpin[6],chip_ce);
bufif1 (d[7],inpin[7],chip_ce);


endmodule

Eventuell ist´s interessant...

[Michael B. (mb_)]

Guest schrieb:
> In TopWin 6.20 hat sich eine Verilogdatei unter die bit files gemischt:

Ja das habe ich schon gesehen. ;)

Ich bin auch schon dran opensource FPGA firmware zu schreiben...

[Michael B. (mb_)]

Michael Buesch schrieb:
> Guest schrieb:
>> In TopWin 6.20 hat sich eine Verilogdatei unter die bit files gemischt:
>
> Ja das habe ich schon gesehen. ;)
>
> Ich bin auch schon dran opensource FPGA firmware zu schreiben...

So, im GIT befindet sich jetzt eine opensource .bit file fuer den 
atmega8. Es ist jetzt alles mitgeliefert um den atmega8 auszulesen. 
(Schreiben noch nicht, aber das sollte kein Problem mehr darstellen).

Das Geraet ist jetzt so gut wie komplett reverse-engineered und kann mit 
"toprammer" auch fuer neue Chips (solche, die Topwin nicht unterstuetzt) 
programmiert werden.
Dazu wird ein bitfile fuer die lowlevel Teile und eine chip_*.py 
Implementation fuer die highlevel Teile des Programmieralgorithmus 
benoetigt.

Das elektrische Interface ist unter Umstaenden etwas beschraenkt (man 
kann nicht ueberall VCC und Programmierspannung anlegen). Deshalb ist je 
nach Chip evtl ein Adapter noetig. Das sollte ja aber kein Problem 
darstellen. :)

Zum Uebersetzen der Verilog sources in bitfiles nehme ich das Xilinx ISE 
9.2. Das kann man kostenlos auf der Xilinx Homepage runterladen. 
Achtung: Die neuste Version (11) unterstuetzt den FPGA nicht mehr. Es 
wird 9.2 benoetigt.

[Michael B. (mb_)]

Nun gibt es ein neues Release (0.2).

Neuerungen sind Unterstützung für mehr chips und viele kleine und grosse 
Verbesserungen.

Chipsupport derzeit:

       atmega32dip40
        atmega8dip28
       atmega88dip28
              m2764a (broken)

[Guido (Gast)]

Und mit Release 2.0 gehen die Probleme mal richtig los. Ich konnte
gerade die Funktion der Version 1 verifizieren, mit Version 2 wird
wohl weniger Wert auf Funktionalität gelegt:

"error while loading shared libraries: libXilinxPkg.so: cannot open
shared object file: No such file or directory"

Wo ist die, wozu braucht man die? Muss ich mir mein ganzes System
mit Pfadangaben o.ä. zusauen um das Programm auszuprobieren?
WebISE legt darauf keinen Wert!

Da macht noch nicht einmal das Testen Spaß.

[Michael B. (mb_)]

Guido schrieb:
> Und mit Release 2.0 gehen die Probleme mal richtig los. Ich konnte
> gerade die Funktion der Version 1 verifizieren, mit Version 2 wird
> wohl weniger Wert auf Funktionalität gelegt:
>
> "error while loading shared libraries: libXilinxPkg.so: cannot open
> shared object file: No such file or directory"

> Da macht noch nicht einmal das Testen Spaß.

Welche Laus ist dir denn über die Leber gelaufen?

Um das Tool nur mal kurz zu Testen braucht man mit Sicheheit das Xilinx 
ISE nicht zu installieren. Das wird nur benötigt, wenn man neue FPGA 
Firmware entwickeln will.

Das "toprammer" Tool an sich braucht nur Python 2.5/2.6 und PyUSB. Mehr 
nicht.

Wenn du ISE verwenden willst um neue FPGA firmware zu schreiben, dann 
musst du zuerst die environment für ISE laden. Das geht mit dem 
mitgelieferten "settings.sh" script. Einfach in bash sourcen:
. settings.sh

Einfach mal die ISE Dokumentation lesen. :)

<ironie>
Ich muss naturlich um Entschuldigung bitten, dass es sich bei dem Tool 
mit Versionsstand 0.2 noch nicht im eine voll ausgereifte Software 
handelt. </ironie>

[Guido (Gast)]

Sorry, mir ist keine Laus über die Leber gelaufen. Aber die
erste Version konnte ich noch testen, dann wollte ich mal
ein paar alte 2764 zum Test lesen, aber die neue Version
schmeißt nur noch Fehlermeldungen. Den Ise-Pack hatte ich
vorher schon am Laufen, neue Chips hebe ich mir aber für
später auf. Also:

./toprammer --help
Traceback (most recent call last):
  File "./toprammer", line 24, in <module>
    from libtoprammer.toprammer_main import *
  File "/mnt/video/lochome/guido/temp/TOP2049/toprammer-0.2/libtoprammer/toprammer_main.py", line 25, in <module>
    from bitfile import *
  File "/mnt/video/lochome/guido/temp/TOP2049/toprammer-0.2/libtoprammer/bitfile.py", line 22, in <module>
    import pkg_resources
ImportError: No module named pkg_resources

Das war der Ausgangspunkt. Dann habe ich halt versucht den Fehler
einzugrenzen.

[Michael B. (mb_)]

Guido schrieb:
> ImportError: No module named pkg_resources

apt-get install python-pkg-resources

Sollte eigentlich zu einer standard Python Installation gehören. Aber 
ich kann das auch noch in die Abhängigkeitsliste mit aufnehmen.

[Guido (Gast)]

Oops, probiere ich morgen.

Gruß, Guido

[Guido (Gast)]

So Michael, kaum hat man alle nötigen Pakete, kanns los gehen.

Es gibt noch Inkonsistenzen zw. M2764A und m2764a. Ich habe alles
auf Kleinschreibung umgestellt und kann dann das Eprom auslesen.
Mit dem Schreiben gibt es noch eine Reihe von Problemen:

Einer von uns beiden berechnet die Checksumme falsch. Ich habe die
Prüfung auskommentiert und frage mich ob die sinnvoll ist. Einige
Freewaretools erzeugen die gar nicht (setzen einfach 00), da sie
eigentlich unnötig ist.

Trotzdem geht es nicht weiter, weil ich nur 16 Bytes brennen wollte
(ich kann die EPROMs nicht mehr löschen, weil meine Lampe schon seit
vielen Jahren nicht mehr startet), toprammer dies aber nicht
zulässt. Das ist aber nicht verboten, das Programm solte alle nicht
eingelesenen Bytes auf FF setzen und beim Brennen dann FF ignorieren
(schon um Zeit zu sparen).

Ich versuche mal ein EEPROM (W27F512) einzubinden, damit kann ich
dann leichter testen.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> kann dann das Eprom auslesen.

Sehr schön. Das ist schon mal mehr als ich von dem ungetesteten Code 
erwartet habe. :)

> Einer von uns beiden berechnet die Checksumme falsch. Ich habe die
> Prüfung auskommentiert und frage mich ob die sinnvoll ist. Einige
> Freewaretools erzeugen die gar nicht (setzen einfach 00), da sie
> eigentlich unnötig ist.

Wo wird denn eine checksumme berechnet? Ich bin mir nicht bewusst sowas 
irgendwo implementiert zu haben. :)

> Trotzdem geht es nicht weiter, weil ich nur 16 Bytes brennen wollte
> (ich kann die EPROMs nicht mehr löschen, weil meine Lampe schon seit
> vielen Jahren nicht mehr startet), toprammer dies aber nicht
> zulässt.

Das ist nur eine kurze Prüfung in chip_m2764a.py.
Bei writeEEPROM() einfach die Prüfung auskommentieren.

> Das ist aber nicht verboten, das Programm solte alle nicht
> eingelesenen Bytes auf FF setzen und beim Brennen dann FF ignorieren
> (schon um Zeit zu sparen).

ja das sollte noch optimiert werden.

> Ich versuche mal ein EEPROM (W27F512) einzubinden, damit kann ich
> dann leichter testen.

Nur als Hinweis: Zur Entwicklung ist es hilfreich die GIT Version zu 
verwenden. Ich habe da einige Sachen mit den Layouts der 
Versorgungsspannungen geändert. Sollte jetzt viel einfacher und vor 
allem universeller verwendbar sein.

[Guido (Gast)]

Jo, mal wieder unvollständige Daten: Ich meine die Checksumme
beim Einlesen von Intel-Hex. Dann werde ich später mal Brennen
probieren.

[Michael B. (mb_)]

Guido schrieb:
> Jo, mal wieder unvollständige Daten: Ich meine die Checksumme
> beim Einlesen von Intel-Hex. Dann werde ich später mal Brennen
> probieren.

Achso. Ich denke, dass die Berechnung des ihex parsers aber stimmt, weil 
ich diesen Code auch noch in einem anderen Projekt erfolgreich einsetze. 
Es gibt aber, wie du schon richtig erkannt hast, keinen richtigen 
Standard und viele Tools berechnen das anders. Ich halte mich hier an 
den Wikipedia Artikel.

Ich sollte den Code ändern, damit nur noch eine Warnung ausgegeben wird, 
wenn die Checksumme nicht stimmt.

Du kannst aber auch das ihex mit einem anderen tool (objdump) nach binär 
konvertieren und das dann als Eingabedaten verwenden.

[Guido (Gast)]

Nene, das ihex-Format ist schon o.k., da man damit ja auch
die Schreibadresse übergibt. Ich rätsele gerade wie ich wohl
den Datenbuffer finde, um ihn erstmal mit 0xFF zu füllen.
Python ist für mich Neuland.

[Guido (Gast)]

So, er hat erfolgreich gebrannt. :-) Beim Einlesen des Ihex-Files
füllt er aber den Bereich vornedran mit 00 auf, unschön. Das Ende
ist dann aber korrekt und der 2764 geht zumindest teilweise (16
Bytes wurden an der korrekten Stelle gebrannt).

[Guido (Gast)]

Und jetzt kann ich einzelne Zeilen (je 16 Bytes) brennen. Ich hänge mal
meine Änderungen an, das geht sicherlich viel besser.

[Michael B. (mb_)]

Guido schrieb:
> Und jetzt kann ich einzelne Zeilen (je 16 Bytes) brennen. Ich hänge mal
> meine Änderungen an, das geht sicherlich viel besser.

Wenn du mir jetzt noch sagst was du verändert hast? Nur die Zeilen 
auskommentiert?

[Guido (Gast)]

Ich fülle erstmal "bin" auf 64 k mit 0xFF. Dann habe ich die
Fehlermeldungen die gestört haben auskommentiert. Und für
den 2764 wird write nur aufgerufen wenn das jew. Byte != 0xFF
ist.

Morgen probiere ich das mal sauberer hinzubekommen.

[Michael B. (mb_)]

Guido schrieb:
> Morgen probiere ich das mal sauberer hinzubekommen.

Nicht nötig. Ich habe das jetzt bereits alles ins GIT repository 
committed (Nicht in deiner Form, aber funktional sollte es aufs gleiche 
rauskommen).

Danke für deine Tests!

Wenn du mehr zum Projekt beitragen willst, empfehle ich dir GIT oder 
diff zu verwenden um unified diff Patches anzufertigen. Das vereinfacht 
deine und meine Arbeit dann erheblich.

[Guido (Gast)]

Hallo Michael,

Git habe ich schon installiert. Aber davon Patches anzulegen bin
ich noch weit entfernt. Ich probiere erstmal etwas rum und lerne
dabei etwas Python. Eigentlich möchte ich lieber mehr in die
Einbindung weiterer Chips investieren.

Eine Frage habe ich noch: das Auslesen des 2764 dauert gut 30 s.
Seehr lang für 8 kByte. Was bremst denn da?

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Hallo Michael,
>
> Git habe ich schon installiert. Aber davon Patches anzulegen bin
> ich noch weit entfernt. Ich probiere erstmal etwas rum und lerne
> dabei etwas Python. Eigentlich möchte ich lieber mehr in die
> Einbindung weiterer Chips investieren.
>
> Eine Frage habe ich noch: das Auslesen des 2764 dauert gut 30 s.
> Seehr lang für 8 kByte. Was bremst denn da?

Das Pufferregister (statusregister genannt) wird für jedes Byte gelesen. 
Das sind jedes mal 64byte über USB. Man kann das optimieren und es nur 
alle 64bytes lesen. Das viele Lesen hat zwei Effekte. Einmal liest es 63 
bytes unnütz und wirft diese weg und zweitens wird bei jedem Lesen die 
command-queue geflusht. Beides kostet viel Zeit.

Im Anhang ist ein mehr oder weniger ungetesteter Patch, der das Auslesen 
auf unter 10sek drückt.

[Guido (Gast)]

Jo, mit dem Patch geht es viel schneller. Wozu dient das Auslesen
des Statusregisters?

Jetzt muss ich zum Löschen des w27f512 VPP an zwei Pins legen, an
Pin 22 und Pin 24. Hast du eine Idee, wie ich das bewerkstelligen
könnte? Ein logisches OR der Pinnummern ergibt ja eine andere
Pinnummer.

[Michael B. (mb_)]

Guido schrieb:
> Jo, mit dem Patch geht es viel schneller. Wozu dient das Auslesen
> des Statusregisters?

Im Statusregister (So habe ich das genannt. Ist vielleicht kein guter 
Name. Es sollte vielleicht eher receive buffer register oder so 
heissen.) werden die Daten, die vom FPGA kommen, zwischengelagert.

> Jetzt muss ich zum Löschen des w27f512 VPP an zwei Pins legen, an
> Pin 22 und Pin 24. Hast du eine Idee, wie ich das bewerkstelligen
> könnte? Ein logisches OR der Pinnummern ergibt ja eine andere
> Pinnummer.

Du musst dir ein entsprechendes VPP Layout aussuchen. Das 
toprammer-layout tool aus der GIT version unterstützt derzeit keine 
mehreren VPP pins. Aber wenn man das script welches die layouts 
definiert ausführt, schreibt es eine Liste aller möglichen Layouts auf 
die konsole:

  python libtoprammer/top2049/vpp_layouts.py

Jeder pin der als "HOT" markiert ist führt in dieser layout 
konfiguration VPP.
Geladen werden kann das Layout von der chip_xxx.py Implementation aus 
mit folgendem Aufruf:

  self.top.vpp.setLayoutID(3)

Das würde Layout 3 laden, welches VPP auf Pin 5, 6 und 7 des ZIF sockels 
legt.
Alternativ kannst du folgendes machen:

  self.top.vpp.setLayoutPins( [5, 6, 7] )

Das lädt auch das Layout mit der ID 3.

Es ist normalerweise nicht schlimm, wenn ein VPP Pin mit anderen Pins 
kollidiert (was besonders in den layouts mit den grossen IDs vorkommt). 
VPP ist über schwache pullups angebunden. Der FPGA hat beispielsweise 
keine Probleme das ganze auf GND oder VCCX zu ziehen.

Selbstverständlich ist das direkte Laden eines Layouts nicht portabel 
zwischen den TOP programmern. Deshalb muss ich den layout-autogenerator 
(nur in GIT. Nicht in 0.2) noch entsprechend anpassen für eine VPP 
Konfiguration mit mehreren VPP pins.

[Guido (Gast)]

Oh, das sind ja nette Tools, da habe ich wohl noch eine Menge
zu erforschen. :-)

>Es ist normalerweise nicht schlimm, wenn ein VPP Pin mit anderen Pins
>kollidiert

Schön zu lesen, die Workarounds, die ich mir für A9/VPP und
OE/VPP überlegt habe brauche ich dann wohl garnicht.

Dann probiere ich mal fröhlich weiter.

Danke, Guido

[Guido (Gast)]

Eine Frage habe ich noch: Die Pins, die mit VPP kollidieren
müsste ich zum Porgrammieren/Löschen  wohl auf Tristate stellen,
damit sie weder auf VCC noch auf VSS gezogen werden. Ich stelle
mir das so vor, dass diese Einstellung im x.py erfolgt, damit
das x.v für ein korrektes Timing dann VPP anlegen und abschalten
kann.

Ich sehe aber nicht, wie ich z.B OE auf Tristate schalte.

[Michael B. (mb_)]

Guido schrieb:
> Eine Frage habe ich noch: Die Pins, die mit VPP kollidieren
> müsste ich zum Porgrammieren/Löschen  wohl auf Tristate stellen,
> damit sie weder auf VCC noch auf VSS gezogen werden. Ich stelle
> mir das so vor, dass diese Einstellung im x.py erfolgt, damit
> das x.v für ein korrektes Timing dann VPP anlegen und abschalten
> kann.
>
> Ich sehe aber nicht, wie ich z.B OE auf Tristate schalte.

Das ist Sache der FPGA Firmware. Du musst halt im Verilog code den Pin 
auf Z stellen. Wenn der Pin nur für VPP gebraucht wird, kann man ihn 
fest mit Z verbinden. Wenn der pin mehrere Funktionen hat, könnte man 
zum Beispiel ein bufif0 verwenden. Das dritte Argument zu bufif0 gibt an 
ob der buffer Z ist oder ob das zweite Argument am Pin ausgegeben wird.

Generell gesagt kann man von dem on-board mikrocontroller, der ja die 
USB Befehle auswertet, nur GND, VPP und VCCX am ZIF sockel direkt 
schalten. Alles andere geht nur vom FPGA aus. Der FPGA wiederum 
kommuniziert mit dem Mikrocontroller über eine 8bit parallele 
Schnittstelle. Diese kann man fast beliebig programmieren. Einfach mal 
in einen Beispiel Verilog code gucken.
Die USB Kommandos um mit dem FPGA zu kommunizieren sind in der TOP 
Klasse und fangen alle mit cmdFPGA...() an.

[Guido (Gast)]

Besten Dank, das hilft mit weiter.

Vllt. sollten wir noch einen Parameter für toprammer einführen:
--ignore_wrong_deviceID

[Michael B. (mb_)]

Guido schrieb:
> Besten Dank, das hilft mit weiter.
>
> Vllt. sollten wir noch einen Parameter für toprammer einführen:
> --ignore_wrong_deviceID

Und was würde der machen?

[Guido (Gast)]

Wenn toprammer die DeviceID prüft und findet nicht die zum
Chip passende, könnte das für einen ähnlichen Chip eines
anderen Herstellers ignoriert werden.

Nicht dass es besonders eilen würde, ich brauche eh noch etwas
länger, aber ich bekomme einen Mapping-Error. Wird doch nicht
daran liegen dass ich die ISE-91i benutze? Hänge das .map mal
an.

[Michael B. (mb_)]

Guido schrieb:
> Wenn toprammer die DeviceID prüft und findet nicht die zum
> Chip passende, könnte das für einen ähnlichen Chip eines
> anderen Herstellers ignoriert werden.

Ich weiss immer noch nicht so richtig was du meinst. :)
toprammer braucht ein bitfile. Diese wird mit -b oder --bitfile 
angegeben. Wenn es diese Datei nicht findet, dann kann es relativ wenig 
machen. Wenn man den Fehler einfach ignorieren würde, würde das recht 
wenig bringen.

> Nicht dass es besonders eilen würde, ich brauche eh noch etwas
> länger, aber ich bekomme einen Mapping-Error. Wird doch nicht
> daran liegen dass ich die ISE-91i benutze? Hänge das .map mal
> an.

Ohne sourcecode kann ich da nicht sagen was los ist.

[Guido (Gast)]

>Ohne sourcecode kann ich da nicht sagen was los ist.

Egal welcher, nimm den m2764 aus dem Git, ergibt denselben
Fehler.

>Ich weiss immer noch nicht so richtig was du meinst. :)

Der TOP* kann ja die DeviceID un die ManufacturerID aus
dem Chip auslesen. Normalerweise sollte er auf Brennversuche
verzichten, wenn diese nicht mit dem im .py-File (eindeutig
dem Chip zuzuordnen für den es geschrieben wurde) hinterlegten
übereinstimmen. Das würde also einen Abbruch geben, den der
Nutzer mit dem Parameter dann bewusst vermeiden könnte.

[Michael B. (mb_)]

Guido schrieb:
>>Ohne sourcecode kann ich da nicht sagen was los ist.
>
> Egal welcher, nimm den m2764 aus dem Git, ergibt denselben
> Fehler.

Ja dann wirds wohl tatsächlich an der ISE Version liegen.

>>Ich weiss immer noch nicht so richtig was du meinst. :)
>
> Der TOP* kann ja die DeviceID un die ManufacturerID aus
> dem Chip auslesen. Normalerweise sollte er auf Brennversuche
> verzichten, wenn diese nicht mit dem im .py-File (eindeutig
> dem Chip zuzuordnen für den es geschrieben wurde) hinterlegten
> übereinstimmen. Das würde also einen Abbruch geben, den der
> Nutzer mit dem Parameter dann bewusst vermeiden könnte.

Achso meinst du das. Ja. Bei den Atmel Implementierungen ist das 
eingebaut. Bei der m2764a Implementierung hab ich das weggelassen, weil 
ich keinen solchen Chip habe und den ganzen kram nur mal eben kurz 
nebenbei geschrieben habe. Du kannst das natürlich gerne hinzufügen. Es 
wäre auch nett, wenn man noch einen Check der Pins durchführt (wie beim 
Atmel code) um evtl zu erkennen ob der Chip ganz verkehrt drinsteckt 
oder so.

[Guido (Gast)]

Wenn ich in der .ucf "read" an P91 lege, funktioniert es. Die
Fehlermeldung ist eigentlich o.k., da ein getaktetes Signal
(hier read) nicht an einem GCK-Pin liegt. Verstehe nicht, wieso
es dann bei dir geht? Was hat denn dein S2-Mapper für eine
Versionsnummer? Kann mir fast nicht vorstellen, dass Xilinx damals
für die uralten Chips noch was verbessert hat.

[Michael B. (mb_)]

Guido schrieb:
> Wenn ich in der .ucf "read" an P91 lege, funktioniert es.

Du kannst read nicht einfach auf P91 legen, weil es nunmal auf P45 
physikalisch zusammengelötet ist.

> Fehlermeldung ist eigentlich o.k., da ein getaktetes Signal
> (hier read) nicht an einem GCK-Pin liegt. Verstehe nicht, wieso
> es dann bei dir geht? Was hat denn dein S2-Mapper für eine
> Versionsnummer?

Weiss ich nicht. Ich nehme ISE 9.2i.

[Guido (Gast)]

Schon klar, war nur ein Test. Die Versionsnummer steht im
.map-File.

[Michael B. (mb_)]

Guido schrieb:
> Schon klar, war nur ein Test. Die Versionsnummer steht im
> .map-File.

Release 9.2i Map J.36
Mapper Version : spartan2 -- $Revision: 1.36 $

[Guido (Gast)]

Habe ich mir schon gedacht, dieselbe Version. Am Mapper liegt
es also nicht. Das nervt, wenn es nur mit einer einzigen
Version der ISE geht.

[Guido (Gast)]

So, nach mehrstündiger Neuinstallation scheint das Auslesen zu
funktionieren. Jetzt habe ich noch ein paar Fragen:

Was bewirken die mit QueueCommand gesendeten Befehle? Ich
verstehe noch nicht mal, ob die beim Chiptreiber (.v)
ankommen.

top.vpp.setLayoutID würde wohl applyVPP ersetzen, oder?

Ob es möglich ist, mit dem delay-Counter eine kleine
Statemachine zu realisieren, so dass z.B. beim Auslesen
immer 16 Byte in einen Puffer geschrieben und anschließend
am Block gesendet werden? Mir scheint, dass im S2 noch eine
Menge Reserven frei sind, abschätzen kann ich das aber nicht.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Was bewirken die mit QueueCommand gesendeten Befehle? Ich
> verstehe noch nicht mal, ob die beim Chiptreiber (.v)
> ankommen.

Mit queueCommand wird ein Befehl für das Gerät in der queue abgelegt. An 
das Gerät gesendet wird es automatisch vor dem nächsten status register 
read oder explizit mit flushCommands.
Der Sinn im command queueing besteht darin mehrere Kommandos in einem 
Rutsch per USB zu senden, anstatt jedes Kommando einzeln.
Das hat einen enormen Geschwindigkeitsgewinn.
Mit dem Kommandozeilenparameter -Q kann man das queueing abschalten. Das 
braucht man aber nicht zu machen, wenn kein Bug im Code ist.

> top.vpp.setLayoutID würde wohl applyVPP ersetzen, oder?

Umgekehrt. applyVPP ersetzt setLayoutID. Der Unterschied ist, dass 
applyXXX() auf das auto-generierte Layout wirkt. Man gibt in _init_ 
einfach an welches DIP Package der Chip hat und wo an diesem DIP Package 
die VCC/VPP und GND sind (man gibt die Pin Nummern am DIP an. Nicht am 
ZIF!). Der auto-generator sucht dann automatisch ein passendes Layout.
Mit toprammer-layout kann man sich ein ascii-art auf der Konsole 
anzeigen lassen, damit man weiss wie der Chip eingesteckt wird und wie 
man den FPGA programmieren muss.

> Ob es möglich ist, mit dem delay-Counter eine kleine
> Statemachine zu realisieren, so dass z.B. beim Auslesen
> immer 16 Byte in einen Puffer geschrieben und anschließend
> am Block gesendet werden? Mir scheint, dass im S2 noch eine
> Menge Reserven frei sind, abschätzen kann ich das aber nicht.

Es kann immer nur ein Byte in den FPGA geschrieben und gelesen werden. 
(cmdFPGAReadByte(), cmdFPGAReadRaw() und cmdFPGAWrite())
Der Unterschied zwischen cmdFPGAReadByte() und cmdFPGAReadRaw() ist ist 
nur eine mehr oder weniger (eher weniger) sinnvolle Optimierung.
cmdFPGAReadByte() ist das gleiche wie cmdFPGAReadRaw(0x10).
Es braucht halt ein Byte weniger auf dem USB Bus.
Generell gesagt ist wie R/W-Adresse 0x10 für das FPGA hardcodiert im 
Mikrocontroller auf dem Programmer. 0x10 ist immer payload-byte 
read/write.

Wenn man ein cmdFPGAReadByte() sendet, dann gibt der mikrocontroller ein 
address-latch mit 0x10 an den FPGA und dann eine edge auf read. Der 
Mikrocontroller legt dann das Byte was auf dem FPGA data bus liegt in 
das "status register" im Mikrocontroller ab. Dieses Register hat einen 
automagischen pointer, der jedes mal imkrementiert wird und auf Null 
zurückgesetzt wird sobald das register mit cmdReadStatusReg() ausgelesen 
wird. Es können somit bis zu 64bytes im Mikrocontroller zwischengelagert 
werden. Trotzdem braucht es für jedes Byte was vom FPGA gelesen wird ein 
explizites cmdFPGAReadByte() um das byte in das status register zu 
lesen. Das ist aber relativ leichtgewichtig, weil toprammer die 
commandos automatisch queued und im Batch zum Gerät schickt.

[Guido (Gast)]

Nur mal weil ich gerade zu faul zum Aufschrauben bin:
Read, Write und Ale hört sich doch nach einem FTDI-Chip
im MCS-51-Modus an. Soeiner hat doch ca. 1,5 kByte Puffer,
sodass man mehrere Bytes im Block senden kann. Im FPGA muss
man dann ein kleines Ram realisieren, was ja recht einfach
geht.

Damit könnte man viel Zeit sparen, durch das Herausnehmen des
Toggelns von /OE im .py (was wohl problemlos geht) reduziert
sich die Auslesezeit auf die Hälfte. Wenn der FPGA teilweise
auch noch die Adressgenerierung ... übernimmt, geht es noch
schneller.

Ich habe hier noch Flashroms, die man mit der momentanen Lösung
wohl nicht brennen könnte, da sie kurze Zeit auf 64 Byte warten
und mit dem Brennen anfangen, wenn ein Timeout abgelaufen ist.
Ich befürchte, dass das Timeout dann schon nach dem ersten
gesendeten Byte abgelaufen wäre.

Gruß, Guido

[Guido (Gast)]

Ich brauche noch ein paar Tgae, aber wie du das beschreibst könnte
es ja funktionieren. So stelle ich mir das vor:

Toprammer schickt normal die Adresse, das x.v gibt sie aus und
speichert sie in einem Register. Dann schickt toprammer hintereinander
64 Bytes Daten, die ebenfalls im x.v gespeicher werden:

reg [7:0] datab [0:63];

always @(negedge ale) begin
    datab[i] <= data;
    i += 1;            
end

Dann schickt toprammer den Brennbefehl und es werden 64 Bytes
im Delay_Counter mit Adressinkrement gebrannt. O.K. zum Brennen
würde ich ev. nur 16 Bytes nehmen, damit man flexibel bleibt.

Wäre das machbar, Guido

[Michael B. (mb_)]

Guido schrieb:
> Dann schickt toprammer den Brennbefehl und es werden 64 Bytes
> im Delay_Counter mit Adressinkrement gebrannt. O.K. zum Brennen
> würde ich ev. nur 16 Bytes nehmen, damit man flexibel bleibt.
>
> Wäre das machbar, Guido

Natürlich ist das machbar. Du kannst aber nach wie vor immer nur ein 
byte pro Befehl an den FPGA schicken.

[Michael B. (mb_)]

Guido schrieb:
> Nur mal weil ich gerade zu faul zum Aufschrauben bin:
> Read, Write und Ale hört sich doch nach einem FTDI-Chip

Nein. read/write/ale sind mit dem mikrocontroller verbunden.

[Michael B. (mb_)]

Und was ich noch dazu sagen möchte: Je mehr im FPGA implementiert wird, 
desto unportabler zwischen den TOPxxxx Geräten wird das ganze. Das ist 
nicht schlimm, wenn es einen signifikanten Geschwindigkeitsvorteil 
gibt. Aber bei sagen wir 10% Vorteil bevorzuge ich die portable 
Variante.

Ausserdem ist der FPGA auch nicht soooo groß. Man stößt da schon recht 
schnell an die Grenzen. Im code für den m8c (noch nicht komplett) sind 
relativ komplexe statemachines implementiert. Mit dem code sind so ca 
85% der FPGA Resourcen ausgelastet.

[Guido (Gast)]

Ahh, danke. Mit dem Lesen geht das wohl leider nicht, da wohl jedes
Byte einzeln von toprammer angefordert werden muss?

Ich Depp, jetzt suche ich seit Stunden warum das 2. Byte der
DeviceID falsch ist (68 statt 08). Endlich ist mir eingefallen,
dass der W27F512 kundenspez. ist, das Datenblatt zum W27E512
gehört. :-( Habe sogar schon das Oszilloskop bemüht.

Immerhin funktioniert das wohl, später mache ich mich mal an
Chip-Erase.

Mit dem FTDI meinte ich die Anbindung ds FPGA an USB.

Gruß, Guido

[Guido (Gast)]

Oops, Crosspost.

Der Geschwindigkeitsvorteil wird riesig, da der USB-Transfer auf
ein Viertel oder mehr reduziert wird.

[Michael B. (mb_)]

Guido schrieb:
> Ahh, danke. Mit dem Lesen geht das wohl leider nicht, da wohl jedes
> Byte einzeln von toprammer angefordert werden muss?

So ist es. Jedoch kann man 64bytes in den mikrocontroller status 
puffer lesen. Das benötigt 64 Kommandos über USB. Aber weil diese 64 
kommandos nur 64byte breit sind, können sie in einem Rutsch gesendet 
werden (command queueing). Vorraussetzung ist, dass kein Lesezugriff auf 
das Statusregister in der Zwischenzeit passiert.

> Ich Depp, jetzt suche ich seit Stunden warum das 2. Byte der
> DeviceID falsch ist (68 statt 08). Endlich ist mir eingefallen,
> dass der W27F512 kundenspez. ist, das Datenblatt zum W27E512
> gehört. :-( Habe sogar schon das Oszilloskop bemüht.

Lol. Sowas passiert mir auch schonmal :D

> Immerhin funktioniert das wohl, später mache ich mich mal an
> Chip-Erase.

Sehr schön. :)

> Mit dem FTDI meinte ich die Anbindung ds FPGA an USB.

Die Hardware sieht so aus:

USB Stecker -> PDIUSBD12 -> "Megawin" Mikrocontroller -> FPGA.

Im Mikrocontroller befindet sich der 64byte lesepuffer (status 
register). Dieser kann aber nur per polling mit jeweils einem Byte ueber 
USB gefüllt werden.

PS: Ja, das USB Protokoll des TOP2049 ist total hirnverbrannt. 
Derjenige, der es entworfen hat gehört auf der Stelle gefeuert. :)
Mit dem Protokoll werden so einige Features des Gerätes verspielt.
Schon alleine der ganze layout Quatsch für die Spannungen ist extrem 
krank. Sowas kann man nur unter extremem Einfluss von schwersten Drogen 
entwerfen.

[Michael B. (mb_)]

Guido schrieb:
> Oops, Crosspost.
>
> Der Geschwindigkeitsvorteil wird riesig, da der USB-Transfer auf
> ein Viertel oder mehr reduziert wird.

Naja, der Transfer an sich frisst nicht die Zeit.
Was viel Zeit frisst ist das wechseln zwischen gesendeten Kommandos und 
cmdReadStatusReg(), weil letzteres die command-queue flushen muss.

Ich muss auch unbedingt als nächstes eine brauchbare Dokumentation 
schreiben, damit ich das nicht jedem hier erklären muss :D

[Guido (Gast)]

Hallo Michael,

ich komme mit den Vpp-Layouts nicht klar. Ich benötige VPP an den
ZIF-Pins 32 und 34. Demnach würde ich vermuten, dass ich die
Layout-ID 30 verwenden kann. Damit bekomme ich VPP an Pin 34,
nicht jedoch an Pin 32. Id 30 scheint mir aber das einzige Layout
zu sein, mit dem ich überhaupt VPP an Pin 34 bekomme. Wie ich
das mit der Ausgabe von vpp_layouts.py in Verbindung bringe, ist
mir völlig unklar.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Hallo Michael,
>
> ich komme mit den Vpp-Layouts nicht klar. Ich benötige VPP an den
> ZIF-Pins 32 und 34. Demnach würde ich vermuten, dass ich die
> Layout-ID 30 verwenden kann. Damit bekomme ich VPP an Pin 34,
> nicht jedoch an Pin 32. Id 30 scheint mir aber das einzige Layout
> zu sein, mit dem ich überhaupt VPP an Pin 34 bekomme. Wie ich
> das mit der Ausgabe von vpp_layouts.py in Verbindung bringe, ist
> mir völlig unklar.

Ich verstehe nicht was du meinst. Bei layout 30 ist VPP sowohl an pin 32 
als auch an pin 34.

Ich würde dir vorschlagen den autogenerator zu nutzen und dir keine 
weiteren Gedanken über das Layout zu machen.

[Guido (Gast)]

Danke für die schnelle Antwort. Mit dem Layoutgenerator komme ich
nicht klar, da ich abhängig von der Aktion an unterschiedlichen
Pins VPP brauche. Ich habe daher zw. VPP und VPE unterschieden.

Layout 28 ist das einzige, mit dem ich VPP an Pin 32 bekomme,
Layout 30 das einzige für Pin 34. Mit allen anderen Layouts
bekomme ich VPP an diesen beiden Pins nicht.

Hier mal wie ich das probiere:

        
bufif0(zif[29], dut_data[7], !dut_OE);  /* Q7 */  
  bufif0(zif[30], dut_CE, low);    /* CE */
  bufif0(zif[31], dut_addr[10], low);  /* A10 */
  bufif0(zif[32], dut_OE, dut_VPE);  /* OE/VPP */
  bufif0(zif[33], dut_addr[11], low);  /* A11 */
  bufif0(zif[34], dut_addr[9], dut_VPE);  /* A9/VPE */
  bufif0(zif[35], dut_addr[8], low);  /* A8 */
  bufif0(zif[36], dut_addr[13], low);  /* A13 */
  bufif0(zif[37], dut_addr[14], low);  /* A14 */
  bufif0(zif[38], high, low);    /* VCC */

Durch Setzen von dut_VPE (dut_VPE <= 1;) sollte dann doch VPP an
den Pins 32 und 34 anliegen? Tut es aber nicht.

[Michael B. (mb_)]

Guido schrieb:
> Danke für die schnelle Antwort. Mit dem Layoutgenerator komme ich
> nicht klar, da ich abhängig von der Aktion an unterschiedlichen
> Pins VPP brauche. Ich habe daher zw. VPP und VPE unterschieden.

Der kann damit umgehen.

> Layout 28 ist das einzige, mit dem ich VPP an Pin 32 bekomme,
> Layout 30 das einzige für Pin 34. Mit allen anderen Layouts
> bekomme ich VPP an diesen beiden Pins nicht.

Ich verstehe immer noch nicht was "VPP an Pin xxx bekomme" bedeutet.
Misst du die Spannung und es ist keine da oder was?

Ich habe die Layout daten per 4094 sniffer aus dem Gerät geladen.
Ich habe nie nachgemessen ob die Daten stimmen, weil es für mich ganz 
einfach funktioniert.

Btw: Wenn Topwin den chip unterstützt würde ich dir ganz einfach 
empfehlen einen USB dump anzufertigen und da zu gucken wie die es 
machen. Das ist viel einfacher als rumzuraten.

[Guido (Gast)]

> Ich verstehe immer noch nicht was "VPP an Pin xxx bekomme" bedeutet.
> Misst du die Spannung und es ist keine da oder was?

Jo, habe wieder das Oszilloskop dranhängen, probiere alle Layouts
durch und schaue was rauskommt. Immer nur VPP an einem Pin.

Für den autogenerator überfordert mich schon die Syntax:
chipPinVPP = 32 + 34, kann es ja wohl nicht sein ;-)

Mit dem Dump wirds wohl nix, ich bekomme Qemu nicht mehr vernünftig
zum Laufen, da es unter Ubuntu kein Framebufferdevice mehr gibt.

[Michael B. (mb_)]

Guido schrieb:
> Jo, habe wieder das Oszilloskop dranhängen, probiere alle Layouts
> durch und schaue was rauskommt. Immer nur VPP an einem Pin.

Ich schliesse nicht aus, dass die layout Daten teilweise falsch sind.

> Für den autogenerator überfordert mich schon die Syntax:
> chipPinVPP = 32 + 34, kann es ja wohl nicht sein ;-)

Erstmal neueste toprammer version nehmen. Dann Python lernen. Dann eine 
Liste von Pins übergeben.

Wenn die Layoutdaten falsch sind bringt das natürlich auch nix.

Wird dein Chip denn von Topwin unterstützt?
Wenn ja, musst du unbedingt VPP an beiden Pins zugleich haben?

[Guido (Gast)]

> Erstmal neueste toprammer version nehmen.

Das ist der entscheidende Hinweis! Sogar mit Dokumentation.:-)

Die nächsten Tage werde ich keine Zeit haben, aber dann probiere
ich mal den autogenerator. Vllt. habe ich ja einen Konflikt der
Layouts untereinander.

Ja und ja: TopWin unterstützt den Chip in derselben Position.
Beide Pins an VPP brauche ich zum Löschen

[Michael B. (mb_)]

Guido schrieb:
>> Erstmal neueste toprammer version nehmen.
>
> Das ist der entscheidende Hinweis! Sogar mit Dokumentation.:-)
>
> Die nächsten Tage werde ich keine Zeit haben, aber dann probiere
> ich mal den autogenerator. Vllt. habe ich ja einen Konflikt der
> Layouts untereinander.
>
> Ja und ja: TopWin unterstützt den Chip in derselben Position.
> Beide Pins an VPP brauche ich zum Löschen

Ok. Es befindet sich auch noch ein flipflop auf dem Gerät, von dem ich 
keine Ahnung habe was er macht. Es könnte ja theoretisch auch noch damit 
zusammenhängen. Ich werde morgen Abend mal durchmessen wo der hingeht.
Das 0E28xx00 Commando vermute ich steht möglicherweise im Zusammenhang 
mit diesem flipflop. Muss ich mal genauer schauen.

Die VPP und VCCX Layouts habe ich direkt von den Shiftregistern auf der 
Platine gesnifft. Es kann natürlich sein, dass ich da einen Fehler 
gemacht habe. Aber ich kann nicht erkennen wo. Das VCCX Layout scheint 
ja korrekt zu sein. Das ist mit dem gleichen Sniffer ausgelesen wie VPP.

[Guido (Gast)]

Hallo,

bei den beiden Pins sieht es so aus, als ob das VPP-Layout
mit dem VCCX-Layout identisch ist. Da könnte ich mal noch
mehr Pins probieren. Notfalls hänge ich morgen abend mal den
Logicanalyzer dran und probiere alle Layouts durch. Das
0E28xx00 Commando probiere ich mal mit ein paar xx-Werten,
am Oszilloskop kann da ja wohl nicht viel passieren.

Da es unter TopWin geht, bekommen wir das auch hin.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Hallo,
>
> bei den beiden Pins sieht es so aus, als ob das VPP-Layout
> mit dem VCCX-Layout identisch ist. Da könnte ich mal noch
> mehr Pins probieren. Notfalls hänge ich morgen abend mal den
> Logicanalyzer dran und probiere alle Layouts durch. Das
> 0E28xx00 Commando probiere ich mal mit ein paar xx-Werten,
> am Oszilloskop kann da ja wohl nicht viel passieren.
>
> Da es unter TopWin geht, bekommen wir das auch hin.
>
> Gruß, Guido

Ich habe jetzt nochmal ein paar Layouts durchgemessen und dort ist 
definitiv was faul. Ich werde wohl nochmal den Sniffer dranhängen müssen 
und das ganze nochmal durchprobieren. Ich bin mir momentan nicht sicher 
was dort beim ersten Auslesen passiert ist. Denn erstens scheinen die 
VCCX Layouts ja zu stimmen (oder nicht?) und zweitens habe ich mehrmals 
ausgelesen um elektrische Störungen in meinem fliegenden Aufbau zu 
erkennen. Mal sehen. Irgendwo ist auf jeden Fall ein Fehler passiert. :)

[Michael B. (mb_)]

So ich hab jetzt nochmal den sniffer drangehangen und beim 
durchnummeriertem Auslesen (layout 0-0xFF) habe ich wieder genau die 
gleichen Daten ausgelesen.
Danach habe ich mal einige Layouts durchgemessen. Die unteren Layouts 
(<10 oder so) sind auch korrekt. Nur in den oberen Layouts läuft was 
schief. Jetzt hab ich mal mit dem sniffer ein oberes Layout ausgelesen 
ohne vorher die unteren Layouts zu proben. Und siehe da: Ein anderes 
Ergebnis. o.O
Vielleicht stimmt da irgendwas mit meinem Sniffer nicht. Was da genau 
schief läuft kann ich noch nicht sagen.

Bei Interesse: Hier ist der sniffer code für einen AtMega8:
http://bu3sch.de/gitweb?p=misc.git;a=tree;f=4094sniffer;hb=HEAD

Der Patch zu Toprammer zum sniffen der Layouts sollte so ähnlich 
aussehen wie der im Anhang.

[Guido (Gast)]

Hallo Michael,

ich habe mich in der Zwischenzeit mal dem AT89C2051 gewidmet.
Teilweise funktioniert es auch, wenn du Lust hast, schau doch
mal die Dateien an. Verbesserungvorschläge willkommen.

Zwei Probleme hab ich noch:

Das zweite Byte wird reproduzierbar nicht gebrannt. Alle anderen
stimmen wie "cmp Original Fälschung" bestätigt. Das ist mir
völlig unerklärlich, ich sehe aber auf dem Oszilloskop, dass
es da einen Aussetzer gibt.

Das Timing mittels delay_count musste ich verdoppeln, als ob der
FPGA mit 24 MHz läuft. Vielleicht habe ich da aber auch nur falsch
gemessen?

Ich muss natürlich beim Brennen noch mein Fehlerbit auswerten,
ev. hilft das beim 1. Fehler ja schon weiter.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Hallo Michael,
>
> ich habe mich in der Zwischenzeit mal dem AT89C2051 gewidmet.
> Teilweise funktioniert es auch, wenn du Lust hast, schau doch
> mal die Dateien an. Verbesserungvorschläge willkommen.
>
> Zwei Probleme hab ich noch:
>
> Das zweite Byte wird reproduzierbar nicht gebrannt. Alle anderen
> stimmen wie "cmp Original Fälschung" bestätigt. Das ist mir
> völlig unerklärlich, ich sehe aber auf dem Oszilloskop, dass
> es da einen Aussetzer gibt.

Ich vermute einen Initialisierungsfehler in der Statemachine.
Bei dem delay_count muss soweit ich das sehe auch noch immer 1 
subtrahiert werden, weil zwischen delay_count=0 und dem Ausführen der 
Kommandos noch ein Takt liegt.

Natürlich wird dieser eine Takt mehr oder weniger meistens bedeutungslos 
sein und das ist sicher nicht die Wurzel deines Problems.

> Das Timing mittels delay_count musste ich verdoppeln, als ob der
> FPGA mit 24 MHz läuft. Vielleicht habe ich da aber auch nur falsch
> gemessen?

Ja der Takt läuft vermutlich mit 24MHz. Das ist auch das was ich 
ungefähr gemessen habe (Habe nur ein 20MHz Scope). Ich müsste mal mit 
dem Frequenzzähler drangehen...

Die 12MHz kommen von einem Verilog file welches sich zwischen den Topwin 
bitfiles befindet. Ich ging davon aus, dass das richtig wäre. Es ist 
aber offensichtlich falsch.


Btw: Hast du denn mal getestet, ob du vom FPGA aus VPP auf GND 
runterziehen kannst? Ich habe das noch nicht probiert.

[Guido (Gast)]

>Btw: Hast du denn mal getestet, ob du vom FPGA aus VPP auf GND
>runterziehen kannst? Ich habe das noch nicht probiert.

Ja, geht. Erst mit applyVPP(False) absschalten und dann gibt es
damit keine Probleme. Ist auch wichtig, sonst läuft VPP über
ewige Zeiten langsam runter.

Ich werde morgen weiter probieren, ist nur seltsam, dass das
erste Byte korrekt gebrannt wird, das 2. garnicht und der Rest
wieder korrekt.

[Michael B. (mb_)]

So ich hab jetzt rausgefunden wie das mit dem VPP funktioniert:

Man kann mehrere Layouts kombinieren indem man sie nacheinander lädt. 
Beispiel:

cmdLoadVPPLayout(0)   # Rücksetzen
cmdLoadVPPLayout(28)  # Layout 28 laden
cmdLoadVPPLayout(30)  # Layout 30 zusätzlich laden

Nun ist VPP auf den Pins von Layout  28 und 30 aktiv. Wenn ich jetzt 
natürlich mit dem sniffer alle Layouts durchprobiere ohne zwischendurch 
layout 0 zu laden (rücksetzen), dann hab ich am Ende auf fast jedem Pin 
VPP. Nur ist der VPP Treiber zu schwach dafür und die ganze Sache wird 
mehr oder weniger zufällig :)

Die VPP Layouts sind also insofern falsch, dass jedes Layout das 
vorhergehende Layout enthält. Ich werde die Definitionen bei Gelegenheit 
korrigieren.
Die Möglichkeit die Layouts zu kombinieren muss dann natürlich auch noch 
in den Autogenerator integriert werden. Das sollte aber kein Problem 
sein.


Das ganze zeigt natürlich wieder wie extremst hirnverbrannt dieses 
Interface ist. Warum man nicht einfach eine Bitmaske übergibt ist mir 
schleierhaft. :)

[Guido (Gast)]

Hauptsache es geht irgendwie. :-)

Der AT89C2051 funktioniert jetzt, ein kleines zusätzliches Delay
in der SM hat den Erfolg gebracht. Ich hänge jetzt noch ein
Verify an Löschen und Programmieren und dann kann ich mich wieder
dem W27E512 zuwenden.

[Guido (Gast)]

So, bin fertig. Habe mal alles in ein tgz gepackt.

Ich glaube, mit dem W27E512 warte ich bis du den Autogenerator
überarbeitet hast. Hab ja schließlich noch andere Testobjekte,
wobei ich die AVRs dir überlasse.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> So, bin fertig. Habe mal alles in ein tgz gepackt.

Danke. Ich werde mir das mal genauer angucken und ins GIT importieren.

EDIT: Möchtest du vielleicht noch deine Copyrighthinweise einfügen? Die 
Dateiköpfe müssen auch noch berichtigt werden.

Du kannst auch gerne noch ein regression-test schreiben. Das ist zwar 
nur für diejenigen nützlich, die die Chips haben (ich nicht), aber man 
kann schnell testen ob in einer neuen Version etwas schiefgelaufen ist. 
Bei Interesse einfach mal in das tests/ Verzeichnis gucken. Viel Doku 
gibts noch nicht dazu, aber ich denke das ist größtenteils 
selbsterklärend.

> Ich glaube, mit dem W27E512 warte ich bis du den Autogenerator
> überarbeitet hast. Hab ja schließlich noch andere Testobjekte,
> wobei ich die AVRs dir überlasse.

Als nächstes werde ich mich den AT-tinys mit HV-serial programmierung 
widmen.
Die Atmegas sollten eigentlich alle mit wenig Aufwand zu implementieren 
sein, weil die so weit ich das sehe alle HV-parallel unterstützen. Da 
kann man dann auf die chip_atmega_common.py Implementation 
zurückgreifen.

[Thomas R. (tinman)]

Michael Buesch schrieb:

>
> Als nächstes werde ich mich den AT-tinys mit HV-serial programmierung
> widmen.


ich sage jetzt schon danke :)

Nach dem ich den dritten attiny85 ins nirvana befördert habe (böse idee 
firmware fehler zu haben wenn nur über bootloader upgedated werden kann) 
kann ich sowas gut gebrauchen.

Leider hat topwin kein support mehr (ging nicht ganz:P) für 
attiny25/45/85 HV programming. Konnte zwar solange herumpatchen bis 
attiny13 HV bit file mit dem attiny85 ging, nur leider fehlte mir immer 
noch ein bit, nach ein paar stunden genug gehabt und stange attinys 
bestellt ...

[Guido (Gast)]

Hallo Michael,

das mit den Tests sieht interessant aus, das schaue ich mir mal an. Die
Dateiköpfe habe ich vergessen, hole ich nach.

Ich habe mal nachgesehen was lyx ist, das sollte doch auch LaTeX-Files
einbinden können? Dann wäre es vielleicht sinvoll noch eine Doku für
die unterstützten Chips anzulegen, einen Entwurf hänge ich an. Damit
kann leicht eine Übersicht erstellt werden (naja, im Moment ist es ja
noch übersichtlich) aber ein zugehöriges Verzeichnis kann auch leicht
mit cat und grep durchsucht werden.

Soll ich mehrere sehr ähnliche Chips in einem Treiber zusammenfassen
und anhand der Signatur entscheiden welcher es ist? Dann schaffen wir
natürlich die 2000+ Chips nicht so schnell :).

Ist es aus deiner Sicht o.k. die Lockbytes zu ignorieren? Ich sperre
mich halt ungern aus und normalerweise braucht man die ja nicht.

Ich werde als nächstes noch die AT89C51/52 probieren, die sind recht
ähnlich zum 2051 und dafür kann ich dann mal mit der Brenngeschwin-
digkeit experimentieren.

ATtinys zum Testen habe ich auch ein paar, die warten schon ;-).

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Ich habe mal nachgesehen was lyx ist, das sollte doch auch LaTeX-Files
> einbinden können?

lyx ist ein LaTeX frontend fuer Leute wie mich die kein LaTeX koennen 
(wollen).

> Dann wäre es vielleicht sinvoll noch eine Doku für
> die unterstützten Chips anzulegen, einen Entwurf hänge ich an. Damit
> kann leicht eine Übersicht erstellt werden (naja, im Moment ist es ja
> noch übersichtlich) aber ein zugehöriges Verzeichnis kann auch leicht
> mit cat und grep durchsucht werden.

Naja, ich bin immer sparsam mit dokus, weil diese schneller veraltet 
sind als man gucken kann. Und veraltete dokus sind schlecher als gar 
keine dokus.

> Soll ich mehrere sehr ähnliche Chips in einem Treiber zusammenfassen
> und anhand der Signatur entscheiden welcher es ist? Dann schaffen wir
> natürlich die 2000+ Chips nicht so schnell :).

Wenn du dir die atmega implementation anschaust, wirst du sehen, dass 
der algorithmus in einer gemeinsamen Klasse definiert ist und die 
Implementierungen der einzelnen Chips davon abgeleitet sind. Das ist IMO 
die sauberste Loesung.
Bitfiles (und die dazugehoerigen sourcecodes) gibt es fuer jeden Chip 
separat, weil ich denke da sind zu viele signifikante Unterschiede 
zwischen den einzelnen Chips. Einfach weil die in verschiedenen Packages 
kommen. Da mit ifdef oder so zu arbeiten ergibt fuer mich keinen Sinn.

Es geht mir auch nicht darum moeglichst viele Chips (die keiner nutzt) 
in kurzer Zeit zu implementieren. Es geht mir darum ein Framework 
bereitzustellen, dass jeder verstehen kann und dann selbst schnell und 
einfach seinen Chip implementieren kann. Es ist unrealistisch zu denken 
ein paar Leute koennten hunderttausende Chips implementieren und 
pflegen(!).

> Ist es aus deiner Sicht o.k. die Lockbytes zu ignorieren? Ich sperre
> mich halt ungern aus und normalerweise braucht man die ja nicht.

Weiss ich nicht. Ich kenne den Chip nicht. Bei atmega ist das Lesen und 
Schreiben der lockbytes implementiert. Ich denke viele Leute wollen 
dieses Feature. Wobei ich es auch fuer ueberbewertet halte. Es grenzt an 
Trivialitaet eine Mikrocontroller Firmware neuzuschreiben ohne das 
Original zu haben. Das habe ich schon oft gemacht. Ich schreibe auch 
lieber ein Programm komplett neu als mich durch den disassemblierten 
Code zu wursteln. Das Programm gegen Auslesen zu schuetzen halte ich 
deshalb fuer Bloedsinn. Aber jedem das Seine. :)

> Ich werde als nächstes noch die AT89C51/52 probieren, die sind recht
> ähnlich zum 2051 und dafür kann ich dann mal mit der Brenngeschwin-
> digkeit experimentieren.
>
> ATtinys zum Testen habe ich auch ein paar, die warten schon ;-).

Ich habe einen tiny28. Dieser verwendet ein modifiziertes HV-parallel. 
Der Code ist auch schon in GIT, aber funktioniert noch nicht so wie es 
soll...

Dann habe ich noch einen tiny13, der HV-serial braucht. Da habe ich noch 
nicht mit angefangen.

[Guido (Gast)]

Ich hoffe, dass jetzt alles passt. Test ist auch dabei (natürlich
getestet).

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Ich glaube, mit dem W27E512 warte ich bis du den Autogenerator
> überarbeitet hast.

Autolayouts sollten jetzt auch für chips mit mehreren VPPs korrekt 
funktionieren.

[Michael B. (mb_)]

Guido schrieb:
> Ich hoffe, dass jetzt alles passt. Test ist auch dabei (natürlich
> getestet).

So, ich habe es ins GIT importiert, aber ein paar Kommentare habe ich 
dazu noch:

Erstmal Thema trailing-whitespace:

> Warning: trailing whitespace in lines 
23,43,47,59,64,65,67,76,77,94,98,105,110,111,119,121,124,126,127,132,135 
,142,154,186,187  of libtoprammer/bit/src/at89c2051dip20/at89c2051dip20.v
> Warning: trailing whitespace in lines 
27,28,45,54,55,57,63,64,65,66,67,68,70,72,73,76,77,78,81,83,85,86,87,88, 
90,92,100,103,105,107,108,114,115,116,124,127,129,135,137,139,141,142,15 
2,153,155,157,158,159,165,166,192,193,201,217,220  of 
libtoprammer/chip_at89c2051dip20.py

Whitespace is sehr wichtig in Python. Man sollte das sehr sorgsam 
handhaben. Dazu gehört auch unnötiger Whitespace-trash am Zeilenende. 
Jeder halbwegs gute Editor hat eine Funktion um bei trailing-whitespace 
zu warnen.

Zweitens: Ich bevorzuge immer GNU/diff gegenüber tar-archiven oder rohen 
Dateien. Ein diff anzufertigen ist einfacher für dich (ja wirklich) und 
es ist sehr viel einfacher für mich das zu importieren. Auch passieren 
dann nicht mehr so Fehler, dass Modifikationen versehentlich ausgelassen 
werden (wie das import des chip... files). Diff ist auch wesentlich 
einfacher zu handhaben, wenn man die Modifikation kommentieren will. Man 
kann einfach ein Teil daraus Zitieren und es ist eindeutig was gemeint 
ist.

Diffs kann man mit GIT anfertigen oder (von mir empfohlen) dem Quilt 
tool. (Natürlich kann man auch das diff tool direkt verwenden. Das ist 
aber nicht empfehlenswert, da frickelig).

[Guido (Gast)]

Hallo Michael, angenehm ruhiger Thread eigentlich. Jaja, die
Whitespaces, die lässt Kate immer beim Löschen übrig. Er zeigt
sie aber an, so dass ich sie noch rausschmeißen kann.

Diff könnte ich doch einfach von der Kommandozeile aus nutzen,
was bringt da Quilt? Muss ich mir mal anschauen. Für tar muss ich
halt nur eine Datei der Files erstellen, klar in "main" muss dann
der Chip von Hand eingetragen werden. Vor einem diff sollte ich
wohl jedesmal ein "git clone" durchführen, damit nichts vermischt
wird.

Der At89C51 scheint jetzt zu funktionieren, ich bin aber ziemlich
genervt, weil die Timingangaben des Datenblattes schlicht
fehlerhaft sind. Man kennt ja die verdächtigen Kandidaten, aber
wenn man an drei, vier Stellen schlicht probieren muss, ist das
nur noch Frickelei.

Ich mache noch den AT89C52, der ist identisch, hat nur den doppelten
Flash. Bei der Testsuite wird es schwierig, weil es die Chips mit
VPP = 12 V und 5 V gibt. Die Signatur entscheidet. Im toprammer ist
das kein Problem, aber wie ich beim Test zwei Varianten für die
Signatur angebe, erschließt sich mir nicht.

Du hast Recht, die Ressourcen des S2 sind nicht üppig. Ich wollte zum
Test neben der SM die 16 Bytes im Block schreibt noch eine SM für
einzelne Bytes anlegen, das hat schon nicht mehr gepasst. Vermutlich
könnte ich da  aber noch optimieren.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> Diff könnte ich doch einfach von der Kommandozeile aus nutzen,
> was bringt da Quilt? Muss ich mir mal anschauen.

Natürlich kann man diff auch direkt benutzen. Ich finde es aber extrem 
umständlich. Quilt ist halt sehr viel bequemer. Ist anfangs etwas 
verwirrend, aber es ist es wirklich wert sich da reinzudenken.

> Für tar muss ich
> halt nur eine Datei der Files erstellen, klar in "main" muss dann
> der Chip von Hand eingetragen werden. Vor einem diff sollte ich
> wohl jedesmal ein "git clone" durchführen, damit nichts vermischt
> wird.

Genau das verhindert man mit quilt. ;)
Man sagt quilt genau was man "ge-difft" haben will (quilt add).
Quilt hat natürlich noch mehr Features (Patch stacking. Einfaches 
Entfernen und hinzufügen von Patches in den stack, etc...)

> Der At89C51 scheint jetzt zu funktionieren, ich bin aber ziemlich
> genervt, weil die Timingangaben des Datenblattes schlicht
> fehlerhaft sind.

Hehe. Jo. Hab mich auch schon mit fehlerhaften Datenblättern rumärgern 
müssen. :)

> Ich mache noch den AT89C52, der ist identisch, hat nur den doppelten
> Flash. Bei der Testsuite wird es schwierig, weil es die Chips mit
> VPP = 12 V und 5 V gibt. Die Signatur entscheidet.

Testsuite ist ja keine Pflicht. Es ist nur bequem wenn man damit schnell 
ein paar Implementationen durchtesten kann um Fehler auszuschließen oder 
einzugrenzen.

> Du hast Recht, die Ressourcen des S2 sind nicht üppig. Ich wollte zum
> Test neben der SM die 16 Bytes im Block schreibt noch eine SM für
> einzelne Bytes anlegen, das hat schon nicht mehr gepasst. Vermutlich
> könnte ich da  aber noch optimieren.

Ich habe gerade den W29EE011 EEPROM implementiert. Dazu verwende ich 
einen 128 byte Schreibpuffer im FPGA (Mehr oder weniger gezwungenermaßen 
wegen der Timings). Ist zwar etwas frickelig zu implementieren weil die 
FPGA Resourcen wirklich winzig sind, aber es geht. Ist auch noch Platz 
im Block-RAM für mehr Puffer. Man muss halt nur gucken, dass man den 
Puffer ins Block-RAM bekommt.
Der EEPROM hat 128kByte. Lesen geht in ca 35sec und Schreiben in ca 
53sec. Das finde ich OK. Beim Schreiben ist auch noch etwas 
Optimierungspotential.

[Guido (Gast)]

Hallo Michael,

das hört sich ja gut an: Ich habe auch noch einige Flashtypen, die
ich nach und nach einbinden möchte. Den Blockram nutzen wird doch
hoffentlich die Xilinx-Software automatisch? Da hätte ich keine
Idee, wie ich das beeinflussen kann. Irgendwann mal googeln.

Ich hänge im Momnet, habe auch kaum Zeit. Für den 89C52 je ein Bit
mehr für die Adresse und nichts geht mehr. Also habe ich den
Verilogteil für den 89C51 noch mal sauberer geschrieben, jetzt geht
der auch nicht mehr. Irgendwo wohl ein grundsätzlicher Fehler.
Immerhin habe ich eine Version die geht und eine die nicht geht und
muss nur mal rausfinden, wo der funktionale Unterschied liegt.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> das hört sich ja gut an: Ich habe auch noch einige Flashtypen, die
> ich nach und nach einbinden möchte. Den Blockram nutzen wird doch
> hoffentlich die Xilinx-Software automatisch?

Nicht unbedingt. Die Logik muss natürlich so geschrieben sein, dass 
blockram möglich ist. Das hört sich einfach an. Für mich war es aber 
ziemlich kniffelig, weil die Synthese einem nicht wirklich umfangreich 
sagt warum es fehlgeschlagen ist. Sie sagt nur mehr oder weniger das 
es fehlgeschlagen ist. Kann aber auch an meiner fehlenden Erfahrung 
liegen.

Ansonsten kann man block-ram auch explizit programmieren. Siehe dazu 
XAPP173.

In dem appnote stehen auch die Vorraussetzungen für block-ram drin, die 
man natürlich auch bei Verwendung von block-ram durch den synthesizer 
eingehalten muss. Ansonsten implementiert der das automatisch als 
flipflops und gibt nur eine kurze INFO Meldung aus das er es so gemacht 
hat.
(Später im build Prozess läuft das ganze dann natürlich aus dem Ruder, 
weil der Chip nicht so viele flipflops hat).

[Guido (Gast)]

Hallo Michael,

jetzt bin ich ratlos. Ich habe den Fehler eingekreist, es liegt am
Delay in folgendem Zustand der SM:

5: begin /* next byte */
            if (prog_ptr == 15) begin /* all done */
              prog_state <= 6;
            end
            else begin
              prog_ptr <= prog_ptr + 1;
              dut_addr <= dut_addr + 1;  
              prog_state <= 1;
              delay_count <= 200;
            end
          end

Die vollständigen Dateien hänge ich an.

Wenn hier der delay_count <> 200 ist, klappt es nicht. Eigentlich ist
hier gar kein Delay erforderlich, ich wollte nur etwas Zeit einräumen,
bis die Adresse stabil am ZIF-Sockel anliegt. Mein Fehler war, hier
den Delay auf 240 Clocks zu setzen, weil ich dachte, dass dieses das
Kopfrechnen erleichtert.Was das für einen Unterschied macht,
erschließt sich mir nicht.

Verstehst du, was da falsch ist? Mein Verdacht, dass der Python-Teil
wg. meinen Fehlern hier einschlägt hat sich nicht bestätigt, ist aber
auch nicht undenkbar.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> jetzt bin ich ratlos. Ich habe den Fehler eingekreist, es liegt am
> Delay in folgendem Zustand der SM:

Naja, was funktioniert denn hier nicht richtig?

[Guido (Gast)]

Wenn ich delay_count nicht auf 200 setze, sondern z.B auf 120 oder
240, werden beim Schreiben Bytes übergangen (fehlen dann).

[Michael B. (mb_)]

Guido schrieb:
> Wenn ich delay_count nicht auf 200 setze, sondern z.B auf 120 oder
> 240, werden beim Schreiben Bytes übergangen (fehlen dann).

Hört sich stark nach einem Synchronisationsproblem an.

[Michael B. (mb_)]

Im GIT repository (das letzte Release hat es noch nicht) gibts jetzt 
auch vollständige Unterstützung für chips mit mehreren VPPs. Von der 
chip-implementierung hat sich nur ein Punkt geändert: applyVPP() hat 
jetzt einen weiteren Parameter, der angibt welche der VPPs aktiviert 
werden sollen (wenn nichts angegeben wird, werden alle aktiviert).
Mal muss also im Chip konstruktor alle möglichen VPPs angeben, damit der 
generator ein korrektes Layout auf dem ZIF finden kann. Dann aktiviert 
man einen oder mehrere VPPs wie man es gerade braucht via applyVPP().

[Guido (Gast)]

Hallo Michael,

ich habe jetzt kapituliert und schreibe die 51er byteweise.
Ich werde beim nächsten Chip das blockweise Schreiben noch
mal etwas systematischer probieren, vllt. finde ich dann
heraus, was ich falsch gemacht habe. So ist es halt furchtbar
langsam, aber ich habe keine Lust mehr, wochenlang weiterzu-
suchen.

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> ich habe jetzt kapituliert und schreibe die 51er byteweise.
> Ich werde beim nächsten Chip das blockweise Schreiben noch
> mal etwas systematischer probieren, vllt. finde ich dann
> heraus, was ich falsch gemacht habe. So ist es halt furchtbar
> langsam, aber ich habe keine Lust mehr, wochenlang weiterzu-
> suchen.

Es ist natürlich auch möglich (obwohl unwahrscheinlich), dass irgendein 
Befehl etwas Unerwartetes macht. Das Gerät implementiert massenweise 
(noch undokumentierte) Befehle wovon sehr viele ähnliche oder gleiche 
Dinge zu machen scheinen.

Ich bin mir ziemlich sicher, dass einige Befehle timings verändern 
und/oder verschiedene Befehle die scheinbar das gleiche machen andere 
Timings haben. Es ist aber schwer das herauszufinden.

Bisher habe ich aber eigentlich von den dokumentierten Befehlen kein 
einziges Mal ein Fehlverhalten gesehen. Deshalb bin ich mir relativ 
sicher, dass das irgendwo passt.

[Guido (Gast)]

Ich glaube eher, dass ich einen oder mehrere Denkfehler hatte.
Deshalb lieber beim nächsten Chip Schritt für Schritt probieren,
falls das klappt kann ich mir diese 51er ja noch mal vornehmen, die
vom Timnig her wohl auch nicht so unproblematisch sind.

Noch was grundsätzliches: Wenn die Bitfiles eine Kennung augeben
würden, könnte man auf das wiederholte Hochladen derselben verzichten.
Dann bräuchte ich auch die angehängten Verify-Läufe nicht. Im Moment
wäre es noch machbar das bei den bestehenden Designs nachzurüsten.

[Guido (Gast)]

So, anbei die beiden Veteranen. Das geht zwar schnarchlangsam,
aber es funktioniert.

Habe mal den w29ee011 angeschaut. Es geht also doch ohne explizite
Deklaration als RAMB4_S8, hatte nach dem Studium der XAPP173 schon
Zweifel. Sehr gute Idee, die Zuweisung der Daten/Adressen per
Assign im Hauptblock zu erledigen. Vllt. war das der Hauptgrund für
meine Fehler, dass ich krampfhaft versucht habe das mit in die SM
zu stecken. Wieder was dazugelernt :-)

Gruß, Guido

[Michael B. (mb_)]

Guido schrieb:
> So, anbei die beiden Veteranen. Das geht zwar schnarchlangsam,
> aber es funktioniert.
>
> Habe mal den w29ee011 angeschaut. Es geht also doch ohne explizite
> Deklaration als RAMB4_S8, hatte nach dem Studium der XAPP173 schon
> Zweifel.

Ja. Das hat mich aber viele Stunden frickelei gekostet. ;)
Der synthesizer sagt einem halt nicht so richtig warum er die Logik 
nicht als RAM implementieren konnte. Er sagt einem nur das er es nicht 
konnte. Man muss dann selbst seine Gehirnwindungen anstrengen und 
herausfinden was falsch ist.
Für mich als absoluter Anfänger im FPGA Bereich keine leichte Aufgabe.

> Sehr gute Idee, die Zuweisung der Daten/Adressen per
> Assign im Hauptblock zu erledigen. Vllt. war das der Hauptgrund für
> meine Fehler, dass ich krampfhaft versucht habe das mit in die SM
> zu stecken. Wieder was dazugelernt :-)

Naja, die statemachine und das I/O sind halt zwei parallele Prozesse. Es 
gibt dann halt register zur Kommunikation zwischen diesen Prozessen und 
andere Register zur Kommunikation zum Chip hin. Wenn jetzt beide 
Prozesse (I/O und statemachine) auf den Chip zugreifen müssen (was bei 
w29ee011 teilweise der Fall ist), dann wirds halt etwas haarig. Da muss 
dann halt ein wenig kombinatorische Logik her.

Im Grunde ist hier ein FIFO implementiert mit einem schreibenden Prozess 
und einem lesenden Prozess. Das Block-RAM ist ideal für diese Sache, 
weil es genau solch ein Szenario implementieren kann. Mehr dazu im 
Appnote.
Die Startadresse wird einfach nur in ein Register abgelegt aus dem sich 
die statemachine es dann wieder rauskopiert und in seinem eigenen 
Zählregister hochzählt wenn das FIFO lesend durchlaufen wird. Viele 
Teile der statemachine laufen auch unter der Annahme, dass der I/O 
Prozess eben nicht parallel läuft (bis auf eine Ausnahme: Das Lesen 
des busy flags). Das vereinfacht die Sache dann schon etwas.

[Michael B. (mb_)]

Guido schrieb:
> Noch was grundsätzliches: Wenn die Bitfiles eine Kennung augeben
> würden, könnte man auf das wiederholte Hochladen derselben verzichten.

Ich werde die Idee mit der Kennung im FPGA auch aufgreifen. Das ist eine 
sehr gute Idee. Ich war nämlich schon länger am rätseln wie man das 
wiederholte Hochladen der FPGA Konfiguration elegant umschiffen kann. 
Eine auslesbare Kennung scheint mir da ideal.

[Michael B. (mb_)]

Release toprammer-0.5:

Neue features:

* Einführung des neuen "toprammer-unitest" tools. Dieses Tool ermöglicht 
es Pins auf dem ZIF Sockel beliebig zu toggeln, auszulesen, Spannungen 
an Pins anzulegen oder Frequenzen (theoretisch bis 24Mhz, praktisch so 
bis ca 2-3Mhz).
Damit kann man dann irgendwelche Logikchips manuell testen oder ein 
Microcontroller Programm oder oder...
Einfach mal angucken. Hat eine total häßliche GUI. Sollte aber 
weitgehend funktionieren. ;)

* Wesentliche Beschleunigung vieler Funktionen. FPGA config files haben 
jetzt eine Onlinekennung und brauchen somit nur einmal hochgeladen zu 
werden.

* AtTiny 13 (Hab halt noch ein paar davon rumfliegen :)

* Viele fixes hier und da. Für Details siehe GIT log.

Viel Spaß!

http://bu3sch.de/toprammer/toprammer-0.5.tar.bz2

[Michael B. (mb_)]

Es hat lange gedauert, aber jetzt gibts ein neues Release.

Release toprammer-0.6:

* Es wurde eine grafisches Tool eingeführt (toprammer-gui). Vom Aussehen 
und der Funktionalität lehnt es sich etwas an TopWin an.

* Die API wurde geändert und aufgeräumt.

* Verschiedene Bugfixes.

Viel Spaß!

http://bu3sch.de/toprammer/toprammer-0.6.tar.bz2