Ultra / UltraPlus support

[drom]

As we discussed on the twitter: https://twitter.com/oe1cxw/status/821646243101372417 it would be nice to have support for the latest / greatest FPGAs. Created this ticket to scope the work need to be done:

New features (in priority order?)

• DSP blocks. (MULT16 + ACC32) iCE5LP1K = 2; iCE5LP2K/4K = 4; iCE40UP3K = 4; iCE40UP5K = 8;
• SPRAM 256 kibit. iCE40UP3K/5K = 4 blocks;
• HF (48MHz), LF (10KHz) Oscillator
• Other Hard-IPs, I2C, SPI, PWM, etc.

Affected tools

• icestorm , new blocks, new devices (resource configuration?)
• yosys , resource inference, instantiation?
• arachne-pnr , placement, routing information for new resources?

Next steps

• make sense to start with the flagman chip on Eval board: http://www.digikey.com/short/3fpvm3
• stab unknown parts of the bitstream with predefined sequences, to achieve ic40 functionality
• propagate stabs for all tools
• work on feature by feature basis

[cliffordwolf]

This two posts outline the first steps for adding support for additional devices:

• https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/
• https://www.reddit.com/r/yosys/comments/4ovgn5/icestorm_adding_support_for_new_devices_part_2/

As I've said many times, I don't have the time (i.e. funding) to work on any of that. I only offer that I'll add Yosys support for additional cell types when there is support for a new cell type in Icestorm and Arachne-pnr.

[tannewt]

@drom Did you ever start reverse engineering these new chips? I may pick one up in case I find some time.

[drom]

@tannewt no, I have not found enough time to do it. But I think UltraPlus is very interesting chip to work with.

[tannewt]

I've started working on the iCE40UP5K for Adafruit here. I'm using the dev board for it but may sketch out a feather design for it too.

[cliffordwolf]

I've started working on the iCE40UP5K for Adafruit here.

That's awesome! Do not hesitate to contact me if you have any questions, or simply open github issues here.

[Obijuan]

Yes!!!!!! Thanks a lot!!! Please don't hesitate on asking for beta testers :-)

[tannewt]

@cliffordwolf Any tips on handling CRAM and BRAM sizes that vary? Thanks!

Parsing bitstream file..
Found preamble at offset 83.
Next command at offset 87: 0x51 0x00
Setting freqrange to 'low'.
Next command at offset 89: 0x01 0x05
Resetting CRC.
Next command at offset 91: 0x92 0x0020
Setting warmboot to 'enabled'.
Next command at offset 94: 0x62 0x02b3
Setting bank width to 692.
Next command at offset 97: 0x72 0x0150
Setting bank height to 336.
Next command at offset 100: 0x82 0x0000
Setting bank offset to 0.
Next command at offset 103: 0x11 0x00
Set bank to 0.
Next command at offset 105: 0x01 0x01
CRAM Data [0]: 692 x 336 bits = 232512 bits = 29064 bytes
Next command at offset 29173: 0x72 0x00b0
Setting bank height to 176.
Next command at offset 29176: 0x11 0x01
Set bank to 1.
Next command at offset 29178: 0x01 0x01
CRAM Data [1]: 692 x 176 bits = 121792 bits = 15224 bytes
Next command at offset 44406: 0x72 0x0150
Setting bank height to 336.
Next command at offset 44409: 0x11 0x02
Set bank to 2.
Next command at offset 44411: 0x01 0x01
CRAM Data [2]: 692 x 336 bits = 232512 bits = 29064 bytes
Next command at offset 73479: 0x72 0x00b0
Setting bank height to 176.
Next command at offset 73482: 0x11 0x03
Set bank to 3.
Next command at offset 73484: 0x01 0x01
CRAM Data [3]: 692 x 176 bits = 121792 bits = 15224 bytes
Next command at offset 88712: 0x62 0x009f
Setting bank width to 160.
Next command at offset 88715: 0x72 0x0080
Setting bank height to 128.
Next command at offset 88718: 0x11 0x00
Set bank to 0.
Next command at offset 88720: 0x82 0x0000
Setting bank offset to 0.
Next command at offset 88723: 0x01 0x03
BRAM Data [0]: 160 x 128 bits = 20480 bits = 2560 bytes
Next command at offset 91287: 0x82 0x0080
Setting bank offset to 128.
Next command at offset 91290: 0x01 0x03
BRAM Data [0]: 160 x 128 bits = 20480 bits = 2560 bytes
Next command at offset 93854: 0x62 0x004f
Setting bank width to 80.
Next command at offset 93857: 0x11 0x01
Set bank to 1.
Next command at offset 93859: 0x82 0x0000
Setting bank offset to 0.
Next command at offset 93862: 0x01 0x03
BRAM Data [1]: 80 x 128 bits = 10240 bits = 1280 bytes
Next command at offset 95146: 0x82 0x0080
Setting bank offset to 128.
Next command at offset 95149: 0x01 0x03
BRAM Data [1]: 80 x 128 bits = 10240 bits = 1280 bytes
Next command at offset 96433: 0x62 0x009f
Setting bank width to 160.
Next command at offset 96436: 0x11 0x02
Set bank to 2.
Next command at offset 96438: 0x82 0x0000
Setting bank offset to 0.
Next command at offset 96441: 0x01 0x03
BRAM Data [2]: 160 x 128 bits = 20480 bits = 2560 bytes
Next command at offset 99005: 0x82 0x0080
Setting bank offset to 128.
Next command at offset 99008: 0x01 0x03
BRAM Data [2]: 160 x 128 bits = 20480 bits = 2560 bytes
Next command at offset 101572: 0x62 0x004f
Setting bank width to 80.
Next command at offset 101575: 0x11 0x03
Set bank to 3.
Next command at offset 101577: 0x82 0x0000
Setting bank offset to 0.
Next command at offset 101580: 0x01 0x03
BRAM Data [3]: 80 x 128 bits = 10240 bits = 1280 bytes
Next command at offset 102864: 0x82 0x0080
Setting bank offset to 128.
Next command at offset 102867: 0x01 0x03
BRAM Data [3]: 80 x 128 bits = 10240 bits = 1280 bytes
Next command at offset 104151: 0x22 0xa3b6
CRC Check OK.
Next command at offset 104154: 0x01 0x06
Wakeup.
Chip type is '5k'.

