neorv32
wb2axip
Our great sponsors
neorv32 | wb2axip | |
---|---|---|
77 | 51 | |
1,397 | 428 | |
- | - | |
9.9 | 3.1 | |
1 day ago | 3 months ago | |
VHDL | Verilog | |
BSD 3-clause "New" or "Revised" License | - |
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.
neorv32
-
Recommendations for RISC-V on FPGA
How about NEORV32?
-
SUGGEST AN OPEN SOURCE RISC-V CORE DESIGNED IN VERILOG
GitHub - stnolting/neorv32: 🖥️ A tiny, customizable and highly extensible MCU-class 32-bit RISC-V soft-core CPU and microcontroller-like SoC written in platform-independent VHDL. this one is good but is written in VHDL though
-
Anyone want to share some embedded projects they have done?
Maybe not a classic (whatever that means...) project, but I am working (together with others) on a RISC-V microcontroller for FPGAs: https://github.com/stnolting/neorv32
- Mapping compressed 'C' instructions to their 32b counterparts.
-
Uploading software program to a custom processor design on a Nexys A7
https://github.com/stnolting/neorv32 ;)
- A tiny and open-source (BSD) RISC-V SoC for (all!) FPGAs
- Looking for help with RISC-V softcore and VHDL
-
Risc-v rv32i softcore processor for Zybo-z7-10
How about the NEORV32?
-
RISC-V Verilog tutorials
This VHDL RISC-V SoC has a lot of documentation: https://github.com/stnolting/neorv32
-
How to verify Embench Benchmark in a RISC-V core?
I am not sure about Embench, but you could start with "porting" CoreMark as there are several implementations out there (like this one).
wb2axip
-
Simple skid buffer implementation
I've always been partial to my own skidbuffer article and implementation. (You'd expect me to be, they're my own ...) I get your point, though, about some applications needing a registered output. I've come across many, as requirements change from one project to the next. This is why, in my own implementation, I have parameters allowing me to adjust which implementation I'm using. In this case in particular, I have a parameter adjusting whether or not the output is registered. (The outgoing READY signal, though, is always registered--that's the point of the skid buffer in the first place, and what keeps it from being a regular buffer.)
-
Looking to implimenting an autocorrelation function (ACF) into one of my projects.
Have you considered this article? It goes over the basics of the autocorrelation function, while also illustrating how you can build one with a Wishbone interface. Further, the Verilator logic for this function is kept and maintained on github here. Sure, it uses Wishbone. If you want to use AXI you can either use a bridge, or rework the the interface (it's not that hard ...).
-
Reference of verification IPs
The worst thing that can happen on a bus is a protocol error that causes the device to lock up. Sadly, such errors have been common when using AXI or AXI-Lite--especially since traditional "verification IP" bus models won't catch all circumstances. This is why I make a general (personal) rule that nothing should touch a bus unless it has been formally verified. This check basically guarantees that every bus request gets one (and only one) response. It's not sufficient to verify an IP fully, but it's a good start. You can find my formal verification models for AXI-Lite, Wishbone, and (to some extent) Avalon in this repository. I've also been known to make my full AXI model available to Patreon sponsors of my blog.
-
Xilinx FIFO generator for skid buffer?
Can a FIFO be generated to use the AXI stream protocol? Absolutely! Check out this FIFO: - S_AXIS_VALID can be fed to the write port, i_wr - S_AXIS_READY is the compliment of the FIFO full output, o_full - S_AXIS_DATA can be fed to the incoming data port, i_data - M_AXIS_VALID is the compliment of the FIFO empty output, o_emtpy - M_AXIS_READY can be fed directly to the read port, i_rd - M_AXIS_DATA can be read directly from the outgoing data port, o_data - If you want to support other AXI Stream signals, they can simply be concatenated with the data signals above.
-
AXI InterConnect
Yes, I have posted an open source AXI interconnect. Unlike Xilinx's interconnect, mine doesn't automatically bridge between one bus width or clock and another, although some bridges exist in the same repository. Bridges exist, for example, for crossing clock domains, going from AXI3 to AXI4, from AXI4 to AXI4-lite, from AXI4 to a smaller AXI4-lite, and from AXI4-lite to a wider width. It's been enough to keep me from needing my own AXI4 interconnect, although AXI can be a real pain to wire up. As a result, I tend to use AutoFPGA for that purpose.
-
Large FIFOs using the Virtual FIFO Controller - My Blog this week.
At one point in time, I built my own AXI virtual FIFO. It wasn't all that hard to write, and took me about a weekend to write and verify. A lot of the things I complain about with AXI were simplified by the nature of the problem: I could insist, for example, that all bursts would be full length and aligned, that WSTRB would always be all ones and so forth. Since that time, I haven't yet had the opportunity to try this FIFO in any applications yet. Unlike what others have said of Xilinx's design, my own version didn't have any artificial size limits--other than the size of the FIFO needed to be at least one burst in length, and a power of two number of words. Neither did I keep track of TLAST or TKEEP. This essentially removed all packet boundaries--which may or may not work for your application.
Have you checked out this open source version of a Virtual FIFO?
-
OS AXI4 Crossbar with good performance
I know of three Open Source AXI crossbars. There's my own, Bluespec has one, and so does the PULP platform as I recall.
-
Advice for studying the AXI specification
Here is link number 1 - Previous text "DMA"
Some things to know: 1. Xilinx's example AXI designs are broken. Even their AXI Stream master is broken. Don't start there. 2. As others have suggested, starting with the AXI stream protocol, and learning AXI handshaking is a good place to start. This is where you'll find the bug in Xilinx's AXI stream master demo--in the handshaking. 2. Once you understand AXI handshaking, I'd then recommend learning about skidbuffers. Without them, you'll never get any decent throughput. 3. The next place I'd go would be to look into AXI-lite. Beware of backpressure! It has caused Xilinx no end of headaches, and forms the backdrop for many of the bugs in their example designs. If you want a working example design, check out this example design that I often use myself when working with AXI-lite. 4. For most use cases, you can stop here. For most of the things that need the full AXI specification for, you can already find example or vendor designs that'll work. (DMA's, MM2S, S2MM, virtual FIFO, video frame buffer reading, video frame buffer writing, etc.) 4. Once you've mastered AXI-lite, then it's time to understand AXI addressing, and the various FIX, WRAP, and INCR addressing modes and how the SIZE field impacts them. You'll need to understand this before diving into building your first AXI slave. Indeed, I've used the next AXI address module built and presented in that article in many designs--ASIC included. 5. The next step would be to build an fully capable AXI slave. 6. When it comes to AXI masters, I would similarly start with an AXI-Lite master. Technically, such a master should be able to be just as fast as an AXI full master. Practically and sadly, many designs cripple AXI-lite implementations. (Hello, Xilinx?) 7. A full discussion of AXI masters gets difficult. It's hard enough that I haven't (yet) posted on how to build general AXI masters--the addressing is just that hard to get right. (Usually takes me a couple of days.) However, you are welcome to examine some of those I've written and posted](https://zipcpu.com/blog/2021/06/28/master-examples.html) if you'd like. 8. I have posted about how to build an instruction fetch routine in both AXI-Lite, and then how to upgrade it to AXI (full). This goes over the AXI Exclusive access protocol, and how you can build a master that uses it--although I only really know of CPUs that need this protocol. 9. It's also important to know how to measure AXI performance. Just what kind of performance are you achieving, what is possible, and what can you expect are all good questions you'll want to know how to answer.
What are some alternatives?
VexRiscv - A FPGA friendly 32 bit RISC-V CPU implementation
linux-on-litex-vexriscv - Linux on LiteX-VexRiscv
picoMIPS - picoMIPS processor doing affine transformation
wavedrom - :ocean: Digital timing diagram rendering engine
upduino-projects - Various VHDL projects I've worked on for the Upduino v2.0 and v3.0
chipyard - An Agile RISC-V SoC Design Framework with in-order cores, out-of-order cores, accelerators, and more
lxp32-cpu - A lightweight, open source and FPGA-friendly 32-bit CPU core based on an original instruction set
fpga-zynq - Support for Rocket Chip on Zynq FPGAs
linux-on-litex-rocket - Run 64-bit Linux on LiteX + RocketChip
serv - SERV - The SErial RISC-V CPU
verilog-axi - Verilog AXI components for FPGA implementation