yosyshq / arachne-pnr Goto Github PK

Place and route tool for FPGAs

License: MIT License

Makefile 1.83% Shell 1.97% C++ 90.40% Python 2.57% Verilog 3.24%

arachne-pnr's Introduction

Arachne-pnr

Arachne-pnr is not maintained anymore; use nextpnr instead, which is a complete functional replacement with major improvements.

Updates

2015-08-06: Interface change: Default seed is 1, can be randomized with -r option.

2015-07-18: New version. Release notes:

IceStorm and arachne-pnr now support the iCE40LP/HX8K
huge speed improvements (~50x)
arachne-pnr now prints the random seed on each run. The seed can be set with the -s option. With the same seed, arachne-pnr should be deterministic across platforms and C++ compilers.

What is arachne-pnr?

Arachne-pnr implements the place and route step of the hardware compilation process for FPGAs. It accepts as input a technology-mapped netlist in BLIF format, as output by the Yosys [0] synthesis suite for example. It currently targets the Lattice Semiconductor iCE40 family of FPGAs [1]. Its output is a textual bitstream representation for assembly by the IceStorm [2] icepack command. The output of icepack is a binary bitstream which can be uploaded to a hardware device.

Together, Yosys, arachne-pnr and IceStorm provide an fully open-source Verilog-to-bistream tool chain for iCE40 1K and 8K FPGA development.

Warning!

This is experimental software! It might have bugs that cause it to produce bitstreams which could damage your FPGA! So when you buy an evaluation board, get a few.

We have done extensive verification-based testing (see tests/), but so far limited hardware-based testing. This will change.

Status

Arachne-pnr uses a simulated annealing-based algorithm for placement and a multi-pass congestion-based router. Arachne-pnr supports all features documented by IceStorm, although the Block RAM has not been extensively tested. This should include everything on the chip except PLLs and timing information. Support for PLLs is in the works. We hope to support timing information as soon as it is documented by the IceStorm project.

Installing

Arachne-pnr is written in C++11. It has been tested under OSX and Linux with LLVM/Clang and GCC. It should work on Windows, perhaps with a little work. (Patches welcome.) It depends on IceStorm. You should also install Yosys to synthesize designs.

To install, just go to the arachne-pnr directory and run

$ make && sudo make install

Invoking/Example

Lattice has several low-cost breakout boards: iCEstick for the 1K [3] and iCE40-HX8K Breakout Board [4] for the 8K.

There is a simple example for the iCEstick evaluation board in example/rot which generates a rotating pattern on the user LEDs. The Verilog input is in rot.v and the physical (pin) constraints are in rot.pcf. To build it, just run make, which executes the following commands:

yosys -q -p "synth_ice40 -blif rot.blif" rot.v
../../bin/arachne-pnr -p rot.pcf rot.blif -o rot.txt
icepack rot.txt rot.bin

You can use the Lattice tools or iceprog from IceStorm to upload rot.bin onto the board.

Feedback

Feedback, feature requests, bug reports and patches welcome. Please email the author, Cotton Seed [email protected], or submit a issue on Github.

Acknowledgements

Arachne-pnr would not have been possible without Clifford Wolf and Mathias Lasser's IceStorm project to reverse-engineer the iCE40 FPGAs and build supporting tools. Also, it would not be useful without Clifford Wolf's Yosys project to synthesize and technology map designs. Thanks to contributors Larry Doolittle, jhol, laanwj, Clifford Wolf (cliffordwolf) and zeldin.

References

[0] http://www.clifford.at/yosys/

[1] http://www.latticesemi.com/iCE40

[2] http://www.clifford.at/icestorm/

[3] http://latticesemi.com/iCEstick

[4] http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard.aspx

arachne-pnr's People

Contributors

Stargazers

Watchers

arachne-pnr's Issues

"Assertion failed!" when instantiating pullup manually

I have created a MVCE of a single SB_IO primitive being instantiated to enable the I/O pullup, and the input being fed to an output pin. Running build_top.bat produces the following crash on Windows. I am currently unable to test on Linux:

seed: 1
device: 1k
read_chipdb +/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif top.blif...
prune...
read_pcf top.pcf...
instantiate_io...
pack...

After packing:
IOs          3 / 96
GBs          0 / 8
  GB_IOs     0 / 8
LCs          0 / 1280
  DFF        0
  CARRY      0
  CARRY, DFF 0
  DFF PASS   0
  CARRY PASS 0
BRAMs        0 / 16
WARMBOOTs    0 / 1
PLLs         0 / 1

place_constraints...
promote_globals...
  promoted 0 nets
  0 globals
realize_constants...
place...
  initial wire length = 40
  at iteration #50: temp = 7.92282, wire length = 40
  final wire length = 40

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertion failed!

Program: C:\msys64\mingw32\bin\arachne-pnr.exe
File: src/bitvector.hh, Line 91

Expression: i >= B && i < n + B

I do not know for sure whether:

arachne-pnr is being fed bad output from yosys.
The yosys output is fine, but arachne-pnr chokes.

Regardless, I wouldn't have expected a crash; the code from which this sample was derived was known to work in September 2016. I recently upgraded yosys from a September 2016 version when I was still using a June 2016 version of arachne-pnr; both the June 2016 and current HEAD crash with this output from my current build. So, I expect that some field in the yosys-emitted BLIF changed between 2016 and now, and arachne-pnr chokes.

Here is some relevant version information:

$ arachne-pnr --version
arachne-pnr 0.1+203+1 (git sha1 7e135ed, g++ 5.3.0 -O2)

$ yosys -V
Yosys 0.7+307 (git sha1 56565a4, i686-w64-mingw32-gcc 5.3.0 -Os)

$ uname -a
MINGW32_NT-6.1 William-THINK 2.4.0(0.292/5/3) 2015-12-22 09:37 x86_64 Msys

Note the yosys used is a fork.

std::out_of_range exception in src/global.cc:242

Given the latest toolchain (for exact tracking you can check out github.com/dpiegdon/IceStormToolchain.git) and the project in github.com/dpiegdon/orbuculum.git branch icestick-support in directory /orbtrace/, when typing make ICE40HX1K_STICK_EVN, yosys will fail with an std::out_of_range exception.

$> make ICE40HX1K_STICK_EVN
arachne-pnr -m 800 -d 1k -P tq144 -p toplevel_ice40hx1k_stick_evn.pcf traceIF.blif -o traceIF_ice40hx1k_stick_evn.txt
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif traceIF.blif...
prune...
read_pcf toplevel_ice40hx1k_stick_evn.pcf...
instantiate_io...
pack...

After packing:
IOs          20 / 96
GBs          0 / 8
  GB_IOs     1 / 8
LCs          942 / 1280
  DFF        286
  CARRY      188
  CARRY, DFF 4
  DFF PASS   84
  CARRY PASS 28
BRAMs        2 / 16
WARMBOOTs    0 / 1
PLLs         1 / 1

