problem while receiving negative integer in microblaze
in [FPGA]
|
Prev: Development boards for CPU development ?
Next: floating point operation in interrupt handler on ML403
From: GrIsH on 25 Oct 2009 13:38 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 25 Oct 2009 14:18 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 25 Oct 2009 15:03 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 26 Oct 2009 13:26 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 26 Oct 2009 16:45
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 |