Info (332102): Design is not fully constrained for setup requirements in max10 devices

[Theja]

Hi ,

I am using max10 device with espi slave ip in my project. My resource utilization is 98% and 97% sometimes .I am using pll of clock 100MHz using for espi controller logic in the design. I have constrained setup and hold with values 4 and 3 as I am using 25MHZ clock for generating 100MHZ clock.

Now the issue is espi reads/writes failes by giving "0xffffffff".Eventhough I am having the warning as Info (332102): Design is not fully constrained for setup requirements,the design works for one bit file. If I change the small logic and generate bit file it won't work. In-consistent behavior w.r.t compilation.

Can you please help me how to constrain the design with input and output delay constraints or is there any way to fix it.

create_clock -name clk -period 40 [get_ports {CPLD_25M_CLK}]
create_clock -name clk_espi` -period 30.3030303 [get_ports {CPU_CPLD_ESPI_CLK}]
create_clock -name clk_led` -period 100 [get_ports {LED_CLK}]

derive_pll_clocks
derive_clock_uncertainty

set_multicycle_path -from {espi_avmm_int:avmm_int|csr_addr*} -to {csr:csr|csr_rddata*} -setup -end 4
set_multicycle_path -from {espi_avmm_int:avmm_int|csr_addr*} -to {csr:csr|csr_rddata*} -hold -end 3
set_multicycle_path -from {csr:csr|csr_rddata*} -to {espi_avmm_int:avmm_int|avmm_writedata*} -hold -end 3

[RichardTanSY_Intel]

What is the timing violation reported in the Quartus?

Could you help to share your design by archiving the project (Project > Archive Project) so that I can investigate it further?

Regards,

Richard Tan

[Theja]

I am not seeing any timing violation in the quartus tool

[RichardTanSY_Intel]

Have you run the functional simulation and checked whether the design functions correctly?

Do you see any Unconstrained Path in the Timing Analyzer? Or any report highlighted in red in the compilation stages?

You can refer to "AN 433: Constraining and Analyzing Source-Synchronous Interfaces" to learn more about set_input_delay and set_output_delay.

Regards,

Richard Tan

[RichardTanSY_Intel]

Any update on this?

Regards,

Richard Tan

[RichardTanSY_Intel]

Any update on this?

Regards,

Richard Tan

[RichardTanSY_Intel]

Hi,

As discussed in the call, here are the discussion points:

1.Design utilization with 99% is very difficult to close timing. Suggest to migrate to a larger device as device with high utilization will complicate timing closure.

2. Advised to close timing in all timing corners as there might be unknown risk even though the design can run successfully in hardware.

3. Advised to resolve the Unconstrained Path violation in the Timing Analyzer.

As we have another duplicate case, we will continue the support in the IPS and will transition this thread to community support. 

If you have any further questions or concerns, please don't hesitate to reach out. 

Thank you and have a great day!

Regards,

Richard Tan