yosyshq / nextpnr Goto Github PK
View Code? Open in Web Editor NEWnextpnr portable FPGA place and route tool
License: ISC License
nextpnr portable FPGA place and route tool
License: ISC License
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
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.
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
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:
budget = std::min(budget, net_delay + path_slack/path_length)
--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...?
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
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.
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
MVCE is here: pll-crash2.zip
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'
E.g. Swaps attempted, swaps accepted, swap attempts per second, etc.
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).
Enable hover highlight when hovering over items in the tree view or properties view.
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.
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)
PLLOUTGLOBAL
followed by SB_GB
should be supported in nextpnr
, even if it's an obsolete hint (?) to the pnr
tool.
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
I have provided an MCVE: pll-crash.zip
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
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.
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)
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.
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?
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
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
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:
Lines 413 to 425 in 4cc49ef
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.
I can't find any documentation for the fact you can use ICEBOX_ROOT
to specify where to find the icebox files?
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.
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.
Current line of thinking:
PortRef
, distribute hold time from each path endpoint evenly across all nets on the path (like setup budget)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
.
$ 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)
nextpnr-ice40 --gui
from MSYS2/MinGW64 bash
(For the file dialog, navigate to the ice40
directory inside the nextpnr
source tree)
No SIGTRAP.
Application immediately closes with "Segmentation Fault".
Backtrace/SIGTRAP source is here: http://ix.io/1iV0
$ 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)
nextpnr-ice40 --gui
from MSYS2/MinGW64 bash
(For each file dialog, navigate to the ice40
directory inside the nextpnr
source tree)
No SIGSEGV
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
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...
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
#!/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
set_io clk12m_in 35
set_io out1 3
set_io out2 4
// 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
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. ๐
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).
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
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.)
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:
DYNAMICDELAY
results in a clean compile.+1
by +0
, or writing a 0 in crash_data
) results in a clean compile.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
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.
$ 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 claims system information is a text file, but it's really binary. So I uploaded an image as well:
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. *
nextpnr-ice40 --gui
from MSYS2/MinGW64 bash
.bash
CTRL+C exit would exit cleanly just like when closing the window manually by clicking "X". (Note: Clicking the "X" works fine.)
Unfortunately, I was unable to get a backtrace from this...
It is slightly inconsistent when I am able to get a driver reset:
nextpnr
is on my first monitor. I'm unsure how to consistently duplicate this.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.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
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:
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!)
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.
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.
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
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
Steps to reproduce:
nextpnr-ice40 --gui
fabout
in search bar and press ENTERZoom Selected
iconTyping local
instead of fabout
will select and zoom to a local net.
Possibly when estimating Fmax at end of placement, as well as end of routing.
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?
Just running ../nextpnr-ice40 --hx8k --gui
(without loading a design or doing anything) already has a pretty high CPU usage.
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:
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
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);
}
}
}
}
}
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).
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
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
Is there a way to disable building with readline support? Is -DENABLE_READLINE=No
enough?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.