I took the 6502 floating point code sample available under the code section of this website and converted it to Verilog. At the same time I extended the precision to triple precision arithmetic. The floating point core is available to a system as a memory mapped peripheral.
Only basic operations are supported: ADD,SUB,MUL,DIV,NEG,fixed to float and float to fixed conversions.
There are two triple precision floating point accumulators located at $FEA200 and $FEA210. The command / busy status port is at $FEA20F.
The core is fairly small, taking up 6% of a XC6SLX45. It doesn't have barrel shifters and shifts are a bit at a time, but it's much faster than software The core can be clocked at a high frequency.

**Currently the core is untested.

_________________
http://www.finitron.ca

This sounds very interesting. Even without the barrel shift feature, I'd expect that performance would be way faster than software. Does your "FP unit" become a bus master when it's working its magic?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nope. It does not master the bus. It relies on the cpu to move data to a from the FAC's. Compared to some other FP units performance is probably pretty dismal, but it's still probably an order of magnitude faster than software. It does manipulate values using the full width of the FAC in a single cycle. Software would have to loop around processing in chunks.

It's a starting point. It could have more FAC registers, and DMA operations for loading and storing data. It's 12 bytes per floating point value.

I started out trying to port the code in assembler for the 65816, and ended up just porting it to Verilog instead.

_________________
http://www.finitron.ca

How many cycles does an average operation take? And what happens if an interrupt hits during that time?

I'm not sure how to calculate an average, but I can provide an idea (estimate) of how many cycles the various ops take. Most operations end with a normalization step, the number of clock cycles required to perform a normalization varies depending on the data.
Normalize: max 160 clock cycles (2 per bit), minimum 1 clock cycle.
ADD: minimum of 8 clocks under idea conditions (exponents are the same so there's no shifting of operands) If non-ideal add plus 3x a max of 80 to align operands, plus normalization
SUB: 3 + number of clock cycles to do an ADD. (A SUB is just an ADD with a complemented FAC).
MUL: about 10 + 4x 80 (about 350 clocks) + normalization
DIV: about 10 + 2x 80 (about 200 clocks) + normalization (Divide is faster than MUL because it has a dedicated shifter)

It does take a ton of clock cycles because it's shifting an 80 bit mantissa a bit at a time. So it can take 100's of clock cycle to complete an operation. It's still much faster than software for the same operation. * I counted up the clock cycles manually by looking at the state machine, so I could be a little off. It can be determined by running simulations exactly how long a particular operation takes.


The core is organized as a memory mapped peripheral. It accepts a command, then processes the command independently of the cpu. So the cpu can go off and perform other processing like interrupts while it waits for an operation to complete. It doesn't delay the cpu any more than a normal memory or I.O cycle would. Software must poll the busy bit in the FPU's status register to find out when an operation is complete. The status has to be checked before a command sent to the FPU, otherwise if the FPU is busy it'll ignore the command.
I've been thinking of adding an interrupt signal to indicate the completion of an FP operation.

_________________
http://www.finitron.ca

I found a way to speed up the multiplies without adding any hardware. So they are the same as a divide now. I replicated the shift logic in a multiply state, rather than call a shift subroutine. But because it's the same shifting logic, the synthesizer is smart enough to generate code for it only once.
I also found a bug in ADD/SUB while testing. The carry flag wasn't being set from the exponent.
Trying to work out an easy way to do mass testing on the beast. I've just been flipping values manually in the test bench.

_________________
http://www.finitron.ca

The core has been tweaked to improve the performance at little cost in hardware.
MUL is now about 200 cycles (down from 350)
DIV is now about 100 cycles (down from 200)
Normalization proceeds at a rate of one bit (and sometimes 16 bits) per clock, rather than two.
So the core is roughly twice as fast now.
This was accomplished by merging together some of the states where possible.

I worked on a routine to display the floating point numbers, it's written in 65816 assembler code. I hope to have a simple expression parser available for testing.

_________________
http://www.finitron.ca

I think the ability to interrupt the MPU would be good. During a complex math operation, the MPU could get other work done without having to constantly poll the FP unit to determine if it is finished.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Very nice work Rob! I personally don't have a use for floating point calculations right now, but it would be nice to see your Verilog optimizations. Is it posted yet on Github?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yes, it's on Github. I also added 80 bit fixed point operations at almost no hardware cost. Mainly a matter of setting a flag to disable things like normalization.
It occurred to me that the 6502 doesn't have multiply and divide so it'd be handy to have those available.

_________________
http://www.finitron.ca

Found a bug in subtraction. It was working backwards with FAC1-FAC2 and needed to be FAC2-FAC1 because of the way the operands are adjusted in preparation for the operation. I have a display onscreen of 1234 converted from fixed to floating point, then divided by 10. This simple test does add / subtract/ multiply and divide by the time it produces display output. The result displayed is: 123.39999999999999999999913 Oh well. I'm pretty sure its a display issue with converting from hex to decimal. A hex dump of the FAC reveals it's an even number ending in zeros.

_________________
http://www.finitron.ca

BUMP

How's this project coming?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Rob's repositories are found at
https://github.com/robfinch/Cores
and you can see he's been working recently on his 64 bit core:
https://docs.google.com/viewer?url=http ... x?raw=true
(Indeed, Rob is posting about that a fair bit over on this thread:
http://anycpu.org/forum/viewtopic.php?f=23&t=179
)

I shelved it for a while to work on other projects.

It really needs a means now to get data into and out of the system easily, For instance a network connection. So far I've been stuck with using block ROM and rebuilding the system to update software.
In order to test the FPU better I would have to develop something like a simple expression evaluator. I'd prefer to write it in 'C' but I've not got a 'C' compiler for the '816. If the 'C' compiler could generate ROMable code that'd be good to have. There's about 400k or so available for ROM code. I also need a routine to convert a string representation of a floating point number into the 96 bit format the FPU uses.

_________________
http://www.finitron.ca