FPGA VGA Controller for 8-bit computer

[BrianHG]

is there any need to step at all?  Couldn't we just parallelise the entire system and have them feed the multiplied values into the accumulator simultaneously?

DSP slices are not magically 32bit, and they are not magically floating point, and even if you do fixed point you have larger infra logic.

Usually DSP slices are 16 bit sized

Can a 32x32 multiply be done with 16x16 multiplies?

               Z = UMUL(X, Y)

Let us now split each of X and Y into two subwords of k-bit each
               X = 2^k*X1 + X0
               Y = 2^k*Y1 + Y0

X1 is the integer formed by the k most significant bits of X
X0 is made of the k least significant bits of X.

The product Z=UMUL(X,Y) may be written

               Z = 2^k* X1*Y1 + 2^k* (X1*Y0 + X0*Y1) + X0*Y0  (1)

X0*Y0 ----> DSP slice
X0*Y1 ----> DSP slice
X1*Y0 ----> DSP slice
X1*Y1 ----> DSP slice
2^k*   ----> shifter

We are not limited on available DSP slices.  We will have the room to individually allocate a FP 32x32 mult unit, an INT 32x32 mult unit, a FP 32x32 div unit,  an INT 32x32 div unit, same with adders, sine, (we may make cosine use an added FP offset of sine to save on resources here unless Altera though of that and built it into their trig functions.) and there is probably room for a square-root.  We will also allow auto-translate from INT-FP, back and forth in and out of each function's A and B inputs, + outputs in real time.  In fact, it may be more convenient to use FP64 for all the functions and just translate the inputs and outputs to the desired bit and INT/FP format.

However:

To make things >20x faster, we would need 4 ALU sections, each with 4x multiplies running my first option all in parallel arriving taking in 128bits at a time and outputting 128 bits at a time with the table [a...p] pre-loaded from ram into a cache.  But this would be a dedicated ALU module just for this instead of a generic any copy & compute module.

this would mean having 4x or 16x 32x32FP multiply-adds eating up most of our available DPS slices if not all.

[BrianHG]

... inc size fraction=0  ,...

Earlier everywhere I wrote ' inc size fraction=0 ', it should have been ' inc size fraction=1 '.

As in add to the integer pointer every loop iteration.
When it was ' inc size fraction=0.25 ', this means add to the integer pointer every fourth loop iteration.

[nockieboy]

Ok, well you are warming up to the idea.
A fractional step is used to re-iterate a source or destination value multiple times before going onto the next term.

Maybe this will help you better see things, where do you store everything?
Assuming everything is a 32bit float...

For example, place [a] in address 1000, [ b ] address 1004, [c] in address 1008... [p] in address 1060.

For [x,y,z,w], lets place them at address 0200000 to 0200012, a group of 1000000 these coordinates meaning addresses 0200000 -> 1799996.

And we want the output to begin at 8000000 consisting of the top row [ax+by+cx+dw] and so forth...

One method may be:

Code: [Select]

set source A-B function to 32x32bit floating multiply and output accumulator = on.
set loop iterations to 1000000x4.  (we neex 4x the number of iterations since every B needs to be multiplied 4 times the number of A inputs)

