yowasp / yosys Goto Github PK

View Code? Open in Web Editor NEW

65.0 3.0 2.0 226 KB

Unofficial Yosys WebAssembly packages

Home Page: https://yowasp.org

License: ISC License

Shell 16.59% Python 52.59% JavaScript 30.82%

fpga yosys webassembly python pypi yowasp

yosys's People

Contributors

Stargazers

Watchers

Forkers

robtaylor registrar-shyran

yosys's Issues

Browser package (npm)

This was discussed on twitter a few times but I thought it would be helpful to track it here.

Use Cases

netlist visualization
- type verilog in the browser and see the netlist update in real time
resource usage visualization
- I started working on this thing that would fetch fusesoc projects from github, synthesize them and display resource usage as a sunburst diagram
- Running it client-side prevents users from using it as synthesis-as-a-service, we are using the users CPU cycles, not my CPU cycles
Place and route visualization
- I havent tried this but it would be interesting to play with
Simulation with cxxrtl
- Useful for FPGA workshops where you dont want to deal with machine setup or user hardware

Why

As a quick demo of Yosys. Some hardware engineers are not very computer savvy and explaining how to install python and running pip isn't as easy as sending them a link to a webpage. Seeing browser visualizations also makes for an impressive flashy demonstration. Also simply being able to run synthesis in browser demonstrates how light weight yoys is compared to vendor tools.
Introductory digital logic workshops are much easier when there is literally zero computer setup required
A lot of visualization tools are already in JS (netlistsvg, wavedrom, d3, etc)
People keep on doing one-off browser builds of Yosys for their specific use case. It would be nice if there was a good package that was good enough for everyone to use instead of rolling their own.

What's the next best alternative?

Grab one of the builds of YosysJS floating around.
Jupyter notebooks are really great educational tool, but require learning the jupyter interface and at least a little python

Challenges

Accessing files is annoying in the browser. In addition to the wasm file, you also need to deal with the users files, the tech library files. So, ideally those would be packaged in a way that is easy to use.

GHDL module

Do you plan to add GHDL module support for mixed language? Thanks!

Error when used with VSCode and Teroshdl

Hi, When I use yowasp to generate netlist with Teroshdl and vscode I get the following error. Please take a look at the attached file. Thank you
netlist_error.log

Feasibility of including pyosys

Hi! This is a great project, thanks for the hard work on it!

Here's my question: I developed a couple of Python applications that use pyosys to do some synthesis/analysis work. Due to the nature of the host OS, packaging and distributing yosys to users of those tools is not a great experience at the moment. I feel like yowasp-yosys could improve that dramatically if it also allowed access to pyosys. This would also somehow fit nicely with the fact that it's being installed via a python package manager?
Being unfamiliar with wasm generally, I wonder if that's feasible at all, given pyosys depends on libyosys?

What solvers come with yowasp?

I typically have my bmc configured with smtbmc and z3, with an occasional foray into boolector. What comes "natively" in yowasp?

Failing exit of `yowasp-yosys` cause an infinite chain of exceptions on Windows

This can be reproduced by running, for example, yowasp-yosys --version:

C:\Users\Maya>yowasp-yosys --version
Yosys 0.23 (git sha1 UNKNOWN, ccache clang 11.0.0-2~ubuntu20.04.1 -Os -flto -flto)
Traceback (most recent call last):
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 624, in _rmtree_unsafe
    os.rmdir(path)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\Maya\\AppData\\Local\\Temp\\tmpt5ul_igjyosys'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python311\Lib\tempfile.py", line 878, in onerror
    _os.unlink(path)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Maya\\AppData\\Local\\Temp\\tmpt5ul_igjyosys'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Maya\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 624, in _rmtree_unsafe
    os.rmdir(path)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\Maya\\AppData\\Local\\Temp\\tmpt5ul_igjyosys'

During handling of the above exception, another exception occurred:
(the exception chain continues indefinitely until the recursion limit is reached)

As a part of the issue #24, a similar problem is reported. This problem has also been reported as YosysHQ/yosys#3217.