[tannewt]

Ok, I think I have icepack working but I only checked it with the one example from the reddit instructions. New commit is here.

One gotcha was that the bottom quarter of the grid is used for the SRAM and therefore the CRAM and BRAM data is half the height of the top quadrants. I think I accounted for that correctly in icepack now though.

I'm also unsure of the cell configuration length for the first set of cells (the left and right sides) because they are DSP blocks rather than IO blocks. In the floor planner they are called IPConnect and Multiplier tiles which span 1 and 4 vertical cells respectively. I can't find any mention of these block names in the datasheets. Its mostly refered to as DSP blocks. The bottom left corner is a CLOCK tile and the bottom right is a WARMBOOT tile.

I'm bit at a loss for next steps. I don't actually have any FPGA experience which makes coming up with example Verilog tricky. (I did do it in college but that was ~2008.) My high level goal is to get a picorv32 going on the chip using the hard IPs. I want to create a board with the Adafruit Feather form factor which can basically replace an M0+ MCU but have the flexibility of custom peripherals or fully custom logic.

I know there is work to be done in Arachne-pr but I'm not sure where to look in there. Guidance on how to get the basic logic and IO cells going for the new chip would be welcome. Once that is done, we can start looking into the new block types.

iceprog seemed to work just fine because the dev board uses the normal FTDI chip.

Thanks!

[cliffordwolf]

@tannewt I'm at DAC right now in Texas and after that I'll travel directly to the UK for FV2017. After that I'll write a "part 3" of the guide on reddit. Please remind me if I haven't posted anything by the end of next week. :)

Please see the two comments I added to your patch.

Don't worry about FPGA experience. For this project (adding support for 5k) having more experience with FPGA design would probably not help as much as you might imagine.

The work to be done in arachne-pnr is not acute right now. The next steps will be:

• Sanity check: does .bin -> .asc -> .bin -> .asc -> ... yield same files (maybe with exception of the comment field)
• Sanity check: is glbcheck.py satisfied with .glb vs .asc equivalence?
• Figuring out the difference (if any) in the different cell types.

The first two points are just checks in your icepack changes are correct. The third one will tell us how much new reverse-engineering we will need to do.

Here is the very short version of the guide to come: Add 5k support to icefuzz (start by patching the makefile) and see if it finds any new or conflicting bit assignments. If it does: Create a new database for 5k and that tile type (like it is already the case for 8k and block rams).

