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: glen herrmannsfeldt on 17 Oct 2009 15:11 rickman <gnuarm(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.) > 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. OK, (8*n upto 8*n+7) or (31-8*n downto 24-8*n) I believe in some cases verilog can do that with a variable n, otherwise it can defintely do it with a constant n. Also, note that the one on the right depends on knowing the width of the word, while the one on the left does not. -- glen
From: rickman on 17 Oct 2009 18:41 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. > > 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. > > OK, > > (8*n upto 8*n+7) or (31-8*n downto 24-8*n) > > I believe in some cases verilog can do that with a variable n, > otherwise it can defintely do it with a constant n. Also, note > that the one on the right depends on knowing the width of the > word, while the one on the left does not. 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. 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. Rick
From: glen herrmannsfeldt on 17 Oct 2009 19:01 rickman <gnuarm(a)gmail.com> wrote: (snip, then I wrote) >> 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. (snip) >> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n) >> I believe in some cases verilog can do that with a variable n, >> otherwise it can defintely do it with a constant n. ?Also, note >> that the one on the right depends on knowing the width of the >> word, while the one on the left does not. > 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. Select a byte from a word. I haven't looked at the internals of microblaze at all, but it isn't unusual to address bytes in a 32 bit word. assign n=x[0:1]; assign byte=word[8*n,8*n+7]; > 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. I would expect selecting bytes from words to happen much more often in processor hardware than calculating the value of bits. Sometimes software has to compute the value of bits, but even that is pretty rare. As I said before, you might make the arguement for little-endian over big-endian, but when designing a big-endian processor, a decision that someone else might have made for you, you do it in the most appropriate way. -- glen
From: rickman on 17 Oct 2009 19:27 On Oct 17, 7:01 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > rickman <gnu...(a)gmail.com> wrote: > > (snip, then I wrote) > > >> 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. > > (snip) > > >> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n) > >> I believe in some cases verilog can do that with a variable n, > >> otherwise it can defintely do it with a constant n. ?Also, note > >> that the one on the right depends on knowing the width of the > >> word, while the one on the left does not. > > 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. > > Select a byte from a word. I haven't looked at the internals > of microblaze at all, but it isn't unusual to address bytes in > a 32 bit word. > > assign n=x[0:1]; > assign byte=word[8*n,8*n+7]; > > > 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. > > I would expect selecting bytes from words to happen much more > often in processor hardware than calculating the value of bits. > > Sometimes software has to compute the value of bits, but even > that is pretty rare. > > As I said before, you might make the arguement for little-endian > over big-endian, but when designing a big-endian processor, a > decision that someone else might have made for you, you do it > in the most appropriate way. I don't care about the endianness. I just have never needed to use that one calculation before. I would code a mux the way I code a mux for arbitrary inputs. with x select byte <= word(31 downto 24) when 00, word(23 downto 16) when 01, word(15 downto 8) when 10, word( 7 downto 0) when 11; It may be more verbose, but I think it is more clear than any calculation, especially since it is the same form as used elsewhere. I recognize instantly that this is a 4 input mux. But then I code a hardware description so that I have some idea of what hardware will be produced. I know a lot of people like to treat HDLs like software where they depend on the tools to optimize the design. The calculations I showed had to do with assigning values between buses of different sizes which is about the only place I can think to use calculations for array indexes. But then I'm sure there are others I just am not thinking of. Like I said, short of some special reason, I would always use N downto 0 notation because it indicates the bit weights. What is the value of bit 4 and 7 set? In this notation I know it is 144 without even knowing the width of the word. Rick
From: Gabor on 19 Oct 2009 09:58
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 |