HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
lowRISC
ibex
SystemVerilog2019–2026
lowRISC / ibex

ibex

Ibex is a small 32-bit RISC-V CPU core with high-level of verification (previously known as zero-riscy)

Hardware & Embedded
Explore on GitHubRead Hacker News discussions
11Distinct people
16Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Ibex is a small 32-bit RISC-V CPU core with high-level of verification (previously known as zero-riscy)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2019-11-05 18:59:53 UTC to 2026-06-14 18:23:41 UTC.

012342019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC110

What Hacker News says

16 sources
moquilabs·Jun 14, 2026Submission

Ask HN: How can you trust your hardware?

There's a widespread idea in the technical community that TPMs don't provide any security: - https://news.ycombinator.com/item?id=37435450 - https://learn.omacom.io/2/the-omarchy-manual/50/getting-started?search=tpm#getting… (see advice on tpm) - NSA encourages we use it https://media.defense.gov/2024/Nov/06/2003579882/-1/-1/0/CSI-TPM-USE-CASES.PDF But, TPMs have real use cases: - It theoretically prevents kernel level exploits extracting secrets. - Projects like Qubes suggest using it to prevent evil maid attacks: https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html#recommended BUT... - It provides a weak level of device attestation from the manufacturer: https://blog.cloudflare.com/anchoring-trust-a-hardware-secure-boot-story/#uefi-att… - That cloudflare article suggests using AMD PSP which is equivalent t
Read the rest
o Intel ME that the NSA is know to request the disabling of https://stateofsurveillance.org/articles/technical/intel-management-engine-deep-dive/ So it seems like to really trust your hardware, you must depend on the vendor. For the vendor to send you the hardware, the hardware could be tampered with, so making it tamper resistant and using a burned in read-only cryptographic signature from the manufacturer. The fips 140 level 4 ibm processor is the closest equivalent I can find: - https://www.ibm.com/docs/en/cryptocards?topic=4770-overview#ibm_4770_overview__tit… - Then to trust the vendor, using an open source design with minimal attack surface is really the only option. Something like https://lowrisc.github.io/sonata-system/ based on https://opentitan.org/ and https://github.com/lowRISC/ibex seems to be the closest I can find. Any thoughts on how to trust your hardware? I'm out of ideas...
3 points · Open discussion
gchadwick·Aug 8, 2024
This looks awesome a really great step up from the RP2040. I'm a big fan of the original and I'm excited to see all the improvements and upgrades. I imagine with the new secure boot functionality they've got a huge new range of customers to tempt to. Also exciting to see them dip their toe into the open silicon waters with the hazard 3 RISCV core https://github.com/Wren6991/Hazard3. Of course it they'd used Ibex https://github.com/lowrisc/ibex the RISC-V core we develop and maintain at lowRISC that would have been even better but you can't have everything ;)
In I got almost all of my wishes granted with RP2350
sitkack·Apr 30, 2024
> Right now, most devices on the market do not support the C extension This is not true and easily verifiable. The C extension is defacto required, the only cores that don't support it are special purpose soft cores. C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file Supports M and C extensions https://github.com/YosysHQ/picorv32 Another sized optimized core with C extension support https://github.com/lowrisc/ibex C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax
In RISC-V support in Android just got a big setback
gchadwick·Mar 5, 2024
> My experience with most "neo HDLs" is that they are all code generators which make the tedious part easy and don't really end up touching the hard part. That's generally make take too, only I'd say they make some of the hard parts harder. When you're getting into timing, power and area optimizations it's important to have a good mental mapping from the HDL you're writing to the circuitry (or FPGA configuration) being produced. For some optimizations you also need to smash through neat abstractions. Often these new HDLs abstract away more from the circuitry so you have to carry more things in your head to think through these optimizations. They aim to work out the details for you but those details matter and when you only have indirect control over them can make things more difficult. In software we're generally happy to accept a drop in
Read the rest
performance or an increase in memory usage to gain powerful abstractions and increase developer productivity. In hardware this is often less acceptable (in particular if you're building high-performance CPU, GPU, AI accelerators etc). From my brief look at the front page of the Filament website I do like the type system but from experience building real CPUs (I worked on the A55, A510 and E1 at arm, focussed on memory systems and now work on Ibex: https://github.com/lowrisc/ibex amongst other things) bugs and other issues around pipelining are often to do with stall conditions, I wonder how well it can handle that? Stall conditions were large and complex and also where you had to do lots of those abstraction busting optimisations to meet timing so it's critical you have a strong grasp of the critical paths being produced in the circuitry. My fear with Filament is it abstracts a bunch of that away. Of course the entire hardware world isn't CPUs, there could well be areas of design this kind of language works well. In particular I can see it's useful for prototyping/design exploration type work.
In Filament – A Language for Fearless Hardware Design
taway32r41·Sep 6, 2023
I definitely agree with the primary point, "building a chip that meets specfic requirements we got from the customer" is not easy and is what matters. However, RISCV cores abound. In pretty much any HDL known to man with varying design trade-offs and capabilities. It's extremely difficult to differentiate at the RTL level at this time. Not impossible, but it would be a significant investment, which is I guess SiFive's business model. Sell IP at prices cheaper than that. Here is a high quality, well documented, SystemVerilog version intended for embedded applications that I know has been included in multiple ASIC and FPGA designs successfully. https://github.com/lowRISC/ibex
In SiFive’s P870 Takes RISC-V Further
panick21_·Mar 26, 2023
Of course these things never die, MIPS wont die. ARM wont die. Nobody is claiming they will. But also, you don't start very many a huge amount of new project with 8052s. Performance isn't that important maybe (depends on the application), but energy often is, size is, having lots of vendors is, having a large software base is. > So I'm really not sure how or why RISC-V would break into the uC world / low end. If by lower end you mean 8-bit, then no it wont. But one of the large adopters of RISC-V are actually places where there used to be tiny 8-bit cores and now people want more substantial 32-bit cores and RISC-V is really good there. And it has already broken into that market as there are already lots of RISC-V products shipping, lots of them in lots of consumer electronics from China. RISC-V will continue to grow in that market, if yo
Read the rest
u were a MIPS costumer for example, you are likely gone move on to RISC-V? > If anywhere, they have a chance at the higher level, like at Rasp Pi level chips or stronger. At the very low end being very cheap, not involving as many lawyers actually matters quite a bit because volumes are high. Specially when there are very competitive verified opensource cores as well. Ibex: https://github.com/lowRISC/ibex Used by Google in the OpenTitan Project Open Hardware Group: https://www.openhwgroup.org/ Chips Alliance: https://www.chipsalliance.org Not to mention all the commercial offerings (or commercial offerings that support those open-cores). They might not be open, but its easy to get up and running with RISC-V compared to commercial stuff. There is just so much education moving to RISC-V. Lots of people will be educated in RISC-V and lots of people will look at some of these OpenSource cores to learn. When places like Berkley, Stanford and ETH embrace something it usually trickles down to most universities.
In Arm wants to charge dramatically more for chip licenses
jabl·Mar 2, 2022
The pretty minimal RV32EC core Ibex is estimated 15k gates: https://github.com/lowRISC/ibex But, the similarly minimal Arm Cortex M0 is, drumroll, 12k gates. Not saying this means Arm is better than RISC-V, such a small difference can probably be explained by some microarchitectural feature or lack of it. Just that you can scale down Arm as well. But yes, I can see tiny chips like these putting a squeeze on 8 and 16 bit microcontrollers.
In RISC-V is succeeding
gchadwick·Sep 27, 2020
> Yes, there is one in the proposed "B" extension. Not good enough: it won't be in the smaller chips, or even in the biggest ones for a good while. The lowRISC Ibex core which I work on and whilst not the smallest core is definitely at the small end has full bitmanip extension support: https://github.com/lowrisc/ibex Yes the extension isn't finalised yet but we're not expecting much change so we can tweak the implementation to match the ratified standard when it appears. I'd also note bitmanip is broken up into subgroups so it's possible smaller cores will only implement the simple stuff (e.g. Popcount) to avoid the overhead of the full implementation.
In RISC-V: What’s Missing and Who’s Competing
jhallenworld·Aug 5, 2020
We need a better list, but it would be quite some work to make it. I'd like a list of performance, size, implementation language and bus interfaces. I've been looking at this one for high end (1.9 DMIPS/MHz!): https://github.com/ultraembedded/biriscv Google/lowRISC has this one: https://github.com/lowRISC/ibex I'm using picorv32 right now on Lattice ECP5- running code out of SPI-flash, but I added an instruction cache for speed. It's amazing how many RISC-V things are happening all at once right now. Anybody know of any free RISC-Vs with floating point? It would be helpful to have something similar to ARM Cortex-M4F. Edit: From the "riscv-cores-list" I see WARP-V, which I'm not interested in due to "TL-Verilog". But its FPU is this: http://www.jhauser.us/arithmetic/HardFloat.html So all of these RISC-Vs should have optional FPU support
Read the rest
based on HardFloat :-) (not that I have any idea of the size of HardFloat).
In System on Chip wrapping the SERV RISC-V soft processor
gchadwick·Jul 9, 2020
I'm slightly surprised the author didn't mention the core I work on Ibex: https://github.com/lowRISC/ibex but maybe not too surprised as it's primary target isn't FPGA softcore, though it does work fine for this purpose. It's got an extensive verification environment (though relies on UVM so you need closed tools to run it, we have a verilator setup for running RISC-V compliance and arbitrary binaries), good documentation and we're pushing the performance up (you can get 3.09 CoreMark/MHz with the current master and that will increase with some branch prediction work I'm currently doing). It's configurable so you can choose your own trade offs between size and performance. Plus we've got support for the B (bitmanip) extension, which our verification environment also tests. All cores have their pros and cons and Ibex is no exception but if
Read the rest
you're looking for an open CPU core I think it's well worth a look.
In FPGA Softcore SoC Shootout
gchadwick·May 21, 2020
It depends what you want to do? Do you want to build a processor from scratch? A basic processor for core RISC-V is actually quite simple. The RISC-V I specification (all the core instructions not including multi/div, none of the privileged spec) is not complex. Implementing something like the story talks about is obviously far more complex. If you're mostly interested in putting together existing processors that can again can vary in complexity, there are some things with 'batteries included' where you can just spin up an FPGA image that works then go poking around, others where there will be significant work in integrating things into a working system. I'll give a plug to Ibex (https://github.com/lowRISC/ibex) which is the core I work on, it doesn't have an MMU and is targetted at embedded applications. It's a 'real' core, in that it's
Read the rest
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.
In VexRiscv is a quadcore, Linux-capable RISC-V softcore for FPGA

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.