// Process all the [x]
A   begin address =    1000, A   inc size int =  4,   A inc size fraction=1   , A   size loop limiter = 4.         (every 4 reads, loop back to begin address, A multiplier's input rotates around the read data [a,b,c,d])
B   begin address = 0200000, B   inc size int = 16,   B inc size fraction=0.25, B   size loop limiter = 2billion.  (4 every loops, hop from [x] to the next [x])
Out begin address = 8000000, Out inc size int = 16, Out inc size fraction=0.25, Out loop size limiter = 2billion.  (accumulate every 4 A*B together into 1 address, then jump 4 to the next output address.)
Run

// Process all the [y]
A   begin address =    1016, A   inc size int =  4,   A inc size fraction=1   , A   size loop limiter = 4.         (every 4 reads, loop back to begin address, A multiplier's input rotates around the read data [e,f,g,h])
B   begin address = 0200004, B   inc size int = 16,   B inc size fraction=0.25, B   size loop limiter = 2billion.  (4 every loops, hop from [y] to the next [y])
Out begin address = 8000004, Out inc size int = 16, Out inc size fraction=0.25, Out loop size limiter = 2billion.  (accumulate every 4 A*B together into 1 address, then jump 4 to the next output address.)
Run

// Process all the [z]
A   begin address =    1032, A   inc size int =  4,   A inc size fraction=1   , A   size loop limiter = 4.         (every 4 reads, loop back to begin address, A multiplier's input rotates around the read data [i,j,k,l])
B   begin address = 0200008, B   inc size int = 16,   B inc size fraction=0.25, B   size loop limiter = 2billion.  (4 every loops, hop from [z] to the next [z])
Out begin address = 8000008, Out inc size int = 16, Out inc size fraction=0.25, Out loop size limiter = 2billion.  (accumulate every 4 A*B together into 1 address, then jump 4 to the next output address.)
Run

// Process all the [w]
A   begin address =    1048, A   inc size int =  4,   A inc size fraction=1   , A   size loop limiter = 4.         (every 4 reads, loop back to begin address, A multiplier's input rotates around the read data [m,n,o,p])
B   begin address = 0200012, B   inc size int = 16,   B inc size fraction=0.25, B   size loop limiter = 2billion.  (4 every loops, hop from [w] to the next [w])
Out begin address = 8000012, Out inc size int = 16, Out inc size fraction=0.25, Out loop size limiter = 2billion.  (accumulate every 4 A*B together into 1 address, then jump 4 to the next output address.)
Run

Since we are using 1 multiplier and 1 adder, to do the matrix 4x4, I ran the function 4 times to illustrate what was going on.  In actually, this can be combined down to:

Code: [Select]

set source A-B function to 32x32bit floating multiply and output accumulator = on.
set loop iterations to 1000000x16.  (we need 16x to process everything...)

// Process all the [x,y,z,w] in a single shot.
A   begin address =    1000, A   inc size int =  4,   A inc size fraction=1   , A   size loop limiter = 16.        (every 16 reads, loop back to begin address, A multiplier's input rotates around the read data [a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p])
B   begin address = 0200000, B   inc size int =  4,   B inc size fraction=0.25, B   size loop limiter = 2billion.  (4 every loops, hop from [x,y,z,w], to next [x,y,z,w])
Out begin address = 8000000, Out inc size int =  4, Out inc size fraction=0.25, Out loop size limiter = 2billion.  (accumulate every 4 A*B together into 1 address, then jump 4 to the next output address.)
Run

To run as fast as possible, you will need to choose base addresses which sit on 128bit boundaries as the 16 bytes used in 4x32bit words fit inside my DDR3 controller's cache.  My first solution only requires the [a...p] multipliers sitting on 128bit boundaries while the object's coordinates [x..w] only need to be located on 32bit boundaries.

To make things >20x faster, we would need 4 ALU sections, each running my first option all in parallel arriving taking in 128bits at a time and outputting 128 bits at a time with the table [a...p] pre-loaded from ram into a cache.  But this would be a dedicated ALU module just for this instead of a generic any copy & compute module.

Ah okay, thanks for clearing up the fraction values.   I'll take a deeper look at this later, I might have some time tomorrow but otherwise this week (and weekend) aren't looking good, so it may be next week before I can work my way through your examples and make a start on some HDL.

[DiTBho]

Things like back-face culling needs to be don in software, here it's when z80 won't help.
That's why I asked you to write/think about the software side BEFORE implementing stuff in HDL.

[nockieboy]

Things like back-face culling needs to be don in software, here it's when z80 won't help.
That's why I asked you to write/think about the software side BEFORE implementing stuff in HDL.

My focus is on creating a versatile FPU; if it can speed up 3D transformations, then that's a great bonus.  If we progress to the point where this turns into a fully-fledged 3D engine then back-face culling will be an issue for consideration.  Calculating vertex order shouldn't be too difficult (without thinking it through much more than working out if they're drawn in clockwise/anti-clockwise order - there could well be issues that I'm unaware of) so working out if they're reversed in a scene shouldn't be too hard in HDL.  Normals, back-face culling, clipping, occlusion culling; I'm still thinking about how to perform 3D transformations on vertices, let alone developing a system that will cope with all these extra features just yet.

[DiTBho]

The point is: isn't 3D too much for z80?

You want PlayStation-like but 1) floating-point and z80-based where on PlayStation things are fixed-point, accelerated by a GTE chip and scenes and misc performed on MIPS-R3K CPU with both higher CPI and clock frequency than your Z80.

I think the GTE is great, but the last part, the CPU contribution, is also very important for the final application.

[nockieboy]

The point is: isn't 3D too much for z80?

Very much so, if you're after ray-traced 3D worlds covering kilometres of play area.  I don't know what your experience of computing is (i.e. how far you go back), but I suspect you've got an entirely different picture of what you think I want when I talk about 3D graphics in this context.

Before I go any further, let me just reiterate that I want an FPU that could potentially be flexible enough to do 3D transformations.  That's all.   Anything else is a bonus - I have to add that, as I have found through experience that BrianHG has a talent for blowing my expectations out of the water and producing something truly "over the horizon" in terms of what I wanted or thought possible.  This whole thread is case-in-point for that.  When I think of 3D graphics in the context of the Z80, I'm thinking of graphics like this:

Starglider on the Amstrad CPC:

i.e. simple wireframe graphics; no BFC, no occlusion-culling, no Gouraud shading, no texture mapping, no forward-rendering, and definitely no smegging flapjacks (see Red Dwarf for that last one).

You want PlayStation-like but 1) floating-point and z80-based where on PlayStation things are fixed-point, accelerated by a GTE chip and scenes and misc performed on MIPS-R3K CPU with both higher CPI and clock frequency than your Z80.

I think the GTE is great, but the last part, the CPU contribution, is also very important for the final application.

Again, no argument from me - I totally agree that the Z80 would be a hideously limiting factor in that feature set (unless the 3D engine is smart enough);  but I'm not after PS1-like graphics, as I've stated above.  I am putting together an FPGA video engine that can work with any number of different host systems, not just Z80s.  If I ever get the time, I'll make a 16-bit Motorola 68010 system and be using this same FPGA video system with that - could you say that system wouldn't be able to handle PS1-style graphics with suitable hardware acceleration in the FPGA?

[BrianHG]

What I described above, the setup factors will also be stores in DDR3 and multiples of these programs can call each other in a greater loop.  So, even such programs can calculate or LUT modify the factors of another.  You have enough to create a ray-caster engine equivalent to Doom.  Though, I would stick to 640x480 for this, though you may get away with 32bit color.  For this core, I only choose something super simple where you only need 4x 32bit adder counters for (A), the same thing for (B), the same thing for (OUT) while keeping track of an 'OP-Code'.   You will use 1 new read port to fetch the instructions, the next read port to fetch the (A) directed by it's 4x 32bit counters, another read port to fetch the (B), then one read/write port to write the (OUT) with it's control counters.

The opcode controls what function will be written.
The int and fractional counters allow us to for example split or selectively render just the red or green or blue, split them apart, do a contrast / brightness / rgb/yuv conversions.  For audio split / combine stereo audio, apply volume to individual channels.  For geometry, well we have already been discussing that.

However, the ALU with it's opcode itself will need some planning.  It is not the math functions themselves as Altera has all the floating point and integer functions, including trig, available for free in their IP store.  It's the decision of how we wire the int/FP in and out conversions as many thing will need int and float conversion and we want to do this on they fly instead of doing another FPU pass when it is not necessary.

Separate of the ALU, one last graphics function we never attempted was a raster graphics fill routing.  All our line / ellipse / box / triangle can perform fills on themselves, but what we are missing is a means of drawing a geometric shape, or have a ready picture made on the screen and decide to choose a pixel and begin a flood fill on all connected pixels of that same color to a new color.

[nockieboy]

Separate of the ALU, one last graphics function we never attempted was a raster graphics fill routing.  All our line / ellipse / box / triangle can perform fills on themselves, but what we are missing is a means of drawing a geometric shape, or have a ready picture made on the screen and decide to choose a pixel and begin a flood fill on all connected pixels of that same color to a new color.

Ah yes, I'd forgotten about that!   That would round the geometry engine out nicely.

[BrianHG]

@Nockieboy, have you tried to wire an Altera FP unit to IO ports?

Just use the FP_Mult for example.

Wire the A & B inputs to out ports 0,1,2,3 & 4,5,6,7 and wire the read output to ports 8,9,10,11.

Then add a FP_ADD's inputs also to ports 0...7, but wire the output to read ports 12,13,14,15.

Then do a divide, sine, 32 bit integer add/sub & divide.

Use a dumb write port numbet to latch the results or something to the effect.

Also add an int -> FP and FP -> int converter, maybe piggybacked on ports 0...7 and output.

Like I said, start with a new module and add first 1 multiplier.
Configure the multiplier so that it can run up to 150MHz.
Note the pipeline delay.  (Though, it will be so fast the Z80 couldn't even read a result before it finishes).
Show your progress and don't forget to double check the features of you generated module & pack everything in a new folder not to mess up what you already have.)

[nockieboy]

@Nockieboy, have you tried to wire an Altera FP unit to IO ports?

Not yet.  I'll try to have a go at this today - this will require some work in Quartus, right?  I'm going to need to create these modules from Quartus IP before wiring them up in the DECA_DDR3_top.sv?

[BrianHG]

@Nockieboy, have you tried to wire an Altera FP unit to IO ports?

Not yet.  I'll try to have a go at this today - this will require some work in Quartus, right?  I'm going to need to create these modules from Quartus IP before wiring them up in the DECA_DDR3_top.sv?

Make a module called nockieboy_alu.sv
do your work in there.
Place that module in _top.sv.
Wire it to the Z80-bus write and read ports.
Use 10 write ports for 32bit A & B and 2 more for alu function.
Use 4 read ports for 32bit return data from the ALU out.

[nockieboy]

@Nockieboy, have you tried to wire an Altera FP unit to IO ports?

Not yet.  I'll try to have a go at this today - this will require some work in Quartus, right?  I'm going to need to create these modules from Quartus IP before wiring them up in the DECA_DDR3_top.sv?

Make a module called nockieboy_alu.sv
do your work in there.
Place that module in _top.sv.
Wire it to the Z80-bus write and read ports.

I'm going to have to move the legacy ports out of Bridgette before I can wire the ALU up - that task has finally been upgraded to 'blocker' from 'nice-to-do'. 

[nockieboy]

Okay, legacy IO has been moved out of Bridgette into its own module (which I may break up even further later for true modularity) and I can make a start on the ALU interconnects later.

In the meantime however, I have a question regarding this line in the _top module:

Code: [Select]

wire [  7:0] IO_RD_DATA [0:255] ; //= '{ default: 8'hFF } ;
I'm assuming that Quartus will prune IO_RD_DATA down to just the wires that are actually in use.  If I uncomment the code setting a default value of 0xFF to all the wires in IO_RD_DATA, will that then cause Quartus to keep them all in the FPGA, or will it still prune the unused ones?

[BrianHG]

Unused wires will get pruned.  You might not get the option to to use the 'default' inside the Z80 module.
You might have to do this outside the module in your _top.sv: (example)

Code: [Select]

logic [7:0] READ_PORT_DATA [0:255] = '{default:8'hFF};  or '{default:8'hZZ};'Wire' might not work, which is why I used 'logic', in the case of this one port name.  'Wire' will work with everything else.


Wire that logic to the Z80 read port inputs.

Remember, when feeding another modules' 16bit device input port:

Code: [Select]

.din ( '{WRITE_PORT_DATA[port_name_hi],WRITE_PORT_DATA[port_name_lo]} )or 32bit (orient the +# to your preferred endian)
 

Code: [Select]

.din ( '{WRITE_PORT_DATA[port_name+3],WRITE_PORT_DATA[port_name+2],WRITE_PORT_DATA[port_name+1],WRITE_PORT_DATA[port_name+0]} )
Also use the write ena/strobe: (hi/lo depends on your write order scheme.

Code: [Select]

.din_ena ( WRITE_PORT_STROBE[port_name_hi/lo] )
Also use the read ena/strobe:  (not always used)

Code: [Select]

.dout_read_ena ( READ_PORT_STROBE[port_name_hi/lo] )
Just like the above 16bit and 32bit examples, you can concatenate larger size buses as you wish, or individually feed 8bit slots, you just feed through the entire 8bit x 256address array.

Read is a little more tricky as you cannot have bus conflicts.  So just keep to individual read port numbers to individual devices.

[nockieboy]

Unused wires will get pruned.  You might not get the option to to use the 'default' inside the Z80 module.
You might have to do this outside the module in your _top.sv: (example)

Code: [Select]

logic [7:0] READ_PORT_DATA [0:255] = '{default:8'hFF};  or '{default:8'hZZ};

Yep, that's where the code I quoted in my previous post sits - in the GPU_DECA_DDR3_top.sv module. 

Remember, when feeding another modules' 16bit device input port:

Code: [Select]

.din ( '{WRITE_PORT_DATA[port_name_hi],WRITE_PORT_DATA[port_name_lo]} )or 32bit (orient the +# to your preferred endian)
 

Code: [Select]

.din ( '{WRITE_PORT_DATA[port_name+3],WRITE_PORT_DATA[port_name+2],WRITE_PORT_DATA[port_name+1],WRITE_PORT_DATA[port_name+0]} )
Also use the write ena/strobe: (hi/lo depends on your write order scheme.

Code: [Select]

.din_ena ( WRITE_PORT_STROBE[port_name_hi/lo] )
Also use the read ena/strobe:  (not always used)

Code: [Select]

.dout_read_ena ( READ_PORT_STROBE[port_name_hi/lo] )
Just like the above 16bit and 32bit examples, you can concatenate larger size buses as you wish, or individually feed 8bit slots, you just feed through the entire 8bit x 256address array.

I'm a step ahead, I already have it all running nicely.

Code: [Select]

   .fifo_cmd_in      ( { IO_WR_DATA[GEO_HI], IO_WR_DATA[GEO_LO] } ), // 16-bit command bus from Z80_BRIDGE.
Above is a snippet from the current GPU_DECA_DDR3_top module as an example of what you're talking about, I think - feeding two 8-bit values into a 16-bit input?

(The latest code is viewable in the github project, btw).

Read is a little more tricky as you cannot have bus conflicts.  So just keep to individual read port numbers to individual devices.

I've kept the IO_RD_DATA bus in the GPU_DECA_DDR3_top module, as a number of sub-modules write data into that bus I've had to keep it a level above the sub-modules to avoid conflicts as you've mentioned.  See the _top module in the github repo for details.

On to linking up the FPU multiplier tomorrow.

[BrianHG]

Just a note, reserve and pass 16 sequential write ports for your command as this is 128bit and the size of the op-code which we will eventually use when reading such code from DDR3 memory.

IE, the 128bits worth of IO port from the Z80 can sever as a direct bypass to the MMU-ALU controls when you do not want to bother getting the MMU / DDR3 part involved with simple calculations.

[nockieboy]

I'm obviously making a silly mistake somewhere, because I can't get anything other than zeros out of the FPU.  I'm able to set factor_A and factor_B values in the nockieboy_FPU module, but output_Q remains stubbornly zero.  I can't seem to get traces in SignalTap for the reset and enable ports to the FPU either - I suspect they're being pruned out which is why the FPU isn't working, but I don't have the time this weekend to play around with it to find out why.

I've attached the key modules involved - if there's an obvious mistake I'm making then let me know, otherwise I might have more time tomorrow night to dig deeper and preserve some of these wires to see what's going on in SignalTap.

[BrianHG]

Other than the extra steps, this looks like it should work.
You can try hard wiring the 'reset' to 0 as it wont make a difference here and it is not needed for now.

Can you successfully write a value to the A and B ports, then just read back port the A and B with the values you just written?

[nockieboy]

Other than the extra steps, this looks like it should work.
You can try hard wiring the 'reset' to 0 as it wont make a difference here and it is not needed for now.

Can you successfully write a value to the A and B ports, then just read back port the A and B with the values you just written?

Yes, I'm getting the written values back fine.  I'm wondering if there's a reset problem, as I'm unable to get that line in SignalTap.  Will have time later today (certainly next two days) to looker deeper.  I'd just assumed I'd made a simple mistake somewhere.

[BrianHG]

Use a different proper reset line which I have made available throughout your project.

[BrianHG]

Well?

[nockieboy]

No progress this week, I'm afraid.  I haven't had any time to even think about the project, let alone work on it.  The last thing I tried was a fixed reset line, no change.  Maybe I'll have some time at the weekend.

[nockieboy]

Have just tried with fixed reset, both high and low just in case it was active high, still getting zero from the FPU.  I'm setting A and B inputs to 7 and 9 respectively, I'm able to read the results back, and the Q output isn't changing at all - all I'm reading back is 0's.

Latest project attached so we're on the same page.

[BrianHG]

Place in an absurd number.

Remember, it is floating point, the exponent needs to be set, though anything you enter besides 0 should work.

It may be a bug in the megafunction.

Can you try an integer 32x32bit multiply?