place_constraints...
promote_globals...
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
gmake: *** [Makefile:27: build] Aborted

It is quite possible that the project is too big to be mappen on an HX1K. I am trying to port a project that can successfully be built using yosys et al for an HX8K to an HX1K (see given repo). That might be the actual source of the bug.

gdb backtrace:

#0  0x00007ffff7144e65 in raise () from /lib64/libc.so.6
#1  0x00007ffff7146b6a in abort () from /lib64/libc.so.6
#2  0x00007ffff7a92f1d in __gnu_cxx::__verbose_terminate_handler () at /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff7a90d46 in __cxxabiv1::__terminate (handler=) at /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x00007ffff7a90d91 in std::terminate () at /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x00007ffff7a90fa9 in __cxxabiv1::__cxa_throw (obj=obj@entry=0xa7ede0, tinfo=Reading in symbols for /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/libsupc++/tinfo.cc...done.
0x7ffff7dc9950 , dest=Reading in symbols for /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/src/c++98/stdexcept.cc...done.
0x7ffff7aa65a0 ) at /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007ffff7aba79f in std::__throw_out_of_range (__s=0x4c135d "map::at") at /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:90
#7  0x0000000000457398 in std::map, std::allocator > >::at (this=0x72c028, __k=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_map.h:532
#8  0x00000000004b2007 in Promoter::promote (this=0x7fffffff98c0, do_promote=true) at src/global.cc:242
#9  0x00000000004b3c33 in promote_globals (ds=..., do_promote=true) at src/global.cc:474
#10 0x000000000040708f in main (argc=12, argv=0x7fffffffda08) at src/arachne-pnr.cc:542

the actual line triggering the exception is in frame 8:

#8  0x00000000004b2007 in Promoter::promote (this=0x7fffffff98c0, do_promote=true) at src/global.cc:242
242                   int g = chipdb->loc_pin_glb_num.at(chipdb->cell_location[c]);

the problem seems to be that chipdb->cell_location[c] resolves to something that is not contained in chipdb->loc_pin_glb_num.

(gdb) print chipdb->cell_location[c]
Reading in symbols for src/chipdb.cc...done.
$2 = (__gnu_cxx::__alloc_traits >::value_type &) @0xb21588: {
  m_tile = 248,
  m_pos = 1
}

(gdb) print chipdb->loc_pin_glb_num
$3 = std::map with 8 elements = {
  [{
    m_tile = 6,
    m_pos = 1
  }] = 6,
  [{
    m_tile = 7,
    m_pos = 0
  }] = 3,
  [{
    m_tile = 112,
    m_pos = 1
  }] = 1,
  [{
    m_tile = 125,
    m_pos = 1
  }] = 0,
  [{
    m_tile = 126,
    m_pos = 0
  }] = 4,
  [{
    m_tile = 139,
    m_pos = 0
  }] = 5,
  [{
    m_tile = 244,
    m_pos = 1
  }] = 7,
  [{
    m_tile = 245,
    m_pos = 0
  }] = 2
}

I am unsure how to proceed here; I do not know very much about internals of FPGAs and cannot make too much sense of the code.

i would appreciate it if you helped me fix this issue.

invalid .names entry

I am trying out the arachne-pnr on a blif file generated with yosys, and it fails on invalid .names entry.

I am using these versions:
Yosys 0.6+209 (git sha1 9b8e06b, gcc 6.1.1 -march=x86-64 -mtune=generic -O2 -fstack-protector-strong -fPIC -Os)
arachne-pnr 0.1+171+0 (git sha1 52e69ed, g++ 6.2.1 -O2)

The build script I am using with yosys is:

read_verilog verilog/Simple/counter.v
read_verilog verilog/Simple/Simple_a4.v
read_verilog verilog/Simple/Simple_binaryTo7Segment_0.v
read_verilog verilog/Simple/Simple_binaryTo7Segment.v
read_verilog verilog/Simple/Simple_BitPackBitVector1.v
read_verilog verilog/Simple/Simple_BitPackBitVector2.v
read_verilog verilog/Simple/Simple_bundler_sbundler.v
read_verilog verilog/Simple/Simple_countThe_scountThe.v
read_verilog verilog/Simple/Simple_debounce.v
read_verilog verilog/Simple/Simple_limiter.v
read_verilog verilog/Simple/Simple_released.v
read_verilog verilog/Simple/Simple_toggle.v
read_verilog verilog/Simple/Simple_topEntity.v

hierarchy -check -top counter

proc;    opt
memory;  opt
techmap; opt
flatten; opt

write_blif -unbu counter.blif

I added the flatten command because before that the generated blif file contained .subckt definitions which currently are not supported by arachne-pnr #21 .

I then invoke arachne-pnr like this:
arachne-pnr -d 1k -p Go_Board_Constraints_arachne_pnr.pcf -P vq100 -o counter.asc counter.blif

The error message I then get from arachne-pnr is:
seed: 1 device: 1k read_chipdb +/share/arachne-pnr/chipdb-1k.bin... supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100 read_blif counter.blif... counter.blif:11: fatal error: invalid .names entry

The first content (including the line of the error) of the blif file used is:

# Generated by Yosys 0.6+209 (git sha1 9b8e06b, gcc 6.1.1 -march=x86-64 -mtune=generic -O2 -fstack-protector-strong -fPIC -Os)

.model counter
.inputs i_Switch_1 system1000 system1000_rstn
.outputs o_LED_1 o_Segment1_A o_Segment1_B o_Segment1_C o_Segment1_D o_Segment1_E o_Segment1_F o_Segment1_G
.names $false
.names $true
1
.names $undef
.names Simple_topEntity_inst.Simple_binaryTo7Segment_0_result_0.map[6].Simple_BitPackBitVector1_0.result o_Segment1_A
0 1

counter.blif.txt
I should mention that I am a beginner in FPGAs.

I don't know whether this is a bug or me not using the tools correctly.

Add version flag

I'm trying to find the version of arachne-pnr I have installed (since it appears to be missing features that should be there).

$ arachne-pnr --version
fatal error: unknown option `--version'
$ arachne-pnr -v
fatal error: unknown option `-v'
$ arachne-pnr -h
…(help, but still no version info)…

Handling of LVDS pin constraint

A minor thing: if an LVDS pin is specified in the .pcf file as the "wrong" one of its pair, arachne-pnr aborts with

