will Synposys Design Compiler support division by two's power and integer rounding?

[walala]

Dear all,

I am facing with the following problem:

I have a temporary variable "temp", 24 bits wide, 23 downto 0,

I want to divide it by 65536, that's to say, take the bit 23 downto
bit 16(the first 8 bits)... but I would like also to have a rounding
after the division...

Can I just use Y<=round(temp/65536) and let the Synopsys DC to work
out that for me?

I know normally Synthesis tool won't take division, but how about a
division by two's power?

Thanks a lot,

-Walala

 

[Kelvin]

you may use shift operator. or just assign an offseted bit-vector...
using a division operator appear absurd for DC...

 

[Ralf Hildebrandt]

Hi walala!

I have a temporary variable "temp", 24 bits wide, 23 downto 0,

I want to divide it by 65536, that's to say, take the bit 23 downto
bit 16(the first 8 bits)... but I would like also to have a rounding
after the division...

Pseudo-code:

result<=temp(23 downto 16) + temp(15);


Note:
* This piece of code has to be rewritten, depending on what types temp
and result are and which libraries you use.
* This solution results in an half-adder ("counter"). Depending on your
problem, it may be too "heavy". Furthermore it may be to slow, if no
synthesis constraints are given.


Ralf

 

[Grzegorz Jablonski]

you may use shift operator. or just assign an offseted bit-vector...
using a division operator appear absurd for DC...

And if you want rounding, and 32768 to temp before shifting. Or add one to
the result if temp(31) was one.

GWJ

 

[walala]

Hi Grzegorz,

Thank you for your answer.

Worse is that forgot to mention that I am looking for
y=round(x/65536) for a signed interger...

I am not sure that if there is mathematical universal definition for
rounding for negative values.

For example, the rounding that I like is:

round(1.1)=1, round(1.5)=2,
round(-1.1)=-1, round(-1.5)=-2.

Do you think these rounding are reasonable? Some other rounding will
have round(-1.5)=-1...

Hence I guess you mentioned "add one to the result if the sign bit of
temp(temp(23)) is 1" is the same as my rounding?

I think I can put in this way

y=x(23 downto 16)+x(15)+x(23)

Then it generates two half adder, do you have any better
implementation?

Thanks a lot,

-Walala

 

[walala]

Hi, Ralf,

Thank you for your answer!

result<=temp(23 downto 16) + temp(15);


Note:
* This piece of code has to be rewritten, depending on what types temp
and result are and which libraries you use.
* This solution results in an half-adder ("counter"). Depending on your
problem, it may be too "heavy". Furthermore it may be to slow, if no
synthesis constraints are given.

By putting what you advised and the other people advised, I clarify my
thought to be the following:

I am looking for y=round(x/65536) for a signed interger...

I am not sure that if there is mathematical universal definition for
rounding for negative values.

For example, the rounding that I like is:

round(1.1)=1, round(1.5)=2,
round(-1.1)=-1, round(-1.5)=-2.

Hence I guess "add one to the result if the sign bit of temp(temp(23))
is 1" is the same as my above expected rounding?

I think I can put in this way

y=x(23 downto 16)+x(15)+x(23)

Am I correct? Then it generates two half adder, do you have any better
implementation?

I guess since I need signed operators, I used the following library:

USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_signed.ALL;

The signal "temp" declaration is STD_LOGIC_VECTOR(24 downto 0);

Please feel free to give comments: I am really newbie in this VHDL
stuff...

Thanks a lot,

-Walala

 

[Grzegorz Jablonski]

Hence I guess you mentioned "add one to the result if the sign bit of
temp(temp(23)) is 1" is the same as my rounding?

I really meant temp(15).

I think I can put in this way

y=x(23 downto 16)+x(15)+x(23)

if you want it this way
round(1.1)=1, round(1.5)=2,
round(-1.1)=-1, round(-1.5)=-1, round(-1.6)=-2

you need to write:

y=x(23 downto 16) + x(15)


if you want it this way:
round(1.1)=1, round(1.5)=2,
round(-1.1)=-1, round(-1.5)=-2.

you have to consider special case:

y=x(23 downto 16) ;
if not (x(14) = '0' and x(13) = '0' and ... and x(0) = '0')) y=y + x(15);

Regards,
GWJ

 

[walala]

I am even more confused... after a second thought,

I think the rounding implementation should be:

y=x(23 downto 16)+x(15)-x(23):

Example 1: round(-1.5)=-2:

After scaled by 65536,
-1.5's two's complement representation in 24 bits is :
11111110_10000000_00000000

x(15)=1, x(23)=1,

hence y=11111110, which is -2, correct!

Example 2: round(-1.1)=-1:

After scaled by 65536,
-1.1's two's complement representation in 24 bits is:
11111110_11100110_01100110

