𝞵GPU FPGA Project

[Renate]

Can you just throw a load resistor on the 3.3V rail?
I mean, you've got a bunch of boards, can't you use them for further development for now?

[DiTBho]

is it opensource/hardware?

[theworldbuilder]

Can you just throw a load resistor on the 3.3V rail?
I mean, you've got a bunch of boards, can't you use them for further development for now?

So, there's a little bit more to the problem that I didn't add to save space on what was already a long post.

I did try a load resistor on the 3.3V rail, but for a different reason, I originally thought maybe the LDO wasn't being loaded enough to be regulating properly, this made no sense but it was worth a try.
So I tried loading the line with different resistances. I started from 200K and worked the whole way down to 1K and the shift in output regulation was a move from 3.7V to ~3.5V if I remember right.
Still out of spec

How this ties back in with what I think is the issue is that when I got my hands on the full suite of Ti docs on the part I was using I noticed that every example circuit had a 200K in series with the 5V input.
My circuit design does not. Why? I was working from the example circuit from the Nexperia datasheet. There is no sign of a 200K in series with the 5V input.
Well boy howdy have I learned my lesson not to trust Nexperia datasheets and instead do much more reading with more reputable sources.


As for making use of the boards I have, I'm not sure what to do to be honest.
I can't use the board I have already made up as I accidentally blasted 5V onto the 3.3V line. This surely killed something.
I will use this board to test my theory about the level shifters being the issue if I can isolate the level shifters on the board. I will probably bodge ground to the enable pin / cut traces.

I could make another board but I kinda don't want to waste the €15 worth of parts.



For developing the digital logic I have been doing some digging and found this gem:
https://github.com/hneemann/Digital

For anyone following along with this thread interested in developing digital logic and converting it to verilog for use on an FPGA this is a nice little visual circuit tool.
I will certainly be making use of it to put together and test blocks of logic for the uGPU.

[theworldbuilder]

is it opensource/hardware?

Short answer
Right now?
No

Long answer
Probably in the future I will make the hardware open source.
I would much rather release it in a much more polished and ready to use state.

What's mostly driving me to do this is actually the fact I gained a lot of insight into how to design this circuit from studying the circuits of the icebreaker FPGA board. (link: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga)
I was only able to do it because it is open source hardware. Although I couldn't directly use most of their circuitry it was really great to learn from.

Having purchased and used an icebreaker FPGA board I can say from experience they are great little boards for the price.

As for the HDL stuff on the uGPU, I'm not so sure. I think I would prefer to keep this closed source.

[theworldbuilder]

Here's a micro update:

So the redesigned boards have arrived fresh from JLCPCB.
Parts should be arriving tomorrow so I should be able to get a board built and tested over the weekend. Wew!

I'll post again soon with the (hopefully good) results.

For now here's a pic of the new board:

[theworldbuilder]

Time for some great news!

The uGPU boards work!  I haven't been this excited by one of my projects in a long while!

~6 months after I began this project I now how a working uGPU circuit board!

BUT the project is nowhere near being completed.
The Verilog needs a whole horde of work to even begin to turn this into the funtional uGPU I'm aiming to complete.
But having working hardware to develop on makes this job possible.

The next uGPU related thing I will be doing is working on a uGPU card for my card based 8-bit computer project.
In the mean time I will begin development of the I/O system for the uGPU so that I can begin to get data into and out of the device.

Hopefully a few posts from now I will have some kind of text terminal implemented with the 8-bit computer project that I will be able to show off!


As for the hardware itself, this will most likely not be the last revision of the board.
There are a few things I've already spotted that I would like to change around. This would probably involve making the board longer (and perhaps thinner?)
But we will have to see when this happens, it will probably be some time before I make these changes as they're not necessary right now.


This will hopefully be the beginning of some more interesting posts of the uGPU actually working in circuit!
Slowly but surely. 

Here are some images attached of the board actually working:

[theworldbuilder]

It's back! And in 16 bit!

To sum up the long absence of any posts:
Burnout, burnout, burnout.
After my last post I began to work on upgrading the uGPU RTL and uncovered the Everest sized mountain of work it was going to take to get any of what I wanted completed.
Basically everything was going to have to be thrown out and reworked, and I had no idea where to even begin. This, on top of general burnout from work and life, completely demotivated me for the last ~6 months.
I didn't work on any projects at all, let alone the uGPU.

But recently I began to work on stuff again, spending some time in familiar territory, building analog circuits for guitar distortion pedals and I supposed I was ready for the uGPU again.

The new:
So my first step was to essentially throw all of my designs and notions out the window. This meant, sprite mode and raster mode were out as well as my old pipelined design.

I decided to come from the angle of building a central state machine that would essentially handle memory transfers between VRAM, IO, and the Renderer.
This would make for a much more extendable and modifiable setup.

I also decided set more achievable goals for the uGPU:

• Text mode
• 16 x 16 pixel characters
• 78 x 43 max characters on screen

