Port to Lattice iCEblink40-HX1K Evaluation Board

[Stefan Lukasser]

Hi all, 

I'd like to port the FPGALink toolchain to a Lattice iCEblink40-HX1K Evaluation Board (link)

The board has following features:

• High-performance, low-power iCE40HX1K FPGA in 100-pin TQFP package
• USB programming, debugging, virtual I/O functions, and power supply
• Four user LEDs
• Four capacitive-touch buttons
• 3.3 MHz clock source
• 1Mbit SPI serial configuration PROM
• Supported by Lattice iCEcube2 design software
• 68 LVCMOS/LVTTL (3.3V) digital I/O connections on 0.1” through-hole connections
• Supports third-party I/O expansion boards and modules, including 3.3V Arduino Shield boards (requires additional sockets, not supplied)

The USB interface is based on an Atmel AT90USB162, so this part should work.

My questions are now:

- is the hardware compatible? connections between uC and FPGA -> schematic

- programming of the FPGA has to be done using the provided command line utility? is it necessary to overwrite the firmware

  of the microcontroller? If yes, is there a possibility to backup the existing firmware first?

Sorry if these are stupid questions, it is my first FPGA evaluation board :)

Thanks in advance,

Stefan

[Chris McClelland]

Great!

The schematic shows an EPP-style connection between AVR and FPGA, which
is used for communication with the FPGA design after programming. This
bit is fine, but the AVR firmware currently only supports
FPGA-programming with JTAG, whereas your board appears to only support
an SPI-style interface, which is currently only supported in the FX2
firmware. Adding it to the AVR firmware will be straightforward, I just
haven't done it yet.

FPGALink is just a library. The command-line utility is provided merely
as an example of how to use the library. You're free to use the utility
to program the FPGA, or link it with your own applications.

It is necessary to overwrite the AVR firmware. Whether or not you can
make a backup of the existing firmware depends on the manufacturer. If
they have read-protected the AVR, you won't be able to read it. With no
backup, unless you can get Lattice to send you replacement firmware,
loading FPGALink firmware will be a one-way operation!

To find out if it's read-protected, you must attach a programmer to J7
on the board and query the AVR. Suitable programmers are cheap - if
you're serious about this, I could even lend you one[1].

Chris

[1]http://www.makestuff.eu/wordpress/minimus-avr-isp-clone/

On Wed, 2013-06-19 at 01:21 -0700, Stefan Lukasser wrote:
> Hi all,
>
>
> I'd like to port the FPGALink toolchain to a Lattice iCEblink40-HX1K
> Evaluation Board (link)
> The board has following features:
>
>

> * High-performance, low-power iCE40HX1K FPGA in 100-pin TQFP
> package
> * USB programming, debugging, virtual I/O functions, and power
> supply
> * Four user LEDs
> * Four capacitive-touch buttons
> * 3.3 MHz clock source
> * 1Mbit SPI serial configuration PROM
> * Supported by Lattice iCEcube2 design software
> * 68 LVCMOS/LVTTL (3.3V) digital I/O connections on 0.1”
> through-hole connections
> * Supports third-party I/O expansion boards and modules,

> including 3.3V Arduino Shield boards (requires additional
> sockets, not supplied)
> The USB interface is based on an Atmel AT90USB162, so this part should
> work.
>
>
> My questions are now:
> - is the hardware compatible? connections between uC and FPGA
> -> schematic
> - programming of the FPGA has to be done using the provided command
> line utility? is it necessary to overwrite the firmware
> of the microcontroller? If yes, is there a possibility to backup the
> existing firmware first?
>
>
> Sorry if these are stupid questions, it is my first FPGA evaluation
> board :)
>
>
> Thanks in advance,
>
>
> Stefan
>

> --
> You received this message because you are subscribed to the "FPGALink
> Users" mailgroup (see
> http://www.makestuff.eu/wordpress/software/fpgalink/).
>
> To post to this group, send email to fpgalin...@googlegroups.com
> To unsubscribe from this group, send email to
> fpgalink-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/fpgalink-users?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "FPGALink Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fpgalink-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Stefan Lukasser]

Hi,

thanks for the quick answer!

I will check if I can read out the firmware, if not I'll replace the MCU with a new, empty one.

As for the SPI programming, what is necessary to modify to get this working? 

[Chris McClelland]

> if not I'll replace the MCU with a new, empty one.

