HIVE-Project

Retro Style Eigenbau Computer mit Parallax Propeller
Aktuelle Zeit: So 25. Aug 2019, 21:42

Alle Zeiten sind UTC [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 4 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Do 5. Okt 2017, 13:34 
Offline
Benutzeravatar

Registriert: Fr 27. Aug 2010, 14:48
Beiträge: 1901
Wohnort: Wrong Planet
----------8<-----{20170422-1849-GMT}----->8----------

http://www.clifford.at/icestorm/

...hat hier jemand damit schon Erfahrung?

Die Toolchain hab ich unter Debian8 gebaut und die Beispiele scheine ich damit übersetzen zu können, hier stellvertretend eines davon:
Code:
(ruth@kumari:25)/opt/icestorm/src/icestorm/examples/hx8kboard$ make clean
rm -f example.blif example.asc example.rpt example.bin
(ruth@kumari:25)/opt/icestorm/src/icestorm/examples/hx8kboard$ make PATH=/opt/icestorm/bin:$PATH |& cat >/tmp/log
(ruth@kumari:25)/opt/icestorm/src/icestorm/examples/hx8kboard$ ls -l /tmp/log
-rw-r--r-- 1 ruth ruth 53802 Apr 22 18:51 /tmp/log
...ok... das ist zu lang zum hier zitieren...
Code:
(ruth@kumari:25)/opt/icestorm/src/icestorm/examples/hx8kboard$ ls -l
insgesamt 1108
-rw-r--r-- 1 ruth ruth 955450 Apr 22 18:37 example.asc
-rw-r--r-- 1 ruth ruth 135100 Apr 22 18:37 example.bin
-rw-r--r-- 1 ruth ruth  18003 Apr 22 18:37 example.blif
-rw-r--r-- 1 ruth ruth   6628 Apr 22 18:37 example.rpt
-rw-r--r-- 1 ruth ruth    444 Apr 22 17:54 example.v
-rw-r--r-- 1 ruth ruth    134 Apr 22 17:54 hx8kboard.pcf
-rw-r--r-- 1 ruth ruth    514 Apr 22 17:54 Makefile
Es könnte also sein, daß alsbald mal ein passendes Board her muß.
Ooookayyy... es eilt nicht wirklich, aber ich fürchte, lange werd ich am Thema FPGA nimmer vorbei kommen... wobei der Antagonist (die dunkle Energie in meiner ewig beschleunigt expandierenden MachMichMalListe) ja auch nicht untätig ist... :-/

....oder sollt ich doch lieber gleich die Sägen streicheln?

----------8<-----{20170423-0340-GMT}----->8----------

Hackaday hat eine Serie über FPGA-en mit dem Lattice iCEstick:

[Hackaday] Learning Verilog for FPGAs

...die Suchergebnisse werden in der Reihenfolge "jüngste Folge zuerst angezeigt".

----------8<-----{20170423-0404-GMT}----->8----------

Olimexs "Get started under Linux" zu ihrem iCE40HX1K-EVB ist auch mal ein Überfliegen wert.

Der Einsatz eines Olimexschen Leonado-Clones stößt mir dabei aber übel auf. Die notwendige Firmware für den Leonardo-Clone und das dazu passende Tool fürs Hochladen werden nicht mit dem Rest von Icestorm synchron gepflegt, können also divergieren.

----------8<-----{20170424-0915-GMT}----->8----------

Olimex's "Getting started with FPGA with only Free and Open source software and hardware tools tutorial" entspricht in weiten Teilen obig erwähntem Text, hat aber eine hoffentlich irgendwann erfüllte Ankündigung am Ende:
Zitat:
Next tutorial will be how to use iCE40HX1K-EVB with A20-OLinuXino-MICRO as both host for the IceStorm tool and programmer via UEXT connector with just cable and what additional options it gives like loading the code directly to FPGA whthout using SPI flash and your can change FPGA code in milliseconds.
Wenn das klärt, wie man das Olimexsche USB-lose iCEHX1K-EVB ohne Leonardo-Clone beschickt, dann ist das vielleicht auch auf Cubienchen & PIs übertragbar.

Vielleicht käm ich dann ja doch in Versuchung...

...aber noch schiele ich eher in Richtung Latticesches iCEHX8K Evalboard. Die iCE40-FPGAs scheinen nicht sooooo die fetten Teile zu sein. Irgendwo las ich, ein Z80-Core fülle ein iCEHX8K schon rund zur Hälfte, da ist die Idee, mit iCEHX1K anzufangen doch vielleicht schnell eine Sackgasse.

----------8<-----{20170426-0536-GMT}----->8----------

...but zwischendurch mal something nicht wirklich completely different...

https://wiki.debian.org/FPGA erwähnt die Tools, die ich aus Quellen selber backte (yosys, arachne-pnr, icestorm) als ab Debian/Stretch (derzeit in Status "Testing") verfügbare Debianpakete und ein Paket (fpgatools), das derzeit nur den Xilinx XC6SLX9 unterstützt und in dessen Quellen man derzeit "Latest commit b7fdb3e on 10 Jul 2015" lesen darf. In Icestorms Quellen liest man derzeit "Latest commit 587363b 3 days ago" und die gemeldete Winzigkeit wurde binnen weniger Stunden gefixt. Vertrauensfördernd!

----------8<-----{20170426-0558-GMT}----->8----------

CPLD vs FPGA

FPGAs are better known than CPLDs, but they share many characteristics. This analogy isn’t perfect, but we like it: where FPGAs are a reprogrammable processor core, a CPLD is a reprogrammable circuit board or breadboard. FPGAs replace microcontrollers, memory, and other components. CPLDs absorb logic ICs, and work well with a microcontroller.
Ok. Bleibt zu klären, ob es für CPLDs auch Tools als freie Software auch in der Unixelt gibt...

CPLD-Infos bitte in einem eigenen Thread sammeln.

----------8<-----{20170427-0630-GMT}----->8----------

...wenn ich eines Tages weiß, was ich tu', dann wird Folgendes interessant:

[Hackaday] FPGAs in C with Cynth

----------8<-----{20170427-1845-GMT}----->8----------

[GitHub] Public examples of ICE40 HX8K examples using Icestorm

...langsam denke ich, der Würfel ist gefallen: Es wird ein ICE40-HX8K-Board. Wenn mich der Hafer zu sehr sticht, vielleicht ein HX1K-Board zusätzlich oder HX1K später oder wie auch ommmMMMmmmMMMmmm...

----------8<-----{20170428-1135-GMT}----->8----------

[OpenTechLab] 002 - Testing the Linux Kernel driver for the Lattice iCE40 FPGA

...direkter Anschluß eines ICE40-FPGAs per SPI an einen PI und das "Wie sage ich es meinem Kernel?"...

Das ist sicher nicht binnen der nächsten wenigen Wochen ein Thema für mich, aber den Link hierauf festhalten könnt lohnen... ;-)

