Synthesis for `jtag-probe` fails with latest YoWASP Yosys

[VioletEternity]

Synthesis for `jtag-probe` fails with latest YoWASP Yosys

[VioletEternity]

It also fails, with the same error, as far back as yowasp-yosys 0.9.post5623.dev231, so the issue might not be Yosys version dependent.

[whitequark]

Looks like the build_top.sh file, when generated on Windows, is written with CRLF line endings, and so sh doesn't run it. I've filed this as amaranth-lang/amaranth#732.

[whitequark]

Other than that, I can reproduce the issue with the archive you attached, but not with Glasgow installed in a fresh venv on Linux. Can you describe your environment in more detail?

[VioletEternity]

I'm using Python 3.11.1 (tags/v3.11.1:a7a450f, Dec 6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)] on win32. The output of pip freeze is:

aiohttp==3.8.3
aiosignal==1.3.1
amaranth==0.3
amaranth-yosys==0.10.0.dev47
appdirs==1.4.4
async-timeout==4.0.2
attrs==22.1.0
bitarray==2.6.0
charset-normalizer==2.1.1
crcmod==1.7
frozenlist==1.3.3
fx2==0.9
-e git+https://github.com/GlasgowEmbedded/glasgow@b8051ad39cf608cf52adf6111892d9510b4420ab#egg=glasgow&subdirectory=software
idna==3.4
Jinja2==2.11.3
libusb1==3.0.0
MarkupSafe==1.1.1
multidict==6.0.3
pyvcd==0.2.4
wasmtime==0.30.0
yarl==1.8.2
yowasp-nextpnr-ice40==0.4.post25.dev361
yowasp-yosys==0.23.dev444

[whitequark]

After removing the src attributes, it looks like there is some difference in the IL where wires end up with internal $-names rather than public \-names:

@@ -60,8 +60,8 @@
       update \stage1 \stage1$next
   end
   process $group_2
-    assign $1 1'0
-    assign $1 \stage1
+    assign \sda_i 1'0
+    assign \sda_i \stage1
     sync init
   end
 end

This is likely to affect the flatten pass. The reason names end up missing are probably bytecode changes in Python 3.11. Can you recheck with 3.9 or 3.10?

[VioletEternity]

I get a different crash with Python 3.10.9 (tags/v3.10.9:1dd9be6, Dec 6 2022, 20:01:21) [MSC v.1934 64 bit (AMD64)] on win32 and YoWASP Yosys:

I: glasgow.cli: building bitstream for applet 'jtag-probe'
ERROR: Assert `ofs.is_open()' failed in ../yosys-src/passes/techmap/abc9_ops.cc:950.
I: glasgow.target.hardware: keeping build tree as C:\Users\Maya\AppData\Local\Temp\glasgow_lfow7thr
Traceback (most recent call last):
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\Maya\Desktop\glasgow\software\glasgow\cli.py", line 861, in <module>
    main()
  File "C:\Users\Maya\Desktop\glasgow\software\glasgow\cli.py", line 857, in main
    exit(loop.run_until_complete(_main()))
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 649, in run_until_complete
    return future.result()
  File "C:\Users\Maya\Desktop\glasgow\software\glasgow\cli.py", line 773, in _main
    f.write(plan.execute(debug=True))
  File "C:\Users\Maya\Desktop\glasgow\software\glasgow\target\hardware.py", line 118, in execute
    products  = self.lower.execute_local(build_dir)
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python310\lib\site-packages\amaranth\build\run.py", line 96, in execute_local
    subprocess.check_call(["cmd", "/c", "call {}.bat".format(self.script)])
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmd', '/c', 'call build_top.bat']' returned non-zero exit status 1.

The output of pip freeze is:

aiohttp==3.8.3
aiosignal==1.3.1
amaranth==0.3
amaranth-yosys==0.10.0.dev47
appdirs==1.4.4
async-timeout==4.0.2
attrs==22.1.0
bitarray==2.6.0
charset-normalizer==2.1.1
crcmod==1.7
frozenlist==1.3.3
fx2==0.9
-e git+https://github.com/GlasgowEmbedded/glasgow@b8051ad39cf608cf52adf6111892d9510b4420ab#egg=glasgow&subdirectory=software
idna==3.4
Jinja2==2.11.3
libusb1==3.0.0
MarkupSafe==1.1.1
multidict==6.0.3
pyvcd==0.2.4
wasmtime==0.30.0
yarl==1.8.2
yowasp-nextpnr-ice40==0.4.post25.dev361
yowasp-yosys==0.23.dev444

The archive with the build tree is attached here: glasgow_lfow7thr.zip

[whitequark]

I can build a bitstream with the build tree from glasgow_lfow7thr.zip on Linux, so it looks like there are at least three bugs here:

1. Amaranth not inferring names for signals properly on Python 3.11;
2. Yosys flatten pass failing to process the netlist Amaranth generates (amaranth-lang/amaranth#733);
3. whatever the fuck is wrong with abc from yowasp that makes it die with a Assert `ofs.is_open()' failed in ../yosys-src/passes/techmap/abc9_ops.cc:950.
4. oh and there's the CRLF issue that I already filed an Amaranth bug for (amaranth-lang/amaranth#732)

