Giter VIP home page Giter VIP logo

siliconcompiler's Introduction

SiliconCompiler

Python CI Tests Tools CI Tests Daily CI Tests Wheels Lint Documentation Status codecov Downloads

Introduction

SiliconCompiler is a modular hardware build system ("make for silicon"). The project philosophy is to "make the complex possible while keeping the simple simple".

Supported Technologies

Type Supported
Design Languages C, Verilog, SV, VHDL, Chisel, Migen/Amaranth, Bluespec
Simulation Tools Verilator, Icarus, GHDL, Xyce
Synthesis Yosys, Vivado, Synopsys, Cadence
ASIC APR OpenRoad, Synopsys, Cadence
FPGA APR VPR, nextpnr, Vivado
Layout Viewer Klayout, OpenRoad, Cadence, Synopsys
DRC/LVS Magic, Synopsys, Siemens
PDKs sky130, gf180, asap7, freepdk45, gf12lp, gf22fdx, intel16

Getting Started

SiliconCompiler is available as wheel packages on PyPI for macOS, Windows and Linux platforms. For working Python 3.8-3.12 environment, just use pip.

python -m pip install --upgrade siliconcompiler

Converting RTL into DRC clean GDS takes less than 10 lines of simple Python code.

import siliconcompiler                             # import python package
chip = siliconcompiler.Chip('heartbeat')           # create chip object
chip.load_target('skywater130_demo')               # load a pre-defined target
chip.input('heartbeat.v')                          # set input sources
chip.clock('clk', period=10)                       # set constraints
chip.set('option','remote', True)                  # enable remote execution
chip.run()                                         # run compilation
chip.summary()                                     # print summary
chip.show()                                        # show layout

Simple designs can be compiled in a single line using the built in command line 'sc' app:

sc -remote -target "asic_demo"

Why SiliconCompiler?

  • Ease-of-use: Programmable with a simple Python API
  • Portability: Powerful dynamic JSON schema supports ASIC and FPGA design and simulation
  • Speed: Flowgraph execution model enables cloud scale execution.
  • Friction-less: Remote execution model enables "zero install" compilation
  • Modularity: Tool abstraction layer makes it easy to add/port new tools to the project.
  • Provenance: Compilation manifests created automatically during execution.
  • Documented: An extensive set of auto-generated high quality reference documents.
  • In-use: Actively used by Zero ASIC for commercial tapeouts at advanced process nodes.

Documentation

The full reference manual and tutorials can be found HERE.

License

Apache License 2.0

How to Cite

If you want to cite our work, please use the following paper:

A. Olofsson, W. Ransohoff, N. Moroze, "Invited: A Distributed Approach to Silicon Compilation", 59th Design Automation Conference (DAC), 10-14 July 2022, San Francisco, CA, USA. Published, 7/2022.

Bibtex:

@inproceedings{10.1145/3489517.3530673,
author = {Olofsson, Andreas and Ransohoff, William and Moroze, Noah},
title = {A Distributed Approach to Silicon Compilation: Invited},
year = {2022},
booktitle = {Proceedings of the 59th ACM/IEEE Design Automation Conference},
pages = {1343โ€“1346},
location = {San Francisco, California}
}

Installation

Complete installation instructions are available in the Installation Guide.

To install the project from source (recommended for developers only).

git clone https://github.com/siliconcompiler/siliconcompiler
cd siliconcompiler
python -m pip install -e .             # Required install step
python -m pip install -e .[docs,test]  # Optional install step for generating docs and running tests

EDA Tool Installation

Installation instructions for all external tools can be found in the External Tools section of the user guide. We have included shell setup scripts (Ubuntu) for most of the supported tools. See the ./setup directory for a complete set of scripts and ./setup/_tools.json for the currently recommended tool versions.

Contributing

SiliconCompiler is an open-source project and welcomes contributions. To find out how to contribute to the project, see our Contributing Guidelines.

Issues / Bugs

We use GitHub Issues for tracking requests and bugs.

More information

Resources Link
Website https://www.siliconcompiler.com
Documentation https://docs.siliconcompiler.com
Sources https://github.com/siliconcompiler/siliconcompiler
Issues https://github.com/siliconcompiler/siliconcompiler/issues
RFCs https://github.com/siliconcompiler/rfcs
Discussion https://github.com/siliconcompiler/siliconcompiler/discussions

