From: GrIsH on
On Oct 24, 2:37 am, Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
> On Oct 24, 3:44 am, GrIsH <grishkun...(a)gmail.com> wrote:
>
>
>
> > On Oct 23, 5:19 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>
> > > Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
>
> > > (snip)
>
> > > >MicroBlazeuse big-endian byte-ordering and big-endian bit ordering.
> > > > This is a legacy from PowerPC and CoreConnect bus.
> > > > It's not only PowerPC who uses big-endian ordering.
> > > > As much as the msb bitnumberchanges for big-endian so does the lsb
> > > > bitnumberfor little-endian.
>
> > > (snip)
>
> > > > I do however prefer big-endian byte order since when dumping bytes
> > > > from memory will show the word in the right order.
> > > > We tend to write numbers with the most significant numbers to the left
> > > > and that is how big-endian is storing bytes within a word.
>
> > > The VAX/VMS DUMP program prints the HEX data right to left, and
> > > the ASCII data left to right with the address in the middle.
> > > Big endian avoids strange solutions like that.
>
> > > -- glen
>
> > lot of thanks to all of you that you people have great discussion on
> > this topic..........i'm new to ubalze and this is my first project in
> > ublaze and i got the chance to know lots of things from these
> > discussions........I'm so sorry that i could not be a part of this
> > discussion for one week because i have a festival here which is one of
> > our great festival and now i'm in course.............
>
> >  i gave continuity to my work from yesterday,i simulated my design
> > with BFM(Bus Function Module) simulation and found the result bit
> > confusing .....
>
> > I already told that i'm new one..You people have great discussion its
> > fine!! But still my problem is with me, i think its very easy for you
> > people....
>
> > How is this happen??
> > I have signal "cnt" of integer type and was mapped to IP2Bus_Data as
> > IP2Bus_Data(0 to 31) <= std_logic_vector(to_signed(cnt,32));
>
> > after simulation , i found the data in the PLB bus was in 2's
> > complement form but i think it should be in signed form so how??
>
> > i mean.....
> > if i send +4(that is value of "cnt"), data in the PLB bus was
> > "00000000000000000000000000000100"(32 bit)
> > if -4 was send then it was "11111111111111111111111111111100" BUT i
> > think in signed form it should be
> > "10000000000000000000000000000100"......
>
> > -Grish- Hide quoted text -
>
> > - Show quoted text -
>
> Hi,
>
> The function to_signed converts it's to 2-complement format which is
> the default way of handlingnegativenumbers.
> The "sign,magnitude" format is not used that much since all arithmetic
> operations has to be handled specially while 2-complement is just
> normal operations.
>
> If you really want the "sign,magnitude" format, you have to manually
> set the sign bit and to a "abs" on the cnt value.
>
> Göran

hey guys!!.....i found that sending/receiving a negative number is
not a problem. The real problem is the value of 'cnt' get
changed abruptly to next value(like 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11 then abruptly it becomes 4101/-3510,random number) after some
regular positive /negative count of encoder pulses........

Is this problem is due to my asynchronous design which is irrespective
of IP2Bus_clk??

my design:
-----------------

my_uut:process(channel_A) is

begin

