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 14 Oct 2009 14:35 On Oct 13, 1:06 am, GrIsH <grishkun...(a)gmail.com> wrote: > > I tried lots of data types and the conversion function but didn't > get the result what i want...... > So iam going to put my problem straight forward to you.......your any > idea will be gr8ly appreciated.... > > Problem: > 1. i need to count the pulses from quadrature encoder , value of count > can be +ve as well as -ve depending upon direction of rotation of > encoder... > 2.This value is to be send to uBlaze.... > 3.I have a code for counting the encoder pulses that is included in > the "user_logic".... > 4.I have used "user software register" method of transferring data > from my custom IP to uBlaze.. > 5.In phase of transferring the value of count from IP to uBlaze, the > value of count must be mapped to IP2Bus_Data in SLV format data > type.... > 6.Here i had defined "count " that counts value of pulses as integer > and it should be converted SLV while transferring... > 7.But this method didn't work as i expected while receiving data in > uBlaze..... > So...Plz suggest me in.... > > what should be the data type of "count" that support +ve as well -ve > numbers and supports operation count<=count+1/-1 > ?? > and how -ve values of count are represented in SLV format?? I don't know that your problem is one of converting data types. You clearly are placing the 16 bit data in an odd location on a 32 bit bus and you have not told me that you are certain that this is correct. I have not worked with the uBlaze, so I'm not familiar with its data bus numbering. Is it 0 to N or N downto 0? Have you simulated your design? Before putting a design into the chip, you should always simulate it first to get your logic right. Then you can load it into the chip and see if it works with the real hardware. If you don't answer my questions and follow my advice, I can't help you. To answer your last question, the SLV signal type does not know anything about numbers. It is just an array, or a bus, of std_logic signals. There is no intended interpretation of this bus as a number. That is why the signed and unsigned types were developed. They have an explicit representation of signed and unsigned numbers respectively. When you talk about "converting" a signed value to an SLV, there really is no conversion. It is more like just connecting the wires. So the SLV ends up receiving the exact same set of 1s and 0s that were in the signed signal, according to the way that they connected. 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? But before changing anything you need to simulate your design. That means you will need a testbench which can be automatically generated by many VHDL tools. Then edit the resulting testbench file to add stimulus to your inputs and you will be able to observe any signal in the design in the waveform window. That will let you see each and every change of data in the path from the counter to the uBlaze CPU. Rick
From: GrIsH on 15 Oct 2009 00:51 On Oct 14, 11:35 am, rickman <gnu...(a)gmail.com> wrote: > On Oct 13, 1:06 am, GrIsH <grishkun...(a)gmail.com> wrote: > > > > > > > I tried lots of data types and the conversion function but didn't > > get the result what i want...... > > So iam going to put my problem straight forward to you.......your any > > idea will be gr8ly appreciated.... > > > Problem: > > 1. i need to count the pulses from quadrature encoder , value of count > > can be +ve as well as -ve depending upon direction of rotation of > > encoder... > > 2.This value is to be send to uBlaze.... > > 3.I have a code for counting the encoder pulses that is included in > > the "user_logic".... > > 4.I have used "user software register" method of transferring data > > from my custom IP to uBlaze.. > > 5.In phase of transferring the value of count from IP to uBlaze, the > > value of count must be mapped to IP2Bus_Data in SLV format data > > type.... > > 6.Here i had defined "count " that counts value of pulses as integer > > and it should be converted SLV while transferring... > > 7.But this method didn't work as i expected while receiving data in > > uBlaze..... > > So...Plz suggest me in.... > > > what should be the data type of "count" that support +ve as well -ve > > numbers and supports operation count<=count+1/-1 > > ?? > > and how -ve values of count are represented in SLV format?? > > I don't know that your problem is one of converting data types. You > clearly are placing the 16 bit data in an odd location on a 32 bit bus > and you have not told me that you are certain that this is correct. I > have not worked with the uBlaze, so I'm not familiar with its data bus > numbering. Is it 0 to N or N downto 0? > > Have you simulated your design? Before putting a design into the > chip, you should always simulate it first to get your logic right. > Then you can load it into the chip and see if it works with the real > hardware. > > If you don't answer my questions and follow my advice, I can't help > you. iam trying to simulate my design and lets see what will be the result... > > To answer your last question, the SLV signal type does not know > anything about numbers. It is just an array, or a bus, of std_logic > signals. There is no intended interpretation of this bus as a > number. That is why the signed and unsigned types were developed. > They have an explicit representation of signed and unsigned numbers > respectively. When you talk about "converting" a signed value to an > SLV, there really is no conversion. It is more like just connecting > the wires. So the SLV ends up receiving the exact same set of 1s and > 0s that were in the signed signal, according to the way that they > connected. > > 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. > > But before changing anything you need to simulate your design. That > means you will need a testbench which can be automatically generated > by many VHDL tools. Then edit the resulting testbench file to add > stimulus to your inputs and you will be able to observe any signal in > the design in the waveform window. That will let you see each and > every change of data in the path from the counter to the uBlaze CPU. > > Rick
From: rickman on 15 Oct 2009 11:14 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? I don't know how the uBlaze reads memory, it's possible that it can read the low 16 bits of the bus as a 16 bit quantity... *if you are using the right instruction* to to read a 16 bit quantity, not 16 bits of a 32 bit quantity. If you are coding in C, you are relying on the compiler to generate the correct code. The easy way to fix this problem in hardware is to assign the upper 16 bits of the bus the value of the sign bit of your result instead of always using zeros. Of course, all of this assumes that bit 31 is the lsb. Do you know that for sure? How do you connect the IP2Bus_Data to the uBlaze data bus? That is what really matters. Rick
From: Andy Peters on 15 Oct 2009 13:10 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
From: Andy Peters on 15 Oct 2009 13:15
On Oct 14, 9:51 pm, 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. You can freely assign little-endian (foo downto bar) vectors to big- endian vectors (bar to foo). You just have to remember that the bit lanes are always in the same order: foo(16 downto 0) <= bar(0 to 16); will put the least-significant bit (right-most bit) in bar (bit 16) into foo(0), and so forth. The only time you will have issues is when you use a loop to iterate over all bits in a vector and you don't pay attention to this (you don't want to assign bar(0) to foo(0), unless that's what you want to do!). -a |