PnR completed but Bitstream generation failed

[ThVerg]

I have read the docs and i have been trying out the tool and im very confused cause of the below problem ( im running the default fabric.csv) . This is the main code im running in sequential_16bit_en.v (same top_wrapper).

module sequential_16bit_en(
    input  wire        clk,
    input  wire [27:0] io_in,
    output wire [27:0] io_out,
    output wire [27:0] io_oeb
);
    wire rst = io_in[0];
    wire en  = io_in[1];   
    reg [7:0] mul0, mul1;
    reg [15:0] result;

    always @(posedge clk) begin
        if (en) begin
            if (rst) begin
                result <= 16'b0;
                mul0 <= 8'b0;
                mul1 <= 8'b0;
            end else begin
                mul0  <= io_in[3:0]   * io_in[3:0];
                mul1  <= io_in[7:4]   * io_in[7:4];
                result <= {mul1, mul0};
            end
        end
    end

    assign io_out = result;
    assign io_oeb = 28'h1; //don't know if this correct
endmodule

And these are the logs i get.

 Info: Program finished normally. INFO | Placement and Routing completed 
INFO | Generating Bitstream for design /home/FABulous/demo/user_design/sequential_16bit_en.fasm 
INFO | Outputting to /home/FABulous/demo/user_design/sequential_16bit_en.bin 
ERROR | CommandError | Bitstream generation failed for /home/FABulous/demo/user_design/sequential_16bit_en.fasm. Please check the logs for more details. 
ERROR | Command 'gen_bitStream_binary user_design/sequential_16bit_en.fasm' execution failed with exit code 1 ERROR | PipelineCommandError | Command failed

In general, i have seen that only if i use the io_in wires from the same IO_1_bidirectional_frame_config_pass it will work. If i use different ones the only accepted operation is +.

Thanks in advance for any help

[KelvinChung2000]

I will need a bit more debug information to tell. But I have two guesses.

1. due to multiplication. In an Xilinx FPGA, when you use the multiply, it is automatically inferred to use a DSP block. However, we have not yet been supported in our toolchain. If you want to use a multiplier, you will either need to implement a custom techmap or instantiate the DSP blocks yourself.
2. The error due to not using the IO_1_bidirectional_frame_config_pass. We have an extra wrapper around the user design, and the tools expect you to constrain all the IO of your design. The io_in, io_out, and the IO wrapper together provide the full constraint on the IO for you. If you want to have more input or output, you can update the top wrapper to meet your requirements.

[ThVerg]

Thanks for the quick reply. The following are the things i have seen using the tools (bug i think is on wire io_in cause i haven't faced problems with other wires):

1. result <= io_in[y+1:y] * io_in[y+1:y]; // array of size 2 works but has to be the same array of size 2
2. result <= io_in[x:y] * io_in[x:y]; // where x>y+1 doesnt work
3. result <= io_in[x:y] + io_in[w:z]; // works for every x,y,w,z
4. result <= io_in[x:y] - io_in [w:z]; // only works if z=y

[KelvinChung2000]

Do you mind sharing the error log for the place and route so we can have a look at what's causing the issue? Because it is very unlikely that the IO wire is "bugged".

[KelvinChung2000]

This is setting a different fasm feature, which might not be right... But anyway, if the root problem is that it cannot recognise X1Y10.G.INIT, there might be a problem with something else.

[ThVerg]

From the experiments i have ran with the rest of the code cases that didn't work. I see that for every *.INIT with start=None and end=None the tool cant recognise them. I made it so that they all these instances change to .FF and bitstream was generated but it seems that there is a delay (in some cases) on the correct result to be passed to the output (example code and testbench attached).
Testbench.txt
sequential_16bit_en.v.txt

[EverythingElseWasAlreadyTaken]

It seems, that our nextpnr integration, at least for some specific cases, has some config bit names hardcoded and ignores the names for config bits provided in the bel.v2.txt.
I've changed the belMap processing a few days / weeks ago, which had some implications on the bitstream spec, which backfires now.

Interestingly, your simple example triggers this, while I didn't had any issues while I've tested It with a few designs that are way more complex.

I'll send a patch in a few minutes, which should fix this.

[EverythingElseWasAlreadyTaken]

#493 should fix this