FPGA VGA Controller for 8-bit computer

[nockieboy]

Eesh, didn't realise it had been this long - I've been flat out on work unfortunately.  I've had five minutes to look at this again and I think something is going on with Quartus optimising signals away.  I've added /* synthesis keep */ to the entirety of the IO_WR_STROBE and IO_WR_DATA buses and at least I can see those signals in SignalTap now and trigger on IO writes to the A and B input values to the FPU.  I can see that the values are getting written to the FPU, but the FPU's output (Q) is not changing.

I'm going to take a longer look at this signal optimisation when I have the time, but one thing I'm wondering is; does the FPU require a strobe on the enable line or is pulling it permanently high okay?

[BrianHG]

Test a 32bit integer multiply.
I have a feeling the floating point unit isn't compiled properly leading to a dead module which simplifies out the source A&B input channels.

[nockieboy]

Test a 32bit integer multiply.
I have a feeling the floating point unit isn't compiled properly leading to a dead module which simplifies out the source A&B input channels.

Hmm.  Well, I set up an integer multiplier using the Quartus IP wizard and it seems to be working perfectly.  I can multiply two 32-bit numbers by writing their bytes to 4 IO addresses each, and can read the (cropped to) 32-bit output via a third set of four IO ports, as intended.

Must be something wrong with the FP_MULT instantiation... 

[BrianHG]

Heeehe....
Ok, I'll look for thee old original Altera FP functions before they combined them all into that single BS megafunction wizard which generates faulty non-functional functions.  It's like they have similar problems with their DDR3 controller.

You can post your question on Intel's website or:

Ok, here are the original direct call cores:
https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/hdl/mega/mega_list_mega_lpm_d1353e88.htm

Though, it was designed for Quartus 17 and earlier.

Now, Quartus is hiding these which have been replaced with the new garbage (ie: It don't function)  you can look at the old documents here:
https://www.manualsdir.com/manuals/746181/altera-floating-point.html?page=67
(I know the pipeline should be around 11 though 5 or 6 or 10 may work depending if low numbers like 5 or 6 can reach your operational 100MHz clock.)

[nockieboy]

The new IP cores don't work?

I hadn't checked the results of the previous test, it was enough that the output had changed and actually had a value in it for me.

I'm compiling the project again as I write this (it's taking over 5 minutes per compile now), with IP files in the right folder.  Using these IP cores is a no-no then?

[BrianHG]

Did you check the compiler messages window?
Maybe there is a clue there, like couldn't find source file XXXX, or simplifying out module XXXX because it is not clocked, or net XXXX missing or wire XXXX generated which usually means a 1 bit wire....

[nockieboy]

Okay, so I've done some very quick and dirty testing of the FP_MULT core provided by Quartus and it's returning values that I'd expect (using integers to multiply each other).  I might have some time later to multiply some fractions, but for the moment it seems to be working okay..

I'll have a look at the compile messages later this week if I get some more time.

EDIT: Fractions seem to be working fine too, at least in so far as the single-precision accuracy allows.

[BrianHG]

EDIT: Fractions seem to be working fine too, at least in so far as the single-precision accuracy allows.

Are you saying that your Z80 basic also requires 64bit floating point number support?

Hmmm.
Maybe make an all 64bit ALU, then just select translate the source format to 64bit double, then down translate the 64 bit result to the selected format.

I thought that a 32bit int and 32bit float ALU would have been enough.

[BrianHG]

EDIT: Fractions seem to be working fine too, at least in so far as the single-precision accuracy allows.

PLS verify negative numbers.

[nockieboy]

EDIT: Fractions seem to be working fine too, at least in so far as the single-precision accuracy allows.

Are you saying that your Z80 basic also requires 64bit floating point number support?

Hmmm.
Maybe make an all 64bit ALU, then just select translate the source format to 64bit double, then down translate the 64 bit result to the selected format.

I thought that a 32bit int and 32bit float ALU would have been enough.

No no, single precision is fine, I was just acknowledging slight rounding errors thanks to the single precision.  I don't need double precision (at least afaiaa).

PLS verify negative numbers.

Have tried multiplying negative x positive, and negative x negative as well as positive x positive.  All results appear correct.

