yosyshq / nextpnr Goto Github PK

nextpnr portable FPGA place and route tool

License: ISC License

CMake 1.81% C++ 83.67% C 3.47% Verilog 4.25% Python 4.46% Makefile 0.02% Jupyter Notebook 0.05% Shell 0.19% Tcl 0.43% Pawn 1.29% Cap'n Proto 0.02% VHDL 0.02% Nix 0.02% Rust 0.32%

nextpnr's People

Contributors

Stargazers

Watchers

Forkers

daveshah1 eddiehung mrek mmicko ragnardanneskjold litghost g2-aj timvideos matthuszagh cr1901 pedrovanzella smunaut xobs bgamari rowhit dmsc ajeakins terrillmoore linuxperia c-elegans gwsu ossdc tomtor twam gsomlo mwkmwkmwk corecode q3k elms symbiflow xanderlent noopwafel joseppinilla jboone ric96 2php tux3 przester wieker rrika zeldin docsteer ylm jgamage91 pepijndevos 42flyingfish ingeniousone technomancer forksbot develone lucaskl newhouseb sarafs1926 se-bi laanwj zyp gojimmypi donrv garytwong ironsteel rschlaikjer tfepam miek edbordin nategraff-sifive zzrpsd kxynos mjcaisse fjardon fpgeh zhaiyif1 ravenslofty liuty10 brightclark cuijialang rroohhh johnmamish yes-uisu sunlite99 silky curioustauseef neuschaefer ucb-cs250 ezhangle haowenw zhugesima aep sylefeb marph91 pdfxy tcal-x eminsight micki0271 umarcor per-gron huangjunying yas chaney36 opensourceeda tiancsgegeburu

nextpnr's Issues

Specifying DYNAMICDELAY on iCE40 PLL may cause crash or errors.

Specifying DYNAMICDELAY on a SB_PLL40_CORE will sometimes result in a std::out_of_range exception, apparently thrown by the map in this assert.

Note that this does not always happen, but seemingly depends on how the clock is actually used, how much work is done, and the current phase of the moon.

I'm a little out of my depth here, so all I have is a repro and some observations that I can't make sense of:

Commenting out the DYNAMICDELAY results in a clean compile.
Simplifying work (e.g. replacing +1 by +0, or writing a 0 in crash_data) results in a clean compile.
Making crash_data less than 5 bits wide, or crash_counter less than 3 results in this error instead:

ERROR: no timing info for port 'DYNAMICDELAY[0]' of cell type 'SB_PLL40_CORE'

Here is the code and command line. I used Yosys and nextpnr master.

// yosys -p 'synth_ice40 -top top -json crash.json' top.v && nextpnr-ice40 --lp8k --json crash.json
module top(input CLK_16MHZ, output DATA_OUT);
wire clk;
reg [4:0] crash_data;
reg [2:0] crash_counter;
assign DATA_OUT = crash_data[crash_counter];

