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...)
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.
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...
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. :)
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.
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.
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 :) )
Hi, interessantes Projekt. In TopWin 6.20 hat sich eine Verilogdatei unter die bit files gemischt:
1 | module pic17dip40std(d,ale,wr,rd,osc12m,pin,RXT,TXT); |
2 | inout [7:0] d; |
3 | input ale; |
4 | input wr; |
5 | input rd; |
6 | input osc12m; |
7 | inout [48:1] pin; |
8 | output TXT; |
9 | input RXT; |
10 | assign TXT=RXT || osc12m; |
11 | |
12 | reg [7:0] sel_in; |
13 | wire [15:0] cy; |
14 | reg [7:0] addr; |
15 | |
16 | always @(negedge ale) |
17 | begin |
18 | addr=d; |
19 | end |
20 | wire AlwaysLo; |
21 | assign AlwaysLo=1'b0; |
22 | assign AlwaysLo= 1'b0; //AlwaysLo always=0 |
23 | |
24 | assign cy[0]=(addr==0+16+128); |
25 | assign cy[1]=(addr==1+16+128); |
26 | assign cy[2]=(addr==2+16+128); |
27 | assign cy[3]=(addr==3+16+128); |
28 | assign cy[4]=(addr==4+16+128); |
29 | assign cy[5]=(addr==5+16+128); |
30 | assign cy[6]=(addr==6+16+128); |
31 | assign cy[7]=(addr==7+16+128); |
32 | assign cy[8]=(addr==8+16+128); |
33 | assign cy[9]=(addr==9+16+128); |
34 | assign cy[10]=(addr==10+16+128); |
35 | assign cy[11]=(addr==11+16+128); |
36 | assign cy[12]=(addr==12+16+128); |
37 | assign cy[13]=(addr==13+16+128); |
38 | assign cy[14]=(addr==14+16+128); |
39 | reg RA0,RA1,OE,en_osc; |
40 | reg [7:0] rb,rc; |
41 | |
42 | |
43 | /*reg [2:0] dev; |
44 | always @(posedge osc12m) |
45 | begin |
46 | dev=dev+1; |
47 | end*/ |
48 | |
49 | always @(posedge wr) |
50 | begin |
51 | if(cy[0]) rb = d; |
52 | if(cy[1]) rc = d; |
53 | |
54 | // if(cy[2] && d[6:0]==1) TEST=d[7]; |
55 | if(cy[2] && d[6:0]==2) RA0=d[7]; |
56 | if(cy[2] && d[6:0]==3) RA1=d[7]; |
57 | if(cy[2] && d[6:0]==4) OE=d[7]; |
58 | if(cy[2] && d[6:0]==5) en_osc=d[7]; |
59 | // if(cy[10]) sel_osc = d; |
60 | if(cy[11]) sel_in = d; |
61 | //--------------------------------add... |
62 | //up active |
63 | end |
64 | wire tp; |
65 | assign tp=sel_in[5]; |
66 | |
67 | bufif0 (pin[21],GND,!AlwaysLo); |
68 | bufif0 (pin[22],1'b1,tp); //ra4 =1 |
69 | bufif0 (pin[23],GND,tp); //ra3=0 |
70 | bufif0 (pin[24],GND,tp); //ra2=0 |
71 | bufif0 (pin[25],RA1,tp); |
72 | bufif0 (pin[26],RA0,tp); |
73 | bufif0 (pin[27],1'b1,tp); //test=1 |
74 | bufif0 (pin[28],GND,!AlwaysLo); |
75 | bufif0 (pin[29],GND,!AlwaysLo); |
76 | bufif0 (pin[30],GND,!AlwaysLo); |
77 | bufif0 (pin[31],GND,tp); //gnd |
78 | bufif0 (pin[32],GND,tp); //vpp |
79 | bufif0 (pin[33],GND,!AlwaysLo); |
80 | bufif0 (pin[34],GND,!AlwaysLo); |
81 | bufif0 (pin[35],GND,!AlwaysLo); |
82 | bufif0 (pin[36],GND,!AlwaysLo); |
83 | bufif0 (pin[37],GND,!AlwaysLo); |
84 | bufif0 (pin[38],GND,!AlwaysLo); |
85 | bufif0 (pin[39],GND,!AlwaysLo); |
86 | bufif0 (pin[40],GND,!AlwaysLo); |
87 | bufif0 (pin[1],GND,tp); //vdd |
88 | bufif0 (pin[2],rc[0],tp|| !OE ); |
89 | bufif0 (pin[3],rc[1],tp|| !OE ); |
90 | bufif0 (pin[4],rc[2],tp|| !OE ); |
91 | bufif0 (pin[5],rc[3],tp|| !OE ); |
92 | bufif0 (pin[6],rc[4],tp|| !OE ); |
93 | bufif0 (pin[7],rc[5],tp|| !OE ); |
94 | bufif0 (pin[8],rc[6],tp|| !OE ); |
95 | bufif0 (pin[9],rc[7],tp|| !OE ); |
96 | bufif0 (pin[10],GND,tp); //gnd |
97 | bufif0 (pin[11],rb[0],tp|| !OE); |
98 | bufif0 (pin[12],rb[1],tp|| !OE); |
99 | bufif0 (pin[13],rb[2],tp|| !OE); |
100 | bufif0 (pin[14],rb[3],tp|| !OE); |
101 | bufif0 (pin[15],rb[4],tp|| !OE); |
102 | bufif0 (pin[16],rb[5],tp|| !OE); |
103 | bufif0 (pin[17],rb[6],tp|| !OE); |
104 | bufif0 (pin[18],rb[7],tp|| !OE); |
105 | bufif0 (pin[19],ale,!en_osc); |
106 | bufif0 (pin[20],GND,!AlwaysLo); |
107 | |
108 | //-------------------------------add... |
109 | reg [7:0] inpin; |
110 | always @(rd or cy or pin) |
111 | begin |
112 | if(cy[0]) inpin=pin[18:11]; |
113 | else if(cy[1]) inpin=pin[9:2]; |
114 | |
115 | else if(cy[6]) inpin=pin[8:1]; |
116 | else if(cy[7]) inpin=pin[16:9]; |
117 | else if(cy[8]) inpin=pin[24:17]; |
118 | else if(cy[9]) inpin=pin[32:25]; |
119 | else if(cy[10])inpin=pin[40:33]; |
120 | end |
121 | |
122 | wire chip_ce; |
123 | assign chip_ce=!rd && addr[7]; |
124 | |
125 | bufif1 (d[0],inpin[0],chip_ce); |
126 | bufif1 (d[1],inpin[1],chip_ce); |
127 | bufif1 (d[2],inpin[2],chip_ce); |
128 | bufif1 (d[3],inpin[3],chip_ce); |
129 | bufif1 (d[4],inpin[4],chip_ce); |
130 | bufif1 (d[5],inpin[5],chip_ce); |
131 | bufif1 (d[6],inpin[6],chip_ce); |
132 | bufif1 (d[7],inpin[7],chip_ce); |
133 | |
134 | |
135 | endmodule |
Eventuell ist´s interessant...
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 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.
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)
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ß.
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>
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:
1 | ./toprammer --help |
2 | Traceback (most recent call last): |
3 | File "./toprammer", line 24, in <module> |
4 | from libtoprammer.toprammer_main import * |
5 | File "/mnt/video/lochome/guido/temp/TOP2049/toprammer-0.2/libtoprammer/toprammer_main.py", line 25, in <module> |
6 | from bitfile import * |
7 | File "/mnt/video/lochome/guido/temp/TOP2049/toprammer-0.2/libtoprammer/bitfile.py", line 22, in <module> |
8 | import pkg_resources |
9 | ImportError: No module named pkg_resources |
Das war der Ausgangspunkt. Dann habe ich halt versucht den Fehler einzugrenzen.
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.
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
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.
Jo, mal wieder unvollständige Daten: Ich meine die Checksumme beim Einlesen von Intel-Hex. Dann werde ich später mal Brennen probieren.
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.
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.
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).
Und jetzt kann ich einzelne Zeilen (je 16 Bytes) brennen. Ich hänge mal meine Änderungen an, das geht sicherlich viel besser.
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?
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.
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.
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
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.
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.
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.
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
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.
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.
Besten Dank, das hilft mit weiter. Vllt. sollten wir noch einen Parameter für toprammer einführen: --ignore_wrong_deviceID
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?
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.
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.
>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.
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.
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.
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.
Schon klar, war nur ein Test. Die Versionsnummer steht im .map-File.
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 $
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.
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
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.
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
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:
1 | reg [7:0] datab [0:63]; |
2 | |
3 | always @(negedge ale) begin |
4 | datab[i] <= data; |
5 | i += 1; |
6 | 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
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.
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.
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.
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
Oops, Crosspost. Der Geschwindigkeitsvorteil wird riesig, da der USB-Transfer auf ein Viertel oder mehr reduziert wird.
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.
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
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
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.
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:
1 | |
2 | bufif0(zif[29], dut_data[7], !dut_OE); /* Q7 */ |
3 | bufif0(zif[30], dut_CE, low); /* CE */ |
4 | bufif0(zif[31], dut_addr[10], low); /* A10 */ |
5 | bufif0(zif[32], dut_OE, dut_VPE); /* OE/VPP */ |
6 | bufif0(zif[33], dut_addr[11], low); /* A11 */ |
7 | bufif0(zif[34], dut_addr[9], dut_VPE); /* A9/VPE */ |
8 | bufif0(zif[35], dut_addr[8], low); /* A8 */ |
9 | bufif0(zif[36], dut_addr[13], low); /* A13 */ |
10 | bufif0(zif[37], dut_addr[14], low); /* A14 */ |
11 | 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.
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.
> 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.
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?
> 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
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.
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
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. :)
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.
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
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.
>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.
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. :)
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.
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
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.
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 ...
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
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.
Ich hoffe, dass jetzt alles passt. Test ist auch dabei (natürlich getestet). Gruß, Guido
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.
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).
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
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.
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
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).
Hallo Michael, jetzt bin ich ratlos. Ich habe den Fehler eingekreist, es liegt am Delay in folgendem Zustand der SM:
1 | 5: begin /* next byte */ |
2 | if (prog_ptr == 15) begin /* all done */ |
3 | prog_state <= 6; |
4 | end
|
5 | else begin |
6 | prog_ptr <= prog_ptr + 1; |
7 | dut_addr <= dut_addr + 1; |
8 | prog_state <= 1; |
9 | delay_count <= 200; |
10 | end
|
11 | 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
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?
Wenn ich delay_count nicht auf 200 setze, sondern z.B auf 120 oder 240, werden beim Schreiben Bytes übergangen (fehlen dann).
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.
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().
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
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.
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.
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
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.
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.
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.