LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shift register data type

Try use the fixed point conversion nodes as suggested and also explicitly wire a fixed point data type other than 32 bits, for example 16, to the fixed point conversion node. 

0 Kudos
Message 11 of 15
(1,199 Views)

Turn off  'Adapt to Source' in the adder.  If that doesn't fix it.....

 

What is the exact type of the fixed-point '2'?  I recommend signed, 6-bit integer, to match the output of the add.

 

With the HTM add, I think you're covered; the output appears to be fixed as +/- 6-bit integer (make sure 'Adapt to Source' is unchecked!).  But the generic add will try to output more bits than its input (to add '4').  (So will the HTM Add, if the result is 'Adapt to source').  And the shift-register will try to upgrade itself to accomodate the constant initializer and the output of the add.  Since the add tries to always output more bits than the shift register and the shift register tries to always be at least as big as the output of the add, they can't resolve without going to floating point.  But as mentioned, floating point isn't allowed in FPGA.

 

One mistake I've run into is hidden tunnels.  It's easy to accidentally wire an output through the wall of the for loop, and back into itself, creating a tunnel underneath the shift register.  Try moving the shift out of the way, to see if there is something hidden underneath.

 

The suggestion to delete the wires & restore them is great, but since that didn't work, I recommend you delete the shift register, too (assuming you didn't find a hidden tunnel).  First wire the '2', then turn it into a shift, then wire the input to the add, then the output from the add.  Last, the indicator, and change the indicator to match the source.  At each step, watch to see if the type changes.

 

___________________
CLD, CPI; User since rev 8.6.
0 Kudos
Message 12 of 15
(1,197 Views)

I think in my case the only solution is to turn off adapt to source for the HTM Add function. All other options doesn't work for me.

 

Thank you for helping!

0 Kudos
Message 13 of 15
(1,183 Views)

I'm glad it's working...

 

As you move forward, you'll need to make sure the fixed-point is the right size for what you ultimately need, so you may need to adjust it a bit.  Good luck.

___________________
CLD, CPI; User since rev 8.6.
0 Kudos
Message 14 of 15
(1,175 Views)

Just to follow up. Like others have already mentioned in this thread Fixed-Point types in LabVIEW by default grow through operations so the values will not overflow (i.e. lose most significant bits). When you have a feedback path created by shifter registers or feedback nodes LabVIEW will determine that there is no single Fixed-Point type that will work without losing values so it coerces up to a floating point type which are the LabVIEW dynamic numeric types.

 

This generally makes it obvious which dataflow paths are causing the cycle. As you start changing your values from floating point to fixed-point types you'l see the cycles in orange. There are two common ways to convert these feedback paths. 

 

1. Insert To Fixed-Point conversion nodes and wire in or override the output type to the appropriate/desired fixed-point type.

 

2. Override the output of the operator(s) in the cycle.

 

2015-08-25_10-40-47.png

 

To override the output of an operator right-click and select Properties and then go to the Output Configuration tab. For the High-Throughput Math Library nodes the approach is very similar, the property page just looks different.

Message 15 of 15
(1,155 Views)