siliconcompiler's People

Contributors

aolofsson avatar aulihant avatar azaidy avatar bsanzhiev avatar dependabot[bot] avatar gabrielaguirre1 avatar gadfort avatar hohe avatar kimiatkh avatar mgielda avatar nmoroze avatar oharboe avatar petergrossmann21 avatar sconvent avatar sebinho avatar seyiayoarl avatar suppamax avatar tommarin avatar troibe avatar ubfx avatar volkamir avatar wransohoff avatar zephray avatar zyedidia avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

siliconcompiler's Issues

Remote message format

@WRansohoff

It would be nice to see the remote printing with exactly the same format as the local logger(even if the remote is not using the logger). We want to make the remote be exactly the same as running locally. Every time I run it, it feels like magic!!
Also, insteat of printing wait, can we print the number of seconds)?

So something like:

2021-05-27 21:04:31,852 INFO Remote job started
2021-05-27 21:04:31,852 INFO Remote 'place' running. (10s)
2021-05-27 21:04:31,852 INFO Remote 'place' running. (20s)
2021-05-27 21:04:31,852 INFO Remote 'place' running. (30s)
2021-05-27 21:04:31,852 INFO Remote 'place' running. (40s)
2021-05-27 21:04:31,852 INFO Remote 'place' completed
2021-05-27 21:04:42,741 INFO Running step 'cts' in dir 'build/gcd/job1/cts'
2021-05-27 21:04:42,889 INFO Remote server call
2021-05-27 21:04:31,852 INFO Remote 'cts' running. (10s)
2021-05-27 21:04:31,852 INFO Remote 'cts' running. (20s)
2021-05-27 21:04:31,852 INFO Remote 'cts' running. (30s)
2021-05-27 21:04:31,852 INFO Remote 'cts' running. (40s)
2021-05-27 21:04:31,852 INFO Remote 'cts' completed

Documentation/website

@nmoroze Thanks again for the Sphinx contribution. This is going to be great!
@WRansohoff

I really like the philosophy of auto generated html from source, but the default seems to be deprecated docs and websites.
Let me know if you have some thoughts on good projects to emolate. Besides style, clarity, organization, and maintenance costs are important.

Complete list:
https://www.sphinx-doc.org/en/master/examples.html

Excellent: (I like the alabaster theme for a reference manual)
https://numpy.org/doc/stable/reference/
https://docs.aiohttp.org/en/stable/
https://alabaster.readthedocs.io/en/latest/
https://jinja.palletsprojects.com/en/2.11.x/

Not my taste:
http://docs.myhdl.org/en/stable/
https://docs.micropython.org/en/latest/
https://docs.python.org/3/
https://pandas.pydata.org/pandas-docs/stable/

Routing param file?

@WRansohoff

Did you forget to add a file?

[INFO GRT-0110] Final usage : 2652.
[INFO GRT-0111] Final number of vias : 1532.
[INFO GRT-0112] Final usage 3D : 7248.
[INFO GRT-0018] Total wirelength: 7576 um.
[INFO GRT-0014] Num routed nets: 292.
/route.params
[ERROR DRT-0001] Error reading param file: //build/route/job1/route.params
Error: sc_route.tcl, 110 DRT-0001

Add all design source files to import

@aolofsson
Import is a special stage, needs to bring in all the sources used, not just verilog files, then gets carried along with data from input to output always! All non-used inputs gets copied from input to output at each stage.
(examples may include SDC, DEF, UPF, etc).
Everything goes through import.

Quality of Results Report from openroad

The standard for EDA tools is to do free form printing reaults for TNS WNS, power,area etc.
Woudl be great if there was a single command that provided qor in a pseudo standard format.
For example, report_qor

We could emulate this command by post processing the various reports with python, but that's not going to end well...

Yosys doesn't support SDC

Something I have suspected for a while, but never verified. Yosys doesn't support timing driven synthesis which means it's pretty much useless for high performance design. The OpenLane develop branch seems to confirms as much.

https://www.reddit.com/r/yosys/comments/an0ud9/does_yosys_support_sdc_file_as_an_input/

https://github.com/efabless/openlane/commits/develop

For now, the solution is to do a decent front end mapping in yosys and push the timing driven transformations to openroad or some other tool.

