LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

80-bit signed number in FPGA to host

Solved!
Go to solution

I have an 80-bit signed number on my FPGA that I want to move to my host which does not support 80-bit numbers.  Host is limited to 64-bits.  I am not worried about displaying the number on my UI and losing resolution as the FPGA will keep an accurate tally with 80-bits.

 

I tried breaking the 80-bit number into 16-bit and a 64-bit numbers and FIFO'ing them to the host.  That works.  However, when the number is negative, the number has been converted to 2's complement.  It is the reassembly of the 16-bit and 64-bit back into their total number that has me stumped.  I cannot convert the two host numbers using standard 2's complement techniques because the math won't work out correctly.

 

My next plan is when the FPGA 80-bit number is negative, undo the 2's complement on FPGA but still use the sign bit (msb) to show that it is negative.  Then, on the host, I can perform simple math to get back to the original number [(2^64)*16-bit number + 64-bit number] and negate if the msb is true.

 

Are there any simpler ways to get this job done?  Anyone see a flaw in my second plan?

0 Kudos
Message 1 of 6
(3,624 Views)

@RascalHamster wrote:

I have an 80-bit signed number on my FPGA that I want to move to my host which does not support 80-bit numbers.  Host is limited to 64-bits.  I am not worried about displaying the number on my UI and losing resolution as the FPGA will keep an accurate tally with 80-bits.

 

I tried breaking the 80-bit number into 16-bit and a 64-bit numbers and FIFO'ing them to the host.  That works.  However, when the number is negative, the number has been converted to 2's complement.  It is the reassembly of the 16-bit and 64-bit back into their total number that has me stumped.  I cannot convert the two host numbers using standard 2's complement techniques because the math won't work out correctly.

 

My next plan is when the FPGA 80-bit number is negative, undo the 2's complement on FPGA but still use the sign bit (msb) to show that it is negative.  Then, on the host, I can perform simple math to get back to the original number [(2^64)*16-bit number + 64-bit number] and negate if the msb is true.

 

Are there any simpler ways to get this job done?  Anyone see a flaw in my second plan?


Don't interpret as a number.  Just send it as a byte array (or a string) and convert it into an array of Booleans on the other side.  Since the most significant bit will be your sign bit, just chop out all the bits in between that bit and the 63rd bit, then convert the remaining array into a 64-bit signed integer.  This is assuming you won't ever send an 80-bit number that is larger than a 64 bit number can handle.  Then, of course, all bits - err, bets - are off...

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 2 of 6
(3,598 Views)
Solution
Accepted by topic author RascalHamster

@billko wrote:


Don't interpret as a number.  Just send it as a byte array (or a string) and convert it into an array of Booleans on the other side.  Since the most significant bit will be your sign bit, just chop out all the bits in between that bit and the 63rd bit, then convert the remaining array into a 64-bit signed integer.  This is assuming you won't ever send an 80-bit number that is larger than a 64 bit number can handle.  Then, of course, all bits - err, bets - are off...

 


Of course I forgot to mention that all this FPGA stuff must happen inside a SCTL running at 50 MHz.  I pondered it a bit and came up with this solution:

1.  broke the 80 bit number into a 63-bit and a 17-bit number

2. FIFO'd to host (everything afterwards is on host)

3. checked the 17th bit of the 17-bit number for negative

4. If negative, treated the 63-bit number as a 2's complement

5. If the 63-bit number overflowed to 64-bits (which I can handle on the host), then I carry to the 2's complement operation of the 17-bit number.

6. Then I changed them to EXT precision, weighted the 17-bit number (now 16-bits) by 2^63, and added to the converted 63-bit number.

 

Kind of screwy but it works.  The key was that first split of the 80 bit number into 63 & 16 bits.  I don't know how to send arrays greater than 16 elements or strings thru a FIFO so I do the best with what I know.

 

0 Kudos
Message 3 of 6
(3,578 Views)

The best solution is always the one that works.  😉

 

Don't forget to mark your own post as the solution so other people could benefit from your wisdom!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 6
(3,572 Views)

Hi Hamster,

 

just because I'm curious: Which datatype do you use to hold this "80-bit signed number"?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 6
(3,551 Views)

On FPGA you are limited to 64-bits.  Or, so I thought!  I was using a Xillinx accumulator that could handle 128-bits.  I asked the same question.  You use a boolean array to hold more than 64-bits.  In my case, 80-bits was sufficient.  I went immediately to a 2-element U64 FIFO to get the data to my host.

 

On the host, I converted to EXT precision when necessary to maintain as many bits as possible.  In addition to using the EXT numbers on my UI, I wrote them to a file for historical purposes.

0 Kudos
Message 6 of 6
(3,525 Views)