macOS

yosys -p "synth_ice40 -blif .pioenvs/icestick/hardware.blif" -q src/counter.v
dyld: Library not loaded: /usr/local/opt/libffi/lib/libffi.6.dylib
Referenced from: /Users/ikravets/.platformio/packages/toolchain-icestorm/bin/yosys
Reason: image not found

Using toolchain-verilog package requires passing some paths to the binaries iverilog and vvp because it is a local installation:

• IVL: /path/to/toolchain-iverilog/lib/ivl
• VLIB: /path/to/toolchain-iverilog/vlib/system.v (yosys lib compatibility)

Use cases:

• Linux/Darwin:
  • iverilog -B IVL VLIB sources
  • vvp -M IVL source
• Windows:
  • iverilog.exe VLIB sources
  • vvp.exe source

There is a standard way to pass these paths to the builder?

Hi,

In this repo are located the cross-compiling scripts for the Icarus Verilog toolchain used by Apio:

https://github.com/FPGAwars/toolchain-iverilog

Please, download the latest release, that contains the packages for:

• Linux_x86_64
• Linux_i686
• Linux_armv7l
• Linux_aarch64
• Windows
• Mac OS

https://github.com/FPGAwars/toolchain-iverilog/releases/tag/v0.3

There are various different methods of 'uploading' a bitstream, they depend on your setup.

For instance, with the mystorm board, which has a hardcore cpu as well, the bitstream is managed by the hardcore, with methods ranging from 'include this in the hardcore binary' to 'just send it out over serial and the hardcore will handle it'. I could also imagine a 'stick this on an SD card' upload or others.

At the moment, there is no way to override the uploader command from an extra_script, so if one really wants to change the behavior, they have to prepend PATH with a directory that contains a fake 'iceprog' script that actually does what they want.

Alternatively, there may be some SCons magic that I'm not familiar with and don't know how to find. (I'm not a SCons user, but I've been looking into it due to platformio.)

I placed a test example named blinky.vhdl inside src folder and get this error upon pressing the checkmark compile button

*** [.pioenvs\icestick\hardware.asc] Source C:\Users\laurent\.platformio\platforms\lattice_ice40\builder\.blif' not found, needed by target .pioenvs\icestick\hardware.asc'.

Hello,
I have problems with this extension in platform IO.

