opentitan

is marketing their usage of an open-source silicon IP block with transparent high assurance, one can only hope they would welcome open security research, ideally via a bug bounty program.

hysical 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 > you could add information about bus interfaces directly in Chisel, and have a single source of truth generate both the RTL and other collateral like IP-XACT. Your example here certainly sounds useful but to me at least falls into the bucket of annoying and tedious tasks that won't radically alter how you design nor the final quality and speed of development. Sure if you need to generate IP-XACT for literally thousands of variations of some piece of IP this kind of things is essential but practically you have far fewer variations you actually want to work with and the manual work required is annoying busy work that will generate some issues but you can deal with it. Then for the thousand of variations case the good old pile o' python doing auto-generation can work. Certainly having a solution based upon a well designed language with a sound type system sounds great and I'll happily have it but not if this means things like timing fixes and ECOs become a whole lot harder. Thanks for the link to the video I'll check it out. Maybe I should make one of my new year's resolution to finally get around to looking at Chisel and CIRCT more deeply! Could even have a crack at toy HDL in the form of the fixed SystemVerilog with a decent type system solution I proposed above using CIRCT as an IR...

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 gac@lowrisc.org if you’ve got any questions.

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 gac@lowrisc.org if you’ve got any questions.

o people having to justify why they're not using open technology.

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.

out what processes this was intended for without digging. ASAP7 is Arm and NCSU, and Skywater130 is Skywater and Google. [0] https://github.com/mflowgen/freepdk-45nm [1] https://docs.siliconcompiler.com/en/latest/reference_manual/... [2] https://github.com/google/skywater-pdk [3] https://github.com/siliconcompiler/zerosoc [4] https://github.com/lowrisc/opentitan

suitable for taping-out into a real system but still quite simple to understand. OpenTitan (https://github.com/lowRISC/opentitan) is a notable project we're also working on that uses it, it's an open source root of trust and will give you a working RISC-V SoC you can put on an FPGA, you can easily carve out the security things leaving you with a RISC-V core, some SRAM and various useful peripherals.