Action: SDC file is ignored in yosys.

Adopt CLANG norms

@aolofsson

Adopt CLANG features at command line interface:
Review other useful features?

-E Only run the preprocessor
-target= Generate code for the given target (use same triplet syntax as clang!!!)
-w Suppress all warnings
-W Enable the specified warning
-working-directory
Resolve file paths relative to the specified directory
--version Print version information

"sc" script

The main command line app should be called "sc".

How to:
-package as executable
-how to test during development
-how to ship as debian?
-how to build a docker container

Implement metrics tracking

I have implemented a summary at the end of the run that pulls in data from the metrics. The next step is to stuff the values into the schema from the different tools in the postprocess step. Some tools like openroad might have some built in quality of results
commands, but most likely it will be custom regex of the log file. All values should get populated. Place 'na' when not available.

Not urgent, let's finish when we get done with current tasks.

@nmoroze can you look at yosys, nextpnr, vpr
@WRansohoff can you look at openroad and the DoE link that I sent

Add C front end to sc

@nmoroze

Xilinx just opensourced their c front end which is a big deal. Time to raise the bar! Can you check how much pain it would be to go from from c/c++ to bitstream? Their tool should be production quality, but I can imagine there being verilog syntax errors when ingesting into yosys.

https://github.com/Xilinx/HLS

flatten eda

@aolofsson
Differentiating between fpga and asic is stupid, artbitraty partition and gets in the way in cases like verilator, yosys
(same tool). use one directory and then project/company. (as a shallow tree). For companies, you might have multiple tools

'jobname' config value causes errors.

When the '-jobname' config value is set, the 'writecfg' method encounters the following error:

$ sc examples/gcd/gcd.v -design gcd -target freepdk45 -asic_diesize '0 0 100 100' -asic_coresize '10 10 90 90' -constraint examples/gcd/constraint.sdc -jobname job3
[...]
FATAL ERROR: File/Dir not found: job3

Expanding the path that wasn't found, it turns out to be:

[...]/build/gcd/job3/import/job3

The call to self.writecfg("sc_schema.tcl", abspath=True) appears to walk through the config dictionary and check the absolute path of every dir-type config value. Should jobname be a string in the schema.py file?

This is an issue for the remote parallel workflow, because I need to set cfg['jobname'] prior to making remote_run calls so that the server can ensure that remote calls are run in the correct job directory.

'copy' parameter for 'cmdline' tool

I just noticed that the renamed openfpga_setup.py file now sets 'copy' to false. However, copying the files was necessary to move the OpenFPGA script template into the working directory. Changing 'copy' back to true results in an error now, due these changes: 38058f6#diff-0a7b686d579b6f3a831a79a61fda4755be2fc2f5cfefc0d848da015810cb3f54R839-R845 (lines highlighted). The error is because abspath doesn't get set if there is no value for 'script'.

I'm not really sure what the best solution here is. Would it be possible to tweak this code to allow 'copy' to be true for command line tools?

Do we want to keep restriction that "export" be last step?

Something I noticed when working on the OpenFPGA bitstream flow is that SC sets the value of "-stop" to be "export", which causes an error if a flow doesn't include "export". This came up because the OpenFPGA bitstream flow just has "import", "syn", and "apr", since what I would consider the export step is fused to the place-and-route step by OpenFPGA's design. I worked around this by adding "-stop apr" to the example run.sh, but I'm not sure if this is too hacky and if it should be fixed somehow.

Possible solutions I thought of:

  • Just change "apr" to "export" in the OpenFPGA bitstream flow
  • Add a dummy "export" step to the OpenFPGA bitstream flow that does nothing
  • Refactor run in core.py to not require a stop step, and remove the default value
  • Decide this is fine and just leave as-is :)

Add missing metrics

@aolofsson
Currently we have support for goals and real for a number of metrics, need to work with foundry to understand if this needs to be extended with more metrics, or if it needs be abstracted away completely, (probably lattter)

Remote broke examples/gcd/run.sh

@WRansohoff

Can you take at the errors for the gcd example. Looks like remote execution mode broke the regular mode.

ERROR: Can't open input file `inputs/gcd Subtractor_0x422b1f52edd46a85.v' for reading: No such file or directory