arachne-pnr: src/place.cc:1063: void Placer::place_initial(): Assertion `valid(chipdb->cell_location[c].tile())' failed.

rather than producing an error message or (perhaps preferably) correctly allocating both pins. To demonstrate this, take the example in the issue report "Apparently invalid bitstream for LVDS input" and change the pin assignment in the first line of the constraints file from 34 to 33.

I/O buffers use local high skew network instead of global clock buffer

As project size increases arachne-pnr has an increasing tendency to connect IO block clocks to global clock networks via an intermediate buffer and high-skew local net chain. This, in turn, destroys output timing and makes the result useless for clocked busses.

I have created a minimal testcase (see attached). Note that data_out[0] and data_out[1] correctly connect the I/O buffer clock directly to the global net, whereas data_out[2] is inexplicably connected to a high-skew local net chain after an unnecessary buffer. In practice, we have verified that this use of the high-skew local nets destroys timing to such an extent that using the current open-source toolchain for clocked synchronous systems is impossible.

Is this something that can be easily fixed?

Thanks!

Test case:
ice40_io_clock_routing_failure_testcase.zip

Accidential use of unbuffered version of buffered clock

(Originally posted as yosys issue #427)

I think I got to the bottom of this. When a clock is used for a global buffer using something like;

SB_GB_IO BtraceClk0
(
.PACKAGE_PIN(traceClk),
.GLOBAL_BUFFER_OUTPUT(BtraceClk)
);

you will got the following error if you try to use traceClk rather than BtraceClk elsewhere in the design;

arachne-pnr: src/netlist.cc:657: void Model::check(const Design*) const: Assertion `!p2->is_bidir()' failed.
./create: line 2: 4153 Aborted (core dumped) arachne-pnr -d 8k -P ct256 -p toplevel.pcf tracIF.blif -o traceIF.txt

Yes, it's probably something only a fool would have tried, but never underestimate the ingenuity of fools....

(I have code in a repository that exhibits this issue, but its otherwise in a horribly broken state so please PM or Gitter me for a link if you need it to re-create the problem usng my codebase ... it will be opensource, just not ready yet).

DAVE

Assertion failed: (cnet_net[cn] == nullptr || cnet_net[cn] == n), function route, file src/route.cc, line 698.

Weird issue I found, and I've broken it down to the minimum Verilog to demonstrate it. Not at all advocating this chunk of Verilog is any good. I'm using the iCE40HX8K evaluation board, and was attempting to use the 6502 softcore from http://www.aholme.co.uk/6502/Main.htm. I was using the start up counter without the Xilinx DCM stuff and I discovered this weird bug.

The same code works in IceCube2 however using yosys and arachne-pnr I always get this assert. Here is a small demonstration of what I'm seeing.

module top (
    input clk,
    output res
);

    reg [7:0] start;
    always @ (posedge clk)
        if (~start[7]) start <= start + 1;
    assign res = start[7];

endmodule

# For the iCE40HX-8K Breakout Board

## System Clock
set_io clk J3

### LEDs
set_io res B5

$ yosys -V
Yosys 0.7 (git sha1 UNKNOWN, clang 9.0.0 -fPIC -Os)
$arachne-pnr -v
arachne-pnr 0.1+252+ 0 (git sha1 a32dd2c, c++ 9.0.0 -O2)

$ yosys -q -p "synth_ice40 -blif test.blif" *.v
$ arachne-pnr -d 8k -P ct256 -o basic.asc -p ice40hx8k.pcf test.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 test.blif...
prune...
read_pcf ice40hx8k.pcf...
instantiate_io...
pack...

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

place_constraints...
promote_globals...
  promoted clk$2, 8 / 8
  promoted $abc$200$n3, 6 / 6
  promoted 2 nets
    1 cen/wclke
    1 clk
  2 globals
    1 cen/wclke
    1 clk
realize_constants...
  realized 1
place...
  initial wire length = 293
  at iteration #50: temp = 11.3403, wire length = 117
  at iteration #100: temp = 4.99118, wire length = 106
  at iteration #150: temp = 1.53407, wire length = 50
  at iteration #200: temp = 0.0054219, wire length = 41
  final wire length = 41

After placement:
PIOs       3 / 206
PLBs       4 / 960
BRAMs      0 / 32

  place time 0.01s
route...
n $true cn 4055 cnet_net[cn] $abc$200$n3$2
Assertion failed: (cnet_net[cn] == nullptr || cnet_net[cn] == n), function route, file src/route.cc, line 698.
Abort trap: 6

Changing this chunk of "start" code to something better has removed the assert trigging, but I'm unsure what's actually causing it. I've tried to dig into the code to see if I can help, but I quickly fell out of my depth. Any assistance or explanation of what is wrong with this would be greatly appreciated. Thanks!

intermittent fatal error during placement

Hi cseed,

Thanks ever so much for arachne-pnr!

with latest arachne-pnr@1a4fdf9
as detailed in jamesbowman/swapforth#27 , the error is:

place...
fatal error: failed to place: placed 1121 LCs of 1220 / 1280

Any suggestions appreciated

Summary output report formats?

Does Project IceStorm toolchain (yosys, arachne-pnr, IceStorm Tools) have some type of standard output format for getting reports about things like;

Messages like info, warnings & errors (for all stages)
Synthesis information like;
- Parameters set for modules
- Optimisations applied
- Transformations
- Component + Blackbox Statistics / Usage
- etc
Place & Route like;
- Resource usage
- Timing information
- etc

The reason I'm asking is that in my CI system, I would like to track how a design is changing over time. For example, I would like to understand if merging a change will dramatically increase resource usage, introduce new warnings, etc.

I don't quite know what would be the most useful to track yet, so also open to suggestions there :-). I don't really want the extreme low level details, more high level and hierarchical summaries.

I eventually hope to write some crappy Python scripts which translate the proprietary tools (like Vivado and ISE) into the Yosys / OpenFPGA formats to reuse the tracking for designs I can't yet use the open tools for.

Thank you for your help!

ICE40HX8K-BG121

Good day,

I'm interested in using the BG121 flavour of the ICE40HX8K, since it's a less expensive 0.8mm alternative to the CT256.

It's not mentioned in much of the Lattice documentation, but in some recent correspondence about the chip with a Lattice representative, he/she said "ICE40HX8K-BG121 package was just added in the datasheet last year so it's not one of the discontinued products."

I'd figure I'd open a ticket, if there's any chance of it being supported.

``make test`` is failing with traceback

cd tests/fsm && bash run-test.sh
+ arachne_pnr=../../bin/arachne-pnr
+ rm -rf temp
+ mkdir temp
+ python generate.py
Traceback (most recent call last):
  File "generate.py", line 46, in <module>
    with file('temp/uut_%05d.v' % idx, 'w') as f:
NameError: name 'file' is not defined
make: *** [Makefile:68: test] Error 1

This is using today's tip. (52e69ed207342710080d85c7c639480e74a021d7)

LUT interior expression

Currently the output produced by the tool provides the information about the LUT configuration as the number.
example:

  "type": "ICESTORM_LC",
  "parameters": {
    "LUT_INIT": 27030, <-- ???
    "CARRY_ENABLE": 1
  }

It would be beneficial (to visualization / navigation / extraction ... effort) to elaborate on LUT configuration in logical expression form.

Here is example of such format: http://wavedrom.com/tutorial2.html

Poor optimisation of carry chains

When a carry chain is "packed" the most-significant bit is handled differently from the others, and an unnecessary pass-through LUT is inserted into the design. This significantly slows the critical path.

