Need updated Yosys to successfully run attosoc test with nextpnr-xilinx

[HackerFoo]

This version of Yosys needs updated to work with nextpnr-xilinx.

Running the attosoc example with this version of Yosys results in:

+ ../../../nextpnr-xilinx --chipdb ../../xc7a35t.bin --xdc arty.xdc --json attosoc.json --write attosoc_routed.json --fasm attosoc.fasm
ERROR: Found an out-of-range integer parameter in the JSON file.
Please regenerate the input file with an up-to-date version of yosys.
0 warnings, 1 error

Using the latest revision (currently 83f84afc0b617fe78fb7cfa31fb9d1cd202e22f2) fixes this.

[acomodi]

@litghost @HackerFoo FYI, I have started the work to get an updated yosys version on master+wip.

To reproduce the tests I have been performing these are the branches and commits needed:

• New yosys master+wip: (f83de1b438a72007b65f2f551c2da359c372b07c)
• SymbiFlow arch-defs: (https://github.com/antmicro/symbiflow-arch-defs/commit/8fab833504025c239b2a3bf77c04d8bbf4db6db0)

I have summed up below the issues preventing us from merging the new master+wip (some of these issues occurred also on the latest attempt of updating yosys):

1. SRL post-synthesis testbenches fail: all of the srl testbenches fail after yosys synthesis, and this does not occur with the current version of yosys master+wip:
   • I am still unsure what causes this failure. The production of a reduced form of the testbenches is non-trivial.
   • This might deal with the ABC9 optimizations performed on the SRLs, it may be possible that the issue is there.
   • pre-synthesis simulation do work fine.
2. Apparently, when running with ABC9 carry carry chains do not end up in the eblif:
   • CARRY models do end up in the eblif if -vpr option is not provided in the synth.tcl
   • This is temporarily solved by removing the abc9_box definition from the carry chains in the cells_sim.v file.
   • In addition I needed to modify the LCU map in the arith_map.v file to as yosys was going through that module, inferring non-supported models (e.g. MUXCY) in VPR.
3. MUX8 are inferred and they cause troubles with VPR during packing.
   • This is temporarily solved by adding the -nowidelut option to the synth.tcl script.

So far I was able to successfully run all the litex tests in Symbiflow-arch-defs:

• mini: basic litex implementation w/o DDR --> works on HW
• mini_ddr: basic litex implementation w/ DDR --> works on HW
• base: Linux capable litex implementation --> ethernet does not work on HW

[acomodi]

Update:

SRL post-synthesis testbenches fail

This seems indeed to be related to ABC9. By disabling abc9, all the post-synthesis tests do pass. I believe that we could remove the abc9_box from the SRL instances in the cells_sim.v file, so we do not have to disable abc9 completely.

[acomodi]

Update on Ethernet not working on the Linux-capable litex design.

I have come across a few things that might be helpful to get forward in the debug process:

• FDSE inference: I have sen that in with the new master+wip yosys, the FDSE primitives are getting inferred, which is not true for the current version of the master+wip.

  • I have locally tested whether the FDSE primitive works on HW and it does.
  • By reverting the changes in Yosys that do allow inference of FDSE primitives, the design still does not work.

• RAMB36: there were additions on the matching patterns for RAMB36 as well as RAMB18. This allowed to infer RAMB36 primitives.

  • By allowing only RAMB18, the implementation still didn't have a working ethernet.

• Ethernet clocks are coming from two inputs (eth_rx_clocks and eth_tx_clocks). These are not passing through a BUFG, but even by forcing a BUFG connection, the ethernet core does not work.

The HW behavior I am seeing is the following:

m1, b0: |00000000000000000000111111111111| delays: 26+-06
m1, b1: |00000000000000000000000000000000| delays: -
m1, b2: |00000000000000000000000000000000| delays: -
m1, b3: |00000000000000000000000000000000| delays: -
m1, b4: |00000000000000000000000000000000| delays: -
m1, b5: |00000000000000000000000000000000| delays: -
m1, b6: |00000000000000000000000000000000| delays: -
m1, b7: |00000000000000000000000000000000| delays: -
best: m1, b0 delays: 26+-06
SDRAM now under hardware control
Memtest OK
--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
             Timeout
Loading emulator.bin from flash...
Error: Invalid image length 0xffffffff
Booting from flash...
Error: Invalid image length 0xffffffff
Booting from network...
Local IP : 192.168.100.50
Remote IP: 192.168.100.100
Fetching from: UDP/6069
(hangs here forever)

The orange led on the eth module is always off, apart from sometimes as soon as the bitstream is loaded, it blinks for a fraction of a second and then goes dark.

I have also produced (by mistake) a non working DDR implementation by setting the phase of one of dqs clock of the PLL to 90 (triggering the parameter parsing issue in yosys). Interestingly, when the netboot command was not called in BIOS at startup, as memtest failed, the orange led was blinking and remained switched on after a while. Then, as soon as I manually called netboot from BIOS, the orange led went dark. This could suggest a possible timing issue, but, for what I have seen, no timing violations on the ethernet clocks were visible, but I would better double check this.