Time constraint and IP core

--- Quote Start ---

Hello, There're some things I'm confusing about time constraint or my design.

Is there any time constraint, which is embedded to code of the IP core to constraint logics inside it?

Because some IP cores are very complicate to understand (for me). Do I need to take care it?

Similar, Can I embed time constraint file to every single component of a top level? If that, the design looks more simple, 'cause I just have to take care only components of the top, not every components of the sub-block.

--- Quote End ---

In principle you need to define various input clocks used in the fpga and io timing.

Additionally you may take risk and add internal deconstraints e.g. multicycle or false path if you know them. Otherwise a lower module need not any specific constraints. some ip vendors may have their own such deconstraints in which case you add them with a new path. Don't worry about lower modules, the whole project is viewed as one module by the tool and it needs to know system clock(s), io timing and then it checks all internal paths.

--- Quote Start ---

In principle you need to define various input clocks used in the fpga and io timing.

Additionally you may take risk and add internal deconstraints e.g. multicycle or false path if you know them. Otherwise a lower module need not any specific constraints. some ip vendors may have their own such deconstraints in which case you add them with a new path. Don't worry about lower modules, the whole project is viewed as one module by the tool and it needs to know system clock(s), io timing and then it checks all internal paths.

--- Quote End ---

Thanks for your response.

In this case. I create some filters by IP then put them into top module. It's cleare that I have to constraint paths between filters and IOs. But if the filter is quite big, time delay between them is significant, there some registers inside it (which I don't really know its structure) and there's risk that some paths inside it do not meet time requirement, so how does the tool does in this case? Is that true that the time requirement inside filter always meet and it work correctly? (if I constraint all path between filters and IOs)

--- Quote Start ---

Thanks for your response.

In this case. I create some filters by IP then put them into top module. It's cleare that I have to constraint paths between filters and IOs. But if the filter is quite big, time delay between them is significant, there some registers inside it (which I don't really know its structure) and there's risk that some paths inside it do not meet time requirement, so how does the tool does in this case? Is that true that the time requirement inside filter always meet and it work correctly? (if I constraint all path between filters and IOs)

--- Quote End ---

Once the tool knows the io timing and system clock(s) it will then check the entire register to register paths inside fpga from input register through all your filters and right to output register.

If you don't add io timing it will still check all paths except input registers and output registers because naturally it does not know what is coming in or going out to and will tell you so. If you have asynchronous reset again it can't check removal/recovery time unless that reset is registered first and will tell you so.

So if you pass timing then it means all internal paths are checked to be short enough for logic changes to be ready in one clock period.