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: Goran_Bilski on 23 Oct 2009 02:42 On Oct 22, 8:14 pm, rickman <gnu...(a)gmail.com> wrote: > On Oct 21, 7:16 am, David Brown <da...(a)westcontrol.removethisbit.com> > wrote: > > > > > > > glen herrmannsfeldt wrote: > > > rickman <gnu...(a)gmail.com> wrote: > > >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > > (snip) > > > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > > >>> ESA/370, ESA/390, and z/Architecture. > > > > (snip) > > >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressing > > >>> as appropriate, and instructions change as the addressing mode changes. > > > >> How are the bits in the address bus numbered? I would find it > > >> extremely confusing to deal with an address where the lsb is numbered > > >> N where N varies depending on the size of the address range. > > > > If by 'address bus' you mean the physical hardware, that is a separate > > > question from the architecture. > > > > Otherwise, the numbering changed in z/, but is internally consistent. > > > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > > > for example, and the address as stored in the PSW is bits 40 to 63. > > > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > > > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > > > That only comes up in reading the descriptions of the instructions. > > > This is "nice and consistent" ?? The bit numbering for the same address > > varies according to the size of the register, and the significance of a > > bit of a given number varies according to the register, the bit width, > > and the machine variant. I'll agree that much of this is hidden from > > the programmer, and that you can get used to it, but it's still > > inconsistent and it's still messy. > > > I've dealt with this in the context of PPC microcontrollers - it is a > > big pain in the neck, and it's very easy to get wrong. Virtually > > everything else in the electronics world numbers bits consistently from > > 0 for the LSB - the PPC sticks out like a sore thumb and means that you > > need to invert the bus numbering when connecting it to external memory. > > Internally, when programming these things, you get the joys of > > figuring out which bits are which in the documentation, and how that > > corresponds to reality. The manual might tell you a hardware register > > is theoretically 64 bits, with the field you are interested in from bits > > 56 to 59. However, perhaps only the lower 32 bits of the register are > > implemented, so the actual bits are 24 to 27. You then have to > > translate this into sensible bit numbers, 4 to 7, so that you can use > > them in software. All in all, reverse bit numbering is a big waste of > > time and effort, and a big cause of mistakes. > > > And for PPC devices (at least, those I have looked at) with 64-bit > > architectures, the external databus is numbered consistently with the > > 32-bit devices. Thus the LSB of the data and address buses stays at 31. > > So the upper half of the databus runs from D-1 to D-32 as the MSB. > > Internally, of course, the registers are numbered with bit 0 as the MSB > > and bit 63 as the LSB. Thus bit 0 in a data register corresponds to pin > > D-32 on the PPC, matching net D63 on any external memory bus. > > > Yes, "nice and consistent" is just the phrase... > > > > In actual coding, (software) one can write a loop in whichever > > > way one wants. The hardware will execute it independent of the > > > thought process of the programmer. > > > I was under the impression that programming was about getting the > > hardware to execute /dependent/ on the thoughts of the programmer! > > > > It never confused me. > > > I've not use the Power architecture, only some PowerPC devices, but I > > have to admit it has confused me on occasion, and irritated and > > frustrated me more often than that. > > > mvh., > > > David > > I didn't realize that the microBlaze used a little endian bus > numbering convention. That is a good reason to avoid it... a small > reason, but a reason nonetheless. > > Actually, the main reason to avoid proprietary IP like microBlaze is > the fact that it is proprietary. I prefer to use one of the available > CPUs that are open source and can be ported to chips from any vendor > or even an ASIC. > > Rick- Hide quoted text - > > - Show quoted text - Hi, MicroBlaze use 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 bit number changes for big-endian so does the lsb bit number for little-endian. In my earlier years before MicroBlaze I only used little-endian bit ordering and I had to change to big-endian for MicroBlaze. It took some time but now when I define a vector bus it tends to be big-endian. I don't have much of a preference anymore. it's just two different ways of defining a vector. 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. But I'm not sure if big-endian byte order and little-endian bit order is a good idea. It might be too confusing. Göran
From: David Brown on 23 Oct 2009 04:32 Goran_Bilski wrote: > On Oct 22, 8:14 pm, rickman <gnu...(a)gmail.com> wrote: >> On Oct 21, 7:16 am, David Brown <da...(a)westcontrol.removethisbit.com> <snip to save space> >> I didn't realize that the microBlaze used a little endian bus >> numbering convention. That is a good reason to avoid it... a small >> reason, but a reason nonetheless. >> I don't actually know much about the MicroBlaze - I can only refer to the PPC, which I have used (not in FPGAs). But I'd agree with you here - having big-endian bit numbering would definitely count against the MicroBlaze as far as I am concerned. I think it would be especially painful in FPGA designs, since tools can often automatically connect up buses (at least, that was the case when I did some work with the Nios and Quartus a few years ago). If you've got some components with big-endian bit numbering, and some with small-endian bit numbering, something's going to get mixed up pretty quickly. >> Actually, the main reason to avoid proprietary IP like microBlaze is >> the fact that it is proprietary. I prefer to use one of the available >> CPUs that are open source and can be ported to chips from any vendor >> or even an ASIC. >> That's another discussion entirely - good points, but they need their own branch or thread. >> Rick- Hide quoted text - >> >> - Show quoted text - > > Hi, > > MicroBlaze use 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. > The PPC is perhaps not alone in using big-endian bit numbering, but it is certainly one of only a very few processors. All the 32-bit processor families that I have worked with are big-endian. This includes MIPS, PPC, ColdFire (68k), AVR32 and Nios. Some of these (like MIPS and PPC) can handle little-endian data to some extent, but are naturally big-endian. The only two major little-endian 32-bit architectures I can think of are ARM and x86. I don't know why most "modern" designs are big-endian. There are good reasons why older CISC designs (such as VAX and x86) are little-endian - for one thing, it makes it easier to write multi-byte arithmetic functions, and it makes it easier to convert integer sizes. There seems to be a fair correlation between RISC and big-endian - certainly when you move from an architecture oriented around accessing memory, working with 8 bits at a time to an architecture oriented around keeping data in registers, and working with a full 32-bit register at a time, then the key advantages of little-endian ordering are no longer relevant. However, of those architectures, the only one which uses big-endian bit numbering is the PPC. Preferences and experiences are, of course, personal. Some people have strong opinions about which endianness they prefer (just ask the Lilliputeans), others are happy to mix and match. > As much as the msb bit number changes for big-endian so does the lsb > bit number for little-endian. > > In my earlier years before MicroBlaze I only used little-endian bit > ordering and I had to change to big-endian for MicroBlaze. > It took some time but now when I define a vector bus it tends to be > big-endian. > I don't have much of a preference anymore. it's just two different > ways of defining a vector. > > 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. > > But I'm not sure if big-endian byte order and little-endian bit order > is a good idea. It might be too confusing. > It's the most common arrangement, in my experience. > G�ran
From: glen herrmannsfeldt on 23 Oct 2009 08:19 Goran_Bilski <goran.bilski(a)xilinx.com> wrote: (snip) > MicroBlaze use 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 bit number changes for big-endian so does the lsb > bit number for 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
From: GrIsH on 23 Oct 2009 21:44 On Oct 23, 5:19 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Goran_Bilski <goran.bil...(a)xilinx.com> wrote: > > (snip) > > > MicroBlaze use 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 bit number changes for big-endian so does the lsb > > bit number for 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
From: Goran_Bilski on 24 Oct 2009 05:37
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) > > > > MicroBlaze use 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 bit number changes for big-endian so does the lsb > > > bit number for 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 handling negative numbers. 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 |