Implementation with nextpnr-xilinx + prjxray doesn't work.

[Unike267]

Hello everyone!

Context:

Until now, I synthesized the NEORV32 with Vivado and there wasn't any problem. Even I added a module via Stream Link and it worked successfully.

However, I'm trying to synthesize the NEORV32 CPU by default using only open tools and I'm having problems.

The board that I'm using is the ARTY A7 35T.

And the open tools are: GHDL + yosys + GHDL yosys plugin + nextpnr-xilinx + prjxray + openFPGALoader

I follow this script to implement the design:

set -ex

cd $(dirname "$0")

cd ..

git clone --recursive https://github.com/stnolting/neorv32-setups

cd synth

mkdir -p build

echo "Analyze NEORV32 CPU"

ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/*.vhd
ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/mem/neorv32_dmem.default.vhd
ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/mem/neorv32_imem.default.vhd
ghdl -i --workdir=build --work=neorv32 ../neorv32-setups/neorv32/rtl/test_setups/neorv32_test_setup_bootloader.vhd
ghdl -m --workdir=build --work=neorv32 neorv32_test_setup_bootloader

echo "Synthesis with yosys and ghdl as module"

yosys -m ghdl -p 'ghdl --workdir=build --work=neorv32 neorv32_test_setup_bootloader; synth_xilinx -flatten -abc9 -arch xc7 -top neorv32_test_setup_bootloader; write_json neorv32_test_setup_bootloader.json'

echo "Place and route"

nextpnr-xilinx --chipdb /usr/local/share/nextpnr/xilinx-chipdb/xc7a35t.bin --xdc arty.xdc --json neorv32_test_setup_bootloader.json --write neorv32_test_setup_bootloader_routed.json --fasm neorv32_test_setup_bootloader.fasm

echo "Generate bitstream"

/home/usainz/Descargas/prjxray/utils/fasm2frames.py --part xc7a35tcsg324-1 --db-root /usr/local/share/nextpnr/prjxray-db/artix7 neorv32_test_setup_bootloader.fasm > neorv32_test_setup_bootloader.frames

/home/usainz/Descargas/prjxray/build/tools/xc7frames2bit --part_file /usr/local/share/nextpnr/prjxray-db/artix7/xc7a35tcsg324-1/part.yaml --part_name xc7a35tcsg324-1 --frm_file neorv32_test_setup_bootloader.frames --output_file neorv32_test_setup_bootloader.bit

echo "Load bitstream in FPGA"
#To send to SRAM:
openFPGALoader --board arty neorv32_test_setup_bootloader.bit

There isn't any errors in the script process but when it is synthesize the bootloader doesn't work. The leds don't light and nothing is displayed in CuteCom terminal.

Is obviously that there isn't any problem in the design therefore any of these tools don't work right.

Questions:

• Have any of you implemented NEORV32 in Arty A7 using only open tools?
  • What tools did you use? (Maybe verilog to routing.)
• Can any of you implemented NEORV32 using these tools? (For confirm this issue.)

It is important to note that:

I followed this tutorial for install nextpnr-xilinx + prjxray and the led example it worked.

---

/cc @gatecat @f4pga @umarcor

[stnolting]

Hey @Unike267!

Unfortunately, I have never tested the open-source toolchain for AMD FPGAs. However, @AWenzel83 did a lot of work to add a test setup for these platforms in https://github.com/stnolting/neorv32-setups/pull/10. Maybe it is about time to finalize that :wink:

You could try to feed the auto-generated Verilog version of the processor (neorv32-verilog) into your flow - just to double-check that the yosys-ghdl plugin runs fine.

[Unike267]

Hello @stnolting!

You could try to feed the auto-generated Verilog version of the processor (neorv32-verilog) into your flow - just to double-check that the yosys-ghdl plugin runs fine

To check if the ghdl-yosys plugin runs fine I have synthesized the design in ICE40 (Alhambra II board). (After adapting the neorv32_test_setup_bootloader.vhd, changing the frequency to 12 MHz, reducing the IMEM to 4x1024 and the DMEM to 2x1024 and setting a appropriate .pcf)

Following this script:

set -ex

cd $(dirname "$0")

cd ..

git clone --recursive https://github.com/stnolting/neorv32-setups

echo "Copy the bootloader for ICE40"

cp synth/neorv32_test_setup_bootloader.vhd neorv32-setups/neorv32/rtl/test_setups

cd synth

mkdir -p build

echo "Analyze NEORV32 CPU"

ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/*.vhd
ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/mem/neorv32_dmem.default.vhd
ghdl -i --workdir=build --work=neorv32  ../neorv32-setups/neorv32/rtl/core/mem/neorv32_imem.default.vhd
ghdl -i --workdir=build --work=neorv32 ../neorv32-setups/neorv32/rtl/test_setups/neorv32_test_setup_bootloader.vhd
ghdl -m --workdir=build --work=neorv32 neorv32_test_setup_bootloader

echo "Synthesis with yosys and ghdl as module"

yosys -m ghdl -p 'ghdl --workdir=build --work=neorv32 neorv32_test_setup_bootloader; synth_ice40 -json neorv32_test_setup_bootloader.json'

echo "Place and route"

nextpnr-ice40 --hx8k --package tq144:4k --pcf lib.pcf --asc neorv32_test_setup_bootloader.asc --json neorv32_test_setup_bootloader.json

echo "Generate bitstream"

icepack neorv32_test_setup_bootloader.asc neorv32_test_setup_bootloader.bin

echo "Load bitstream in FPGA (make with sudo)"

sudo iceprog neorv32_test_setup_bootloader.bin

---

And it works.

So we can discard that the problem comes from ghdl-yosys plugin.

Anyway tomorrow I could try with the auto-generated Verilog version in Arty (now in home only have the ICE40).

Thanks for the feedback!!

:smiley: :+1:

[stnolting]

That looks good! :wink: Any progress on the Arty approach?

[Unike267]

Hello @stnolting!

Yes, I fixed the problem!

I solved it adding -nodsp and -nolutram arguments to yosys. As shown in the following command:

yosys -m ghdl -p 'ghdl --workdir=build --work=neorv32 neorv32_test_setup_bootloader; synth_xilinx -nodsp -nolutram -flatten -abc9 -arch xc7 -top neorv32_test_setup_bootloader; write_json neorv32_test_setup_bootloader.json' 

The rest of commands don't change.

I have checked it in Arty A7-35T and in Arty A7-100T and it works fine.

Here the proof:

I think that the optimization for dsps and for lutrams is not well implemented for xilinx fpgas.

Anyway thanks for your interest! :smiley:

[stnolting]

This is great! Thank you very much for sharing your findings! :+1:

I think that the optimization for dsps and for lutrams is not well implemented for xilinx fpgas.

I've heard that before. But anyway, it is a start 😉