chisel
opentitan
chisel | opentitan | |
---|---|---|
25 | 14 | |
3,717 | 2,357 | |
1.1% | 1.3% | |
9.7 | 10.0 | |
8 days ago | 5 days ago | |
Scala | SystemVerilog | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
chisel
-
Calyx: Intermediate Language for Hardware Accelerators
My first instinct was to ask "Does this play well with CIRCT?" And thankfully they answer that right away in the README.
I'm personally of the opinion that there is a LOT of room for improvement in the hardware design tooling space, but a combination of market consolidation, huge pressure to meet deadlines, and an existing functional pipeline of Verilog/VHDL talent is preventing changes.
That's not to say "Verilog/VHDL are bad", because clearly they've been good enough to support nearly all of the wonderful designs powering today's devices. But it is to say, "the startup scene for hardware will continue to look anemic compared to the SaaS scene until someone gives me all of the niceties I have for building SaaS tools in software."
A huge amount of ideas (and entire designs) start off as software sims, which enables kernel/compiler engineers to start building out support for new hardware before it's manufactured.
There is some interesting work going on at SiFive building hardware with Chisel[1], as well as some interesting work lead by a professor at William and Mary to improve simulations[2].
1: https://www.chisel-lang.org
2: https://github.com/sarchlab/akita
- Chisel: A Modern Hardware Design Language
-
I may be creating an abomination
Inspired by Scala. Which can do a whole lot more, and worse. The currently biggest competitor to decades old hardware description languages is a Scala DSL.
-
An addressable little explored language gap: HDL - Hardware Description Languages, any language used for electronic circuit design, description, and specs
Already mentioned Chisel: https://www.chisel-lang.org/
-
Trying to learn and work with FPGAs
I'm also a hobbyist. There are a number of alternative HDLs out there, and as hobbyists we can deviate more from the mainstream of (System)Verilog and VHDL if we desire, though you'll still need to be able to read them. In the past I've done Verilog, but lately I've been using SpinalHDL and have been really enjoying it. Its close relative Chisel also makes appearances in the RISC-V space.
- Alternate HDL language and Physical Design/EDA tools?
-
Learning VDHL after knowing Verilog
What are your thoughts on other HDLs like Chisel or BlueSpec when it comes to better type checking?
-
Learning Verilog and FPGA
I started playing with FPGAs and HDLs a couple years ago with no hardware design background (I'm mostly a software architect/engineer) and in the end found that a "higher-level" HDL suited me better.
I chose Chisel (https://www.chisel-lang.org/) an HDL based on Scala (technically a Scala DSL) which can provide many facilities to hardware generation.
I'd highly advise looking into it although also knowing Verilog helps a lot.
-
If you keep clicking "Give 15 seconds" on Lichess, eventually it overflows to a negative number and you win
But some go further and ask "what if when we add a soldering station on top of it?"
-
What universities have good PhD programmes in digital design?
In recent years Chisel HDL, RISC V, and SiFive came out of their architecture group, to name a few.
opentitan
-
Chisel: A Modern Hardware Design Language
Thanks for the info these all certainly sound like promising developments though I still think there's a major hurdles to overcome.
> good PPA with popular backend tools
Getting good PPA for any given thing you can express in the language is only part of the problem. The other aspect is how easy does the language make it to express the thing you need to get the best PPA (discussed in example below)?
> Think of it like a source map that allows you to jump back and forth between the final System Verilog and the source HDL.
This definitely sounds useful (I wish synthesis tools did something similar!) but again it's only part of the puzzle here. It's all very well to identify the part of the HDL that relates to some physical part of the circuit but how easy is it to go from that to working out how to manipulate the HDL such that you get the physical circuit you want?
As a small illustrative example here's a commit for a timing fix I did recently: https://github.com/lowRISC/opentitan/commit/1fc57d2c550f2027.... It's for a specialised CPU for asymmetric crypto. It has a call stack that's accessible via a register (actually a general stack but typical used for return addresses for function calls). The register file looks to see if you're accessing the stack register, in which case it redirects your access to an internal stack structure and when reading returns the top of the stack. If you're not accessing the stack it just reads directly from the register file as usual.
The problem comes (as it often does in CPU design) in error handling. When an error occurs you want to stop the stack push/pop from happening (there's multiple error categories and one instruction could trigger several of them, see the documentation: https://opentitan.org/book/hw/ip/otbn/index.html for details). Whether you observed an error or not was factored into the are you doing a stack push or pop calculation and in turn factored into the mux that chose between data from the top of the stack and data from the register file. The error calculation is complex and comes later on in the cycle, so factoring it into the mux was not good as it made the register file data turn up too late. The solution, once the issue was identified, was simple, separate the logic deciding whether action itself should occur (effectively the flop enables for the logic making up the stack) from the logic calculating whether or not we had a stack or register access (which is based purely on the register index being accessed). The read mux then uses the stack or register access calculation without the 'action actually occurs' logic and the timing problem is fixed.
To get to this fix you have two things to deal with, first taking the identified timing path and choosing a sensible point to target for optimization and second actually being able to do the optimization. Simply having a mapping saying this gate relates to this source line only gets you so far, especially if you've got abstractions in your language such that a single source line can generate complex structures. You need to be able to easily understand how all those source lines relate to one another to create the path to choose where to optimise something.
Then there's the optimization itself, pretty trivial in this case as it was isolated to the register file which already had separate logic to determine whether we were actually going to take the action vs determine if we were accessing the stack register or a normal register. Because of SystemVerilog's lack of powerful abstractions making a tweak to get the read mux to use the earlier signal was easy to do but how does that work when you've got more powerful abstractions that deal with all the muxing for you in cases like this and the tool is producing the mux select signal for you. How about where the issue isn't isolated to a single module and spread around (e.g. see another fix I did https://github.com/lowRISC/opentitan/commit/f6913b422c0fb82d... which again boils down to separating the 'this action is happening' from the 'this action could happen' logic and using it appropriately in different places).
I haven't spend much time looking at Chisel so it may be there's answers to this but if it gives you powerful abstractions you end up having to think harder to connect those abstractions to the physical circuit result. A tool telling you gate X was ultimately produced by source line Y is useful but doesn't give you everything you need.
> the combination of Chisel and CIRCT offers a unique solution to a deeper problem than dealing with minor annoyances in System Verilog: capturing design intent beyond the RTL
-
Ask HN: Who is hiring? (July 2023)
lowRISC https://lowrisc.org | Non-profit | Cambridge, UK | Zurich, Switzerland | Design Verification Engineers | Infrastructure Engineer | HYBRID | Full time
lowRISC's mission is to bring open source silicon to the hardware world and see it shipping in volume in commercial applications. We want to see open source silicon occupy a similar position to open source software (e.g. look at Linux, it's the default choice in many applications, we'd like open source silicon to be used for similar foundational technologies in the hardware world).
Our major project focus is OpenTitan: https://github.com/lowRISC/opentitan it’s a silicon root of trust being built and funded by a collaboration of major companies, such as Google, Western Digital, Seagate, Winbond and Rivos amongst others. lowRISC stewards the project as well as performing a significant proportion of the engineering work.
We’ve just announced the RTL freeze for the first OpenTitan tapeout, a discrete chip, named Earl Grey: https://lowrisc.org/blog/2023/06/opentitans-rtl-freeze-lever...
We’re looking for verification and infrastructure engineers to join us. We work in System Verilog and use UVM, though plan to expand our use of formal verification. We’re also keen to explore new innovative ways to verify designs.
A key responsibility for lowRISC is maintaining the CI and regression infrastructure for OpenTitan. This is a complex system running many different tools across different machines (both cloud and on-site) and involves FPGAs and custom hardware. We use ansible and terraform to manage it all. We’re seeking an infrastructure engineer to maintain and scale the system as well as architect and build new facets of it.
lowRISC is headquartered in Cambridge, UK and we have an office in Zürich, Switzerland. We utilize a hybrid working model.
We offer competitive salaries (see job ads for ranges) and a generous pension (12.5% employer contribution in the UK), you can find our individual job postings here: https://lowrisc.applytojob.com/apply/
Feel free to email me at [email protected] if you’ve got any questions.
-
Putting out the hardware dumpster fire
We're aiming to push things in the other direction with OpenTitan: https://github.com/lowRISC/opentitan/
It's an Open Silicon root of trust, all RTL (the actual hardware design in SystemVerilog), firmware, documentation and verification environment is open source and in the repository I just linked.
We're closing in on our first discrete chip (details here https://opensource.googleblog.com/2023/06/opentitan-rtl-free... and https://lowrisc.org/blog/2023/06/opentitans-rtl-freeze-lever...) and have lots more in the pipeline (our project director Dom Rizzo gave a keynote at the Barcelona RISC-V Europe summit recently with some details, sadly not available on video yet).
The hope is this will be a real proof point of the value of open source in hardware and, if as successful as we like it to be, can push the industry from a closed by default to people having to justify why they're not using open technology.
-
Looking to work in Open Source Silicon and RISC-V? lowRISC is hiring DV and infrastructure engineers
Our major project focus is OpenTitan: https://github.com/lowRISC/opentitan it’s a silicon root of trust being built and funded by a collaboration of major companies, such as Google, Western Digital, Seagate, Winbond and Rivos amongst others. lowRISC stewards the project as well as performing a significant proportion of the engineering work.
-
Towards a More Open Secure Element Chip
Interesting to see more potential entrants into this space. I work on OpenTitan https://opentitan.org/ which I believe will do much (indeed maybe everything) of what Cramium and Bunnie are aiming for (of course being a stealth startup hard to know what their plans actually are). We're at an advanced stage of development and being open you can take a look at our work right now https://github.com/lowRISC/OpenTitan our nightly regression dashboards demonstrate the project's maturity https://reports.opentitan.org/hw/top_earlgrey/dv/latest/repo... and https://reports.opentitan.org/hw/top_earlgrey/dv/summary/lat...
-
Phoronix: "AMD, Google, Microsoft & NVIDIA Announce "Caliptra" Open-Source Root of Trust"
Um hello? Google already has an open source hardware root of trust, called OpenTitan. Why didn't they just use that?
-
Google, Western Digital, Seagate quietly an open source root of trust
We've changed the URL to that from https://github.com/lowRISC/opentitan,
and the title from
-
Making open source hardware design a reality
Whilst open source hardware work goes back a fair way, I feel we're really at a turning point where it can become a serious force within the hardware world (think late 80s/early 90s in software terms, Linux and GCC emerging and beginning to find their feet). There's lots of interesting developments in tooling plus significant open hardware projects on-going.
I shall take the opportunity to plug OpenTitan: https://github.com/lowRISC/opentitan
It's an open source root of trust being developed collaboratively by multiple companies such as lowRISC (who I work for), Google, Western Digital and Seagate amongst others. We've been rather quiet on the PR front but there's a lot of engineering work happening and other exciting things we can't yet make public.
Whilst there's some things we have to keep closed (generally relating to ASIC design kits and things like Flash and memory IP) the vast majority of the RTL, documentation and software is open. Plus we're doing development in the open, the public repo is our live development repo. We're not developing it in private then just opening the end product.
-
How good is Verilator for big industry designs?
We use Verilator to do full system simulations of OpenTitan (https://github.com/lowRISC/opentitan) but couple that with a full DV environment using standard commercial simulators with UVM. The Verilator environment is used to run self checking system tests written in C.
-
lowRISC stopped working on their SoC in 2018 ;-(
Whilst the 64-bit SoC project isn't being actively developed we are working hard on OpenTitan (https://opentitan.org/, https://github.com/lowRISC/opentitan) which we hope will become the first large scale deployment of significant open source silicon IP.
What are some alternatives?
SpinalHDL - Scala based HDL
fusesoc - Package manager and build abstraction tool for FPGA/ASIC development
myhdl - The MyHDL development repository
ibex - Ibex is a small 32 bit RISC-V CPU core, previously known as zero-riscy.
amaranth - A modern hardware definition language and toolchain based on Python
openlane - OpenLane is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen and custom methodology scripts for design exploration and optimization.
cocotb - cocotb, a coroutine based cosimulation library for writing VHDL and Verilog testbenches in Python
skywater-pdk - Open source process design kit for usage with SkyWater Technology Foundry's 130nm node.
rocket-chip - Rocket Chip Generator
bsc - Bluespec Compiler (BSC)
VHDL_Lib - Library of VHDL components that are useful in larger designs.