----------8<-----{
20171010-1127-GMT}----->8----------
Nachdem es nicht am Tag der Ankunft
der FPGA-Boards klappte, sie mal anzuschließen, ist es nun eine Nacht später dran...
Einer derer Kandidaten hängt am USB-Port und blinkt friedlich aus einer roten 8-LEDs-Zeile (alle 8 LEDs im Gleichschritt). Die Saft-Strippen sind also ok... \o/
Code: Alles auswählen
$ lsusb | fgrep 0403:
Bus 001 Device 008: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
...die Datenstrippen sind also auch nicht futsch...
Code: Alles auswählen
$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Okt 10 09:46 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Okt 10 09:46 /dev/ttyUSB1
...und es gibt 2 USB-Serielle...
Jetzt mal schau'n ob ich das Icestorm-Beispiel zu diesem Board gebaut und ins RAM des FPGA geschubst bekomme ohne das LED-Blinken im Flash zu überschreiben...
Code: Alles auswählen
$ quiet PATH=/opt/icestorm/bin:$PATH make
$ ls -l
insgesamt 1104
-rw-r--r-- 1 yeti yeti 955450 Okt 10 09:57 example.asc
-rw-r--r-- 1 yeti yeti 135100 Okt 10 09:57 example.bin
-rw-r--r-- 1 yeti yeti 13125 Okt 10 09:57 example.blif
-rw-r--r-- 1 yeti yeti 6628 Okt 10 09:57 example.rpt
-rw-r--r-- 1 yeti yeti 444 Apr 22 17:54 example.v
-rw-r--r-- 1 yeti yeti 134 Apr 22 17:54 hx8kboard.pcf
-rw-r--r-- 1 yeti yeti 514 Apr 22 17:54 Makefile
"*.bin" und Jedöns sind entstanden. Pestens!
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog --help |& fgrep -- -S
/opt/icestorm/bin/iceprog -S <input file>
-S perform SRAM programming
...verrät, was bei...
...noch als Gewürz dazu muß.
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog -S example.bin
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010).
ABORT.
$ sudo /opt/icestorm/bin/iceprog -S example.bin
[sudo] Passwort für yeti:
init..
cdone: high
reset..
cdone: low
programming..
cdone: low
Bye.
Frechigkeit! Ich bin doch in der dialout-Gruppe... das muß ich später nochmal ergründeln...
Alle 8 roten LEDs leuchten nun wie mit halber Kraft und nach Stromlosigkeit kommt das 8-LED-Blinken wieder. Beim mit dem Board rumhampeln schaut das nicht aus, als würden die LEDs nur zu schnell für meine Augen gepulst... ich weiß ja auswendig nicht, mit welcher Taktfrequenz sie durchgezählt werden... insgesamt also seltsam!
Edit@20171014-1630-GMT: 'clk' ist wohl 12MHz, las ich irGÄHNdwo. Ich werd einen Teiler durch Anderes als Zweierpotenzen als eine meiner nächsten Fingerübungen einplanen und dann mal schau'n, z.B. ob ich die LEDs synchron zu einem Sekundenzeiger choreographiert bekomme...
Code: Alles auswählen
$ cat example.v
module top (
input clk,
output LED0,
output LED1,
output LED2,
output LED3,
output LED4,
output LED5,
output LED6,
output LED7
);
localparam BITS = 8;
localparam LOG2DELAY = 22;
reg [BITS+LOG2DELAY-1:0] counter = 0;
reg [BITS-1:0] outcnt;
always @(posedge clk) begin
counter <= counter + 1;
outcnt <= counter >> LOG2DELAY;
end
assign {LED0, LED1, LED2, LED3, LED4, LED5, LED6, LED7} = outcnt ^ (outcnt >> 1);
endmodule
...oder les' ich das nur phallisch phöllsch?
***minutenlang_Fahrstulmusik***
***langes_Plattenspielernadel_quer_über_alle_Rillen_schrapp_Gerräusch***
Irgendwas ist beim "-S" schräg... ohne klappte es dann... und die LEDs blinken nun hübsch mit unterschiedlichen Frequenzen durcheinander...
Jetzt brauch ich erstmal 'ne Pauuuseee... uuuuund Frühstück... schon wieder lange wach und noch ohne Futter... mein Arzt bringt mich um!!! :-P
Vermutlich werd ich dann später mal die Suchente anrufen: "Weiser Verwalter der allwisenden Müllhalde im weißen Federkleid: Warum will "iceprog -S" nicht wie ich will? Liegt es an mir? Am Board? An Icestorm? Muß man beim Laden ins SRAM anders vorgehen? Bekomme ich Mengenrabatt bei so vielen Fragen?"
----------8<-----{
20171010-1713-GMT}----->8----------
—▶
http://www.mouser.com/ds/2/225/lattice_eb85-357777.pdf – Seite 6
Ok... die Jumper hatte ich heut Mitag schon in Verdacht, aber die Zeit am Mittag war zu knapp für "ordentlich". Sowas rächt sich dann mehrfach... :-/
Jetzt klappt Laden ins RAM... \o/
...und das sogar ohne großes Suchentenanrufungsritual...
Nu' kann ich also ohne bei jedem Versuch das Flash abzuwetzen ganz befreit drauflosfehlern... :-D
...und das Laden ins RAM geht zudem noch scheller!
Warum ich "sudo" dafür bemühen muß, bleibt aber noch zu ergründen...
----------8<-----{
20171011-1633-GMT}----->8----------
Ökäÿ... ich hab da mal ein bissl in UDEVs Gesetzen rumgeschraubt...
(alle Zeilen dieser Datei vor den Gezeigten sind leer oder wegkommentiert)
Code: Alles auswählen
$ tail -10 /etc/udev/rules.d/53-lattice-ftdi.rules
##++
## Lattice iCE40HX8K-EVB has the dual FTDI-FD2232 chip and the serial number
## unluckily is unset.
##
## TODO: find out wether it may be flashed to be unique like the single FT232
## can be flashed...
##
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", \
OWNER="yeti", GROUP="yeti", MODE:="0660"
##--
...und das scheint zumindest was die Zugriffsrechte und Besitzverhältnisse angeht den gewünschten Effekt zu haben:
Code: Alles auswählen
$ ls -l /dev/ttyUSB*
crw-rw---- 1 yeti yeti 188, 0 Okt 11 16:00 /dev/ttyUSB0
crw-rw---- 1 yeti yeti 188, 1 Okt 11 16:00 /dev/ttyUSB1
"iceprog" mag dennoch nicht ohne Superwutz-Rechte:
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog -S example.bin
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010).
ABORT.
...aber mit "sudo"-Doping geht's dann...
Code: Alles auswählen
$ sudo /opt/icestorm/bin/iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
...muß ich das versteh'n?
<horrorfilmmusik> Ein grausamer Verdacht:
</horrorfilmmusik>
"iceprog --help" zeigt keinen Weg, das USB-TTY namentlich anzugeben und hat nur eine Option, es über den "device string" zu adressieren:
Code: Alles auswählen
-d <device string> use the specified USB device [default: i:0x0403:0x6010]
d:<devicenode> (e.g. d:002/005)
i:<vendor>:<product> (e.g. i:0x0403:0x6010)
i:<vendor>:<product>:<index> (e.g. i:0x0403:0x6010:0)
s:<vendor>:<product>:<serial-string>
...vielleicht geht das über Kernel-Funktionen oder Schleichwege im SysFS (oder wo steckt "/proc/bus/usb" heute?), die nachwievor Superwutz-Rechte brauchen, egal wie ich den Device-Node in "/dev/" verdrehe?
Summary: HÜÜÜÜLFÄÄÄÄÄHHHHHH?!?!?!?!?!?!??? ... – – – ...
----------8<-----{
20171012-0430-GMT}----->8----------
...selbst "Use the source, Luke!" half mir beim Superwutzproblem mit `iceprog` nicht weiter... ich hab dann erst mit...
Code: Alles auswählen
(yeti@kumari:20)/opt/icestorm/bin$ sudo chown root:dialout iceprog
(yeti@kumari:20)/opt/icestorm/bin$ sudo chmod u+s,g+s,o= iceprog
(yeti@kumari:20)/opt/icestorm/bin$ ls -l iceprog
-rwsr-s--- 1 root dialout 40960 Okt 4 23:18 iceprog
...rumgespielt und das klappte wie erwartet... aber dann fiel mir ein, daß Debian9 ein zwar altes, aber immerhinque "fpga-icestorm"-Paket hat und darin fand ich die UDEV-Regel...
Code: Alles auswählen
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"
"uaccess" ist mir zugegebenerweis' total neu, aber ich habe das einfach mal meiner UDEV-Gesetzgebung statt der bisherigen Stümpereien hinzugefügt und siehe daaaa...
Code: Alles auswählen
$ iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
\\o o// \o/
Also nochmal für's Log:
Code: Alles auswählen
$ cat /etc/udev/rules.d/53-lattice-ftdi.rules
##++
## see fpga-icestorm_*.deb ;-)
##
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"
##--
...alles Andere ist rausgeflogen!
Summary: Immer gleich beim richtigen Vorbild spionieren Du mußt!
Edit@20171012-2108-GMT: Das Alles erklärt aber noch immer nicht, warum dies Gehampel beim FT2232 nötig ist und bei anderen USB-Chips (FT232, CP2102, CH34x) nicht!
----------8<-----{
20171012-1430-GMT}----->8----------
But now for something not really completely different...
Code: Alles auswählen
$ iceprog --help |& awk '/Notes for the iCE40-HX8K/' RS='\n\n'
Notes for the iCE40-HX8K Breakout Board:
Make sure that the jumper settings on the board match the selected
mode (SRAM or FLASH). See the iCE40-HX8K user manual for details.
...das hab ich wohl Dienstag voll überseh'n...
Code: Alles auswählen
$ iceprog --help |& awk '/Notes for iCEstick/' RS='\n\n'
Notes for iCEstick (iCE40HX-1k devel board):
An unmodified iCEstick can only be programmed via the serial flash.
Direct programming of the SRAM is not supported. For direct SRAM
programming the flash chip and one zero ohm resistor must be desoldered
and the FT2232H SI pin must be connected to the iCE SPI_SI pin, as shown
in this picture:
http://www.clifford.at/gallery/2014-elektronik/IMG_20141115_183838
...also das mit dem iCEstick als handliches Drittboard überleg ich mir nochmal!
----------8<-----{
20171012-1502-GMT}----->8----------
Ich glaube, ich seh lamsan wo der Hase lang hoppelt:
Code: Alles auswählen
$ cat hx8kboard.pcf
set_io LEDs[0] B5
set_io LEDs[1] B4
set_io LEDs[2] A2
set_io LEDs[3] A1
set_io LEDs[4] C5
set_io LEDs[5] C4
set_io LEDs[6] B3
set_io LEDs[7] C3
set_io clk J3
$ cat example.v
module top (
input clk,
output [7:0] LEDs // 8-Spurige Autobahn zu den LEDs ;-)
);
//
// die Anzahl der toten LEDs bzw nicht dargestellten Zählerbits:
//
localparam UNSEEN_BITS = 20;
//
// der Zähler ist 8 Bits/LEDs breiter als die UNSEEN_BITS
//
reg [7+UNSEEN_BITS:0] counter = 0;
//
// bei jedem steigenden clk: Gib ihm!
//
always @(posedge clk) begin
counter <= counter + 1;
end
//
// und verdrahte die obersten 8 Bits des Zählers mit den den LEDs
//
assign LEDs = counter[7+UNSEEN_BITS:UNSEEN_BITS];
endmodule
$ cat Makefile
PROJ = example
PIN_DEF = hx8kboard.pcf
DEVICE = hx8k
export PATH := /opt/icestorm/bin:$(PATH)
all: $(PROJ).rpt $(PROJ).bin
%.blif: %.v
yosys -Q -q -p 'synth_ice40 -top top -blif $@' $<
%.asc: $(PIN_DEF) %.blif
arachne-pnr -q -d $(subst hx,,$(subst lp,,$(DEVICE))) -o $@ -p $^
%.bin: %.asc
icepack $< $@
%.rpt: %.asc
icetime -d $(DEVICE) -mtr $@ $<
prog: $(PROJ).bin
iceprog -S $<
clean:
rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
.SECONDARY:
.PHONY: all prog clean
Im "Makefile" nur noch Upload ins RAM ohne "sudo"... "yosys -Q -q" zeigt nur noch Probleme an... "arachne-pnr -q" ist auch nimmer geschwätzig... das spart fast 60 Kilobytes an Output!
Code: Alles auswählen
$ make
yosys -Q -q -p 'synth_ice40 -top top -blif example.blif' example.v
arachne-pnr -d 8k -o example.asc -p hx8kboard.pcf example.blif
icetime -d hx8k -mtr example.rpt example.asc
// Reading input .asc file..
// Reading 8k chipdb file..
// Creating timing netlist..
// Timing estimate: 5.84 ns (171.32 MHz)
icepack example.asc example.bin
$ make prog
iceprog -S example.bin
init..
cdone: high
reset..
cdone: low
programming..
cdone: high
Bye.
...und siehe da: Ein etwas hektisches Binärzähler-LED-Blinken!
Ich wollt ja nicht ewig warten bis die höchstwertige LED mal leuchtet!
:-)
...und eines Tages werd' ich auch mal versteh'n, warum der FT2232 wärmer als das FPGA wird... liegt's an seinem internen Spannungsregler? Vielleicht wird das FPGA ja wärmer als der Dual-FTDI, wenn's mal richtig voll mit "Zeuchs" ist...
----------8<-----{
20171012-2304-GMT}----->8----------
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs )
reg [19:0] counter = 0;
initial LEDs = { 0, 0, 0, 0, 0, 0, 0, 1 };
always @(posedge clk) counter <= counter + 1;
always @(posedge counter[19]) LEDs <= { LEDs[6:0], LEDs[7] };
endmodule
Klappt!
Aber ein Im-Kreis-Lauflicht geht bestimmt auch viel intelligenterer... ich komm da noch drauf... ;-)
----------8<-----{
20171013-0850-GMT}----->8----------
Binärzähler reloaded, diesmal oberkraß naïv...
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [19:0] cdiv = 0;
initial LEDs <= { 0, 0, 0, 0, 0, 0, 0, 0 };
always @(negedge clk ) cdiv[ 0] <= ~cdiv[ 0];
always @(negedge cdiv[ 0]) cdiv[ 1] <= ~cdiv[ 1];
always @(negedge cdiv[ 1]) cdiv[ 2] <= ~cdiv[ 2];
always @(negedge cdiv[ 2]) cdiv[ 3] <= ~cdiv[ 3];
always @(negedge cdiv[ 3]) cdiv[ 4] <= ~cdiv[ 4];
always @(negedge cdiv[ 4]) cdiv[ 5] <= ~cdiv[ 5];
always @(negedge cdiv[ 5]) cdiv[ 6] <= ~cdiv[ 6];
always @(negedge cdiv[ 6]) cdiv[ 7] <= ~cdiv[ 7];
always @(negedge cdiv[ 7]) cdiv[ 8] <= ~cdiv[ 8];
always @(negedge cdiv[ 8]) cdiv[ 9] <= ~cdiv[ 9];
always @(negedge cdiv[ 9]) cdiv[10] <= ~cdiv[10];
always @(negedge cdiv[10]) cdiv[11] <= ~cdiv[11];
always @(negedge cdiv[11]) cdiv[12] <= ~cdiv[12];
always @(negedge cdiv[12]) cdiv[13] <= ~cdiv[13];
always @(negedge cdiv[13]) cdiv[14] <= ~cdiv[14];
always @(negedge cdiv[14]) cdiv[15] <= ~cdiv[15];
always @(negedge cdiv[15]) cdiv[16] <= ~cdiv[16];
always @(negedge cdiv[16]) cdiv[17] <= ~cdiv[17];
always @(negedge cdiv[17]) cdiv[18] <= ~cdiv[18];
always @(negedge cdiv[18]) cdiv[19] <= ~cdiv[19];
always @(negedge cdiv[19]) LEDs[0] <= ~LEDs[0];
always @(negedge LEDs[0] ) LEDs[1] <= ~LEDs[1];
always @(negedge LEDs[1] ) LEDs[2] <= ~LEDs[2];
always @(negedge LEDs[2] ) LEDs[3] <= ~LEDs[3];
always @(negedge LEDs[3] ) LEDs[4] <= ~LEDs[4];
always @(negedge LEDs[4] ) LEDs[5] <= ~LEDs[5];
always @(negedge LEDs[5] ) LEDs[6] <= ~LEDs[6];
always @(negedge LEDs[6] ) LEDs[7] <= ~LEDs[7];
endmodule
...aber es klappt! ;-)
----------8<-----{
20171014-2020-GMT}----->8----------
Mein zweiter
UpDuino war heute im Briefkasten. \o/
Jetzt fehlt nur, daß der
Ultra/UltraPlus-Support für Icestorm und Freunde (Icestorm/Issue #68) eines Tages freundlich per GitHub-Mail bei mir anklopft.
OmmmMMMmmmMMMmmmPtimistisch bleiben... ;-)
----------8<-----{
20171014-2134-GMT}----->8----------
Wie schaut der freundliche Zylone von nebenan?
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [19:0] counter = 0;
reg [13:0] vLEDs = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 };
always @(posedge clk) counter <= counter + 1;
always @(posedge counter[19])
begin
vLEDs <= { vLEDs[12:0], vLEDs[13] };
LEDs <= {
vLEDs[7],
vLEDs[6] | vLEDs[8],
vLEDs[5] | vLEDs[9],
vLEDs[4] | vLEDs[10],
vLEDs[3] | vLEDs[11],
vLEDs[2] | vLEDs[12],
vLEDs[1] | vLEDs[13],
vLEDs[0]
};
end
endmodule
...ich dachte, ich mach's mir einfach: Es gibt 2 LEDs, die Wendepunkte sind und jede andere LED wird auf dem Hin- und Rückweg des Effektes benutzt und dies zähle ich als unterschiedliche LEDs. Somit ist das ein Rundlauf auf 14 virtuellen LEDs, die ich dann frech auf 8 real existierende LEDs abbilde...
Noch bin ich mit jeder Lösung zufrieden, die mich nicht zu mehreren Bildschirmen voll Quelltext zwingt. Ob dies die aus der Sicht des FPGAs optimalen Lösungen sind, werd ich ir
GÄHNdwann später lernen...
----------8<-----{
20171015-1337-GMT}----->8----------
Ok... hier der ir
GÄHNdwo oben mal angekündigte Teiler durch 12000000;
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [7:0] LEDs = 0;
reg [23:0] counter = 0;
always @(posedge clk) counter <= counter < 11999999 ? counter + 1 : 0;
always @(counter)
LEDs <= {
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000
};
endmodule
...wieder aus der Rubrik "naïv, aber läuft": Beim einfachen Mitzählen des Blinkens mit linkem Auge und linker Hirnhälfte während rechtes Auge und Hirnhälfte meine Handy-Uhr überwachen, scheint es 1 Blink pro Sekunde gut zu treffen.
----------8<-----{
20171021-1342-GMT}----->8----------
...die Entscheiiiiidung!!!
Seit das direkt in Verilog verdrahtetes tanzen lassen der 8 LEDs im roten Tütü nun mehr und mehr zur Wiederholungstat wird, brauche ich ein neues Ziel...
Eine UART als Ausgabe statt der LEDs wäre schon nett... aber das wär ein "Gerät", das die ihm auf 8 Leitungen gefütterten Daten seriell rausschubst. Wo kommen diese Daten dann her? Für eine "Hallo FPGA-Welt!"-Fingerübung müssten die Bytes des Textes irgendwie nach und nach in die UART gepumpt werden. Schwupps ist man bei Automaten angelangt...
Die Alternative wäre, dem FPGA einen Prozessor zur Seite zu stellen und der pumpt auf 8 Datenleitungen und einem Clock oder Write-Strobe, vielleicht noch begleitet von einem richtig gesetzten Chip-Select die Textbytes in die UART...
Bekommt die FPGA nun einen Propeller-Beiwagen? Oder umgekehrt?
Die dritte Hirnhälfte meint, den Prozessor könne man ja gleich auch in die FPGA schieben.
Ich kann mich schlicht noch nicht entscheiden...
KommmMMMmmmt Zeit, kommmMMMmmmt Plan!
Munter bleiben! _o/"
----------8<-----{
20171021-1930-GMT}----->8----------
UP5K-Support in Icestorm fängt wieder an zu zucken...
\o/
----------8<-----{
20171023-2222-GMT}----->8----------
The Hobbyists Guide to FPGAs
...na hoffentlich wächst das Tut-Öhrchen noch weiter...
----------8<-----{
20171024-1819-GMT}----->8----------
Initial UltraPlus 5k support #106
\o/
Ja ist denn scho' Weihnachten?
;-)
----------8<-----{
20171025-0901-GMT}----->8----------
FPGA Design From Top to Bottom
...jo mään! Schlau me up! ;-)
...und laut dem Vortragenden im Aufbau:
IceStorm Learner’s Documentation
----------8<-----{20181223-0402-GMT}----->8----------
[Hackaday] Old Game Development IDE Goes FPGA
Anguggen, ausprobieren, staunen!
Zackzack!!!
Dies ist keine Übung!!!
----------8<-----{20181223-1710-GMT}----->8----------
https://8bitworkshop.com/v3.3.0/?=&file ... rm=verilog
...CRT included!
Ich fänd's ja netterer wenn's 'n VGA simulieren würd, aber ok... Spatz macht's trotzdem. Vielleicht krieg ich ja raus, welch Takt dieses virtuelle FPGA hat, um das auf die hier vorhandene Hardware umzurechnen?
Auch hübsch übersichtlich scheinen mir die beiden CPU-Beispiele zu sein:
https://8bitworkshop.com/v3.3.0/?=&file ... rm=verilog
https://8bitworkshop.com/v3.3.0/?=&file ... 0-1127-GMT}----->8----------
Nachdem es nicht am Tag der Ankunft
der FPGA-Boards klappte, sie mal anzuschließen, ist es nun eine Nacht später dran...
Einer derer Kandidaten hängt am USB-Port und blinkt friedlich aus einer roten 8-LEDs-Zeile (alle 8 LEDs im Gleichschritt). Die Saft-Strippen sind also ok... \o/
Code: Alles auswählen
$ lsusb | fgrep 0403:
Bus 001 Device 008: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
...die Datenstrippen sind also auch nicht futsch...
Code: Alles auswählen
$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Okt 10 09:46 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Okt 10 09:46 /dev/ttyUSB1
...und es gibt 2 USB-Serielle...
Jetzt mal schau'n ob ich das Icestorm-Beispiel zu diesem Board gebaut und ins RAM des FPGA geschubst bekomme ohne das LED-Blinken im Flash zu überschreiben...
Code: Alles auswählen
$ quiet PATH=/opt/icestorm/bin:$PATH make
$ ls -l
insgesamt 1104
-rw-r--r-- 1 yeti yeti 955450 Okt 10 09:57 example.asc
-rw-r--r-- 1 yeti yeti 135100 Okt 10 09:57 example.bin
-rw-r--r-- 1 yeti yeti 13125 Okt 10 09:57 example.blif
-rw-r--r-- 1 yeti yeti 6628 Okt 10 09:57 example.rpt
-rw-r--r-- 1 yeti yeti 444 Apr 22 17:54 example.v
-rw-r--r-- 1 yeti yeti 134 Apr 22 17:54 hx8kboard.pcf
-rw-r--r-- 1 yeti yeti 514 Apr 22 17:54 Makefile
"*.bin" und Jedöns sind entstanden. Pestens!
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog --help |& fgrep -- -S
/opt/icestorm/bin/iceprog -S <input file>
-S perform SRAM programming
...verrät, was bei...
...noch als Gewürz dazu muß.
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog -S example.bin
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010).
ABORT.
$ sudo /opt/icestorm/bin/iceprog -S example.bin
[sudo] Passwort für yeti:
init..
cdone: high
reset..
cdone: low
programming..
cdone: low
Bye.
Frechigkeit! Ich bin doch in der dialout-Gruppe... das muß ich später nochmal ergründeln...
Alle 8 roten LEDs leuchten nun wie mit halber Kraft und nach Stromlosigkeit kommt das 8-LED-Blinken wieder. Beim mit dem Board rumhampeln schaut das nicht aus, als würden die LEDs nur zu schnell für meine Augen gepulst... ich weiß ja auswendig nicht, mit welcher Taktfrequenz sie durchgezählt werden... insgesamt also seltsam!
Edit@20171014-1630-GMT: 'clk' ist wohl 12MHz, las ich irGÄHNdwo. Ich werd einen Teiler durch Anderes als Zweierpotenzen als eine meiner nächsten Fingerübungen einplanen und dann mal schau'n, z.B. ob ich die LEDs synchron zu einem Sekundenzeiger choreographiert bekomme...
Code: Alles auswählen
$ cat example.v
module top (
input clk,
output LED0,
output LED1,
output LED2,
output LED3,
output LED4,
output LED5,
output LED6,
output LED7
);
localparam BITS = 8;
localparam LOG2DELAY = 22;
reg [BITS+LOG2DELAY-1:0] counter = 0;
reg [BITS-1:0] outcnt;
always @(posedge clk) begin
counter <= counter + 1;
outcnt <= counter >> LOG2DELAY;
end
assign {LED0, LED1, LED2, LED3, LED4, LED5, LED6, LED7} = outcnt ^ (outcnt >> 1);
endmodule
...oder les' ich das nur phallisch phöllsch?
***minutenlang_Fahrstulmusik***
***langes_Plattenspielernadel_quer_über_alle_Rillen_schrapp_Gerräusch***
Irgendwas ist beim "-S" schräg... ohne klappte es dann... und die LEDs blinken nun hübsch mit unterschiedlichen Frequenzen durcheinander...
Jetzt brauch ich erstmal 'ne Pauuuseee... uuuuund Frühstück... schon wieder lange wach und noch ohne Futter... mein Arzt bringt mich um!!! :-P
Vermutlich werd ich dann später mal die Suchente anrufen: "Weiser Verwalter der allwisenden Müllhalde im weißen Federkleid: Warum will "iceprog -S" nicht wie ich will? Liegt es an mir? Am Board? An Icestorm? Muß man beim Laden ins SRAM anders vorgehen? Bekomme ich Mengenrabatt bei so vielen Fragen?"
----------8<-----{
20171010-1713-GMT}----->8----------
—▶
http://www.mouser.com/ds/2/225/lattice_eb85-357777.pdf – Seite 6
Ok... die Jumper hatte ich heut Mitag schon in Verdacht, aber die Zeit am Mittag war zu knapp für "ordentlich". Sowas rächt sich dann mehrfach... :-/
Jetzt klappt Laden ins RAM... \o/
...und das sogar ohne großes Suchentenanrufungsritual...
Nu' kann ich also ohne bei jedem Versuch das Flash abzuwetzen ganz befreit drauflosfehlern... :-D
...und das Laden ins RAM geht zudem noch scheller!
Warum ich "sudo" dafür bemühen muß, bleibt aber noch zu ergründen...
----------8<-----{
20171011-1633-GMT}----->8----------
Ökäÿ... ich hab da mal ein bissl in UDEVs Gesetzen rumgeschraubt...
(alle Zeilen dieser Datei vor den Gezeigten sind leer oder wegkommentiert)
Code: Alles auswählen
$ tail -10 /etc/udev/rules.d/53-lattice-ftdi.rules
##++
## Lattice iCE40HX8K-EVB has the dual FTDI-FD2232 chip and the serial number
## unluckily is unset.
##
## TODO: find out wether it may be flashed to be unique like the single FT232
## can be flashed...
##
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", \
OWNER="yeti", GROUP="yeti", MODE:="0660"
##--
...und das scheint zumindest was die Zugriffsrechte und Besitzverhältnisse angeht den gewünschten Effekt zu haben:
Code: Alles auswählen
$ ls -l /dev/ttyUSB*
crw-rw---- 1 yeti yeti 188, 0 Okt 11 16:00 /dev/ttyUSB0
crw-rw---- 1 yeti yeti 188, 1 Okt 11 16:00 /dev/ttyUSB1
"iceprog" mag dennoch nicht ohne Superwutz-Rechte:
Code: Alles auswählen
$ /opt/icestorm/bin/iceprog -S example.bin
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010).
ABORT.
...aber mit "sudo"-Doping geht's dann...
Code: Alles auswählen
$ sudo /opt/icestorm/bin/iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
...muß ich das versteh'n?
<horrorfilmmusik> Ein grausamer Verdacht:
</horrorfilmmusik>
"iceprog --help" zeigt keinen Weg, das USB-TTY namentlich anzugeben und hat nur eine Option, es über den "device string" zu adressieren:
Code: Alles auswählen
-d <device string> use the specified USB device [default: i:0x0403:0x6010]
d:<devicenode> (e.g. d:002/005)
i:<vendor>:<product> (e.g. i:0x0403:0x6010)
i:<vendor>:<product>:<index> (e.g. i:0x0403:0x6010:0)
s:<vendor>:<product>:<serial-string>
...vielleicht geht das über Kernel-Funktionen oder Schleichwege im SysFS (oder wo steckt "/proc/bus/usb" heute?), die nachwievor Superwutz-Rechte brauchen, egal wie ich den Device-Node in "/dev/" verdrehe?
Summary: HÜÜÜÜLFÄÄÄÄÄHHHHHH?!?!?!?!?!?!??? ... – – – ...
----------8<-----{
20171012-0430-GMT}----->8----------
...selbst "Use the source, Luke!" half mir beim Superwutzproblem mit `iceprog` nicht weiter... ich hab dann erst mit...
Code: Alles auswählen
(yeti@kumari:20)/opt/icestorm/bin$ sudo chown root:dialout iceprog
(yeti@kumari:20)/opt/icestorm/bin$ sudo chmod u+s,g+s,o= iceprog
(yeti@kumari:20)/opt/icestorm/bin$ ls -l iceprog
-rwsr-s--- 1 root dialout 40960 Okt 4 23:18 iceprog
...rumgespielt und das klappte wie erwartet... aber dann fiel mir ein, daß Debian9 ein zwar altes, aber immerhinque "fpga-icestorm"-Paket hat und darin fand ich die UDEV-Regel...
Code: Alles auswählen
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"
"uaccess" ist mir zugegebenerweis' total neu, aber ich habe das einfach mal meiner UDEV-Gesetzgebung statt der bisherigen Stümpereien hinzugefügt und siehe daaaa...
Code: Alles auswählen
$ iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
\\o o// \o/
Also nochmal für's Log:
Code: Alles auswählen
$ cat /etc/udev/rules.d/53-lattice-ftdi.rules
##++
## see fpga-icestorm_*.deb ;-)
##
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"
##--
...alles Andere ist rausgeflogen!
Summary: Immer gleich beim richtigen Vorbild spionieren Du mußt!
Edit@20171012-2108-GMT: Das Alles erklärt aber noch immer nicht, warum dies Gehampel beim FT2232 nötig ist und bei anderen USB-Chips (FT232, CP2102, CH34x) nicht!
----------8<-----{
20171012-1430-GMT}----->8----------
But now for something not really completely different...
Code: Alles auswählen
$ iceprog --help |& awk '/Notes for the iCE40-HX8K/' RS='\n\n'
Notes for the iCE40-HX8K Breakout Board:
Make sure that the jumper settings on the board match the selected
mode (SRAM or FLASH). See the iCE40-HX8K user manual for details.
...das hab ich wohl Dienstag voll überseh'n...
Code: Alles auswählen
$ iceprog --help |& awk '/Notes for iCEstick/' RS='\n\n'
Notes for iCEstick (iCE40HX-1k devel board):
An unmodified iCEstick can only be programmed via the serial flash.
Direct programming of the SRAM is not supported. For direct SRAM
programming the flash chip and one zero ohm resistor must be desoldered
and the FT2232H SI pin must be connected to the iCE SPI_SI pin, as shown
in this picture:
http://www.clifford.at/gallery/2014-elektronik/IMG_20141115_183838
...also das mit dem iCEstick als handliches Drittboard überleg ich mir nochmal!
----------8<-----{
20171012-1502-GMT}----->8----------
Ich glaube, ich seh lamsan wo der Hase lang hoppelt:
Code: Alles auswählen
$ cat hx8kboard.pcf
set_io LEDs[0] B5
set_io LEDs[1] B4
set_io LEDs[2] A2
set_io LEDs[3] A1
set_io LEDs[4] C5
set_io LEDs[5] C4
set_io LEDs[6] B3
set_io LEDs[7] C3
set_io clk J3
$ cat example.v
module top (
input clk,
output [7:0] LEDs // 8-Spurige Autobahn zu den LEDs ;-)
);
//
// die Anzahl der toten LEDs bzw nicht dargestellten Zählerbits:
//
localparam UNSEEN_BITS = 20;
//
// der Zähler ist 8 Bits/LEDs breiter als die UNSEEN_BITS
//
reg [7+UNSEEN_BITS:0] counter = 0;
//
// bei jedem steigenden clk: Gib ihm!
//
always @(posedge clk) begin
counter <= counter + 1;
end
//
// und verdrahte die obersten 8 Bits des Zählers mit den den LEDs
//
assign LEDs = counter[7+UNSEEN_BITS:UNSEEN_BITS];
endmodule
$ cat Makefile
PROJ = example
PIN_DEF = hx8kboard.pcf
DEVICE = hx8k
export PATH := /opt/icestorm/bin:$(PATH)
all: $(PROJ).rpt $(PROJ).bin
%.blif: %.v
yosys -Q -q -p 'synth_ice40 -top top -blif $@' $<
%.asc: $(PIN_DEF) %.blif
arachne-pnr -q -d $(subst hx,,$(subst lp,,$(DEVICE))) -o $@ -p $^
%.bin: %.asc
icepack $< $@
%.rpt: %.asc
icetime -d $(DEVICE) -mtr $@ $<
prog: $(PROJ).bin
iceprog -S $<
clean:
rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
.SECONDARY:
.PHONY: all prog clean
Im "Makefile" nur noch Upload ins RAM ohne "sudo"... "yosys -Q -q" zeigt nur noch Probleme an... "arachne-pnr -q" ist auch nimmer geschwätzig... das spart fast 60 Kilobytes an Output!
Code: Alles auswählen
$ make
yosys -Q -q -p 'synth_ice40 -top top -blif example.blif' example.v
arachne-pnr -d 8k -o example.asc -p hx8kboard.pcf example.blif
icetime -d hx8k -mtr example.rpt example.asc
// Reading input .asc file..
// Reading 8k chipdb file..
// Creating timing netlist..
// Timing estimate: 5.84 ns (171.32 MHz)
icepack example.asc example.bin
$ make prog
iceprog -S example.bin
init..
cdone: high
reset..
cdone: low
programming..
cdone: high
Bye.
...und siehe da: Ein etwas hektisches Binärzähler-LED-Blinken!
Ich wollt ja nicht ewig warten bis die höchstwertige LED mal leuchtet!
:-)
...und eines Tages werd' ich auch mal versteh'n, warum der FT2232 wärmer als das FPGA wird... liegt's an seinem internen Spannungsregler? Vielleicht wird das FPGA ja wärmer als der Dual-FTDI, wenn's mal richtig voll mit "Zeuchs" ist...
----------8<-----{
20171012-2304-GMT}----->8----------
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs )
reg [19:0] counter = 0;
initial LEDs = { 0, 0, 0, 0, 0, 0, 0, 1 };
always @(posedge clk) counter <= counter + 1;
always @(posedge counter[19]) LEDs <= { LEDs[6:0], LEDs[7] };
endmodule
Klappt!
Aber ein Im-Kreis-Lauflicht geht bestimmt auch viel intelligenterer... ich komm da noch drauf... ;-)
----------8<-----{
20171013-0850-GMT}----->8----------
Binärzähler reloaded, diesmal oberkraß naïv...
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [19:0] cdiv = 0;
initial LEDs <= { 0, 0, 0, 0, 0, 0, 0, 0 };
always @(negedge clk ) cdiv[ 0] <= ~cdiv[ 0];
always @(negedge cdiv[ 0]) cdiv[ 1] <= ~cdiv[ 1];
always @(negedge cdiv[ 1]) cdiv[ 2] <= ~cdiv[ 2];
always @(negedge cdiv[ 2]) cdiv[ 3] <= ~cdiv[ 3];
always @(negedge cdiv[ 3]) cdiv[ 4] <= ~cdiv[ 4];
always @(negedge cdiv[ 4]) cdiv[ 5] <= ~cdiv[ 5];
always @(negedge cdiv[ 5]) cdiv[ 6] <= ~cdiv[ 6];
always @(negedge cdiv[ 6]) cdiv[ 7] <= ~cdiv[ 7];
always @(negedge cdiv[ 7]) cdiv[ 8] <= ~cdiv[ 8];
always @(negedge cdiv[ 8]) cdiv[ 9] <= ~cdiv[ 9];
always @(negedge cdiv[ 9]) cdiv[10] <= ~cdiv[10];
always @(negedge cdiv[10]) cdiv[11] <= ~cdiv[11];
always @(negedge cdiv[11]) cdiv[12] <= ~cdiv[12];
always @(negedge cdiv[12]) cdiv[13] <= ~cdiv[13];
always @(negedge cdiv[13]) cdiv[14] <= ~cdiv[14];
always @(negedge cdiv[14]) cdiv[15] <= ~cdiv[15];
always @(negedge cdiv[15]) cdiv[16] <= ~cdiv[16];
always @(negedge cdiv[16]) cdiv[17] <= ~cdiv[17];
always @(negedge cdiv[17]) cdiv[18] <= ~cdiv[18];
always @(negedge cdiv[18]) cdiv[19] <= ~cdiv[19];
always @(negedge cdiv[19]) LEDs[0] <= ~LEDs[0];
always @(negedge LEDs[0] ) LEDs[1] <= ~LEDs[1];
always @(negedge LEDs[1] ) LEDs[2] <= ~LEDs[2];
always @(negedge LEDs[2] ) LEDs[3] <= ~LEDs[3];
always @(negedge LEDs[3] ) LEDs[4] <= ~LEDs[4];
always @(negedge LEDs[4] ) LEDs[5] <= ~LEDs[5];
always @(negedge LEDs[5] ) LEDs[6] <= ~LEDs[6];
always @(negedge LEDs[6] ) LEDs[7] <= ~LEDs[7];
endmodule
...aber es klappt! ;-)
----------8<-----{
20171014-2020-GMT}----->8----------
Mein zweiter
UpDuino war heute im Briefkasten. \o/
Jetzt fehlt nur, daß der
Ultra/UltraPlus-Support für Icestorm und Freunde (Icestorm/Issue #68) eines Tages freundlich per GitHub-Mail bei mir anklopft.
OmmmMMMmmmMMMmmmPtimistisch bleiben... ;-)
----------8<-----{
20171014-2134-GMT}----->8----------
Wie schaut der freundliche Zylone von nebenan?
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [19:0] counter = 0;
reg [13:0] vLEDs = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 };
always @(posedge clk) counter <= counter + 1;
always @(posedge counter[19])
begin
vLEDs <= { vLEDs[12:0], vLEDs[13] };
LEDs <= {
vLEDs[7],
vLEDs[6] | vLEDs[8],
vLEDs[5] | vLEDs[9],
vLEDs[4] | vLEDs[10],
vLEDs[3] | vLEDs[11],
vLEDs[2] | vLEDs[12],
vLEDs[1] | vLEDs[13],
vLEDs[0]
};
end
endmodule
...ich dachte, ich mach's mir einfach: Es gibt 2 LEDs, die Wendepunkte sind und jede andere LED wird auf dem Hin- und Rückweg des Effektes benutzt und dies zähle ich als unterschiedliche LEDs. Somit ist das ein Rundlauf auf 14 virtuellen LEDs, die ich dann frech auf 8 real existierende LEDs abbilde...
Noch bin ich mit jeder Lösung zufrieden, die mich nicht zu mehreren Bildschirmen voll Quelltext zwingt. Ob dies die aus der Sicht des FPGAs optimalen Lösungen sind, werd ich ir
GÄHNdwann später lernen...
----------8<-----{
20171015-1337-GMT}----->8----------
Ok... hier der ir
GÄHNdwo oben mal angekündigte Teiler durch 12000000;
Code: Alles auswählen
module top ( input clk, output [7:0] LEDs );
reg [7:0] LEDs = 0;
reg [23:0] counter = 0;
always @(posedge clk) counter <= counter < 11999999 ? counter + 1 : 0;
always @(counter)
LEDs <= {
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000,
counter < 6000000
};
endmodule
...wieder aus der Rubrik "naïv, aber läuft": Beim einfachen Mitzählen des Blinkens mit linkem Auge und linker Hirnhälfte während rechtes Auge und Hirnhälfte meine Handy-Uhr überwachen, scheint es 1 Blink pro Sekunde gut zu treffen.
----------8<-----{
20171021-1342-GMT}----->8----------
...die Entscheiiiiidung!!!
Seit das direkt in Verilog verdrahtetes tanzen lassen der 8 LEDs im roten Tütü nun mehr und mehr zur Wiederholungstat wird, brauche ich ein neues Ziel...
Eine UART als Ausgabe statt der LEDs wäre schon nett... aber das wär ein "Gerät", das die ihm auf 8 Leitungen gefütterten Daten seriell rausschubst. Wo kommen diese Daten dann her? Für eine "Hallo FPGA-Welt!"-Fingerübung müssten die Bytes des Textes irgendwie nach und nach in die UART gepumpt werden. Schwupps ist man bei Automaten angelangt...
Die Alternative wäre, dem FPGA einen Prozessor zur Seite zu stellen und der pumpt auf 8 Datenleitungen und einem Clock oder Write-Strobe, vielleicht noch begleitet von einem richtig gesetzten Chip-Select die Textbytes in die UART...
Bekommt die FPGA nun einen Propeller-Beiwagen? Oder umgekehrt?
Die dritte Hirnhälfte meint, den Prozessor könne man ja gleich auch in die FPGA schieben.
Ich kann mich schlicht noch nicht entscheiden...
KommmMMMmmmt Zeit, kommmMMMmmmt Plan!
Munter bleiben! _o/"
----------8<-----{
20171021-1930-GMT}----->8----------
UP5K-Support in Icestorm fängt wieder an zu zucken...
\o/
----------8<-----{
20171023-2222-GMT}----->8----------
The Hobbyists Guide to FPGAs
...na hoffentlich wächst das Tut-Öhrchen noch weiter...
----------8<-----{
20171024-1819-GMT}----->8----------
Initial UltraPlus 5k support #106
\o/
Ja ist denn scho' Weihnachten?
;-)
----------8<-----{
20171025-0901-GMT}----->8----------
FPGA Design From Top to Bottom
...jo mään! Schlau me up! ;-)
...und laut dem Vortragenden im Aufbau:
IceStorm Learner’s Documentation
----------8<-----{
Mehr...}----->8----------