System Generator and clock in co-simulation

Question

Hello,
I did connected Nexys 4 board to system generator co-simulation. Board runs with co-simulation mode but really slowly. The fastest pulse is ca 1 ms and speed is not stable. That might be caused due usb speed.
- How can I use boards own 100MHz clock from pin E3?
- How to route clock signal to Xilinx block correctly?
I would like to create SPI-controller and I need 5 MHz clock signal. I would like to give registers values to SPI controller from simulink and measure feedback values on simulink. I just don't understand how to implement real clock signal to xilinx block.
I did made MCode block to serial and parallel conversion, but now I cannot get correct clock signals to real system. Plan was just first make an demo from boards own accelerometer. System generator settings are: FPGA clock 10 (ns), Simulink system period 1 (sec) and Clock pin location E3.
What is going wrong? Any ideas?
Antti

Answer 1

Hi antti,
Free running mode can be done only via JTAG and on any board (if the target device is supported by your ISE/Vivado license).
If your board is not listed, then you have to create a new HW-Cosim target for sysgen.
Actually this has to be done most of the time, since you have to define the I/Os (Pin locations) that your design will use.
I wonder how you intend to simulate the interface activities like the mentioned SPI in your Matlab/simulink simulation Model.
These are hard to predict and often only give an idealized result. So even if the normal HW-Cosimulation would be incredible fast you would see differences that could spoil the comparision between the simulation model and the actual hardware.
But what you still can do is:
Run your simulation first. Store the results.
Then run your HW-Cosim in Free Running mode.
Transfer the data you want to compare to the host system and do the comparision afterwards.
Comparision of simulations with Data taken from actual running Hardware is always a challenge.
Eitehr your simulation becomes very very complex, or the darn real physical stuff does behave quite unexpected, even if working correctly.
The best approach is to concentrate on only a few interesting data points and analyze these isolated from timing behavior.
For Interfaces there's also the possibility to implement OVL Checkers in the hardware. These check the proper interface activity in realtime in your design.
Follow this link to learn more about it:
http://accellera.org/activities/working-groups/ovl
Have a nice synthesis
  Eilert