----------8<-----{20170620-2017-GMT}----->8----------

...es tut sich was in Sachen nächstgrößere FPGAs: https://github.com/cliffordwolf/icestorm/issues/68#issuecomment-309668850 \o/

----------8<-----{20170707-2200-GMT}----->8----------

P1V?

    Icestorm?

        iCE40HX8K?


            ***Lauscher_aufstell...***

Jenen Thread sollt ich mal im Auge behalten...
;-)

...sollte jenes etwa bedeuten, daß ein P1V in einen iCE40HX8K paßt?

----------8<-----{20170710-1722-GMT}----->8----------

Nööö!

...in den iCE40HX8K paßt kein voller P1V.

Eher nur rund 1/4 davon.

...also weiter auf Support für größere FPGAs in Icestorm hoffen...

----------8<-----{20170802-1500-GMT}----->8----------

FPGA-Boards kommen langsam in interessante Preisbereiche:

—▶ http://gnarlygrey.atspace.cc/development-platform.html#upduino

Der darin verwendete Chip wird noch nicht von Icestorm unterstützt, aber bleiben wir da mal ommmmmmmmmmmmPtimistisch...

----------8<-----{20171004-2338-GMT}----->8----------

Södele... heute fand ich den ersten UpDuino im Briefkasten. Bestellt hatte ich via oben erwähntem 8US$-Link und das klappte doch tatsächlich. \o/
Ich hatte zunächst ein paar Zweifel, denn das selbe Board soll bei Ebay nicht nur mehr als diese 8US$ kosten, sondern es käme nochmal spürbar mehr als dessen Preis als Porto obendrauf. Da es aber via den 8US$-Link geklappt hat, will ich noch eines aus der Quelle bunkern. Das ist auch schon bestellt... ;-)

