yosyshq / icestorm Goto Github PK

View Code? Open in Web Editor NEW

963.0 963.0 224.0 2.46 MB

Project IceStorm - Lattice iCE40 FPGAs Bitstream Documentation (Reverse Engineered)

License: ISC License

Makefile 1.29% Python 79.41% Shell 4.02% Verilog 3.92% C++ 8.99% C 2.36% Tcl 0.01%

icestorm's People

Contributors

Stargazers

Watchers

Forkers

cyrozap 8l zeldin qbit anttilukats saturnu jesus89 aventuri zuloloxi jhol 104player ylm mfkiwl antmicro esden juan-micuss pedrolopes tuyenth sebastianboe kraiskil plaes obijuan sebkuzminsky hungrymonkey leviathanch benpye 32bitmicro lowfatcomputing dvc94ch ujfuentes aakarsh jamesbowman smoe wanming2008 adamhorden set-soft tyll babooppa6 udif thoughtpolice rgwan sebylim joshhead cbiffle juanmard rlutz adafruit tannewt c-elegans arcanenibble jeandet zavs sfrias martinda marcusmueller rowhit yao-zl cz172638 euripedesrocha kubatyszko daveshah1 mithro edmundhumenberger cr1901 kelu124 mrek mcmasterg jimparis awygle bert elms jkrautter osresearch zhangjialiang-tt litghost f4pga sam-willis rjlv2 nathanrossi sandeepmistry gsteiert matthuszagh jburgess777 greydoubt christianphan terrillmoore anuejn cbmeeks gwsu delvers john-k keesj calplug profeblanco tweakoz corecode mohism-research gojimmypi luowy indigos33k3r

icestorm's Issues

Ultra / UltraPlus support

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

Problem compiling

Hi
When running make -j$(nproc)

I get:

make -C icebox
make[1]: Entering directory '/home/habiloid/icestorm/icebox'
python icebox_chipdb.py > chipdb-1k.new
python icebox_chipdb.py -8 > chipdb-8k.new
Traceback (most recent call last):
File "icebox_chipdb.py", line 250, in
print_tile_nonrouting_bits("logic", ic.logic_tiles.keys()[0])
TypeError: 'dict_keys' object does not support indexing
Makefile:6: recipe for target 'chipdb-1k.txt' failed
make[1]: *** [chipdb-1k.txt] Error 1
make[1]: *** Waiting for unfinished jobs....
Traceback (most recent call last):
File "icebox_chipdb.py", line 250, in
print_tile_nonrouting_bits("logic", ic.logic_tiles.keys()[0])
TypeError: 'dict_keys' object does not support indexing
Makefile:10: recipe for target 'chipdb-8k.txt' failed
make[1]: *** [chipdb-8k.txt] Error 1
make[1]: Leaving directory '/home/brett/BUILDS/COMPILATIONS/icestorm/icebox'
Makefile:3: recipe for target 'all' failed
make: *** [all] Error 2

Any help would be appreciated

iceblink example `make clean` question

Is there a special reason not to remove $(PROJ).rpt in icestorm/examples/iceblink?

icestorm/examples$ grep -A1 -B0 clean: */Makefile
hx8kboard/Makefile:clean:
hx8kboard/Makefile-     rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
--
iceblink/Makefile:clean:
iceblink/Makefile-      rm -f $(PROJ).blif $(PROJ).asc $(PROJ).bin
--
icestick/Makefile:clean:
icestick/Makefile-      rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin
--
icezum/Makefile:clean:
icezum/Makefile-        rm -f $(PROJ).blif $(PROJ).asc $(PROJ).rpt $(PROJ).bin

Chip DB for the iCE40-HX1K should report that there is no PLL in the VQ100 package.

The following design should not be place-able on the iCE40-HX1K VQ100
pll.tar.gz

http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/IK/iCE40sysCLOCKPLLDesignandUsageGuide.pdf?document_id=47778

please make icecompr/icecompr.py executable

Inconsistency between icePLL and iCEcube2

When icepll is used to generate a PLL for an input frequency of 12MHz and an output of 25MHz, it gives this output:

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:   25.000 MHz (requested)
F_PLLOUT:   24.000 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  768.000 MHz