Can you take a look at the code below in the clI, it would be better if the remote doesn't impose any changes to the source.
As discussed, let's only do remote after import and you can assume that all the sources are in place in that directory.

Copy files and update config for running on a remote cluster if necessary.

job_hash = mychip.cfg['design']['value'][0] + '_' + mychip.cfg['target']['value'][0]
mychip.status['job_hash'] = job_hash
if (len(mychip.cfg['remote']['value']) > 0) and (mychip.cfg['remote']['value'][0] != ""):
    # Re-name the given source files to match compute cluster storage.
    new_paths = []
    for filepath in mychip.cfg['source']['value']:
        filename = filepath[filepath.rfind('/')+1:]
        new_paths.append(mychip.cfg['nfsmount']['value'][0] + '/' + job_hash + '/' + filename)
    # Copy the source files to remote compute storage.
    mychip.upload_sources_to_cluster()
    # Rename the source file paths in the Chip's config JSON.
    mychip.cfg['source']['value'] = new_paths

OpenDB documentation missing

In order to script floorplanning a small number of database operations are needed at a minimum.
-place cell
-pace terminal
-place net

This may already be supported?

Testing framework

The current testing approach is terrible. I keep adding modules and putting little print statements/code at the end of modules, then removing it. Surely, there is a better way. I looked into "unittest", seems to be some choices to make:

-placing tests inside siliconcompiler or outside?
-how to enable running tests from anywhere?
-enable users to run tests?

Create Docker image for sc server + open source tools

I have a feature/infrastructure idea that I wanted to propose: I think it could be a good idea to create a Docker image that includes SC as well as the open source EDA tools we support already installed.

I think this would be useful for:

  1. Making it easy for someone to try out SC on Windows/Mac/Linux without having to install lots of software and jump through hoops like building tools from source
  2. Having a consistent setup for development
  3. Might be a useful start towards creating a testing environment or eventually deploying SC on actual servers

Point 1 seems particularly important since a lot of the open source tools feel somewhat difficult to install -- many aren't included in package managers (or are outdated versions), so you have to build from source (which is often only well supported on Linux). Having an image that lets you spin up a Docker container would make it easy to get started with SC right away. Someone would just need Docker, the image we provide, and the SC client installed locally. They could run the container in the background with the server exposed over some port, and then they could use SC's remote feature to transparently let the tools in the container do the build tasks.

Curious if either of you (@aolofsson, @WRansohoff) have thoughts on this (I also wouldn't be surprised if you've thought about it already). It doesn't seem super high priority to me, but I think it could be nice to have something like this if SC ever gets an open source release, and I'd be happy to take a stab at it if I have enough time outside my main tasks.

Commands running twice as of 3a64105

@aolofsson

I'm trying to fix some breakages with the FPGA builds, and I'm noticing that as of the latest commit (3a64105), all build commands appear to be run twice. For example, if I add -quiet to the GCD example run.sh, I see:

2021-04-26 18:04:22,374 INFO     Running step 'import' in dir 'build/gcd/job2/import'
2021-04-26 18:04:22,374 INFO     Running step 'import' in dir 'build/gcd/job2/import'
2021-04-26 18:04:22,542 INFO     verilator --lint-only --debug -I../../../ /home/noah/siliconcompiler/examples/gcd/gcd.v > verilator.log
2021-04-26 18:04:22,542 INFO     verilator --lint-only --debug -I../../../ /home/noah/siliconcompiler/examples/gcd/gcd.v > verilator.log
2021-04-26 18:04:22,994 INFO     Running step 'syn' in dir 'build/gcd/job2/syn'
2021-04-26 18:04:22,994 INFO     Running step 'syn' in dir 'build/gcd/job2/syn'
2021-04-26 18:04:23,171 INFO     yosys -c /home/noah/siliconcompiler/eda/yosys/sc_syn.tcl > yosys.log
2021-04-26 18:04:23,171 INFO     yosys -c /home/noah/siliconcompiler/eda/yosys/sc_syn.tcl > yosys.log
2021-04-26 18:04:24,053 INFO     Running step 'floorplan' in dir 'build/gcd/job2/floorplan'
2021-04-26 18:04:24,053 INFO     Running step 'floorplan' in dir 'build/gcd/job2/floorplan'
2021-04-26 18:04:24,237 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:24,237 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:25,377 INFO     Running step 'place' in dir 'build/gcd/job2/place'
2021-04-26 18:04:25,377 INFO     Running step 'place' in dir 'build/gcd/job2/place'
2021-04-26 18:04:25,577 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:25,577 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:30,170 INFO     Running step 'cts' in dir 'build/gcd/job2/cts'
2021-04-26 18:04:30,170 INFO     Running step 'cts' in dir 'build/gcd/job2/cts'
2021-04-26 18:04:30,398 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:30,398 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:36,294 INFO     Running step 'route' in dir 'build/gcd/job2/route'
2021-04-26 18:04:36,294 INFO     Running step 'route' in dir 'build/gcd/job2/route'
2021-04-26 18:04:36,566 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:36,566 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:55,275 INFO     Running step 'dfm' in dir 'build/gcd/job2/dfm'
2021-04-26 18:04:55,275 INFO     Running step 'dfm' in dir 'build/gcd/job2/dfm'
2021-04-26 18:04:55,525 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:55,525 INFO     openroad -no_init -exit /home/noah/siliconcompiler/eda/openroad/sc_apr.tcl > openroad.log
2021-04-26 18:04:56,695 INFO     Running step 'export' in dir 'build/gcd/job2/export'
2021-04-26 18:04:56,695 INFO     Running step 'export' in dir 'build/gcd/job2/export'