EDIT: Just need some coherent free time so I can sit down and get my head around displaying/reading 32-bit floats to/from ASCII.  There's some source code out there, I just need to interpret and repurpose it.

[BrianHG]

EDIT: Just need some coherent free time so I can sit down and get my head around displaying/reading 32-bit floats to/from ASCII.  There's some source code out there, I just need to interpret and repurpose it.

I usually read a strict integer, then multiply by the correct base 10 decimal point position.

Setting the input integer as the mantisa and use the decimal to set the exponent value wont work because the exponent is in base 2, not base 10.

Note that there does exist FP unit conversion megafunctions to convert to and from integer and FP.

[BrianHG]

When will you add the rest of the FP functions?

Also register moving/copying and FP <-> INT functions.

Also, don forget all the 32bit int functions...

Might as well add Zero and Negative & Carry/Overflow flags.
(IE, performing a FP subtract between A&B will tell you if A>B, A=B, or A<B by examining the flags, or if you use a separate FP_SUB function, Always leave it wired on and have dedicated A>B, A=B, or A<B as part of your FP flags as well as having INT flags.)

All together, this should make your Z80 perform 32 bit functions with absurd speed.

Though, making the ALU DMA right through the DDR3 ram with a start and stop memory coordinates like we were going on about a number of posts before would make it to ludicrous speed in Z80 terms.

[nockieboy]

When will you add the rest of the FP functions?

Also register moving/copying and FP <-> INT functions.

Also, don forget all the 32bit int functions...

Might as well add Zero and Negative & Carry/Overflow flags.
(IE, performing a FP subtract between A&B will tell you if A>B, A=B, or A<B by examining the flags, or if you use a separate FP_SUB function, Always leave it wired on and have dedicated A>B, A=B, or A<B as part of your FP flags as well as having INT flags.)

All together, this should make your Z80 perform 32 bit functions with absurd speed.

Though, making the ALU DMA right through the DDR3 ram with a start and stop memory coordinates like we were going on about a number of posts before would make it to ludicrous speed in Z80 terms.

I'll get the other functions added as soon as I can get the FP_MULT function fully testable in BBCBASIC.  I have confirmed that it's working - have a small program that allows me to set and read values and it's producing the right results, but right now my next step is to get it integrated (i.e. replace the existing FP math routines) in BBCBASIC so it can accelerate the math in already-existing programs like the Mandelbrot generator, where I can see at a glance the improvements it's making.  Unfortunately, it's taking me a little time to pull the complex web of functions apart to work out what to isolate and replace in the BBCBASIC code with my FPU interface code.  Once that's working, I'll add the other functions - integrating them should be a lot easier then as I'll have an example to work from.

[nockieboy]

Are you saying that your Z80 basic also requires 64bit floating point number support?

Hmmm.
Maybe make an all 64bit ALU, then just select translate the source format to 64bit double, then down translate the 64 bit result to the selected format.

I thought that a 32bit int and 32bit float ALU would have been enough.

Coming back to this comment - I've got the FP multiplier working with BBCBASIC now, but it uses 40-bit floats - 8-bit exponent, 1-bit sign, 31-bit mantissa.  Currently I'm dropping the last byte of the mantissa from BBCBASIC's floats for the FPU, but it would be trivial to build a new FPU that supports 40-bit floats.

My question is - should I?  Or should I just go for double-precision and dumb it down for BBCBASIC?

EDIT: Also, is this okay? (Referring to the minus 1 mathematical operation on the first byte)

Code: [Select]

q        <= { (output_Q[SIZE-2:SIZE-9] - 1), output_Q[SIZE-1], output_Q[SIZE-10:0] } ;

[BrianHG]

Well, you can make a 40bit FPU, and then make 2 sets of ports, one with 4xbyte 32bit wiring and another with 5xbyte 40bit wiring.

Or, go the 64bit route and make a 3 sets of IO ports, 32, 40 & 64 bit ports.
IE: A write to the 32 or 40 bit IO ports would properly fill/translate to the 64bit port with the correct padded number.  Writing to the 64bit port would be a raw direct feed to the FPU.  Your only problem is the Zero flag.  You will need to test the results to see if a true 0 has been reached because of an exponent which happens to be too far to the right to be seen by a 40bit result.  Same for the overflow flag having an exponent too far to the left.

 (Only a guess) I can imagine the 40bit mess was designed in BBC basic to exclusively run floats for all variables.  This way, when calculating integers, you can still maintain 32bit int precision.