That is music to my ears. It marks you as one worthy of the name
"hacker" (in the original 1970s sense of the word)! :-)

You can see how the SPI programming is achieved on the FX2[1]. We need
to implement doProgram() on the AVR also[2]. At the moment the AVR
firmware doesn't use the AVR's SPI logic, it just bit-bangs[3] it, to
support boards with different pin assignments. I should change it to use
the hardware SPI for the specific case where the board connections make
it possible to do so, this will speed up the programming enormously.

For your board, we need to determine the correct programming algorithm.
For Xilinx FPGAs, the algorithm (simplified) looks like this:

Assert PROG (active low)
Wait for INIT and DONE to go low
Deassert PROG
Wait for INIT to go high
Clock in bits from the FPGA bitstream file
Check that DONE went high

It is implemented on the host side[4].

A similar algorithm appears to be possible for Lattice FPGAs[5], but the
signals appear to have nonstandard names on your board's schematic.

This is not really a "user" discussion, it's more of a "developer"
discussion, so I'm happy to take it off this mailgroup and discuss it
between us, either on email or preferably the IM of your choice
(GoogleTalk, Jabber, MSN, Skype, IRC etc).

To be clear though, this is not a trivial piece of work; if we can work
efficiently together on it, it will probably take a few days to get
everything working. Unfortunately I have no Lattice FPGAs to test with,
so I can't give you a finished product, I can only give you stuff to
try, and provide help and advice. Much of it will necessarily be trial
and error. Your board appears to have adequate protection against
firmware programming errors (series resistors etc), so it's unlikely
we'll damage your board, but I can't guarantee that.

The first thing to do is to get to the point where you can build your
own AVR firmware and load it into your board. I have a whole load of
at90usb162-related posts on my website[6&7] which may be helpful.
Although it's possible to do this stuff on Windows, it's MUCH easier on
Linux.

Chris

[1]https://github.com/makestuff/libfpgalink/blob/master/firmware/fx2/prog.c#L454
[2]https://github.com/makestuff/libfpgalink/blob/master/firmware/avr/prog.c#L303
[3]https://github.com/makestuff/libfpgalink/blob/master/firmware/avr/prog.c#L57
[4]https://github.com/makestuff/libfpgalink/blob/master/prog.c#L340
[5]http://www.latticesemi.com/documents/TN1222.pdf
[6]http://www.makestuff.eu/wordpress/category/electronics/minimus/
[7]http://www.makestuff.eu/wordpress/electronics/nanduino/

[Chris McClelland]

Actually, this doc is better than the other one I sent:

http://www.latticesemi.com/documents/TN1248.pdf

It has programming algorithm flow-charts, and has the same signal names
as those used on your board's schematic.

Chris

[Stefan Lukasser]

Thanks for the input so far.

That's a good idea, could you send me an email, so that we can exchange contacts (slukasser at gmail.com)

Stefan

[Peter Stuge]

Chris McClelland wrote:
> This is not really a "user" discussion

True as that is I would still love to follow the discussion purely
out of interest. Having it archived somewhere also makes for a nice
reference the next time someone wants to port to a new architecture.
(Yes, rare, but still.)


//Peter

[Chris McClelland]

Acknowledged. I'll see what I can do. Perhaps a separate fpgalink-devel
list makes sense, or perhaps a one-off dump of the IM logs to this topic
at a later date. Unfortunately my brain considers context-switches to be
extremely costly. Going on past experience with bringing new FPGA boards
into the fold remotely, trying to collaborate over email lacks immediate
feedback, making the process difficult, frustrating and unnecessarily
lengthy.

[Peter Stuge]

Chris McClelland wrote:
> Acknowledged. I'll see what I can do. Perhaps a separate fpgalink-devel
> list makes sense, or perhaps a one-off dump of the IM logs to this topic
> at a later date. Unfortunately my brain considers context-switches to be
> extremely costly. Going on past experience with bringing new FPGA boards
> into the fold remotely, trying to collaborate over email lacks immediate
> feedback, making the process difficult, frustrating and unnecessarily
> lengthy.

Yes, I understand. Maybe IRC? I'm in #fpgalink on irc.freenode.net.


//Peter

[Chris McClelland]

Peter,

Actually, yes, IRC is a great idea. I can post the logs to the mailing
list periodically.

I just joined the channel as chrismc. Can you give me ops?

Chris

[Chris McClelland]