SB_PLL40_CORE #(.FEEDBACK_PATH("SIMPLE"), .DIVR(4'b0000), .DIVF(7'b0111111), .DIVQ(3'b100)) 
pll_inst (
    .DYNAMICDELAY(8'b0),
    .REFERENCECLK(CLK_16MHZ),
    .PLLOUTCORE(clk),
);

always @(posedge clk) begin
    crash_counter <= crash_counter + 1;
    crash_data <= !clk; // By the way, shouldn't Yosys deduce clk as a constant here? Writing a 0 compiles "cleanly".
end
endmodule

SB_RGBA_DRV support

Trying a design using the RGB drivers result in a fatal error :

ERROR: no timing info for port 'RGB0' of cell type 'SB_RGBA_DRV'

In arachne, there is a warning but it proceeds. Here this is preventing the process altogether.

Error on install

I get the following message trying to install

>cmake -DARCH=ecp5 -DTRELLIS_ROOT=/home/qubits/proj/prjtrellis  .
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.6", minimum required is "3.5") 
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   filesystem
--   thread
--   program_options
--   system
--   chrono
--   date_time
--   atomic
CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:1626 (message):
  No header defined for python-py366; skipping header check
Call Stack (most recent call first):
  CMakeLists.txt:124 (find_package)


-- Could NOT find Boost
CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:1626 (message):
  No header defined for python-py36; skipping header check
Call Stack (most recent call first):
  CMakeLists.txt:131 (find_package)


-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   python-py36
--   filesystem
--   thread
--   program_options
--   system
--   chrono
--   date_time
--   atomic
-- Configuring architecture : ecp5
-- Configuring done
-- Generating done
-- Build files have been written to: /home/qubits/proj/nextpnr

> make -j
[  2%] Built target bbasm
[  3%] Automatic MOC for target gui_ecp5
[  5%] Automatic MOC for target QtPropertyBrowser
[  6%] Generating ecp5/chipdbs/chipdb-45k.bba
[  7%] Generating ecp5/chipdbs/chipdb-25k.bba
[  9%] Generating ecp5/chipdbs/chipdb-85k.bba
[  9%] Built target gui_ecp5_autogen
[  9%] Built target QtPropertyBrowser_autogen
[ 42%] Built target gui_ecp5
[ 57%] Built target QtPropertyBrowser
Traceback (most recent call last):
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 381, in <module>
Traceback (most recent call last):
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 381, in <module>
    main()
    main()
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 347, in main
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 347, in main
    pytrellis.load_database(database.get_db_root())
    pytrellis.load_database(database.get_db_root())
RuntimeError: /home/qubits/proj/prjtrellis/database/devices.json: cannot open file
RuntimeError: /home/qubits/proj/prjtrellis/database/devices.json: cannot open file
Traceback (most recent call last):
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 381, in <module>
    main()
  File "/home/qubits/proj/nextpnr/ecp5/trellis_import.py", line 347, in main
    pytrellis.load_database(database.get_db_root())
RuntimeError: /home/qubits/proj/prjtrellis/database/devices.json: cannot open file
CMakeFiles/ecp5_chipdb.dir/build.make:79: recipe for target 'ecp5/chipdbs/chipdb-25k.bba' failed
make[2]: *** [ecp5/chipdbs/chipdb-25k.bba] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/ecp5_chipdb.dir/build.make:84: recipe for target 'ecp5/chipdbs/chipdb-45k.bba' failed
make[2]: *** [ecp5/chipdbs/chipdb-45k.bba] Error 1
CMakeFiles/ecp5_chipdb.dir/build.make:89: recipe for target 'ecp5/chipdbs/chipdb-85k.bba' failed
make[2]: *** [ecp5/chipdbs/chipdb-85k.bba] Error 1
CMakeFiles/Makefile2:143: recipe for target 'CMakeFiles/ecp5_chipdb.dir/all' failed
make[1]: *** [CMakeFiles/ecp5_chipdb.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Assertion failure: unable to find config bit ColBufCtrl.glb_netwk_0 on ICE40 LP384

terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
  what():  Assertion failure: unable to find config bit ColBufCtrl.glb_netwk_0 (/home/dlharmon/software/ice40/nextpnr/ice40/bitstream.cc:41)

I was able to reduce my project to a simple LED blinker while still getting the assertion failure. Pin number for the clock or LED doesn't seem to matter. Fortunately, I can fall back to arachne for these ICE40LP384 projects and try out nextpnr on the HX1K projects.

versions (about 12 hours old at this point)

dlharmon@dlhlaptop:~/nextpnr_assertion_failure_ColBufCtrl$ yosys -V
Yosys 0.8+46 (git sha1 5387ccb0, clang 3.8.1-24 -fPIC -Os)
dlharmon@dlhlaptop:~/nextpnr_assertion_failure_ColBufCtrl$ nextpnr-ice40 --version
nextpnr-ice40 -- Next Generation Place and Route (git sha1 15d9b3d)

top.v

module top(input clock,
           output led);

   reg [23:0]    count = 0;

   always @ (posedge clock)
        count <= count + 1'b1;

   assign led = count[23];

endmodule

constraints.pcf:

set_io led 18
set_io clock 19

Makefile

SOURCES = top.v

all: fine.asc

fine.json: $(SOURCES)
	yosys -q -p 'synth_ice40 -top top -json fine.json' $(SOURCES)

fine.asc: fine.json constraints.pcf
	nextpnr-ice40 --lp384 --json fine.json --pcf constraints.pcf --asc fine.asc

MVCE repo

https://github.com/dlharmon/nextpnr_assertion_failure_ColBufCtrl

You should be able to just run make to reproduce the failure assuming nextpnr and yosys are installed.

nextpnr-ice40 crashes when using pll block

I am using a PLL block on iCE40up5k. This causes nextpnr to crash with the following error:

Info: Packing constants..
Info: Promoting globals..
Info: Packing IOs..
Info: Packing LUT-FFs..
Info: Packing non-LUT FFs..
Info: Packing carries..
Info: Packing RAMs..
Info: Packing special functions..
terminate called after throwing an instance of 'std::out_of_range'
  what():  _Map_base::at
../main.mk:15: recipe for target 'pll_uart_mirror.asc' failed
make: *** [pll_uart_mirror.asc] Aborted (core dumped)

I have published the design that is triggering the error here: https://github.com/icebreaker-fpga/icebreaker-examples/tree/master/pll_uart

To reproduce the error just run make USE_NEXTPNR=1 in the linked directory. If I am "just doing something wrong" please let me know too. 😄

Between place and route, GUI option to draw rats nest

ice40: "Floating wire node value" message is mangled

Looks something like this:

Info: Importing module top
Info:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
, converted to zero driverInfo:       Floating wire node value, 'x' of port 'MASK' in cell 'storage.0.0.0' of module 'top'
... etc

Design

Supported input formats

More of a couple of questions than an issue.

Is the json format the only intended input format? I see that new versions of yosys can generate json, but up until now I have used blif.

Will there be any support for edf?

Is there some command I'm missing to convert blif/edf to json?

Print out stats at end of placement

E.g. Swaps attempted, swaps accepted, swap attempts per second, etc.

Hover for items in tree view and property view

Enable hover highlight when hovering over items in the tree view or properties view.

Print a slack histogram

Possibly when estimating Fmax at end of placement, as well as end of routing.

CTRL+C Exit Causes Display Driver Reset on Windows

Environment

Lenovo Thinkpad W520. Optimus is Enabled. I have a dual-monitor setup. Thanks to how the buses are laid out, Intel GFX or NVIDIA can use the built-in first monitor, but only NVIDIA is capable of using an external second monitor.

Programs

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev2, Built by MSYS2 project)

$ nextpnr-ice40 -V
nextpnr-ice40 -- Next Generation Place and Route (git sha1 2743d0f)

NVIDIA Graphics

System Information

NVIDIA claims system information is a text file, but it's really binary. So I uploaded an image as well:

Intel Graphics

Intel(R) HD Graphics 3000




Report Date:			8/1/2018
Report Time[hh:mm:ss]:		12:18:51
Driver Version:			9.17.10.3347
Operating System:		Microsoft Windows 7 Professional (6.1.7601)
Default Language:		English (United States)
DirectX* Version:		11.0
Physical Memory:		8075 MB
Processor:			Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
Processor Speed:		2192 MHz
Vendor ID:			8086
Device ID:			0126
Device Revision:		09




*   Processor Graphics Information   *


Processor Graphics in Use:		Intel(R) HD Graphics 3000
Video BIOS:			2089.1
Current Graphics Mode:		1600 by 900




*   Devices Connected to the Graphics Accelerator   *


Active Notebook Displays: 1
	*	Built-in Display	*


Monitor Name:			ThinkPad Display 1600x900
Display Type:			Digital
Gamma Value:			2.2
DDC2 Protocol:			Supported


Maximum Image Size:
Horizontal:			13.39 inches
Vertical:			07.48 inches


Monitor Supported Modes:
1600 by 900 (50 Hz)
1600 by 900 (60 Hz)



Display Power Management Support:
Standby Mode:			Supported
Suspend Mode:			Supported
Active Off Mode:		Supported


Raw EDID:
00 FF FF FF FF FF FF 00 30 AE B1 40 00 00 00 00 
00 14 01 03 80 22 13 78 EA C8 95 9E 57 54 92 26 
0F 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 
01 01 01 01 01 01 9F 25 40 7E 60 84 1E 30 30 20 
25 00 58 C2 10 00 00 19 7F 1F 40 86 60 84 1E 30 
30 20 25 00 58 C2 10 00 00 19 00 00 00 0F 00 A9 
09 32 A9 09 32 16 09 00 4C A3 4B 54 00 00 00 FE 
00 4C 54 4E 31 35 36 4B 54 30 32 34 30 31 00 8B 


* Other names and brands are the property of their respective owners. *

Steps to Duplicate

Run nextpnr-ice40 --gui from MSYS2/MinGW64 bash.
Drag and move the window slightly while keeping it on the second monitor. This is the most consistent way to reproduce the reset. See Other Information.
Send CTRL+C to bash

Expected Behavior

CTRL+C exit would exit cleanly just like when closing the window manually by clicking "X". (Note: Clicking the "X" works fine.)

Actual Behavior

Unfortunately, I was unable to get a backtrace from this...

Other Information

It is slightly inconsistent when I am able to get a driver reset:

Not dragging the window on the second monitor before sending CTRL+C seems to result in a clean exit. At least, I don't remember triggering any crashes during testing.
Rarely, I will get a driver reset if I CTRL+C while nextpnr is on my first monitor. I'm unsure how to consistently duplicate this.
If I do not get a driver reset if I CTRL+C while nextpnr is on my first monitor, the next invocation of nextpnr where I drag the window and then CTRL+C while nextpnr is on the second monitor will not cause a driver reset. This is weird for me, considering NVIDIA GFX card must be using the second monitor on the Thinkpad W520.

ice40: PACKER_VCC appears on critical path

E.g. this report, trivial to reproduce:

Info: Critical path report:
Info: curr total
Info:  0.0  0.0  Source $PACKER_VCC.O
Info:  6.3  6.3    Net $PACKER_VCC_NET budget 2.777000 ns (11,1) -> (12,31)
Info:                 Sink $gbuf_$PACKER_VCC_NET_$glb_clk.USER_SIGNAL_TO_GLOBAL_BUFFER
Info:  0.0  6.3  Source $gbuf_$PACKER_VCC_NET_$glb_clk.GLOBAL_BUFFER_OUTPUT
Info:  6.8 13.1    Net $PACKER_VCC_NET_$glb_clk budget 2.777000 ns (12,31) -> (10,28)
Info:                 Sink $auto$alumacc.cc:474:replace_alu$1660.slice[1].carry$CARRY.I1
(etc)

I understand that it has the enormous 6.3 ns delay because it's a single 1'b1 net for the entire chip, but that shouldn't matter if you have a reset, and so I think it shouldn't contribute to timing.

Smarter initial placement for ice40

I have a design that fails initial placement. This is mostly because of incompatible CE lines for the flipflops and it is for a LP384 which doesn't have a lot of resources and I'm trying to pack 330 LCs in there.

icecube2 does produce a valid and working bitstream, so that design can definitely fit. But looking at the output, it seems that the synthesizer of icecube 2 also produces a slightly smaller result, so this might help as well.

Anyway, what I've been toying with is to add a int Arch::scoreBelForCell(CellInfo *cell, BelId bel) const method that returns a "score" of how good a BEL is for a CELL. and then I use that score in the initial placement instead of random.

Currently my attempt looks like this :

int Arch::scoreBelForCell(CellInfo *cell, BelId bel) const
{       
    /* Only process LC */
    if (cell->type != id_ICESTORM_LC)
        return 0;
    
    NPNR_ASSERT(getBelType(bel) == id_ICESTORM_LC);
        
    /* If the cell doesn't have any FF, no preferences */
    if (!cell->lcInfo.dffEnable)
        return 8;

    /* If the cell has a FF, then count how many bels would be used in that slice */
    size_t num_cells = 0; 

    Loc bel_loc = getBelLocation(bel);
    for (auto bel_other : getBelsByTile(bel_loc.x, bel_loc.y)) {
        CellInfo *ci_other = getBoundBelCell(bel_other);
        if (ci_other != nullptr && bel_other != bel)
            num_cells++;
    }

    return 8 - num_cells;
}

Basically if the cell has flipflops, it will try to pack it in the same slice as other cells that have the same constraints. If the cell doesn't have a FF, then doesn't matter, it can get ripped up and replaced somewhere else if needed.

This does help. I went from finding placement for only ~ 230 LCs to about 320 LCs. Still not enough for my design though.

Using `PLLOUTGLOBAL` on PLL results in :Assertion failure"

Actual Behavior

The following Verilog module:

William@William-THINK MINGW64 ~/src/tinyfpga-soc
$ cat pll-crash/build/top.v
/* Machine-generated using Migen */
module top(
        input clk16,
        output out
);

wire sys_clk;
wire clk16_1;
wire clk32;


// Adding a dummy event (using a dummy signal 'dummy_s') to get the simulator
// to run the combinatorial process once at the beginning.
// synthesis translate_off
reg dummy_s;
initial dummy_s <= 1'd0;
// synthesis translate_on

assign clk16_1 = clk16;
assign out = sys_clk;

SB_PLL40_CORE #(
        .DIVF(6'd63),
        .DIVQ(3'd5),
        .DIVR(1'd0),
        .FILTER_RANGE(3'd1)
) SB_PLL40_CORE (
        .REFERENCECLK(clk16_1),
        .RESETB(1'd1),
        .PLLOUTGLOBAL(clk32)
);

SB_GB SB_GB(
        .USER_SIGNAL_TO_GLOBAL_BUFFER(clk32),
        .GLOBAL_BUFFER_OUTPUT(sys_clk)
);

endmodule

results in the following assertion failure:

William@William-THINK MINGW64 ~/src/tinyfpga-soc/pll-crash
$ python3 pll-crash.py
Warning: Found one of those horrible `(synopsys|synthesis) translate_off' comments.
Yosys does support them but it is recommended to use `ifdef constructs instead!
Info: Importing module top
Info: Rule checker, Verifying pre-placed design
Info: Checksum: 0x191aa3eb

Info: constrained 'clk16' to bel 'X9/Y33/io0'
Info: constrained 'out' to bel 'X0/Y30/io0'

Info: Packing constants..
Info: Promoting globals..
Info: Packing IOs..
Info: Packing LUT-FFs..
Info: Packing non-LUT FFs..
Info: Packing carries..
Info: Packing RAMs..
Info: Packing special functions..
Warning: PLL 'SB_PLL40_CORE' has unknown connected port 'PLLOUTGLOBAL' - ignoring
Info:   constrained PLL 'SB_PLL40_CORE_PLL' to X16/Y0/pll_3
Info:   constrained PLL 'SB_PLL40_CORE_PLL' to X16/Y33/pll_3
Info: Constraining chains...
Info: Checksum: 0x28c010d3

Info: Annotating ports with timing budgets for target frequency 16.00 MHz

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
  what():  Assertion failure: port_fanin.empty() (../common/timing.cc:167)

Expected behavior

PLLOUTGLOBAL followed by SB_GB should be supported in nextpnr, even if it's an obsolete hint (?) to the pnr tool.

Other information

William@William-THINK MINGW64 ~/src/tinyfpga-soc
$ uname -a
MINGW64_NT-6.1 William-THINK 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 Msys

MCVE

I have provided an MCVE: pll-crash.zip

ERROR: No wire found for port PACKAGE_PIN on destination cell SB_IO.

I'm getting the following error when compiling a design;

Info: Routing..
ERROR: No wire found for port PACKAGE_PIN on destination cell SB_IO_1.
ERROR: Routing design failed.

I'm not sure what it means? I think the important verilog is below;

module top(
	input clk16,
	output reg spiflash_cs_n,
	output reg spiflash_clk,
	output reg spiflash_mosi,
	input spiflash_miso,
	output spiflash_wp,
	output spiflash_hold,
	input serial_rx,
	output reg serial_tx,
	inout usb_d_p,
	inout usb_d_n,
	output usb_pullup,
	output user_led0
);

SB_IO #(
	.PIN_TYPE(6'b101001),
	.PULLUP(1'd0)
) SB_IO_1 (
	.D_OUT_0(usbdevice_usb_n_tx),
	.OUTPUT_ENABLE(usbdevice_usb_tx_en),
	.PACKAGE_PIN(usb_d_n),
	.D_IN_0(usbdevice_usb_n_rx_io)
);

I've also included the full test case in the following zip file: wire-package-pin.zip

File dialogs don't work on Xubuntu 18.04 inside VirtualBox

Hi!

I just compiled nextpnr from git on Xubuntu 18.04 running in VirtualBox. (simple cmake -DARCH=ice40 . , make, sudo make install).

If I start nextpnr-ice40 --gui, and click on File-> Open, the window frame appears, but without contents. Application freezes until I close the window.

Console says:
Gtk-Message: 21:18:59.190: GtkDialog mapped without a transient parent. This is discouraged.

Is there anything I can do to help debugging this?

best regards,
Thomas

Project mode with CLI

The project mode seems quite handy for FuseSoC. My idea is to generate a project file with all required properties and then let the user open it in the GUI or use it on the command-line to generate the bitstream with just the project file as input (This is how many of the other tool backends are implemented).

I can't figure out how to use project files on the command-line though. nextpnr-ice40 --load blinky.proj just seems to load the file and then exit (also, adding --gui doesn't do anything when --load is used).

Loading Sample Blinky Project From GUI Causes SIGTRAP on MinGW64 Windows

Environment

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev2, Built by MSYS2 project)

$ nextpnr-ice40 -V
nextpnr-ice40 -- Next Generation Place and Route (git sha1 2743d0f)

Steps to Duplicate

Run nextpnr-ice40 --gui from MSYS2/MinGW64 bash
File > Open > blinky.proj

(For the file dialog, navigate to the ice40 directory inside the nextpnr source tree)

Expected Behavior

No SIGTRAP.

Actual Behavior

Application immediately closes with "Segmentation Fault".

Backtrace/SIGTRAP source is here: http://ix.io/1iV0

`nextpnr-ice40` is failing to route PLL clock

Actual Behavior

The following Verilog module:

/* Machine-generated using Migen */
module top(
	input clk16,
	input usb_d_p,
	input usb_d_n,
	output usb_pullup,
	output user_led
);

wire sys_clk;
reg sys_rst = 1'd0;
wire clk16_1;
wire clk16b;
reg [23:0] count = 24'd0;


// Adding a dummy event (using a dummy signal 'dummy_s') to get the simulator
// to run the combinatorial process once at the beginning.
// synthesis translate_off
reg dummy_s;
initial dummy_s <= 1'd0;
// synthesis translate_on

assign clk16_1 = clk16;
assign usb_pullup = 1'd0;
assign user_led = count[22];

always @(posedge sys_clk) begin
	count <= (count + 1'd1);
	if (sys_rst) begin
		count <= 24'd0;
	end
end

SB_PLL40_CORE #(
	.DIVF(6'd63),
	.DIVQ(3'd6),
	.DIVR(1'd0),
	.FILTER_RANGE(3'd1)
) SB_PLL40_CORE (
	.REFERENCECLK(clk16_1),
	.RESETB(1'd1),
	.PLLOUTCORE(clk16b)
);

SB_GB SB_GB(
	.USER_SIGNAL_TO_GLOBAL_BUFFER(clk16b),
	.GLOBAL_BUFFER_OUTPUT(sys_clk)
);

results in a design which passes timing according to nextpnr, but results in a nonfunctional bitstream (no LED blinking). Modifying the above Verilog module to remove the PLL and route the system clock directly to the logic creates a functional bitstream (LED blinking). I have reproduced it below:

/* Machine-generated using Migen */
module top(
	input clk16,
	input usb_d_p,
	input usb_d_n,
	output usb_pullup,
	output user_led
);

wire sys_clk;
reg sys_rst = 1'd0;
wire clk16_1;
reg [23:0] count = 24'd0;


// Adding a dummy event (using a dummy signal 'dummy_s') to get the simulator
// to run the combinatorial process once at the beginning.
// synthesis translate_off
reg dummy_s;
initial dummy_s <= 1'd0;
// synthesis translate_on

assign sys_clk = clk16_1;
assign clk16_1 = clk16;
assign usb_pullup = 1'd0;
assign user_led = count[22];

always @(posedge sys_clk) begin
	count <= (count + 1'd1);
	if (sys_rst) begin
		count <= 24'd0;
	end
end

endmodule

Expected behavior

As both the above modules are driven by a 16MHz clock- one from the PLL output, the other from a pin- I would expect the above two modules to behave identically.

Other information

William@William-THINK MINGW64 ~/src/tinyfpga-soc
$ uname -a
MINGW64_NT-6.1 William-THINK 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 Msys

MCVE

MVCE is here: pll-crash2.zip

Support ports forming both register and combinational inputs in cells

The current timing visitor will stop at a port once it is determined to be a register input (getPortClock != IdString()). This doesn't work for ports that may be both, such as ECP5 slice inputs, or iCE40 LUT inputs with LUTCascade/carries.

Instead, it should keep looking for further paths if there are any more outputs with a direct timing path getCellDelay returning true.

Relevant code

    if (ctx->getPortClock(user.cell, user.port) != IdString()) {
        // At the end of a timing path (arguably, should check setup time
        // here too)
        value = slack / path_length;
        if (slack < min_slack) {
            min_slack = slack;
            if (crit_path)
                *crit_path = *current_path;
        }
    } else {
        // Default to the path ending here, if no further paths found
        value = slack / path_length;
        // Follow outputs of the user
        for (auto port : user.cell->ports) {
            if (port.second.type == PORT_OUT) {
                DelayInfo comb_delay;
                // Look up delay through this path
                bool is_path = ctx->getCellDelay(user.cell, user.port, port.first, comb_delay);
                if (is_path) {
                    NetInfo *net = port.second.net;
                    if (net) {
                        delay_t path_budget = follow_net(ctx, net, path_length, slack - comb_delay.maxDelay(), update,
                                                         min_slack, current_path, crit_path);
                        value = std::min(value, path_budget);
                    }
                }
            }
        }
    }

Disable readline support?

Is there a way to disable building with readline support? Is -DENABLE_READLINE=No enough?

Timing analysis cannot cope with combinatorial loops

git clone https://github.com/SolraBizna/friedice
cd friedice
make bin/friedup.asc

Somewhere in that spaghetti bowl of unpipelined logic is yet another edge case that ends up triggering this assert:

terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
  what():  Assertion failure: port_fanin.empty() (/home/sbizna/nextpnr/common/timing.cc:170)

This code is difficult to gradually reduce to a minimal test case, because it's all so horribly entangled. All I can say for sure is that the problem lies in src/friedice.v or src/register_file.v.

Duplicate pin constraint error missing

When the .pcf file contains multiple constraints for the same pin nextpnr produces a cryptic assertion:

terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
  what():  Assertion failure: bel_to_cell[bel.index] == nullptr ([redacted]/nextpnr-git/ice40/arch.h:440)
Makefile:17: recipe for target 'hyperram.asc' failed
make: *** [hyperram.asc] Aborted (core dumped)

Arachnepnr produces a much more useful error:

read_pcf icebreaker.pcf...
icebreaker.pcf:24: fatal error: duplicate pin constraints for pin `36'
Makefile:20: recipe for target 'hyperram.asc' failed
make: *** [hyperram.asc] Error 1

Implement hold timing analysis and satisfaction

Current line of thinking:

Add hold "budget" to each PortRef, distribute hold time from each path endpoint evenly across all nets on the path (like setup budget)
Adapt router to account for this minimum delay requirement

Running Pack From GUI Results in SIGSEGV on MinGW64 Windows

Environment

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev2, Built by MSYS2 project)

$ nextpnr-ice40 -V
nextpnr-ice40 -- Next Generation Place and Route (git sha1 2743d0f)

Steps to Duplicate

Run nextpnr-ice40 --gui from MSYS2/MinGW64 bash
Design > Open JSON > blinky.json
Design > Open PCF > blinky.pcf
Design > Pack

(For each file dialog, navigate to the ice40 directory inside the nextpnr source tree)

Expected Behavior

No SIGSEGV

Actual Behavior

Packing starts but soon (~1-2 seconds) results in a "Segmentation Fault" and the application closes.

Backtrace/SIGSEGV source is here (ignore the extra --asc option): http://ix.io/1iUS

Document ICEBOX_ROOT parameter to cmake

I can't find any documentation for the fact you can use ICEBOX_ROOT to specify where to find the icebox files?

Feature request: --quiet mode

Most of the time, Glasgow designs will place and route successfully and within reasonable time, so progress messages aren't very interesting. The only really interesting part is Fmax. It'd be nice if nextpnr had a mode like arachne-pnr -q which only kept errors on console (but still wrote them to a logfile).

Improve slack redistribution for timing improvement

Currently, the --slack_redist_iter # option runs slack redistribution every # placement and routing iterations.

This operation walks all clock-to-clock paths in an attempt to:

(on its forward pass) compute the path slack, based on the current target Fmax
(on its backward pass) distribute this path slack evenly between all the net budgets on this path, where budget = std::min(budget, net_delay + path_slack/path_length)
(on its forward pass) record the minimum path slack across all paths, for possible use in computing next target Fmax (if --freq 0 specified)

Currently, enabling slack redistribution does not appear to return a significant timing improvement. Perhaps something more intelligent than evenly distributing any slack surplus may be beneficial...?

Slower timing results with higher frequency target

I am building picosoc for ice40up5k and getting strange results.

When running nextpnr with a 13mhz target it produces an asc with 10.91 MHz fmax according to nextpnr and 11.99 MHz according to icetime. On the other hand when running nextpnr with 12mhz target it produces an asc with 12.05 MHz fmax according to nextpnr and 12.15 MHz according to icetime.
I have uploaded a bunch of files including output logs, and asc files for reference: http://esden.net/blubb/picosoc/2018_09_04/
Yosys version: Yosys 0.7+650 (git sha1 4d269f9b, clang 6.0.0-1ubuntu2 -fPIC -Os)
nextpnr version: nextpnr-ice40 -- Next Generation Place and Route (git sha1 61b1a75)
icestorm version built from: sha 52f91d92

Let me know if you need any additional information.

Hover doesn work with lines that span an entire tile

iCE40 IO tiles contain lines that span the entire tile. For some reason hover doesn't work for those lines: https://imgur.com/a/nayWuzA

Negative integer in JSON causes error

This snippet of the attached JSON (on line 21643, generated by Yosys):

        "$abc$529$auto$blifparse.cc:465:parse_blif$538": {
          "hide_name": 1,
          "type": "LUT5",
          "parameters": {
            "INIT": -2147483648
          },

causes nextpnr to issue the following error:

ERROR: Unexpected character in JSON file: '-'
ERROR: Loading design failed.

blinky.json.txt -- GH no likey *.json

Tasks:

Fix this?
Provide better error messages, e.g. a line number

I dug into Yosys, and it's policy is that if the number of bits in a parameter (INIT) is less than 32 bits, then its value is output as an integer. Any more, then a string is used. Whether INIT can/should be marked as an unsigned integer in Yosys may be something that @cliffordwolf can chime in... (but regardless task 2 remains valid!)

Use of an SB_GB_IO fails with error -- works under arachne-pnr

rebuilding a known-to-work in arachne-pnr design, I get an error:

ERROR: no timing info for port 'GLOBAL_BUFFER_OUTPUT' of cell type 'SB_GB_IO'

And then it stops. Is SB_GB_IO not supported yet?

FPGA feature licensing?

How (if at all) will using an open source toolchain impact the licensing of FPGA features?

For a specific example, will it be necessary to pay for a license to use the SerDes capability of ECP5/ECP5-5G family chips?

I believe I read that some of these features have to be licensed separately and I am not sure if that is a license to enable the silicon or to use the design tools.

"Zoom Selected" doesn't work with fabout net

Steps to reproduce:

Launch nextpnr-ice40 --gui
Type fabout in search bar and press ENTER
Click Zoom Selected icon

Typing local instead of fabout will select and zoom to a local net.

GUI CPU usage

Just running ../nextpnr-ice40 --hx8k --gui (without loading a design or doing anything) already has a pretty high CPU usage.

Speed up placer by performing incremental cost updates

Based on this profile it appears that 86% of total runtime is spent inside placement, and 47% of total runtime is spent inside get_net_metric() which is responsible for computing the cost of a swap.

Instead of computing the half-perimeter-wire-length (HPWL) and worst-slack from scratch for every pin of every net of every affected cell, perhaps an incremental update can be performed? For example:

if a pin is moved entirely inside the existing HPWL, then there's no need to recompute scratch
if a pin does not currently have the worst-slack of the net, and does not increase the worst-slack, then no need to recompute from scratch
etc.

-DSTATIC_BUILD=ON fails trying to link libpython3.6m.so

Command line I'm using is;
cmake -DARCH=ice40 -DBUILD_GUI=OFF -DSTATIC_BUILD=ON -DICEBOX_ROOT=${PREFIX}/share/icebox .

Revision 474aa34

/home/tansell/conda/conda-bld/nextpnr_1537154254666/_build_env/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: attempted static link of dynamic object `/home/tansell/conda/conda-bld/nextpnr_1537154254666/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/libpython3.6m.so'

Critical paths with multiple global buffers

I see critical paths like the following:

Info: Critical path report:
Info: curr total
Info:  1.4  1.4  Source $auto$simplemap.cc:420:simplemap_dff$2753_DFFLC.O
Info:  1.8  3.2    Net qmem_done budget 0.618000 ns (12,9) -> (12,9)
Info:                 Sink $abc$14511$auto$blifparse.cc:492:parse_blif$14726_LC.I3
Info:  0.0  3.2  Source $abc$14511$auto$blifparse.cc:492:parse_blif$14726_LC.O
Info:  5.0  8.1    Net mem_client_qmem budget 1.856000 ns (12,9) -> (13,31)
Info:                 Sink $gbuf_mem_client_qmem_$glb_clk.USER_SIGNAL_TO_GLOBAL_BUFFER
Info:  0.0  8.1  Source $gbuf_mem_client_qmem_$glb_clk.GLOBAL_BUFFER_OUTPUT
Info:  1.8  9.9    Net mem_client_qmem_$glb_clk budget 1.856000 ns (13,31) -> (13,6)
Info:                 Sink $abc$14511$auto$blifparse.cc:492:parse_blif$14728_LC.I3
Info:  0.9 10.8  Source $abc$14511$auto$blifparse.cc:492:parse_blif$14728_LC.O
Info:  2.8 13.6    Net mem_addr[0] budget 1.856000 ns (13,6) -> (10,6)
Info:                 Sink $abc$14511$auto$blifparse.cc:492:parse_blif$15156_LC.I0
Info:  1.3 14.9  Source $abc$14511$auto$blifparse.cc:492:parse_blif$15156_LC.O
Info:  2.3 17.2    Net $abc$14511$n1856 budget 2.386000 ns (10,6) -> (8,6)
Info:                 Sink $auto$alumacc.cc:474:replace_alu$1146.slice[0].adder_LC.I2
Info:  0.0 17.2  Source $auto$alumacc.cc:474:replace_alu$1146.slice[0].adder_LC.O
Info:  6.8 24.0    Net mem.shamt[0] budget 2.386000 ns (8,6) -> (19,31)
Info:                 Sink $gbuf_mem.shamt[0]_$glb_clk.USER_SIGNAL_TO_GLOBAL_BUFFER
Info:  0.0 24.0  Source $gbuf_mem.shamt[0]_$glb_clk.GLOBAL_BUFFER_OUTPUT
Info:  4.4 28.4    Net mem.shamt[0]_$glb_clk budget 2.394000 ns (19,31) -> (22,1)
Info:                 Sink $abc$14511$auto$blifparse.cc:492:parse_blif$14739_LC.I0
Info:  1.3 29.7  Source $abc$14511$auto$blifparse.cc:492:parse_blif$14739_LC.O
Info:  2.3 32.0    Net mem.shifted_wen[1] budget 2.394000 ns (22,1) -> (24,1)
Info:                 Sink $abc$14511$auto$blifparse.cc:492:parse_blif$14741_LC.I0
Info:  0.0 32.0  Source $abc$14511$auto$blifparse.cc:492:parse_blif$14741_LC.O
Info:  3.0 34.9    Net $abc$14511$n479 budget 2.394000 ns (24,1) -> (25,0)
Info:                 Sink mem.ram[0].spram_RAM.WREN

Maybe we should make sure not to place global buffers in the input- or output-cone of another global buffer when promoting signals. (Also, we should probably provide an option to disable automatic gbuf promotion of logic signal.)

`Assertion Failure` when routing using clock pin multiple times.

Actual Behavior

The following Verilog module:

william@xubuntu-dtrain:~/Projects/migen_up5k$ cat conn-crash/conn-crash/conn-crash.v
/* Machine-generated using Migen */
module top(
        output sevenseg_segment7,
        output sevenseg_segment6,
        output sevenseg_segment5,
        output sevenseg_segment4,
        output sevenseg_segment3,
        output sevenseg_segment2,
        output sevenseg_segment1,
        output sevenseg_enable0,
        input clk12
);

wire sys_clk;
wire sys_rst;
wire por_clk;
reg int_rst = 1'd1;


// Adding a dummy event (using a dummy signal 'dummy_s') to get the simulator
// to run the combinatorial process once at the beginning.
// synthesis translate_off
reg dummy_s;
initial dummy_s <= 1'd0;
// synthesis translate_on

assign sevenseg_enable0 = 1'd1;
assign sevenseg_segment7 = 1'd1;
assign sevenseg_segment6 = 1'd1;
assign sevenseg_segment5 = 1'd1;
assign sevenseg_segment4 = 1'd1;
assign sevenseg_segment3 = 1'd1;
assign sevenseg_segment2 = 1'd1;
assign sevenseg_segment1 = 1'd1;
assign sys_clk = clk12;
assign por_clk = clk12;
assign sys_rst = int_rst;

always @(posedge por_clk) begin
        int_rst <= 1'd0;
end

endmodule

and the following (erroneous!) PCF:

set_io sevenseg_segment7 32
set_io sevenseg_segment6 38
set_io sevenseg_segment5 31
set_io sevenseg_segment4 28
set_io sevenseg_segment3 37
set_io sevenseg_segment2 35
set_io sevenseg_segment1 34
set_io sevenseg_enable0 43
set_io clk12 35

results in the following assertion failure:

william@xubuntu-dtrain:~/Projects/migen_up5k/conn-crash$ python3 conn-crash.py
Warning: Found one of those horrible `(synopsys|synthesis) translate_off' comments.
Yosys does support them but it is recommended to use `ifdef constructs instead!
Info: Importing module top
Info: Rule checker, Verifying pre-placed design
Info: Checksum: 0x032fdd82

Info: constrained 'sevenseg_segment7' to bel 'X16/Y31/io0'
Info: constrained 'sevenseg_segment6' to bel 'X8/Y31/io1'
Info: constrained 'sevenseg_segment5' to bel 'X16/Y31/io1'
Info: constrained 'sevenseg_segment4' to bel 'X17/Y31/io0'
Info: constrained 'sevenseg_segment3' to bel 'X13/Y31/io0'
Info: constrained 'sevenseg_segment2' to bel 'X12/Y31/io1'
Info: constrained 'sevenseg_segment1' to bel 'X13/Y31/io1'
Info: constrained 'sevenseg_enable0' to bel 'X9/Y31/io0'
Info: constrained 'clk12' to bel 'X12/Y31/io1'

Info: Packing constants..
Info: Promoting globals..
Info: Packing IOs..
Info: Packing LUT-FFs..
Info: Packing non-LUT FFs..
Info: Packing carries..
Info: Packing RAMs..
Info: Packing special functions..
Info: Constraining chains...
Info: Checksum: 0x779074fe

Info: Annotating ports with timing budgets for target frequency 12.00 MHz
Info: Checksum: 0xfa41405b

Info: Device utilisation:
Info:            ICESTORM_LC:     1/ 5280     0%
Info:           ICESTORM_RAM:     0/   30     0%
Info:                  SB_IO:     9/   96     9%
Info:                  SB_GB:     0/    8     0%
Info:           ICESTORM_PLL:     0/    1     0%
Info:            SB_WARMBOOT:     0/    1     0%
Info:           ICESTORM_DSP:     0/    8     0%
Info:         ICESTORM_HFOSC:     0/    1     0%
Info:         ICESTORM_LFOSC:     0/    1     0%
Info:                 SB_I2C:     0/    2     0%
Info:                 SB_SPI:     0/    2     0%
Info:                 IO_I3C:     0/    2     0%
Info:            SB_LEDDA_IP:     0/    1     0%
Info:            SB_RGBA_DRV:     0/    1     0%
Info:         ICESTORM_SPRAM:     0/    4     0%

terminate called after throwing an instance of 'nextpnr_ice40::assertion_failure'
  what():  Assertion failure: bel_to_cell[bel.index] == nullptr (/home/william/Projects/nextpnr/ice40/arch.h:440)
build_conn-crash.sh: line 5: 10951 Aborted                 (core dumped) nextpnr-ice40 --up5k --package sg48 --pcf conn-crash.pcf --json conn-crash.json --asc conn-crash.txt --freq 12.000048000192
Traceback (most recent call last):
  File "conn-crash.py", line 68, in <module>
    plat.build(m, run=True, build_dir="conn-crash", build_name="conn-crash")
  File "/home/william/Projects/migen/migen/build/lattice/platform.py", line 27, in build
    return self.toolchain.build(self, *args, **kwargs)
  File "/home/william/Projects/migen/migen/build/lattice/icestorm.py", line 175, in build
    _run_script(script)
  File "/home/william/Projects/migen/migen/build/lattice/icestorm.py", line 68, in _run_script
    raise OSError("Subprocess failed")
OSError: Subprocess failed

Expected behavior

Design should fail to route with an error message, rather than trigger an assertion failure; I accidentally used a clock input multiple times when generating the Verilog code.

Other information

william@xubuntu-dtrain:~/Projects/migen_up5k/conn-crash$ uname -a
Linux xubuntu-dtrain 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

commit 96efe48847dbf7f25f97b6059dacacd33fde4bec (HEAD -> master, origin/master, origin/HEAD)

MCVE

I have provided an MCVE: conn-crash.zip
Note: The Python script depends on migen features for which I haven't made a PR/pushed yet, and so will not work in general.

GUI startup segmentation fault on OS X

On OS X 10.13.6 (High Sierra) I get a segmentation fault when running nextpnr-ice40 (0208897).

I am running the example from the GitHub repo.

nextpnr-ice40 --json blinky.json --pcf blinky.pcf --asc blinky.asc --gui

I can "fix" the issue by commenting out line basewindow.cc:81

centralTabWidget->tabBar()->tabButton(0, QTabBar::RightSide)->resize(0, 0);

Poking about with LLDB indicates that tabButton() is returning NULL for QTabBar::RightSide. If it is passed LeftSide then a value is returned.

Here is the stack trace for the issue.

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x0000000109c6bc30 QtWidgets`QWidget::resize(QSize const&) + 16
    frame #1: 0x00000001000c36de nextpnr-ice40`nextpnr_ice40::BaseMainWindow::BaseMainWindow(std::__1::unique_ptr<nextpnr_ice40::Context, std::__1::default_delete<nextpnr_ice40::Context> >, QWidget*) [inlined] QWidget::resize(this=<unavailable>, w=0, h=0) at qwidget.h:838 [opt]
    frame #2: 0x00000001000c36ca nextpnr-ice40`nextpnr_ice40::BaseMainWindow::BaseMainWindow(this=0x00007ffeefbff150, context=<unavailable>, parent=<unavailable>) at basewindow.cc:81 [opt]
    frame #3: 0x00000001000e91b2 nextpnr-ice40`nextpnr_ice40::MainWindow::MainWindow(this=0x00007ffeefbff150, context=<unavailable>, args=(type = HX1K, package = "tq144"), parent=<unavailable>) at mainwindow.cc:40 [opt]
    frame #4: 0x0000000100097e07 nextpnr-ice40`main(argc=<unavailable>, argv=<unavailable>) at main.cc:396 [opt]
    frame #5: 0x00007fff6762e015 libdyld.dylib`start + 1

Regression from arachnepnr: failure to route SB_PLL40_2_PAD

Below is a test of using SB_PLL40_2_PAD which provides both the original clock and the synthesized clock via globals. This works in iceCube2 and with arachne-pnr but fails with nextpnr with:
ERROR: PLL 'pll0.pll_inst' is using multiple ports mapping to PLLOUT_A output of the PLL

pll-test.tar.gz

pll-test.sh

#!/bin/sh
set -ex

yosys -p 'synth_ice40 -top top -blif pll-test.blif -json pll-test.json' pll-test.v

# this succeeds
arachne-pnr -d 5k -p sg48 -o pll-test-apnr.asc -p pll-test.pcf pll-test.blif

# this fails
# ERROR: PLL 'pll0.pll_inst' is using multiple ports mapping to PLLOUT_A output of the PLL
nextpnr-ice40 --package sg48 --up5k --pcf pll-test.pcf --asc pll-test-npnr.asc --json pll-test.json

pll-test.pcf

set_io clk12m_in 35

set_io out1 3
set_io out2 4

pll-test.v

// instantiate pll with both original and generated clocks available
// pass clocks to test points out1, out2

module top(
	input clk12m_in,
	output out1,
	output out2
	);

wire clk25m;
wire clk12m;

pll pll0(
	.PACKAGEPIN(clk12m_in),
	.PLLOUTGLOBALA(clk12m),
	.PLLOUTGLOBALB(clk25m),
	.PLLOUTCOREA(),
	.PLLOUTCOREB(),
	.LOCK(),
	.RESET(1'b1)
	);

assign out1 = clk25m;
assign out2 = clk12m;

endmodule


// below generated by lattice icecube2

module pll(PACKAGEPIN,
           PLLOUTCOREA,
           PLLOUTCOREB,
           PLLOUTGLOBALA,
           PLLOUTGLOBALB,
           RESET,
           LOCK);

inout PACKAGEPIN;
input RESET;    /* To initialize the simulation properly, the RESET signal (Active Low) must be asserted at the beginning of the simulation */ 
output PLLOUTCOREA;
output PLLOUTCOREB;
output PLLOUTGLOBALA;
output PLLOUTGLOBALB;
output LOCK;

SB_PLL40_2_PAD pll_inst(.PACKAGEPIN(PACKAGEPIN),
                        .PLLOUTCOREA(PLLOUTCOREA),
                        .PLLOUTCOREB(PLLOUTCOREB),
                        .PLLOUTGLOBALA(PLLOUTGLOBALA),
                        .PLLOUTGLOBALB(PLLOUTGLOBALB),
                        .EXTFEEDBACK(),
                        .DYNAMICDELAY(),
                        .RESETB(RESET),
                        .BYPASS(1'b0),
                        .LATCHINPUTVALUE(),
                        .LOCK(LOCK),
                        .SDI(),
                        .SDO(),
                        .SCLK());

//\\ Fin=12, Fout=25;
defparam pll_inst.DIVR = 4'b0000;
defparam pll_inst.DIVF = 7'b1000010;
defparam pll_inst.DIVQ = 3'b101;
defparam pll_inst.FILTER_RANGE = 3'b001;
defparam pll_inst.FEEDBACK_PATH = "SIMPLE";
defparam pll_inst.DELAY_ADJUSTMENT_MODE_FEEDBACK = "FIXED";
defparam pll_inst.FDA_FEEDBACK = 4'b0000;
defparam pll_inst.SHIFTREG_DIV_MODE = 2'b00;
defparam pll_inst.PLLOUT_SELECT_PORTB = "GENCLK";
defparam pll_inst.ENABLE_ICEGATE_PORTA = 1'b0;
defparam pll_inst.ENABLE_ICEGATE_PORTB = 1'b0;

endmodule

Consider GraphicElement semantics to be "struct of vectors" instead of "vector of struct"

Right now GraphicElement is defined as


struct GraphicElement
{
    enum type_t
    {…
    } type = TYPE_NONE;

    enum style_t
    {…
    } style = STYLE_FRAME;

    float x1 = 0, y1 = 0, x2 = 0, y2 = 0, z = 0;
    std::string text;
};

and at various places a vector of this struct is used. In the context of graphics programming this is considered an anti-pattern since it prevents the direct use of the data relevant for graphics operation and mandates the creation of intermediary coalesce-copies (a larger part of fpgawidget.cc is concerned with coalescing the graphics data).

A better approach would be to have a

enum style_t {…};
struct GraphicElements {
    std::vector<int16_t> style;
    std::vector<vec2> xy[2];
    std::vector<float> z;

    std::vector<std::string> text;
};
struct TypedGraphicElements {
    enum type_t { …
    TYPE_COUNT };
    GraphicElements elms[TYPE_COUNT];
};

This allows to directly load the data of the elements into the graphic APIs – including the style – and all the calculations performed in lineshader.cc (which is a misnormer¹ BTW, because the actual shader is something different) could be then done in the shaders for real (i.e. creating thick lines, mitering, etc.) while at the same time cutting the amount of data transferred to the GPU in less than half.

¹: I consider this misnormer being a direct result of the people who develop the Qt toolkit having no clue about OpenGL and placing the interface for setting attribute values or buffer bindings in the QOpenGLShaderProgram class (where it's entirely misplaced) instead of the QOpenGLContext class, where this actually belongs.

Hover highlight stays on when cursor leaves the GL view

Assertion failure: init != "" (/path/to/nextpnr/ice40/bitstream.cc:778)

I'm hitting an assertion failure with cfaa6c0 (have not tried other versions). Don't have the time to create a minimal example now, but I can try to provide that later if required. In the meantime, I'm attaching the synthesized project in the hope that it's something easy to figure out. make serv_0.bin should do the trick. Shout if you need the source tree as well
tinyfpga_bx-icestorm.tar.gz

Run out of RAM when compiling with 4Gbyte

Hi,

When I try to compile nextpnr (configured with cmake . -DARCH=all -DTRELLIS_ROOT=/home/matt/prjtrellis), it runs out of RAM (I have 4GB, no swap, no graphics) with the following error:

[  2%] Generating ecp5/chipdbs/chipdb-85k.bba
Traceback (most recent call last):
  File "/home/matt/nextpnr/ecp5/trellis_import.py", line 381, in <module>
    main()
  File "/home/matt/nextpnr/ecp5/trellis_import.py", line 370, in main
    ddrg = pytrellis.make_dedup_chipdb(chip)
MemoryError
make[2]: *** [CMakeFiles/ecp5_chipdb.dir/build.make:90: ecp5/chipdbs/chipdb-85k.bba] Error 1
make[1]: *** [CMakeFiles/Makefile2:72: CMakeFiles/ecp5_chipdb.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Can anything be done to reduce its RAM usage?

Thanks,

Matt

Investigate clustering related cells together in ice40

nextpnr-ice40 operates at the logic cell (LUT+FF) level. Investigate the effect of clustering related logic together to take advantage of any local feedback paths (are there any?) and to reduce the placement search space.

Not sure about other architectures, but a general solution would be great.

Once related logic is determined, one possible way of encoding affinity could be placement constraints?

What's interesting is that there exists the flexibility to capture relationships that stretch between "put these two cells next to each other" to "put these five cells somewhere in the same tile" to "put these eight cells in exactly these eight locations in one tile".

placer1 will also need to be enhanced to cope with swapping constrained cells with other constrained cells...

Timing analysis crashes on bin_size == 0

Floating point exception occurs at bins[(i.first - min_slack) / bin_size] in timing histogram code.

Verilog source:

`default_nettype none

module wtf(
    input clk_12,
    output fast
);

wire clk_216;

ice40_pll_12_216 pll(
    .clock_in(clk_12),
    .clock_out(clk_216)
);

assign fast = clk_216;

endmodule

Yosys/nextpnr invocation:

icepll -o 216 -m -n ice40_pll_12_216 -f ice40_pll_12_216.v
yosys -p 'read_verilog wtf.v ice40_pll_12_216.v; synth_ice40 -top wtf; write_json wtf.json'
nextpnr-ice40 --hx1k --json wtf.json --pcf wtf.pcf --asc wtf.asc

Crash:

gdb-peda$ bt
#0  0x000055555577eaeb in nextpnr_ice40::timing_analysis (ctx=<optimized out>, print_histogram=print_histogram@entry=0x1, print_path=print_path@entry=0x0)
    at /home/q3k/Work/Symbiotic/nextpnr/common/timing.cc:421
#1  0x000055555574b483 in nextpnr_ice40::SAPlacer::place (this=this@entry=0x7fffffffcfb0) at /home/q3k/Work/Symbiotic/nextpnr/common/placer1.cc:295
#2  0x0000555555745b27 in nextpnr_ice40::placer1 (ctx=ctx@entry=0x555560ca0e20, cfg=...) at /home/q3k/Work/Symbiotic/nextpnr/common/placer1.cc:500
#3  0x0000555555794255 in nextpnr_ice40::Arch::place (this=0x555560ca0e20) at /home/q3k/Work/Symbiotic/nextpnr/ice40/arch.cc:611
#4  0x000055555572fc16 in nextpnr_ice40::CommandHandler::executeMain (this=this@entry=0x7fffffffd5f0, ctx=std::unique_ptr<nextpnr_ice40::Context> containing 0x555560ca0e20)
    at /home/q3k/Work/Symbiotic/nextpnr/common/command.cc:210
#5  0x00005555557300d6 in nextpnr_ice40::CommandHandler::exec (this=0x7fffffffd5f0) at /home/q3k/Work/Symbiotic/nextpnr/common/command.cc:267
#6  0x000055555572afb4 in main (argc=<optimized out>, argv=<optimized out>) at /home/q3k/Work/Symbiotic/nextpnr/ice40/main.cc:161
#7  0x00007ffff3b50aee in __libc_start_main () from /lib64/libc.so.6
#8  0x000055555572b57a in _start ()

Relevant source:

nextpnr/common/timing.cc

Lines 413 to 425 in 4cc49ef

    
           constexpr unsigned num_bins = 20; 
        
           unsigned bar_width = 60; 
        
           auto min_slack = slack_histogram.begin()->first; 
        
           auto max_slack = slack_histogram.rbegin()->first; 
        
           auto bin_size = (max_slack - min_slack) / num_bins; 
        
           std::vector<unsigned> bins(num_bins + 1); 
        
           unsigned max_freq = 0; 
        
           for (const auto &i : slack_histogram) { 
        
               auto &bin = bins[(i.first - min_slack) / bin_size]; 
        
               bin += i.second; 
        
               max_freq = std::max(max_freq, bin); 
        
           } 
        
           bar_width = std::min(bar_width, max_freq);

Segfault with input driving output directly

I get the following segfault during packing (see attached zip for test case). I think this is related to outputs being driven directly by inputs.

$ bash run.sh
....
Info: dbg1 feeds SB_IO qpi_in_buf[1], removing $nextpnr_obuf dbg1.
Info: dbg2 feeds SB_IO qpi_in_buf[0], removing $nextpnr_obuf dbg2.
Info: dbg3 feeds SB_IO qpi_io_buf[0], removing $nextpnr_obuf dbg3.
Info: dbg4 feeds SB_IO qpi_io_buf[1], removing $nextpnr_obuf dbg4.
Info: qpi_io2 feeds SB_IO qpi_io_buf[2], removing $nextpnr_iobuf qpi_io2.
run.sh: line 2: 10962 Segmentation fault      nextpnr-ice40 --freq 25 --up5k --asc mlaccel.asc --pcf mlaccel.pcf --json mlaccel.json

Running it in valgrind gives me a bunch of invalid read errors, then it exits using the following message during timing budgeting:

Info: Annotating ports with timing budgets for target frequency 25.00 MHz
ERROR: no timing info for port 'I' of cell type '$nextpnr_obuf'

This is with current git master (2298c89).

nextpnr_segfault.zip

ERROR: Assert `src_wire != WireId()' failed in nextpnr/common/router1.cc:869.

If you have an inout wire on the top level that's not connected to anythng in the design, this will trigger the assert in the title when checking the routing in next-pnr.

Minimal test case :

module bug (
    inout wire gpio
);

endmodule

	constexpr unsigned num_bins = 20;
	unsigned bar_width = 60;
	auto min_slack = slack_histogram.begin()->first;
	auto max_slack = slack_histogram.rbegin()->first;
	auto bin_size = (max_slack - min_slack) / num_bins;
	std::vector<unsigned> bins(num_bins + 1);
	unsigned max_freq = 0;
	for (const auto &i : slack_histogram) {
	auto &bin = bins[(i.first - min_slack) / bin_size];
	bin += i.second;
	max_freq = std::max(max_freq, bin);
	}
	bar_width = std::min(bar_width, max_freq);

yosyshq / nextpnr Goto Github PK

nextpnr's People

Contributors

Stargazers

Watchers

Forkers

nextpnr's Issues

MVCE repo

Environment

Programs

NVIDIA Graphics

Intel Graphics

Steps to Duplicate

Expected Behavior

Actual Behavior

Other Information

Actual Behavior

Expected behavior

Other information

MCVE

Environment

Steps to Duplicate

Expected Behavior

Actual Behavior

Actual Behavior

Expected behavior

Other information

MCVE

Environment

Steps to Duplicate

Expected Behavior

Actual Behavior

Actual Behavior

Expected behavior

Other information

MCVE

pll-test.sh

pll-test.pcf

pll-test.v

Recommend Projects

Recommend Topics

Recommend Org