FPGA.vi not compiled as designed

[riplakish]

I'm having an issue with an FPGA.vi that I have written which tries to implement six different variable PWM outputs in parallel.  The code excerpt below shows three of the six outputs (the other three mirror this implementation and reside in the same loop):

For this VI id=initial delay, ht=high time.  These are integer values in terms of FPGA clk cycles and they are calculated in the RT Host VI.  The PWMs are implemented with this initial delay to make the pulses of all six PWMs centered. All PWMs should have a frequency of 10kHz (40MHz/4000cycles).

When I compile and run this code it seems like the PWM signals are being multiplexed.  For instance if all the signals had the same duty cycle then they should all have the same rising and falling edge times.  Instead what I see is each signal being toggled in turns, with 6.6us between each action.  With six PWMs this means that I get 39.6us more high time and low time per period for each signal than I ought to.

Even using a multiplexed execution, 6.6us seems like an excessively long time, but that is beside the point.  First of all, am I correct in my theory that the compiler has implemented unasked for pipelining?  And if so, what can I do to enforce the parallelism I desire?  I considered putting each of the six PWMs in its own loop, but then I have a mess of synchronization to perform.  Thanks.

[riplakish]

A little bit of additional information.  The hardware being used here is an NI-9403 C-series module.  I tested out a VI which turns a single channel on and then immediately off.  I scoped the high-time on this action and it turned out to be 6.6us, so it looks like that might actually be the time it takes to change a DO.  This matches the 7us sampling time which is spec'd for the module, but I assumed that FPGA mode would decrease this significantly.

As for why the digital writes are executed in succession I have a theory that it is because the hardware itself does not allow individual channels to be written to independently and simultaneously.  Again this is not the behavior I expected.  In this case it would be the arbiter which is putting these digital writes into a queue.  It looks like I may need a different DIO module for my project needs.  Again any confirmation/revision of my theory here is welcome.  Thanks.

[Ever_Song]

Hi riplakish,

You are correct about the results from your scope test, the module itself is limited to a maximum speed of 7 us. Note: this is the maximum speed on the CompactRIO only. In a cDAQ this time is determined by driver and software latency and is likely much larger (see footnote 6 in the specs sheet).

Regarding your second question about successive writes, this is also hardware specific and is determined by the Output channel-to-channel skew (see footnote 5 in the specs sheet). There will indeed be a delay between outputting from successive channels.

[riplakish]

Thank you very much, you've given me some valuable information.  I was unfamiliar with channel-to-channel skew rate.  However the delay that I am seeing between successive writes is much greater than the skew rate for my module (7us rather than 265ns).  That is why I feel like it must be because all of my write commands are being queued by an arbiter, and apparently I cannot write to multiple channels independently and simultaneously.

It seems like the only way to write to multiple channels simultaneously would be to write an integer to the whole port.  The way I understand it, the writes that occurred on each channel from this would all be within 265 ns (channel-to-channel skew).  Am I understanding this correctly?  I could rewrite my program this way, but having effectively 6.6us resolution for my PWMs is unacceptable.  I'm looking to swap my 9403 for a 9401 and rewrite my PWM generation in a SCTL.  Again all feedback is welcome.  Thanks.