[tannewt]

@cliffordwolf Thank you so much for your guidance on this. I'd suggest enabling the GitHub wiki and posting the guides there because the reddit posts are now immutable. Having the info on a wiki or in the code itself would allow me to add more details as I figure them out. (For example, where to find the info for the chipdb.)

I did one simple check with glbcheck.py before and will do one today. (to probably find I broke icepack.)

I actually spent some time adding the chip to the db yesterday and will start today by doing the icefuzz work. Thanks for the tip on that! I really appreciate all of the work you've put into this project.

[Obijuan]

+1 to enabling the wiki :-)

[cliffordwolf]

Wiki is enabled. Feel free to copy the posts and edit away.

[tannewt]

Thanks @cliffordwolf! I copied the posts here and will add more as I come across it.

[tannewt]

I've gotten icefuzz going for the 5k. Change for it is https://github.com/adafruit/icestorm/commit/58a6110be198089d784b5ad3e2ecb611182bd5ea.

[tannewt]

I discovered icefuzz/tests and have been using them to update more info in icebox.py. https://github.com/adafruit/icestorm/commit/a25c8679ac37df5219e1d7a8cdd932288cd596b1

[tannewt]

I discovered I had an error in icepack and used netpbm to correct the mapping. glbcheck.py now passes without issue on most of the fuzz tests. I'm having trouble creating the chipdb though because of duplicate segments. Latest commits are here: https://github.com/adafruit/icestorm/commits/master

[cliffordwolf]

@tannewt Here is an example 8k .asc file:

example_8k_image.asc.txt

If you pack that into a .bin file with my old version of icepack and your new version of icepack you get different results. The difference is in block ram configuration. Please investigate and fix.

[cliffordwolf]

@tannewt Jfyi: I have an ice5k branch now: https://github.com/cliffordwolf/icestorm/tree/ice5k

Maybe you'd like to rebase your work ontop of that.

[tannewt]

Thanks @cliffordwolf! I should have time tomorrow to rebase and fix the block ram problem. Its not super high on my list of things to do but I should have more time for it in the next few weeks.

[tannewt]

Ok, I've rebased and fixed BRAM for 8k. I'm not sure if its correct for 5k. https://github.com/adafruit/icestorm/commit/b019ae4e65a65e26ae0b765641f2c1a8150500b0

I'm going to spend a little time looking at the icebox chipdb issues I was running into.

[tannewt]

I realized my net issue was due to not normalizing the db entries. Fixed in f704149.

[aurabindo]

Is the support for ultraplus devices in a usable state?

[cliffordwolf]

@aurabindo No. It's still in a very early stage.

@tannewt I've now merged your stuff into my master with a ton of bugfixes ontop of it. Please make sure that you have pulled my master branch before continuing your work.

[tannewt]

Thanks for the heads up @cliffordwolf. I'm not exactly sure when I'll pick it up again. I'll be a lot more interested when chips are more readily available. Thanks!

[mirecta]

Chips are avalilable ice40up5k board http://gnarlygrey.atspace.cc/development-platform.html#upduino 7.99USD

[multician74]

also available on ebay, search "ice40". they go for $9.99, any quantity, and there is a link to the aforementioned $7.99 GnarlyGrey on the very same ebay page.

[mirecta]

something news here ? future plans ?

[daveshah1]

What version of icecube have you been using for icefuzz @tannewt @cliffordwolf ? I've been trying to use the latest version but it fails in make_io.py with a placement violation unless one of the IOs (pins 23) are removed from the pin list in fuzzconfig.py. Failures seem to occur whenever the clk_in of the SBIO is assigned to this pin. The output is as follows:

bash ../icecube.sh io_00 > io_00.log 2>&1 && rm -rf io_00.tmp || tail io_00.log
Total HPWL cost is 351
Warning: cannot find the IO pin Input/Output direction for clk_out_pad_0 (ICE_IO)
Warning: cannot find the IO pin Input/Output direction for latch_in_pad_1 (ICE_IO)
Warning: cannot find the IO pin Input/Output direction for oen_pad_0 (ICE_IO)
Warning: cannot find the IO pin Input/Output direction for latch_in_pad_0 (ICE_IO)
Warning: cannot find the IO pin Input/Output direction for oen_pad_1 (ICE_IO)
Warning: cannot find the IO pin Input/Output direction for clk_out_pad_1 (ICE_IO)
ICE_GB_IO clk_in_pad_1 ICE_GB clk_in_pad_0_gb SB_GB_IO & SB_GB placement conflict!
used logic cells: 0
Packing failed due to placement violation!
python3 ../glbcheck.py io_00.asc io_00.glb
Traceback (most recent call last):
  File "../glbcheck.py", line 9, in <module>
    with open(argv[1]) as f:
