8$ iCE40 developer board..

[aventuri]

i've just found this Upduino board, a Lattice iCE40 based design for less then 8$ shipping included!! tell me about cheapness..
BTW it looks like an Ultra Plus version of Lattice FPGA with ~5K LUT  and boasting 8 MAC/DSP cores, 1Mbit of added RAM, I2C HW cores. it's a beefy IC (with respect to Lattice lineup, of course..)
 
it's also promoted by Lattice Semi itself..  that's a kind of an endorsement!
 
two one downside:
* you need to stick with Icecube2 for design, as it's still one of the few iCE40 devices still not supported by the free toolchain arachne-pnr/icestorm..
* there's no programmer on board and so need a Raspi or similar SBC with SPI port.. not a big deal..

there's schematic and all, so pretty documented project

finally this board CAN be programmed with the free toolchain Yosys/Arachne-pnr/icestorm!!

looking at the Linked-in page of the owner of the site, i would say he's a Lattice "insider" and these boards are heavily subsidzed, but it's just my speculation..

me, i'm curious so i've committed for a couple and see how they fares.. eventually put up a post at the right time
 
bests

EDIT: updated with the fact that the free toolchain based in Icestorm is able to program these parts too!!

[Bruce Abbott]

Nice!

[Sal Ammoniac]

What's wrong with Icecube2?

[Bruce Abbott]

What's wrong with Icecube2?

Only works in Windows 7-10 and Red Hat Linux. That's me out!
 

[daybyter]

Use a VirtualBox ?

[mubes]

Um....I tend to use icestorm but unless things have changed _very_ recently then Linux is deffo a supported platform. There are some gotchyas to getting is going and their support is write-only, but the stuff is (was) there.

Dave

[joshtyler]

I believe that Red Hat is the only officially supported linux distro, but other distros work just fine. icecube2 works well for me on Arch.

Project Icestorm is much more pleasant to use however.

[ZaneKaminski]

iCE40 UltraPlus is an amazing part. Looks like a regular iCE40 at first, but it has more block RAM--128 kbytes in four separate banks--than any other FPGA anywhere near the same implementation cost. That's why it's pretty light on I/O; I guess they used all their die area up for sram. I've been eyeing this part for a few months, so I'm glad to score this devkit for so cheap.

[Cerebus]

What's wrong with Icecube2?

Only works in Windows 7-10 and Red Hat Linux. That's me out!

Works fine under wine. In my case on OS X, but i see no reason why it shouldn't work OK on any random Linux.

[aventuri]

i've just got the devices by snail mail; they were packaged in a very thin envelope indeed. that's a bit cheap..

in attach the first shot; sorry it's fuzzy, my phone doesn't macro very well..

in my hand the device by front side with the FPGA, the other in the "protective" bag is on the back side, so you can see the SPI flash to;. assembled on both front and back ..expensive!

now let's see if they fire up for the blinking led test..

[eliocor]

Am I reading it wrong, or is the date on the postage stamp: "22 Sep 2017"? 

@AVenturi: are you living in Italy or in the USA? Your flag is like mine, but...
 

[edavid]

i've just got the devices by snail mail; they were packaged in a very thin envelope indeed. that's a bit cheap..

If the envelope is more than 1/4" thick, the postage rate goes up from $1 to $13 

[aventuri]

yes, i'm still living in Italy! 

the time stamp is a bit fuzzy.. of course cant be 22.9! as today is only 19..  i suppose the packet was sent 1 week ago or so..

[daybyter]