• 'include: error message during compilation: "can not open file" even if the file is in the same directory as the verilog file. (works in IceCube2)
  "-pullup yes" in file the pcf is not recognized (works in IceCube2) : fatal error: unknown option `-pullup'
  Is there a configuration that needs to be modified for it to work?
  Thank you

Please add this widely used FPGA board that is based on Lattice iCE40LP1K-CM36. which is fully supported by the open source toolchain (yosys & nextpnr & icestorm) and has 14 usable IOs fan-out with 3 standard PMOD interfaces. It has on-board debugger iCELink (based on ARM Mbed DAPLink). pls check https://github.com/wuxx/icesugar-nano for more info.

It would be useful to be able to test submodules separately with a testbench each.
Is this possible?
Have I overlooked a reason why only a single *_tb.v file may be present?
Is there some other mechanism in place for this purpose that I overlooked?

Please support more boards like Upduino, wich are supported by apio.

Simply editing the Board-JSON wit another chip don't work due the outdated toolchain...

Hi,

I have created the release/v1.1.0:

• Targets: verify, sim, time
• Improved examples

Tests passed. Can I merge in master?

Hi,

In this repo are located the cross-compiling scripts for the Icestorm toolchain used by Apio:

https://github.com/FPGAwars/toolchain-icestorm

Please, download the latest release, that contains the packages for:

• Linux_x86_64
• Linux_i686
• Linux_armv7l
• Linux_aarch64
• Windows
• Mac OS

https://github.com/FPGAwars/toolchain-icestorm/releases/tag/0.9

[env:icezum] platform = lattice_ice40 board = icestick

Hi, this is more a question than an issue I suppose ...

In the boards definition "boards/icestick.json" it states a value I wasn't able to trace back to the datasheet.

  "upload": {
    "maximum_ram_size": 32768,
    "maximum_size": 32768
  }

On page 2 of the "iCE40TM LP/HX Family Data Sheet" it says for the "HX1K":

RAM4K Memory Blocks: 16
RAM4K RAM bits: 64K

So, shouldn't be the "maximum_ram_size" and "maximum_size" of that size?

FYI I don't own the icestick board but am planning to get the "iCE40HX8K-B-EVN". For that reason I was trying to create a board file.

This is what I have so far:

{
  "build": {
    "core": "iCE40HX8KBreakoutBoard",
    "cpu": "fpga",
    "f_cpu": "12000000L",
    "hwids": [
      [
        "0x0403",
        "0x6010"
      ]
    ],
    "mcu": "iCE40-HX8K-CT256",
    "pack": "ct256",
    "size": "8k",
    "type": "hx"
  },
  "frameworks": [
    "icestorm"
  ],
  "name": "Lattice iCE40-HX8K Breakout Board",
  "upload": {
    "maximum_ram_size": 65536,
    "maximum_size": 65536
  },
  "url": "http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard",
  "vendor": "Lattice"
}

I tried the building process with a simple LED example and all stages are beeing processed:

[Wed Apr 18 13:25:01 2018] Processing ice40 (platform: lattice_ice40; board: iCE40HX8KBreakoutBoard; framework: icestorm)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
yosys -p "synth_ice40 -blif .pioenvs/ice40/hardware.blif" -q src/main.v
Warning: Wire top.counter has an unprocessed 'init' attribute.
arachne-pnr -d 8k -P ct256 -p /Users/ts/Documents/PlatformIO/Projects/Hello_FPGA/src/main.pcf -o .pioenvs/ice
40/hardware.asc .pioenvs/ice40/hardware.blif
seed: 1
device: 8k
read_chipdb +/share/arachne-pnr/chipdb-8k.bin...
supported packages: cb132, cb132:4k, cm121, cm121:4k, cm225, cm225:4k, cm81, cm81:4k, ct256, tq144:4k
read_blif .pioenvs/ice40/hardware.blif...
prune...
read_pcf /Users/ts/Documents/PlatformIO/Projects/Hello_FPGA/src/main.pcf...
instantiate_io...
pack...

After packing:
IOs          9 / 206
GBs          0 / 8
GB_IOs     0 / 8
LCs          28 / 7680
DFF        3
CARRY      2
CARRY, DFF 23
DFF PASS   0
CARRY PASS 1
BRAMs        0 / 32
WARMBOOTs    0 / 1
PLLs         0 / 2

place_constraints...
promote_globals...
promoted hwclk$2, 26 / 26
promoted 1 nets
1 clk
1 globals
1 clk
realize_constants...
realized 1
place...
initial wire length = 496
at iteration #50: temp = 21.5721, wire length = 116
at iteration #100: temp = 9.44191, wire length = 110
at iteration #150: temp = 2.0266, wire length = 78
at iteration #200: temp = 0.00158118, wire length = 51
final wire length = 51

After placement:
PIOs       9 / 206
PLBs       6 / 960
BRAMs      0 / 32
 
place time 0.04s
route...
pass 1, 0 shared.
 
After routing:
span_4     19 / 29696
span_12    2 / 5632
 
route time 0.09s
write_txt .pioenvs/ice40/hardware.asc...
icepack .pioenvs/ice40/hardware.asc .pioenvs/ice40/hardware.bin
========================= [SUCCESS] Took 14.95 seconds =========================

I am using a source with an always_comb block which only builds when I change it to always @* and rename the file from foo.sv to foo.v.
Looking through the builder, it looks like only .v extensions are recognixed, rather than .sv which would enable systemverilog files.
A solution to build systemverilog files is to recognize .sv as a source suffix, or find some other way to pass -sv to yosys.