by grouped properly you mean that the logic blocks that were being used to make up the combinatorial block were required to be in close proximity right?
All logic is timed register to register. So none of the code was combinatorial. It was all synchronous - but this compiles to register -> comb logic -> register. The proximity thing is making sure an etire entity (or multiple entities) are grouped in the same part of the chip. In altera these are called LogicLock regions.
since the timing analysis is carried out using a highly pessimistic scenario, if timing was failing in ps, shouldn't it be possible to ignore them?
have you had to do a design where the design was constrained to both clock edges i.e positive edge and also negative edge caused data to be latched?
No, the whole design was a single rising_edge clock.
false paths would be, reset input or any signal that only occurs like once at the start of the design power-up, clock crossing paths where we have put clock crossing bridges, and any other asynchronous input for which we have put in a register chain. Are there some other false paths
False paths are rare, but are usually for clock domain crossing (but you really should be using max delays for these). Some of them were for impossible logic combinations.
You should NEVER have an async input in a register chain. You risk meta-stable register output.
usually the data is latched at the next positive edge from the current positive edge of clk which is called launch edge, if this relationship of launch and latch edges is not intentionally held true in our design then we must add multi cycle path. have you had to use this often? when we add multi-cycle path constraint and then synthesize the design, will the fitter try to fit the design such that the delay from launch to latch register becomes as exactly much as given in the multi-cycle constraint (even if it can fit the design with less delay?)
wow, this is so awesome !
You dont have to use multi cycle paths. You can use them when you have a periodic clock enable (say it is high one in every N clocks)
This way you know that the data wont be latched until N clocks after the current clock edge, hence the multi cycle relationship
so the usual way to specify these would
set_multi_cycle_path -from *my_multicycle_regs* -to *my_multicycle_regs* N
- - - Updated - - -
All SDC constraints should be used by the fitter and timing analyser. In qaurtus (at least) you can add tcl to your SDC file, so you can set constraints only to the fitter (for examples, we had some max delays that were an overconstraint of the clock, so that they should pass timing when it came to the actually timing analysis).