LabVIEW
Diagram Disable causes error in FPGA code
Plus this isn't restricted to FPGA. Here's a standard snippet from a VI with no project. Note that the array is not fixed to a size. The array is of I32. The broken wire says that the sink is a double. Notice I did not say a 1D array of double! The disabled case is wired straight through.
Unfortunately, that work around does not work for all numeric primitives, Absolute Value for instance.
@Donovan_B wrote:
I did some looking and this has already been reported to R&D (# 291212). As crossrulz mentioned, unchecking the Adapt to Source property for the increment primitive (and optionally specifying an overriding output type) should work around the issue.
Thanks for checking into that. I didn't know the increment function had that feature; however, the type mismatching isn't the problem I was referring to, nor do I use the increment function in my code. It was just the simplest thing that caused the error I was talking about. The image below is a better representation of my actual code.
As you can see, the wire type bug is completely independent of the "fixed size array" error I'm seeing. In the last two cases I can eliminate the error by wiring a constant into the N terminal, but it's not clear to me why it is required only for those to situations.
@User002 wrote:
I wouldn't be using arrays. They consume a lot of FPGA resources.
Rather use registers or block memory.
Probably wise council, but I'm still an FPGA newb and haven't graduated to registers or block memory. 
As it turns out I'm doing very little in the FPGA code and it has no problem with the small array I am using.
@Daklu wrote:
Probably wise council, but I'm still an FPGA newb and haven't graduated to registers or block memory. As it turns out I'm doing very little in the FPGA code and it has no problem with the small array I am using.
I am not sure using block memory is "harder". It is basically a predefined array with a reference pointing to it.
With Block Memory:
With an array based operation:
Br,
/Roger
I agree it's not harder, but it does require knowledge I haven't obtained yet if I want to use them intelligently. For example, with the code I have the final device utilization report shows I've used 10 of 40 "Block RAMs." How big is each Block RAM? Is using block RAM instead of a 4 element array going to consume 1 of those blocks?
Also, below is a screenshot of my main FPGA loop. I assume the array created from the Build Array function is implemented as flip flops directly in the logic. Won't it increase the propogation delay if I'm shuffling the data off to a memory block somewhere instead of right where the data is created and used?
@Daklu wrote:
I agree it's not harder, but it does require knowledge I haven't obtained yet if I want to use them intelligently. For example, with the code I have the final device utilization report shows I've used 10 of 40 "Block RAMs." 1. How big is each Block RAM? Is using block RAM instead of a 4 element array going to consume 1 of those blocks?
Also, below is a screenshot of my main FPGA loop. I assume the array created from the Build Array function is implemented as flip flops directly in the logic. 2. Won't it increase the propogation delay if I'm shuffling the data off to a memory block somewhere instead of right where the data is created and used?
1. It depends on the FPGA HW/Config. As long as you are not running low on these blocks, don't worry.
2. Block memory accesses can be inside single cycle nodes. That is, the operation takes 1 clock cycle to complete. I got those in my single-cycle I2C driver FPGA code.
There seem to be a coercion dot on the FIFO, you should consider splitting up the for loop (unrolling the loop) into 4 separate filter entries for better filter presicion (if you need it?). Array based filter access are limited to 16bit FXP presicion.
Br,
/Roger
