Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎01-06-2009

XtremeDSP hw Cosim timing constraints

I am trying to run the hw cosim on the Xtreme DSP VirtexII Pro board and when generating the cosim block the xflow throws a timing error and the block does not get simulated. I understand this is based on the Simulink period, however I am still a bit confused. For example with the simulink period of 3.125e-7 we get the error with the Worst case Slack being -339610.853ns. However with the simulink period of 3.125e-6 the block gets generated and the Worst Case Slack is 825027.287ns. How come there is such a big swing with one order of magnitude in the simulink period. Below is the error and the component that causes it. Also at this point the only things contained in the hw cosim is Read from FIFO block and DAC. Is there any way to be able to run the system with the faster simulink period?



ERROR:Par:228 - At least one timing constraint is impossible to meet because component delays alone exceed the

   constraint. A timing constraint summary below shows the failing constraints (preceded with an Asterisk (*)). Please

   use the Timing Analyzer (GUI) or TRCE (command line) with the Mapped NCD and PCF files to identify which constraints

   and paths are failing because of the component delays alone. If the failing path(s) is mapped to Xilinx components as

   expected, consider relaxing the constraint. If it is not mapped to components as expected, re-evaluate your HDL and

   how synthesis is optimizing the path. To allow the tools to bypass this error, set the environment variable




* TS_ce_3200000_8ff8109f_group_to_ce_320000 | SETUP   | -339610.853ns|     3.301ns|     116|   739926274

  0_8ff8109f_group = MAXDELAY FROM                 

  TIMEGRP "ce_3200000_8ff8109f_group" TO TI      

  MEGRP         "ce_3200000_8ff8109f_group"       

   51200000 ns                              

0 Kudos
5 Replies
Registered: ‎08-01-2007


There are two things to clarify here. The timing error is not based on the simulink system period. It is based on The FPGA clock period. The FPGA clock period is the period, in nanoseconds, of the

system clock. If p represents the Simulink system period, and c represents the FPGA system clock period, then something that takes kp units of time in Simulink takes k ticks of the system clock (hence kc nanoseconds)


in hardware. And it is impossible for us to include DAC in the hw-cosim block. The DAC in SysGen is essentialy equivalent to Gateway Out.


As for how to resolve this timing error, you can either increase the FPGA clock period but before do that you should know what clock frequency the oscillator on the board can provide, or find out the critical paths in the


design and add registers to reduce them.

0 Kudos
Registered: ‎01-06-2009

Thanks for the response. It turns out that the timing errors were only occuring when the simulink system period was not matched with the FPGA clock period. When the periods are close, everything works out well.


However, I would like to know why can't you have DAC's inside the hw_cosim block?  In my design I do bunch of signal filtering and I want to output analog signal from the board? Do I have to put the data in a shared memory and then put it to a DAC outside of hw_cosim block? Or what would be the optimal way to do so. 


Thanks for any help. 

0 Kudos
Registered: ‎08-01-2007


A hardware co-simulation block does not include board-specific ports on its external interface. This means that if a model includes a gateway that correspondes to a board-specific port, the corresponding port is connected to the simulation model instead of the actual hardware when the design is compiled for hardware co-sim. To leave the port connected to a real port, use a non-memory mapped gateway instead.


FPGA platforms often include a variety of on-board devices (e.g., external memory, analog
to digital converters, etc.) that the FPGA can communicate with. For a variety of reasons, it
may be useful to form connections to these components in your System Generator models,
and to use these components during hardware co-simulation. For example, if your board
includes external memory, you may want to define the control and interface logic to this
memory in your System Generator design, and use the physical memory during hardware

You can interface to these types of components by including board-specific I/O ports in
your System Generator models. A board-specific port is a port that is wired to an FPGA
pad when the model is compiled for hardware co-simulation. Note that this type of port
differs from standard co-simulation ports that are controlled by a corresponding port on a
hardware co-simulation block.

A board-specific I/O port is implemented using special non-memory mapped gateway blocks
that tell System Generator to wire the signals to the appropriate FPGA pins when the
model is compiled into hardware. To connect a System Generator signal to a board-specific
port, connect the appropriate wire to the special gateway (in the same way as is done for a
traditional gateway).

Non-memory mapped gateways that are common to a specific device are often packaged
together in a Simulink subsystem or library. The XtremeDSP Development Kit, for
example, provides a library of external device interface subsystems, including analog to
digital converters, digital to analog converters, LEDs, and external memory.

Registered: ‎02-09-2011


I designed the digital controller usin XSG blocks.It works fine.The problem is that it offerd total path delay of 33 ns.

I have Spartan 3E offers clock frequency of 50 MHz,equivalent to 20 ns.The path delay should be less than this clock period (20 ns).First I want to generate hw cosim block and then want to use it for the hardware/software cosimulation. I can't simplyfy further my algorithm to reduce the path delay. How can I solve this problem?Please help me,I am confused.

All I want to use hardware in loop and I had Spartan 3E.

0 Kudos
Registered: ‎09-01-2011

I've got exactly the same problem of abbas_0612000

0 Kudos