synth: assertion failure for --synth on Chips4Makers JTAG code

[Fatsie]

Description ghdl --synth fail on Chips4Makers JTAG code

How to reproduce? I am running on Ubuntu 18.04.3 LTS with freshly compiled ghdl using gnat-8 package. Following steps should reproduce the problem:

eda@eda:/tmp$ git clone https://gitlab.com/Chips4Makers/c4m_jtag.git
Cloning into 'c4m_jtag'...
remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (32/32), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 116 (delta 9), reused 0 (delta 0)
Receiving objects: 100% (116/116), 28.36 KiB | 261.00 KiB/s, done.
Resolving deltas: 100% (34/34), done.
eda@eda:/tmp$ cd c4m_jtag/rtl/vhdl/
eda@eda:/tmp/c4m_jtag/rtl/vhdl$ export GHDL_OPTS="--std=08"
eda@eda:/tmp/c4m_jtag/rtl/vhdl$ ghdl -a $GHDL_OPTS c4m_jtag_pkg.vhdl c4m_jtag_idblock.vhdl c4m_jtag_irblock.vhdl c4m_jtag_iocell.vhdl c4m_jtag_ioblock.vhdl c4m_jtag_tap_fsm.vhdl c4m_jtag_tap_controller.vhdl 
eda@eda:/tmp/c4m_jtag/rtl/vhdl$ ghdl -e $GHDL_OPTS c4m_jtag_tap_controller
eda@eda:/tmp/c4m_jtag/rtl/vhdl$ ghdl --synth $GHDL_OPTS c4m_jtag_tap_controller

******************** GHDL Bug occurred ***************************
Please report this bug on https://github.com/ghdl/ghdl/issues
GHDL release: 0.37-dev (v0.36-928-g950f6b8c) [Dunoon edition]
Compiled with GNAT Version: 8.3.0
Target: x86_64-linux-gnu
/tmp/c4m_jtag/rtl/vhdl/
Command line:
ghdl --synth --std=08 c4m_jtag_tap_controller
Exception TYPES.INTERNAL_ERROR raised
Exception information:
raised TYPES.INTERNAL_ERROR : synth-context.adb:283
Call stack traceback locations:
0x55f66c831896 0x55f66c831b6d 0x55f66c831c10 0x55f66c836a4e 0x55f66c841d62 0x55f66c83752e 0x55f66c8375ce 0x55f66c833fdc 0x55f66c87b333 0x55f66c7ddbd7 0x55f66c92559d 0x55f66c5c5261 0x7efd5cd59b95 0x55f66c5c3bd8 0xfffffffffffffffe
******************************************************************
eda@eda:/tmp/c4m_jtag/rtl/vhdl$ cat -n ~/Compile/ghdl/src/synth/synth-context.adb |grep "   28[0-6]"
   280                    end if;
   281                    Current := Current.Up_Block;
   282                 end loop;
   283                 raise Internal_Error;
   284              end;
   285           when Kind_Package =>
   286              if Scope.Pkg_Parent = null then

[tmeissner]

It would be much easier to locate the problem, if you would synthesize the files one after another.

[eine]

Indeed, it seems that about 7 projects in https://gitlab.com/Chips4Makers are to be potentially tested with ghdl --synth. Instead of opening multiple bulk issues that might be duplicates, I'd suggest creating a single issue to track the 'Status of synthesis support for Chips4Makers'; just as we are doing with microwatt: #903.

@Fatsie, you can have a script that tries to build/synth as many repos as you want; execute it periodically to see how GHDL's support evolves; and update the follow-up issue accordingly. Nonetheless, please help us by further triaging the code that is producing the crashes. We don't expect you to find the specific line, but synthesizing files one by one (as suggested by @tmeissner) would be really helpful. Should you have too many files, we can help you find the compilation order automatically.

[Fatsie]

@Fatsie, you can have a script that tries to build/synth as many repos as you want; execute it periodically to see how GHDL's support evolves; and update the follow-up issue accordingly. Nonetheless, please help us by further triaging the code that is producing the crashes. We don't expect you to find the specific line, but synthesizing files one by one (as suggested by @tmeissner) would be really helpful. Should you have too many files, we can help you find the compilation order automatically.

I thought that having one big thread would make it more difficult to see which problem is solved and which is not. That's why I made issue for each type of error I find but if you prefer to have one big issue I'll do that. I will try to nail down in the future the lowest unit that is causing the error. I do look if an unhandled statement is not reported before as then I would have added a comment in the thread. For a raise Internal_Error it is difficult to see if it is a duplicate.

[tgingold]

Staf, your issues are OK. For me, they are easy to investigate even if they are slightly large.

Of course, it would be better to have small reproducers so that I can put it directly in the testsuite. But I agree that when you have a crash, it is not easy for the user to create a reproducer.

[eine]

I thought that having one big thread would make it more difficult to see which problem is solved and which is not. That's why I made issue for each type of error I find but if you prefer to have one big issue I'll do that.

And that is the most sensible approach for any relatively stable feature, which is the case of simulation support in GHDL. However, synthesis features are in an extremely experimental state. As a result, you are likely to find tens of unsupported features; especially when trying large designs as a black box.

As long as you are able to avoid duplicates, it is OK open new issues. That helps us see that the project advances! 🚀

I will try to nail down in the future the lowest unit that is causing the error. I do look if an unhandled statement is not reported before as then I would have added a comment in the thread. For a raise Internal_Error it is difficult to see if it is a duplicate.

That's why I suggested a script the represents which projects you'd like to be supported. I am personally interested on which other cool designs you bring, and I'd like to help with periodically testing/triaging related issues.

FTR, I am working on a GitHub Action that will allow to re-evaluate the MWEs in the first message of an issue, and post the Bug occurred blog in the issue, whenever GHDL is updated. Your sets of projects are the kind of designs for which I find it specially useful to have a tracking issue.

[Fatsie]

Problem is that I have synthesis now integrated in Makefile flow that uses nmigen + yosys and nmigen is also a fast moving target. I'll try to remove the need for nmigen.

[eine]

Please, just point me to that Makefile, and I will have a look. The GitHub Action I commented is based on docker containers. Hence, we might probably just try to execute your makefile straightaway and search for GHDL related errors. That's something I'd like to support.

[Fatsie]

Actually I am still using Symbiotic EDA with verific plugin for yosys for VHDL synthesis and trying to convert to ghdl. Will let you know when I have that implemented. I can also help in making needed docker images, CI was also one of the things on my list to have a deeper look at.

[eine]

Will let you know when I have that implemented.

Great!

I can also help in making needed docker images, CI was also one of the things on my list to have a deeper look at.

We are currently providing images based on Debian Buster for yosys, symbiyosys, nextpnr, and VUnit, apart from GHDL and GHDL's language server. See https://github.com/ghdl/docker#-cacheyml-5-jobs--max-5--7-images-weekly

On the one hand, there is some overlap with what FOSSI (librecores-ci) might provide/maintain: librecores/docker-images#33. On the other hand, I'd like to know which features you miss in the set of images that we provide currently.