YosysHQ / arachne-pnr

Place and route tool for FPGAs
MIT License
413 stars 73 forks source link

Undefined behaviour generated when output is assigned to 0 #139

Open Hellonity opened 4 years ago

Hellonity commented 4 years ago

Steps to reproduce the issue:

Consider the following verilog code.

module demo (output y);
  assign y = 0;
endmodule

when synthesized using

yosys -p 'synth_ice40 -blif demo.blif' demo.v

and the version of Yosys used is

Yosys 0.9+2406 (git sha1 5c426d2b, clang 9.0.0-2 -fPIC -Os)

The output blif is like this

.model demo
.inputs
.outputs y
.names $false
.names $true
1
.names $undef
.names $false y
1 1
.end

Then use arachne-pnr to transform into .asc

arachne-pnr -d 1k  demo.blif -o demo.asc

The arachne-pnr version

arachne-pnr 0.1+328+0 (git sha1 c40fb22, g++ 9.2.1-9ubuntu2 -O2)

And use icebox_vlog to transform back into verilog

icebox_vlog  demo.asc

Expected behavior

It is expected the output is also assigned to be zero like

module chip (output io_11_17_1);

wire io_11_17_1;

wire n2;

assign n2 =  1'b0;
assign io_11_17_1 = n2;

endmodule

The code above is also generated by icebox_vlog but the .asc is now generated by nextpnr instead of arachne-pnr

The commands used are

yosys -p 'synth_ice40 -json demo.json' demo.v
nextpnr-ice40 --hx1k --json demo.json --asc demo.asc
icebox_vlog demo.asc 

Actual behavior

However, arachne-pnr actually leaves the output as a wire. Therefore, this bit is giving undefined behavior during simulation.

module chip (output io_11_17_0);
wire io_11_17_0;
// (11, 17, 'io_0/D_OUT_0')
// (11, 17, 'io_0/PAD')
endmodule
whitequark commented 4 years ago

Have you read the notice here? https://github.com/YosysHQ/arachne-pnr#arachne-pnr