openxc7 / nextpnr-xilinx

Experimental flows using nextpnr for Xilinx devices

nextpnr-xilinx

nextpnr is a open-source multi-architecture place-and-route framework aimed at real-world FPGA silicon. This is an experiment to integrate nextpnr with RapidWright, an open interface into Xilinx FPGAs, and Project Xray, open bitstream documentation for xc7 FPGAs.

Currently two flows are supported:

• UltraScale+ with RapidWright database generation, bitstream generation using RapidWight and Vivado
• xc7 with Project Xray database generation, bitstream generation using FASM and Project Xray (no Vivado anywhere in the flow)

Prerequisites - UltraScale+

• Follow the RapidWright manual install instructions
• Make sure $RAPIDWRIGHT_PATH is set correctly for all further steps
• Download a JAR of recent GSON
• Download and build Project Xray
• Install yosys

Prerequisites - Artix-7

• Run git submodule init and git submodule update to fetch the database and metadata
• Download and build Project Xray
• Install yosys

A brief (academic) paper describing the Yosys+nextpnr flow can be found on arXiv.

Building - Artix-7

• Run cmake -DARCH=xilinx .
• Run make (with -jN as appropriate)

Building - UltraScale+

• Run cmake -DARCH=xilinx -DRAPIDWRIGHT_PATH=/path/to/rapidwright -DGSON_PATH=/path/to/gson-2.8.5.jar .
• Run make (with -jN as appropriate)

Building the Arty example - XRay database

