FPGA oder: Denn er weiß nicht, was er tut...

Alles andere hier herein
Antworten
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

----------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: Alles auswählen

(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: Alles auswählen

(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:
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----------
[Hackaday] How-to: Programmable logic devices (CPLD) hat geschrieben: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/icestor ... -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/developmen ... ml#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----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: Los geht's...

Beitrag von yeti »

----------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...

Code: Alles auswählen

$ make -n prog
iceprog example.bin
...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 irGÄHNdwann später lernen...

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

Ok... hier der irGÄ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...

Code: Alles auswählen

$ make -n prog
iceprog example.bin
...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 irGÄHNdwann später lernen...

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

Ok... hier der irGÄ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----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

----------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 ... 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 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 ... rm=verilog
https://8bitworkshop.com/v3.3.0/?=&file ... rm=verilog

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

Also echt jetzt!
Sogar der schüchterne Zylone guggt ganz brav:
20181223-224438-GMT--8bitworkshop--cylon.v.png
cylon.v.txt
(529 Bytes) 611-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----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

----------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----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

Hat hier vielleicht jemand mehr Durchblick in Sachen FPGAs?
Wie schaut's aus mit den größten ECP5-Chips?
Würde ein P1V oder gar P2 da rein passen?
Die FOSS Toolchain für ECP5 scheint zu wachsen.
Irgendwo sah ich schon ein RISCV-Beispiel dafür, also konvergiert sie wohl langsam gegen "brauchbar".

Ok: Bei meinem derzeitigen FPGA-Wissen bin ich noch weit von CPUs entfernt, aber mal andersrum: Wir betreiben auch andere Geräte mit Firmware, die wir nicht selber verstehen, also dürfte ein FPGA, in das wir eine von jemand anders gebaute "P1V-Verdrahtung" reinladen uns auch nicht wirklich erschrecken.

...und irgendwie hätte ich derzeit noch immer lieber einen P1++ mit mehr Pins und vielleicht noch sowas wie integriertem XMM (selbst wenn's nur 64..512kBytes wären), als einen P2.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von thiloa »

yeti hat geschrieben:Würde ein P1V oder gar P2 da rein passen?
Ich hab mal den P1V Verilog Quelltext mit minimalen Modifikationen meinerseits durch yosys laufen lassen (mit synth_ecp5). Das hat er als nötige Ressourcen ausgegeben:

Code: Alles auswählen

DP16KD                         32 Dual Port Mems
PDPW16KD                        8 Dual Port Mems
CCU2C                         896 Carry Chain
L6MUX21                      4549 Mux 2:1
PFUMX                        9466 Mux 2:1
LUT4                        28074 Lookup Tables
TRELLIS_FF                   5242 Flip Flop
Also mal eine grobe Abschätzung meinerseits (für eine exakte und belastbare Aussage hätte man das platzieren müssen, da wäre aber mehr manuelle Arbeit erforderlich gewesen):

Man braucht also 32+8 =40 Block Rams, womit mindestens ein LFE5U-25 erforderlich ist, der 56 davon hat.

Bei den Logic Cells kann man nur abschätzen. Im schlimmsten (aber sehr unwahrscheinlichen) Fall sind es 896+4549+9466+28074+5242 = 48227 Logic Cells. In der Praxis werden viele Flip Flops und Carry Chains zusammen mit Luts in eine Zelle gepackt werden können. Damit ist der LFE5U-25 definitiv zu klein und man bräuchte mindestens den LFE5U-45 was aber extrem knapp wird oder gerade nicht geht. Je nach Taktfrequenz wird man den FPGA auch niemals zu 100% füllen können. Eventuell muss man also auch einen LFE5U-85 nutzen.

Insgesamt bin ich recht begeistert wie gut yosys den Block Ram aus dem Verilog Code extrahiert hat. Bei den LUTs hängt es den kommerziellen Tools wohl (auch nach Eigenaussage) etwas hinterher. Die Anzahl könnte man evtl. durch manuelle Nacharbeit noch etwas drücken. Eventuell würde man es dann sogar gerade noch auf einen LFE5U-25 pressen können.

Ich habe es auch mal für den ice40 (mit synth_ice40) durchlaufen lassen und es sind interessanterweise deutlich weniger Logic Cells (<24000) erforderlich. Da ich eigentlich davon ausgegangen bin, dass beide ähnliche Technologien (beides mal gleiche Lut4 und Carry Chains) benutzen wundert mich das etwas. Evtl ist yosys aber schon besser darauf optimiert.

Für den P2 habe ich nur Bitfiles aber keinen Verilog Code gefunden, habe aber auch nicht so intensiv gesucht. Jeder Cog hat aber mehr Ram was mit den Block Rams knapp werden könnte. Auch wird er deutlich mehr Logic Cells brauchen. Den Hub Ram wird man extern realisieren müssen.
yeti hat geschrieben:...und irgendwie hätte ich derzeit noch immer lieber einen P1++ mit mehr Pins und vielleicht noch sowas wie integriertem XMM (selbst wenn's nur 64..512kBytes wären), als einen P2.
Was gefällt dir am P2 denn nicht, wenn ich mal fragen darf, im Vergleich zu seinem Vorgänger? Ich habe mir den nicht so genau angeschaut, und bin selbst auch kein Propeller Experte an sich. Aber der erhöhte Cog Ram und der eingebaute Multiplizierer klingen für mich schon nach einer sinnvollen Verbesserung.

Gerade der knappe Cog Ram hat mich immer etwas skeptisch werden lassen, was den Propeller an sich angeht. Ich werde irgendwie das Gefühl nicht los, das bei "üblichen" Programmen ein Großteil der Cogs die meiste Zeit am warten ist und viel von den theoretischen 8x20 MIPS verschenkt werden. Auch die fehlende Kommunikation zwischen den Cogs (eigentlich ja vor allem über den Hub Ram) ist so eine Sache. Und sehr hoch ist die Codedichte ja auch nicht. Ich lasse mich da aber gerne eines Besseren belehren... ;)
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

thiloa hat geschrieben:Was gefällt dir am P2 denn nicht, wenn ich mal fragen darf, im Vergleich zu seinem Vorgänger? Ich habe mir den nicht so genau angeschaut, und bin selbst auch kein Propeller Experte an sich. Aber der erhöhte Cog Ram und der eingebaute Multiplizierer klingen für mich schon nach einer sinnvollen Verbesserung.
Parallax und Sotware... das ging bisher fleißig schief. So wär ein etwas aufgepusteter P1, der keine neue Software braucht, einfach ein kleineres Risiko. Der P8X32 war von Anfang an für 2 Ports à 32 Pins angedacht, so sollte das leicht in die existierenden Spincompiler reinzuflicken sein, wenn diese nicht eh schon DIRB/INB/OUTB beherrschen.

EIn FPGA-P1V würde ja leider nicht wie der Original-P1 ein reiner 3.3V-Chip sein, aber gäbe es einen P8X64, könnte er das schon sein, was einfacher zu handhaben wär, als der P2.

Das mit dem mehr COG-RAM im P2 hab ich nicht genau verfolgt, aber da scheint es dann Unterschiede zwischen dem unteren und oberen GOG-RAM-Bereich zu geben. Das war mir dann im Trockenschwimmen zu unübersichtlich, um es weiter zu verfolgen. Aber ich finde, der P2 ist gegenüber dem P1 nochmal um Dimensionen unübersichtlicher.

...oder es ist Alles nur Altersstarrsinn... Bild...mwhuaaaaaaaahhahahahahahaa...
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

----------8<-----{20191101-1440-GMT}----->8----------

[hackaday] Symbiflow Open Source FPGA Toolchain

Das sitz ich aus, bis mir das Spielen mit Icestorm zu langweilig wird, aber dann ... mwhuahahahhahahaaa ... dann geht's voll los! Oder so ähnlich...

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

[hackaday] The $5 FPGA

Unterbietungsversuche gegen die UpDuini? Aber keine FOSS-Toolchain, das ist ein Showstopper. Ansonsten hätt ich ja aus reiner Neugier zugeschlagen.

----------8<-----{20191104-1933-GMT}----->8----------

[hackaday] Gigantic FPGA In A Game Boy Form Factor, 2019 Supercon Badge Is A Hardware Siren Song

..vielelicht für wenn ich aus der iCE40-Krabblergruppe raus bin...
;-)

----------8<-----{Ommmmmmprimistisch bleiben!}----->8----------
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: FPGA oder: Denn er weiß nicht, was er tut...

Beitrag von yeti »

𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Antworten