8$ iCE40 developer board..

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