It doesn't actually seem to be breaking the GCD example, but I think it might be affecting the FPGA examples. I can debug further if you don't have a chance to look soon, but have to sign off for now so just wanted to open an issue to draw your attention to this.

Klayout hard coded value

@WRansohoff

Small issue, but can you look at the klayout_setup file. There is a compelling use case for using klayou for some real technologies, so the klayou should probably query the cfg at run time:

options.append('in_gds=%s/%s'%(
               sc_root,
               chip.cfg['stdcell']['NangateOpenCellLibrary']['gds']['value'][-1]))

Help function

@aolofsson
Help function needs to be revamped,
-keep short function by default
-Add extra custom print at end witih text wrap

Suggestion for how to define targets

In light of all the refactoring going on, I wanted to propose an idea for what I think might be a better way to represent default targets - I think it could be cleaner to represent them as data rather than code, and then have code that operates on that data. For example, I think it might be nice to represent all the default targets in one dictionary. This dictionary could live in one file (siliconcompiler/targets.py), or perhaps split among different files and constructed by appending entries to the main dictionary. In any case, as a sketch of what I think something like this could look like:

DEFAULT_ASIC = {"mode": "asic",
                "flow": [{"step": "import", "vendor": "verilator", "tool": "verilator"}, 
                         {"step": "syn", "vendor": "yosys", "tool": "yosys"},
                         ...]
               }

targets = {
  "freepdk45": DEFAULT_ASIC,
  "asap7": DEFAULT_ASIC,
  "ice40": {"mode": "fpga", 
            "flow": [{"step": "import", "vendor": "verilator", "tool": "verilator"},
                     {"step": "syn", "vendor": "yosys", "tool": "yosys"},
                     ...
                     {"step": "export", "vendor": "icepack", "tool": "icepark"}] 
            }, 
   ...
}

With this setup Chip.target() could contain code that indexes into this dictionary using the received target name, and then use the data in the dictionary to populate the schema, import EDA tool settings, etc..

I think this accomplishes two main things:

  1. It removes the need for boilerplate in target files, for example the following would no longer have to be duplicated:
 packdir = "eda." + vendor    
module = importlib.import_module('.'+vendor, package=packdir)
setup_tool = getattr(module,'setup_tool')
setup_tool(chip, step)

This would make future refactoring easier, since it reduces duplicated code.

  1. I think it makes the configuration of default targets more readable. This is more of a matter of personal preference, but I find it easier to read something like this dictionary structure rather than code like:
  for step in chip.cfg['steps']['value']:            
      if step == 'import':
          vendor = 'verilator'
      elif step == 'syn':
          vendor = 'yosys'   
      elif step == 'export':
          vendor = 'klayout'
      else:
          vendor = 'openroad'

I'm open for thoughts on this! If you think it might be a good idea, I'm also happy to draft a PR that fleshes out the idea into something working and concrete -- I don't think it would take too long.

Include constraints files in the 'import' step?

