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 19 Oct 2009 11:11 On Oct 19, 9:58 am, Gabor <ga...(a)alacron.com> wrote: > On Oct 16, 6:59 pm, rickman <gnu...(a)gmail.com> wrote: > > > > > 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 > > The historical reason is that IBM's Power PC is big endian, so > all of the V2 pro tools were big endian, and microBlaze came > later. Sticking with big endian at that stage in the game > was better than re-writing a bunch of supporting software. > > Regards, > Gabor Are you saying that on the Power PC they number bits in the data bus with 0 as msb and 31 as lsb? How about address bits, is the lsb numbered 31 and the msb numbered 0? I would find that very confusing. I could care less if the byte addressing is big-endian or little- endian. I don't see that having much import when defining the bits in a bus. Rick
From: Martin Thompson on 20 Oct 2009 08:32 rickman <gnuarm(a)gmail.com> writes: > On Oct 19, 9:58�am, Gabor <ga...(a)alacron.com> wrote: > Are you saying that on the Power PC they number bits in the data bus > with 0 as msb and 31 as lsb? How about address bits, is the lsb > numbered 31 and the msb numbered 0? Yes. And IIRC on the Motorola 88110 which preceded it, on which the PowerPC 601 was based (buswise anyway). > I would find that very confusing. > > I could care less if the byte addressing is big-endian or little- > endian. I don't see that having much import when defining the bits in > a bus. > If you look at address 0, it corresponds with bits 0 to 7 of the data bus, address 1 is bits 8 to 15. Just like on a little-endian processor. (Would you want address 0 on bits 31 downto 24? Maybe?) Anyway, once they've taken that convention, making the address bus numbered the same way makes more sense than making it opposite to the databus! (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of the 48 bit address bus :) Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Gabor on 20 Oct 2009 09:30 On Oct 20, 8:32 am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > rickman <gnu...(a)gmail.com> writes: > > On Oct 19, 9:58 am, Gabor <ga...(a)alacron.com> wrote: > > Are you saying that on the Power PC they number bits in the data bus > > with 0 as msb and 31 as lsb? How about address bits, is the lsb > > numbered 31 and the msb numbered 0? > > Yes. And IIRC on the Motorola 88110 which preceded it, on which the > PowerPC 601 was based (buswise anyway). > > > I would find that very confusing. > > > I could care less if the byte addressing is big-endian or little- > > endian. I don't see that having much import when defining the bits in > > a bus. > > If you look at address 0, it corresponds with bits 0 to 7 of the data > bus, address 1 is bits 8 to 15. Just like on a little-endian processor.. > (Would you want address 0 on bits 31 downto 24? Maybe?) > > Anyway, once they've taken that convention, making the address bus > numbered the same way makes more sense than making it opposite to the > databus! > > (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of > the 48 bit address bus :) > > Cheers, > Martin > > -- > martin.j.thomp...(a)trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html By the way the "hard" big endian numbering was IBM's not Motorola's. The Power-PC originated at IBM and was later a joint venture with Motorola. Motorola's own processors, 68K series, use a mix of big endian byte numbering and little endian bit numbering, so in fact bits 31:24 of a 32-bit word on a 32-bit bus would be byte 0. How did we get on this topic? Regards, Gabor
From: rickman on 20 Oct 2009 14:47 On Oct 20, 8:32 am, Martin Thompson <martin.j.thomp...(a)trw.com> wrote: > rickman <gnu...(a)gmail.com> writes: > > On Oct 19, 9:58 am, Gabor <ga...(a)alacron.com> wrote: > > Are you saying that on the Power PC they number bits in the data bus > > with 0 as msb and 31 as lsb? How about address bits, is the lsb > > numbered 31 and the msb numbered 0? > > Yes. And IIRC on the Motorola 88110 which preceded it, on which the > PowerPC 601 was based (buswise anyway). > > > I would find that very confusing. > > > I could care less if the byte addressing is big-endian or little- > > endian. I don't see that having much import when defining the bits in > > a bus. > > If you look at address 0, it corresponds with bits 0 to 7 of the data > bus, address 1 is bits 8 to 15. Just like on a little-endian processor.. > (Would you want address 0 on bits 31 downto 24? Maybe?) > > Anyway, once they've taken that convention, making the address bus > numbered the same way makes more sense than making it opposite to the > databus! > > (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of > the 48 bit address bus :) Why would I care what the numeric name of the bits for a given byte are? I much prefer to be able to determine the weights of each bit without messy arithmetic. The part that would really confuse me is if the address bus were numbered with 0 as the msb. Do the big endian processors do that as well? Is the uBlaze really done this way? Rick
From: glen herrmannsfeldt on 20 Oct 2009 15:21
rickman <gnuarm(a)gmail.com> wrote: (snip) > Why would I care what the numeric name of the bits for a given byte > are? I much prefer to be able to determine the weights of each bit > without messy arithmetic. > The part that would really confuse me is if the address bus were > numbered with 0 as the msb. Do the big endian processors do that as > well? Is the uBlaze really done this way? IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, ESA/370, ESA/390, and z/Architecture. Note that z/ is the 64 bit extension, where all general registers and addresses are now 64 bits. The 32 bit instructions consistently operate on bits 32 to 63 of general registers, leaving 0 to 31 unchanged. Even more, z/ can operate on code using 64, 31, or 24 bit addressing as appropriate, and instructions change as the addressing mode changes. It is nice and consistent, and not so hard to get used to. -- glen |