How do you program the fpga? It has to be done via SPI? I ordered one of these boards now, too, and thougt about using some arduino as a programmer? (Don't have a raspberry. Just an orange pi.)

[Cerebus]

How do you program the fpga? It has to be done via SPI? I ordered one of these boards now, too, and thougt about using some arduino as a programmer? (Don't have a raspberry. Just an orange pi.)

Read the datasheet for the full details, but basically you can choose between:

• Program the FPGA RAM via SPI from a microcontroller
• Program the SPI EEPROM on the board, and the FPGA will program its own RAM from that at startup
• In addition, on some other members of the iCE40 family program a write-once configuration PROM on the FPGA over SPI

From a cursory glance at the board's schematic it would appear to have strapping for choosing between the first two options.

Note that this particular board is specifically designed to fit the Arduino Micro/nano pinouts, so obviously programming the FPGA from an Arduino is going to be possible. Note that all the iCE40 parts are maximum 3V3 IO (3V6 abs. max.).

[mark03]

If nothing else, it's apparently the only way to obtain the largest ultraplus ice40 in a QFN package.  I've been interested in that part too, but nobody has stock that I know of.  I guess the risk is that you might learn to like the chip, only to find out that it will *never* be available in small quantities for your projects.

[daybyter]

I ordered such a board to give it a try.

What still irritates me, that Lattice doesn't have PDF's with datasheets on their website, like Xilinx or Altera have. Still have no clue about max frequencies or such.

[Cerebus]

I ordered such a board to give it a try.

What still irritates me, that Lattice doesn't have PDF's with datasheets on their website, like Xilinx or Altera have. Still have no clue about max frequencies or such.

Err, they most certainly do. Either that or the ghosts of PALs and GALs put them in my datasheets folder.

[Marco]

If nothing else, it's apparently the only way to obtain the largest ultraplus ice40 in a QFN package.  I've been interested in that part too, but nobody has stock that I know of.  I guess the risk is that you might learn to like the chip, only to find out that it will *never* be available in small quantities for your projects.

Are they playing some office politics with this part?

It seems almost impossible that there is no demand.

[Back2Volts]

I have just ordered one.   May be I can learn something about FPGAs this winter.

[Bruce Abbott]

I believe that Red Hat is the only officially supported linux distro, but other distros work just fine. icecube2 works well for me on Arch.

I tried, I really did - but after wasting the whole evening I am giving up.

First problem was the license checker couldn't find my network card. Turns out it only looks for an interface called 'eth0'. Found several online tutorials on how to change the interface name - all different so which one to try? Edit this file with VI they said - file doesn't exist, VI is a disgusting piece of crap. Manage to create the file, reboot, and... no change. Turns out there's another file called GRUB that has default settings in it. Remove line that sets up interfaces, reboot and... success!

Run Icecube software and it seems to be happy - except it can't find the tool directory so it can't compile or synthesize anything. Wot's this - a directory full of 64 bit executables - but my machine is 32 bit!
       

[daybyter]

It's the other way around here with many tools. I have to run quartus and ise sims in 32 bit virtual boxes on my 64 bit machine.

On topic:



But maybe we could start an upduino 'get started' thread here.  Seems like there are not many tutorials yet.

[bingo600]

Have a board underway

I can't download the Icecube2 sw 
It says page not found , on both that one , and the licence gen page.
I have had a lattice account for some time , but haven't been logged in for 1+ year.
They write something about 1 buisiness day to activate a new/sleeping account 

I can download the PDF's etc.
But no sw

/Bingo

Ps: Attached a Makefile version of the Raspi programmer  (rename to .tar.gz)

[Bruce Abbott]

Only works in Windows 7-10 and Red Hat Linux. That's me out!

Ubuntu was a no go, but the Windows version does work in XP, so I'm back in!

[aventuri]

i had three different issues for running iCEcube2 in Linux/ Debian stretch (the latest stable..), but finally i did it!!

i'll enumerate the issues because they are pretty easy to workaround and, as running native should be more efficient then running emulated like wine or virtualized like virtualbox (how many choices, in the end, anyway..), i think it worth the effort to fix these.

let met start saying the iCEcube2 is a 32bit application so you'll need the multi-arch setup if you run (as i am)  an AMD64 architecture OS.

the first issue (you'll fall into at setup time of the install package..)  is that the application depends on a libpng12-x library, but the current Debian uses a libpng16.. package. luckily you can have both the libs at the same time, but you'll have to install the package manually.

i've got mine from the official Debian repo from a previous version and installed this way:

Code: [Select]

sudo dpkg -i /home/andrea/Scaricati/libpng12-0_1.2.50-2+deb8u3_i386.deb

now we are good to go for the install phase, let's get it through and point the install at the right license file you should have got from the Lattice web site..

then at app startup, i stumbled into a problem with recognizing my license.dat was not good. it's a "macrovision technology" so always very dumb..  :-)

the issue here is that the recent Debian (and Ubuntu?) install are using "smart names" for network interfaces. so it's no more plain old ETHO on ifconfig but it's a "smarter" enps025 interface or something like that (i removed that name from my mind!), BTW this is a systemd thing.. please don't start an holy war on that! :-)

again with some google-fu you have plenty of choices to put back the old name, and i chose to add to my "grub bootloader" the param net.ifnames=0 that make the trick

now the app starts ok, and load the sample projects and so far so good.. what happens now when you try the synthesys for example... error like these:

Code: [Select]

...
/opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/synplify_pro: 137: [: unexpected operator
/opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/synplify_pro: 151: [: !=: argument expected
/opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/synplify_pro: 321: /opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/config/execute: Syntax error: "(" unexpected (expecting ";;")

this is again not a big deal but anyway again a small hitch to scratch. the issue here is that in Debian /bin/sh is a symbolic link to /bin/dash. no good for sick scripts..

so now you have two choices.

• modify the Lattice scripts when you see these errors on the logs windows
• change the default shell back to bash

i preferred the former option and so i made my way in the script directories, manually updating in first line /bin/bash in place of /bin/sh.

Code: [Select]

/opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/
/opt/lattice/lscc/iCEcube2.2017.01/synpbase/bin/config/
finaly i've been able to restart iCEcube2 and make my bitstream!

is that easy!? :-)

[martinayotte]

Unfortunately, the iCEcube2 download server is currently down ...

EDIT: in fact, it was simply a broken URL, I've been able to fix it manually and actually download the Linux version.

[aventuri]

i've finally suceeded in upload a bitstream into the upduino FPGA SRAM, from my Cubieboard A10 based SBC

here a about it..

the main issue about the connection is related documentation and use cases. Gnarly Grey doesn't describe deeply enough how one is supposed to drive the SPI interface for the two main tasks at hand:

• programming the FPGA internal SRAM for a quick test
• writing a bitstream in the external SPI flash for stable design to boot at each reset

the data flow is completely different from one case to the other.
me, i've actually tackled only th first one, also because it's the only one supported in the so called Raspi Programmer examplr

i suppose for writing the SPI flash you'll need some kind of protocol to access the SPI flash registers (and eventually erase each page in advance..)

i'll try to take a stab to this SPI flash writing step before making a code drop on github.. BTW the code is currently using direct MMAP access to A10/A20 GPIO's so it's pretty dedicated to these SOCs..

[bingo600]

Thanx for the tips on linux

Here's one in return

To make bash the default shell do this
sudo dpkg-reconfigure dash

And select No when it asks whether to use/install dash as /bin/sh. 

/Bingo

[bingo600]

Just got my board , and did a quick test on a Raspi3

The led blinks , but i get an error about CDONE still being low

running =3
running 1
running =3
CDONE is Low! Configuration Error!
bingo@raspi4:~/lattice $

Has anyone else tried a Raspi as programmer ??

Hmm seems like CDONE is not connected if one follows his wiring guide for Raspi , it seems only to be connected on TP2

/Bingo

[aventuri]

yeah, i've been told that CDONE is missing and it was a miss.

that Raspi prog should be good also for the next "incarnation" Upduino v2 that has a MCU on board too and should "complement" the offering.

anyway IMHO it's not a big deal.. still one could use a GPIO to assess when the bitstream is running on the device, a hackish work around..

[bingo600]

yeah, i've been told that CDONE is missing and it was a miss.

anyway IMHO it's not a big deal.. still one could use a GPIO to assess when the bitstream is running on the device, a hackish work around..

Naah .. I'll just snag it from TP2
Will see if i can do it during this weekend

That V2 looks nice too , wonder what MCU will be onboard (Hopefully something w. USB onboard)
Ie. a STM32 , the STM32F103 is approx 1$. Even cheaper than an Atmel w. USB.

/Bingo

[bingo600]

And now with CDONE connected to RPI pin 15

running 2
running 1
running =3
CDONE is High! End of Configuration!
bingo@raspi4:~/lattice $

Edit : But it doesn't function (aka no led blinks)
It works if i disconnect CDONE

Edit2:

Seems like the fpga wants 2 dummy bytes after CDONE goes high , now it works.

Code: [Select]

    if ((pdone==0) && (bcm2835_gpio_lev(CDONE)==HIGH)) {

//The fpga doesn't start wo. sending 2 extra dummy bytes
        sendbyte (0);
        sendbyte (0);

        printf("CDONE is High! End of Configuration!\n");

        pdone = 1;

       break;

/Bingo

[bingo600]

I find it a bit strange that the "text header" in the beginning of the bin file gets sent to the fpga.



But i haven't read any of the DS doc yet 


/Bingo

[Cerebus]

I find it a bit strange that the "text header" in the beginning of the bin file gets sent to the fpga.



But i haven't read any of the DS doc yet 


/Bingo

The chip just hunts for a signature (0x7EAA997E) that must occur within 'x' bytes of the start of down/upload. You can trim off the header if you really want to and it should all work the same.

[bingo600]

Ahh thnx   

Just found the same on pg. 18 in the programming doc   
http://www.latticesemi.com/view_document?document_id=46502


Any idea why the 2 extra dummy bytes are needed ?
I'll read on in the prog manual , but if you know ....

Ahh... seems like this might be the reason (pg. 19)



But 2 bytes isn't 49 cycles.

Maybe i should just throw 8 dummy bytes after it, to be sure.

Attached a new Rpi archive w. makefile

/Bingo

[bingo600]

Here's a fpga reset Rpi prog , for when you have had enough of the blinking.

Removing +5v doesn't stop it from running, still blinking in a strange pattern though.
And i'm to lazy to reset via JP1

Maybe we should tristate (input) all the SPI pins , must be where it gets the "phantom power from"  or

/Bingo

[bingo600]

Just threw a program together , that can program the FPGA from the binary outputfile.

Usage : ./fprog <binfilename>

It was made as a proof of concept ,and i didnt even bother to debug why getopt didn't work on the Rpi , it did on my Mint.
I just skipped getopt and hardcoded it to use last argument as binfilename.

Well it seems to work , but is something of a copy/paste kludge.

Binfiles are found here (for the original proj)

.../RGB_LED_BLINK_20170606/rgb/rgb_Implmnt/sbt/outputs/bitmap

/Bingo

[__daz__]

I found Diamond programmer to be a bit cumbersome to use so I made this very simple iCE40 programmer for FTDI C232HM MPSSE cable.

https://github.com/siorpaes/iCE40prog

It does all the job: resets FPGA, puts it in SPI slave mode and pushes the bitstream. Tested with UPDuino board on Ubuntu and Cygwin.

David

[aventuri]

i published my programmer too here: https://github.com/aventuri/iceProgrammer

the good thing is that can upload bitstream both on FPGA SRAM for volatile tests, and on FLASH NOR (for  fixed design). with different commands. it borrows the skeleton from icoprog (that was Raspberry only).

the bad thing is that it's currently working on Allwinner SOC ony and the pins are hardcoded because i wanted the less dependancy possible, so used memory map access to pins (no device tree..) and runs as root.

hope it's useful..

i'll enhance when i'll decide it's not good enough, now i want to start playing with FPGA designs..

[bingo600]

i published my programmer too here: https://github.com/aventuri/iceProgrammer

the good thing is that can upload bitstream both on FPGA SRAM for volatile tests, and on FLASH NOR (for  fixed design). with different commands. it borrows the skeleton from icoprog (that was Raspberry only).

the bad thing is that it's currently working on Allwinner SOC ony and the pins are hardcoded because i wanted the less dependancy possible, so used memory map access to pins (no device tree..) and runs as root.

hope it's useful..

i'll enhance when i'll decide it's not good enough, now i want to start playing with FPGA designs..

Nice ..

In order to use the flash , did you "turn/flip" the two resistors ?

How do you connect the Alwinner mosi/miso when doing fpga-ram vs fpga-flash ?
Don't you have to "reverse" miso/mosi when doing ram vs flash ?

/Bingo

[aventuri]

just two notes about the HW setup:

• i didn't modify any resistor.
• the wires between A20 and FPGA board do not have to change for writing to FLASH or to FPGA SRAM
• indeed, when writing to SRAM, you need to write on MISO (as the FPGA, if SS low on CRESET posedge, stay listening for a bitstream there),
   this change is made inside the program, of course..
• then, when writing to SRAM, i keep high the SS to keep FLASH Hiz
• then, when writing to FLASH, i keep CRESET down to keep FPGA Hiz
• i closed the jumper on the left of the "programming 6x pin connector

BTW i dumped also the FLASH before writing, and i found the strings of a Cisco switch firmware: CN=CiscoSystems;OU=Nexus9k;O=CiscoSystems

it looks like the flash are refurbished (desoldered?) parts by the assembly factory? who knows..

[martinayotte]

I got a strange behavior :
It is working fine for uploading in SRAM, but I'm unable into FLASH, although I've the jumper on SS
It loops forever on writting sectors ...

Code: [Select]

root@micro:~/git-work/iceProgrammer# ./programmer -f < RGB_LED_BLINK_fast.bin
flash id: 00 c0 80 00 00 02 10 42 00 00 00 00 00 00 00 84 00 00 00 00
writing 101.71kB..
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Also, after doing a Ctrl-C and retrying, the FlashID seems to be destroyed :

Code: [Select]

root@micro:~/git-work/iceProgrammer# ./programmer -f < RGB_LED_BLINK_fast.bin
flash id: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
writing 101.71kB..
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I guest I will have to desolder this flash and resolder a new one ...

EDIT :
I've try my second modules, still getting this strange flash id "00 c0 80 00 00 02 80 80 01 80 00 00 18 00 21 01 fc 00 00 00"
So, I decided to replace the flash of the first one with Winbond W25Q32, and now the flash id make sense "ef 40 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00", and I was able to flash bitstream this time.
So, I bet that original flash is a strange one (I can't figured out the manufacturer) which is not following conventional flashing commands ...

[aventuri]

umh. i'm sorry for all these issues..

let me tell you that i don't think the Flash is burnt. usually they are pretty strong device, and when you read all bit high from the device is because there's something pulling-up the line.. maybe the iCE40 was not in reset state or something like that..

then also the device ID in the first trial looks a bit suspicious to me. i don't have my data here, but in my test the flash id was consistent with model stamped on the IC and the datasheet values.. the three first bytes, i mean (the other 14 are an unique random id..). a 32Mbit Flash NOR marked. 25Q03213 E40

let me know if you sort out your issues..

EDIT only rereading the thread, i did see you already solved your issue, and you found a "noname rom".  so my answer above looks a bit out of context.. BTW me, i found a ROM with already a firmware inside for a Cisco Switch.. i really believe the assembly  house made a good price only because has offered random stuff as parts for the design..

[martinayotte]

No worries, it is not your issue, but I think I will email gnarlygrey to figure out which flash chips was on my delivered boards since FlashID of those was unkown to me, and I'm fluent with those since years in other designs, Winbond, BergMicro, etc., even some Cypress FRAM.

[Dubbie]

I used an ICE40 for my first FPGA project and it worked very well.
It was for when I needed 16 channels of very precise timing. Something I wasn't able to do on an MCU.

[CM800]

Just got mine....

Friday Evening in the UK, forgot to make the account in advance.

Seems like I may not get to do anything over the whole weekend unless they activate it somehow today

[aventuri]

theorically i couldn't believe that registering user and "releasing" free licenses for the THEIR sw to sell THEIR IC would be a manual task for an established corporation involved in the semiconductor market in 2017  (and yet to be so interesting to chinese, that the US government decided to forbid the deal), yet....

...with Latticesemi, i often get the feeling of "we do business like a Public Administration.."  or something like that :-)

to Lattice guys, don't take it personally, of course! you do lot of great stuff, BUT you could do a bit better! think positive!

PS of course, not being ENG native, don't know if i convey the idea well enough.

[CM800]

Yay, they got their shit together and I managed to get a download.


Whats the deal between Lattice and Mentor / LSI?

"I verify that I am not an employee of Cadence Design Systems, Mentor Graphics Corporation, or Magma Design Automation "

[martinayotte]

I've finally got iCEcube2 working (MultiArch gave me some problem with X11 resolution been reset to 800x600, but I fixed that).
I've done some pratice to revamp my Verilog knowledge, not done any since a year, I modified the RGB_LED_BLINK sample code, just as PoC, to get more Colors ... 
Now it is alternate with also magenta/cyan/yellow/while ...
If someone wish to test it, here in attachment ...
Next step, find duty to this small board : maybe I2C slave peripheral !
I didn't check yet if UPDuino_IOX_20170908.tar is doing so ...
Maybe DMX output thru I2C ?
I think I must dream more about it ...

[bingo600]

I've done some pratice to revamp my Verilog knowledge, not done any since a year, I modified the RGB_LED_BLINK sample code, just as PoC, to get more Colors ... 
Now it is alternate with also magenta/cyan/yellow/while ...
If someone wish to test it, here in attachment ...

Seems like you forgot to include the Project source ....

Would you mind to reupload   

/Bingo

[ebclr]

I'm in this boat just ordered  the board

[martinayotte]

Seems like you forgot to include the Project source ....

Would you mind to reupload   

Simply overwrite/rename the original RGB_LED_BLINK.v with this one ...

[aventuri]

just a bump up to note that the iCEcube2 IDE has been updated few days ago to 2017.08 release..

don't know what's different for the FPGA part used in upduino, still not supported by iCEstorm, i.e. iCE40UP5K. anyway i have to note that the Windows version is a lot more featureful then the linux one, as it supports the Aldec-HDL simulation environment. (and simulation is everything in HDL world!)

[asmi]

I've managed to buy few 5LP4K parts in QFN package when they were still available. Even built a simple breakout board for them:

Nice thing about them is that due to low consumed power an extremely tiny dual LDO part TLV7111225 (U2 on photo) fulfills all power requirements for the FPGA.
Was monitoring Mouser/DK for a while in case 5K parts show up, but no dice Since that I moved onto Artix-7.
One thing I remember from making that breakout is wrecking my head trying to come up with a way to allow all 3 config options available on the board

[peepo]

Has anyone created a wiki for this 8$ lattice board?

I'm finding the thread hard work to trawl through

tx

board has been ordered, not yet arrived...

[ebclr]

Mine too, no board, no contact, no board I guess something is wrong..................

[asmi]

I've ordered one a couple of days ago. No communications from the seller so far.

[Kalvin]

I got mine in an envelope after some days from the Paypal payment. No smalltalk, just delivery.

[asmi]

Just received an email from PP that the board has been shipped out by USPS. That's gonna take a while to arrive as USPS shipments have a tendency to get stuck at the border for a while
But hey - I didn't expect anything else from $8 purchase.

[martinayotte]

I got mines within a week after the order (I'm in Canada too).
It was shipped in a standard letter envelope...

[daybyter]

Is there is a chance to program this board via an Arduino? (Would be the cheapest solution, I guess.) Just write the data from PC via USB to and Arduino and then via SPI to the fpga board?

[martinayotte]

Technically, it is doable. But you will have to write some software and sketch to achieve that.

[asmi]

Is there is a chance to program this board via an Arduino? (Would be the cheapest solution, I guess.) Just write the data from PC via USB to and Arduino and then via SPI to the fpga board?

Buy the MPSSE cable - you can use it to program this FPGA, but even in general it's a very useful thing for prototyping as it can talk to I2C, SPI, UART devices straight from computer. Just keep in mind that there are two versions for different voltages - 3.3 V and 5 V.

[asmi]

I got mines within a week after the order (I'm in Canada too).
It was shipped in a standard letter envelope...

You was right. Received my board today (or maybe yesterday - I didn't check my mail that day), one week since it was sent.
It is SO tiny - about the size of my thumb!

[ebclr]

Mine received today, It's well made only the silk screen is so so

[peepo]

https://github.com/siorpaes/iCE40prog

wfm thank you!

[bpye]

Looks like the QFN part will be available from Mouser next year... https://eu.mouser.com/ProductDetail/Lattice/ICE40UP5K-SG48ITR/?qs=sGAEpiMZZMup8ZLti7BNC%252bRErHeER90MppcnI512H%252bs%3d

[mark03]

Yep... and Digikey is taking orders now too ("standard lead time 8 weeks").  Looks like somebody saw the light.

[ale500]

I got one last week, it works a treat !. Both SPI Flash programming and CRAM work well. I added the missing PLL cap too. I hope the internal oscillator can drive the PLL reliably to be able to drive a VGA monitor.

One thing I didn't look up properly is that the block ram in simple dual port: one read and one write port. Reading the docs is an advantage , I should have done it earlier !.

To program it I bought a FT2232H board from aliexpress, it works with diamond programming very well. I had to re-program the EEPROM attached to the FT2232H to make it compatible.

I just wonder how low power are these things in reality...

[ale500]

Using the internal oscillator to drive the PLL and get 25 MHz for 640x480 works, but well it has a noticeable amount of jitter . Saying that the pixels dance is pretty near to what they do  . It remembers me of the old TK-85, the picture was also not that stable .

[mac.6]

Tested mine today. CRAM download is fine, but flash chip doesn't, not even able to scan the device when swapping MISO/MOSI for flash use...
To bad as buying a new flash chip will cost more than the board 

Edit: ok I found out that when using FT232H cable/diamond programmer, you should wire it like for CRAM programing to do the scan, then swap MISO/MOSI before flashing, never seen that for fpga programming...

[Cerebus]

Tested mine today. CRAM download is fine, but flash chip doesn't, not even able to scan the device when swapping MISO/MOSI for flash use...
To bad as buying a new flash chip will cost more than the board 

Edit: ok I found out that when using FT232H cable/diamond programmer, you should wire it like for CRAM programing to do the scan, then swap MISO/MOSI before flashing, never seen that for fpga programming...

Yeah, I advise reading the data sheets twice, and then twice again, to properly get your head around what SPI lines are driven, inputs and floating in each configuration scenario.

[mac.6]

I am used to xilinx and other boards which do not require live switching wires for alternating FPGA/flash programing, which is puzzling in this case.

[Cerebus]

I am used to xilinx and other boards which do not require live switching wires for alternating FPGA/flash programing, which is puzzling in this case.

I think that it's down to a tension between the FPGA acting as a master for an external EEPROM, as a slave for an external master to program it as SRAM and as a slave for an external master to program the internal EEPROM. They can't all be consistent without changing the direction of some pins at start-up and for whatever reason that was decided against, perhaps because it would call for more external mode setting pins.

[mac.6]

But it's working fine on other lattice board like hx8k or icestick, so what's different with this board?

[Cerebus]

Dunno. I'll figure it out once mine arrives and I have to, until then this head-cold (Which I have had for over a week, dammit!) means I don't have the energy for the dive into the schematics and data sheet that requires. Speculation I can manage, but proper thinkin' and figurin' is a bit beyond me at the moment.

[aventuri]

actually a programmer SW can indeed provide a seamless operation without re-wiring for programming the FPGA on volatile ram or programming permanently the FLASH, and it's just a matter to "swap" the GPIO configuration for MISO/MOSI on the fly! (and keeping the "other" IC reset or disabled to have its pins HiZ!)

this is how it works for icoprog and  what i'm doing with my iceprogrammer, which borrowed from icoprog the basic skeleton but stripped away the Raspberry GPIO library dependancy, as it's currently tailored for A10/A20 Allwinner SOC.

BTW i'm finishing a new revision that's supposed to have:
* configurable pins on the command line, so you can easily wire the upduino against your SBC as you like..
* tested working very easily by me both on ARM32 ( A10/A20 ) and H5 (when compiled as Aarch64..) SOC, and maybe it works on other Allwinner SOCs too.., because luckily enough the Allwinner guys kept the GPIO memory interface exactly at same position and with the same pin names!

[IuriC]

Ordered one, lets see how long it will take to arrive.

[simmconn]

What I received is a torn envelope. Sent an email to the seller with the picture and asked if I can pay another $7.99 to have one shipped in a box. No reply received after 2 and a half weeks.
Just to let you know that there is risk shipping a rigid board in a first-class mail letter, and the seller is apparently too busy to handle shipping problems like this...

[Rasz]

What I received is a torn envelope. Sent an email to the seller with the picture and asked if I can pay another $7.99 to have one shipped in a box. No reply received after 2 and a half weeks.
Just to let you know that there is risk shipping a rigid board in a first-class mail letter, and the seller is apparently too busy to handle shipping problems like this...

as an European shipping anything without confirmation of delivery sounds insane to me. Additional cost for a letter is whole $0.5, and it comes with insurance.

[chickenHeadKnob]

The automated mail handling equipment a letter is subjected to makes sending a small populated board in this way a game of Russian roulette. Mine arrived intact mailed to Canada around 2 weeks after ordering. Both the outside of the  envelope and the board and extra pins revealed signs of rough treatment.   

[martinayotte]

The automated mail handling equipment a letter is subjected to makes sending a small populated board in this way a game of Russian roulette. Mine arrived intact mailed to Canada around 2 weeks after ordering. Both the outside of the  envelope and the board and extra pins revealed signs of rough treatment.

Mines too, but within a week ...

[ale500]

Is it the LED soldered or not ?. I have ordered some too, and the LED was not soldered. I have only seen one with a soldered LED delivered at the end of October.

[asmi]

The automated mail handling equipment a letter is subjected to makes sending a small populated board in this way a game of Russian roulette. Mine arrived intact mailed to Canada around 2 weeks after ordering. Both the outside of the  envelope and the board and extra pins revealed signs of rough treatment.

Yes, header pins arrived all bent with my board too. The board itself seems OK though.

[edavid]

What I received is a torn envelope. Sent an email to the seller with the picture and asked if I can pay another $7.99 to have one shipped in a box. No reply received after 2 and a half weeks.
Just to let you know that there is risk shipping a rigid board in a first-class mail letter, and the seller is apparently too busy to handle shipping problems like this...

as an European shipping anything without confirmation of delivery sounds insane to me. Additional cost for a letter is whole $0.5, and it comes with insurance.

That's because you don't know US shipping rates.  The extra cost for confirmation would be about $1.60 for US addresses and $12 for international mail.  Insurance is more.

simmcomm, just open a PayPal dispute and order another one.

[bingo600]

I've ordered 2 , and both arrived in nice conditions within their envelopes (EU).

/Bingo

[martinayotte]

Is it the LED soldered or not ?. I have ordered some too, and the LED was not soldered.

Mines were having the RGB LED soldered...

[Geoff_S]

Mine came with two 6-pin right-angle headers.  I can't work out what they were meant for.  I'm obviously lacking sufficient intelligence to use this thing 

[dpenev]

Hello,

I've tried latest iceProgrammer on A20 board
./programmer -p is working fine. 

I am getting however as martinayotte got:

./programmer -f < RGB_slow.bin
flash id: 00 c0 80 00 00 02 14 60 00 00 60 00 00 00 00 08 00 00 00 00
writing 101.71kB..
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..

martinayotte did you manage to solve this?
I have CDONE still not connected to the iCE40 module.

EDIT1:
As I saw martinayotte has replaced his flash chip I have decided to give it a try too.
I found M25P40 handy but with it I got:
 
./programmer -f < RGB_slow.bin
flash id: 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
writing 101.71kB..
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  0% @000000 erasing 64kB sector..
  0% @000000 writing: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I have verified that M25P40 has similar command IDs as programmer uses. Hmm strange.

Edit2: I have noticed that flashing with the original flash chip started working if I touch the SS signal.
Experimenting with some pullups pull down seems improve noting. 
I have added some delay in the code as bellow which made flashing a bit more stable at my side but still I get some XXX..
I don't want to investigate now more but it seems we have inexpensive FPGA toy now
....
void spi_begin()
{
    digitalSync(10); //penev
    digitalWrite(SUNXI_ICE_CS, LOW);
    digitalSync(10); //penev
    // fprintf(stderr, "SPI_BEGIN\n");
}

void spi_end()
{
    digitalSync(10); //penev
    digitalWrite(SUNXI_ICE_CS, HIGH);
    digitalSync(10); //penev
    // fprintf(stderr, "SPI_END\n");
}   
...

Best Regards
Dimitar

[martinayotte]

Edit2: I have noticed that flashing with the original flash chip started working if I touch the SS signal.

Yes, I've seen this symptom too, but didn't investigate further since touching is a good workaround ...

[SiliconWizard]

I'd be interested to see how the iCE40 UltraPlus really compares to the MachXO2-ZE.

Of course, the iCE40 is cheaper and has SPRAM.
I'd like to see the real power draw and LUTs usage of a similar design on both devices though, like an LCMXO2-2000ZE vs. iCE40 UP3K for instance. Static current on both is similar (80 µA vs. 75 µA).

[ale500]

I'd like to see the real power draw and LUTs usage of a similar design on both devices though, like an LCMXO2-2000ZE vs. iCE40 UP3K for instance. Static current on both is similar (80 µA vs. 75 µA).

Me too.

I have a design with some 25 % of a 7000ZE with the internal oscillator running at 2.08 MHz (133.3 divided to 2.08), it eats 7 mA when running. The same design didn't seem to report anything useful using my multimeter. I replaced the original 1.2V reg with a MCP1700-1.2, those should be pretty low in quiescent  current.

Did someone do some reliable measurements ?

[iMo]

Mind this UPduino board is intended for very basic demonstration purposes only (blinking the LEDs), not for high performance designs (a poor pcb layout, weak decoupling, no PLL decoupling).

Running J1a forth cpu (~2600LUTs, 15kB bram) at 30MHz (an external Xtal oscillator) takes 19.5-21mA (the current consumption of the UPduino board - do subtract the quiescent currents of the 2x 1117 voltage regulators and SPI flash to get the Ice40UP5k only).

No fun with PLL yet 

[Cerebus]

...no PLL decoupling...

Every third party iCE40 development board that I have seen the schematic for gets this wrong. The damning thing is that right there in the original data sheets they tell you how to do it properly. It's in the document "iCE40 Hardware Check List" under the heading "Analog Power Supply Filter for PLL". It's trivial to get right, but it seems reading data sheets properly is beyond most people.

[iMo]

The trick is the ice40UP5k in SG48 packages does not possess the GNDPLL pin. The appnote says the PLL's decoupling filter shall be wired between VCCPLL and GNDPLL, and "GNDPLL must not be connected to the board's ground". They want to minimize the noise getting into the PLL, therefore in other packages the special GNDPLL pin is directly connected to the internal sensitive PLL circuitry..
As the SG48 got only a single GND at its thermal pad the pcb designers are in doubt where to wire the decoupling capacitors, it seems..

[iMo]

This is a quick workaround (missing VCCPLL decoupling) - I've soldered an 1uF ceramic in between VCCPLL and GND pads.
Not fully according to the appnote recommendation, however, but better than nothing..
Provided as-is, use at your own risk..

[PartialDischarge]

Why is it that Lattice FPGAs are (or seem) much less used than altera or xilinx?  Given that Icecube2 or lattice diamond can be used 'free' and seem easy to program are they used only in some small applications?

[iMo]

Why is it that Lattice FPGAs are (or seem) much less used than altera or xilinx?

Market share 2016:
Xilinx 53%
Altera/Intel 36%
Lattice 3% (but with highest Y2Y growth)
Source: https://www.eetimes.com/author.asp?doc_id=1331443

Xilinx makes $$ with the High-End FPGA devices, used in the most demanding apps you may imagine. A development kit (a 20x20cm board) may cost you up to $250000 (1-2 FPGAs on it).. Currently the supported chips are all high pin count BGA packages, not easy to use, very expensive for smaller designs. Not supported chips today but in DIY friendly flatpacks are the Spartan3/6 etc, "cheap" and available, not supported by Vivado, however. Vivado and old ISE is "free". Technologically the most complex and best FPGAs, very good docs, good support on forums as well.

Lattice with iCE40 occupies the Low-Cost, Low-Power, Low-Performance low-end (the other families might be comparable with Altera's midrange). They target today towards wearable, IOT, handheld devices (usually for interfacing/conditioning/preprocessing in Sensors<->MCUs). Popularity grows today as the packages could be still used easily by DIY market/community. Technologically the "simplest" stuff which does exist (ie. that is why the "icestorm" project is so successful). Designs on Lattice (especially on the iCE40) are usually 2-3x slower, and require 2-3x more fpga resources than the same verilog on today's Xilinxes. Similar tools as the Xilinx, rather basic support. Any pointer to a Lattice forum where we may discuss the stuff??

[daveshah]

I'm currently developing icestorm for this FPGA. At the moment it has experimental, but working, for almost all the features. This will probably be declared stable in the next week or two, except for hard I2C and SPI which are included but will remain experimental for a while.

General icestorm info: http://www.clifford.at/icestorm/
Quickstart demo project (fading RGB) : https://github.com/cliffordwolf/icestorm/tree/master/examples/up5k_rgb
Bigger demo project (NES) : https://github.com/daveshah1/up5k-demos/tree/master/nes
Technical info on UltraPlus features : http://www.clifford.at/icestorm/ultraplus.html

Currently work is in progress on a new development board using this FPGA, that will be a bit more expensive than the upduino but will be properly designed and have many more features, the "icebreaker".

[asmi]

These chips are finally in stock at Digikey (and coming soon at Mouser)! Grab some while you can!

[iMo]

Running J1a forth cpu (~2600LUTs, 15kB bram) at 30MHz (an external Xtal oscillator) takes 19.5-21mA (the current consumption of the UPduino board - do subtract the quiescent currents of the 2x 1117 voltage regulators and SPI flash to get the Ice40UP5k only).

UPduino board: Under CBReset 6mA, J1a clock stopped 8mA. Thus UP5k itself approx. 250uA/MHz with 50% fpga utilization..

[iMo]

The VCC (VCC after the R1=1 ohm, towards the UP5k's pins 5 and 30) is not blocked either. I've added:
1uF (or 10uF) || 100n to VCCPLL (see my post above), 0603
10uF to 1117 3.3V output, 0805
10uF to 1117 1.2V output, 0805
10uF between 3.3V and GND header pins, 0805
100nF to the VCC track against GND at the programming header,  0603
replaced R1 with 30ohm ferrite bead, 0603
and also I've soldered 3 wires in to help with 3.3V and GND routing.
I do not use the 5V-GND header pins, better you solder a 100nF-10uF between that pads as well.
Welcome to the DIY club

PS: Even with these "fixes" I cannot get the PLL working somehow. With a 30MHz external Xtal oscillator the stuff works here, with 30MHz off the PLL (20MHz external Xtal oscillator as the ref, PLL is locked) the serial comm shows errors..
EDIT: the PLL now works at 30MHz.

[SiliconWizard]

Nice initiative. Kudos.

Unfortunately, yosys for synthesis only seem to support Verilog. Does anyone know of a similar open-source tool for VHDL?

Thanks

[fanoush]

FYI, anyone considering buying this board should check this thread: https://twitter.com/fpga_dave/status/950059100519485441
The creator of the "Upduino" did a pretty terrible job of layout, and copied an error from a dev board (no filter on VCCPLL). Paging Dave...

The "I thought the UPDuino board was designed by freshman student." comment is dead on. Check this https://www.element14.com/community/groups/fpga-group/blog/2017/09/30/gnarly-grey-upduino#comment-115883

[iMo]

On board quality - I paid a High School/College kid in ... I will give him your feedback.

HIJK you.. 
The board calls for 4 layers. It cannot be routed properly in such small size in 2 layers, and with all the required stuff on it.
Lattice provided the chips as samples most probably free, and with the 2 layers it is a cheap gadget to show the stuff works.
As the UP5k chips are not available, it could be the Lattice is making a new UP5k silicon revision which works better and those chips on the board are prototype samples. A good board for finetuning of your development chain/tools

[asmi]

As the UP5k chips are not available, it could be the Lattice is making a new UP5k silicon revision which works better and those chips on the board are prototype samples. A good board for finetuning of your development chain/tools

They are available and in stock right now in both Digikey and Mouser.

[fanoush]

But still, the minimalist idea of the UPDuino board is good. It is similar to those arduino pro mini boards  - just bare minimum and smallest size. So it is not a devboard, it is something to flash over SPI, put into some project and keep it there. It is for people who can't design their own board for their specific project. One can have one more expensive dev board with FTDI chip and all that  for development (like the planned icebreaker one), but the one like UPDuino is cool too for the final step. BTW I wonder what is target price for icebreaker. I guess the FTDI chip alone will double the BOM price?

[fanoush]

And BTW my fist idea for using UPDuino was to convert packets between CSI and DSI for fast data transfers between two Raspberry Pis as described here. But I guess it is not designed for such high speed stuff after all. But nevermind, as I am just a beginner with fpgas, even blinking few leds or some simple soft core with serial port or SPI/I2C would be more than enough to learn the stuff.

[aventuri]

But still, the minimalist idea of the UPDuino board is good. It is similar to those arduino pro mini boards  - just bare minimum and smallest size. So it is not a devboard, it is something to flash over SPI, put into some project and keep it there. It is for people who can't design their own board for their specific project. One can have one more expensive dev board with FTDI chip and all that  for development (like the planned icebreaker one), but the one like UPDuino is cool too for the final step. BTW I wonder what is target price for icebreaker. I guess the FTDI chip alone will double the BOM price?

you are really right here! a minimalist board with an UP5K, an OSC, a SPI flash and a user led (or a couple) and two GPIO rails is really needed for the very reasons.
practically speaking, we are talking about the Tinyfpga B-serie boards here; just with the UP5K in place of the current iCE40 FPGA!

...and the "very clever" USB low cost interface with the "bootloader" FW, makes this design VERY flexible and compelling ..

saddenly, upduino, as it is, is too broken with regard to PCB settings, for any high-performance FW design! but as "first mover" we have to recognize it's still useful enogh

[asmi]

I don't understand the problem to be honest. These chips are super easy to integrate into your own boards, and since they are not in BGA package, you can get away with cheap-ass 2 layer board which will probably cost you less than FPGA chip itself! Take 3.3 V power source, TLV7111225 dual LDO for power, main 3.3 rail to power IO buffers, drop in any oscillator, SPI flash, few decoupling caps - and you're done! The minimal schematic will contain less than a dozen of parts. To program the flash, you can use FTDI MPSSE cable (which works with Lattice's Diamond Programmer).

[iMo]

There is the Mecrisp-Ice Forth running on the J1a CPU ported for the UPduino board at:
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB

It offers some interesting enhancements, ie.:
1. a full 15kB of the internal bram could be used for Forth,
2. includes 48bit Floating Point Library,
3. it does not require any special tools except IceCube2 or IceStorm,
4. etc.

As the original Mecrisp-Ice this port can store the entire ram (with a current dictionary) onto the onboard 4MB flash with save/load commands too.

With IceCube2 it runs at max. 30MHz external oscillator or internal PLL, with IceStorm at max. 20MHz with external oscillator, as of today.

[aventuri]

hello,

i've just made an adaptation of a RISCV-32 ice40 port (original repo is icicle)

the upduino github repo is: https://github.com/aventuri/icicle

with make upduino you'll get a firmware to upload to upduino board and see on the serial port: 21 is uartTx, 12 is uartRX, the helloWorld greeting! of course you need a working risc-v gcc toolchain..

BTW i had to add the CAPS for PLL stability!! see picture

have fun

[fanoush]

BTW i had to add the CAPS for PLL stability!! see picture

Can you make closeup of your modifications for PLL stability? Thanks.

[aventuri]

i've put three 1uF CAPS as per this post. - thanx Andy (the guy who made that post and the shot in annex).

two on the front as depicted in the picture below, one on the back, on the same pins of the other LDO.

[iMo]

Do not forget the VCC capacitor.. See the complete list:
https://www.eevblog.com/forum/microcontrollers/8$-ice40-developer-board/msg1400271/#msg1400271
A closer look at the PLL capacitor: https://www.eevblog.com/forum/microcontrollers/8$-ice40-developer-board/msg1396661/#msg1396661
You may stack up more caps there if needed.

[Cerebus]

Have any of you gotten configuration working over SPI? I can't seem to get the slave select / reset order working.

You're going to have to be more specific than "configuration working over SPI" as there are three modes that this could refer to (FPGA in slave mode, FPGA in master mode and flash programming).

[Cerebus]

I am referring to slave SPI mode. I'm following the appropriate TN document, and have checked my pins, but CDONE is never going high.

Ah, all clear now.

Obvious, but have you slapped an oscilloscope on the pins and made sure you're seeing what you'd expect to see?

I'd have to go back to the (not very well done) schematics and spend a few minutes decoding them to be sure but I think you need to remove J1 to disconnect the FLASH CS so that it tri-states and keeps off the SPI bus. Have you done that?

CRESET is on pin 2 of JP1 - I presume you're actively driving that to start the configuration cycle and holding SPI_SS low as you release CRESET to force the FPGA into slave mode. (See what I mean about the schematics J1 and JP1? Sheesh!)

[Cerebus]

This is on a custom board I made, link to the thread about it is earlier in this thread. That is indeed the sequence I'm using. What is confusing me at the moment is the "power cycle the board" step on this admittedly old guide:
http://j-marjanovic.io/lattice-ice40-configuration-using-raspberry-pi.html
Wouldn't cutting power to the ICE40 make the volatile config state disappear?

Sorry, as this is the Upduino thread I, somewhat naturally, assumed that's what you were referring to.

He's power cycling the board because he's not controlling the iCE40's C_RESET signal and so has to rely on the power on reset. He's not doing the programming until after the power on reset. For the iCE40 to go into slave mode you have to hold SPI_SS low as it comes out of reset, then you can configure it from your programmer/micro/whatever. If SPI_SS is high as it comes out of reset it goes into master mode (after first checking that the internal EPROM isn't programmed).

I suggest a very thorough read and then re-read of Lattice's TN1248 "CE40 Programming and Configuration" guide. It's only 27 pages but is not, perhaps, the most clearly written document.

By the way, if you're working in slave mode you must send the configuration in one go (i.e. you can't release SS during programming) and there are minimum clock rates you must meet (i.e. it's possible to try and program it too slowly). That might catch you out if you have to wait to read chunks of the configuration from another device and have to have a relatively long pause between blocks of configuration output to the FPGA. This is all explained in TN1248, but it's not made as explicitly clear as it, IMHO, ought to be.

[fanoush]

Looks like there is Upduino V2.0 for $16 with FT232H and 12Mhz oscillator
http://gnarlygrey.atspace.cc/development-platform.html#upduino_v2
https://github.com/gtjennings1/UPDuino_v2_0
VCPLL have capacitors according to pdf schematics https://github.com/gtjennings1/UPDuino_v2_0/blob/master/PCB/UPDuino_v2_0_C_121217.pdf

[iMo]

Nice!

FTDI FT232H USB to SPI Device for FPGA programming

I would add

FTDI FT232H USB to UART for easy serial communication..

It may work fine I guess (a small fix needed perhaps)..
ICE_MISO = Rx
ICE_SCK =  Tx

[ale500]

Maybe I should have waited a bit... I got 6 boards of the first version... I also got one FT2232H breakout board to program... it works very well, both SRAM and Flash. For 7.11 € they are exceptional value.

[fanoush]

Upduino V2.0 .... with FT232H and 12Mhz oscillator

I watched bringup of icebreaker board and the guy said https://youtu.be/VPH-_nxBasw?t=14m18s he wanted 12Mhz clock source to be used by both FTDI and the FPGA so he did not use crystal. When checking schematics of upduino 2.0 there is CSTCR resonator and the OSC_OUT signal from FTDI is brought out to J8 and is not connected to FPGA. Does it mean it cannot be used easily as an external 12Mhz clock source to FPGA?

[iMo]

..there is CSTCR resonator and the OSC_OUT signal from FTDI is brought out to J8 and is not connected to FPGA. Does it mean it cannot be used easily as an external 12Mhz clock source to FPGA?

The output of such an oscillator is usually not a perfect square wave. It may work, you have to try..

[fanoush]

Just to let you know that I received Upduino 2.0 today :-)
I went through the initial RGB blinking example described in https://github.com/gtjennings1/UPDuino_v2_0 /Programming Instructions.docx , flashed the hex file via Diamond programmer over USB and it works :-)
Now it is time to build and try icestorm on linux.

EDIT:
So after hour or so I have icestorm/arachne-pnr/yosys built and installed on my Pi3. Building example icestorm/examples/up5k_rgb worked fine. Then attached over usb to Pi3. make sudo-prog (which called iceprog -S) printed no  error and stopped previous led blinking but nothing more happened. However when I removed the -S it flashed fine and now I have very slowly fading rgb led between shades of r,g,b colors, cool :-)

[iMo]

I've tried with my external FT232H and UPduino v1 to elaborate how to use the Serial UART over USB in the same wiring as it is with the new UPduino v2.

Experimental, use at your own risk.

It works, when:

1. insert 3x 680ohm resistors in series with FT232H's pins 13 (TXD), 15 (RTS), 17 (DTR)

2. you have to redirect your fpga app's RxD/TxD to UP5k's pins 14 (TxD) and 15 (RxD) such they will be active only when UP5k's pin 16 is high (pin 16 is connected to the chipselect of the bitstream flash), the UP5k's pin 15 is an "inout" based on the 16, when 16 is low you may use those pins for the flash SPI access when applicable (ie. I've been using the flash SPI with the above mentioned Forth for load/save the dictionaries from/into the flash).
Mind when writing the SPI flash while in console you will see a garbage coming in..

3. you have to reinsert the USB plug as the Diamond programmer leaves the FT232H in SPI mode (the FT232H starts in Serial UART mode when you open the COMx in your terminal app, ie. in TeraTerm)

4. you have to toggle the DTR to 'High' within your terminal app, otherwise the UP5k will not boot from the bitstream flash (the UP5k does sense the SPI flash chipselect (wired to the DTR) and when high it boots from the SPI flash).

[tiltit]

I have just received the upduino V2. It took about a week and a half to get to Germany. When I first plugged it in it wasn't drawing any current, then I noticed that the micro usb connector wasn't properly soldered on. Once that was fixed I got it working with the open source yosys and icestorm toolchain. I am now trying to lean verilog and how to make use the thing. I have still no idea what I can use it for but I find it interesting none the less. Overall I think it's quite good, it permits me to experiment with an fpga without having to spend a lot money for something that may or may not be useful to me. In any case it is interesting to see how different it is from writing a program for a microcontroller.
Does anyone know if there is a simple cpu core that would fit onto it? I understand that 5K Lut is quite small.

[iMo]

FYI - you may go to OpenCores, Processors tab, and you get a list of various verilog/vhdl CPUs. A CPU which fits into ~1500 LUTs of Xilinx may fit in UPduino. The only issue could be the 15kB of internal bram only (which can be loaded out of bitstream upon boot), and the fact it cannot be inferred easily (has to be done manually). You have got 128kBytes of single port ram which could be used as well (but it cannot be loaded off the bitstream). You may attach an external sram, the limit is the number of available i/o pins. If you are keen on Forth the J1a CPU fits nice.

[mark03]

I bookmarked this a while back:

https://github.com/cliffordwolf/picorv32

I'm sure there are plenty of small cores to choose from, but this is RISC V which IMO makes it compelling quite apart from its capabilities/attributes.  (I think RISC V is likely to become more important in the future == good to learn.)

[iMo]

I've got the v2 and it works fine 
Tried with Diamond programmer.
Btw, the mail sorting machines are not v2 friendly - it took me half an hour to get the tiny usb socket work (deformed by the machines).

[Cerebus]

It's increasingly looking like the issues I'm having with the iCE40 board I made are due to my remarkably poor decision to enable VCC/VCCPLL manually *after* powering the IOBanks. I removed all other SPI devices from the board, and it still won't assert VCCPLL.

From the data sheet:

4.5. Power-up Supply Sequence
It is recommended to bring up the power supplies in the following order. Note that there is no specified timing delay between the power supplies, however, there is a requirement for each supply to reach a level of 0.5 V, or higher, before any subsequent power supplies in the sequence are applied.
1. VCC and VCCPLL should be the first two supplies to be applied. Note that these two supplies can be tied together subject to the recommendation to include a RC-based noise filter on the VCCPLL. Refer to TN1252, iCE40 Hardware Checklist.
2. SPI_VCCIO1 should be the next supply, and can be applied any time after the previous supplies (VCC and VCCPLL) have reached as level of 0.5 V or higher.
3. VPP_2V5 should be the next supply, and can be applied any time after previous supplies (VCC, VCCPLL and SPI_VCCIO1) have reached a level of 0.5 V or higher.
4. Other Supplies (VCCIO0 and VCCIO2) do not affect device power-up functionality, and they can be applied any time after the initial power supplies (VCC and VCCPLL) have reached a level of 0.5 V or greater. There is no power down sequence required. However, when partial power supplies are powered down, it is required the above sequence to be followed when these supplies are re-powered up again.

Note the usual Lattice data sheet clarity! Oh Boy, do they need to hire some better tech writers.

I don't think that it's an accident that the required 0.5V is a diode drop at low current. That is, I suspect it represents substrate diodes (isolation tubs, whatever) between the subsystems which are required to be held reverse biased at all times.

[iMo]

I do not think the UP5k dev boards I've seen (and I've got ie UPduino v1, v2) care much about the sequence, and they simply work..

[Cerebus]

I think you're OK as long as you don't have the bias the wrong way around - so bringing up all the rails at the same slope is OK, bringing up VCC and VCCPLL after the IO rails isn't OK.

[daveshah]

I think most of the cheap boards derive 1.2V from 3.3V using an LDO (usually itself derived from 5V with another LDO), so 3.3V VccIO will be brought up first, but presumably the difference and/or time period isn't high enough to cause a practical problem...

[Cerebus]

Really need some graphs here but I can't be bothered. If you derive the 1.2V from 3.3V then they both tend to ramp up to the same voltage at the same time (i.e they both have the same ^dv/_dt and perhaps a small offset) until the higher supply overtakes the lower supply at 95-100% of the lower supplies final value. Separately derived supplies may have different slopes and often tend to hit the same proportion of their final voltage at the same time.

The iCE40 is very forgiving in terms of power supply sequencing; check the specs of some other FPGAs and you can find requirements that are hard enough to meet that specific power supply chips have been developed to go with them. I think cleaningOut above just managed to find the one power sequencing order that the iCE40 chips won't tolerate, which appears to be bringing VCCPLL up late.

[iMo]

This is the most probable power-up sequence with UPduino v2:

[aventuri]

hi,

just a note about a new software called Lattice Radiant that has been released.

it should target precisely the Upduino FPGA iCE40 UltraPlus UP5K.. it should run both on indows and Linux. But a quick shot to install it on Debian turned me down, because it says "Fedora/RedHat" only.. let's see in next days..

I'm really wondering why they departed from IceCube2 with a new IDE specifically for UltraPlus..  anyone hints?

bye

andrea

[ale500]

just a note about a new software called Lattice Radiant that has been released.

Just when I was hoping they would integrate them into Diamond...

From the demo video it looks like icecube with a new GUI..

[daveshah]

Just when I was hoping they would integrate them into Diamond...

From the demo video it looks like icecube with a new GUI..

As far as I can see, it's actually much closer to Diamond with a new GUI (and limited device support) under the hood. Also, they renamed all the primitives - mostly removing the "SB_" prefix, the last remaining trace of the iCE parts' SliconBlue heritage.

[iMo]

Radiant: It is not only the SB_ prefix.. 
There is a migration document, all stuff has been renamed somehow. They mention "Radiant IP Catalog " I cannot find. You cannot take the IceCube2 verilog, remove SB_ and run under Radiant, no way..
I've installed it under Win7, the license var name the same as the of Diamond
Much better editor  and the Radiant programmer is integrated as well (the same as the Diamond's stand alone one)..

[daveshah]

There isn't a published ip catalog yet, but you can work a lot out from the provided simulation and cell libraries.

It seems as well as the name changes the format of the parameters also changes, from being a Verilog number parameter to a numeric literal inside a string.

[iMo]

Radiant: not compatible with IceStorm anymore.. 

[iMo]

Radiant: Reveal analyzer does recognize the FT232H (an external cheapo board).

Code: [Select]

INFO - cable[0]=FTUSB-0,USB2,Single RS232-HS Location 0000Mind you have to enable the reveal's cableserver in your firewall, however..

[ale500]

The UPDuino board has a 4 MByte Flash device, but the configuration needs like 75 kBytes... Does anybody know how to pre-program some use data ?

[iMo]

The bitstream is first 104156 bytes. You can access (read/write) data in the 4MB bitstream SPI flash from verilog/vhdl. The UP5k's "special" SPI flash pins work as standard io pins after the UP5k boots. Pre-programming the SPI flash with user data has to be done via your programmer (any SPI flash programmer works).

PS: for example there is the icestorm's  multi tool - it could be easily modified to incorporate any user data into the bitstream, I guess.. 

[s4]

mouser.de ships it same day for €40 with a nice camera+microphone board. Also Lattice has that same double package. 

[s4]

did anyone manage to run the famous  J1  Forth  soft-CPU on it ?

on the UPduino  or the NAND-Land  GO board ?  both have same FPGA by LAttice

[s4]

this guy seems to be #1 on the Forth MCU front:    http://excamera.com/sphinx/article-j1a-swapforth.html 

[iMo]

did anyone manage to run the famous  J1  Forth  soft-CPU on it ?

on the UPduino  or the NAND-Land  GO board ?  both have same FPGA by LAttice

Here you are - with improved J1a and the famous Mecrisp Forth:

https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB

Ready to build with IceStorm, IceCube, Radiant..