I could be wrong, but I don't think that that the constraints file is being included in the import step. At the moment, I think that the remote commands might only be working correctly because the remote and test servers also contain the siliconcompiler/examples/gcd/constraint.sdc file.

We should probably make sure that the SDC file is copied into the import/ directory, and passed through the inputs/outputs directories in the same way that the Verilog sources are. Right now, I don't see a <design>.sdc file until the floorplan/outputs directory.

Implement generic vpr target in fpga.py

@nmoroze

I put in some code in fpga.py as a placeholder for nextpnr. Hopefully this together with the freepdk45 will show how easy it is to add a new target. You get to be the testpilot.:-)

asic.py and fpga.py are the default flows if the user only gives a single string as target, ie feepdk45.

If the user gives _ as a target then an foo.py would need to exist in the /asic/targets

Does that make sense?

eda/targets/fpga.py

`Chip.target()` method adds duplicate entries when a config file is loaded.

It looks like the Chip.add(...) method which is used in Chip.target() will add duplicate values to the config dictionary if a target was already defined.

This is an issue for the cloud workflow, because when the -cfg flag is used to pass in a config file, the target values get defined twice. This causes issues in the build scripts as, for example, yosys tries to load the "NangateOpenCellLibrary NangateOpenCellLibrary" target library.

For now, I'm working around the issue by only calling chip.target() from cli.py if the -cfg flag is not passed in. But I'm not sure if that is a good long-term solution, so I thought I'd raise an issue instead of submitting that change as part of a PR.

GUI not implemented

Place holder:...Idea would be to generate a decent looking html page with css, html based linkable report and an SVG showing the floorplan.
From core.py:
if(self.cfg['sc_gui']['values']):
webbrowser.open("https://google.com")

Enable CI tests on pull requests from forks

By default, GitHub actions do not run on pull requests from forks of private repositories. I think that limitation is preventing the CI tests from running on PRs from Noah and I.

Fortunately, they recently added an option to enable actions from private forks, but it's still opt-in. Could you please enable this setting for the siliconcompiler repository? These two pages discuss the option and how to enable it:

https://docs.github.com/en/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository#enabling-workflows-for-private-repository-forks

https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

I think we should only need the "Run workflows from fork pull requests" option. Thanks!

Alternative dictionary initializations in `defaults()`?

Currently, the defaults() method in core.py initializes a number of small dictionaries describing command-line switches like this:

    default_cfg['sc_gui'] = {}
    default_cfg['sc_gui']['help'] = "Launches GUI at every stage"
    default_cfg['sc_gui']['values'] = False
    default_cfg['sc_gui']['switch'] = "-gui"

Python lets you define all of those keys in a single declaration, e.g.:

    default_cfg['sc_gui'] = {
        'help':   "Launches GUI at every stage",
        'values': False,
        'switch': "-gui",
    }

You can also nest arrays, dictionaries, etc. into the latter syntax. Do you think it would be worth making a PR with a quick conversion of the existing keys, or do you like them the way they are?

Strange openroad replace behavior

global_placement -disable_routability_driven -density 0.3 #-->completes
global_placement -disable_routability_driven -density 0.2 #-->complains about density!?
global_placement -disable_routability_driven #-> fails to converge
global_placement #-->core dump

I will close this with the openroad team.

Add filter policy

@aolofsson
User should be able to specify files to keep, or files to delete at the end of the run.
Gets used by the post processing command
Reference flows , produce ridiculous amounts of data, no need to keep all of them

Fail on error

@WRansohoff

Not a big deal, but now when flow errors, out the exit message is a bit confusing, if the error in the route, the program should stop dead if possible (with the logger ERROR being the last message).

2021-04-20 09:08:09,261 ERROR Command failed. See log file ***/siliconcompiler/build/route/job1/openroad.log
2021-04-20 09:08:09,272 ERROR Task exception was never retrieved
future: <Task finished name='Task-1' coro=<Chip.run() done, defined at ***/siliconcompiler/siliconcompiler/core.py:788> exception=SystemExit()>
Traceback (most recent call last):
File "/usr/lib/python3.8/asyncio/base_events.py", line 603, in run_until_complete
self.run_forever()
File "/usr/lib/python3.8/asyncio/base_events.py", line 570, in run_forever
self._run_once()
File "/usr/lib/python3.8/asyncio/base_events.py", line 1859, in _run_once
handle._run()
File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
self._context.run(self._callback, *self._args)
File ***/siliconcompiler/siliconcompiler/core.py", line 980, in run
sys.exit()
SystemExit