DIVR:  0 (4'b0000)
DIVF: 63 (7'b0111111)
DIVQ:  5 (3'b101)

FILTER_RANGE: 1 (3'b001)

However, when iCEcube2 is given the same parameters, it generates a PLL with these parameters:

DivR: 0000 (0)
DivF: 1000010 (66)
DivQ: 101 (5)
Output frequency: 25.13MHz

It seems that iCEcube2 sets DIVF outside its documented range of [0,63], and gives a PLL configuration that more closely matches the frequency requested. Could the DIVF range given in the datasheet simply be a mistake?

I can't verify this at the moment as I don't have an oscilloscope.

UP5k - icestorm/icetime - size and timing estimates

When running this https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version with icestorm (the latest) and IceCube2 I get two quite different results:

IceCube2
size 383 PLBs, timing estimate 31.5MHz, works fine at 20/30MHz external osc.
icestorm
size 541-557 PLBs, timing estimate 32-40MHz, does not run reliably at 20MHz ext. osc.
PS: building the "icestorm version" with IceCube2 for this test, with identical HW, programmer, serial terminal..

UP5k Arachne dump

While building this (yesterday's pull and reinstall of the icestorm/arachne/yosys)
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version
I get an arachne-pnr dump

  After placement:
PIOs       21 / 39
PLBs       541 / 660
BRAMs      30 / 30

  place time 22.68s
route...
36 -> 77837 75389 76613 26219 77633 75593 28667 28463 78041 76205 77021 27647 77225 75797 28871 28055 78241 76409 76817 27851 77429 76001 29071 28259 26423 26627 26831 27035 27239 27443 78429
arachne-pnr: src/route.cc:793: void Router::route(): Assertion `unrouted.empty()' failed.
Aborted (core dumped)

Not sure it comes from the design itself or from the experimental UP5k..

err.h is not available on mingw

The commit dbdc65b seems to be an attempt to improve some error reporting. However, it uses functions from err.h which "are nonstandard BSD extensions" according to this man page. This breaks the build for Windows/MinGW-w64.

.pcf parser doesn't accept some comments

This is fine:

# D9
set_io led[0]     B5

This breaks (but is accepted by arachne-pnr):

set_io led[0]     B5 # D9

High-level configuration tool license

@rlutz:

At the risk of inciting a huge flamewar, I would like to request that the newly-added high-level configuration tool be licensed under a non-copyleft license rather than the copyleft GPLv3+. The rest of the IceStorm project is under the ISC license.

Block ram reads within ~36 cycles of device reset always return 0, but only on the first reset after device reconfiguration.

This repros on an ICE40-HX8K breakout board using Icestorm tools built from head as of a week or so ago. The board is in "sram" mode, and I'm flashing it using "iceprog -S ..."

To repro -

Flash the board with some placeholder config, I use this one -

module placeholder(input clk_in, output reg [7:0] out_debug, output reg out_trap);
assign out_debug = 8'b10101010;
endmodule

Flash the board with this config, which reads from a blockram shortly after device reset and displays the result of the read on the board's LEDs -

module blockram_bug(input clk, output reg [7:0] out_debug);

reg [31:0] memory[0:127];
initial begin
  memory[0] = 32'hFFFFFFFF;
  memory[1] = 32'hFFFFFFFF;
  memory[2] = 32'hFFFFFFFF;
  memory[3] = 32'hFFFFFFFF;
  memory[4] = 32'hFFFFFFFF;
  memory[5] = 32'hFFFFFFFF;
  memory[6] = 32'hFFFFFFFF;
  memory[7] = 32'hFFFFFFFF;
end

reg [25:0] count = 0;
reg [31:0] mem_raddr = 32'hFFFFFFFF;

always @(posedge clk) begin
  if (count == 0) begin
    mem_raddr <= 7;
    out_debug <= 32'hFFFFFFFF;
  end

  if (count == 36) begin
    out_debug <= memory[mem_raddr];
  end

  count <= count + 1;
end

endmodule

If the bug does not repro, the LEDs will light up immediately. If the bug does repro, the LEDs should be off for ~5 seconds until the counter rolls over, then they should light up. Changing the "if (count == 36)" to 37 or higher will cause the bug to not repro.

Flash the board a second time with the same .bin from step 2. The bug should not repro (LEDs light up immediately).
Flash the board with the placeholder again, then flash with blockram_bug. The bug should repro again.

icebox_vlog can't parse --warn-no-port attributes

This would be handy; as a workaround I'm just supplying a stripped .pcf to icebox_vlog vs arachne-pnr.

OSX problems

There is no python2 installed on OSX. I created a link on my own machine, but that's not possible for people without admin rights (e.g. running on travis-ci).

Build on Cygwin fails due to missing vasprintf

Hi,

At least on Cygwin vasprintf declarations in stdio.h are protected by _GNU_SOURCE so this needs to be added in appropriate places. Attached patch adds the definition it in relevant source files, similar to what's already done for iceprog.cc.

0001-Explicitly-ask-for-vasprintf-where-appropriate.patch.txt

icepll can produce out-of-range DIVF values

I just tried running icepll like this:

icepll -i 12 -o 200

to get a 200MHz (ish) output from a 12MHz xtal on the icestick

and got the following output:

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:  200.000 MHz (requested)
F_PLLOUT:  201.000 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  804.000 MHz

DIVR:  0 (4'b0000)
DIVF: 66 (7'b1000010)
DIVQ:  2 (3'b010)

FILTER_RANGE: 1 (3'b001)

The value of 66 for DIVF is out of range (data sheets say 0..63) - I tried it on the Icestick (to check I am not going mad) and indeed it produces the equivalent of it wrapping around to 2, as expected.

I think the issue is at line 101 in the code:

for (int divf = 0; divf <= 127; divf++)

Which should probably be:

for (int divf = 0; divf <= 63; divf++)

Unless, of course, I am misunderstanding something (I am new to lattice ICE parts and icestorm).

PS: Thanks for all your work on this. It's a completely awesome project and a fantastic achievement. I am really enjoying working with open source tools on an FPGA. Is there any way to help with / donate to the project?

James.

[glibc 2.26] Can't compile icestorm because of missing xlocale header.

Hi,

Recently i updated my OS from Ubuntu 16.04 to 17.10 and tried to compile icestorm (I'm on the current master HEAD (722790a)).

When i try to compile icestorm i got:

icestorm $ make
for dir in icebox icepack iceprog icemulti icepll icetime icebram; do \
	make -C $dir all || exit; \
done
make[1]: Entering directory '/home/d3bug/icestorm/icebox'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/d3bug/icestorm/icebox'
make[1]: Entering directory '/home/d3bug/icestorm/icepack'
make[1]: *** No rule to make target '/usr/include/xlocale.h', needed by 'icepack.o'.  Stop.
make[1]: Leaving directory '/home/d3bug/icestorm/icepack'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2

So searching a bit i found this release notes for glibc 2.26.

The nonstandard header xlocale.h has been removed in this release.

To know the version of glibc on my box i used:

$ ldd --version      
ldd (Ubuntu GLIBC 2.26-0ubuntu2.1) 2.26
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

So that why i can't compile icestorm nor arachne (i got the same error output). I tried searching xlocale on the icepack source but i couldn't find it (i haven't searched deeply tho).

I know this is not directly a icestorm problem but i wanted to ask for suggestions to solve it, i have found this workaround tho.

Can this be solved directly on icestorm/arachne or should i find a way to downgrade glibc?

Regards.

Pre-requisites for Fedora 24

Hi Clifford,
For Fedora 24, the following pre-requisites line should be suitable:

sudo dnf install make automake gcc gcc-c++ kernel-devel clang bison \
         flex readline-devel gawk tcl-devel libffi-devel git mercurial \
         graphviz python-xdot pkgconfig python python3 libftdi-devel

iCEFuzz: documentation & usage

icetime runs make_lc40 on IO tile

Hi. I found a strange thing running icetime.

If a logic tile with Y=1 has C_ON set for LC_0 (which my design has for some reason, don't know if this is normal), icetime will call make_lc40() with Y=0. But Y=0 is not a logic tile, it's an IO tile. So trying to interpret the config bits as a logic tile will probably produce garbage. Under some circumstances it even proceeds to Y=-1 and crashes.

As I said, no idea if C_ON for a logic cell in this position is normal, but the design was generated with yosys 0.6 and latest arachne-pnr, and does not contain any hand-rolled logic cells...

Chipdb path issue on Arch Linux

Hi, first off, I want to congratulate your release of Icetime.

Minor issue;
On Arch Linux, and other systems that don't use /usr/local,
this is broken

https://github.com/cliffordwolf/icestorm/blob/master/icetime/icetime.cc#L268

ParseError in high-level configuration tool

cc @rlutz

I just tried running icebox_asc2hlc.py and icebox_hlc2asc.py on a "real" design, and icebox_hlc2asc.py fails to round-trip the design. It instead raises a ParseError:

Traceback (most recent call last):
  File "./icebox/icebox_hlc2asc.py", line 1052, in <module>
    main()
  File "./icebox/icebox_hlc2asc.py", line 1049, in main
    main1(args[0])
  File "./icebox/icebox_hlc2asc.py", line 985, in main1
    stack[-1].read(fields)
  File "./icebox/icebox_hlc2asc.py", line 882, in read
    super().read(fields)
  File "./icebox/icebox_hlc2asc.py", line 754, in read
    raise ParseError
__main__.ParseError

The high-level bitstream file is here. Let me know if you would like me to try to minimize it.

icetime - 1000020.4ns with UP5k

Does the 10000XX.XX indicate a design issue here (yesterday's icestorm/arachne/yosys pull from github and reinstall), chip ice40UP5k?
Sources: https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version

icetime topological timing analysis report
==========================================

Report for critical path:
-------------------------

        loop-start at net_34778
        t7262 (LocalMux) I -> O: 0.330 ns
        inmux_9_15_38650_38720 (InMux) I -> O: 0.260 ns
        t1267 (CascadeMux) I -> O: 0.000 ns
        lc40_9_15_7 (LogicCell40) in2 -> lcout: 0.379 ns
1000000.968 ns net_34778 (_j1.insn_from_memory[13])
        odrv_9_15_34778_38506 (Odrv4) I -> O: 0.372 ns
        t7288 (LocalMux) I -> O: 0.330 ns
        inmux_10_14_42377_42392 (InMux) I -> O: 0.260 ns
        t1388 (CascadeMux) I -> O: 0.000 ns
        lc40_10_14_1 (LogicCell40) in2 -> lcout: 0.379 ns
1000002.307 ns net_38480 ($abc$26981$n3234_1)
        odrv_10_14_38480_42090 (Odrv4) I -> O: 0.372 ns
        t8348 (Span4Mux_h4) I -> O: 0.316 ns
        t8347 (Span4Mux_h4) I -> O: 0.316 ns
        t8346 (Span4Mux_h1) I -> O: 0.175 ns
        t8345 (LocalMux) I -> O: 0.330 ns
        inmux_20_14_80032_80082 (InMux) I -> O: 0.260 ns
        lc40_20_14_3 (LogicCell40) in3 -> lcout: 0.316 ns
1000004.390 ns net_76486 ($abc$26981$n3939_1)
        odrv_20_14_76486_53935 (Odrv12) I -> O: 0.540 ns
        t15878 (Span12Mux_h2) I -> O: 0.168 ns
        t15877 (LocalMux) I -> O: 0.330 ns
        inmux_11_14_46195_46251 (InMux) I -> O: 0.260 ns
        lc40_11_14_6 (LogicCell40) in0 -> lcout: 0.449 ns
1000006.137 ns net_42316 ($abc$26981$n3938_1)
        t8921 (LocalMux) I -> O: 0.330 ns
        inmux_11_13_46065_46106 (InMux) I -> O: 0.260 ns
        t1542 (CascadeMux) I -> O: 0.000 ns
        lc40_11_13_2 (LogicCell40) in2 -> lcout: 0.379 ns
1000007.105 ns net_42189 ($abc$26981$n3937_1)
        odrv_11_13_42189_45906 (Odrv12) I -> O: 0.540 ns
        t8884 (Span12Mux_h4) I -> O: 0.217 ns
        t8883 (Sp12to4) I -> O: 0.449 ns
        t8882 (Span4Mux_v0) I -> O: 0.203 ns
        t8881 (Span4Mux_h0) I -> O: 0.147 ns
        t8880 (Span4Mux_v1) I -> O: 0.203 ns
        t8879 (LocalMux) I -> O: 0.330 ns
        inmux_9_12_38294_38319 (InMux) I -> O: 0.260 ns
        lc40_9_12_2 (LogicCell40) in0 -> lcout: 0.449 ns
1000009.903 ns net_34404 (_j1.pcN[1])
        odrv_9_12_34404_34311 (Odrv4) I -> O: 0.372 ns
        t7065 (Span4Mux_v4) I -> O: 0.372 ns
        t7064 (Span4Mux_h4) I -> O: 0.316 ns
        t7063 (Span4Mux_v4) I -> O: 0.372 ns
        t7082 (Span4Mux_h4) I -> O: 0.316 ns
        t7081 (Span4Mux_h4) I -> O: 0.316 ns
        t7080 (Span4Mux_h4) I -> O: 0.316 ns
        t7108 (Span4Mux_h0) I -> O: 0.147 ns
        t7107 (Span4Mux_v4) I -> O: 0.372 ns
        t7106 (Span4Mux_h0) I -> O: 0.147 ns
        t7105 (Span4Mux_v4) I -> O: 0.372 ns
        t7104 (Span4Mux_h0) I -> O: 0.147 ns
        t7103 (Span4Mux_v4) I -> O: 0.372 ns
        t7102 (Span4Mux_h4) I -> O: 0.316 ns
        t7101 (Span4Mux_v4) I -> O: 0.372 ns
        t7100 (Span4Mux_v4) I -> O: 0.372 ns
        t7099 (Span4Mux_v4) I -> O: 0.372 ns
        t7098 (Span4Mux_h4) I -> O: 0.316 ns
        t7097 (Span4Mux_v4) I -> O: 0.372 ns
        t7096 (Span4Mux_v2) I -> O: 0.252 ns
        t7095 (IoSpan4Mux) I -> O: 0.323 ns
        t7094 (Span4Mux_h0) I -> O: 0.147 ns
        t7093 (Span4Mux_v4) I -> O: 0.372 ns
        t7092 (Span4Mux_v4) I -> O: 0.372 ns
        t7091 (Span4Mux_v4) I -> O: 0.372 ns
        t7090 (Span4Mux_h0) I -> O: 0.147 ns
        t7089 (Span4Mux_v4) I -> O: 0.372 ns
        t7088 (Span4Mux_h0) I -> O: 0.147 ns
        t7087 (Span4Mux_v4) I -> O: 0.372 ns
        t7086 (Span4Mux_h0) I -> O: 0.147 ns
        t7085 (Span4Mux_v4) I -> O: 0.372 ns
        t7084 (Span4Mux_h2) I -> O: 0.203 ns
        t7083 (LocalMux) I -> O: 0.330 ns
        inmux_19_3_75447_75480 (InMux) I -> O: 0.260 ns
        t2677 (CascadeMux) I -> O: 0.000 ns
1000020.143 ns net_75480_cascademuxed
        ram_19_3 (SB_RAM40_4K) RADDR[1] [setup]: 0.290 ns
1000020.433 ns dangling_wire_513

Resolvable net names on path:
1000000.968 ns ..1000001.929 ns _j1.insn_from_memory[13]
1000002.307 ns ..1000004.075 ns $abc$26981$n3234_1
1000004.390 ns ..1000005.688 ns $abc$26981$n3939_1
1000006.137 ns ..1000006.726 ns $abc$26981$n3938_1
1000007.105 ns ..1000009.454 ns $abc$26981$n3937_1
1000009.903 ns ..1000020.143 ns _j1.pcN[1]
              RDATA[11] -> _bn20.rd[11]
               RDATA[3] -> _bn20.rd[3]

Total number of logic levels: 7
Total path delay: 1000020.43 ns (0.00 MHz)

icebox_vlog

I'm getting the following error:

Traceback (most recent call last):
  File "/usr/local/bin/icebox_vlog", line 344, in <module>
    for s in sorted(net_segs):
TypeError: unorderable types: str() < tuple()

The offending input is here: https://gist.github.com/cseed/7c648bd527f00fd40be1. Just run icebox_vlog carry_route_fail1.txt.

iceprog requires additional compiler flags

On Fedora 23, iceprog cannot be built because it requires additional linker and compiler flags for libftdi. I tried to fix this, but it seems like different GNU/Linux distributions have different library names for pkg-config. I'm not quite sure how to process this in makefile.

Fedora 23:

[user@fedora]$ pkg-config --libs --cflags libftdi1
-I/usr/include/libftdi1 -I/usr/include/libusb-1.0 -lftdi1 -lusb-1.0

Ubuntu 12.04:

user@ubuntu:~$ pkg-config --libs --cflags libftdi
 -lftdi

As a side note, maybe it would be more convenient to have a more flexible build system, like cmake, autotools or premake? With premake, for example, it would be easier to provide configurations for variety of compilers for different platforms. Here is a quick example for icestorm.

Has LVDS out been tested?

Clifford,

Has LVDS out been tested**?
code sample: lvds.txt

simple LVDS code builds with no errors reported:

using iCEcube2 runs as expected
Total number of logic levels: 12
Total path delay: 14.37 ns (69.58 MHz)

on iCEstorm does not run as expected
Total number of logic levels: 22
Total path delay: 23.95 ns (41.76 MHz)

**I only found reference to LVDS in:
http://www.clifford.at/icestorm/io_tile.html

Communication via USB to iCEstick - how?

I find it to be beyond my immediate capabilities to figure out how to communicate with the HX1K via USB. I can follow the instructions on https://wiki.debian.org/FPGA/Lattice, can modify that code, all fine. I have a USB-TTL converter and could imagine to use that to communicate with the device via some extra cables, basically along the examples for the IrDA. But if somehow possible I would want to use the USB port that the device is using already.

Does anybody reading this have any respective code (host and fpga) available? Maybe something along the "echo" example at ztex (http://www.ztex.de/firmware-kit/example.e.html)?

Many thanks

Steffen

`.comment' format mismatch

The syntax of the .comment statement expected by IceStorm does not appear to match the syntax output by arachne-pnr.

icepack expects comments to be in the following syntax:

.comment
First line
Second line

Everything following .comment on the first line is ignored. Each subsequent line is treated as a comment until the comment block is terminated by a line starting with .. This line is treated normally; it is not ignored. If multiple comment blocks are specified, all except the last one are ignored.

icepack includes the comments in the following form at the beginning of the .bin output:

ff 00 <First line> 00 <Second line> 00 00 ff

However, arachne-pnr outputs a comment of the following form:

.comment arachne-pnr <version> (git sha1 <commit>, <compiler version and options>)

This is understood by icepack as an empty comment block, so it adds the pattern

ff 00 00 ff

at the beginning of every .bin file generated from arachne-pnr output.

I stumbled across this when I realized that icepack actually interprets .comment statement. I'm not sure what the correct behavior is supposed to be, but I guess it's one of the following:

.comment blocks are intended as a mechanism to include arbitrary strings in a .bin file, but arachne-pnr got the format wrong, so instead of the version string, an empty comment block is included in the output
.comment blocks are intended as a mechanism to include arbitrary strings in a .bin file, but arachne-pnr mistook the syntax for a “real” comment and inadvertently inserts an empty comment block in every file
.comment statements are intended as a way to be able to add comments to an .asc file; icepack is not supposed to include their content in the output

Upduino ICE40UP5k ICEPROG doesnt work.

I tried with rgb example here ...
https://github.com/cliffordwolf/icestorm/tree/master/examples/up5k_rgb

I used the same connections as a working setup with Lattice Diamond programmer, FTDI2232H (channel A).

I get no errors on "sudo make prog" after successful "make", but fpga don't get programmed.
I can see ft2232 pins "talk" to fpga board when i type "sudo make prog" with a logic analyzer but I have no experience with SPI or jtag to go further.

Someone has a working setup with RGB example trough "Makefile" and "make prog" con FTDI2232?
THanks

libftdi1-dev required on debian stretch

When following the build instructions (copy+pasted the apt-get), it seems libftdi1-dev is missing:

make[1]: Entering directory '/space/home_laforge/projects/git/icestorm/iceprog'
cc -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -I/usr/local/include   -c -o iceprog.o iceprog.c
iceprog.c: In function ‘main’:
iceprog.c:387:13: error: ‘INTERFACE_C’ undeclared (first use in this function); did you mean ‘INTERFACE_B’?
     ifnum = INTERFACE_C;
             ^~~~~~~~~~~
             INTERFACE_B
iceprog.c:387:13: note: each undeclared identifier is reported only once for each function it appears in
iceprog.c:389:13: error: ‘INTERFACE_D’ undeclared (first use in this function); did you mean ‘INTERFACE_C’?
     ifnum = INTERFACE_D;
             ^~~~~~~~~~~
             INTERFACE_C
iceprog.c:589:7: warning: implicit declaration of function ‘ftdi_usb_open_string’; did you mean ‘ftdi_usb_get_strings’? [-Wimplicit-function-declaration]
   if (ftdi_usb_open_string(&ftdic, devstr)) {
       ^~~~~~~~~~~~~~~~~~~~
       ftdi_usb_get_strings
<builtin>: recipe for target 'iceprog.o' failed
make[1]: *** [iceprog.o] Error 1
make[1]: Leaving directory '/space/home_laforge/projects/git/icestorm/iceprog'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2

After installing the relted package, the build went through successful.

iceprog sram programming does not work with icestick

I got a new Icestick to start experimenting with verilog. The normal programming works fine, but programming it with
iceprog -S file.bin
does not work. The leds on the stick then go into the half-on state and nothing else happens. Also it prints cdone: low at the end.
Attached is a wireshark usb capture, if that helps.
program_iceprog_sram.zip

Breaking icestick with icestorm ?

On the icestorm official web page :
http://www.clifford.at/icestorm/

It's written that we can break our icestick with this project. Have you ever break an icestick or it's just a warning ?

Thanks

icebram: Parser not fully compatble with that of $readmemh

For icebram to work as a drop-in replacement for incuding the hexfiles directly with $readmemh, it should accept the same hexfile syntax. The differences I have found:

icebram requires one word per line. $readmemh accepts multiple words per line
icebram does not accept horizontal whitespace in the file. $readmemh accepts horizontal whitespace in the file
icebram requires the file to be padded to the size of the BRAM. $readmemh accepts any size <= the size of the BRAM.

icetime using icebox PREFIX on runtime

I think it would be useful to allow loading icebox data path during runtime. The binary would be a more flexible binary.

icepll -m output has trailing comma in port list

When icepll saves PLL configuration as a module, it includes a comma after the last port in the port list.

Yosys synthesizes it with no problems, but Icarus Verilog considers the extra comma a syntax error.

Would it be better to remove the comma after .PLLOUTCORE(clock_out)?

$ icepll -m -f pll.v

F_PLLIN:    12.000 MHz (given)
F_PLLOUT:   60.000 MHz (requested)
F_PLLOUT:   67.500 MHz (achieved)

FEEDBACK: SIMPLE
F_PFD:   12.000 MHz
F_VCO:  540.000 MHz

DIVR:  0 (4'b0000)
DIVF: 44 (7'b0101100)
DIVQ:  3 (3'b011)

FILTER_RANGE: 1 (3'b001)

PLL configuration written to: pll.v

pll.v

/**
 * PLL configuration
 *
 * This Verilog module was generated automatically
 * using the icepll tool from the IceStorm project.
 * Use at your own risk.
 *
 * Given input frequency:        12.000 MHz
 * Requested output frequency:   60.000 MHz
 * Achieved output frequency:    67.500 MHz
 */

module pll(
	input  clock_in,
	output clock_out,
	output locked
	);

SB_PLL40_CORE #(
		.FEEDBACK_PATH("SIMPLE"),
		.DIVR(4'b0000),		// DIVR =  0
		.DIVF(7'b0101100),	// DIVF = 44
		.DIVQ(3'b011),		// DIVQ =  3
		.FILTER_RANGE(3'b001)	// FILTER_RANGE = 1
	) uut (
		.LOCK(locked),
		.RESETB(1'b1),
		.BYPASS(1'b0),
		.REFERENCECLK(clock_in),
		.PLLOUTCORE(clock_out),
		);

endmodule

$ iverilog -t null pll.v /usr/local/share/yosys/ice40/cells_sim.v
pll.v:31: syntax error
pll.v:25: error: Syntax error in instance port expression(s).

recipe for target 'iceprog.o' --failed-- warnings

...
make -C iceprog
make[1]: Entering directory '/home/drom/work/github/cliffordwolf/icestorm/iceprog'
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include    -c -o iceprog.o iceprog.c
iceprog.c:27:10: fatal error: 'ftdi.h' file not found
#include <ftdi.h>
         ^
1 error generated.
<builtin>: recipe for target 'iceprog.o' failed
make[1]: *** [iceprog.o] Error 1
make[1]: Leaving directory '/home/drom/work/github/cliffordwolf/icestorm/iceprog'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

Use chipdb*.bin files

Hi, Is there a plan to unify the chipdb binary files between Icestorm and Arachne-pnr?

Now there is a share/icebox directory with the chipdbs*.txt (about ~44Mb) and other share/arachne-pnr directory with the same information chipdb*.bin (about ~12Mb) for the same toolchain.

Do you plan to generate those chipdb*.bin from the icebox tools and read those chipdb*.bin files in the icetime tool?

Thanks!

Strange behaviour with unused wire/reg

Below Verilog does not work (only 2 leds come on), but is fixed when I uncomment the unused wire 'idle' in module debounce. I may be missing something obvious of course...

module button(input clk, input [1:0] buttons, output [3:0] led);
	assign led = leds;

	reg [3:0] leds = 4'b0;
	wire on;
	wire off;
	wire pressed;

	debounce dbon(.clk(clk),.button(buttons[0]),.state(on));
	debounce dboff(.clk(clk),.button(buttons[1]),.state(off));

	assign pressed = on | off;

	always @(posedge pressed) 
		leds <= (on) ? 4'b1111 :
					(off) ? 4'b0000 : leds;

endmodule

module debounce(input clk, input button, output reg state);
	//wire idle;
	reg sync;
	reg [15:0] count;

	always @(posedge clk) begin
		sync <= ~button;
		count <= (state == sync) ? 0 : count + 16'b1;
		if(&count) 
			state <= ~state;
	end
endmodule

IceStorm vers:
Yosys 0.5+460 (git sha1 45af4a4, clang 3.4-1ubuntu3 -fPIC -Os)
arachne-pnr 0.1+136+0 (git sha1 1a4fdf9, g++ 4.8.4-2ubuntu1~14.04.1 -O2)

JSON report format

Very good feature 👍
But about File format. There are couple of issues to make it JSON

all object keys has to be double quoted.
no dangling commas

Now:

[
    { out_net: "net_8353", cell: "lc40_3_2_4", cell_type: "LogicCell40", cell_in_port: "[clk]", cell_out_port: "lcout", delay_ns: 0.640, },
    { out_net: "net_252", cell: "odrv_3_2_8353_252", cell_type: "Odrv4", cell_in_port: "I", cell_out_port: "O", delay_ns: 1.012, },
]

Should be:

[
    { "out_net": "net_8353", "cell": "lc40_3_2_4", "cell_type": "LogicCell40", "cell_in_port": "[clk]", "cell_out_port": "lcout", "delay_ns": 0.640 },
    { "out_net": "net_252", "cell": "odrv_3_2_8353_252", "cell_type": "Odrv4", "cell_in_port": "I", "cell_out_port": "O", "delay_ns": 1.012 }
]

Errors during compilation

Hi Clifford,

I just pulled revision af36a8a and I got compiler errors that are possibly related to gcc version 6.1:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC)

I'm using Arch Linux and I have the latest packages for everything. The output I get:

make -C icebox
make[1]: Entering directory '/home/aaa/Software/icestorm/icebox'
python3 icebox_chipdb.py > chipdb-1k.new
mv chipdb-1k.new chipdb-1k.txt
python3 icebox_chipdb.py -8 > chipdb-8k.new
mv chipdb-8k.new chipdb-8k.txt
make[1]: Leaving directory '/home/aaa/Software/icestorm/icebox'
make -C icepack
make[1]: Entering directory '/home/aaa/Software/icestorm/icepack'
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include   -c -o icepack.o icepack.cc
clang -o icepack  icepack.o -lm -lstdc++
ln -sf icepack iceunpack
make[1]: Leaving directory '/home/aaa/Software/icestorm/icepack'
make -C iceprog
make[1]: Entering directory '/home/aaa/Software/icestorm/iceprog'
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include    -c -o iceprog.o iceprog.c
clang -o iceprog  iceprog.o -L/usr/local/lib -lm -lftdi -lusb
make[1]: Leaving directory '/home/aaa/Software/icestorm/iceprog'
make -C icemulti
make[1]: Entering directory '/home/aaa/Software/icestorm/icemulti'
clang -MD -O0 -ggdb -Wall -std=c++11   -c -o icemulti.o icemulti.cc
clang -o icemulti  icemulti.o -lm -lstdc++
make[1]: Leaving directory '/home/aaa/Software/icestorm/icemulti'
make -C icepll
make[1]: Entering directory '/home/aaa/Software/icestorm/icepll'
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include   -c -o icepll.o icepll.cc
clang -o icepll  icepll.o -lm -lstdc++
make[1]: Leaving directory '/home/aaa/Software/icestorm/icepll'
make -C icetime
make[1]: Entering directory '/home/aaa/Software/icestorm/icetime'
python3 timings.py > timings.inc.new
mv timings.inc.new timings.inc
clang -MD -O0 -ggdb -Wall -std=c++11 -I/usr/local/include -DPREFIX='"/usr/local"'   -c -o icetime.o icetime.cc
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:471:67: error: 
      pack expansion contains parameter packs '_Elements' and '_UElements' that
      have different lengths (1 vs. 3)
      return __and_<is_constructible<_Elements, const _UElements&>...>::value;
                                     ~~~~~~~~~        ~~~~~~~~~~  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:645:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, int> &>::_ConstructibleTuple<int, int, int>'
      requested here
                    _ConstructibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, int>, _Dummy = void]
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
      (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:339:11: note: in instantiation of member function
      'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
      std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
      std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
      >::operator[]' requested here
                        pin_pos[key] = tok;
                               ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:477:65: error: 
      pack expansion contains parameter packs '_UElements' and '_Elements' that
      have different lengths (3 vs. 1)
      return __and_<is_convertible<const _UElements&, _Elements>...>::value;
                                         ~~~~~~~~~~   ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:647:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, int> &>::_ImplicitlyConvertibleTuple<int, int, int>'
      requested here
                    _ImplicitlyConvertibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, int>, _Dummy = void]
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
      (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:339:11: note: in instantiation of member function
      'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
      std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
      std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
      >::operator[]' requested here
                        pin_pos[key] = tok;
                               ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:483:62: error: 
      pack expansion contains parameter packs '_Elements' and '_UElements' that
      have different lengths (1 vs. 3)
      return __and_<is_constructible<_Elements, _UElements&&>...>::value;
                                     ~~~~~~~~~  ~~~~~~~~~~   ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:669:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, int> &>::_MoveConstructibleTuple<int, int, int>'
      requested here
                    _MoveConstructibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, int>, _Dummy = void]
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
      (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:339:11: note: in instantiation of member function
      'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
      std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
      std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
      >::operator[]' requested here
                        pin_pos[key] = tok;
                               ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:489:60: error: 
      pack expansion contains parameter packs '_UElements' and '_Elements' that
      have different lengths (3 vs. 1)
      return __and_<is_convertible<_UElements&&, _Elements>...>::value;
                                   ~~~~~~~~~~    ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:671:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, int> &>::_ImplicitlyMoveConvertibleTuple<int, int,
      int>' requested here
                    _ImplicitlyMoveConvertibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, int>, _Dummy = void]
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, int>, _Dummy = (no value), $2 =
      (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:339:11: note: in instantiation of member function
      'std::map<std::tuple<int, int, int>, std::__cxx11::basic_string<char>,
      std::less<std::tuple<int, int, int> >, std::allocator<std::pair<const
      std::tuple<int, int, int>, std::__cxx11::basic_string<char> > >
      >::operator[]' requested here
                        pin_pos[key] = tok;
                               ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:471:67: error: 
      pack expansion contains parameter packs '_Elements' and '_UElements' that
      have different lengths (1 vs. 3)
      return __and_<is_constructible<_Elements, const _UElements&>...>::value;
                                     ~~~~~~~~~        ~~~~~~~~~~  ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:645:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, std::__cxx11::basic_string<char> >
      &>::_ConstructibleTuple<int, int, std::__cxx11::basic_string<char> >'
      requested here
                    _ConstructibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = void]
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = (no value), $2 = (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:450:15: note: in instantiation of member function
      'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
      std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
      std::allocator<std::pair<const std::tuple<int, int,
      std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
                x_y_name_net[key] = seg.net;
                            ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:477:65: error: 
      pack expansion contains parameter packs '_UElements' and '_Elements' that
      have different lengths (3 vs. 1)
      return __and_<is_convertible<const _UElements&, _Elements>...>::value;
                                         ~~~~~~~~~~   ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:647:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, std::__cxx11::basic_string<char> >
      &>::_ImplicitlyConvertibleTuple<int, int, std::__cxx11::basic_string<char>
      >' requested here
                    _ImplicitlyConvertibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:651:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = void]
        constexpr tuple(const tuple<_UElements...>& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = (no value), $2 = (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:450:15: note: in instantiation of member function
      'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
      std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
      std::allocator<std::pair<const std::tuple<int, int,
      std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
                x_y_name_net[key] = seg.net;
                            ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:483:62: error: 
      pack expansion contains parameter packs '_Elements' and '_UElements' that
      have different lengths (1 vs. 3)
      return __and_<is_constructible<_Elements, _UElements&&>...>::value;
                                     ~~~~~~~~~  ~~~~~~~~~~   ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:669:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, std::__cxx11::basic_string<char> >
      &>::_MoveConstructibleTuple<int, int, std::__cxx11::basic_string<char> >'
      requested here
                    _MoveConstructibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = void]
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = (no value), $2 = (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:450:15: note: in instantiation of member function
      'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
      std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
      std::allocator<std::pair<const std::tuple<int, int,
      std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
                x_y_name_net[key] = seg.net;
                            ^
In file included from icetime.cc:24:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/functional:55:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:489:60: error: 
      pack expansion contains parameter packs '_UElements' and '_Elements' that
      have different lengths (3 vs. 1)
      return __and_<is_convertible<_UElements&&, _Elements>...>::value;
                                   ~~~~~~~~~~    ~~~~~~~~~ ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:671:21: note: 
      in instantiation of function template specialization 'std::_TC<true, const
      std::tuple<int, int, std::__cxx11::basic_string<char> >
      &>::_ImplicitlyMoveConvertibleTuple<int, int,
      std::__cxx11::basic_string<char> >' requested here
                    _ImplicitlyMoveConvertibleTuple<_UElements...>()
                    ^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/tuple:675:19: note: 
      while substituting prior template arguments into non-type template
      parameter [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = void]
        constexpr tuple(tuple<_UElements...>&& __in)
                  ^~~~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/bits/stl_map.h:484:38: note: 
      while substituting deduced template arguments into function template
      'tuple' [with _UElements = <int, int, std::__cxx11::basic_string<char>>,
      _Dummy = (no value), $2 = (no value)]
                                            std::tuple<const key_type&>(__k),
                                                                        ^
icetime.cc:450:15: note: in instantiation of member function
      'std::map<std::tuple<int, int, std::__cxx11::basic_string<char> >, int,
      std::less<std::tuple<int, int, std::__cxx11::basic_string<char> > >,
      std::allocator<std::pair<const std::tuple<int, int,
      std::__cxx11::basic_string<char> >, int> > >::operator[]' requested here
                x_y_name_net[key] = seg.net;
                            ^
8 errors generated.
<builtin>: recipe for target 'icetime.o' failed
make[1]: *** [icetime.o] Error 1
make[1]: Leaving directory '/home/aaa/Software/icestorm/icetime'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

[iceprog] It takes more than 30 seconds to download the bistream in some computers

I have tested in three different laptops. What I got is:

$ time sudo iceprog scicad1.bin
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x12 0x67 0x21 0x23 0x00 0x21 0x00 0x43 0x04 0x11 0x11 0x5F 0x7D
file size: 32220
erase 64kB sector at 0x000000..
programming..
reading..
VERIFY OK
cdone: high
Bye.

real 0m33.554s
user 0m0.016s
sys 0m0.056s

It takes 33 seconds to perform the programming. But in other computers it just takes 3 seconds.

I made one test in two laptops with ubuntu 15.10. Same kernel, same linux distro. Laptop A took 30 seconds and Laptop B only 3sec

Laptop A: High-end laptop: i7, 8GB RAM
Laptop B: Low-end laptop: intel core duo, 4GB RAM (five years old)

Any help or suggestions on test to perform are welcome

JSON timing report and wire delay

Some important information in timing report present in textual format and absent in JSON.

wire detay (or cell delay?) on of those
extended wire name like $auto$alumacc.cc:470:replace_alu$9.C[3]

text:

        lc40_1_2_1 (LogicCell40) carryin -> carryout: 0.126 ns
     1.987 ns net_4014 ($auto$alumacc.cc:470:replace_alu$9.C[2])
        lc40_1_2_2 (LogicCell40) carryin -> carryout: 0.126 ns
     2.113 ns net_4020 ($auto$alumacc.cc:470:replace_alu$9.C[3])

json:

    { out_net: "net_4014", cell: "lc40_1_2_1", cell_type: "LogicCell40", cell_in_port: "carryin", cell_out_port: "carryout", delay_ns: 1.987, },
    { out_net: "net_4020", cell: "lc40_1_2_2", cell_type: "LogicCell40", cell_in_port: "carryin", cell_out_port: "carryout", delay_ns: 2.113, },

wiki

clifford, would the icestorm wiki be the place to link to tutorials (like mine ~:")

[For FAQ?] UDEV Magic

From Project Icestorm homepage:

Notes for Linux: Create a file /etc/udev/rules.d/53-lattice-ftdi.rules with the following line in it to allow uploading bit-streams to a Lattice iCEstick and/or a Lattice iCE40-HX8K Breakout Board as unprivileged user:

ACTION=="add", ATTR{idVendor}=="0403", ATTR{idProduct}=="6010", MODE:="666"

This did not work for me on Debian9. Other tries like setting the device node's ownership/permissions right for my account failed too.

After digging a while, I found Debian's fpga-icestorm_*.deb includes this UDEV rule:

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0660", GROUP="plugdev", TAG+="uaccess"

This one worked here and now I can drop sudo for loading the FPGA.

Timing estimate: 0.00 ns (inf MHz)

Using attached bitstream, fpga-icestorm 0~20160218gitf2b2549- from Debian and running icetime -d hx8k -p board/iCE40HX8K-B-EVM.pcf -P ct256 test.txt.
test.txt

Problem building on Mac OS X 10.9.5

Hello,

The make fails with:

[Geoffreys-MacBook-Pro-2:fpga/tools/icestorm] geoffc% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C icebox
make[1]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C icepack make[1]: Nothing to be done forall'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C iceprog
clang -MD -O0 -ggdb -Wall -std=c99 -I/usr/local/include -c -o iceprog.o iceprog.c
In file included from iceprog.c:27:
/usr/local/include/ftdi.h:20:10: fatal error: 'usb.h' file not found

include <usb.h>

1 error generated.
make[1]: *** [iceprog.o] Error 1
make: *** [all] Error 2

I'm not sure which package I might need to supply the usb.h file. Has anyone else run across this one?

Thanks.

Geoff

Build system bikesheds

I currently provide automated nightly builds of the icestorm toolchain, and I am finally getting around to upstreaming the horrible ugly build system hacks that I've been using. I noticed that icestorm has a special mxebin makefile target that is used to create a Windows package. Is there a particular reason why the normal install target cannot be fixed to work? Would you accept a patch that fixes install for cross-building Windows packages?

icebox_explain

Ignore this comment!

icetime does not accept valid net names for timing analysis

When attempting to generate a timing report for any given global clock net names (verified to exist in the corresponding arachne-pnr output) icetime always returns:

icetime -m -d hx8k -p test.pcf -P ct256 -T secondary_clock test.int
// Reading input .pcf file..
// Reading input .asc file..
// Reading 8k chipdb file..
// Creating timing netlist..

icetime topological timing analysis report
==========================================

Info: max_span_hack is enabled: estimate is conservative.

Report for secondary_clock:
--------------------------------------

Net not found: secondary_clock

Yet the symbol exists:

.sym 6 secondary_clock

Is this a bug? There is next to no documentation on icetime for anything other than generating an absolute worst case timing estimate for the entire design.

Thanks!

icetime, from json support, bug: std::out_of_range

Hi,

From the commit bafd99b , icetime terminates with an 'std::out_of_range' exception (tested on an hx8k asc file).
The exception is emited by map::at in icetime.cc line 863

Simon.