how to use a fixed portion of fpga except logic lock?

[Altera_Forum]

I am working at module level and my cells seem to be scattered over the fpga board and hence i am experiencing high IC delays and if i constrain one the other paths get affected... 

I know about ogic locking but want a generic technique to reduce my IC delays.. THANX

[Altera_Forum]

You should constrain all your design, and Quartus will make sure that the delays are within your specifications.

[Altera_Forum]

All my design? 

you mean to say each and every node? Because the global assignments given to the entity are not working properly. Thanks

[Altera_Forum]

--- Quote Start ---  All my design? you mean to say each and every node? Because the global assignments given to the entity are not working properly. Thanks  --- Quote End ---   What is meant by 'all' is that you should specify all of the timing constraints to Quartus. At a minimum, these constraints are: - Input pin setup time for all input pins to the device - Output pin clock to output delay for all output pins from the device - Clock frequency (or frequencies if more than one) - Input pin to output pin propogation delay (if there are any purely combinatorial logic paths)   There can be other less common constraints which would be used only if your design contains certain specific features (for example, a clock boundary crossing).   The basic idea is that - Your code specifies the function to be implemented - The timing constraints define the performance that is required   If you have a design that implements the function you want and meets all of your performance requirements then for the most part you really shouldn't care how the tool places logic within the device. If you are concerned, it is typically because you are trying to second guess the tools. Not to say that you can't do better, but most of the time you won't.   In order to specify the various timing constraints mentioned above, you need to calculate based on the characteristics of the system in which the FPGA will live. As a simple example, consider an FPGA input pin that receives its input from a device that has a clock to output delay of 5 ns. This device is clocked by the same clock as the FPGA. Then, in order to figure out the maximum allowable input setup time of the FPGA, you would basically perform the following calculation: FPGA_Setup_Time = Clock_Period - 5 ns - Estimated_Clock_Skew There would be an analogous type of calculation performed for FPGA output pins. Note the following: - You need to do these calculations independently for each input and output pin, it is not a 'global' device level calculation. - The timing constraints are mostly I/O pin related, not so much for anything internal to the device no matter how simple or complicated the function that is being implemented is. A design with 100 I/O pins would have 100 I/O pin related timing constraints and a clock period constraint but possibly nothing else. This would be true whether the design fits into a smallest Cyclone or the largest Stratix device.   As I suggested, there can also be other constraints that might be required, but that would depend on whether or not you have those elements in your design. The most common example is having two different internal clocks running around and signal(s) that are sourced from one clock domain being sampled in the other clock domain.   Once you have all of the timing constraints entered into Quartus, do a build. Those constraints give Quartus the information it needs to do the placement and routing tradeoffs needed in order to meet your performance requirements (i.e. timing constraints). The report file will tell you if any paths failed and by how much. From there you analyze the path and try to figure out what needs to change in the logic path (or the clock period) in order to meet all of the constraints.    Kevin Jennings

[Altera_Forum]

Ok..Thanks kevin  

A well explained idea was all i required and you provided it. Thanks

[Altera_Forum]

Can you throw some more light on the constraint with the input to output pin propagation delay?

[Altera_Forum]

--- Quote Start ---  Can you throw some more light on the constraint with the input to output pin propagation delay?  --- Quote End ---   Consider the following example:   - FPGA design has two inputs 'A' and 'B'; one output 'C'. The functional requirement is simply C <= A and B; - 'A' and 'B' are outputs of some other device(s) on the board that is clocked by the signal 'CLK'; the clock to output delay of that device(s) is 5 ns. This device is 'U1'. - 'C' is received by yet another device on the board that is clocked by 'CLK'. There is a setup time requirement on that device that 'C' must arrive at the device at least 3 ns before the rising edge of 'CLK'. This receiving device is 'U2'. - The period of 'CLK' is 20 ns. - The skew of 'CLK' between U1 and U2 is estimated to be no more than 0.5 ns.   So the function that the FPGA is implementing is simply an 'and' gate, there are no flip flops involved, no clock. Therefore 'A' and 'B' would not have any setup time requirements; 'C' would have no clock to output requirements. Yet the system as a whole does have timing requirements. However, if you tried to enter setup requirements for 'A' or 'B' or clock to output requirements for 'C', Quartus would ignore them (and it would also list those requirements as being ignored).   What the FPGA is implementing though is a purely combinatorial logic path which means that the requirement that needs to be specified is a pin to pin propogation delay. For this example, the tpd requirement for 'A' would be calculated as: Tpd_Rqmt_A_To_C = Clock_Period - Tco(A) - Tsu(C) - Clock_Skew Tpd_Rqmt_A_To_C = 20 ns - 5 ns - 3 ns - 0.5 ns = 11.5 ns Signal 'B' would have an analogous calculation and in this example the computed number would be the same 11.5 ns. However, one must still treat these as independent logic paths. If 'B' came from some other device than 'A' and had a different delay then 'Tpd_Rqmt_B_To_C' would have a different value than 'Tpd_Rqmt_A_To_C'. Whether they are the same or different, both constraints are entered into Quartus and as with the other timing requirements mentioned in my previous response would be taken into account during place/route and reported on to determine if the requirements have been met.   One simple way to check to see if you have all of these basic requirements (setup, clock to output, prop delay) specified is to look at the Quartus timing report. It will have a section called 'Unconstrained Paths'. Basically what this is listing are paths that have no timing requirements specified. At a minimum, you should have no such paths if you think you have fully specified the timing requirements.   There can be situations where you really do not have any specific prop delay requirement. Taking this same example, what if there was no setup time requirement on 'C' (perhaps the receiving device really can take this signal in completely asynchronously). Now you would have no prop delay requirements from 'A' to 'C' or 'B' to 'C'. What you can do in that situation is simply enter a nominal delay into Quartus. What this does is removes these paths from Quartus' list of 'Unconstrained Paths' but does not overly burden the place/route operation trying to meet some absurd requirement. This makes it easier to verify that the timing requirements are met as you do new builds since you simply need to see that there are no failing timing paths and no unconstrained paths.   As you change your design to fix functional problems, you should also look to see that there are no new 'Unconstrained Paths' that are popping up. Again, taking this example (with 'C' still having a setup time requirement), what if you changed the function so that 'C' is now a clocked output. In that situation, the prop delay requirement that you previously specified would now show up as an 'Ignored timing assignment'; setup time to 'A' and 'B' as well as clock to output delay of 'C' should show up as 'Unconstrained Paths'. So logic changes can alter what you need to specify as the timing constraints.   Kevin Jennings

[Altera_Forum]

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?

[Altera_Forum]

--- 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

[Altera_Forum]

ok ok...got you kevin...and yes thanks a lot..