Der Icestorm-Support für dies Board bzw dessen Chip steckt noch unvollendet im Dornröschenschlaf, aber das wird/kann/darf/soll/muß (für Sie nicht Zutreffendes übermalen Sie bitte auf Ihrem Bildschirm mit handelsüblicher Korrekturflüssigkeit)  sich ja noch ändern... und wenn nicht, dann war 2mal 8US$ auch keine in den Sand gesetzte Summe, die mich zu Wasser und Brot zwingen wird.

...und eine Bestellung für 2 Lattice-Boards mit dem größten derzeit von Icestorm unterstützten Chip, also iCE40HX8K, ist auch grad rausgegangen!
Bloß schnell handeln bevor mich der Elan wieder verläßt... :-P ...dachte es in mir.
Denn: Für lange Winterabende vorsorgen ich muß und die Herbst-Equinox schon vorbei sie ist! ;-)

Das wird ein Gefühl wie Einschulung werden... das Thema FPGA ist für mich totales #Neuland...

----------8<-----{20171006-1427-GMT}----->8----------

Ja Himmiherrgottsakra...usw...etc...pp...et-al...!!!

Laut FedEx-Tracking ward zunächst hochgerechnet, die Boards kämen Montag an. Eben seh ich aber im Paketstalker, daß Mister FedEx mich heute schon verpaßt hat.

Mittwoch spät am Abend (nach hiesiger Zeit) in Texas eingesammelt, Donnerstag Zwischenstop in Memphis/Tennesee, Freitag Zwischenstopp in Frankreich, dann Hannover, Braunschweig und etwas später vergeblich vor meiner Tür. Welchem Rennkuckuck habense denn das Paket auf'n Rücken geschnallt? Und vermutlich war der letzte Sturm dann Rückenwind für den Rennkuckuck...

Ok... Samstags nix FedEx-Retry... also Montag erreichbar sein... so war die ursprüngliche Hochrechnung am Ende dann doch richtig... aber wennse das wußten, warum habense das heute überhaupt probiert?

Fraaagen über Fraaagen...

----------8<-----{20171007-0630-GMT}----->8----------

[github.com/Obijuan] Digital Design for FPGAs, with free tools ... schaut erstmal gut aus und mit ein bissl Eigendenken sollten sich die Beispiele auch auf den größeren iCE40-Chip übertragen lassen. Wenn nicht, dann muß doch noch ein ICESTICK her...

----------8<-----{20171007-0855-GMT}----->8----------

Auch andere Mütter haben schöne Boards und ein Forum mit netten Ideen...

—▶ Retro-Computing with BlackIce

...aber erstmal die Fingerübungen auf dem Lattice-Board!

----------8<-----{0171009-0712-GMT}----->8----------

Tadddddaaaaaa... das Paket ist da... aber es darf sich erstmal in Ruhe hier akklimatisieren, denn ich hab noch ein paar höher priorisierte Aktionen zu erledigen, bevor ich mich darauf stürzen kann...

----------8<-----{0171009-1635-GMT}----->8----------

Ooooberkraß: Eine Programmiersprache mit embedded Verilog statt embedded Assembler wie in anderen Sprachen:

—▶ Exploring High-Level Synthesis on ICE40

----------8<-----{Auf gar keinen Fall hier klicken!!!}----->8----------

_________________
"Vrijdag voor VT100!" — Yeti.
"There is no PLANET-B!" — ???


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Los geht's...
BeitragVerfasst: Mo 23. Okt 2017, 23:35 
Offline
Benutzeravatar

Registriert: Fr 27. Aug 2010, 14:48
Beiträge: 1901
Wohnort: Wrong Planet
----------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:
$ 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:
$ 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:
$ 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:
$ /opt/icestorm/bin/iceprog --help |& fgrep -- -S
       /opt/icestorm/bin/iceprog -S <input file>
  -S                    perform SRAM programming
...verrät, was bei...
Code:
$ make -n prog
iceprog example.bin
...noch als Gewürz dazu muß.
Code:
$ /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:
$ 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:
$ 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:
$ 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:
$ /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:
$ 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:
  -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:
(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:
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:
$ iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
\\o   o//   \o/

Also nochmal für's Log:
Code:
$ 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:
$ 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:
$ 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:
$ 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:
$ 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:
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:
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:
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 irGÄHNdwann später lernen...

----------8<-----{20171015-1337-GMT}----->8----------

Ok... hier der irGÄHNdwo oben mal angekündigte Teiler durch 12000000;
Code:
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=chardisplay.v&platform=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=cpu8.v&platform=verilog
[url]https://8bitworkshop.com/v3.3.0/?=&file=cpu16.v&p----------8<-----{[url=https://www.youtube.com/watch?v=dV4yHbese8w]20171010-1127-GMT[/url]}----->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:
$ 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:
$ 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:
$ 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:
$ /opt/icestorm/bin/iceprog --help |& fgrep -- -S
       /opt/icestorm/bin/iceprog -S <input file>
  -S                    perform SRAM programming
...verrät, was bei...
Code:
$ make -n prog
iceprog example.bin
...noch als Gewürz dazu muß.
Code:
$ /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:
$ 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:
$ 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:
$ 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:
$ /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:
$ 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:
  -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:
(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:
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:
$ iceprog -S example.bin
init..
cdone: low
reset..
cdone: low
programming..
cdone: high
Bye.
\\o o// \o/

Also nochmal für's Log:
Code:
$ 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:
$ 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:
$ 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:
$ 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:
$ 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:
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:
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:
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 irGÄHNdwann später lernen...

----------8<-----{20171015-1337-GMT}----->8----------

Ok... hier der irGÄHNdwo oben mal angekündigte Teiler durch 12000000;
Code:
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----------

_________________
"Vrijdag voor VT100!" — Yeti.
"There is no PLANET-B!" — ???


Nach oben
 Profil  
 
BeitragVerfasst: So 23. Dez 2018, 18:20 
Offline
Benutzeravatar

Registriert: Fr 27. Aug 2010, 14:48
Beiträge: 1901
Wohnort: Wrong Planet
----------8<-----{20181223-0402-GMT}----->8----------

[Hackaday] Old Game Development IDE Goes FPGA

Anguggen, ausprobieren, staunen!
Zackzack!!!
Dies ist keine Übung!!!

----------8<-----{20181223-1720-GMT}----->8----------

https://8bitworkshop.com/v3.3.0/?=&file=chardisplay.v&platform=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 iCE40-Ingeskirche-Hardware umzurechnen? Ein 320x240-PAL/NTSC-TFT-Minimonitörchen ist ja griffbereit für solch Spielereien. (Der wurd mir zwar als 640x480 angedreht und ich wollt den zum 80-mal-Aischesmoschee-Terminal machen, was dann an der Auflösung scheiterte, aber das ist so lange her, daß es verjährt ist.)

Auch hübsch übersichtlich scheinen mir die beiden CPU-Beispiele zu sein:

https://8bitworkshop.com/v3.3.0/?=&file=cpu8.v&platform=verilog
https://8bitworkshop.com/v3.3.0/?=&file=cpu16.v&platform=verilog

----------8<-----{20181223-2300-GMT}----->8----------

Also echt jetzt!
Sogar der schüchterne Zylone guggt ganz brav:
Dateianhang:
20181223-224438-GMT--8bitworkshop--cylon.v.png
20181223-224438-GMT--8bitworkshop--cylon.v.png [ 64.01 KiB | 2035-mal betrachtet ]
Dateianhang:
cylon.v.txt [529 Bytes]
112-mal heruntergeladen
Das LED[...]-Array meiner im zweiten Beitrag erwähnten FPGA-Zylone-Demo wollt die IDE als ein Signal mit Werten 0..255 ausgeben, also hab ich mal die kolossale Tipparbeit investiert, dies in einzeln getaufte Signale zu zerlegen. Den Vorteiler für die 12MHz der echten Hardware hab ich auch rausgekickt und noch immer keine Ahnung über die Zeitbasis der Simulation, aber das Rumspielen damit macht macht davon unbeleckt deutlich Spatz!

----------8<-----{Muh!}----->8----------

_________________
"Vrijdag voor VT100!" — Yeti.
"There is no PLANET-B!" — ???


Nach oben
 Profil  
 
BeitragVerfasst: Sa 23. Feb 2019, 23:04 
Offline
Benutzeravatar

Registriert: Fr 27. Aug 2010, 14:48
Beiträge: 1901
Wohnort: Wrong Planet
----------8<-----{20181227-1853-GMT}----->8----------

Nachdem ich Ewigkeiten nicht den Hintern hoch bekam (das Leben über einem lokalen Gravitationsmaximum ist schon echt hart!) zu ertüfteln, wie ich den UpDuino1 in Gang bekomme, hab ich Ende November einen UpDuino2 bestellt, der im Gegensatz zum UpDuino1 einen FTDI-Helfer besitzt. Er kam dann nach ungefähr 3,571 Wochen Wanderschaft heute an (es gab unterwegs scheinbar ganz viel Xmatsch auf den Wegen) und ich konnte ihm auch als Testlauf ein RGB-Blinken entlocken.

—▷ http://www.gnarlygrey.com
—▷ https://github.com/gtjennings1/UPDuino_v1_0
—▷ https://github.com/gtjennings1/UPDuino_v2_0

Meine selbst verordneten Symmetriegesetze erforderten dann eine sofortige Bestellung eines weiteren Solchen. ;-)

Ich hoffe, ich kann am UpDuino2 genug abguggen um mit den rumliegenden FTDI-losen UpDuini1 endlich direkt per SPI inne Puschen zu kommen.

Was mir rund um die UpDuini noch ein Riesenmysterium ist, schieb ich noch 'ne Weile vor mir her und alldieweil wächst vielleicht auch etwas mehr Dokumentation dazu:

—▷ https://github.com/gtjennings1/HyperBus

8 Megabytes RAM und es gibt eine damit funktionierende RISC-V-Implementierung.

Das Leben bleibt also auch 2019 spannend, aber Santa hat natürlich wieder mal den schon seit mindestens einem Jahrzehnt auf meinem Wunschzettel stehenden 100-Stunden-Tag vergessen endlich zu liefern oder war eher Rudi schuld?

----------8<-----{20190223-2203-GMT}----->8----------

Freunde der FPGAs und der mehrfach verknoteten Stacks, es gibt da etwas vermutlich echt hübsches, das ich aber noch nicht die Zeit fand auszuprobieren:

[github] Mecrisp-Ice Forth running on 16bit j1a processor (iCE40UP5k based UPduino board) with full 15kB of bram and 48bit Floating Point Library.

Die Warmduscherversion des zugrunde liegenden FPGA-Boards (Upduino2) kostet weniger als ein Original-Arduino⁽¹⁾ und ist dank Onboard-FTDI vergleichbar handlich.

Dank iCE40-Chip und freier Toolchain hierfür sollte auch den ansonsten oft genug ausgegrenzten Unixern nichts im Wege stehen, damit zu spielen. Das Binary ließ sich problemlos (auf Debian9) bauen, es auszuprobieren steht aber noch unabgeholt mit den Armen um Aufmerksamkeit wedelnd auf meiner Mach-Mich-Mal-Am-Besten-Sogar-Schon-Gestern-Du-Alter-Hänger-Liste (Dark Energy Inside!).

——————————
(1): Ich hab vor wenigen Monaten US-$16,12 bezahlt.

----------8<-----{20190824-1248-GMT}----->8----------

Mal im Auge behalten: https://github.com/ranzbak/fpga-workshop

Dies (noch unvollendete?) Kürsle basiert direkt auf Icestorm und UpDuino2, dürfte also derzeit so ziemlich der günstigste Einstieg sein.

...aber vor die `configure / make / make install`-Anleitung bitte nicht ernst nehmen. Es kostet nur wenig Tippserei und fast kein Hirnschmalz zusätzlich, die Toolchain so zu kompilieren, daß sie a) fast ohne Superwutzrechte und b) nicht wüst ins System installiert wird, wo man sie nicht wirklich leicht wieder raus bekommt.

Stichwort `configure --prefix=/opt/fpgatoolchain`.

----------8<-----{Fochtsetzung folcht...}----->8----------

_________________
"Vrijdag voor VT100!" — Yeti.
"There is no PLANET-B!" — ???


Zuletzt als neu markiert von yeti am Sa 23. Feb 2019, 23:04.


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 4 Beiträge ] 

Alle Zeiten sind UTC [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de