Stefan finally got approval for his project, and we were able to get the FPGALink/AVR firmware running nicely on his iCEblink40 board.

In case anyone else wants to do it, here's the instructions. You should realise that this is an irreversible operation, because Lattice have deliberately prevented you from making a backup of the existing firmware. It will also invalidate your warranty. If you brick your board in the process, I will try to help you recover it, but I will not be held responsible.

You'll need an iCEblink40 board and an AVR-ISP programmer (Lattice unhelpfully disabled the AVR bootloader). Attach the programmer to J7 on the board, being careful to match the signals given in the iCEblink40 schematic with the signals on your programmer's header.

I attached a 20131101 label to the FPGALink code so you should be able to build it yourself. Rather than requiring you to build the firmware from source, I published the .hex file here:

https://gist.github.com/makestuff/7282251/raw/95123dcd0652ba1d2454b584a84a6454b8397852/firmware.hex

You can install it in one of two ways. Like this:

Install the LUFA bootloader[1] using your AVR-ISP, e.g with avrdude:

avrdude -c avrispmkII -P usb -p at90usb162 -e -U flash:w:BootloaderDFU.hex -U hfuse:w:0xD9:m -U lfuse:w:0x5E:m -U efuse:w:0xF4:m

This installs the bootloader in the top 4KiB of flash. You can now detach your AVR-ISP - we're finished with it.

The board will now start the bootloader when you connect it. You can use either Atmel FLIP[2] or dfu-programmer[3] to write the firmware.hex file (the FPGALink/AVR firmware) to the bottom 12KiB of flash.

The advantage of doing it this way is you can update the FPGALink firmware without needing to attach your AVR-ISP again.

Or like this:

Write firmware.hex directly using your AVR-ISP, e.g avrdude:

avrdude -c avrispmkII -P usb -p at90usb162 -e -U flash:w:firmware.hex -U hfuse:w:0xD9:m -U lfuse:w:0x5E:m -U efuse:w:0xF4:m

...and you're done.

It might seem like option 2 is easier, but I recommend you do option 1 because it makes future firmware updates easier.

Note that in both cases I'm resetting the low, high and extended fuse bytes to their factory-default settings listed in the AT90USB162 datasheet.

Having installed the FPGALink firmware, the board will now enumerate as an FPGALink/AVR device. You'll need a driver for it, which you can install by running Zadig.exe[4] and choosing the device with VID/PID 1D50:602B.

Now you can build the 20131101-tagged release of the FPGALink host-side code:

1) Download http://www.swaton.ukfsn.org/bin/makestuff-windows-20130829.tar.gz
2) Unpack as C:\makestuff.
2) Run C:\makestuff\setup.exe, select a C compiler and click "Create Shortcut".
3) Launch the desktop shortcut created by setup.exe.
4) Continue:
cd $HOME/apps
../scripts/msget.sh makestuff/flcli/20131101
cd flcli
make deps
cd ..
../scripts/msget.sh makestuff/gordon
cd gordon
make deps

The "gordon" tool is for programming your board, and flcli is the regular FPGALink command-line tool. You're now ready to build the cksum example. Unfortunately I was unable to make the Lattice tools work with hdlmake.py, so you'll have to fetch the code manually and build it in the iCEcube2 GUI:

cd $HOME
scripts/msget.sh makestuff/hdlmake
cd hdlmake/libs
mkdir makestuff
cd makestuff
../../../scripts/msget.sh makestuff/comm-fpga
../../../scripts/msget.sh makestuff/seven-seg
cd ../../apps
mkdir makestuff
cd makestuff
../../../scripts/msget.sh makestuff/swled
cd swled/cksum/vhdl
wget -q https://gist.github.com/makestuff/7255059/raw/185474c70af5ba33a95b10292f5f108f0e948952/cksum_sbt.project

Now launch iCEcube2, press ctrl-o and double-click the cksum_sbt.project in C:\makestuff\hdlmake\apps\makestuff\vhdl, then select the physical constraint file:

1) Open "P&R Flow -> Add P&R Files".
2) Right-click "Constraint Files" and choose "Add Files".
3) Navigate to ../../templates/epp/boards/iceblink40/board.pcf

You can now build it into a .bin file, which you can then load like this:

cd $HOME/apps/gordon win.x86/rel/gordon -v 1d50:602b -p ../../hdlmake/apps/makestuff/swled/cksum/vhdl/cksum_Implmnt/sbt/outputs/bitmap/top_level_bitmap.bin

