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: rickman on 16 Oct 2009 18:59 On Oct 15, 1:10 pm, Andy Peters <goo...(a)latke.net> wrote: > On Oct 15, 8:14 am, rickman <gnu...(a)gmail.com> wrote: > > > > > On Oct 15, 12:51 am, GrIsH <grishkun...(a)gmail.com> wrote: > > > > On Oct 14, 11:35 am, rickman <gnu...(a)gmail.com> wrote: > > > > > I have never worked with SLV in the 0 to N direction. To be honest, I > > > > don't remember the details of how assignments are made between buses > > > > using different directions of indexes. I wouldn't expect any > > > > surprises, but then I have no experience with them. Is there a reason > > > > that you are using 0 to N numbering instead of N downto 0 on your SLV > > > > arrays? This may not be a problem, but if you are stuck, why use this > > > > uncommon convention? > > > > for IP2Bus_Data we are not allowed to make this convention of N > > > downto 0 that's why i didn't use this convention. > > > Ok, it shouldn't matter really, as long as you use it correctly. Can > > you explain what this bus is and why it is 0 to 31? Is this a port on > > the uBlaze? Where exactly does this restriction come from. Why do > > you assign your counter result to bits 16 to 31? > > MicroBlaze is big endian. Bits 16 to 31 are the two least significant > bytes in a 32-bit word (bit 31 is the right-most bit). > > -a I wonder why they do that. I have only seen bit zero as the most significant bit in a handful of designs and I expect the first was done for fairly obscure reasons and the rest were done to be compatible. Did the uBlaze need to be compatible with something in this regard? Rick
From: glen herrmannsfeldt on 16 Oct 2009 19:29 rickman <gnuarm(a)gmail.com> wrote: (snip) > I wonder why they do that. I have only seen bit zero as the most > significant bit in a handful of designs and I expect the first was > done for fairly obscure reasons and the rest were done to be > compatible. Did the uBlaze need to be compatible with something in > this regard? I don't know about the design, but all the documentation for IBM S/360, S/370, ESA/390, and z/Architecture numbers the bits with 0 as the MSB. That complicates the description change from 32 bit (through ESA/390) to 64 bit (z/Architecture), but otherwise it is more consistent with big-endian byte order. For an architecture without bit addressing it isn't so obvious that the documentation needs to be consistent with the byte ordering, but sometimes consistency is nice. As far as uBlaze and big endian, it would seem that [8*n,8*n+7] where n is a byte number would be somewhat more convenient than the other way around. -- glen
From: rickman on 17 Oct 2009 02:12 On Oct 16, 7:29 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > rickman <gnu...(a)gmail.com> wrote: > > (snip) > > > I wonder why they do that. I have only seen bit zero as the most > > significant bit in a handful of designs and I expect the first was > > done for fairly obscure reasons and the rest were done to be > > compatible. Did the uBlaze need to be compatible with something in > > this regard? > > I don't know about the design, but all the documentation for IBM > S/360, S/370, ESA/390, and z/Architecture numbers the bits with 0 > as the MSB. That complicates the description change from 32 bit > (through ESA/390) to 64 bit (z/Architecture), but otherwise it is > more consistent with big-endian byte order. > > For an architecture without bit addressing it isn't so obvious > that the documentation needs to be consistent with the byte ordering, > but sometimes consistency is nice. > > As far as uBlaze and big endian, it would seem that [8*n,8*n+7] > where n is a byte number would be somewhat more convenient than > the other way around. > > -- glen I don't follow that at all. N downto 0 numbering allows the weight of the bit to be 2**N. That is the overriding factor for me. Switching it around to "be consistent" with byte addressing when you don't have bit addressing seems pretty low on the priority list. Rick
From: glen herrmannsfeldt on 17 Oct 2009 02:28 rickman <gnuarm(a)gmail.com> wrote: (snip of long explanation before I wrote) >> As far as uBlaze and big endian, it would seem that [8*n,8*n+7] >> where n is a byte number would be somewhat more convenient than >> the other way around. > I don't follow that at all. N downto 0 numbering allows the weight of > the bit to be 2**N. That is the overriding factor for me. Switching > it around to "be consistent" with byte addressing when you don't have > bit addressing seems pretty low on the priority list. 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? -- glen
From: rickman on 17 Oct 2009 14:44
On Oct 17, 2:28 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > rickman <gnu...(a)gmail.com> wrote: > > (snip of long explanation before I wrote) > > >> As far as uBlaze and big endian, it would seem that [8*n,8*n+7] > >> where n is a byte number would be somewhat more convenient than > >> the other way around. > > I don't follow that at all. N downto 0 numbering allows the weight of > > the bit to be 2**N. That is the overriding factor for me. Switching > > it around to "be consistent" with byte addressing when you don't have > > bit addressing seems pretty low on the priority list. > > 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. I address bits in words all the time in VHDL. I often use notation like (foo'high-bar'high downto 0) which gives the lsbs of foo where bar is a shorter length than foo. Or conversely (foo'high downto bar'high) for the msbs in foo that are wider than bar. I have never used any notation like you have shown. Rick |