SiliconCompiler is an open source compiler framework that automates translation from source code to silicon.

siliconcompiler

Last update: Jan 4, 2023

Related tags

Miscellaneous siliconcompiler

Overview

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

Mission

SiliconCompiler is an open source compiler framework that aims to automate translation from source code to silicon.

Project Overview

The SiliconCompiler project includes a standardized compiler data Schema, a Python object oriented API, and a distributed systems execution model. The project philosophy is to "make the complex possible while keeping the simple simple".

Intrigued? Check out the extensive documentation!

import siliconcompiler                    # import python package
chip = siliconcompiler.Chip()             # create chip object
chip.target('asicflow_freepdk45')         # load pre-defined flow
chip.set('source', 'heartbeat.v')         # define list of sources
chip.set('design', 'heartbeat')           # set top module name
chip.set('constraint', 'heartbeat.sdc')   # define constraints
chip.set('remote', True)                  # compiler remotely
chip.run()                                # run compilation
chip.summary()                            # print run summary
chip.show()                               # show layout

Command Line Interface

Command line interface programs are very effective for quick experimentation. SiliconCompiler includes a command line program 'sc', with full support for all compiler schema parameters. For simple designs, compiling using sc is as easy as using gcc or llvm.

flipflop.v sc flipflop.v -remote">

pip install siliconcompiler
echo "module flipflop (input clk, d, output reg out); \
	always @ (posedge clk) out <= d; endmodule"> flipflop.v
sc flipflop.v -remote

More complex designs are handled by simply adding more options.

sc hello.v add.v -remote -constraint hello.sdc -target "asicflow_skywater130"

Installation

SiliconCompiler is available as wheel packages on PyPI for macOS, Windows and Linux platforms. Full complete installation instructions see the Installation Guide. If you already have a working Python 3.6-3.10 environment, just use pip:

python -m pip install siliconcompiler

To install the project from source (supported on Linux and macOS platforms):

git clone https://github.com/siliconcompiler/siliconcompiler
cd siliconcompiler
git submodule update --init --recursive third_party/tools/openroad
pip install -r requirements.txt
python -m pip install -e .

External Dependencies

Installation instructions for all external tools can be found in the Tools Directory. For the '-remote' option, there are no external dependencies.

Contributing

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

Issues / Bug Reports

We use GitHub Issues for tracking requests and bugs.

License

Apache License 2.0

Comments

Precedence between values set explicitly vs by `chip.target()` call
When working on ZeroSoC's build script, I set a value for chip.cfg['stop'] and noticed that it wasn't being respected. I realized this is because I ran chip.target() after setting the value for chip.cfg['stop'], which overrides it back to the default value.

At first I thought this should be considered a bug, since it seemed a little counterintuitive. However, I'm not sure there's a clean way to prioritize values set by the user vs values set by the target, so I'm thinking we should probably clearly document that chip.target(...) overrides configuration values the user may have set, and perhaps emphasize crafting scripts like this in examples:

chip.target('target') # custom configuration here, after target call... chip.run()
opened by nmoroze 10
Add VPR submodule

This PR integrates VPR flow with Yosys to create a full open-source FPGA flow. A Verilog library has been added to Yosys in order to support hard blocks defined in a typical VPR architecture file.

opened by kimiatkh 9
Fix report generation for remote runs.

The report generation logic relies on some schema parameters which get removed by the server sanitizer, so we need a bit of logic to make that part of the summary() function fault-tolerant, and to generate a final report locally after a remote run.

opened by WRansohoff 9
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?

opened by aolofsson 9
Klayout formatting failure

https://github.com/siliconcompiler/siliconcompiler/blob/a202264ed29cbb960d85fad3be29cd071d4e66b2/siliconcompiler/tools/klayout/def2stream.py#L225 https://github.com/siliconcompiler/siliconcompiler/blob/a202264ed29cbb960d85fad3be29cd071d4e66b2/siliconcompiler/tools/klayout/def2stream.py#L226

These two lines keep messing me up with an invalid syntax error. changing them to '{0}.def'.format(design) appears to work, not sure why the current one doesn't work.

opened by gadfort 7
Account for `environment` parameters being stored as an array

