FPGA Active Open Source Projects

[Foxxz]

I am a novice in the FPGA world and have fired up a couple of my own projects at this point. I have lofty goals but not the experience or training to carry them out. I'm usually very good at executing and completing such goals no matter what I do but I'm finding FPGAs to be a bit more complicated than I'm used to and available help and resources for them are not as robust as other subjects.

To that end I have been looking around for active group and open source projects to help cut my teeth on some more involved work as I find working with others helps motivate me and provide some direction; especially in subjects I'm not experienced in.

I have been primarily working in verilog as a personal preference and, if at all possible, I'd like to continue down that path. If the audience here could offer up suggestions for active verilog projects looking for participants I'd be grateful for the referral.

[asmi]

In my experience HDL code is much harder to read than regular programming languages. So collaborating in general is harder, unless the project can be easily decomposed into semi-autonomous modules which can be designed by different people pretty much stand-alone.

As for project ideas, design your very own RISC-V SoC. This project can be as simple as you want or as advanced as you dare. At the easy end, the very minimal - but still functional enough to execute code generated by C compiler! - RV32I core can be designed in few hours to few days time (depending on the level of your expertise), but then there are a million things which can be added on top of that - from pipelining to AXI peripheral bus, from I/D caches to external memory bus, from simple external AXI peripheral interconnect to PCI Express root complex, from super-scalar and out-of-order execution to multicore complexes with APICs and IPI support, from simple bare-metal applications to running a full-on Linux OS on your very own CPU. Possibilities are endless!

[Foxxz]

So you've hit on many good points. Some of them are the same ideas I also have.

First I will agree with you about HDL being stylistic from person to person. Each having their own approach to solving the same problem. And assigning ownership of modules within a group project is probably the ideal way to go about a project with several participants. I suppose you could have people who like doing the verification and writing the unit tests for modules as well which would be helpful.

Going into your second suggestion - the RISC-V SOC hits upon my more lofty goals. Eventually, I wanted to implement a design to have two lattice FPGAs interconnected to build a standalone SDR platform. The reasoning between having two FPGAs was that one would run a RISC-V (or other) softcore and interface with the peripherals for controlling the radio (screen, buttons, storage, frequency control, etc) and be static during runtime while the other FPGA would be slaved to the first to handle modulation. And not just one type of modulation but be reconfigured on the fly to load up whichever modulator was desired for the task at hand be it various audio or digital modes geared towards ham radio or generalized usage.

I am not married to the lattice FPGAs and I realize there are FPGAs that can do partial reconfiguration or have hard CPUs in them like the Zynq. But the project is more about flexibility and openness of the design. I have built several block diagrams of everything I'd like to include. But I'm not sure I am ready to tackle it alone.

[rstofer]

HamsterNZ has a VHDL implementation of a low end RISC-V core.  He is a major contributor to this forum.

https://github.com/hamsternz/Rudi-RV32I/tree/master/src/cpu

Unfortunately (for you), it is written in VHDL and, additionally, I don't believe there is any way in hell a newcomer is going to create a RISC-V core.  It gets a lot of pixels in this forum as a startup project but I think it takes a whole lot more experience.  But that's just my opinion and I haven't actually tried it.

There are fundamental building blocks you need to be able to create and most are easy (MUX, Decoder, counter, register) but the big one is the Finite State Machine.  I prefer the two process approach but the case can be made for a one process or even a three process approach.  All of the real work gets done in a FSM.

Again, it's VHDL but you might take a look at VHDLwhiz.com.  He has some great tutorials and most of the effort centers around simulation.  Alas, it's VHDL...

I don't have it but maybe this book will have something worthwhile:
https://www.amazon.com/Computer-Architecture-Tutorial-Using-FPGA-ebook/dp/B08GK4HNMC

This book revolves around creating an ARM processor and code is provided in System Verilog and VHDL.  The book discusses pipelining but the code doesn't support it.  There is a matching book by the same authors that talks about MIPS processors.

https://www.amazon.com/gp/product/0128000562

Here's a book about the Z80 processor and Verilog written by the guy who designed the Z80.  He does all of the design with spreadsheets and then implements the code.  Since the Z80 is more of a CISC processor, the number of states per instruction can get quite high.

https://www.amazon.com/gp/product/0963013351

Writing the code is easy, it's designing the system that is hard.  Unless somebody hands you the block diagram and state table, you need to be able to create these on your own.

Most of the folks around here aren't impressed with the LC3 because they can implement the RISC-V.  I'm not sure I could.

These projects (LC3 and LC3b) are taught in many universities and there is a book, actually two books:

