Question about unconstrained input/ouput paths

[Altera_Forum]

Let's say I do not specify any input/output constraints in my design (set_input_delay/set_output_delay). This means there is nothing to report 'to the input register' as well as 'from the output register'. What will happen in real hardware situation?  

 1) Hardware will fail as these paths are supposed to be timing-analyzed but is not due to the missing I/O constraints. 2) Hardware will not fail - but fitter might not optimize timing due to the absence of the I/O constraints.

[Altera_Forum]

just make assignmet for ports "Virtual Pin" 

it is closer to 2nd, but it is not true. Cause you constrain clock network at least and exclude asynchronus signals properly from analysis. Try out clock as Virtual :-P

[Altera_Forum]

--- Quote Start ---  Let's say I do not specify any input/output constraints in my design (set_input_delay/set_output_delay). This means there is nothing to report 'to the input register' as well as 'from the output register'. What will happen in real hardware situation?   1) Hardware will fail as these paths are supposed to be timing-analyzed but is not due to the missing I/O constraints. 2) Hardware will not fail - but fitter might not optimize timing due to the absence of the I/O constraints.  --- Quote End ---    default behavior is that you will get a chip with a given tSU/tH/tCO which you shouldn't then violate i.e. external chips should take care. This is no good as fitting may also vary from build to build.

[Altera_Forum]

I was leaning more to outcome# 2, because the FPGA might fail to meet timing (i.e where the set_input_delay max would exceed the Setup Relationship but this is not reflected in TimeQuest since it is not constrained) resulting in hardware failure. Is my assumption here valid?

[Altera_Forum]

--- Quote Start ---  I was leaning more to outcome# 2, because the FPGA might fail to meet timing (i.e where the set_input_delay max would exceed the Setup Relationship but this is not reflected in TimeQuest since it is not constrained) resulting in hardware failure. Is my assumption here valid?  --- Quote End ---    since internal paths are constrained then there is no issue there. The io paths are not constrained and are unknown. The compiler ends up with figures for tSU/tH/tCO at io as achieved by fitter. Whether this is good for your io or not is a different matter. Moreover from build to build it will change. So it is not recommended anyway. If you are not sure about io constraints try some arbitrary figures rather than leave it unconstrained.

[Altera_Forum]

--- Quote Start ---  since internal paths are constrained then there is no issue there. The io paths are not constrained and are unknown. the compiler ends up with figures for tsu/th/tco at io as achieved by fitter. Whether this is good for your io or not is a different matter. Moreover from build to build it will change. So it is not recommended anyway. If you are not sure about io constraints try some arbitrary figures rather than leave it unconstrained.  --- Quote End ---    Kaz, do you mind elaborating more on this part as I am not familiar how I/O timing works with regards to tSU/tH/tCO. Does that mean fitter will randomly assign some values for those if unconstrained?

[Altera_Forum]

--- Quote Start ---  Kaz, do you mind elaborating more on this part as I am not familiar how I/O timing works with regards to tSU/tH/tCO. Does that mean fitter will randomly assign some values for those if unconstrained?  --- Quote End ---    yes it will as it inserts delays freely.  If it was me I will issue warning (or error) and stop compilation. However some designers prefer to close timing in three stages: 1) do internal paths only 2) add io 3) adding exceptions  the easiest is first and must pass before moving on.  I personally put it all in one go.   The tSU/tH achieved at inputs and tCO at outputs will be reported under device datasheet.