With these set out I got to work and I'm glad to say that I have gotten the uGPU working with this new design!
I'm currently having some issues where verilog seems to be synthesizing weirdly for me, i.e. minor changes that should have no effect are causing the whole video output to go from working to completely borked.
So I need to get to the bottom of these, they are a sign/symptom of not so good things going on in my code. It also means my sims are basically useless as the sims are showing the exact desired behavior.
The I/O block has also not been implemented, nor the relevant states in the state machine to handle transfers from the IO block to VRAM so this will also need to be taken care of before I can actually use the uGPU.
But I would say that it is closer than ever to a valid usable implementation which is exciting!

I'm currently adding a POR circuit to set and synchronize everything into a known state on powerup; I'm sure this will also cause my synthesis to go haywire so I can wait to debug this one.

I've attached some photos of the current output. Please excuse my crayola grade characters; the important thing is that it demonstrates the functionality of the entire flow from VRAM, through the FSM, and into the renderer.

I'll update here again when I have the I/O implemented and working with my 8-bit computer.
Until then, stay safe!

[theworldbuilder]

At last, I've succeeded.

Thrice I descended into FPGA hell. Twice I was rebuffed; turned away in defeat.

But this time, I've cracked it  All it took was another entire overhaul 

The new++ uGPU design:
This time the uGPU is built around a rudimentary 16bit RISC style processor I created specifically for this application.
The processor is a Harvard architecture, this easily allows it to be a single cycle processor.

The core pillar of the system is that the processor is put into a HALT state where all internal registers are reset until an IRQ comes in.
These IRQs will prompt the processor to do something, like load the next character data into the renderer, or transfer data from the I/O into memory.

The implementation
This being my third redesign, I designed the processor over Christmas (the 'rona made a few near passes on me, I had some spare time while I was avoiding it) and then gave myself 3 weeks to get it all implemented.
If it wasn't done by this Friday just passed I was going to can the whole thing and switch over to using an RPI zero as my video out.

So the deadline was set, and off I went. I ran into many of the same old FPGA hell speedbumps (sims working, FPGA not), and caught many of the same silly mistakes I had learned from already (using combinational logic where I really shouldn't have been).
This time it was make or break. I had to get this working. Tuesday/Wednesday I had glimmers of hope. The internal systems were behaving themselves; the processors IO routine was responding to the IRQ and transferring hardcoded data across to the video memory.
Come Thursday I implemented my first version of the IO block. A mix of messy logic combining combinational and clocked in all the worst ways; but it kind of works. Data is bouncing around not being always written to the write location, but no corruption which is good.
For the first time since I started this project I have data being written into the uGPU (a z80 got that grace) and updating characters on the screen. That felt really good!
By Friday I have made no more progress. In work I scribble out a schematic and simulate it here: http://digitaljs.tilk.eu/ (very helpful online Verilog visualizer, synthesis using yosys).
The logic seems nice and clean but I won't get to implement it until Sunday, as I'm traveling over the weekend. I know it's beyond my Friday deadline, but it was technically designed on Friday and I couldn't give up when I was so close.

So I get in on Sunday and implement and test it in hardware. Now the IO is completely stable no characters being written to the wrong location. But some of the characters just don't seem to be getting written.
With some more serious head scratching I realize that I have set my IO IRQ to clear any time the processors RD signal goes high. That means the processor could be doing something completely unrelated and accidentally clear the IRQ interrupt.
One quick processorRD AND'ed with the IO_CS line later and I have a working uGPU, with no missed character writes.

Success.



... what next?
Relax for a while. But not too long. Just the right amount. Then come back and see what functionality I can extend and add to the uGPU. I now have a processor that I can easily write any sort of program for.
Add cursor functionality? Sure. Add fancy commands like screen clearing? Absolutely. See what I can do about adding hardware scrolling to the renderer and some kind of sprite support? I'll put that on the long finger for now but it is in the pipeline.
I also had to drop the video output resolution back down to 800x600 to minimize timing issues while implementing the design, so one thing I want to try is bumping it back up to 720p.

If people have an interest in the source code, uGPU board design, or whatever let me know. I will put together documentation for myself, but if there's interest in this project I will tidy it up and make it releasable.
No promise on when I would get around to this, I want to write up an assembler and do a few other items for the uGPU's processor for the sake of my own sanity, but I will do it if it's wanted.


I've attached an image I captured of the Z80 writing characters the the uGPU.
I'll upload a video of it to YouTube and link it here when I get a chance.

[dmendesf]

Congratulations, nice work!

[theworldbuilder]

A micro update:

Put together a small Z80 assembly program that let me modify the first 256 characters using a keyboard! The rest of the screen content is just whatever RAM felt like initializing to.
My RPI is sending the characters over via UART to the 68B50 and the Z80 is taking these characters, doing a little bit of checking and then writing them to the uGPU.
I've attached some pics to this post.

When I do dive back into the uGPU I think I will add a screen blank command, set character by XY location command, and some kind of screen scroll command? Oh and try out 720p when I remember!

I think I'll try and get the uGPU working with a 6502 and 6309 soon, should just be a matter of writing some assembly!