https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond/dp/0072467509 -- this book discusses the LC3, a simple 16 bit RISC machine
https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond-ebook/dp/B07VWKMJBX -- I'm not sure if the 3d edition describes the LC3b

The LC3b is byte addressable and includes more instructions - a much better CPU

You can get an idea about the LC3 from
https://justinmeiners.github.io/lc3-vm/supplies/lc3-isa.pdf
http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdf

You can find similar documents for the LC3b but the ones I found omit the interrupt system.

The reason I tout the LC3 is that the book goes from bits and gates up through ISA design and on to a complete hardware diagram and a form for microcoding.  We could use microcoding in an FPGA but more likely not.  I didn't...  The book is for a class on system design so everything is spoon fed.  No assumptions are made about design capabilities.  No HDL is given, you take the hardware diagram and start coding.  The FSM will be written directly from the state diagram.

[asmi]

VHDL sucks because its' signal to noise ratio is very low. Get over it already. LC3 sucks too because it's useless 16bit garbage. 16 bits! in the end of 2020! Ditto Z80. That thing is older than I am ffs!
RISC-V is simple and modern. Very easy to implement in the basic form. You have a choice of going for 32 or 64 bit core with very few differences among them (unlike some "other" architectures which have a ton of "historical" garbage, so each new mode is radically different from other modes, and you will have to essentially start over learning how to program for each of them). Don't listen to people who haven't even tried designing damn thing, yet somehow "have an opinion".

[rstofer]

Ah, the language wars!  Again...

https://www.campera-es.com/vhdl-vs-verilog-vs-systemverilog

I don't have an opinion, I use VHDL because that is what I started with.

[rstofer]

LC3 sucks too because it's useless 16bit garbage. 16 bits! in the end of 2020!

For an embedded controller, 8 bits is probably overkill.  We're not trying to cure world hunger, just control a few gadgets and respond to a few events.

Ditto Z80. That thing is older than I am ffs!

Unless the objective is to recreate PacMan using the original PROMs (in BlockRAM of course).  The T80 core at Opencores is quite good.

It's the PROCESS that's important, not the label on the plastic.  Because it's a CISC processor, multiple cycles are required and using a spreadsheet to show all the timing is quite clever.  In fact, it's brilliant!  But you would have to read the book...

RISC-V is simple and modern. Very easy to implement in the basic form. You have a choice of going for 32 or 64 bit core

Why would an embedded controller need anything like 64 bits?  If I need networking, there are a ton of chips that do that kind of thing including the NXP LPC1768 which I quite like.  It's getting old but it works quite well.  I don't see myself porting TCP/IP to a minimalist RISC-V.

Don't listen to people who haven't even tried designing damn thing, yet somehow "have an opinion".

Show me a book with a block diagram of a minimal machine along with a state transition diagram that I can translate into a FSM and I'll think about it.  I have a book coming that MIGHT deal with the issue but I have yet to see a document at the level of the LC3 appendices.  The system design is handed to you, all you have to do is write the code.  It is a terrific FIRST project because every detail is described!  With a very few lines of code, it is possible to have an interrupt driven keyboard routine echoing chars to a terminal.  The RISC-V can wait its turn as a second project.

"Computer Organization and Design RISC-V Edition" Patterson and Hennessy.  Late January to mid-February, if I'm lucky.

Before you slam the LC3 project, look over the appendices and show me something identical for the RISC-V.  If it exists I might give it a try.  Otherwise, for an embedded controller, the LC3 (or, better, the LC3b) meets my needs.  At the moment...

I should do a line count on HamsterNZ's RISC-V versus the LC3.  Maybe I'll do that one day.  His code is elegant, no doubt.  I didn't see the interrupt controller and that's kind of a big deal but I didn't spend all that much time going through the code.  The LC3 has a nice interrupt vector setup with 256 entries.  It also had a nice TRAP system with 512 entries.  Simple to implement!

Sometimes, people want to get into FPGAs without having courses in computer architecture or computer design.  Starting projects need to be simple and yet non-trivial.

[asmi]

For an embedded controller, 8 bits is probably overkill.  We're not trying to cure world hunger, just control a few gadgets and respond to a few events.

LOL. 8 bit controllers are dead except for very new very niche uses. And so are 16 bit ones. Welcome to the real world of today, not the imagined world circa 1990. The world of today runs on 32 bit controllers and 64 bit CPUs.

Unless the objective is to recreate PacMan using the original PROMs (in BlockRAM of course).  The T80 core at Opencores is quite good.