Sigh...

[whitequark]

Hey @mwkmwkmwk, can you please take a look at the netlist in glasgow_sm98_a5s.zip please and say if there's a reason the flatten pass should be failing on it?

[whitequark]

• whatever the fuck is wrong with abc from yowasp that makes it die with a Assert `ofs.is_open()' failed in ../yosys-src/passes/techmap/abc9_ops.cc:950.

It looks like abc is failing to write a LUT library:

void write_lut(RTLIL::Module *module, const std::string &dst) {
	std::ofstream ofs(dst);
	log_assert(ofs.is_open());
	ofs << module->design->scratchpad_get_string("abc9_ops.lut_library");
	ofs.close();
}

Probably because the path is wrong or something?

[mwkmwkmwk]

Hey @mwkmwkmwk, can you please take a look at the netlist in glasgow_sm98_a5s.zip please and say if there's a reason the flatten pass should be failing on it?

Amaranth is using $13 as an autogenerated port name. Unfortunately, yosys has the convention that ports called $<number>are actually positional parameters, so cell port called $13 will actually bind to, say, wire width 4 input 13 \fx2_0__flag__i1.

I highly suggest choosing a different naming convention.

[mwkmwkmwk]

Oh, and by the way, this only happens when the $<number> actually happens to be a valid port number — you may get lucky if the autogenerated name is high enough.

[whitequark]

That is incredibly cursed.

[mwkmwkmwk]

I can build a bitstream with the build tree from glasgow_lfow7thr.zip on Linux, so it looks like there are at least three bugs here:

1. Amaranth not inferring names for signals properly on Python 3.11;

The version of amaranth here seems to be 0.3, which is earlier than 851546bf2d16db62663d7002bece51f07078d0a5 that adds Python 3.11 support — could you retest with current git main?

[VioletEternity]

I've retested with Amaranth version 0.4.dev36+ge3b2ba4 (installed via pip install git+https://github.com/amaranth-lang/amaranth.git); glasgow build --rev C2 jtag-probe succeeds with yowasp-yosys version 0.23.dev444.

[whitequark]

Of issues described in #298 (comment):

• (1) was already fixed upstream;
• (2) is an Amaranth issue that was fixed upstream;
• (3) is a consequence of (2), probably because there's a comb loop or something;
• (4) isn't a cause of bugs here and is tracked upstream.

I think this is done now. Thanks for the report.

[whitequark]

@mwkmwkmwk So I've never actually aimed to create ports with $\d+ names, it was an invariant violation elsewhere.