Forum Discussion
Altera_Forum
Honored Contributor
14 years ago --- Quote Start --- ohh thanks kevin...i implemented your ideas and am seeing some meaningful results.. However i am not constraining the reset signal with and input delay constraint and it is being reported as an unconstrained path as obvious.. What i learnt was to treat reset signals not as other input signals but i am still not able to constraint is as i really dont have the clear idea to contraint a reset signal? --- Quote End --- Most likely what is meant by whoever told you about reset being 'different' is that typically the FPGA design should be such that the user of the FPGA (i.e. the PCBA designer) does not have a timing requirement to meet. In other words, the FPGA designer has a requirement that it does not impose any timing requirement on the reset signal. From the perspective of the FPGA design, what this means is that reset can come along at any time relative to any clock in the design. In order to use that reset input in the FPGA design, one must first synchronize it to the clock (or clocks) and then only distribute the synchronized reset signal to any place in the design that requires a reset. This insures that reset will not violate any setup time requirements at any flip flops in the design. While this requirement about not imposing a timing requirement on an input signal is most prevalent with reset, it is not unique to reset. Imagine your FPGA is connected to a processor with an asynchronous SRAM type of interface. On such an interface, the specification lists min/max pulse widths for read and write signals but does not reference these signals to any other 'clock' signal. From the perspective of the FPGA then these signals can change at any time relative to the FPGA's clock. In any case, if you have the situation where an input is not synchronized to any clock available to the FGPA, then you can do one of the following: - Add some nominal setup time requirement so that the input pin does not cause an 'Unconstrained Path' warning - Tell Quartus to ignore timing paths originating from the I/O pin in question - Do neither and manually check that all unconstrained paths are correct every time you do a build. Kevin Jennings