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 GitHub Read 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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:24:48 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.

* 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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	4	0	4
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	0	3
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	3	0	3
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	3	0	3
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	0	1
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1	0

What Hacker News says

3 sources

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