m-labs / nmigen

A refreshed Python toolbox for building complex digital hardware. See https://gitlab.com/nmigen/nmigen
https://nmigen.org
Other
646 stars 55 forks source link

Bus arbiter broken after synthesis #325

Closed strobo5 closed 4 years ago

strobo5 commented 4 years ago

I'm using minerva's WishboneArbiter in a small design based on nMigen. Simulation in nMigen's simulator and behavioral simulation of the generated verilog code are fine. The synthesis results are broken though. Xilinx XST generates a small netlist that gives a more or less static output. Functionality is definitely gone.

With the arbiter rewritten in nMigen in a simpler form (WbArbiter), everything is fine.

In the allegedly broken verilog output there are casez statements with a suspicious question mark, starting at line 132:

    casez (bus_pe_o)
      1'h0:
          bus__bte = port__bte;
      1'h?:
          bus__bte = \port__bte$8 ;
    endcase

In s3e_arbiter.zip I'm attaching a more or less minimal design (s3e_arbiter.py) that either uses minerva.wishbone.WishboneArbiter (not attached) or my own WbArbiter in wbarbiter.py. Both verilog outputs are attached. Also there is a simple testbench that even spits out some errors when the outputs are not as expected. It fails when the post-translate model from Xilinx ISE is simulated, which is not attached. The target board is a Digilent Spartan-3E board.

nmigen@8f5a253b22cd4ebcd56304a3662f4c70e3b34ed5 yosys@7f1d83c5db6201efd96a1f0d842c2ca9d671e974

With yosys 0.9 the issue ss similar. In the casez block there is 1'hz: instead of 1'h?:

s3e_arbiter.zip

strobo5 commented 4 years ago

Solved, not an nmigen issue. As @whitequark pointed out on IRC I was using Xilinx XST without the '-use_new_parser yes' parameter. The old parser is doing it wrong. With the new parser the issue is solved.

In XilinxSpartan3Or6Platform nmigen already uses that option so it was just to blame on my Platform-less flow.