Setup violations implementing 10GB core

[multiprobe]

Hi,

I have been using the 10G-BASE R core(in 32 bit mode) for my communication from zc706 board to a custom board through optical cable. I had so far just been usign it by tweaking the top wrapper of the example design to use my ARM programmed Si5324 clock output to give a 312.5 MHz clock,.

I did not use any create_clocks command at my top level constraints ( directly routed clock pins to clock sources)  and despite giving me critical warnings about a lower level clock contraint file missing on certain false paths, It used to give me a pretty consistent bitstream that used to give me correct error free communication.

I had added very basic logic to tie 3 of the 32 bits to SPI signals to be sent to the destination board. This was working at KHz frequencies but not at higher frequencies. So I tried playing around with clocking wizard, and entered constarints for top level clock, after which the Implementation no longer passes succesfully. I am having setup violations, in a few paths . To make sure its not the added logic ( though it has been tested), I removed the SPI signalling, and just sent basic data vector through the xgmii, but the timing and hence the implementation still fails(after adding top level clocks).

I need to know if it is a mandatory criteria for using create_clocks in the design even if I directly route the input port to a clock source.

[yashp]

Hi,

I guess your design is not properly constraint.
You need to constraint your design and then there should not be any timing violation at tool level.

Once your design is passed you can check the same design at hardware.

As you mentioned designed passed with Khz clock and failed with higher clocks this is clear timing violation issue. You need to constraint your design 1st before moving into board.

I need to know if it is a mandatory criteria for using create_clocks in the design even if I directly route the input port to a clock source.
--> This constraints are useful to analyze your design at software level, they wont affect anything at hardware level.
In easy language if your board is using 200Mhz then provide clock constraint for 200Mhz and check your design behavior at software.


Thanks,
Yash

[multiprobe]

It is an example design which comes with the core, and I am just modifying the top-level wrapper, assigning some GPIO LEDs,PINs to provide input/output control,using the system clock to do I2C programming of  the jitter attenuator clock ( no added logic in the verilog level) ,which provides the required reference clock for the design. Do you think an example design will carry  timing violations ? 

When I compare the timing summary of the default example design with the tiing summary of my customized example design , 

I dont see the failing paths reported as passing in any of the clock groups defined in the example . In my design it is reported under the category **asynch_default**.

I have the below constraint in the IP timing constraint file which comes with the design, which is supposed to set these failing paths as false:

# False paths for async reset removal synchronizers
set_false_path -to [get_pins -of_objects [get_cells -hierarchical -filter {NAME =~ *sync1_r_reg*}] -filter {NAME =~ *PRE}]

Howver, the failing paths seem to be from above, ie they should ideally be trated as false paths by vivado, but the tool doesnt. Attaching a screenshot of the violations, and also what gets dumped on tcl console when I execute the get_pins from above. The last 8 lines show that these pins are supposed to be filtered out.

What are possible reasons this false path setting is not happening ?