I'm using XST for synthesis and I'm seeing an odd timing failure from PAR with a 19 bit counter. The counter code is:
reg [19:1] rd_addr; // read port wire [19:1] rd_addr_preload;
// handle ram address counter assign rd_addr_preload = (repeat_done) ? next_wave_addr : cur_wave_addr ; always @(posedge clk_mem) if (next_instr) rd_addr
Well, with the structure the Virtex CLBs, a loadable counter implemented in one level of logic has the carry chain after the mux. The timing analysis does not take into account logic state, only combinatorial paths. In the case of the loadable counter, it sees a path out of the LUT and up the carry chain. Normally, the loadable counter uses the mult_and to gate off the DI input of the mux_carry when the counter is being loaded so that a carry does not propagate, but the timing analyzer has no way of knowing this without your help. You can either do what you can to reduce the delay on the load path so it meets timing without regard to false paths, or you can declare this as a false path. My preference is to try to make it pass without declaring false paths because of the danger of inadvertently marking a valid path as false.
John Providenza wrote:
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Indeed, be careful with declaring false paths I noticed the clock skew was quite high(!) at 113ps. Does the carry chain straddle different bits of the clock tree? You could try locking it down to reduce the skew. You only need 8ps! Or, you could tell the timing analyser your worst case temperature and power supply voltage to get back the 8ps. good luck, Syms.
All -
Thanks for your comments on my problem.
I'm also a bit worried about using false paths, but I think this one *might* be safe:
NET "upatgen/*_inst_cy_*" TPTHRU = "thru_carry"; TIMESPEC "TS_seq_rd_addr" = FROM RAMS(upatgen/seq_rd_data) THRU "thru_carry" TO FFS (upatgen/rd_addr) 10ns;
I'm a bit worried that this could be toooo agressive, is there a way to to restrict this specifically to the COUT/CIN pins?
John P
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.