YoWASP yosys fails to generate SVG diagrams

Currently, YoWASP Yosys fails to generate SVG diagrams. However, the .dot file is created correctly in the output directory.
The problem seems to be related to dot execution:

3. Generating Graphviz representation of design.
Writing dot description to `yosys.dot'.
Dumping module ADDER to page 1.
Exec: dot -Tsvg 'yosys.dot' > 'yosys.svg.new' && mv 'yosys.svg.new' 'yosys.svg'

Steps to reproduce:

wget https://raw.githubusercontent.com/SymbiFlow/sphinxcontrib-verilog-diagrams/master/tests/verilog/adder.v
python3 -c "from yowasp_yosys import *; run_yosys(['-p', 'prep -top ADDER ; cd ADDER; ; show -format svg -prefix yosys', 'adder.v'])"

Comparison with standard Yosys:

wget https://raw.githubusercontent.com/SymbiFlow/sphinxcontrib-verilog-diagrams/master/tests/verilog/adder.v
yosys -p 'prep -top ADDER ; cd ADDER; ; show -format svg -prefix yosys' adder.v

Pip made me scared. Is wasmtime 0.20.0 incompatible?

(This is on WSL on Windows 10 x86_64)

$ pip install yowasp-yosys
Collecting yowasp-yosys                                                                                                   
  Downloading yowasp_yosys-0.9.post4951.dev55-py3-none-any.whl (6.5 MB)                                                      
    |████████████████████████████████| 6.5 MB 1.9 MB/s                                                                 
Requirement already satisfied: appdirs~=1.4 in /home/robertbaruch/miniconda3/lib/python3.8/site-packages (from yowasp-yosys) (1.4.4)                                                                                                            
Requirement already satisfied: importlib-resources; python_version < "3.9" in /home/robertbaruch/miniconda3/lib/python3.8/site-packages (from yowasp-yosys) (3.1.1)                                                                             Collecting wasmtime~=0.20.0                                                                                               
  Downloading wasmtime-0.20.0-py3-none-manylinux1_x86_64.whl (4.5 MB)                                                        
    |████████████████████████████████| 4.5 MB 7.3 MB/s                                                                 
Installing collected packages: wasmtime, yowasp-yosys                                                                     
  Attempting uninstall: wasmtime                                                                                            
    Found existing installation: wasmtime 0.19.0                                                                            
    Uninstalling wasmtime-0.19.0:                                                                                             
      Successfully uninstalled wasmtime-0.19.0
                                                                       
ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.
                                                                                                                                                                                                
We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.                                                                                                                                                                                                                                             

nmigen-yosys 0.9.post3527.dev26 requires wasmtime~=0.19.0, but you'll have wasmtime 0.20.0 which is incompatible.**       

Successfully installed wasmtime-0.20.0 yowasp-yosys-0.9.post4951.dev55

binding to pyosys

it would be nice to have https://github.com/YoWASP/yosys/blob/develop/pypi/yowasp_yosys/__init__.py exposes the same API as pyosys (YosysHQ/yosys#905), is that something that has already been looked at?

Crash on Windows with STATUS_BAD_STACK

Running the nmigen example 01_blinky.py with nmigen 0.3.dev95+g126f0be and yowasp-yosys 0.9.post4547.dev5 on Windows 10 x64 yields the following error messages:

Traceback (most recent call last):                                                                                           
  File "01_blinky.py", line 21, in <module>                                                                                  
    platform.build(Blinky(), do_program=True)                                                                                
  File "<my path>\nmigen\nmigen\build\plat.py", line 90, in build                         
    plan = self.prepare(elaboratable, name, **kwargs)                                                                        
  File "<my path>\nmigen\build\plat.py", line 163, in prepare                      
    return self.toolchain_prepare(fragment, name, **kwargs)                                                                  
  File "<my_path>\nmigen\nmigen\build\plat.py", line 437, in toolchain_prepare            
    render(content_tpl, origin=content_tpl))                                                                                 
  File "<my_path>\nmigen\nmigen\build\plat.py", line 431, in render                       
    "autogenerated": autogenerated,                                                                                          
  File "<my_path>\Miniconda3\lib\site-packages\jinja2\environment.py", line 1090, in render                            
    self.environment.handle_exception()                                                                                      
  File "<my_path>\Miniconda3\lib\site-packages\jinja2\environment.py", line 832, in handle_exception                   
    reraise(*rewrite_traceback_stack(source=source))                                                                         
  File "<my_path>\Miniconda3\lib\site-packages\jinja2\_compat.py", line 28, in reraise                                 
    raise value.with_traceback(tb)                                                                                           
  File "<template>", line 2, in top-level template code                                                                      
  File "<my_path>\nmigen\nmigen\build\plat.py", line 315, in emit_debug_verilog           
    strip_internal_attrs=False, write_verilog_opts=opts)                                                                     
  File "<my_path>\nmigen\nmigen\back\verilog.py", line 10, in _convert_rtlil_text         
    yosys = find_yosys(lambda ver: ver >= (0, 9))                                                                            
  File "<my_path>\nmigen\nmigen\_yosys.py", line 220, in find_yosys                       
    version = proxy.version()                                                                                                
  File "<my_path>\nmigen\nmigen\_yosys.py", line 157, in version                          
    version = cls.run(["-V"])                                                                                                
  File "<my_path>\nmigen\nmigen\_yosys.py", line 186, in run                              
    return cls._process_result(popen.returncode, stdout, stderr, ignore_warnings, src_loc_at)                                
  File "<my_path>\nmigen\nmigen\_yosys.py", line 108, in _process_result                  
    raise YosysError(stderr.strip())                                                                                         
nmigen._yosys.YosysError

Running with -m pdb shows that popen.returncode being non-zero is the cause of this error. This can be verified independently by running yowasp-yosys -V then echo %errorlevel% which prints:
-1073741784

assert failure on modern intel cpus with avx512_bf16

running into this issue: gz/rust-cpuid#45 (comment)

you'll probably need to update to a later version of wasmtime once the fix is included in the version released on PyPI.

Support for Mac M1

I am able to install yowasp using: python -m pip install yowasp-yosys but when I try to run it I get:

RuntimeError: unsupported architecture for wasmtime: arm64

Any plan to support arm64 for Mac M1?

out of bounds memory access

This is potentially user error, or a wasmtime error, I'm not experienced in this field, but I was attempting to build orbtrace-mini using the yowasp-yosys and yowasp-nextpnr-ecp5 instead of getting the binary oss-cad-suite tooling.

packages installed in the venv, via pip.

wasmtime==0.30.0
yowasp-nextpnr-ecp5==0.3.post31.dev324
yowasp-yosys==0.17.post67.dev359

The build works fine for quite a while, but eventually crashes with wasmtime._trap.Trap: wasm trap: out of bounds memory access

.... much skipped ...
10.43.1.1. Executing ABC.
Running ABC command: /yosys-abc -s -f <abc-temp-dir>/abc.script 2>&1
ABC command line: "source /tmp/yosys-abc-000000/abc.script".

+ read_blif /tmp/yosys-abc-000000/input.blif 
+ read_lut /tmp/yosys-abc-000000/lutdefs.txt 
+ strash 
+ ifraig 
+ scorr 
Warning: The network is combinational (run "fraig" or "fraig_sweep").
+ dc2 
+ dretime 
+ strash 
+ dch -f 
+ if 
+ mfs2 
+ dress 
Traceback (most recent call last):
  File "/home/karlp/src/orbtrace.git/.env3/bin/yosys", line 8, in <module>
    sys.exit(_run_yosys_argv())
  File "/home/karlp/src/orbtrace.git/.env3/lib64/python3.9/site-packages/yowasp_yosys/__init__.py", line 79, in _run_yosys_argv
    sys.exit(run_yosys(sys.argv[1:]))
  File "/home/karlp/src/orbtrace.git/.env3/lib64/python3.9/site-packages/yowasp_yosys/__init__.py", line 75, in run_yosys
    return _run_wasm_app("yosys.wasm", ["yowasp-yosys", *argv])
  File "/home/karlp/src/orbtrace.git/.env3/lib64/python3.9/site-packages/yowasp_yosys/__init__.py", line 68, in _run_wasm_app
    app.exports(store)["_start"](store)
  File "/home/karlp/src/orbtrace.git/.env3/lib64/python3.9/site-packages/wasmtime/_func.py", line 100, in __call__
    raise WasmtimeError._from_ptr(error)
  File "/usr/lib64/python3.9/contextlib.py", line 126, in __exit__
    next(self.gen)
  File "/home/karlp/src/orbtrace.git/.env3/lib64/python3.9/site-packages/wasmtime/_func.py", line 263, in enter_wasm
    raise trap_obj
wasmtime._trap.Trap: wasm trap: out of bounds memory access
wasm backtrace:
    0: 0xaa2465 - <unknown>!<wasm function 16189>
    1: 0x1ad149 - <unknown>!<wasm function 2389>
    2: 0x1ace11 - <unknown>!<wasm function 2388>
    3: 0x1addc8 - <unknown>!<wasm function 2394>
    4: 0x1aebdd - <unknown>!<wasm function 2401>
    5: 0x1b167b - <unknown>!<wasm function 2433>
    6: 0x1b6630 - <unknown>!<wasm function 2501>
    7: 0x1b66a9 - <unknown>!<wasm function 2506>
    8: 0x5a3fcd - <unknown>!<wasm function 7481>
    9: 0x5a442a - <unknown>!<wasm function 7482>
   10: 0x5a5eca - <unknown>!<wasm function 7484>
   11: 0x5a69c3 - <unknown>!<wasm function 7487>
   12: 0x105297 - <unknown>!<wasm function 1414>
   13: 0x105445 - <unknown>!<wasm function 1415>
   14: 0x105a54 - <unknown>!<wasm function 1419>
   15: 0x146c3f - <unknown>!<wasm function 1754>
   16: 0x26289 - <unknown>!<wasm function 270>
   17: 0x27bf1 - <unknown>!<wasm function 289>
   18: 0xa6155 - <unknown>!<wasm function 1016>
   19: 0x26289 - <unknown>!<wasm function 270>
   20: 0x27bf1 - <unknown>!<wasm function 289>
   21: 0x1ba289 - <unknown>!<wasm function 2602>
   22: 0xd5bd7f - <unknown>!<wasm function 19128>
   23: 0xd519f8 - <unknown>!<wasm function 19126>
   24: 0x91643d - <unknown>!<wasm function 13541>
   25: 0x9160b1 - <unknown>!<wasm function 13539>
   26: 0x91993b - <unknown>!<wasm function 13579>
   27: 0x1224c94 - <unknown>!<wasm function 24315>
   28: 0x919aad - <unknown>!<wasm function 13581>
   29: 0x12230cc - <unknown>!<wasm function 24313>
   30: 0x91643d - <unknown>!<wasm function 13541>
   31: 0x9160b1 - <unknown>!<wasm function 13539>
   32: 0x8fce3d - <unknown>!<wasm function 13296>
   33: 0x8f93fa - <unknown>!<wasm function 13275>
   34: 0x8e4216 - <unknown>!<wasm function 13026>
   35: 0x8e4292 - <unknown>!<wasm function 13027>
   36: 0x8e352f - <unknown>!<wasm function 13003>
   37: 0xb773 - <unknown>!<wasm function 24>

Traceback (most recent call last):
  File "/home/karlp/src/orbtrace.git/./orbtrace_builder.py", line 112, in <module>
    main()
  File "/home/karlp/src/orbtrace.git/./orbtrace_builder.py", line 101, in main
    builder.build(**trellis_argdict(args), run=args.build)
  File "/home/karlp/src/orbtrace.git/deps/litex/litex/soc/integration/builder.py", line 350, in build
    vns = self.soc.build(build_dir=self.gateware_dir, **kwargs)
  File "/home/karlp/src/orbtrace.git/deps/litex/litex/soc/integration/soc.py", line 1193, in build
    return self.platform.build(self, *args, **kwargs)
  File "/home/karlp/src/orbtrace.git/deps/litex/litex/build/lattice/platform.py", line 43, in build
    return self.toolchain.build(self, *args, **kwargs)
  File "/home/karlp/src/orbtrace.git/deps/litex/litex/build/lattice/trellis.py", line 236, in build
    _run_script(script)
  File "/home/karlp/src/orbtrace.git/deps/litex/litex/build/lattice/trellis.py", line 174, in _run_script
    raise OSError("Error occured during Yosys/Nextpnr's script execution.")
OSError: Error occured during Yosys/Nextpnr's script execution.

System is fedora34, x86-64.

ESM Module problem

I'm trying to use @yowasp/yosys npm package directly in a VSCode extension, but I'm encountering some difficulties. @yowasp/yosys uses "type": "module",, but VSCode haven't a good support for ES Modules.

I'm having problems importing @yowasp/yosys with my commonjs extension. Also I have tried:

async function getYosys(): Promise<any> {
    const yosys = await (eval(`import('@yowasp/yosys')`) as Promise<typeof import('@yowasp/yosys')>);
    return yosys;
}

export async function showYosysVersion() {
    const yosys = await getYosys();
    await yosys.runYosys(["--version"]);
}

But there are some errors related to WebAssembly. Could be possible to publish the package with commonjs instead of ESM Module?

Thanks!

TCL support for yowasp-yosys

Would it be possible to add TCL support to yowasp-yosys?

Please add examples on how to use this module

An example of how to use this would be great! Thanks!

I tried this code:

async function loadModule() {
    try {
        // Dynamically import the module
        const module = await import('https://cdn.jsdelivr.net/npm/@yowasp/yosys/gen/bundle.js');
        
        // Once the module is imported, you can use its exports
        module.runYosys(["--version"]);
    } catch (error) {
        console.error('Error loading module:', error);
    }
}

// Call the function to load the module
loadModule();

but i get this error from the browser:

Uncaught (in promise) RangeError: WebAssembly.Instance is disallowed on the main thread, if the buffer size is larger than 8MB. Use WebAssembly.instantiate, or use the flag `--enable-features=WebAssemblyUnlimitedSyncCompilation`.
    at bundle.js:508:28
    at Application.instantiate (bundle.js:4460:28)
    at Application.execute (bundle.js:504:30)
    at Application.run (bundle.js:534:17)
    at bundle.js:531:46

JavaScript: accessing generic resource/`share` files (e.g. cxxrtl headers)

Would it be possible to export some subset of Yosys' resource files directly from the APIs? In particular, I'd like to get access to the (compatible!) cxxrtl headers for my given yosys build, so that I can spit them out alongside a write_cxxrtl

There are probably some other (reasonable, but perhaps marginal) use cases that could be satisfied by providing generic access to other resource files. But I'm also ok with just the cxxrtl headers since that's all I need, I think. :)

Broken abc9 support for `synth_ecp5`

When using synth_ecp5, it seems -abc9 has been turned on by default at some point. However, it looks like something got miscompiled, or abc support is missing somehow, meaning synth_ecp5 just immediately fails unless you specify -noabc9:

...
3.42.18.3. Executing XAIGER backend.
<suppressed ~11 debug messages>
Extracted 231 AND gates and 1034 wires from module `top' to a netlist network with 115 inputs and 196 outputs.

3.42.18.4. Executing ABC9_EXE pass (technology mapping using ABC9).

3.42.18.5. Executing ABC9.
Running ABC command: "/yosys-abc" -s -f <abc-temp-dir>/abc.script 2>&1

I haven't taken the time to diagnose if this is an obviously known issue or not. I thought abc would be compiled into yosys in this case, but I can't remember all the details OTTOMH...

Version: @yowasp/yosys/0.37.58-dev.635