if(channel_A 'event and channel_A='1') then
direction<= '1' and channel_B;
if(direction='0') then

cnt<=cnt+1;

else
cnt<=cnt-1;

end if;
end if;

if(cnt<0) then
sign_bit<='1';
else
sign_bit<='0';
end if;

end process;

channel_A and channel_B are quadrature encoder pulses(with 90 degree
phase difference) as:

--------- --------- ----------
| | | | | |
channel_A:------- -------- ---------
----------
--------- ---------
----------
| | | |
| |
channel_B:----------- --------- ---------
-------------

-grish
From: GrIsH on
On Oct 25, 10:38 am, GrIsH <grishkun...(a)gmail.com> wrote:
> On Oct 24, 2:37 am, Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
>
>
>
> > On Oct 24, 3:44 am, GrIsH <grishkun...(a)gmail.com> wrote:
>
> > > On Oct 23, 5:19 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>
> > > > Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
>
> > > > (snip)
>
> > > > >MicroBlazeuse big-endian byte-ordering and big-endian bit ordering..
> > > > > This is a legacy from PowerPC and CoreConnect bus.
> > > > > It's not only PowerPC who uses big-endian ordering.
> > > > > As much as the msb bitnumberchanges for big-endian so does the lsb
> > > > > bitnumberfor little-endian.
>
> > > > (snip)
>
> > > > > I do however prefer big-endian byte order since when dumping bytes
> > > > > from memory will show the word in the right order.
> > > > > We tend to write numbers with the most significant numbers to the left
> > > > > and that is how big-endian is storing bytes within a word.
>
> > > > The VAX/VMS DUMP program prints the HEX data right to left, and
> > > > the ASCII data left to right with the address in the middle.
> > > > Big endian avoids strange solutions like that.
>
> > > > -- glen
>
> > > lot of thanks to all of you that you people have great discussion on
> > > this topic..........i'm new to ubalze and this is my first project in
> > > ublaze and i got the chance to know lots of things from these
> > > discussions........I'm so sorry that i could not be a part of this
> > > discussion for one week because i have a festival here which is one of
> > > our great festival and now i'm in course.............
>
> > >  i gave continuity to my work from yesterday,i simulated my design
> > > with BFM(Bus Function Module) simulation and found the result bit
> > > confusing .....
>
> > > I already told that i'm new one..You people have great discussion its
> > > fine!! But still my problem is with me, i think its very easy for you
> > > people....
>
> > > How is this happen??
> > > I have signal "cnt" of integer type and was mapped to IP2Bus_Data as
> > > IP2Bus_Data(0 to 31) <= std_logic_vector(to_signed(cnt,32));
>
> > > after simulation , i found the data in the PLB bus was in 2's
> > > complement form but i think it should be in signed form so how??
>
> > > i mean.....
> > > if i send +4(that is value of "cnt"), data in the PLB bus was
> > > "00000000000000000000000000000100"(32 bit)
> > > if -4 was send then it was "11111111111111111111111111111100" BUT i
> > > think in signed form it should be
> > > "10000000000000000000000000000100"......
>
> > > -Grish- Hide quoted text -
>
> > > - Show quoted text -
>
> > Hi,
>
> > The function to_signed converts it's to 2-complement format which is
> > the default way of handlingnegativenumbers.
> > The "sign,magnitude" format is not used that much since all arithmetic
> > operations has to be handled specially while 2-complement is just
> > normal operations.
>
> > If you really want the "sign,magnitude" format, you have to manually
> > set the sign bit and to a "abs" on the cnt value.
>
> > Göran
>
> hey guys!!.....i found that sending/receivinganegativenumberis
> not  a problem. The real problem is the value of 'cnt' get
> changed abruptly to next value(like 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
> 11 then abruptly it becomes 4101/-3510,randomnumber) after some
> regular positive /negativecount of encoder pulses........
>
> Is this problem is due to my asynchronous design which is irrespective
> of IP2Bus_clk??
>
> my design:
> -----------------
>
>  my_uut:process(channel_A) is
>
>     begin
>
>         if(channel_A 'event and channel_A='1') then
>                       direction<= '1' and channel_B;
>             if(direction='0') then
>
>                 cnt<=cnt+1;
>
>             else
>                 cnt<=cnt-1;
>
>             end if;
>         end if;
>
>         if(cnt<0) then
>                 sign_bit<='1';
>         else
>                 sign_bit<='0';
>         end if;
>
>     end process;
>
> channel_A and channel_B are quadrature encoder pulses(with 90 degree
> phase difference) as:
>
>                        ---------        ---------         ----------
>                        |        |       |         |        |         |
> channel_A:-------         --------         ---------
> ----------
>                            ---------         ---------
> ----------
>                            |        |        |         |
> |         |
> channel_B:-----------         ---------         ---------
> -------------
>
> -grish


channel_A and channel_B are:
-------- ---------
| | | |
------- -------- -----------
--------- ---------
| | | |
----------- --------- ------------------
From: GrIsH on
On Oct 25, 11:18 am, GrIsH <grishkun...(a)gmail.com> wrote:
> On Oct 25, 10:38 am, GrIsH <grishkun...(a)gmail.com> wrote:
>
>
>
> > On Oct 24, 2:37 am, Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
>
> > > On Oct 24, 3:44 am, GrIsH <grishkun...(a)gmail.com> wrote:
>
> > > > On Oct 23, 5:19 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>
> > > > > Goran_Bilski <goran.bil...(a)xilinx.com> wrote:
>
> > > > > (snip)
>
> > > > > >MicroBlazeuse big-endian byte-ordering and big-endian bit ordering.
> > > > > > This is a legacy from PowerPC and CoreConnect bus.
> > > > > > It's not only PowerPC who uses big-endian ordering.
> > > > > > As much as the msb bitnumberchanges for big-endian so does the lsb
> > > > > > bitnumberfor little-endian.
>
> > > > > (snip)
>
> > > > > > I do however prefer big-endian byte order since when dumping bytes
> > > > > > from memory will show the word in the right order.
> > > > > > We tend to write numbers with the most significant numbers to the left
> > > > > > and that is how big-endian is storing bytes within a word.
>
> > > > > The VAX/VMS DUMP program prints the HEX data right to left, and
> > > > > the ASCII data left to right with the address in the middle.
> > > > > Big endian avoids strange solutions like that.
>
> > > > > -- glen
>
> > > > lot of thanks to all of you that you people have great discussion on
> > > > this topic..........i'm new to ubalze and this is my first project in
> > > > ublaze and i got the chance to know lots of things from these
> > > > discussions........I'm so sorry that i could not be a part of this
> > > > discussion for one week because i have a festival here which is one of
> > > > our great festival and now i'm in course.............
>
> > > >  i gave continuity to my work from yesterday,i simulated my design
> > > > with BFM(Bus Function Module) simulation and found the result bit
> > > > confusing .....
>
> > > > I already told that i'm new one..You people have great discussion its
> > > > fine!! But still my problem is with me, i think its very easy for you
> > > > people....
>
> > > > How is this happen??
> > > > I have signal "cnt" of integer type and was mapped to IP2Bus_Data as
> > > > IP2Bus_Data(0 to 31) <= std_logic_vector(to_signed(cnt,32));
>
> > > > after simulation , i found the data in the PLB bus was in 2's
> > > > complement form but i think it should be in signed form so how??
>
> > > > i mean.....
> > > > if i send +4(that is value of "cnt"), data in the PLB bus was
> > > > "00000000000000000000000000000100"(32 bit)
> > > > if -4 was send then it was "11111111111111111111111111111100" BUT i
> > > > think in signed form it should be
> > > > "10000000000000000000000000000100"......
>
> > > > -Grish- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Hi,
>
> > > The function to_signed converts it's to 2-complement format which is
> > > the default way of handlingnegativenumbers.
> > > The "sign,magnitude" format is not used that much since all arithmetic
> > > operations has to be handled specially while 2-complement is just
> > > normal operations.
>
> > > If you really want the "sign,magnitude" format, you have to manually
> > > set the sign bit and to a "abs" on the cnt value.
>
> > > Göran
>
> > hey guys!!.....i found that sending/receivinganegativenumberis
> > not  a problem. The real problem is the value of 'cnt' get
> > changed abruptly to next value(like 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
> > 11 then abruptly it becomes 4101/-3510,randomnumber) after some
> > regular positive /negativecount of encoder pulses........
>
> > Is this problem is due to my asynchronous design which is irrespective
> > of IP2Bus_clk??
>
> > my design:
> > -----------------
>
> >  my_uut:process(channel_A) is
>
> >     begin
>
> >         if(channel_A 'event and channel_A='1') then
> >                       direction<= '1' and channel_B;
> >             if(direction='0') then
>
> >                 cnt<=cnt+1;
>
> >             else
> >                 cnt<=cnt-1;
>
> >             end if;
> >         end if;
>
> >         if(cnt<0) then
> >                 sign_bit<='1';
> >         else
> >                 sign_bit<='0';
> >         end if;
>
> >     end process;
>
> > channel_A and channel_B are quadrature encoder pulses(with 90 degree
> > phase difference) as:
>
> >                        ---------        ---------         ----------
> >                        |        |       |         |        |         |
> > channel_A:-------         --------         ---------
> > ----------
> >                            ---------         ---------
> > ----------
> >                            |        |        |         |
> > |         |
> > channel_B:-----------         ---------         ---------
> > -------------
>
> > -grish
>
> channel_A and channel_B are:
>         --------            ---------
>        |         |         |          |
> -------           --------            -----------
>             ---------             ---------
>            |          |          |          |
> -----------            ---------            ----

ye.....my problem is get solved!!

thanx all of you guys!!
From: Andy Peters on
On Oct 17, 3:41 pm, rickman <gnu...(a)gmail.com> wrote:
> On Oct 17, 3:11 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>
>
>
> > rickman <gnu...(a)gmail.com> wrote:
>
> > (snip, then I wrote)
>
> > >> Which seems simpler and more natural: ?
> > >> ? ? ? ? ? [8*n,8*n+7] ? ?or ? ?[31-8*n,24-8*n]
> > >> I do know that it took me longer to write the second one and
> > >> to verify that it did what I wanted it to do. ?
> > >> Or are you asking about the preference of big-endian for
> > >> processor design?
>
> > > I don't know what the above equations are for.  I have never used
> > > either forms for anything that I can recall.
>
> > That is the verilog from.  Most of the time I can read VHDL and
> > get the right idea, but I have never written it.  (I did some
> > VHDL to verilog conversions that worked, never the other way.)
>
> The verilog form for what?  I have never used a calculation like
> that.  What is n?  Why are you performing this calculation?  What is
> the context.

All Glen is trying to do is index individual bits in the word. n is
the index.

If you've created a "custom IP core" for a Xilinx EDK project, then
undoubtedly you've run into the following construct:

for byte_index in 0 to (C_SLV_DWIDTH/8) - 1 loop
if (Bus2IP_BE(byte_index) = '1') then
my_register(byte_index*8 to byte_index*8+7) <=
Bus2IP_Data(byte_index*8 to byte_index*8+7);
end if;
end loop;

Here, C_SLV_DWIDTH is defined as the width of the data bus (for
MicroBlaze this is 32 bits). byte_index iterates over the number of
byte-lane enables (Bus2IP_BE) so for a 32-bit data bus you have four
BEs. If the byte-lane is enabled then you assign all of the bits in
that byte. If you had a PPC system your data bus could be 64 or 128
bits wide so you'd have eight BEs or sixteen BEs.

The point here is that the same code handles all of these cases. This
is VERY useful.

> Like I said above, I have no idea why you are using a complicated
> calculation to specify the bit of a word.  It is extremely seldom that
> I need to select a bit range based on a byte address the way you have
> shown.  In fact, I can't remember ever doing that.

The example above shows why we use this "extremely complicated
calculation." And really -- it's not complicated at all.

The code you show later in this thread has the explicit bit
assignments, which is excellent for readability but is not at all
scalable.

> Ignoring that, I don't see this one calculation as being a driving
> reason to choose a numbering scheme for a bus.  It seems to me to be
> infinitely more useful to have the index correspond to the weight of
> each bit to facilitate the calculation of the values in this signal.

The numbering scheme goes back to the decisions made by IBM at the
time they were defining the architecture used by the PPC and the
MicroBlaze. Since it's an IBM bus, Xilinx uses the IBM nomenclature.

Note that BE(0) in my example above _always_ refers to the MOST
significant byte lane -- ALWAYS bits (0 to 7) which are the most
significant. If you think about it, this actually makes more sense
than the little-endian notion where the MS bits are numbered based on
the number of bits in the word. In a 32-bit world, the MS byte lane is
3 and the bits are (31 downto 24). In a 64-bit world, the MS byte lane
is 7 and the bits are (63 downto 56).

Really, this is not difficult at all.

-a
From: rickman on
On Oct 26, 1:26 pm, Andy Peters <goo...(a)latke.net> wrote:
>
> The numbering scheme goes back to the decisions made by IBM at the
> time they were defining the architecture used by the PPC and the
> MicroBlaze. Since it's an IBM bus, Xilinx uses the IBM nomenclature.

Any idea what those decisions were made on? The only advantage I have
seen for little endian is the niceness of byte dumps. But then I
guess I don't want to open that can of worms. Even with little endian
byte addressing, I don't agree that little ending bit numbering goes
with it to any significant advantage.


> Note that BE(0) in my example above _always_ refers to the MOST
> significant byte lane -- ALWAYS bits (0 to 7) which are the most
> significant. If you think about it, this actually makes more sense
> than the little-endian notion where the MS bits are numbered based on
> the number of bits in the word. In a 32-bit world, the MS byte lane is
> 3 and the bits are (31 downto 24). In a 64-bit world, the MS byte lane
> is 7 and the bits are (63 downto 56).
>
> Really, this is not difficult at all.

No, it's not especially difficult, but I have never needed that
particular calculation. I find it much, much simpler to use the
convention that is much more dominant where a bit index is calculated
without any reference to the byte. Only a small portion of HDL code
is used in microprocessor interfaces. In fact, the OP's example
requires him to convert between the two. So what is the point of a
small savings with that one calculation when there are so many other
issues that are created in the interface? The OP's case is a perfect
example, I couldn't tell from his code where he intended the 16 bit
quantity to show up on the bus and I couldn't tell if he intended to
sign extend the quantity or if it even mattered.

Sure, you may be some small improvement in HDL code that is entirely
internal to the processor, but that is just a small microcosm. That
decision has impacts outside of that area.

Rick