Velocity Reviews > VHDL > will Synposys Design Compiler support division by two's power and integer rounding?

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

walala
Guest
Posts: n/a

 09-13-2003
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" <(E-Mail Removed)> wrote in message
news:bjvvai\$5ve\$(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > 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
> >
> > "Grzegorz Jablonski" <gwj@mangled_w-s.pl> wrote in message

> news:<bjuunu\$ep6\$(E-Mail Removed)>...
> > >
> > > And if you want rounding, and 32768 to temp before shifting. Or add

one
> to
> > > the result if temp(31) was one.
> > >
> > > GWJ

>
>

walala
Guest
Posts: n/a

 09-13-2003
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" <(E-Mail Removed)> wrote in message
news:bjvvb0\$5vk\$(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > 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

>
>

Jon
Guest
Posts: n/a

 09-14-2003
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

"walala" <(E-Mail Removed)> wrote in message news:<bk06bd\$90e\$(E-Mail Removed)>...
> 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" <(E-Mail Removed)> wrote in message
> news:bjvvb0\$5vk\$(E-Mail Removed)...
> > 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" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed) om...
> > > 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

> >
> >