• Run pypy3 xilinx/python/bbaexport.py --device xc7a35tcsg324-1 --bba xilinx/xc7a35t.bba (regular cpython works as well, but is a lot slower)
• Run ./bbasm --l xilinx/xc7a35t.bba xilinx/xc7a35t.bin
• Set XRAY_DIR to the path where Project Xray has been cloned and built (you may also need to patch out the Vivado check for utils/environment.sh in Xray by removing this line and everything beyond it: https://github.com/SymbiFlow/prjxray/blob/80726cb73ba5c156549d98a2055f1ee3eff94530/utils/environment.sh#L52)
• Run attosoc.sh in xilinx/examples/arty-a35.

Building the zcu104 example - RapidWright

• Run java -jar rapidwright_bbaexport.jar xczu7ev-ffvc1156-2-e xilinx/constids.inc xilinx/xczu7ev.bba
• Run ./bbasm --l xilinx/xczu7ev.bba xilinx/xczu7ev.bin
• Run blinky.sh in xilinx/examples/zcu104.

Creating chip database from RapidWright

• Run java -jar rapidwright_bbaexport.jar xczu2cg-sbva484-1-e xilinx/constids.inc xilinx/xczu2cg.bba

  • This uses RapidWright to build a textual representation of a chip database for nextpnr
  • Replace xczu2cg-sbva484-1-e and the bba filename with the device you want to target. You can build multiple databases for multiple devices if desired (subject to the support caveats above)

• Run ./bbasm --l xilinx/xczu2cg.bba xilinx/xczu2cg.bin

  • This converts the text database from above to a binary database that nextpnr can mmap

• See xilinx/examples for example scripts that run the Yosys/nextpnr/RapidWright flow, then use Vivado to write a Verilog simulation netlist.

Notes

• Currently supported:

• xc7 and xcup: LUTs (including fractured), FFs, DRAM (only RAM64X1D), carry (XORCY and MUXCY or CARRY4), SRL16E and SRLC32E (no cascading), BRAM and IO

• xcup: OSERDESE3, ISERDESE3, IDDRE1, ODDRE1, IDELAYE3, ODELAYE3, IDELAYCTRL, BUFGCTRL, BUFG, BUFGCE, BUFG_PS, PLLE4_ADV, PLLE4_BASIC, MMCME4_ADV, MMCME4_BASIC, URAM288E, DSP48E2 (no cascading)

• xc7: OSERDESE2, ISERDESE2, IDDR, ODDR, IDELAYE2, ODELAYE2, IDELAYCTRL, BUFGCTRL, BUFG, BUFH, BUFHCE, IBUFDS_GTE2, GTPE2_COMMON, GTPE2_CHANNEL, PLLE2_BASIC, PLLE2_ADV, MMCME2_ADV, MMCME2_BASIC, DSP48E1 (cascading works)

• Bels, tile wires and pips are deduplicated but nodes (connections between tile wires) are not. This means that databases for larger devices will be several gigabytes in size (but significantly smaller than a fully flat database).

nextpnr-xilinx's Issues

nice to meet you

I have implemented most primitives and prjxray info of the XC7 devices using the f4pga-arch-defs project. but I've encountered some challenging issues with VPR, and Xilinx's architecture doesn't seem to fit well with VPR either. I am planning to try nextpnr next. I have forked your project. would it be possible to reach out to you if I encounter any issues in the future?

Prioritize support of BSCANE2 and STARTUPE2 primitives

With proliferation of SOC designs with on-chip CPUs, the selection of open-source RISC-V IP that can be used with openXC7 flow is severely limited due to lack of support for these two essential Xilinx primitives. That drastically affects openXC7 adoption rate, leaving it primarily to nerds and niche use-cases. E.g., the very popular Vex is not compatible with openXC7!

Even the essential PicoRV32 becomes problematic with openXC7 if one wants to deploy a serious and productive SW development flow for it.

https://symbioticeda.slack.com/archives/C053XV4R248/p1682539265405079
https://symbioticeda.slack.com/archives/C053XV4R248/p1686199192866639

/* as a workaround for this openXC7 handicap, we've put together a UART-based solution for the live CPU program uploads, without having the rebuild the entire FPGA. While it worked for us, that's not sufficient for more complex apps, and also not compatible with GDB */

Add support for pin drive strength

Please add support for pin drive strength.
This is set with "set_property DRIVE" in the .xdc file.

Currently nextpnr-xilinx only give an assertion, when it finds such entry in the xdc.

what(): Assertion failure: !is_string (/home/tobiw/nextpnr/tmp/nextpnr-xilinx/common/nextpnr.h:350) make: *** [Makefile:29: spec2g4.fasm] Aborted

LUTRAM write occurs on rising edge regardless of IS_WCLK_INVERTED property

Issue Description

Issue discovered in #20 (comment)

When IS_WCLK_INVERTED property is asserted, we expect the write to LUTRAM to occur on the falling edge. However, this does not happen as the placer and fasm writer ignores the property for LUTRAMs, and, therefore, treats as if all writes should occur on rising edge. This may lead to functional errors in designs that require writes on negative edge.

Steps to Reproduce and Test

To distinguish between a write occuring on a positive edge and negative edge of clock, I created a simple test with two LUTRAMs sensitive to different edges of clock. Output of posedge LUTRAM and negedge LUTRAM drives led_o[0] and led_o[1], respectively. A single BSCANE2 primitive will be used to manually drive WCLK+DI+WE pins of the LUTRAM via JTAG.

1. Clone primitive-tests repo fork with xc7-lutram-negedge-write-demo branch

git clone https://github.com/hansemro/primitive-tests.git -b xc7-lutram-negedge-write-demo

2. Navigate to primitive-tests/lutram-tests/negedge-write-test and build the test with the openXC7 toolchain:

Note

If targeting an FPGA board other than SQRL Acorn CLE215+, then provide an XDC file with
3 active-low LEDs mapped to led_o[2:0] and update BOARD/FAMILY/PART/JTAG_CABLE/XDC
target parameters in the Makefile.

$ cd primitive-tests/lutram-tests/negedge-write-test
$ nix develop github:openXC7/toolchain-nix
[nix(openXC7)] make

3. Check that CLKINV bit is not set anywhere inside top.fasm (a sign that the test will fail). Proceed with the following steps to test.

4. Load the bitstream onto the FPGA:

make program

5. With LUTRAM initialized to 0, write a 1 on positive edge with the following openocd command:

Note

Use an appropriate interface adapter script (usually located in /usr/share/openocd/scripts/interface/).

Digilent HS2 support is provided with digilent-hs2.cfg in case interface/ftdi/digilent-hs2.cfg does not work.

Note

setup.cfg defines a function set_lutram <we> <data> <clk> to manually set LUTRAM input pins.

To avoid setup/hold violations, we should not change clk and we/data together.

openocd -f interface/ADAPTER.cfg -f setup.cfg \
    -c "set_lutram 0 0 0" \
    -c "set_lutram 0 0 0" \
    -c "set_lutram 1 1 0" \
    -c "set_lutram 1 1 1" \
    -c "shutdown"

If the design works correctly, only the LED (led_o[0]) assigned to the posedge LUTRAM should be lit after a positive-edge write. If LEDs led_o[1:0] light up together, then the design was incorrectly implemented. (LED at led_o[2] should dim on positive-edge write since the outputs should differ).

Anyhow, to perform a write on the negative edge, we would run the following afterwards:

openocd -f interface/ADAPTER.cfg -f setup.cfg \
    -c "set_lutram 1 1 0"
    -c "shutdown"

6. (Optional) Compare positive-edge (and negative-edge) write behavior against bitstream built with Vivado bitstream:

make vivadoclean top.vivado.bit
make BITSTREAM=top.vivado.bit program
# initial positive-edge write
openocd -f interface/ADAPTER.cfg -f setup.cfg \
    -c "set_lutram 0 0 0" \
    -c "set_lutram 0 0 0" \
    -c "set_lutram 1 1 0" \
    -c "set_lutram 1 1 1" \
    -c "shutdown"
# negative-edge write
openocd -f interface/ADAPTER.cfg -f setup.cfg \
    -c "set_lutram 1 1 0"
    -c "shutdown"

Design implemented with Vivado should have the two LUTRAM perform writes at different edges of the clock.

Other Considerations

LUTRAM and FFs share clock from CLKINV routing BEL, so all synchronous elements within the SLICE site must have the same IS_*CLK_INVERTED property.

STA is very rudimentary, down to not even honoring timing constraints, yet alone accounting for clock tree skew

This is not forthcoming from the provided documentation and examples, and we had to uncover this major shortcoming indirectly, which does not contribute to openXC7 stated goal of "User friendliness uber alles". This also does not help the QOR -- We now understand the reluctance to conduct objective QOR comps to other open-source PnR tools (such as VPR), yet alone proprietary solutions.

nextpnr failed to route 6 RAMB36E1 design, gives ERROR: Failed to route arc 0 of net 'modules_2.mem_ext.Memory.0.8.genblk1.genblk1.CAS_B', from SITEWIRE/RAMB36_X3Y21/CASCADEOUTB to SITEWIRE/RAMB36_X2Y28/CASCADEINB

ERROR_Failed_to_route_arc_0_of_net_modules_2_mem_ext_Memory_0_8_genblk1_genblk1_CAS_B.zip

Info: Device utilization:
Info: SLICE_LUTX: 15157/126800 11%
Info: SLICE_FFX: 332/126800 0%
Info: CARRY4: 1026/15850 6%
Info: PSEUDO_GND: 1/30932 0%
Info: PSEUDO_VCC: 1/30932 0%
Info: HARD0: 0/ 2376 0%
Info: RAMB18E1: 0/ 270 0%
Info: FIFO18E1: 0/ 135 0%
Info: RAMBFIFO36E1: 0/ 135 0%
Info: RAMB36E1: 6/ 135 4%
Info: DSP48E1: 5/ 240 2%

Vivado works (resource usage is different in Vivado, more BRAMS are used)

nextpnr cant route design, Vivado works - ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.

ERROR_timing_analysis_failed_due_to_presence_of_combinatorial_loops_incomplete_specification_of_timing_ports.zip

Update k325 branch of kintex-chatter prjxray-db repository to upstream

For ease of development at this time, we change the submodule path to kintex-chatter's fork of prjxray-db, cf.
openXC7/xc7k325t-blinky-nextpnr#18
and #1.

Once k325t becomes part of the upstream prxjray-db, we should revert the changes of #1 and 3165a86

Error Message by Constraining Positiv OBUFDS Output to negativ Pin Pair

ERROR: No Bel named 'IOB_X1Y132/IOB33S/OUTBUF' located for this chip...

Limited support for Distributed Memory / LUTRAM

Issue Description

memory_libmap pass in Yosys 0.18 and newer would synthesize LUTRAMs unsupported by nextpnr including:

• RAMS32 (manually instantiated)
• RAMD32 (manually instantiated)
• RAMS64E (manually instantiated)
• RAMD64E (manually instantiated)
• RAM32X1S
• RAM64X1S
• RAM64X1S_1 (same as RAM64X1S with inverted clock)
• RAM128X1S
• RAM256X1S

Part of the issue stems from nextpnr not fully supporting all LUTRAMs in the Distributed RAM packer in xilinx/pack_dram.cc.

Resolving this should also address openXC7/demo-projects#6.

Tasks/Status

TODO: rewrite tasks

Development Branches

• experimental branch with support for RAMS32, RAMS64E, RAM32X1S, RAM64X1S, RAM128X1S, RAM256X1S: https://github.com/hansemro/nextpnr-xilinx/commits/xc7-lutram-dev/
  • use with yosys 0.18 or newer to test
  • rebuild chipdb after building
  • broken as many incorrect assumptions were made in this branch:
    • does not check negative z height for newly supported cells, possibly breaking projects with several newly supported cells.
    • missing RAMS32/RAMD32 to LUT_OR_MEM transformations with DI1 and O6 ports used.

References

See 018-clb-ram minitest. Build and view design checkpoint in Vivado.

https://f4pga.readthedocs.io/projects/prjxray/en/latest/architecture/dram_configuration.html

https://docs.xilinx.com/v/u/en-US/ug474_7Series_CLB

https://docs.xilinx.com/v/u/en-US/ug574-ultrascale-clb

https://docs.xilinx.com/r/en-US/ug953-vivado-7series-libraries

https://docs.xilinx.com/r/en-US/ug974-vivado-ultrascale-libraries

https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/7series_hdl.pdf

https://docs.amd.com/v/u/en-US/7series_hdl

https://github.com/Xilinx/XilinxUnisimLibrary/tree/master/verilog/src/unisims

The link to the manual RapidWright installation does no longer exist

Original:

"Follow the RapidWright manual install instructions"

-> 404

Maybe change to https://www.rapidwright.io/docs/Install.html?highlight=install ?

BSCANE2 placement not determined by JTAG_CHAIN parameter

Issue Description

NextPNR's placer may place BSCANE2 BELs at a different location than expected, and thus require a different USERx instruction to access.

Steps to Reproduce

1. Clone jtag_led demo with right-shift-fail branch:

git clone https://github.com/hansemro/jtag_led.git -b right-shift-fail
cd jtag_led

2. Modify USER_PORT/JTAG_CHAIN parameter in src/rtl/jtag_led.sv with any value between 1-4 (inclusive).

3. Build with make using openXC7 toolchain:

nix develop github:openXC7/toolchain-nix
make

4. Check if NEXTPNR_BEL attribute for bscane cell is valid or not inside jtag_led.place.json.

Expected placement:

JTAG_CHAIN	NEXTPNR_BEL
1	BSCAN_X0Y0/BSCAN
2	BSCAN_X0Y1/BSCAN
3	BSCAN_X0Y2/BSCAN
4	BSCAN_X0Y3/BSCAN

If still valid, try rebuilding with make YOSYS_OPTS=-DLS clean all. For some reasons, changing how jtag_tdi gets shifted into a shift register can affect placement.

Workaround

As a workaround, you can manually correct placement in jtag_led.place.json and let nextpnr route with the corrected json:

# clear build
make clean

# Synthesize, pack, and place design
make jtag_led.place.json

# edit jtag_led.place.json with correct `NEXTPNR_BEL` placement if necessary
...

# let make route and build the bitstream with corrected placement
make

oen signal of Tristate outputs is inverted by default in router1

ZINV_T1 bits are not generated for the oen lines of non inverted tristate outputs.

If N polarity pin is used as single clock BUFG, nextpnr gives error ERROR: Invalid global constant node 'INT_L_X0Y109/VCC_WIRE'

ERROR_Invalid_global_constant_node_INT_L_X0Y109_VCC_WIRE.zip

Vivado gives error:
[DRC PLIO-9] Placement Constraints Check for IO constraints: A clock source clock has been LOCed to a N-Type CCIO :

nextpnr-xilinx crash when MONITOR_BOT_XXX pin is used as input or output data PAD

using MONITORING PIN gives a crash:

terminate called after throwing an instance of 'std::out_of_range'
  what():  _Map_base::at
make: *** [../openXC7.mk:44: Test.fasm] Aborted (core dumped)

or

Info: Generating input buffer for '$iopadmap$Test.a'
Info:     Created 69 PAD cells from:
Info:             69x PAD
Info: Preparing clocking...
terminate called after throwing an instance of 'std::out_of_range'
  what():  dict::at()
Aborted (core dumped)

pin like
J10,0,IPAD_X0Y30,MONITOR_BOT_X46Y131,VP_0
for
xc7a100tcsg324-2

terminate_called_after_throwing_an_instance_of_std_out_of_range.zip

RAM32M/RAM64M not initialized with INIT_A/INIT_B/INIT_C/INIT_D parameters

Issue Description

As discovered in #20 (comment), nextpnr packer was checking the wrong INIT parameter without the underscore and produce fasm result with INIT parameters unset.

Additionally, in the following post in #20 (comment), I became more concerned after finding INIT pattern discrepancies between Vivado and NextPNR fasm results.

Indeed, with the recently merged LUTRAM over JTAG Primitive Test, it becomes more clear that my initial fix (https://github.com/hansemro/nextpnr-xilinx/tree/fix-ram32m-ram64m-init) would have functional errors due to invalid INIT patterns.

Affects OpenXC7 toolchain 0.8.2 and older.

Steps to Reproduce

[Affects RAM32M+RAM64M] Missing INIT underscore:

1. Clone primitve-tests repo:

git clone https://github.com/openXC7/primitive-tests.git

2. Update target parameters in Makefile (if not using SQRL Acorn CLE215(+)).

3. Build LUTRAM over JTAG test with RAM32M using openXC7 toolchain:

cd primitive-tests/lutram-tests/jtag-test
nix develop github:openXC7/toolchain-nix
make LUTRAM=RAM32M top.pack.json

3. Observe missing INIT parameters for transformed be.ram32m/* cells in top.pack.json.

[Affects RAM32M only] Invalid INIT patterns after correcting underscore typo

1. Checkout fix-ram32m-ram64m-init-0.8.2 branch in my nextpnr-xilinx fork:

git clone --recurse-submodules -b fix-ram32m-ram64m-init-0.8.2 https://github.com/hansmero/nextpnr-xilinx.git

2. Build nextpnr-xilinx:

cd nextpnr-xilinx
mkdir build
cd build
cmake ..
make -j$(nproc)

3. Update environment variables:

export PATH=$PWD:$PATH
export NEXTPNR_XILINX_DIR=$PWD
export NEXTPNR_XILINX_PYTHON_DIR=$PWD/../xilinx/python

4. Rebuild test with openXC7 toolchain + fix-ram32m-ram64m-init-0.8.2 branch of nextpnr-xilinx

cd /path/to/primitive-tests/lutram-tests/jtag-test
make LUTRAM=RAM32M clean top.bit

5. Program the board

make [JTAG_LINK=...] program

6. Run the following openocd test commands:

openocd -f interface/ADAPTER.cfg \
    -f ./setup.cfg \
    -c "read_lutram_range 0x0 32"
    -c "shutdown"

7. Compare openocd output against Vivado's RAM32M results in the following:

0xf
0x2d
0x5a
0x2d
0xa5
0x2d
0xf0
0x2d
0xf
0x78
0x5a
0x78
0xa5
0x78
0xf0
0x78
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0

[REFERENCE] Building JTAG over LUTRAM Using Vivado Toolchain

1. Create build template build-vivado.tcl inside primitive-tests/lutram-tests/jtag-test/ with the following:

# VIVADO TEMPLATE SCRIPT
# Do not run this script directly.
# Run build-vivado.sh with required arguments instead.

create_project -in_memory -part __PART__

set_property default_lib xil_defaultlib [current_project]
set_property target_language Verilog [current_project]

read_verilog -library xil_defaultlib ../top.v
read_xdc top.xdc

synth_design -top top \
    -part __PART__ \
    -verilog_define VIVADO \
    -verilog_define TEST___LUTRAM__
#write_checkpoint -force top.synth.dcp
place_design
#write_checkpoint -force top.place.dcp
phys_opt_design
route_design
#write_checkpoint -force top.route.dcp
write_bitstream -force top.vivado.bit

2. Create bash script build-vivado.sh inside primitive-tests/lutram-tests/jtag-test/ with the following:

#!/bin/bash

if [ -z $1 ]; then
    echo "Missing Arg1:FAMILY (e.g. kintex7)"
    exit 1
fi

if [ -z $2 ]; then
    echo "Missing Arg2:PART (e.g. xc7k325tffg900-2)"
    exit 1
fi

if [ -z $3 ]; then
    echo "Missing Arg3:BOARD (e.g. kc705)"
    exit 1
fi

if [ -z $4 ]; then
    echo "Missing Arg4:LUTRAM (e.g. RAM64X1D)"
    exit 1
fi

set -euo pipefail

FAMILY="$1"
PART="$2"
BOARD="$3"
LUTRAM="$4"

mkdir -p "${BOARD}_${PART}_${LUTRAM}"
cd "${BOARD}_${PART}_${LUTRAM}"
sed "s/__PART__/${PART}/g" ../build-vivado.tcl > build-vivado.tcl
sed -i "s/__LUTRAM__/${LUTRAM}/g" build-vivado.tcl
test -f "../${BOARD}.xdc" && cp "../${BOARD}.xdc" top.xdc || touch top.xdc
vivado -mode batch -source build-vivado.tcl
bit2fasm --db-root $PRJXRAY_DB_DIR/${FAMILY}/ --part ${PART} top.vivado.bit > top.vivado.fasm
cd ..

3. Source Vivado (2017.2) environment and generate bitstream with build-vivado.sh:

source /path/to/Xilinx/Vivado/2017.2/settings64.sh
chmod +x ./build-vivado.sh
./build-vivado.sh <FAMILY> <PART> <BOARD> <LUTRAM>

# Example
./build-vivado.sh artix7 xc7a200tfbg484-3 empty RAM32M

4. Program <BOARD>_<PART>_<LUTRAM>/top.vivado.bit to the board.

Main analytical placer locks up for designs with high Distributed RAM usage.

The exact same RTL+XDC went through both VTR (https://github.com/chipsalliance/f4pga) and Vivado w/o problem.

[https://symbioticeda.slack.com/archives/C053XV4R248/p1691005203874859]

See line#256 of [https://github.com/chili-chips-ba/openXC7-TetriSaraj/blob/main/1.hw/ip.cpu/picosoc_noflash.v], and change BRAM to DistRAM.

nextpnr cant route design - ERROR: Invalid global constant node 'INT_L_X0Y60/GND_WIRE'

This looks new since there is no crash after error
The design is very very small and simple
Vivado works
ERROR_Invalid_global_constant_node_INT_L_X0Y60_GND_WIRE.zip

Crash during DSP check_illegal_fanout

I am currently trying to synthesize a project (same constraints and project file given in my previous issue (#15).

When invoking ./build/nextpnr-xilinx --chipdb nexys.bin --json ~/p/dragon/build-xc7/hdl/Dragon.json --xdc ~/p/dragon/board_support/nexys/Nexys-Video-Master.xdc there is an assertion which triggers, and I cannot understand how the code here is intended to work. Hoping we can make some progress and get a fix in (I can potentially help once I know what is supposed to happen in this code).

Final lines before debug assert:

...
Info: Packing BRAM..
Info: Packing DSPs..
Info:     Created 16 DSP48E1_DSP48E1 cells from:
Info:             16x DSP48E1
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)

GDB Backtrace

(gdb) bt
#0  0x00007ffff72b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x00007ffff725fafe in raise () from /lib64/libc.so.6
#2  0x00007ffff724887f in abort () from /lib64/libc.so.6
#3  0x00007ffff74a4d19 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
#4  0x00007ffff74b4f4c in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
#5  0x00007ffff74b4fb7 in std::terminate() () from /lib64/libstdc++.so.6
#6  0x00007ffff74b5218 in __cxa_throw () from /lib64/libstdc++.so.6
#7  0x00007ffff74a7765 in std::__throw_out_of_range_fmt(char const*, ...) [clone .cold] () from /lib64/libstdc++.so.6
#8  0x00000000004c4ebf in std::vector<nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::slot, std::allocator<nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::slot> >::_M_range_check (this=0xbca82c0, __n=1) at /usr/include/c++/13/bits/stl_vector.h:1155
#9  0x00000000004c4327 in std::vector<nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::slot, std::allocator<nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::slot> >::at (this=0xbca82c0, __n=1) at /usr/include/c++/13/bits/stl_vector.h:1177
#10 0x00000000004c3d5c in nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::at (this=0xbca82c0, idx=...)
    at /home/sh4/p/nextpnr-xilinx/common/kernel/indexed_store.h:165
#11 0x00000000004c38be in nextpnr_xilinx::indexed_store<nextpnr_xilinx::PortRef>::iterator::operator* (this=0x7fffffffc450)
    at /home/sh4/p/nextpnr-xilinx/common/kernel/indexed_store.h:202
#12 0x00000000007b90fb in operator() (__closure=0x7fffffffc4f0, ni=0xbca82a0, port="PCOUT47") at /home/sh4/p/nextpnr-xilinx/xilinx/pack_dsp_xc7.cc:34
#13 0x00000000007b9325 in nextpnr_xilinx::XC7Packer::walk_dsp (this=0x7fffffffc900, root=0xbca9c10, current_cell=0xbca9c10, constr_z=25)
    at /home/sh4/p/nextpnr-xilinx/xilinx/pack_dsp_xc7.cc:47
#14 0x00000000007b9f8f in nextpnr_xilinx::XC7Packer::pack_dsps (this=0x7fffffffc900) at /home/sh4/p/nextpnr-xilinx/xilinx/pack_dsp_xc7.cc:158
#15 0x0000000000790a34 in nextpnr_xilinx::Arch::pack (this=0x9e8af0) at /home/sh4/p/nextpnr-xilinx/xilinx/pack.cc:905
#16 0x000000000049a1c1 in nextpnr_xilinx::CommandHandler::executeMain (this=0x7fffffffd6d0, ctx=std::unique_ptr<nextpnr_xilinx::Context> = {...})
    at /home/sh4/p/nextpnr-xilinx/common/kernel/command.cc:452
#17 0x000000000049bd47 in nextpnr_xilinx::CommandHandler::exec (this=0x7fffffffd6d0) at /home/sh4/p/nextpnr-xilinx/common/kernel/command.cc:549
#18 0x0000000000784cdf in main (argc=7, argv=0x7fffffffdb78) at /home/sh4/p/nextpnr-xilinx/xilinx/main.cc:91

If we look here in the code @ pack_dsp_xc7.cc

    auto check_illegal_fanout = [&] (NetInfo *ni, std::string port) {
        if (ni->users.entries() > 1)
            log_error("Port %s connected to net %s has more than one user", port.c_str(), ni->name.c_str(ctx));

34:        PortRef& user = *ni->users.end();
        if (user.cell->type != id_DSP48E1_DSP48E1)
            log_error("User %s of net %s is not a DSP block, but %s",
                user.cell->name.c_str(ctx), ni->name.c_str(ctx), user.cell->type.c_str(ctx));
    };

Line 34 is immediately dereferencing the end iterator of a container. In any standard library or other custom container I've ever seen, end represents an exclusive end (i.e. "the locastion after the last valid entry"), so this would appear on the surface to be just broken. Do you understand what is intended here? Perhaps I'm reading it wrong.

Unreadable error: ERROR: Port PCOUT40 has no connections - because of DSP in one design

Unknown unreadable error from DSPs inferred by Yosys in one random design

ERROR_Port_PCOUT40_has_no_connections.zip

Add rules check for conflincting outputs

Please add design rule check that warn when routing to driving signals to one target.

Placer places posedge and negedge flip flops into the same slice

The root problem seems to be the following:
The constraints regarding clock polarity are checked in here. It uses ArchCellInfo::ffInfo->is_clkinv. ArchCellInfo::ffInfo->is_clkinv is set here. However, ArchCellInfo::ffInfo->is_clkinv is false even if the underlying FF type is FDRE_1 (inverted). This is the case if CellInfo::params contains that string. This is the way how the post place validity is checked here. That is inconsistent, right?

I don't know how to fix this properly as I know nothing about the inner workings.

A quick hack for now might be inserting the following into arch_place.cc at the location mentioned before.

std::string orig_type_name = str_or_default(cell->attrs, id_X_ORIG_TYPE, "");
if (orig_type_name == "FDRE_1")
    cell->ffInfo.is_clkinv = true;

warning: format '%d' expects on Arm64 M1Mac

Replace %d with %ld because a warning will appear and the build will stop.

24.66 /nextpnr-xilinx/bba/main.cc: In function 'int main(int, char**)':
24.66 /nextpnr-xilinx/bba/main.cc:269:43: warning: format '%d' expects argument of type 'int', but argument 3 has type 'int64_t' {aka 'long int'} [-Wformat=]
24.66   269 |             printf("    stream '%s' with %d tokens\n", s.name.c_str(), int64_t(s.tokenTypes.size()));
24.66       |                                          ~^                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
24.66       |                                           |                            |
24.66       |                                           int                          int64_t {aka long int}
24.66       |                                          %ld
24.66 /nextpnr-xilinx/bba/main.cc:397:28: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'int64_t' {aka 'long int'} [-Wformat=]
24.66   397 |                 printf("%08x ", cursor - numBytes);
24.66       |                         ~~~^    ~~~~~~~~~~~~~~~~~
24.66       |                            |           |
24.66       |                            |           int64_t {aka long int}
24.66       |                            unsigned int
24.66       |                         %08lx
24.66 /nextpnr-xilinx/bba/main.cc:449:42: warning: format '%d' expects argument of type 'int', but argument 4 has type 'int64_t' {aka 'long int'} [-Wformat=]
24.66   449 |         fprintf(fileOut, "const char %s[%d] =\n\"", streams[0].name.c_str(), int64_t(data.size()) + 1);
24.66       |                                         ~^                                   ~~~~~~~~~~~~~~~~~~~~~~~~
24.66       |                                          |                                                        |
24.66       |                                          int                                                      int64_t {aka long int}
24.66       |                                         %ld

Contribute xc7k update to upstream

This issue is to pursue propagating updates for Kintex7 to upstream. At this time, this seems to be only a couple of changes to Python scripts, cf. 1c89de2
@hansfbaier: Based on your changes, does the code need to be further abstracted before are pull request is possible? Why was it necessary to distinguish between the variables name and basepart?

The second difference is the submodule prjxray-db which has been changed. In this case, an update of upstream prjxray is already pending (subject to their CI).

XDC Parsing fails without human-readable error

Running nextpnr-xilinx version Version 0.6.0-1-g55beb766 for part xc7a200tsbg484-1

I'm trying to file an issue for nextpnr-xilinx failing to handle my yosys output. Along the way, I found out the xdc file itself even fails parsing, but there is no error message. This is nearly unchanged from the official XDC file from Digilent for the Nexys Video.

I am running via the command line

./nextpnr-xilinx --chipdb ~/nexys.bin --json ~/Dragon.json --xdc ~/maybe.xdc

Parser overly (?) sensitive to whitespace

I am not sure exactly what the case is since I had to bulk edit many lines several times to get it to pass this stage, but some part of the XDC parser is very sensitive to spaces, e.g. } ] vs }]. I can dig into this more, but ideally if there is a parse error, it does not abort but will report the line which fails to the user (and then maybe abort if no more useful message can be made).

General failure to parse XDC

In the attached file I have some other parse error which has no human-readable error. There is again no human-readable error to help figure out what is wrong. Running in gdb via gdb --args ./nextpnr-xilinx --chipdb ~/nexys.bin --json ~/Dragon.json --xdc ~/maybe.xdc leads to

terminate called after throwing an instance of 'std::out_of_range'
  what():  dict::at()

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737351878464) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737351878464) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737351878464) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737351878464, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7042476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff70287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff74a2b9e in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff74ae20c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff74ae277 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007ffff74ae4d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00005555555dc6d7 in nextpnr_xilinx::dict<nextpnr_xilinx::IdString, nextpnr_xilinx::IdString, nextpnr_xilinx::hash_ops<nextpnr_xilinx::IdString> >::at (this=0x555555bb8a70, key=...)
    at /home/sh4/p/nextpnr-xilinx/common/kernel/hashlib.h:597
#10 0x00005555555d918f in nextpnr_xilinx::BaseCtx::getNetByAlias (this=0x555555bb7c90, alias=...) at /home/sh4/p/nextpnr-xilinx/common/kernel/basectx.h:216
#11 0x000055555598837e in operator() (__closure=0x7fffffffd1f0, str="get_ports {clk}") at /home/sh4/p/nextpnr-xilinx/xilinx/xdc.cc:110
#12 0x0000555555988d1a in nextpnr_xilinx::Arch::parseXdc (this=0x555555bb7c90, in=...) at /home/sh4/p/nextpnr-xilinx/xilinx/xdc.cc:172
#13 0x0000555555927631 in UspCommandHandler::customAfterLoad (this=0x7fffffffd950, ctx=0x555555bb7c90) at /home/sh4/p/nextpnr-xilinx/xilinx/main.cc:83
#14 0x0000555555604ad7 in nextpnr_xilinx::CommandHandler::executeMain (this=0x7fffffffd950, ctx=std::unique_ptr<nextpnr_xilinx::Context> = {...}) at /home/sh4/p/nextpnr-xilinx/common/kernel/command.cc:431
#15 0x0000555555606e00 in nextpnr_xilinx::CommandHandler::exec (this=0x7fffffffd950) at /home/sh4/p/nextpnr-xilinx/common/kernel/command.cc:549
#16 0x00005555559277a7 in main (argc=7, argv=0x7fffffffddf8) at /home/sh4/p/nextpnr-xilinx/xilinx/main.cc:91

so I assume there is some issue finding a particular net. Debugging this is a little difficult since the net names are stored in a dictionary (which is good, but makes seeing which net this is harder).

The general ask is to add error messages before aborting.

Dragon.tar.gz
maybe.xdc.txt

Error messaging does not provide enough info for the self-guided debug

"Failed assert" was reported for an issue that had nothing to do with assertions.
https://symbioticeda.slack.com/archives/C053XV4R248/p1691040074754449

We also strongly suggest adding switch for control of tool messaging verbosity level. This is even more important given the very limited openXC7 user base, hence no useful finds in Internet searches.

ERROR: Failed to route arc 0 of net '$abc$20823$aiger20822$2149', from SITEWIRE/DSP48_X0Y49/PCOUT23 to SITEWIRE/DSP48_X0Y51/PCIN23

dsp_err_Failed_to_route_arc_0.zip

Design with DSPs generated by Yosys gives unreadable error.
It's possible that clock pins are used for data or vice versa.