For example, given the input BLIF file test1.blif:

# Generated by Yosys 0.6+139 (git sha1 df5ebfa, clang 3.8.0-2ubuntu3 -fPIC -Os)

.model top
.inputs clk a0 a1 a2 b0 b1 b2
.outputs y0 y1 y2
.names $false
.names $true
1
.names $undef
.gate SB_LUT4 I0=$false I1=b0 I2=a0 I3=$false O=d[0]
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param LUT_INIT 0110100110010110
.gate SB_CARRY CI=$false CO=$auto$alumacc.cc:470:replace_alu$4.C[1] I0=b0 I1=a0
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:47"
.gate SB_LUT4 I0=$false I1=b1 I2=a1 I3=$auto$alumacc.cc:470:replace_alu$4.C[1] O=d[1]
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param LUT_INIT 0110100110010110
.gate SB_CARRY CI=$auto$alumacc.cc:470:replace_alu$4.C[1] CO=$auto$alumacc.cc:470:replace_alu$4.C[2] I0=b1 I1=a1
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:47"
.gate SB_LUT4 I0=$false I1=b2 I2=a2 I3=$auto$alumacc.cc:470:replace_alu$4.C[2] O=d[2]
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param LUT_INIT 0110100110010110
.gate SB_DFF C=clk D=d[0] Q=y0
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_DFF C=clk D=d[1] Q=y1
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_DFF C=clk D=d[2] Q=y2
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.names y0 q[0]
1 1
.names y1 q[1]
1 1
.names y2 q[2]
1 1
.end

which is a simple registered three-bit adder, pin constraints file test1.pcf:

set_io y0 107
set_io y1 106
set_io y2 105
set_io clk 34
set_io a0 2
set_io a1 3
set_io a2 4
set_io b0 19
set_io b1 20
set_io b2 21

and command line:

arachne-pnr --post-pack-blif test1.post.pack.blif -p test1.pcf -o test1.asc test1.blif

the result in the file test1.post.pack.blif contains

.gate ICESTORM_LC I0=$false I1=b0$2 I2=a0$2 I3=$false CIN= CLK=clk$2 CEN=$true SR=$false LO= O=y0$2 COUT=
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2|/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param DFF_ENABLE 1
.param LUT_INIT 0110100110010110
.gate ICESTORM_LC I0=$false I1=b1$2 I2=a1$2 I3=$auto$alumacc.cc:470:replace_alu$4.C[1] CIN=$auto$alumacc.cc:470:replace_alu$4.C[1] CLK=clk$2 CEN=$true SR=$false LO= O=y1$2 COUT=$auto$alumacc.cc:470:replace_alu$4.C[2]$2
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2|/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param CARRY_ENABLE 1
.param DFF_ENABLE 1
.param LUT_INIT 0110100110010110
.gate ICESTORM_LC I0=$false I1=b2$2 I2=a2$2 I3=$auto$alumacc.cc:470:replace_alu$4.C[2] CIN= CLK=clk$2 CEN=$true SR=$false LO= O=y2$2 COUT=
.attr src "test1.v:6|/usr/local/bin/../share/yosys/ice40/cells_map.v:2|/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param DFF_ENABLE 1
.param LUT_INIT 0110100110010110
.gate ICESTORM_LC I0= I1=b0$2 I2=a0$2 I3= CIN=$false CLK= CEN= SR= LO= O= COUT=$auto$alumacc.cc:470:replace_alu$4.C[1]
.param CARRY_ENABLE 1
.gate ICESTORM_LC I0= I1= I2= I3=$auto$alumacc.cc:470:replace_alu$4.C[2]$2 CIN= CLK= CEN= SR= LO= O=$auto$alumacc.cc:470:replace_alu$4.C[2] COUT=
.param LUT_INIT 1111111100000000

The last ICESTORM_LC gate is being used as a pass-through to route C[2] to input I3 of the logic cell generating y2, when the same effect could have been got by using the carry-in input of that cell.

I believe the problem is around line 497 of pack.cc, where the code checks only whether the final output of the carry chain (which is calculated in the penultimate logic cell of the chain) is used, but not whether it is used as the carry-in of the last logic cell in the chain.

Although the logic produced is correct, this issue significantly affects the performance of adders. I believe a similar problem occurs with counters, but I have not investigated this thoroughly.

Note that the in example above the tool has also inserted unnecessary duplicate logic to calculate y0 and C[1], not present in the input BLIF file. This is a less significant problem, as it represents only a small inefficiency in resource usage and is unlikely to affect the performance of a design.

Assigning IO to pin 78 gives assert

Changing the rot.v example's assignments in rot.pcf from

set_io D5 95

set_io D5 78

then running make gives:

arachne-pnr: src/vector.hh:70: BasedVector<T, B>::reference BasedVector<T, B>::operator[](BasedVector<T, B>::size_type) [with T = int; typename std::vector<_RealType>::size_type B = 1ul; BasedVector<T, B>::reference = int&; BasedVector<T, B>::size_type = long unsigned int]: Assertion `i >= B && i < B + v.size()' failed.

adding icestorm package variant results in assertion failure

Hi, I just tried to add bonding information for the vq100 package of the 1k chip in the icestorm project (see https://github.com/alibabashack/icestorm/tree/1k-vq100). When I try to build arachne-pnr with the resulting chip-db I get the following assertion failure. I'm unsure if my modifications in icestorm are wrong or this is a problem in arachne:

mkdir -p share/arachne-pnr
bin/arachne-pnr -d 1k -c /usr/local/share/icebox/chipdb-1k.txt --write-binary-chipdb share/arachne-pnr/chipdb-1k.bin
seed: 1
device: 1k
read_chipdb /usr/local/share/icebox/chipdb-1k.txt...
arachne-pnr: src/chipdb.cc:852: void ChipDB::finalize(): Assertion `tile_pos_cell[t][pos] == 0' failed.
make: *** [share/arachne-pnr/chipdb-1k.bin] Aborted (core dumped)

Feature request: timing constraints

Now that IceStorm has documented the timing for these devices (and in fact can generate a nice static timing report via icetime), would you consider adding timing-driven P&R to arachne? We really need to be able to place a period constraint on a couple of our clock signals.

Thanks!

route.cc:652: void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed.

arachne-pnr: src/route.cc:652: void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed.

This seems to be triggered by using .PLLOUTGLOBAL(clk) instead of .PLLOUTCORE(clk)

Maybe related to #20 ?

Support for ASM.JS target

I am building in-browser tool to design and program FPGAs using Yosys and Arachne-PNR.
Yosys provides ability to build for the ASM.JS target. Would it be possible to add similar ability to the Arachne-PNR?

`make simpletest` assumes yosys is installed

... but this line says that it doesn't.
make simpletest executes tests/regression/run-test.sh, which on line 25 executes yosys.

Feature request: Ignore unused constraints