The environment schema parameter is stored as an array, not a string. So it probably makes sense to use ':'.join with these values, even though there's usually only one value for each environment variable.

opened by WRansohoff 7
Netgen LVS run failed for example design because of mismatch in number of nets

I've run the example design, heartbeat, with DRC/LVS enabled and get a mismatch in the number of nets, meaning that LVS fails. I see a similar problem with other designs I've run.

Circuit 1 contains 34 devices, Circuit 2 contains 34 devices. Circuit 1 contains 53 nets, Circuit 2 contains 104 nets. *** MISMATCH ***

Result: Netlists do not match. Logging to file "outputs/heartbeat.lvs.out" disabled LVS Done.

I've attached the lvs.log. lvs.log .

opened by jarvis-lorry 7

Core API change. remove add() method [inputs needed]

The current API has a method for set() and one for add(). The add() method appends value to existing list while the set always clears. This is a bit historical since we used to not treat scalars vs lists so transparently. Now that we look at the type field before writing, this is no longer needed.

The proposal is to remove the add method and make the set method append a value by default for lists (for scalars it doesn't matter). A 'clear' argument is added for the rare cases where we want to reset the list before updating. Not found in any case so far.

The gcd example is passing with this new change.

Any objections?

def set(self, *args, chip=None, cfg=None, clear=False):
        '''
        Sets a Chip dictionary value based key-sequence and data provided.

        Accesses to non-existing dictionary entries results in a logger
        error and in the setting the 'chip.error' flag to 1. For built in
        dictionary keys with the 'default' keywork entry, new leaf trees
        are automatically created by the set method by copying the default
        tree to the tree described by the key-sequence as needed.

        The data type provided must agree with the dictionary parameter 'type'.
        Before setting the parameter, the data value is type checked.
        Any type descrepancy results in a logger error and in setting the
        chip.error flag to 1. For descriptions of the legal values for a
        specific parameter, refer to the schema.py documentation. Legal values
        are cast to strings before writing to the dictionary. Illegal value
        are not written to the dictionary. For list types, the default
        behavior is to append the provided value to the existing list. For
        scalar types, the old value is always cleared before writing in the
        new value provided.

        Args:
            args (string): A variable length key list used to look
                up a Chip dictionary entry. For a complete description of the
                valid key lists, see the schema.py module. The key-tree is
                supplied in order.
            chip (object): A valid Chip object to use for cfg query.
            cfg (dict): A dictionary within the Chip object to use for
                key list query.
            clear (bool): If True, the new data value overwrites the old value,
                otherwise the new value is appended to the current list. The
                option is ignored for scalar types.

        Examples:
            >>> set('source', 'mydesign.v')
            Sets the file 'mydesign.v' to the list of sources.
        '''

opened by aolofsson 7

Add layer width to schema

re: our discussion the other day, I'm adding the layer default routing width to the schema since the floorplan API relies on it, and Skywater doesn't have the same width = pitch/2 relationship that FreePDK45 does.

Also, something I noticed while making this PR: looks like you changed the pitches for the first 3 layers in a recent commit. Is there a source you're using for why it should be that way? It doesn't seem to match what's in the tech lef (each of the layers only has a single pitch value), but I was wondering if it has to do with some sort of override OpenROAD uses or something like that.

opened by nmoroze 7
quickstart guide

I received an error while running the following command from the tutorial. Could you please point out what i am missing?

Command: python -c "import siliconcompiler;chip=siliconcompiler.Chip();print(chip.get('version','sc'))"

Error message: .../venv/lib64/python3.6/site-packages/siliconcompiler/crypto.py:3: CryptographyDeprecationWarning: Python 3.6 is no longer supported by the Python core team. Therefore, support for it is deprecated in cryptography and will be removed in a future release. from cryptography.hazmat.backends import default_backend Traceback (most recent call last): File "", line 1, in TypeError: init() missing 1 required positional argument: 'design'

opened by arlted 6
Adjust behavior of ['tool', , 'continue'] to always fail on fatal error
I think the current behavior of ['tool', <tool> ,'continue'] is unideal. It's necessary in some cases because your tool produces nonfatal errors, but even in these cases I think you don't want the flow to continue running if the tool errors out with a nonzero status, since in that case future steps are probably pretty likely to fail.

This PR proposes the simplest possible change, which is to always kill the flow if the tool exits with a nonzero status. Another proposal that I'd be happy to implement would be to make 'continue' take a few possible values, something like:

"never": always quit on any error condition

"nonfatal": only quit on fatal errors (always continue if tool quits successfully)

"always": flow always continues
opened by nmoroze 6
Library import

When loading a library, a bunch of default values get pulled. This will likely go away with move to python modules.

chip.import_library(lib)

dict set sc_cfg library nangate45 option msgcontact [list ] dict set sc_cfg library nangate45 option metricoff [list ] dict set sc_cfg library nangate45 option clean [list false] dict set sc_cfg library nangate45 option hash [list false] dict set sc_cfg library nangate45 option nodisplay [list false] dict set sc_cfg library nangate45 option quiet [list false] dict set sc_cfg library nangate45 option jobincr [list false] dict set sc_cfg library nangate45 option novercheck [list false]

opened by aolofsson 0
gdsfactory integration

Hi,

what are your thoughts of supporting gdsfactory as one of the tools offered by silicon compiler? https://gdsfactory.github.io/gdsfactory/README.html

I love your client server architecture for running large jobs, and gdsfactory users could benefit from it https://github.com/gdsfactory/gdsfactory/issues/331

@aolofsson @nmoroze @proppy @skandanc @simbilod @tvt173 @thomasdorch

opened by joamatab 0
`archive()` enhancements
[ ] Archive multiple jobs into one tarball

[ ] Give some indication of progress

[ ] Performance on large build directories

[ ] Even lighter-weight mode that just includes certain/final outputs and logs
opened by nmoroze 0
Draft idea: Remove `merge_manifest` function

This PR contains an alternative, more radical solution to #1061 (compared with #1172): maybe we could remove the whole process of merging manifests.

Considering that we originally implemented partial merges for the sake of performance, maybe it's worth considering a less holistic approach to the process of updating the manifest between tasks. Instead of striving for a one-size-fits-all set of rules to merge arbitrary schema parameters, maybe we could handle parallel input tasks by fully re-loading one task's output manifest, and then importing known output fields from the others (metrics, reports, flowgraph status, file hashes).

Being able to resume or review a run using only its manifest, with no critical state saved during the run, seems like a generally good goal.

There are a few workarounds in this PR to get all of the CI tests to pass, and I can think of good reasons to avoid making such a deep change, so we should review this more closely if it seems like it could be a good idea.

opened by WRansohoff 1
Fix input/output file hash tracking

This is a small change to address issue #1061 so that SiliconCompiler's manifests can be used to determine the file hashes for a design's final inputs and outputs, but it has performance implications that we may want to discuss.

The change allows the schema's file hashes to propagate through a flow by updating the merge_manifest method to include file-type parameters in partial updates. I also tried allowing library schemas (whose files sometimes get hashed) to be read from the prior manifest rather than re-imported, but I ran into issues with CI and runtime.

This impacts the performance of the manifest-merging, because chip.get is a fairly hefty call to add for each keypath. On the minimal heartbeat example, merge runtimes (measured using time.monotonic around the calls to _merge_manifset) increased from 2-15ms to 28-44ms. That is a significant increase, but still a large reduction from a non-partial merge which takes 110-130ms per step.

I experimented with parallelizing this logic using multiprocessing to let us remove the _key_may_be_updated check, but that ended up significantly increasing the runtime. I think that Python's GIL and the need for a thread-safe dictionary data structure may prevent efficient parallel writes.

opened by WRansohoff 0

Releases(v0.9.6)

v0.9.6(Oct 4, 2022)
Major:

Fixed bug that causes tool setup information to be lost when running a flow in multiple chunks using a steplist.

Minor:

Fixed old schema references in Yosys synthesis strategy scripts.

Updated error message for missing file requirements.

Updated OpenROAD scripts to handle multiple LEF files.

Updated KLayout driver to use batch mode flag and capture more warnings.

Updated Verilator driver to implement ['option', 'trace], ['option', 'warningoff'], and provide passthroughs for CFLAGS and LDFLAGS.

Removed support for 'extraopts' passthrough in Verilator driver.

Updated version of Surelog bundled with wheels distribution.

Source code(tar.gz)
Source code(zip)
v0.9.5(Sep 16, 2022)
Minor:

Schema: Added ['tool', <tool>, 'prescript'/'postscript', <step>, <index>] to support user-supplied pre- and post-scripts for script-based tools.

Schema: Added ['tool', <tool>, 'file', <step>, <index>] passthrough parameter.

Added runtime logic to terminate tools that do not exit on their own after a job is interrupted with ctrl-c.

Fixed KLayout show bugs.

Fixed issue building SC in editable mode using newer versions of Pip/setuptools.

Source code(tar.gz)
Source code(zip)
v0.9.4(Aug 26, 2022)
Major:

Changed run() logic to not reset metrics to zero.

summary() will only display metrics that have been explicitly set.

Minor:

Schema: Changed ['constraint', <scenario>, 'libcorner'] from scalar to list.

Added support for --latches option in GHDL driver.

Added :keypath: directive to distributed Sphinx extensions.

Added reports and final manifest to archive() outputs.

Fixed bug where job argument to find_files() was not handled properly.

Fixed pin sizes and PDN vias in Caravel wrapper example.

Updated flow scripts to support newer version of OpenROAD.

Updated version of Surelog bundled with wheels distribution.

CI hint: NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.9.3(Aug 2, 2022)
Major:

Added basic editing functionality for signoff checklists in HTML report.

Changed file collection behavior:

For local runs, inputs are not copied into import/ at all.

For remote runs, inputs are copied into import/0/inputs/ only, not output/.

Implemented ['option', 'entrypoint'], allowing users to specify an alternative top-level.

Implemented support for "pure Python" tools.

A run() method inside a tool setup file will be run instead of an executable.

Minor:

Changed run() behavior to read metrics from all leaf tasks.

Fixed implementation of ['option', 'jobincr'].

Fixed bug causing exception on summary() for machines with a default encoding other than UTF-8.

Fixed logfile reading logic to gracefully handle invalid characters.

Improved error messages for some common issues.

Source code(tar.gz)
Source code(zip)
v0.9.2(Jul 10, 2022)
Major:

Schema: Added ['option', 'flowcontinue'] to control whether flow continues when a tool reports errors.

This used to be controlled by ['tool', <tool>, 'continue'], but this parameter is meant to feed directly into tools (rather than controlling the SC runtime).

Schema: Added ['option', 'continue'] parameter to control whether errors in the Python API are fatal.

The default value makes errors fatal, setting this parameter to True reverts to the old behavior.

Added VPR-based FPGA bitstream generation flow.

Added logic to set errors and warnings metrics based on ['tool', <tool>, 'regex', ...] matches. This reduces tool driver boilerplate and makes the metrics consistent with the generated regex match files.

Minor:

Changed default technology target for sc app.

Changed KLayout show script to always use a dark background.

Changed check_manifest() to allow tool tasks to have multiple inputs (behaving as if they were merged with a "join" builtin).

Changed check_manifest() to return True on success rather than 0 (the previous behavior didn't match the documentation).

Changed Yosys and OpenROAD tool drivers to make them easier to use in flows with alternate step names.

Changed GHDL tool driver to allow additional CLI options via ['tool', <tool>, 'var', ..., 'extraopts'].

Removed return codes from post_process().

Source code(tar.gz)
Source code(zip)
v0.9.1(Jun 21, 2022)
Major:

Added input filetype inference based on file extension (restores functionality lost in 0.9.0).

Added manifest tree viewer to HTML report.

Added simulator exe compilation support to Verilator.

Improved TCL manifest generation:

Fixed escaping of special characters and whitespace.

Fixed insertion of "$env" in filepaths.

Changed tuple printing to be TCL list instead of tuple-like string.

Minor:

Schema: Added tool CLI arguments to ['record', ...] schema.

Changed create_cmdline() switchlist parameter to accept switch names as specified on command line.

Changed setup module docs generator to be packaged with SC.

Changed HTML report to be self-contained.

Fixed CSV manifest generation.

Source code(tar.gz)
Source code(zip)
v0.9.0(May 19, 2022)
Major:

Schema: Reorganized entire schema! Changes summarized below:

Cleaned and consolidated top-level organization, most parameters are now nested.

Moved build configuration options underneath ['option', ...].

Added ['output', ...] to store pointers to flow outputs.

Added ['model', ...] to store pointers to design abstractions (timing libraries, layouts, etc).

Added ['datasheet', ...] to store information about design's interface.

Renamed ['eda', ...] to ['tool', ...]

Renamed ['mcmm', ...] to ['constraint', ...]

Replaced ['source'], ['constraint'], and ['read', ...] with more flexible ['input', <filetype>] to supply input files.

Added support for storing multiple PDKs in schema and selecting which one to use for run (analagous to flows).

Schema: Removed special ['library', ...] keypaths. All libraries are now created as Chip objects, and have their full config imported into a parent chip's schema.

Added ability to configure stdout and stderr redirection on a per-tool basis (thanks to @suppamax for implementing).

Added flexible tool version checking based on PEP-440 standard, now enabled by default.

Added 'clean' feature for cleaning up intermediate tool outputs.

Added 'resume' feature for restarting failed flows (for debugging).

Added automatic capture of peak memory usage (adds dependency on psutil).

Changed ['design'] to be a required parameter for instantiating a Chip.

Changed error behavior to consistently raise exceptions rather than exit.

Removed tool script copy feature, so now all EDA scripts are run from the reference directory.

Minor:

Schema: Added ability to store per-parameter designer notes.

Added offline wheels distribution.

Added checklist support.

Added read_lef() function to help with PDK bring-up.

Added environment variables to replay scripts.

Added LVS/DRC signoff flow and top-level GDS stream out flow.

Added native support for Sky130 I/O library, along with Heartbeat + padring example.

Changed internals to minimize SC performance overhead with large flowgraphs.

Changed task runtime tracking to distinguish between time spent in tool and total time.

Fixed breakpoints to work more consistently across tools.

Note: Since there was no public release of version 0.8.0, this list summarizes all changes since 0.7.0.

CI hint: NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.7.0(Mar 3, 2022)
Major:

Schema: Added ability to specify environment variables on a per-tool, per-task basis.

Schema: Added per-tool 'techmap' parameter to library schema.

Added browser-viewable report generation to core.summary().

Minor:

Schema: Added filetypes to library schema: 'def', 'gerber', 'netlist', 'model' category.

Schema: Added 'stackup' key to library lef/gds parameters.

Schema: Changed 'pdk' and 'stackup' library parameters to lists.

Schema: Added 'dir' passthrough to library schema.

Schema: Added 'nodisplay' option to schema to better support headless jobs.

Schema: Added 'licensefile' to package parameters to support non-standard licenses.

Schema: Added 'gerber' to read schema.

Schema: Added several cell categories to library schema.

Changed how PDK-specific Yosys and OpenROAD parameters are driven to avoid hardcoding process info in tool drivers.

Fixed step ordering bug in core.summary().

Fixed bug with how 'arg', 'index' is handled.

Fixed small bugs in automatic documentation generation.

Added core.check_filepaths() helper.

CI hint: NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.6.0(Feb 14, 2022)
Major:

Schema: Added 'flow' key to flowgraph to enable multi-flow targets.

Schema: Added 'flow' parameter to enable selection between flows in flowgraph.

Schema: Changed '_' separated tuple target to a single 'module' load target.

Schema: Added 'regex' for grep like functionality.

Schema: Changed metal grid to use PDK metal name as the major key.

Schema: Added 'tool' key to PDK settings to avoid tool file conflicts.

Schema: Added 'units' parameter to enable tech agnostic SDC.

Schema: Added ability to specify tricky apr setup files on a per tool basis (tracks, taps, vias, antenna, etc).

Schema: Added checklist functionality

Added core.grep function

Added core.check_logfile function to core API to emulate grep behavior

Added core.load_{target, flow, lib, pdk} functions to core API in place of target()

Added asap7 target

Added docker support for basic RTL2GDS tool chain

Removed core.target() function

Minor:

Schema: Changed lib 'driver' to move into cells (consistency)

Schema: Added site symmetry to avoid full lef parser.

Schema: Changed tool version switch to a list

Schema: Changed 'asic', 'targetlib' to 'asic', 'logiclib' for clarity.

Schema: Changed 'eda, 'report' parameter guideline to always use 'metric' as keyword

Schema: Added -skip_check option to speed up new target bringup

Schema: Added -skip_step option to enable skipping specific steps

Schema: Added 'pdk', ['file', 'directory', 'variable'] parameters to enable tool-specific PDK setups.

Schema: Changed cell types to be hardcoded (tapcell, buf, clkbuf, etc) to avoid fragmentation.

CI hint: NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.4.1(Jan 6, 2022)
Fix bug in Yosys parameter requirements spec that made check_manifest() too scrict

Source code(tar.gz)
Source code(zip)
v0.4.0(Jan 5, 2022)
Happy New Year!

Schema updates

Add 'tool' key to PDK fields

Clean up unneeded 'record' keys

A few other misc. changes

Functionality changes

Implement automatic record-keeping

Implement -I CLI switch for include directory

Implement checks that flow make sense in terms of file I/O and that required files resolve

Allow importing multiple files with the same basename

Automatically configure KLayout path on macOS

Bug fixes

Fix sc-show to use 'read' schema introduced in last release

CI hint: NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.3.1(Dec 21, 2021)
Fix sc-show on WIndows

NOPUBLISH
Source code(tar.gz)
Source code(zip)
v0.3.0(Dec 21, 2021)
First release since v0.1.1, we skipped the v0.2.0 release.

Schema update: add 'read' section (marked as v0.2.0)

Schema update: tweak 'eda' schema a bit

Fix old version of Surelog bundled with wheels

Alternate frontend support: Python, C, Chisel

Note: new 'frontend' parameter replaces 'flowarg', 'sv'

Other small misc. changes

CI hint: NOPUBLISH (we will publish manually)
Source code(tar.gz)
Source code(zip)
v0.1.1(Dec 8, 2021)
Prevent sc-show crash when PDK files are not found

Ensure sc-show can find KLayout executable on Windows

Source code(tar.gz)
Source code(zip)
v0.1.0(Dec 3, 2021)

Source code(tar.gz)
Source code(zip)

Owner

siliconcompiler

The Silicon Compiler Project

GitHub

This Program Automates The Procces Of Adding Camos On Guns And Saving Them On Modern Warfare Guns

6 May 26, 2022

Python script that automates the tasks involved in starting a new coding project

Auto Project Builder Automates the repetitive tasks while starting a new project Installation Use the REQUIREMENTS.txt file to install the dependencie

1 Feb 3, 2022

The most widely used Python to C compiler

Welcome to Cython! Cython is a language that makes writing C extensions for Python as easy as Python itself. Cython is based on Pyrex, but supports mo

7.6k Jan 3, 2023

Reactjs web app written entirely in python, using transcrypt compiler.

22 Nov 27, 2022

A small C compiler written in Python for learning purposes

A small C compiler written in Python. Generates x64 Intel-format assembly, which is then assembled and linked by nasm and ld.

3 Oct 22, 2021

a simple functional programming language compiler written in python

Functional Programming Language A compiler for my small functional language. Written in python with SLY lexer/parser generator library. Requirements p

3 Nov 5, 2021

Pulse sequence builder and compiler for q1asm

q1pulse Pulse sequence builder and compiler for q1asm. q1pulse is a simple library to compile pulse sequence to q1asm, the assembly language of Qblox

3 Dec 14, 2022

MatroSka Mod Compiler for ts4scripts

MMC Current Version: 0.2 MatroSka Mod Compiler for .ts4script files Requirements Have Python 3.7 installed and set as default. Running from Source pip

1 Dec 13, 2021

This is a small compiler to demonstrate how compilers work.

This is a small compiler to demonstrate how compilers work. It compiles our own dialect to C, while being written in Python.

2 Jul 19, 2022

A C-like hardware description language (HDL) adding high level synthesis(HLS)-like automatic pipelining as a language construct/compiler feature.

██████╗ ██╗██████╗ ███████╗██╗ ██╗███╗ ██╗███████╗ ██████╗ ██╔══██╗██║██╔══██╗██╔════╝██║ ██║████╗ ██║██╔════╝██╔════╝ ██████╔╝██║██████╔╝█

391 Jan 1, 2023

A simple BrainF**k compiler written in Python

bf-comp A simple BrainF**k compiler written in Python. What else were you looking for?

1 Jan 9, 2022

Hotpile: High Order Turing Machine Language Compiler

Hotpile: High Order Turing Machine Language Compiler Build and Run Requirements: Python 3.6+, bison, flex, and GCC installed. Needs to be run under UN

4 Dec 29, 2021

Compiler Final Project - Lisp Interpreter

2 Jan 23, 2022

chiarose(XCR) based on chia(XCH) source code fork, open source public chain

chia-rosechain 一个无耻的小活动 | A shameless little event 如果您喜欢这个项目，请点击star 将赠送您520朵玫瑰，可以去 facebook 留下您的(xcr)地址，和github用户名。 If you like this project, please

376 Dec 14, 2022

Bionic is Python Framework for crafting beautiful, fast user experiences for web and is free and open source.

Bionic is Python Framework for crafting beautiful, fast user experiences for web and is free and open source. Getting Started This is an example of ho

14 Apr 10, 2022

An open-source hyper-heuristic framework for multi-objective optimization

MOEA-HH An open-source hyper-heuristic framework for multi-objective optimization. Introduction The multi-objective optimization technique is widely u

1 Feb 10, 2022

Source-o-grapher is a tool built with the aim to investigate software resilience aspects of Open Source Software (OSS) projects.

5 Jun 28, 2022

sawa (ꦱꦮ) is an open source programming language, an interpreter to be precise, where you can write python code using javanese character.

ꦱꦮ sawa (ꦱꦮ) is an open source programming language, an interpreter to be precise, where you can write python code using javanese character. sawa iku

307 Jan 7, 2023

Open Source defrag's mod code

Open Source defrag's mod code Goals: Code & License: Respect FOSS philosophy. Open source and community focus. Eliminate all traces of q3a-sdk licensi

1 Dec 10, 2022

SiliconCompiler is an open source compiler framework that automates translation from source code to silicon.

Related tags

Overview

Mission

Project Overview

Command Line Interface

Installation

External Dependencies

Contributing

Issues / Bug Reports

License

Comments

Releases(v0.9.6)

v0.9.6(Oct 4, 2022)

v0.9.5(Sep 16, 2022)

v0.9.4(Aug 26, 2022)

v0.9.3(Aug 2, 2022)

v0.9.2(Jul 10, 2022)

v0.9.1(Jun 21, 2022)

v0.9.0(May 19, 2022)

v0.7.0(Mar 3, 2022)

v0.6.0(Feb 14, 2022)

v0.4.1(Jan 6, 2022)

v0.4.0(Jan 5, 2022)

v0.3.1(Dec 21, 2021)

v0.3.0(Dec 21, 2021)

v0.1.1(Dec 8, 2021)

v0.1.0(Dec 3, 2021)

Owner

siliconcompiler

This Program Automates The Procces Of Adding Camos On Guns And Saving Them On Modern Warfare Guns

Python script that automates the tasks involved in starting a new coding project

The most widely used Python to C compiler

Reactjs web app written entirely in python, using transcrypt compiler.

A small C compiler written in Python for learning purposes

a simple functional programming language compiler written in python

Pulse sequence builder and compiler for q1asm

MatroSka Mod Compiler for ts4scripts

This is a small compiler to demonstrate how compilers work.

A C-like hardware description language (HDL) adding high level synthesis(HLS)-like automatic pipelining as a language construct/compiler feature.

A simple BrainF**k compiler written in Python

Hotpile: High Order Turing Machine Language Compiler

Compiler Final Project - Lisp Interpreter

chiarose(XCR) based on chia(XCH) source code fork, open source public chain

Bionic is Python Framework for crafting beautiful, fast user experiences for web and is free and open source.

An open-source hyper-heuristic framework for multi-objective optimization

Source-o-grapher is a tool built with the aim to investigate software resilience aspects of Open Source Software (OSS) projects.

sawa (ꦱꦮ) is an open source programming language, an interpreter to be precise, where you can write python code using javanese character.

Open Source defrag's mod code