Why does selecting a new bitfile cause FPGA VI Reference to show a coercion dot?

[Mark_L]

I am trying to understand why a coercion dot is happening with LabVIEW FPGA and if it is a problem.  

To test this I created a brand new FPGA project and a blank FPGA.vi.

1) I place an "Open FPGA VI Reference" on my block diagram and configure it to the bitfile.  I then create an indicator from the "Open FPGA VI Reference."  The FPGA VI Reference Out indicator does not have a coercion dot.  This seems reasonable.  

2) If I then configure the indicator and select "Import from Bitfile" and select the same exact bit file then a coercion dot appears.  

Does this make sense and is there a way to eliminate the coercion dot?

[Dragis]

If you are selecting the exact same bitfile, then that seems like a bug. The type of the reference wire coming out of the node describes the interface to the FPGA application, and for the same bitfile that interface should be identical.

[Mark_L]

Yes, that is what I am thinking too.  

[ewang52]

Hello Mark,

What version of LabVIEW is this running on? And can you please attach your project? If this is indeed a bug, I can file a Corrective Action Request to bring this to the attention of our developers.

Eric

Applications Engineering

[Mark_L]

Hi Eric,  

I am running LabVIEW 2015 Service Pack 1 (version 15.0.1f7, 32-bit)

I used the Cloud Compile server to create the bit file.

I do have several other versions of LabVIEW on my computer.

Attached is a Test Project that shows the issue.  

Look at the comments in the block diagrams to see the sequence that show how the coercion dot appeared.  

[Mark_L]

By the way, my original intent was to modify the FPGA code from a project I created using the Sample Project "LabVIEW FPGA Waveform Acquisition and Logging on Compact RIO."  

I kept coming up with broken wires and also this coercion dot.  So I narrowed it down to just re-configuring the indicator. 

What I really want to do is to somehow update the Global FPGA Reference in the project I am making from the Sample Project.  

[nathand · Accepted solution]

---

@Mark_L wrote:

What I really want to do is to somehow update the Global FPGA Reference in the project I am making from the Sample Project.  

---

You can make an FPGA Reference into a type definition; then you only need to update the type definition and all the instances of it will be updated. Does that help, or did I misunderstand your question? Also, if the Open FPGA VI Reference function is configured with the Bind to Type Definition option, then when you reconfigure it to point at a different FPGA bitfile, it will update the type definition, overriding any changes you might have already made to that linked type definition. If you're using the Bind to Type Definition option, don't edit the type definition yourself.

[Mark_L]

Thank you Nathan.  I am going to try the Binding of an FPGA VI Reference. I'm trying to follow the instructions here 

http://digital.ni.com/public.nsf/allkb/2906287B989006EA862576AB005BE08E

I'll let you know if this works.

The Sample Project "LabVIEW FPGA Waveform Acquisition and Logging on Compact RIO"  does have a type def (not strict though).  

[nathand]

After I posted I opened your project (I had to find a machine with LabVIEW 2016 first). It opens the FPGA reference in Dynamic mode, so binding to a type definition isn't an option. However, you can still use a type definition, you just need to create one from the indicator instead of binding it within the Open FPGA VI configuration.

Also, I didn't check if it's the case here, but note that you may see a coercion dot when you wire data to a type definition if the data source isn't that same type definition, even though the data itself is the same type. There's no downside or problem with a coercion like that, and it's not worth trying to avoid it.

[Mark_L]

I still need some experience with understanding which is better to use Dynamic or Binding and when.  But for now the Bind FPGA host reference to type definition option is letting me go forward.  

Thanks.  

[DavidGrimm]

This happens when the data cluster within that reference does not match that of the control or indicator. Front panel items, memory items, FIFOs, etc. and their data types are all contained within that reference wire and if they don't match between the sink and the source, it will coerce it.

To fix this problem, make sure all the FPGA VI items match perfectly between inputs and outputs you are trying to wire together.