Hi folks-

I've asked this question on various FPGA formums so please excuse my 
persistence.  I'm hoping different eyes might see my question and be able to 
help.

I'm looking for an HDL replacement for sprintf() that will do a float to 
string conversion using the "%.3E" format specification.  Such a conversion 
in C source code is laborius in code and hence time consuming.  I need to 
convert in about 20 usec on a NIOS on FPGA clocking at 100 MHz.

I'm guessing the best way to do it is to use some C code coupled with 
various HDL modules to reduce the C processing load.  Such a solution is 
acceptable to me as long as I can meet my conversion time target.  The best 
solution would be all in HDL if possible.  I prefer verilog but will take 
anything that works.  An IP purchase is better than trying to figure out 
somthing that isn't finished or is academic but at this point anything I can 
find is better than nothing.

Can anyone recommend a good HDL sub for sprintf("%.3E")?

Thanks for your help on this,

John Speth



--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

On Jul 9, 1:27=A0pm, "John Speth"
<johnsp...@yahoo.com> wrote:
> Hi folks-
>
> I've asked this question on various FPGA formums so please excuse my
> persistence. =A0I'm hoping different eyes might see my question and be ab=
le to
> help.
>
> I'm looking for an HDL replacement for sprintf() that will do a float to
> string conversion using the "%.3E" format specification. =A0Such a conver=
sion
> in C source code is laborius in code and hence time consuming. =A0I need =
to
> convert in about 20 usec on a NIOS on FPGA clocking at 100 MHz.
>
> I'm guessing the best way to do it is to use some C code coupled with
> various HDL modules to reduce the C processing load. =A0Such a solution i=
s
> acceptable to me as long as I can meet my conversion time target. =A0The =
best
> solution would be all in HDL if possible. =A0I prefer verilog but will ta=
ke
> anything that works. =A0An IP purchase is better than trying to figure ou=
t
> somthing that isn't finished or is academic but at this point anything I =
can
> find is better than nothing.
>
> Can anyone recommend a good HDL sub for sprintf("%.3E")?
>
> Thanks for your help on this,
>
> John Speth
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

Have a look at the following SNUG paper:

http://bear.cwru.edu/VHDL/doc/snug2002_20040606_slides.pdf

and the following page:

http://bear.ces.case.edu/VHDL/index.html

I have used this in the past.  It is a bit cumbersome for some
functions, but it works.

Cheers,
-- Amal

John Speth <j...@yahoo.com> wrote:
 
(snip) 
> I'm looking for an HDL replacement for sprintf() that will do a float to 
> string conversion using the "%.3E" format specification.  Such a conversion

> in C source code is laborius in code and hence time consuming.  I need to 
> convert in about 20 usec on a NIOS on FPGA clocking at 100 MHz.

20us*100MHz=2000 clock cycles.  Not so bad.
 
> I'm guessing the best way to do it is to use some C code coupled with 
> various HDL modules to reduce the C processing load.  Such a solution is 
> acceptable to me as long as I can meet my conversion time target.  The best 
> solution would be all in HDL if possible.  I prefer verilog but will take 
> anything that works.  An IP purchase is better than trying to figure out 
> somthing that isn't finished or is academic but at this point anything I can 
> find is better than nothing.

How big or small can the values be?

Last I looked at such routines, they had a table of powers of 10
from 0 to 9 and from 10 to the largest floating point value
by tens.  In a loop, compare the input value, then divide (or multiply
by the reciprocal) as appropriate, first the tens then the ones.
After that, you have the appropriate exponent, and only need to
convert the resulting value to decimal, still not so easy.

Now, how much memory do you have available?  Using the binary exponent
and a small table should get you within a factor of 10, that is,
within 1 of the correct decimal exponent.  Then one compare using
a table of powers of 10 and one multiply should get you the binary
value to convert to decimal and apply the exponent.

IEEE single has an eight bit binary exponent, double has 11 bits,
so you would need a 256 by 24 or 2048 by 53 table, respectively.
Well, maybe two tables, also one for the multplier.

Now long does the multply take?  Oh, you don't need so many decimal
digits, though if you don't do the full precision some values
might round the wrong way.  Well, you can do the compare to
full precision (to get the right exponent), but the multiply
(to get the significand) at reduced precision.  I think that works.

-- glen