Note that 64bit floats may require a 'NOP' on the Z80 before the read when doing a 64bit divide.  That one's pipeline may be a good 30-50 clocks to support 100MHz.  However, at Z80 speeds, my guess just the next instruction fetch will consume more time that that.  Then again, running a 40bit or 64bit divide with a single 'NOP' latency should still be much faster than calculating it with an 8bit CPU the long-way.

[nockieboy]

Well, you can make a 40bit FPU, and then make 2 sets of ports, one with 4xbyte 32bit wiring and another with 5xbyte 40bit wiring.

Or, go the 64bit route and make a 3 sets of IO ports, 32, 40 & 64 bit ports.
IE: A write to the 32 or 40 bit IO ports would properly fill/translate to the 64bit port with the correct padded number.  Writing to the 64bit port would be a raw direct feed to the FPU.  Your only problem is the Zero flag.  You will need to test the results to see if a true 0 has been reached because of an exponent which happens to be too far to the right to be seen by a 40bit result.  Same for the overflow flag having an exponent too far to the left.

I went with a 40-bit FPU in the end, one set of IO ports and the ability to tell the FPU what format to use.

(Only a guess) I can imagine the 40bit mess was designed in BBC basic to exclusively run floats for all variables.  This way, when calculating integers, you can still maintain 32bit int precision.

Spot on.

I've run the Mandelbrot BASIC program and am getting a ~14% speed increase drawing the image, using FP multiply, divide, add and subtract hardware acceleration.  That seems like a really small speed increase, but there's a lot of stuff going on in the background with BBCBASIC around the floating point math.  I suspect a true floating-point 3D application would speed up even more.

I'm probably doing it all wrong, but I've attached the top module and the FPU's top module so you can see what I've done.  This is all implemented using Altera's own FPU core IP generated in Quartus.  As always, feedback appreciated.  I'm away all of next week, so progress is going to remain slow for a while, unfortunately.

[BrianHG]

Ok, in the attached code, you forgot to include the FP_lpm functions.

Anyways, I would have not used all those dumb strobes in the _top.sv.

For the format, that should be I'm guessing a write port and you should include it's strobe into the ALU.

Using that strobe for the function, you can latch the all of the 'IO_WR_DATA' which should be directly tied to the input_A & input_B to your new ALU's internal register's in_A and in_B.

Now, it will be possible to add functions combined with the function's 'strobe' for a single stroke action to, for example, copy all of the multiply/divide/add/sub's output back into register in_A or in_B.  Or, you can swap in_A and in_B.

These are suggestions to allow a few more examples, like in the future having 16x in_A and 16x in_B registers with an output table of results.  This may help in storing rotation/scale factors and requesting a block of computation or transformation matrix in a single go.

[nockieboy]

Ok, in the attached code, you forgot to include the FP_lpm functions.

LPM_COMPARE, LPM_COUNTER, LPM_DIVIDE and LPM_MULT?

I'm in the process of looking up what the LPM functions are.  Not finding much info on them other than they're a library of parametrised modules, or Lagrangian Particle Methods (don't think they're the last one!)

What are they?  What's their use-case?

Anyways, I would have not used all those dumb strobes in the _top.sv.

For the format, that should be I'm guessing a write port and you should include it's strobe into the ALU.

Using that strobe for the function, you can latch the all of the 'IO_WR_DATA' which should be directly tied to the input_A & input_B to your new ALU's internal register's in_A and in_B.

Yes, it's an IO port that the host writes to so that it can set the ALU's function.  Currently, you set the function and the output of the ALU changes accordingly.  The output is 'live', so you send the floats to the ALU by writing to the 8 IO ports for them and read the result, either setting the function before or after the floats are sent (I do it before).

You're saying I should stop updating the IO_RD_DATA array with any writes to the FPU IO ports by using the FORMAT IO strobe to signal to the FPU to latch all the IO_WR_DATA ports to the appropriate inputs (a, b)?