Very few people care about old junk. It's mostly older people because that old crap reminds them of time when they were young and girls were pretty. There is zero technical baggage to take away from such projects, as they involved compromises that make zero sense in the modern world.

Why would an embedded controller need anything like 64 bits?  If I need networking, there are a ton of chips that do that kind of thing including the NXP LPC1768 which I quite like.  It's getting old but it works quite well.  I don't see myself porting TCP/IP to a minimalist RISC-V.

Because you didn't design any of those chips. But RV64 one you can design. You don't need to port anything, it's already done by other people. And 64bit have nothing to do with networking. It's useful anywhere where you need to have 64 bit operations, or you need more than 4G of address space. The latter is getting more and more common nowadays, because RAM becomes cheaper and larger as time goes on. 512 MBytes DDR3 chip goes for less than $5, DDR4 is even cheaper relative to capacity. Again, historically people had to come up with hacks like PAE which makes no sense to implement in brand new architectures.

Show me a book with a block diagram of a minimal machine along with a state transition diagram that I can translate into a FSM and I'll think about it.  I have a book coming that MIGHT deal with the issue but I have yet to see a document at the level of the LC3 appendices.  The system design is handed to you, all you have to do is write the code.  It is a terrific FIRST project because every detail is described!  With a very few lines of code, it is possible to have an interrupt driven keyboard routine echoing chars to a terminal.  The RISC-V can wait its turn as a second project.

I've managed to do that without any books which hold your hand as if you're mentally deficient. You can do it all by yourself.

Sometimes, people want to get into FPGAs without having courses in computer architecture or computer design.  Starting projects need to be simple and yet non-trivial.

I didn't take any of those courses either. If I can do it, so does everybody else. Just don't be lazy and use your brain like nature intended!
----
Look, I don't want to make it personal and repeat this debate over and over again. If you like reinventing 40 years old wheels - be my guest. But telling new generation of engineers that they have to learn how those half a century old wheels worked is a no go, as it gives them absolutely nothing that is going to be useful in the projects of today and tomorrow. New times call for new means! Leave that old stuff where it belongs - in museums.

[SiliconWizard]

VHDL sucks because its' signal to noise ratio is very low. Get over it already. LC3 sucks too because it's useless 16bit garbage. 16 bits! in the end of 2020! Ditto Z80. That thing is older than I am ffs!

Frankly, I was used to reading rather sensible posts from you overall. What is this sudden crap? Hopefully you were drunk while posting this, or something. This just looks like basic teenager trolling. Just my 2 cents though.

[woofy]

Here's a book about the Z80 processor and Verilog written by the guy who designed the Z80. 

