Cologne Chips place&route 'p_r' fails with "Error: Exception Handler called. ExitCode: 112"

[fm4dd]

This error occurs when executing Cologne Chips place and route 'p_r' in step08 and step10 only.

Observed error output details:

home/fm/cc-toolchain-linux/bin/p_r/p_r -i SOC_synth.v -o SOC -ccf ../gatemate-e1.ccf +uCIO > SOC_pr.log
make: *** [../config.mk:35: impl] Error 112

fm@nuc7fpga:~/fpga/projects/git/gatemate-riscv/step10$ tail SOC_pr.log
    7  Netlength: 2685.74   diff(%): 3.26346   1
    8  Netlength: 2623.89   diff(%): 2.35712   1
    9  Netlength: 2580.43   diff(%): 1.68426   1
   10  Netlength: 2593.39   diff(%): -0.49977   1
   11  Netlength: 2792.54   diff(%): -7.13145   2

Time (s):       1.303
Combine RAMs 877 and 876
#### Error: Exception Handler called. ExitCode: 112
Exception Class: EAccessViolation

Error Origin: The error traces back to the constraints file gatemate-e1.ccf in line 57:

Pin_out "TXD" Loc = "IO_NB_B5"; # RXD

The problem in this pin assignment seems to be with PMOD bank NB. As soon as a different IO bank such as SB or EA is configured, 'p_r' works. E.g. changing "IO_NB_B5" to "IO_SB_B5" lets p_r finish the routing fine.

It is mysterious why this pin assignment fails for the particular step08 and step10 only, while the same constrains file shared across all steps works without issue there. The NB bank pin is assigned to the attached Digilent PMOD USBUART serial TX line, and is verified to work.

p_r version:

fm@nuc7fpga:~/fpga/projects/gatemate/learn-fpga/step10$ /home/fm/cc-toolchain-linux/bin/p_r/p_r -h
GateMate (c) Place and Route
Version 4.2 (1 Jul 2023)
All Rights Reserved (c) Cologne Chip AG

fm@nuc7fpga:~$ cat cc-toolchain-linux/bin/VERSION 
yosys-gcc-static-0.29+42
openFPGALoader-mingw64-v.0.10.0
p_r-dcclinux64-2023.07-002

Workaround: Create a local constraints file and a local Makefile inside the step08 and step10 folders, copied from the global master. Remove the UART pin assignment line inside the local constraints file copy. The serial line is only needed from step17 onwards, so taking them out for step08 and step10 will not break the code. Finally, adjust the local Makefile to let 'p_r' use the local constraints file, and run 'make'.

[fm4dd]

The workaround has been added to step08 and step10 folders. There, the local Makefile simply overrides the global config.mk to use a locally added constraints file.

fm@nuc7fpga:~/fpga/projects/git/gatemate-riscv/step08$ cat Makefile 
### Local Makefile, adding the exercise-specific code modules.  ###
### Anything else is defined in the upper directory centralized ###
### Makefile config.mk                                          ###
### ----------------------------------------------------------- ###
include ../config.mk
ADD_SRC += ../rtl-shared/clockworks.v \
           ../rtl-shared/pll_gatemate.v

# Setting local folder constraints file as workaround for p_r issue
# in https://github.com/fm4dd/gatemate-riscv/issues/1
PIN_DEF = gatemate-e1.ccf

fm@nuc7fpga:~/fpga/projects/git/gatemate-riscv/step08$ ls -l gatemate-e1.ccf 
-rwxrwxrwx 1 root root 2936 Sep  2 14:47 gatemate-e1.ccf

I suspect the issues is caused by bug within the 'p_r' executable from Cologne Chip, and needs to be re-evaluated when newer 'p_r' versions are released.

[fm4dd]

After checking with the latest toolchain version from October-18, the problem still exists:

fm@nuc7fpga:~$ cat cc-toolchain-linux/bin/VERSION 
yosys-gcc-static-0.33+65
openFPGALoader-mingw64-v.0.10.0
p_r-dcclinux64-2023.10-003

(Not relevant, but the latest toolchain now creates an additional, empty "abc.history" file during synthesis.)