I understand passing a strobe into the ALU module will be useful, but it's handy to be able to read the value on each ALU IO port so I'm not sure of the benefits of latching the IO_WR_DATA directly to the ALU's inputs?

Now, it will be possible to add functions combined with the function's 'strobe' for a single stroke action to, for example, copy all of the multiply/divide/add/sub's output back into register in_A or in_B.  Or, you can swap in_A and in_B.

Surely I can do this currently, as inputs a & b to the ALU module aren't passed directly to the FPU sub-modules and can be redirected by the ALU?

These are suggestions to allow a few more examples, like in the future having 16x in_A and 16x in_B registers with an output table of results.  This may help in storing rotation/scale factors and requesting a block of computation or transformation matrix in a single go.

Sounds good!  I think I just need to understand the reasoning behind moving the IO_WR_DATA bus directly into the ALU module; there's clearly something I'm misunderstanding.

[BrianHG]

Ok, in the attached code, you forgot to include the FP_lpm functions.

LPM_COMPARE, LPM_COUNTER, LPM_DIVIDE and LPM_MULT?

I'm in the process of looking up what the LPM functions are.  Not finding much info on them other than they're a library of parametrised modules, or Lagrangian Particle Methods (don't think they're the last one!)

What are they?  What's their use-case?

  Where is the source code for the following functions in red?

  ADD40 addsubber (

    .clk    ( clk      ), // clk
    .areset ( areset   ), // reset
    .a      ( factor_A ), // a
    .b      ( factor_B ), // b
    .q      ( ADD_Q    ), // output
    .s      ( SUB_Q    )  // output

  );

  DIV40 divider (

    .clk    ( clk      ), // clk
    .areset ( areset   ), // reset
    .a      ( factor_A ), // a
    .b      ( factor_B ), // b
    .q      ( DIV_Q    )  // output

  );

  MULT40 multiplier (

    .clk    ( clk      ), // clk
    .areset ( areset   ), // reset
    .a      ( factor_A ), // a
    .b      ( factor_B ), // b
    .q      ( MUL_Q    )  // output

  );

endmodule

[nockieboy]

I've included the entire FPU module in the attachment, so all files should be there.

[nockieboy]

Eek.  Been so busy recently.  Have been pottering about with the graphics tile demo/game I started ages ago this evening and managed to take some pictures of these blue lines/artefacts that occasionally appear on screen - they'll fade in, flicker about, the pattern might change (as shown in the pics) and they'll disappear again.  I've tried cable-wiggling as my most serious attempt to debug the issue, but now I have photographic evidence thought I'd post here to see if there's an HDL or FPGA cause for this issue?

 

[BrianHG]

If the issue is with a too long or bad HDMI cable, then there is nothing you can do in firmware to fix.
(IE: if plugging and unplugging the cable or changing a HDMI cable, switching to a different monitor input changes the garbage pattern, then the issue is not in the firmware) \

(Note that my LG Flatron24 did this on the red channel when I used the HDMI input and the DECA board.  Switching to the DVI input using a HDMI-DVI adapter fixed the issue,)


Otherwise, we need to look at your compiler build's timing report.

If timing isn't met for the VGA output clock section, maybe just changing the compiler optimization technique will fix the issue.

Or, maybe, I need to invert the VGA output dac clock, or set the DVI encoder's CLK input phase using it's I2C controls.

[nockieboy]

Okay, no worries, when I get a moment I'll plug it into my TV in the living room and see if the lines appear there.  It's only a 1-metre HDMI cable, but points taken about the cable quality etc.

Any follow-up on the FPU thread at all?  Is that implementation okay or are there issues?

[BrianHG]

Okay, no worries, when I get a moment I'll plug it into my TV in the living room and see if the lines appear there.  It's only a 1-metre HDMI cable, but points taken about the cable quality etc.

Any follow-up on the FPU thread at all?  Is that implementation okay or are there issues?

The FPU implementation is up to you.

Did you fix the video blue speckles?

[nockieboy]

Did you fix the video blue speckles?

I think it must be interference on the HDMI cable somewhere, I've re-routed the cable and it hasn't come back since, but I've not had any long periods of time to test for it recently, so I'll hold fire on calling it fixed just yet.