FPGA co-simulation host VI synchronization

[xl600]

I am using LabView 2014 with Questa/ModelSim for cycle accurate co-simulation.  One thing that eludes me is how to get the host VI to supply stimulous to the FPGA code in a synchronized manner.

For example, if I have a SCTL enclosed FPGA logic function (Subframe_Detect_test_wrapper), I would like to feed test vectors to that in-sync  with the FPGA clock or with defined arbitrary timing.

When I use the niFpgaWaitForSimulatedTimeNs.vi to pace the stimulous in the host vi (After reading a set of test vectors from a CSV file), the vectors are applied once for every 56 (Why 56?) FPGA clocks when the wait is set to 25ns and the FPGA clock is 40MHz.

There's really no examples I've found which directly talk about how to get host VIs to drive aribitrary or clock synchronized stimuli into co-simulated FPGA simulation builds so I'm hoping someone here knows what the magic is.

Thanks!

[tcap]

Hello xl600,

Have you tried placing a Pause between the left shift register and the read/write control?

This should pause the elapse of time, write the values, progress 25ns, pause, and repeat.

Regards,

[xl600]

Yes.  That doesn't actually work.  There's some sort of arbitration logic that is executing inside the model.  I noticed that the host input data is actually synchronous but they aren't applied to the internals of the FPGA at the same time.  The arbitration process only operates on a single control input at a time.  A pause just tells ModelSim to pause but doesn't affect the control write process at all (Other than delaying during the pause period).

I'm beginning to suspect this is an intentional behavior and how compiled FPGA controls and indicators actually work in real life.  Do you think that might be the case?

What I'm trying to simulate are things like CLIP I/O and intra-FPGA I/O to/from sub-vis inside a SCTL.  It doesn't appear that cosimulation is capable of exercising that level of I/O.

[T-REX$]

If I recall correctly, our simulation model does include bus arbitration logic, which is useful for system level testbenches.

It sounds like what you want to do is more along the lines of unit/component testing. If your code is well modularized, you can likely compose a testbench fpga VI specific for testing each of your components. Something along the lines of a state machine that pulls down the stimulus values via DMA, then begins excercising your specific component, then pushes results back up.

It can be tough to design a testbench to sufficienly excercise inter-module communication, but It's the approach I would take...

[xl600]

Would you have an example of how to use DMA as stimulus for unit test FPGA simulations?  I tried to build a cosim testbench host VI to push vectors into DMA of a wrapper FPGA vi.  The wrapper FPGA vi waits for he DMA to be completed then it reads vectors out and applies the stimulus to the unit under test.  Couldn't get it actually work in Questa (DMA values would not read from the simualted DMA).  I only spent an hour or so so there might be something blatently wrong with my technique.

I may just give up on cosimulation and drive the CLIP IO or other internal IO directly in a VHDL file, but I don't have any good examples of that either so that's been my least favorite preference.  Cosimulation is where I would want to try to stay.

THanks,

Robert

[xl600]

Would you have an example of how to use DMA as stimulus for unit test FPGA simulations?  I tried to build a cosim testbench host VI to push vectors into DMA of a wrapper FPGA vi.  The wrapper FPGA vi waits for he DMA to be completed then it reads vectors out and applies the stimulus to the unit under test.  Couldn't get it actually work in Questa (DMA values would not read from the simualted DMA).  I only spent an hour or so so there might be something blatently wrong with my technique.

I may just give up on cosimulation and drive the CLIP IO or other internal IO directly in a VHDL file, but I don't have any good examples of that either so that's been my least favorite preference.  Cosimulation is where I would want to try to stay.

THanks,

Robert

[T-REX$]

I don't seem to have anything lying around anymore... but I also never used Questa, always ISIM (as it ships with LabVIEW). I know I've used that pattern before, and have also used pre-initialized memory items. 

Are you using VHDL or LV based host testbenches? I don't recall having any issues with DMA before.

[xl600]

Questa and modelsim operate identically (Modelsim is the core VHDL simulation engine of Questa).  I would like to use a host VI since I know that far better than VHDL, but if I have to use VHDL for driving the clip I/O and internal signals of the units under test, I will go down that route.

[T-REX$]

Well, if you're using LabVIEW or VHDL, the overall goal is the same if you're trying to avoid the simulation of the host interface... buffer/create any logic you need in the LabVIEW FPGA VI testbench (not sure if this came across well before: for unit testing, use an FPGA VI to stimulate your logic). I used to use FIFOs for a buffer, but pre-initialized memory items, or large arrays can work. its just for simulation, so it doesn't actually care about resource util or anything like that. If you need some initialization steps, you can always use a boolean indicator to give you a milestone in the waveform diagram, so you know when your actual simulation starts.

[xl600]

I was looking through the autogenerated sim files and pretty much came up with the same thoughts.  Use an FPGA VI as the driver and let LabView compile the driver code into the design.

Is it possible to drive CLIP or internal signals purely in VHDL? In the FPGA VI, I can plop down a FPGA interface node and access any of the CLIP signal I/O I want.  How would this be done via tb_NiFpgaSimulationModel.vhd?  It looks like NI doesn't provide access to any internal signals except GPIO and clocks.  If that's true, then to access internal signals would require deep modification of a lot of the autogenerated code items.