FPGA race conditions/static hazards

[ToeCutter]

Hi,

I'm fresh off a LabVIEW FPGA course and feel I have a decent grasp of it, however a colleague on a project we are starting is pushing me for some answers before I have had a chance to 'play' with it.

The questions are:

1. How are you dealing with race conditions?

2. How are you dealing with static hazards?

My initial answer was that I think that LabVIEW will 'deal with it' and that the data driven 'wiring' paradigm will ensure that race conditions do not occur, so long as I'm not using local variables or reading/writing to the same control/indicator, in which case I will need to consider race conditions in the same way I would in old, non FPGA LabVIEW. Static hazards I have never heard mentioned in association with LabVIEW, so again I'm assuming it's taken care of 'behind the scenes'?

The application is streaming data to an NI PXIe-5644R and doing some onboard calculations in FPGA before streaming to the modulator if this has any bearing.

Thanks

[crossrulz · Accepted solution]

As long as you properly follow data flow, you won't have a race condition.  But it is something to be careful of.

I've never heard of static hazards being an issue with LabVIEW FPGA.  One thing NI does is it has buffers for each clock cycle.  This will keep the static hazards away.  Inside of a single cycle timed loop, these buffers are removed to get everything inside of a single cycle.  I'm not sure what NI does with these, but I've never heard of it being an issue.

[T-REX$]

The issue of static hazards inside SCTLs is more or less handled by the Xilinx compiler. When you specify a clock rate for an SCTL, a timing constraint is applied around the appropriate region (by LabVIEW). As the Xilinx Compiler does it's thing, it figures out what gates it needs to use, and then uses the setup and hold time of each resource to calculate how long is needed. If the design can safely execute within the specified clock cycle, then you will get a valid bitfile. If the compiler realizes that the summation of the setup and hold times for each logic cell in the critical path exceeds the period specified in the timing constraint, then you'll get a timing violation error.

So, long story short... yes it is taken care of behind the scenes, unless it can't be, at which point you get a compilation error (Timing Failure).

[ToeCutter]

Thanks gents! I wish I could mark them both as solutions. Crossrulz was first in, but T-REX added some detailed and useful info.

Thanks again