Is that true? Did Monte Dalrymple work on the Z80 before joining Zilog? (I've not read the book).
The Z80 was conceived by Federico Faggin (of intel 4004 fame) in 1974 and introduced by Zilog, the company he founded, in 1976.
Monte Dalrymple, the author of the referenced book, joined Zilog in 1978, two years after the Z80 was placed on the market.
He designed Z80 peripherals, worked on the Z280 and was lead architect on the Z380.
I don't think he designed the Z80.

[rstofer]

Here's a book about the Z80 processor and Verilog written by the guy who designed the Z80. 

Is that true? Did Monte Dalrymple work on the Z80 before joining Zilog? (I've not read the book).
The Z80 was conceived by Federico Faggin (of intel 4004 fame) in 1974 and introduced by Zilog, the company he founded, in 1976.
Monte Dalrymple, the author of the referenced book, joined Zilog in 1978, two years after the Z80 was placed on the market.
He designed Z80 peripherals, worked on the Z280 and was lead architect on the Z380.
I don't think he designed the Z80.

I could have that all bass akwards.  Nevertheless, the approach is sound and it leaves a document trail.  It's not often one sees an Excel spreadsheet involved with CPU design.  Of course, that approach came long after the actual Z80 design. I don't recall spreadsheets much before 1979 when VisiCalc was invented.  There were paper spreadsheets long before - accountants had been using them for a very long time.

[DiTBho]

LC3 sucks too because it's useless 16bit garbage

In my opinion LC3 is good for teaching as alternative to all the common MIPS1 courses. I do largely prefer MIPS to LC3, but LC3 is somehow smaller and "legal free". MIPS is not.

If the purpose is "to teach", LC3 is brilliant. If the purpose is "to do some realistic project", no doubt RISC-V is better because it has a more complete ISA, and a better mainstream-tool-chains support.

[ebclr]

"8 bit controllers are dead except for very new very niche uses"

That's a very stupid affirmation.

8 Bits is 40 years Old And will have much more to go, Nothing beats 8-bit simplicity and cost, It's a sea of applications for this kind of processor, In fact much bigger than 16 and 32 Bit's counterparts, Who have a place only on the middle to complex systems who is still the minority of real-world application.

[james_s]

VHDL sucks because its' signal to noise ratio is very low. Get over it already. LC3 sucks too because it's useless 16bit garbage. 16 bits! in the end of 2020! Ditto Z80. That thing is older than I am ffs!
RISC-V is simple and modern. Very easy to implement in the basic form. You have a choice of going for 32 or 64 bit core with very few differences among them (unlike some "other" architectures which have a ton of "historical" garbage, so each new mode is radically different from other modes, and you will have to essentially start over learning how to program for each of them). Don't listen to people who haven't even tried designing damn thing, yet somehow "have an opinion".

I very strongly prefer VHDL over Verilog, the latter looks like abbreviated gibberish to me, VHDL is very clear and logical and it doesn't have to be nearly as verbose as some people write it. It's a personal preference though, use the one that works for you, their capabilities are identical.

Frankly you sound extremely elitist, "everything old is useless crap and you are stupid if you think otherwise". But then virtually my entire interest in FPGAs has been recreating vintage hardware, most of my projects have been based around the 6502 microprocessor core.

[james_s]

"8 bit controllers are dead except for very new very niche uses"

That's a very stupid affirmation.

8 Bits is 40 years Old And will have much more to go, Nothing beats 8-bit simplicity and cost, It's a sea of applications for this kind of processor, In fact much bigger than 16 and 32 Bit's counterparts, Who have a place only on the middle to complex systems who is still the minority of real-world application.

Indeed, 8 bit micros are EVERYWHERE. If you need a tiny 6 pin part to blink an LED, read a sensor and send the data out via some other format, peform a task similar to what you might use a 555 for, or some other simple application it would be silly to throw a 32 bit processor at it. There is an enormous market for small, simple, CHEAP microcontrollers. Compact cars didn't go away when vans and SUVs were invented and 8 bit microcontrollers didn't go away when 16 and 32 bit microcontrollers were developed.

[DiTBho]

New times call for new means! Leave that old stuff where it belongs - in museums.

Umm, it has nothing to do with it, you just made me remember there is a funny course at MIT, something like three weeks with old stack-machines, then you move on to RISC design for two semesters 

[BrianHG]

Some of my beginner entry level functional and useful Verilog source code tutorials.

https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg2801388/#msg2801388
https://www.eevblog.com/forum/fpga/home-made-systemverilog-3-word-zero-latency-fifo-documented-for-beginners/msg3123336/#msg3123336
https://www.eevblog.com/forum/fpga/2-word-first-word-fall-through-(fwft)-fifo-fifo-style-elastic-buffer-for-speed/msg3191352/#msg3191352

[NorthGuy]

Eventually, I wanted to implement a design to have two lattice FPGAs interconnected

This is a very bad idea. Things in FPGA runs in parallel and execute independently of each other. Having two FPGAs only adds non-necessary interconnection troubles. If you're out of space, use a bigger FPGA instead.

What you suggest is like if you wanted to have two houses - one house would have a living room and a dining room, while the other house would have a bathroom and a bedroom.

[fourfathom]

Eventually, I wanted to implement a design to have two lattice FPGAs interconnected

This is a very bad idea. Things in FPGA runs in parallel and execute independently of each other. Having two FPGAs only adds non-necessary interconnection troubles. If you're out of space, use a bigger FPGA instead.

That sort of depends on the problem being solved, doesn't it?  While I would look at the "bigger FPGA" approach first, perhaps there is a reasonable functional partitioning that works well with two FPGAs.  Perhaps there are different internal resource or IO requirements.  It might be a great idea.

[DiTBho]

This is a very bad idea. Things in FPGA runs in parallel and execute independently of each other. Having two FPGAs only adds non-necessary interconnection troubles.

It depends, for instance I have here two FPGAs here, they talk serially over a synchronous serial link at 2Mbit/sec, and it is OK for me.

[Gerhard_dk4xp]

Here's a book about the Z80 processor and Verilog written by the guy who designed the Z80. 

Is that true? Did Monte Dalrymple work on the Z80 before joining Zilog? (I've not read the book).
The Z80 was conceived by Federico Faggin (of intel 4004 fame) in 1974 and introduced by Zilog, the company he founded, in 1976.
Monte Dalrymple, the author of the referenced book, joined Zilog in 1978, two years after the Z80 was placed on the market.
He designed Z80 peripherals, worked on the Z280 and was lead architect on the Z380.
I don't think he designed the Z80.

I remember Federico Faggin and Matoshi Shima as the Z80 designers.
And they were FAST. A matter of weeks.

Gerhard

ed. Masatoshi Shima
https://es.wikipedia.org/wiki/Masatoshi_Shima
(I cannot read that)

[rstofer]

Speaking of Open Source and Verilog, opencores.org has a lot of projects and it seems that many of them are written in Verilog.

I know for a fact that the T80 core (Z80) will run Digital Research's PL/I compiler under CP/M.  Lesser programs, like Microsoft Fortran and Digital Research's Macro Assembler also work.  Oh, and PacMan works - probably the most important project I have done with this core.

Don't forget to terminate the external connections for NMI and similar signals.  There's a reason I know this.

[Foxxz]

Eventually, I wanted to implement a design to have two lattice FPGAs interconnected

This is a very bad idea. Things in FPGA runs in parallel and execute independently of each other. Having two FPGAs only adds non-necessary interconnection troubles. If you're out of space, use a bigger FPGA instead.

I don't think that having two FPGAs interconnected is a terrible idea. Connect them over SPI or a parallel bus or whatever works. If my goal is to have a library of de/modulators for various analog and digital radio modes I think it'd be ideal to have the slaved FPGA available to load up whichever bitstream is called for at the time rather than trying to fit all possible de/modulators on a single FPGA. I think there is likely a power benefit here as well to using two small FPGAs over a single large one.

[asmi]

I don't think that having two FPGAs interconnected is a terrible idea. Connect them over SPI or a parallel bus or whatever works. If my goal is to have a library of de/modulators for various analog and digital radio modes I think it'd be ideal to have the slaved FPGA available to load up whichever bitstream is called for at the time rather than trying to fit all possible de/modulators on a single FPGA.

Didn't you say you want to implement SDR? As far as I know, they tend to require a lot of bandwidth, so SPI or parallel bus will not do you any good. You will need a high speed LVDS linkup between FPGAs. And that will require using expensive controlled-impedance connectors so that you can actually reach the kind of bandwidth you need.
In short, it's not worth it. The only time when using multiple FPGAs is warranted is when there is absolutely no other way. All other times it's better to use a single larger device.

I think there is likely a power benefit here as well to using two small FPGAs over a single large one.

Not even close. One device will always consume less power than two. You will also need to add dynamic power consumption of your interconnect, which can be significant for high speed connection. And you will need to dedicate some amount of FPGA resources to implement that interconnect on both sides.
There is a reason devices like Zynq exist. If what you said would be true, they would make no sense. And yet no only do they exist, they are very popular in many applications.

[Foxxz]

Didn't you say you want to implement SDR? As far as I know, they tend to require a lot of bandwidth, so SPI or parallel bus will not do you any good. You will need a high speed LVDS linkup between FPGAs. And that will require using expensive controlled-impedance connectors so that you can actually reach the kind of bandwidth you need.
In short, it's not worth it. The only time when using multiple FPGAs is warranted is when there is absolutely no other way. All other times it's better to use a single larger device.

I'm thinking the slaved FPGA is talking to the SDR and performing the de/mod. The de/mod data is communicated to the primary FPGA. That data should be vastly smaller than raw IQ data. Remember I'm talking ham radio here. I'm not looking to deal with a wide bandwidth. I was thinking 192khz with 32 bit IQ data using a stereo audio ADC/DAC. So thats ~12mbps?

Putting both FPGAs on the same board won't require any connectors between them so not a worry there.

And I COULD use an FPGA with a hard CPU on it but were is the fun in that?

I get it. None of this is the most efficient or best way to do this. But its more of an educational project for myself.

[NorthGuy]

I don't think that having two FPGAs interconnected is a terrible idea. Connect them over SPI or a parallel bus or whatever works. If my goal is to have a library of de/modulators for various analog and digital radio modes I think it'd be ideal to have the slaved FPGA available to load up whichever bitstream is called for at the time rather than trying to fit all possible de/modulators on a single FPGA.

This can be done with a single FPGA as well. You probably can do partial re-configuration to alter the design at run time, or you can have multiple configuration, or you can completely configure the entire FPGA from the PC with whatever bitstream you need.

[rstofer]

Somewhere on the Interwebs there is a project that uses a uC to select a configuration file to hand to the FPGA at boot time.

Here's one approach for managing an update copy while retaining a "golden" copy:
https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf

Here's a more general microcontroller approach:
https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf

Neither of these are the project I was thinking about.  My Google foo isn't working today.