FileNotFoundError: [Errno 2] No such file or directory: 'io_00.asc'
make[1]: *** [Makefile:4: io_00.bin] Error 1
make[1]: Leaving directory '/home/david/icestorm/icefuzz/work_5k_io'
make: *** [Makefile:132: data_5k_io.txt] Error 2

I have attached the verilog and PCF files causing this problem.

I suspect this is due to this IO being one of the special I³C IOs, although it doesn't seem to happen with pin 25, the other I³C IO pin. However before doing this I'm curious whether other had this issue, or whether it is only with the latest icecube version (unfortunately I can't test this as I don't have anything older, nor can find any download links)

io_00.zip

.

[cliffordwolf]

@daveshah1 I don't think I actually have tried running the icefuzz stuff for 5k myself, so I don't have an answer for you unfortunately. If removing pin 23 fixes the issue then I'd suggest we'll do that for now.

[daveshah1]

OK, done that for now and also made a few other fixes to get icefuzz running completely for the 5k (working in my fork ultraplus_experiments) for now).

[tannewt]

@daveshah1 Glad you were picking it up! I was using iCEcube 2.2017.01 I believe. I have it on my Linux laptop if you want it.

The error in the later version is probably worthwhile fixing like you did already.

[daveshah1]

I've got icefuzz working on the latest ICEcube, which is probably best, although it's useful to know you have an older copy if I need to test anything more.

I'm not sure whether anyone else has tried this yet, but now I have my upduino board I was curious whether we are able to generate bitstreams for the up5k yet - and the answer is yes with caveats.

I have patched arachne to add the up5k device - see my fork here.

When running a simple test project (wiring one output to an input and the other to the inverse of that input), it appears that outputs and logic work correctly, but inputs don't - they appear as stuck low internally.

My guess is that this is due to the new input configuration bits, which are currently being ignored (padeb_test_0/1 and cf_bit_35/39), but I'll investigate this further. Eventually a new IO database may be needed for the 5k as it has some special input features as well (the I³C capable pins and the constant current LED pins which also function as open drain IO).

A rough list of what needs to be done still:

• Fix the above IO issue
• Fix the PLL configuration in icebox - I had to remove the PLL to get arachne to work as its ports are definitely not correct
• Add support for the internal oscillator and special IO types
• Add support for the DSPs
• Add support for the internal 1Mbit SPRAM
• Reverse engineer IPConnect and add support for it (prerequisite for I²C and SPI)
• Add support for I²C and SPI hard IP

[daveshah1]

The not working inputs seem to be down to the IeRens being swapped within a tile, at least for some IOs (e.g. IeRen (18, 31, 1) controls IO (18, 31, 0) and vice versa). Now I just need to work out exactly which other IeRens and IOs are swapped and all inputs will be working. My quick test is working though now, which is good.

It still remains a mystery what those unknown bits do, it seems to work fine without even setting them, but I'm sure there's a reason for them still so I will still change it so they're set. I just need to work out the pattern for setting the cf_bit bits first though.

[paulreimer]

I can happily confirm that the UPDuino boards I just received are able to receive a working bitstream, generated with the latest master branch at this time (I programmed the board with RPi3 GPIO bitbanging for now).

I'm not sure how to help, I just wanted to say how exciting this is -- still can't believe I am just using a short Makefile and compiling on-target, on a $10 dev board.

[daveshah1]

Glad this is working for you! If you want to do more complex stuff I would recommend this branch: ultraplus_experiments, it has some bug fixes compared to master and is capable of building a picoRV32 core.

[paulreimer]

@daveshah1 That sounds good, I will try that ASAP. I'm hoping for internal oscillator support; I do see that in the TODO list above but I will watch your branch to be sure.

I was following that branch before and I recently saw a new ultraplus_extended branch as well that is slightly farther ahead. Would you still suggest following your experiments branch for now, and/or what is the extended branch for?

