09-09-2015 06:34 PM
@dkfire wrote:
Just one comment there, 36 and 38 is NOT on the same wire, there is a tunnel/border crossing.
The time when a output of the case structure is pressent depends on all the functions within the case structure. You have e.g. a write to memory in the case structure, how many circle does that take?
Remember that LabVIEW is dataflow, nothing can come out of a structure until all the code in the structure has completed.
Be careful with this comment. It's partially accurate. You're right that 36 and 38 aren't the same wire.
You're confusing a PC with the FPGA when you're talking about dataflow and cycles. Dataflow still matters. But, in a Single Cycle Timed Loop, all of the code will take place within a single cycle on the FPGA. That means the answer to your question about cycles is 1. It will take one cycle.
I wouldn't expect a SCTL to simulate very well on a cycle by cycle basis in your readings. It's going to take more than a single cycle in Windows to perform this task. I'm not sure if the simulator takes that into account or not.
09-10-2015 08:36 AM
I wouldn't expect a SCTL to simulate very well on a cycle by cycle basis in your readings. It's going to take more than a single cycle in Windows to perform this task. I'm not sure if the simulator takes that into account or not.
The FPGA Waveform simulator will take that into account. You should be able to prove that with the "show clocks" button in the probe window. Of course in "real-word time" things aren't running in a PC clock cycle, but back in the 2011-ish time frame, the idea of simulated time was introduced to the compiler, enabling features like "lock step" simulation, the desktop execution node, and the waveform probes.
Anyway, this does appear to be a bug in the way the waveforms are being rendered. I'll make sure that it gets reported as such to the team that owns it. Thanks for reporting it, and thank you ZX81 for posting reproducing code, that helps a ton when trying to track these things down!