Query: numeric_std: div,rem,mod
| Author |
Message |
|
Kiran Maheri
#1 / 5
|
 Query: numeric_std: div,rem,mod It is about the div, rem and mod functions.
As far as I know, the div, rem and mod functions are not fully supported
by Synopsys (or may other synth tools too), in that, the limitation is
imposed on the the denominator (it should be a power of two). It can be
understood that with this limitation, division is simply a right shift
of the first argument (for div).
My question is, why is this limit imposed? As far I could see, the
numeric_std package is quite general, with a generic divMod procedure
implementing the main task of dividing.
Here is the header of the numeric_std.vhd:
----------------------------------------------------------------------------
-- Title : NUMERIC_STD arithmetic package for synthesis
-- : Rev. 1.7 (Nov. 23 1994)
-- :
-- Library : This package shall be compiled into a library
symbolically
-- : named IEEE.
-- :
-- Developers : IEEE DASC Synthesis Working Group, PAR 1076.3
-- :
-- Purpose : This package defines numeric types and arithmetic
functions
-- : for use with synthesis tools. Two numeric ....
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Of course, there are some more things related to this, but first I would
love to know the real reason for the limitation from the guru's!
kiran.
|
| Sun, 18 Nov 2001 03:00:00 GMT |
|
 |
|
Renaud Pacale
#2 / 5
|
Query: numeric_std: div,rem,mod Quote:
> It is about the div, rem and mod functions.
> As far as I know, the div, rem and mod functions are not fully supported
> by Synopsys (or may other synth tools too), in that, the limitation is
> imposed on the the denominator (it should be a power of two). It can be
> understood that with this limitation, division is simply a right shift
> of the first argument (for div).
> My question is, why is this limit imposed? As far I could see, the
> numeric_std package is quite general, with a generic divMod procedure
> implementing the main task of dividing.
> Here is the header of the numeric_std.vhd:
> ----------------------------------------------------------------------------
> -- Title : NUMERIC_STD arithmetic package for synthesis
> -- : Rev. 1.7 (Nov. 23 1994)
> -- :
> -- Library : This package shall be compiled into a library
> symbolically
> -- : named IEEE.
> -- :
> -- Developers : IEEE DASC Synthesis Working Group, PAR 1076.3
> -- :
> -- Purpose : This package defines numeric types and arithmetic
> functions
> -- : for use with synthesis tools. Two numeric ....
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Of course, there are some more things related to this, but first I would
> love to know the real reason for the limitation from the guru's!
> kiran.
Well, I'm not a guru but I have a possible explanation: dividers are large and complex operators with a lot of possible architectures (number of pipe-line stages, throughput, etc). In order to make it synthesizable you would have to put a lot of synthesis cues and the synthesizer would need a large library of algorithms. Yes, it's about the same with multipliers but multipliers are 100 times more useful than dividers in digital designs. Logic synthesis must stop somewhere. You can't ask for a floating point unit, a square root or cosine function. The limit is just between multipliers and dividers. Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
|
| Mon, 19 Nov 2001 03:00:00 GMT |
|
|
|
Kiran Maheri
#3 / 5
|
Query: numeric_std: div,rem,mod Quote:
> Well, I'm not a guru but I have a possible explanation: dividers are > large and complex operators with a lot of possible architectures > (number of pipe-line stages, throughput, etc). In order to make it > synthesizable you would have to put a lot of synthesis cues and the > synthesizer would need a large library of algorithms. > Yes, it's about the same with multipliers but multipliers are 100 > times more useful than dividers in digital designs. > Logic synthesis must stop somewhere. You can't ask for a floating > point unit, a square root or cosine function. The limit is just > between multipliers and dividers. > Regards,
> --
> Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
It is true that multipliers are more useful. But, if a synthesis tool can provide at least one implementation of
these functions, it can serve the purpose.
The main (current) use may be in synthesizable testbenches. Here, you
are not worried about the gate count, but at the same time want to have
flexibility for at least the basic functions (not the complex functions
you have mentioned). 'mod' is one such function which is use very often.
In any case, it is upto the user, isn't it, to decide whether to use
built in '/' 'mod' or 'rem' or to build their own optimized functions!
Further, it is still not in the domain of the behavi{*filter*}compilers. It
is still RTL.
Regards,
kiran
|
| Mon, 19 Nov 2001 03:00:00 GMT |
|
|
|
me..
#4 / 5
|
Query: numeric_std: div,rem,mod
Quote: > <HTML>
Ugh. Quote: > <P>Just out of curiosity, why would you want to write a
> synthesisable test bench???
One common reason is so that the TB can be accellerated. Paul
--
OrCAD | www.orcad.com | spread fear, uncertainty and doubt
P.O. Box 71767 | 919-479-1670[v] | in the users' minds."
Durham, NC 27722-1767 | 919-479-1671[f] | --Don Jones, MS's Y2K Product Mgr
|
| Tue, 20 Nov 2001 03:00:00 GMT |
|
|
|
Kiran Maheriy
#5 / 5
|
Query: numeric_std: div,rem,mod Quote: > Ugh.
> > <P>Just out of curiosity, why would you want to write a
> > synthesisable test bench???
> One common reason is so that the TB can be accellerated.
> Paul
Exactly. In fact, IKOS Systems (company where I am currently working) provides Hardware accelerators (and also Emulators), which can accelerate
the RTL simulations. If the testbench is also synthesizable, then the whole simulation can be done in H/W--giving best acceleration
(15X- 20X).
Of course, I agree it is far TOO much of hardware for a divider used as mod/rem. But I wanted to know!!
Thanks,
kiran
|
| Thu, 22 Nov 2001 03:00:00 GMT |
|
| |
|