[daveshah1]

Internal oscillator support will hopefully be added fairly soon, as it's a good simple IP to start with. The ultraplus_extended branch is currently being used for fuzzing these new features, but I'm making modifications that may temporarily break bitstream generation so I wouldn't use it for the time being. It is where I will add new ultraplus specific features though. I'll probably create a pull request once internal oscillator support is working as it seems to be a popularly requested feature.

[daveshah1]

I've made some more progress and there will be another pull request early next week once I've done some more regression testing and made a few other tweaks. The following features are now working:

• DSPs (cascading is not yet supported though)
• SPRAM
• Internal Oscillators
• LED driver pins

The changes are now in my up5k branches of icestorm, arachne-pnr and yosys.

[on1arf]

Hi all,

As of about two weeks, I have a UPduino (small ice40up5k) board).

As I managed to fidn a way to program the serial flash ROM (using micropython on a stm32f4disc), I am now ready to try out "project icestorm" on this board. But when using the main branch of Cliffort to compile the "blinking RGB led" example that came with the board, I got this error: "rgbblink.blif:192: fatal error: unknown formal `CLKHFEN[0]'"

The issue seams to be in the code for the internal oscilator.

Can somebody say what version of the software I now use best? I am a little bit confused by the multiple forks and branches of project icestorm for the 5K

Is all the code of Dave already included into the main version of Cliffort? Or is there some other repo or branch to use?

Also can somebody explain what exactly this error means? I am interested in understanding how the icestorm toolchain actually works.

If I am correct, yosys generated a blif-file, which is then processed by arachne-pnr for place-and-route. So what exactly is the difference between "/usr/local/share/yosys/ice40/cells_sim.v" and "/usr/local/share/arachne-pnr/chipdb-5k.bin" ? Is it like the ".h" include-files and the .so libraries files whn compiling C code? (i.e. "description" vs. actual code?)

Thanks in advance for any advice.

Kristoff

[daveshah1]

What version of yosys, arachne-pnr and icestorm do you have installed?

[on1arf]

Dave,

Thanks for helping out.

I did a "git pull" for yosys, arache-pnr and icestorm using Cliffort's "master" tree: Yosys 0.7+428 (git sha1 9804ebe, clang 3.8.0-2ubuntu4 -fPIC -Os) arachne-pnr 0.1+253+0 (git sha1 24f6b9c, g++ 5.4.0-6ubuntu1~16.04.5 -O2)

Do I need to add things to the makefile or pcf file to use the local oscilator or the LED driver on the UP5K?

This is the makefile: PROJ = rgbblink PIN_DEF = ice40up5k-upduino.pcf DEVICE = 5k PACKAGE = sg48

%.blif: %.v yosys -p 'synth_ice40 -top $(PROJ) -blif $@' $<

%.asc: $(PIN_DEF) %.blif arachne-pnr -d $(subst hx,,$(subst lp,,$(DEVICE))) -o $@ -p $^ -P $(PACKAGE)

Kristoff

[daveshah1]

I presume you are using the Gnarly Grey example? I haven't actually tested it with icestorm until now.

It looks like the problem is the in Verilog of that example, changing this line

    SB_HFOSC  u_SB_HFOSC(.CLKHFPU(1), .CLKHFEN(1), .CLKHF(int_osc));

to

   SB_HFOSC  u_SB_HFOSC(.CLKHFPU(1'b1), .CLKHFEN(1'b1), .CLKHF(int_osc));

makes it compile, although I haven't tested this on hardware yet. If you still have trouble, please see if you can use this example design also for the upduino: https://github.com/cliffordwolf/icestorm/tree/master/examples/up5k_rgb

As far as the Verilog issue above is concerned, I don't have enough knowledge of the standard to know whether or not the unmodified code should work, or whether it's simply a case of Lattice's tools being less strict than the standard. If it's the former then this is a bug that needs to be fixed. cc @cliffordwolf who might know.

[cliffordwolf]

As far as the Verilog issue above is concerned, I don't have enough knowledge of the standard to know whether or not the unmodified code should work, or whether it's simply a case of Lattice's tools being less strict than the standard.

It is complicated. Here is what is happening:

SB_HFOSC is a blackbox module. For blackbox modules the hierarchy command right now does not re-evaluate the Verilog AST for the given set of parameters. Because of that yosys does not know how wide the module ports are for the given set of parameters, thus it does not prune extra bits from the module port. (I know that in this case there are no parameters, but there is no special handling in Yosys for that case.)

