search

YosysHQ / nextpnr

nextpnr portable FPGA place and route tool
ISC License
1.28k stars 240 forks source link

nextpnr-mistral Failed to route arc 0.0 of net 'r_led', from WIRE.43.1.FFOUT[34] to NONE.0.0.0. #853

Closed infphyny closed 2 years ago

infphyny commented 2 years ago

A repro is available.

From a simple blink led example from QMTech repository, nextpnr-mistral failed to route the synthesized verilog by yosys for 5CEFA5F23I7 device. nextpnr-ecp5 and nextpnr-ice40 successfully place and route the synthesized verilog.

What I have noticed is nextpnr-mistral show that device 5CEFA5F23I7 have a total of 352 IO. The datasheet of 5CEFA5F23I7 p. 7 show that it have 240 IO pins.

yosys version is: 0.10+46 (git sha1 52ba31b1, gcc 11.2.0-7ubuntu2 -fPIC -Os). nextpnr-mistral version is: Next Generation Place and Route (Version 80a14592)

thanks.

gatecat commented 2 years ago

Thanks for the testcase. It looks like V19 is an IO that has to be accessed via HMC route-through, which isn't currently supported. I'll keep this issue open as a reminder that this still needs to be implemented.

Ravenslofty commented 2 years ago

I don't really have anything to add, but I wanted to say thanks for trying Mistral, even in its experimental state.

Ravenslofty commented 2 years ago

I'm going to add support for routing through to V19, but before I do, I'm going to mention that I think while the I/O difference is a little confusing, it's not really a bug. Those pads do actually exist on the die (it's a 5CGTFD5C5F27I7), but because it's an F23 part you can't actually name the pins: if you try they'll be rejected because they don't correspond to a pad.

infphyny commented 2 years ago

I do not have a deep knowledge of cyclone V fpga. With quartus, the pin V19 is an accessible I/O for 5CEFA5F23I7 and able to generate bitstream.

The following is maybe not useful for you, but if I remove the V19 output I/O for the blink led example and modify the Arch::init_base_bitstream() in this file to handle CycloneV::GT75F, I was able to generate a bitstream. From the decompiled quartus bitstream, the command grep 'i [_A-Z0-9.]* 1' gave me 

 // Discover these mux values using
 //   grep 'i [_A-Z0-9.]* 1' empty.bt
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(0, 11), 69), true); //i GOUT.000.011.0069 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(0, 12), 4), true); // i GOUT.000.012.0004 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(0, 33), 69), true);//i GOUT.000.033.0069 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(0, 34), 4), true);//  i GOUT.000.034.0004 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(0, 53), 62), true);//i GOUT.000.053.0062 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 17), 66), true);//i GOUT.009.017.0066 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 19), 8), true);//i GOUT.009.019.0008 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 26), 69), true);//i GOUT.009.026.0069 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 27), 43), true);//i GOUT.009.027.0043 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 39), 66), true);//i GOUT.009.039.0066 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 41), 8), true);//i GOUT.009.041.0008 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 48), 69), true);//i GOUT.009.048.0069 1
cyclonev->inv_set(CycloneV::rnode(CycloneV::GOUT, CycloneV::xy2pos(9, 49), 43), true);//i GOUT.009.049.0043 1

Of course other default config are not set like CycloneV::SX120F. When I decompile the generated bitstream from nextpnr-mistral I got the following message.

Source unknown on rnode GOUT.001.000.0041 (23, 001)
Source unknown on rnode GOUT.002.000.0008 (30, 020)
Source unknown on rnode GOUT.002.001.0044 (57, 0200)
Source unknown on rnode GOUT.002.001.0048 (41, 0200)
Source unknown on rnode GOUT.002.001.0052 (57, 0001)
Source unknown on rnode GOUT.002.001.0055 (49, 0008)
Source unknown on rnode GOUT.002.001.0063 (49, 0010)
Source unknown on rnode GOUT.002.001.0066 (57, 0100)
Source unknown on rnode GOUT.002.001.0071 (49, 0001)
Source unknown on rnode H3.000.001.0070 (16, 02)
Source unknown on rnode H3.002.001.0005 (16, 02)
Source unknown on rnode V4.000.000.0000 (16, 08)
Source unknown on rnode TD.001.000.0007 (14, 01)
Source unknown on rnode TD.001.001.0027 (16, 80)
Source unknown on rnode TD.001.001.0042 (16, 20)
Source unknown on rnode TD.002.000.0001 (14, 02)
Source unknown on rnode TD.002.000.0007 (14, 02)
Source unknown on rnode TD.002.000.0016 (12, 20)
Source unknown on rnode TD.002.001.0028 (16, 02)

I don't know if that help just a little to begin support for 5CEFA5F23I7. That was the experiment I have done so far.

Thanks.

galibert commented 2 years ago

That's a symptom of a bad bug in mistral that I just fixed, which also needs change on the nextpnr side. Once my PR is acceptable and merged the Source unknown problems should be gone and the hmc-bypassed gpios handled.

infphyny commented 2 years ago

Great, with latest mistral and nextpnr update, the error is gone.