Once it's loaded you can interact with it like this:

../flcli/win.x86/rel/flcli -v 1d50:602b -a 'w1 CA;w2 FE;r1;r2'

You will want to solder a 3-way SIL strip into JP2 on your board. This selects different clock speeds. Leaving it open gives you 3.33MHz. Shorting the top two pins with a jumper gives you 333kHz, and shorting the bottom two pins gives you 33.3MHz. You can see how the choice of clock-frequency affects the throughput. Here's me copying 1MiB of random data into my board, first at 333kHz, then at 3.33MHz and finally at 33.3Mz:

$ dd if=/dev/urandom of=random.dat bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.0745853 s, 14.1 MB/s
$ win.x86/rel/flcli -v 1d50:602b:0001 -a 'w1 00;w2 00;w0 "random.dat";r1;r2' -b
Attempting to open connection to FPGALink device 1d50:602b:0001...
Executing CommFPGA actions on FPGALink device 1d50:602b:0001...
Wrote 1 bytes (checksum 0x0000) to channel 1 at 0.003117 MiB/s
Wrote 1 bytes (checksum 0x0000) to channel 2 at 0.004436 MiB/s
Wrote 1048576 bytes (checksum 0x84F4) to channel 0 at 0.048841 MiB/s
Read 1 bytes (checksum 0x0084) from channel 1 at 0.000609 MiB/s
Read 1 bytes (checksum 0x00F4) from channel 2 at 0.004277 MiB/s
         00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 84 F4                                           ..
$ win.x86/rel/flcli -v 1d50:602b:0001 -a 'w1 00;w2 00;w0 "random.dat";r1;r2' -b
Attempting to open connection to FPGALink device 1d50:602b:0001...
Executing CommFPGA actions on FPGALink device 1d50:602b:0001...
Wrote 1 bytes (checksum 0x0000) to channel 1 at 0.001855 MiB/s
Wrote 1 bytes (checksum 0x0000) to channel 2 at 0.003455 MiB/s
Wrote 1048576 bytes (checksum 0x84F4) to channel 0 at 0.125537 MiB/s
Read 1 bytes (checksum 0x0084) from channel 1 at 0.002167 MiB/s
Read 1 bytes (checksum 0x00F4) from channel 2 at 0.004375 MiB/s
         00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 84 F4                                           ..
$ win.x86/rel/flcli -v 1d50:602b:0001 -a 'w1 00;w2 00;w0 "random.dat";r1;r2' -b
Attempting to open connection to FPGALink device 1d50:602b:0001...
Executing CommFPGA actions on FPGALink device 1d50:602b:0001...
Wrote 1 bytes (checksum 0x0000) to channel 1 at 0.001979 MiB/s
Wrote 1 bytes (checksum 0x0000) to channel 2 at 0.003076 MiB/s
Wrote 1048576 bytes (checksum 0x84F4) to channel 0 at 0.146952 MiB/s
Read 1 bytes (checksum 0x0084) from channel 1 at 0.003668 MiB/s
Read 1 bytes (checksum 0x00F4) from channel 2 at 0.004436 MiB/s
         00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 84 F4                                           ..

Notice that at 333kHz, the FPGALink transfer rate is only 49KiB/s. This rises to 126KiB/s at 3.33MHz, and finally reaches 147KiB/s at 33.3MHz. This is roughly half the 330KiB/s throughput quoted in the FPGALink manual because the manual assumes a 16MHz AVR clock, whereas the iCEblink40's AVR only has an 8MHz crystal.

For future reference, assuming you installed the bootloader, you can tell the board to return to the bootloader by running "gordon -v 1d50:602b -b". At that point you can either install updated FPGALink firmware (using FLIP or dfu-programmer), or you can power-cycle the board to get back to the existing FPGALink firmware. If you wish to build the firmware yourself, there's a few special options[5] you'll need in order to get firmware suitable for the iCEblink40.

Have fun!

Chris

[1]https://gist.github.com/makestuff/7282251/raw/645c803741e14e10f2ccbbb6e2aa648b88cf789f/BootloaderDFU.hex
[2]http://www.atmel.com/tools/FLIP.aspx
[3]http://dfu-programmer.sourceforge.net/
[4]http://zadig.akeo.ie/
[5]https://gist.github.com/makestuff/7282251/raw/28a5d6f934207d038a03bd7de8c8a0d10a652108/HOWTO.txt