Missing 'sc_schema.tcl' file?

I've updated the asynchronous logic to use the multiprocessing module, and it looks like a simple change. Thank you for pointing that library out to me.

But when I checked out the most recent version of main to make a PR, I started to get the following error starting in the floorplan step:

[ERROR STA-0511] cannot open './sc_schema.tcl'.

Is there an sc_schema.tcl file that needs to be committed for the OpenROAD refactor? I didn't see any in the eda/ or siliconcompiler/ directories. Thanks!

LICENSE File

I was looking into adding some badges to the top of the readme, and I realized that the siliconcompiler repository doesn't appear to have a license file yet.

If you've decided which one you want to use, one common place for the license text is in a LICENSE file at the root of the repository.

Loopback test for scserver

@WRansohoff

Since I am still making slight API changes it would be good if there as a loop back test for the client/server that I could run locally to make sure I can fix what I can.

Dynamic loading

@aolofsson
Remove root from tool setup, no need for it if the cfg is passed in. There is only need for one parameter, "SCLIB_ROOT", similar to LDPATH or PYTHONPATH.

DEF viewer

The chosen app for viewing def/lef/gds is the external program "klayout".
No sense to replace it, but thereneeds to be some work to make sure we can load design.def
by simply doing something like

klayout -c script.py desgin.def

klayout [] [] ..
options
-b Batch mode (same as -zz -nc -rx)
-c Use this configuration file
-nc Don't use a configuration file (implies -t)
-d Set debug level
-e Editable mode (allow editing of files)
-ne Readonly mode (editing of files is disabled)
-gr Record GUI test file
-gp Replay GUI test file
-gb Replay GUI test file up to (including) line
-gx Replay rate for GUI test file
-gi Incremental logs for GUI test file
-i Disable undo buffering (less memory requirements)
-ni Enable undo buffering (default, overrides previous -i option)
-j Add the given path to the macro project paths
-l Use layer properties file
-lx With -l: add other layers as well
-lf With -l: use the lyp file as it is (no expansion to multiple layouts)
-m Load RDB (report database) file (into previous layout view)
-mn Load L2NDB (layout to netlist database) file (into previous layout view)
-n Technology to use for next layout(s) on command line
-nn Technology file (.lyt) to use for next layout(s) on command line
-p Load the plugin (can be used multiple times)
-r <script> Execute main script on startup (after having loaded files etc.)
-rm <script> Execute module on startup (can be used multiple times)
-rd = Specify skript variable
-rx Ignore all implicit macros (*.rbm, rbainit, *.lym)
-s Load files into same view
-t Don't update the configuration file on exit
-nt Update the configuration file on exit (default, overrides previous -t option)
-u Restore session from given file
-v Print program version and exit
-wd = Define a variable within expressions
-x Synchronous drawing mode
-y Package installation: install package(s) and exit - can be used more than once
('package' is a name, an URL and optionally a version in round brackets)
-yd With -y: include dependencies
-z Non-GUI mode (hidden views)
-zz Non-GUI mode (database only, implies -nc)

Helper functions

A few functions needed to support schema....put in schema.py?
Really part of the definition)

Function#1
-def boolean compare with string, checks if the value is (True, true, TRUE,TRuE) and always takes the last value of the list.
This comes from the fact hat the boolean switches are recorded as strings and a list
-One tradeoff made that signifcantly simplified the code, but is currently making it harder for user

Function#2
-def resolve path. We made $SC_ROOT explicit in the json. This means it needs to be resolved at the receiver. It's a linux centric world, but so is EDA...keeping the $SC_ROOT in plain sight makes it easier to debug paths which is critical. Copy past from json to terminal.

CLI switch generator broken

@aolofsson

Dynamic dictionary switch generator broken...need some quiet time to rethink this. Starting to look ugly, should not be,..just an effect of starting with a very simple dict and now having something quite complex. Need to look at how many unique rules there are...

Multiprocessing shared memory issue?

@WRansohoff
Not sure if this was happening to you as well, but the summary function at the end of the cli is failing?
Could be a problem on my end but I think it might be a shared memory issue wrt to multiprocessing?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.