x(15)=1, x(23)=1,

hence y=11111110, which is -2, but it is WRONG!

Example 3: round(1.1)=1:

After scaled by 65536,
1.1's two's complement representation in 24 bits is:
00000001_00011001_10011001

x(15)=0, x(23)=0,

hence y=1, correct!

Example 4: round(1.5)=2:

After scaled by 65536,
1.5's two's complement representation in 24 bits is:
00000001_10000000_00000000

x(15)=1, x(23)=0,

hence y=1+1=2, correct!

----------------------------------------------

It seems to me that rounding for negative values is not a simple problem...
It may need sophiscated hardware to do it. Am I right?

The simplest one is y=x(23 downto 16)+x(15),

but this does not give round(-1.5)=-2...

And it still needs a half-adder to do it... any simpler techniques can be
applied here?

Thanks a lot,

-Walala

 

[walala]

I am even more confused... after a second thought,

I think the rounding implementation should be:

y=x(23 downto 16)+x(15)-x(23):

Example 1: round(-1.5)=-2:

After scaled by 65536,
-1.5's two's complement representation in 24 bits is :
11111110_10000000_00000000

x(15)=1, x(23)=1,

hence y=11111110, which is -2, correct!

Example 2: round(-1.1)=-1:

After scaled by 65536,
-1.1's two's complement representation in 24 bits is:
11111110_11100110_01100110

x(15)=1, x(23)=1,

hence y=11111110, which is -2, but it is WRONG!

Example 3: round(1.1)=1:

After scaled by 65536,
1.1's two's complement representation in 24 bits is:
00000001_00011001_10011001

x(15)=0, x(23)=0,

hence y=1, correct!

Example 4: round(1.5)=2:

After scaled by 65536,
1.5's two's complement representation in 24 bits is:
00000001_10000000_00000000

x(15)=1, x(23)=0,

hence y=1+1=2, correct!

----------------------------------------------

It seems to me that rounding for negative values is not a simple problem...
It may need sophiscated hardware to do it. Am I right?

The simplest one is y=x(23 downto 16)+x(15),

but this does not give round(-1.5)=-2...

And it still needs a half-adder to do it... any simpler techniques can be
applied here?

Thanks a lot,

-Walala

 

[Grzegorz Jablonski]

news:[email protected]...

if you want it this way:
round(1.1)=1, round(1.5)=2,
round(-1.1)=-1, round(-1.5)=-2.

you have to consider special case:

y=x(23 downto 16) ;
if not (x(14) = '0' and x(13) = '0' and ... and x(0) = '0')) y=y + x(15);

Correction:

y=x(23 downto 16) ;
if (x(23) ='0' or not (x(14) = '0' and x(13) = '0' and ... and x(0) =
'0'))) y=y + x(15);

Regards,
GWJ

 

[walala]

I am sorry, after a third thought,

I found out it should be

y=x(23 downto 16) + x(15) + x(24)...

hence the output is still 8 bits, but the internal temparory variable should
be 25 bits(24 downto 0), hence it should be one bit more than neccessry.

The reason is that there will always be some overflow for some large extreme
cases:

For example, x(24 downto 15)= B"1_01111110_1" (the first bit is bit 24, the
last bit is bit 15)

If we use just y=x(23 downto 16)+x(15), it will be 01111111 which is +127,
but actually we want -128, hence it is wrong...

If we use y=x(23 downto 16)+x(15)+x(24), it will be 1000000, which is -128,
correct!

OOOOPS... I am greatly confused... can andbody enlighten me a little on this
problem? Hardware design is really tricky!!!

 

[walala]

I am sorry, after a third thought,

I found out it should be

y=x(23 downto 16) + x(15) + x(24)...

hence the output is still 8 bits, but the internal temparory variable should
be 25 bits(24 downto 0), hence it should be one bit more than neccessry.

The reason is that there will always be some overflow for some large extreme
cases:

For example, x(24 downto 15)= B"1_01111110_1" (the first bit is bit 24, the
last bit is bit 15)

If we use just y=x(23 downto 16)+x(15), it will be 01111111 which is +127,
but actually we want -128, hence it is wrong...

If we use y=x(23 downto 16)+x(15)+x(24), it will be 1000000, which is -128,
correct!

OOOOPS... I am greatly confused... can andbody enlighten me a little on this
problem? Hardware design is really tricky!!!

 

[Jon]

Hi Walala,
Just consider how you want to round and write the code to do it
for positvie numbers and then a routine to do it for negative numbers.
Once you have that you probably will see that you can combine alot of
the code of the two routines. The most common type of round that I
have seen is rounding based on the 1/2 principle. Basically for
postive numbers look at the bits to round off and if the msb is 1 and
any other bits are not equal to 0 then round up else round down.

Jon