It would be nice to have an option to allow unused entries in a PCF file to be ignored. If there is a way to do that, I haven't found it.

arachne-pnr: src/route.cc:653: void Router::route(): Assertion `cnet_net[cn] == nullptr || cnet_net[cn] == n' failed.

I'm developing on a BlackIce board, basically an ICE40 FPGA.

My code is a very simple counter on 4 LEDS, almost identical with a Blackice Tutorial example,
but with a software reset facility, which I need for further development. The tutorial example
compiles and runs without problems, but with the reset counter added in, I get the assertion
failure.

I had a lot of other code in there, but after cutting it back to the minimum that still fails it is:

module test(input CLK100,
	    output [3:0] LEDS
	    );

   reg [26:0] 	   rst_ct;
   reg [26:0] 	   bigcount;
   wire 	   reset;

   assign reset   = !rst_ct[26];
   assign LEDS = bigcount[26:23];

   always @ (posedge CLK100) 
     begin
	if (rst_ct[26]) begin
	end
	else
	  rst_ct <= rst_ct + 27'd1;
     end

   always @ (posedge CLK100)
     if (reset) 
       begin
	  bigcount <= 27'd0;
       end
     else
       begin
	  bigcount <= bigcount + 27'd1;
       end // else: !if(reset)
endmodule // test

My .pcf file is:

# .pcf file for BlackIce
#
# based on Richard Miller's version - thanks, Richard!
#
#LEDs 
set_io --warn-no-port LEDS[0] 70 # LD1
set_io --warn-no-port LEDS[1] 68 # LD2
set_io --warn-no-port LEDS[2] 67 # LD3
set_io --warn-no-port LEDS[3] 71 # LD4

#PMOD13: 17A 17B 23A 23B
# set_io --warn-no-port PMOD13A 23
# set_io --warn-no-port PMOD13B 24
# set_io --warn-no-port RX 28
# set_io --warn-no-port TX 29

# Onboard 100Mhz oscillator
set_io CLK100 129

My version of IceStorm:

Yosys 0.7+74 (git sha1 45e10c1, clang  -fPIC -Os)    and
arachne-pnr 0.1+187+0 (git sha1 e97e35c, g++ 4.8.4-2ubuntu1~14.04.3 -O2)

I'm happy to try work-arounds if you can suggest them.

Thanks, Bill

Better cross-compiling support

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. One issue I have with the way arachne-pnr's build system is currently set up is that it does not work well with cross-compiling. Specifically, the build system generates binary chipdb files by executing the just-built arachne-pnr binary. This cannot work if the just-built binary isn't built for the same architecture as the host system. I noticed that the Windows target has a completely different makefile path to deal with this problem. Is it possible to make cross-compiling work better and make Windows less of a special case?

LUT cascade

In the SiliconBlue documentation they mention that you can cascade LUTs by connecting the output of a LUT in cell i-1 to the input I2 of the LUT in cell i. I tried doing that and looked at the result. It didn't seem to use the cascade.

Is this feature supported? If so, how do you use it?

Problem parsing blif file

I am getting an error from arachne-pnr:

arachne-pnr -d 1k -P vq100 -p src/iceblink40.pcf bin/top.blif -o bin/top.txt
bin/top.blif:1443: fatal error: unknown model `$DFFSR_PPP'

blif file was generated with:
yosys -q -p "synth_ice40 -blif bin/top.blif" src/top.v

I am using the following versions:
arachne-pnr -v
arachne-pnr 0.1+203+0 (git sha1 7e135ed, g++ 7.1.1 -march=x86-64 -mtune=generic -O2 -fstack-protector-strong -O2)

yosys -V
Yosys 0.7+207 (git sha1 ea805af6, gcc 7.1.1 -march=x86-64 -mtune=generic -O2 -fstack-protector-strong -fPIC -Os)

Any idea ?
Thx

Consider more permissive open source licensing

Hello! I'm working on an open source library which will be generating FPGA bitstreams dynamically, using yosys + icestorm + arachne-pnr. If you'd like more info about what I'm doing, here's the site: https://github.com/scanlime/wiggleport

I was wondering if you would consider re-releasing arachne-pnr under a more permissive license that would allow it to be integrated into other software packages? Something similar to the MIT or ISC license would be ideal, but even LGPL would be a step forward.

Thank you for your consideration!

Make the --warn-no-port the default in the pcf

Could we make the --warn-no-port the default when reading the constraint file ?

At the moment, when absent, it's considered a fatal error to define a port there, and not have in in the top level. I don't think this should be a fatal error, but I might be missing something there.

arachne-pnr: Unknown Model: $_DLATCH_P_

Hello mates,

I am trying to compile an Asynchronous FIFO for the ICE40. It is used to share data between 2 buses with different clock frequencies. The model is taken from the page World of ASIC. It has been copied&pasted and compiled with the commercial tool Ice Cube 2 and it works.

I am trying to do the same with the open source toolchain. However, arachne-pnr fails with the following error:

[...] fatal error: unknown model '$_DLATCH_P_'

I assume the problem comes when trying to place the D LATCH described below:

//'Status' latch logic:
    always @ (Set_Status, Rst_Status, Clear_in) //D Latch w/ Asynchronous Clear & Preset.
        if (Rst_Status | Clear_in)
            Status = 0;  //Going 'Empty'.
        else if (Set_Status)
            Status = 1;  //Going 'Full'.

yosys effectively synthetizes this as a D LATCH and writes the following line to the .blif file:

.attr src "./aFifo.v:105|/usr/local/bin/../share/yosys/ice40/cells_map.v:18"
.gate $_DLATCH_P_ D=$abc$1111$n75 E=$abc$1111$n71 Q=afifo1.Status

Then, the problem must be that arachne-pnr does not know the model for the D latch. Any ideas?

Regards

Add support for the blif construct .subckt

Hi,

from what I see in the blif parser, it appears that the .subckt
construct is not supported yet.

I would like this supported because Yosys generated .subckt
commands when the -noflatten option was used.

Symptom:
top.blif:42: fatal error: unknown directive

Workaround:
Don't use subckt. (For the yosys flow, don't use the -noflatten option)

PS: Thanks for creating this project. Since there exists a workaround, it might make sense
to close this as won't fix.

Error trying to process blockram

I'm trying to create a very simple example of using blockram on an iCE40. My code is in this gist. yosys runs fine, but arachne-pnr gives this output:

seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: tq144
read_blif ramtest.blif...
prune...
read_pcf ramtest.pcf...
instantiate_io...
D1
0x7fac02e1b190
RDATA[0]
clk
0x0
pack...

After packing:
IOs          2 / 96
LCs          0 / 1280
  DFF        0
  CARRY      0
  CARRY, DFF 0
  DFF PASS   0
  CARRY PASS 0
BRAMs        1 / 16
WARMBOOTs    0 / 1
GBs          0 / 8

promote_globals...
  promoted 0 nets
  0 globals
realize_constants...
  realized 0
place...
  initial wire length = 23
  final wire length = 4