Because of this the SB_HFOSC cell ends up with a 32 bit wide signal connected to CLKHFEN, which causes the BLIF back-end to split the port into 32 individual single-bit ports named CLKHFEN[0], CLKHFEN[1], and so forth. But arachne-pnr does not know anything about those ports.

The solution is to re-evaluate the Verilog AST for blackbox instances in hierarchy with the right module parameters, just so we can query the correct port widths. I will implement this now.

[cliffordwolf]

Should be fixed now in Yosys commit 2d140a4.

[on1arf]

Hi all,

I can confirm that the latest commit of the master branch of Clifford works and produces a correct image. I now have blinking LEDs on my upduino based on the Gnarly Grey example-code. :smile:

Also, for who might be interested

Concerning the upduino, it looks to be a nice and very cheap platform for -at least- trying out the up5k flow, but two remarks (compairing it with the olimex hx1k and hx8k boards I have):

• the serial-flash only supports the instruction "0xc7" to bulk-erase the complete flash. (compaired to the serial flash on the olimex that supports both 0xc7 and 0x60). So if you write a programmer for the upduino, make sure you use 0xc7 to erase the flash. (unlike the arduino/SPIFlash-based tool proposed by olimex for their board that uses the instruction 0x60).

• The UPDuino expose the CDONE pin only on a very small pad (instead of a easy-to-access pin) which makes it very impossible to program the configuration-RAM of the FPGA directly (instead of programming the serial-flash and then booting the FPGA from the flash).

  Kristoff

[daveshah1]

In terms of programming the SRAM on the UPDuino boards, the inaccessibility of the CDONE pin is not an issue, it is not really required other than as a debugging aid (but this could effectively be replicated by setting a pin permanently high or low in your design). My standard development approach has been SRAM programming using an FTDI cable - all you need to do compared to flash programming is remove the flash CS jumper and swap MISO and MOSI.

IMO the biggest issue on the UPDuino is the fairly poor PCB design, in particular no VccPLL decoupling at all and quite possibly inadequate supply decoupling. I have had reliability issues running designs that contain both a PLL and a significant amount of logic.

[on1arf]

Dave,

(I do not know if this is the best place to discuss this here, so I'll keep it short).

Concerning CDONE, if you use another pin as indication that the iCE is configured, then you loose a user-pin for that purpose; so I do not really understand what you have gained. The CDONE pin is there, so wjy not use it.

Concerning the PCB design itself, I did say "trying out the up5k flow" not without a reason :grin: I agree I wouldn't really use the board for more then basic functionality tests of the icestorm flow and learning about the chip.

BTW. I forgot to mention this: Thanks to Clifford for his explanation of the background of this issue. I've been trying out the "dump-ast" option in yosys to learn a little bit about the internal working of yosys and arachne-pnr

Kr.

[igor-m]

IMO the biggest issue on the UPDuino is the fairly poor PCB design, in particular no VccPLL decoupling at all and quite possibly inadequate supply decoupling. I have had reliability issues running designs that contain both a PLL and a significant amount of logic.

There is a small fix for the VCCPLL decoupling issue which may help you - see http://www.eevblog.com/forum/microcontrollers/8$-ice40-developer-board/msg1396661/#msg1396661 You may use 10u + 100n as recommended in the appnote (0603 size ceramics). But missing larger gnd plane on the pcb cannot be fixed, sure.

[dbetz]

I'm trying to use the up5k_rgb example on a Upduino board. I am programming the board with the connections described in the Upduino documentation for programming with an AdaFruit FT232H breakout board and am using the command "iceprog -d i:0x403:0x6014 -S rgb.bin" This seems to complete successfully but the RGB LED on the Upduino doesn't flash. Should this work or is there some modification I need to make to the code for the Upduino board?

[daveshah1]

If you followed the UPDuino board instructions directly, you will have connected your FT232H to program flash not SRAM. Either tell the programmer to program flash by removing the "-S" from the iceprog command, or wire your board to program SRAM by removing the CS jumper and swapping MISO and MOSI.

No modifications are needed to run the example. If you still have trouble getting things to work, see whether CDONE (TP2 on the UPDuino) goes high. Also checking whether you can read the flash ID correctly, when wired for flash programming, is a good test of your setup.