08-30-2010 12:06 PM - edited 08-31-2010 01:38 PM
CR,LF? I switched to IE8 so RTF works now...
I am evaluating the system generator and have some questions I need help with.
I am using ISE 12.2 and Matlab R2009B. I have an ML506 board that I would like to try using with the co-simulation. In one Xilinx document it talks about a 1G Ethernet card being required, but another talks about being able to use down to 10MB. Is there a big gain from the Ethernet speed?
The ML506 comes with a 128M FLASH card. I unpacked the files from Matlab and then edited the ip.dat to use with my local network. I could not find anywhere that talks about how the DIP switches need to be set on the ML506 when using it as a co-simulator. Does it matter?
If I target the ML506 using JTAG, it all seems to work. If I target using Ethernet, point to point, even through a switch, this seems to work fine. Strange, I am able to remove the FLASH card and still get it to work point to point, so I assume the MAC is loaded as part of the image? Is the card only required when using IP?
I see that if I have the card installed, then run a point to point simulation, the LCD will display the MAC and IP. After this, I am able to ping the board. However, I seem unable to use IP from Simulink. What needs to be done to make IP work?
I used the lab 7, in the system generator getting started as a benchmark. I built this using all three methods, (Simulink, Xilinx primitive and Xilinx co-sim) and compared results. Next I built it using each method and measured the run time to 0.1 seconds.
Simulink 1 second
Xilinx prim. 2 min, 22 sec.
Xilinx co-sim 3min, 30sec.
I assume the co-simulation is so slow because of the Ethernet overhead. I am using 100MB Ethernet for this benchmark. This was point to point. I assume a call is made for every time step. I have not yet put a sniffer on it to try and see what's going on, but I would have thought that they would make use of the on-chip memory to reduce the number of calls.
Are there some good examples out there that actually show where there are gains from the co-sim, versus just the Simulink software approach?
I did see one crash that the tool complained about one of the Xilinx primitives. Typical call Xilinx support with as much info as possible. I attempted to repeat these steps today and had no luck doing so. Are there known leaks, etc that users should be made aware of that cause the tools to crash?
Not on topic but good job with ISIM. This version is actually becoming useful. Start thinking about code coverage! Thanks for any help you can provide.