After placement:
PIOs       2 / 96
PLBs       1 / 160
BRAMs      1 / 16

  place time 0.00s
route...
  pass 1, 0 shared.
  route time 0.01s
write_txt ramtest.txt...
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: map::at:  key not found
make: *** [ramtest.bin] Abort trap: 6

You can also see that the .txt file generated appears truncated.

Forgive me if it's a problem with the Verilog file. I know that this isn't fully correct use of the blockram, but I wanted to isolate the problem. If there's a working example of blockram use out there, I would love to see it.

I'm at arachne-pnr d820f31 and yosys eb38722e98.

Fix Cygwin build

Cygwin build currently fails due to minor issues. Attached patch seems to fix those (reproduced and tested on Clifford's clone of arachne-pnr).

0001-arachne-pnr-Fix-Cygwin-build.patch.txt

feature request: version query

yosys has a nice feature:

$ yosys -V
Yosys 0.5+352 (git sha1 5dd3e93, gcc 4.6.3-1ubuntu5 -fPIC -Os)

Which is nice for quickly confirming installed version. Would it be possible to implement something similar for archne-pnr?

Ignore PLLs that are unavailable in the current package

Some of the iCE40 devices have a PLL disabled in certain chip packages. Current git head of Project IceStorm adds this information to the chipdb file.

1K ChipDB file:

.extra_cell 6 0 PLL
LOCKED cb121 cb81 cm49 swg16tr cm36 qn48 vq100

8K ChipDB file:

.extra_cell 16 33 PLL
LOCKED cm81:4k cm81

In commit 45ea318 I added a quick hack to simply ignore those entries.

Ultimately the PLLs should be made unavailable to the placer if arachne-pnr is called with a chip package that has the PLL marked as locked. But I'm not sure about the best way to add this to arachne-pnr.

Inferring SB_IO with D_IN_0 from $_TBUF_ cells

I've been playing with inference of SB_IO from $_TBUF_ cells and encountered a few problems. Afaics it boils down to the following test case:

module test(input din, en, output dout, inout io);
  assign io = en ? din : 1'bz, dout = io;
endmodule

yosys -p 'synth_ice40 -blif tristate.blif' tristate.v
arachne-pnr -o tristate.asc tristate.blif

Which should of course be equivalent to:

module test(input din, en, output dout, inout io);
  SB_IO #(
    .PIN_TYPE(6'b 1010_01),
    .PULLUP(1'b 0)
  ) iobuf (
    .PACKAGE_PIN(io),
    .OUTPUT_ENABLE(en),
    .D_OUT_0(din),
    .D_IN_0(dout)
  );
endmodule

But arachne-pnr produces the following error for BLIF generated from the first Verilog code:

tristate.blif:14: fatal error: toplevel inout port 'io' not connected to SB_IO PACKAGE_PIN

The BLIF generated by Yosys looks reasonable imo:

.model test
.inputs din en io
.outputs dout io
.names $false
.names $true
1
.names $undef
.gate $_TBUF_ A=din E=en Y=io
.attr src "tristate.v:2"
.names io dout
1 1
.end

multi-core processing?

Is there a posibility to run arachne using several CPU cores to speed up its processing?

arachne-pnr: src/route.cc:745: void Router::route(): Assertion `unrouted.empty()' failed.

The following BLIF file

.model c3demo
.inputs CLK12MHZ
.outputs CLKOUT
.names $false
.names $true
1
.names $undef
.gate SB_LUT4 I0=$false I1=$true I2=divided_clock[0] I3=$false O=$0\divided_clock[7:0][0]
.attr src "/usr/local/bin/../share/yosys/ice40/arith_map.v:53"
.param LUT_INIT 0110100110010110
.gate SB_DFF C=CLK12MHZ D=$0\divided_clock[7:0][0] Q=divided_clock[0]
.attr src "c3demo.v:61|/usr/local/bin/../share/yosys/ice40/cells_map.v:2"
.gate SB_GB GLOBAL_BUFFER_OUTPUT=clk USER_SIGNAL_TO_GLOBAL_BUFFER=divided_clock[0]
.attr src "c3demo.v:64"
.names clk CLKOUT
1 1
.names $undef divided_clock[1]
1 1
.names $undef divided_clock[2]
1 1
.names $undef divided_clock[3]
1 1
.names $undef divided_clock[4]
1 1
.names $undef divided_clock[5]
1 1
.names $undef divided_clock[6]
1 1
.names $undef divided_clock[7]
1 1
.end

yields in the following error:

$ arachne-pnr -d 8k c3demo.blif
...
route...
5 -> 114959
arachne-pnr: src/route.cc:745: void Router::route(): Assertion `unrouted.empty()' failed.
Aborted

Obscure error message and core dump when PLL instance can't be routed

arachne-pnr -d 8k -P tq144:4k -p blackice-ii.pcf chip.blif -V post_place.v -o chip.txt

The error message:

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

The design mistake is that the input clock of a SB_PLL40_2F_PAD PLL is also used to clock a FF directly. Arachne should flag this as illegal.

Example attached.

issue.zip

[Windows] Error when reading the chipdb*.bin in Windows

I've cross-compiled arachne for working in windows. Everything works ok except that it cannot read the chipdb*.bin files.

This is the error I get:

arachne-pnr -d 1k -p t1.pcf t1.blif -o t1.asc
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
fatal error:std::istream::read: No error

Initially I though maybe the problem was in the paths: it could not find the chipdb-1k.bin file. So, I copy the chipdb-1k.bin into the same folder than arachne and tested it againg:

arachne-pnr -d 1k -p t1.pcf -c chipdb-1k.bin t1.blif -o t1.asc
seed: 1
device: 1k
read_chipdb chipdb-1k.bin...
fatal error:std::istream::read: No error

I tried to use the chipdb-1k.txt instead of chipdb-1k.bin and it worked:

arachne-pnr -d 1k -p t1.pcf -c chipdb-1k.txt t1.blif -o t1.asc
seed: 1
device: 1k
read_chipdb chipdb-1k.bin...
  supported packages: ......
  ....

I've checked that the generated chipdb-1k.bin files are ok (tested on linux). I've also generated the chipdb-1k.bin from Windows. But the error still remains.

Support for primitive placement constraints

Hi mates,

I am working on a FPGA project involving generating an internal clock using only a Ring Oscillator (the same as used by Clifford Wolf in his pressure-sensing project here

My issue is that, as the frequency of such oscillator depends on the propagation delay of the signals, it varies when the design is routed differently. It would be nice to be able to assign a position manually to the involved LUT's, so the frequency is preserved when other parts of the design are changed.

In the commercial IceCube utility from Lattice, this can be done by specifying the placement of the primitives in a PCF file (generated with the 'floor planner' graphical tool)

The first lines specify a "name" to the desired LUTs in the design:

###BLE List 48
ble_pack ring_osc_0 {ring_osc1.buffers[0]}
ble_pack ring_osc_1 {ring_osc1.buffers[1]}
ble_pack ring_osc_2 {ring_osc1.buffers[2]}
ble_pack ring_osc_3 {ring_osc1.buffers[3]}
ble_pack ring_osc_4 {ring_osc1.buffers[4]}
ble_pack ring_osc_5 {ring_osc1.buffers[5]}
ble_pack ring_osc_6 {ring_osc1.buffers[6]}
ble_pack ring_osc_7 {ring_osc1.buffers[7]}

Then, the LUTs are packed on groups of 8, and the position of each group is specified:

clb_pack ring_osc_clb_0 {ring_osc_0,ring_osc_1,ring_osc_2,ring_osc_3,ring_osc_4,ring_osc_5,ring_osc_6,ring_osc_7}
set_location ring_osc_clb_0 8 5

The first line packs the LUTs in the same CLB, the second line assigns the position of the CLB in the tile (8, 5)

Any ideas on how to implement this on arachne-pnr? Maybe the file pcf.cc could be modified to parse these lines, then assign the positions to the affected elements and tell the optimizer not to move them.

Apparently invalid bitstream for LVDS input

According to http://www.clifford.at/icestorm/io_tile.html for a 1K chip:

When an input pin pair is used as LVDS pair ... then the four bits IoCtrl IE_0/IE_1 and IoCtrl REN_0/REN_1 are all set, as well as the IoCtrl LVDS bit.

However, it seems that the IE and REN bits are only set for one of the pins of the LVDS pair, not both, and as a result the LVDS input does not work reliably. Setting the bits manually makes the input work reliably.

For example, with the BLIF file lvds.blif:

.model top
.inputs in
.outputs out
.names $false
.names $true
1
.names $undef
.gate SB_IO D_IN_0=x PACKAGE_PIN=in
.attr src "lvds.v:8"
.param IO_STANDARD "SB_LVDS_INPUT"
.param PIN_TYPE 000001
.gate SB_IO D_OUT_0=x PACKAGE_PIN=out
.attr src "lvds.v:13"
.end

constraints file lvds.pcf:

set_io in 34
set_io out 98

and command line:
arachne-pnr -d 1k -o lvds.asc -p lvds.pcf lvds.blif
the result in io_tile 0 2 is:

.io_tile 0 2
000000000000000000
000100000000000001
000000000000000000
000000000000000001
000000000000000000
000000000000000000
000000000000000000
000000000000000000
001000000000000000
000100000000000000
000000000000000000
000000000000000000
000000000000000000
000000000000000000
000000000000000000
000000000000000000

B1[3] and B9[3] are set, but B6[2] and B6[3], which I think should also be set, are not.

Error messages during build when downloaded as .zip

The git commands in the makefile don't work then.
I'm getting:

fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index] <path> <path>
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index] <path> <path>
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
echo "const char *version_str = \"arachne-pnr 0.1+0+0 (git sha1 , g++ `g++ --version | tr ' ()' '\n' | grep '^[0-9]' | head -n1` -O0 -fno-inline)\";" > src/version_02097.cc

It does not stop there, but continues.
It finally fails with:

g++ -Isrc -std=c++11 -MD -O0 -fno-inline -g -Wall -Wshadow -Wsign-compare -Werror  -o bin/arachne-pnr src/arachne-pnr.o src/netlist.o src/blif.o src/pack.o src/place.o src/util.o src/io.o src/route.o src/chipdb.o src/location.o src/configuration.o src/line_parser.o src/pcf.o src/global.o src/constant.o src/designstate.o src/version_02097.o -lm
make: *** No rule to make target '/usr/share/icebox/chipdb-1k.txt', needed by 'share/arachne-pnr/chipdb-1k.bin'.  Stop.

Now I'm not sure... will git clone fix it or am I missing some textfiles?

map::at: key not found

When trying to route a design using LUT instantiation, I get this error:

route...
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: map::at:  key not found

Does arachne-pnr not support cascading LUTs via the LO port of ICESTORM_LC? I've tried it with both I0 and I2, and it errors both times.

Test case:

test.v:

module test (/*AUTOARG*/
   // Outputs
   LED,
   // Inputs
   clk, pin
   ) ;
   input clk, pin;
   output [1:0] LED;
   wire [1:0]  a;
   wire [1:0]  s;
   ICESTORM_LC #(
		 .LUT_INIT('b01),
		 .DFF_ENABLE(0))
   l1(
      .I0(pin), .LO(a[0]), .O(), .CLK(clk));
   ICESTORM_LC #(
		 .LUT_INIT('b01),
		 .DFF_ENABLE(1))
   l2(
      .I0(a[0]), .LO(a[1]), .O(s[0]), .CLK(clk));
    ICESTORM_LC #(
		 .LUT_INIT('b01),
		 .DFF_ENABLE(1))
   l3(
      .I0(a[1]), .LO( ), .O(s[1]), .CLK(clk));

   assign LED = s;
endmodule // test

test.pcf:

set_io LED[0] 99
set_io LED[1] 98
set_io pin 112
set_io clk 21

built with:

yosys -p "synth_ice40 -top test -blif test.blif" test.v
arachne-pnr -p test.pcf test.blif -o test.txt

PLLs: terminate called after throwing an instance of 'std::out_of_range'

The following BLIF file

.model c3demo
.inputs CLK12MHZ
.outputs CLKOUT
.names $false
.names $true
1
.names $undef
.gate SB_PLL40_CORE BYPASS=$false DYNAMICDELAY[0]=$false DYNAMICDELAY[1]=$false DYNAMICDELAY[2]=$false DYNAMICDELAY[3]=$false DYNAMICDELAY[4]=$false DYNAMICDELAY[5]=$false DYNAMICDELAY[6]=$false DYNAMICDELAY[7]=$false EXTFEEDBACK=$false LATCHINPUTVALUE=$false LOCK=pll_lock PLLOUTCORE=PLLOUTCORE PLLOUTGLOBAL=clk REFERENCECLK=CLK12MHZ RESETB=$true
.attr src "c3demo.v:34"
.param DELAY_ADJUSTMENT_MODE_FEEDBACK "FIXED"
.param DELAY_ADJUSTMENT_MODE_RELATIVE "FIXED"
.param DIVF 00000000000000000000000000000000
.param DIVQ 00000000000000000000000000000001
.param DIVR 00000000000000000000000000001010
.param ENABLE_ICEGATE 00000000000000000000000000000000
.param FDA_FEEDBACK 00000000000000000000000000000000
.param FDA_RELATIVE 00000000000000000000000000000000
.param FEEDBACK_PATH "SIMPLE"
.param FILTER_RANGE 00000000000000000000000000000000
.param PLLOUT_SELECT "GENCLK"
.param TEST_MODE 00000000000000000000000000000000
.names clk CLKOUT
1 1
.end

and the following PCF file

set_io CLK12MHZ R9
set_io CLKOUT P14

Produce the following error:

$ arachne-pnr -d 8k -p test.pcf test.blif 
seed: 1
...
place_constraints...
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted

Typo in the short description

Hello,

The short description of the project says

Place and route tool for FGPAs

I believe it should be FPGAs instead of FGPAs.

Regards,
Thoma

fatal error: failed to place: placed 0 PLLs of 1 / 2

Hi there, hope this is the right place to post this issue.

I'm using the ice40 8k fpga and the toolchain described by @cliffordwolf.

In my project I'm using SB_IO (for bidirectional port pins on some SRAM) and SB_PLL blocks (for a fast DVID clock).

arachne-pnr fails with the above error, and the line in arachne-pnr that is failing is

https://github.com/cseed/arachne-pnr/blob/master/src/pcf.cc#L283

It is the first clause (D_IN_0 is connected) that is true and causing the fail.

I tried making an MVP to show the issue but removing unrelated parts of the project also 'fixed' it. So I have left the project as is and pushed my development branch: https://github.com/mattvenn/fpga-virtual-graf/tree/blackice

I'm a beginner with FPGAs, but my guess is that the PLL has limited options for its connectivity and these have already been used by other parts of the project. Is there a way to choose to instantiate the other PLL the 8k device has? Or am I completely wrong here.

If there is any other information needed please ask.

global network conflict PLL vs GB

When using PLL:s, arachne-pnr does not correctly handle conflicts with GB:s during placing.

Using the attached BLIF as input, arachne-pnr places a GB (for the promoted net $auto$rtlil.cc:1705:NotGate$12488$2) at (0 16), and the PLL at (16 0), causing them both to drive glb_netwk_6.

(Device 8k)
bad.blif.txt
bad.pcf.txt

Failing with "assertion failed" using SB_LVDS_INPUT

I'm trying to get the following Verilog to compile, using SB_LVDS_INPUT. I can't find any examples online aside from the Lattice PDF, which I tried to follow, but am getting a failed assertion in arachne-pnr:

module Main (
    input clk,
    output LED1,
    output LED2,
    input PIO3_02,
    input PIO3_03,
);
  reg input_0;
  reg input_180;

  // Differential input, DDR data
  SB_IO #(
    .PIN_TYPE(6'b0000_00),
    .IO_STANDARD("SB_LVDS_INPUT")
  ) differential_input (
    .PACKAGE_PIN(PIO3_02),
    .LATCH_INPUT_VALUE ( ),
    .CLOCK_ENABLE ( ),
    .INPUT_CLK (clk),
    .OUTPUT_CLK ( ),
    .OUTPUT_ENABLE ( ),
    .D_OUT_0 ( ),
    .D_OUT_1 ( ),
    .D_IN_0 (input_0),
    .D_IN_1 ()
  );

    always @(*) begin
        LED1 <= input_0;
        LED2 <= input_180;
    end
endmodule

The error it is failing with:

Assertion failed: (valid(chipdb->cell_location[c].tile())), function place_initial, file src/place.cc, line 1104.

Relevant pcf for the HX1K ship I'm using:

set_io clk 21   # 12 MHz clock
set_io --warn-no-port LED1 99  # red
set_io --warn-no-port LED2 98  # red
set_io --warn-no-port PIO3_02 1 # PIO3_02/DP00A
set_io --warn-no-port PIO3_03 2 # PIO3_02/DP00B

I've investigated the place.cc file, it fails on this clause in Placer::valid(int t):

if (g1) {
    ...
    Instance *inst1 = gates[g1];
    if (inst1->get_param("IO_STANDARD").as_string() == "SB_LVDS_INPUT")
        return false; // Fails here

I apologize if I'm overlooking something simple about how to set up a differential LVDS input on DP00A/B.

Output JSON file

I am working on rendering engine that would produce SVG image of the FPGA array with logic functions and connections between them. I know that yosys is capable of producing result in JSON format, that is greatly simplifies further processing. Would it be possible to emit PNR information in JSON format from arachne-pnr?

hx1k vq100 package not supported?

Hi,
I'm trying to use arachne to PNR a FPGA design for ice40-hx1k-vq100.
I get an error when I do the following command:
arachne-pnr -d 1k -P vq100 -p netlist.pcf top_module.blif -o top_module.asc

I found the list of options @ http://www.clifford.at/icestorm/ (see table).

This gives the following output (some output stripped to make it shorter):
...
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
supported packages: tq144
fatal error: unknown package `vq100'
Makefile:6: recipe for target 'build' failed

Looks like the VQ100 package isn't supported anymore? Or is there something wrong with my installation?
(uname -a gives: Linux mint 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux)

Thanks in advance.

SB_IO_OD doesn't work

While yosys + arachne seems to work with the RGB pins in open-drain GPIO mode by setting the pins in the pcf file and using it as a normal signal output, the results appear incorrect (pin does nothing - stay in tristate) when a SB_IO_OD block is instantiated and connected to the output.

Note that explicit SB_IO_OD instantiation is required by iCEcube, and works as expected there.

~~arachne fails with this error when running on a design with a SB_IO_OD (using the RGB pins in open-drain GPIO mode) block:~~

arachne-pnr -d 5k -P sg48 -p top.pcf build/top.blif -o build/top.asc

seed: 1
device: 5k
read_chipdb +/share/arachne-pnr/chipdb-5k.bin...
  supported packages: sg48, uwg30
read_blif build/top.blif...
prune...
read_pcf top.pcf...
instantiate_io...
pack...

After packing:
IOs          1 / 39
  IO_I3Cs    0 / 0
  IO_ODs     1 / 3
GBs          0 / 8
  GB_IOs     0 / 8
LCs          0 / 5280
  DFF        0
  CARRY      0
  CARRY, DFF 0
  DFF PASS   0
  CARRY PASS 0
BRAMs        0 / 30
WARMBOOTs    0 / 1
PLLs         0 / 1
MAC16s       0 / 8
SPRAM256KAs  0 / 4
HFOSCs       0 / 1
LFOSCs       0 / 1
RGBA_DRVs    0 / 1
LEDDA_IPs    0 / 1
I2Cs         0 / 2
SPIs         0 / 2

place_constraints...
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

The code compiles fine in iCEcube, so I'm not sure what's going on here. While arachne allows signals to be directly connected to the RGB pins, iCEcube requires that they be connected to a SB_IO_OD - so it would appear impossible to get the same code to compile through both toolchains.

module Top(
  output  foo,
);
  SB_IO_OD #(.PIN_TYPE(25), .NEG_TRIGGER(0)) SB_IO_OD (
    .PACKAGEPIN(foo),
    .DOUT0(1)
  );
endmodule

and the relevant line in the pcf file:

set_io foo 39

~Support for SB_IO_OD at all seems to be a new-ish feature, since a not-that-old version of arachne used to error out with fatal error: unknown model `SB_IO_OD'.

(separated out from #100, since this is failing to place/route with a presumably good design, instead of just a error message issue)~