Spartan-6 hold time problems (multipost to Xilinx forums)
in [FPGA]
|
From: Rob Gaddi on 2 Jun 2010 19:12 I've got a Spartan-6 design with two different clocks. They're generated from the same 20 MHz reference on two PLLs, and are called WB_SYS.CLK_I (50 MHz) and clk128. They're treated as entirely asynchronous by the design logic, and data passing between them is safe by design, and so in order to get rid of the slew of timing errors thrown by MAP I've added the following to my UCF: ============================================================= NET "WB_SYS.CLK_I" TNM_NET = FFS "BUS_FLOPS"; NET "clk128" TNM_NET = FFS "FAST_FLOPS"; TIMESPEC "TS_ASYNC1" = FROM "BUS_FLOPS" TO "FAST_FLOPS" TIG; TIMESPEC "TS_ASYNC2" = FROM "FAST_FLOPS" TO "BUS_FLOPS" TIG; ============================================================= When I try to map this design, I'm getting two different, but possibly related, batches of timing errors. I've got a whole mess like this first one, which always represents a hold violation from a flop output to the address input of a LUTRAM, both on the same clock. ============================================================= Slack (hold path): -0.152ns (requirement - (clock path skew + uncertainty - data path)) Source: M68K_BRIDGE/WB_OUT.ADDR_2 (FF) Destination: CHANNEL/CHANS[4].CHAN_ON.CHAN/FIFO_FLT/Mram_ram_k_lo12/DP (RAM) Requirement: 0.000ns Data Path Delay: -0.152ns (Levels of Logic = 0) Positive Clock Path Skew: 0.000ns Source Clock: WB_SYS.CLK_I rising at 20.000ns Destination Clock: WB_SYS.CLK_I rising at 20.000ns Clock Uncertainty: 0.000ns ============================================================= The second is a batch of setup violations located inside of the instantiated asynchronous FIFO cores. These are a bunch of copies of a CoreGen, specifically "Fifo_Generator family Xilinx,_Inc. 5.3". I'm not enough of a masochist to try to roll my own asynch FIFO after all of Peter's warnings. The violation is in going across the clock boundary; I had assumed that the TIG should have taken care of these. ============================================================= Slack: -2.172ns (requirement - (data path - clock path skew + uncertainty)) Source: CHANNEL/ltrigmux_1 (FF) Destination: CHANNEL/CHANS[1].CHAN_ON.CHAN/FIFO/FIFO/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[0].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram (RAM) Requirement: 0.312ns Data Path Delay: 1.690ns (Levels of Logic = 2)(Component delays alone exceeds constraint) Clock Path Skew: -0.094ns (1.519 - 1.613) Source Clock: WB_SYS.CLK_I rising at 320.000ns Destination Clock: clk128 rising at 320.312ns Clock Uncertainty: 0.700ns Clock Uncertainty: 0.700ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.489ns Phase Error (PE): 0.453ns ============================================================= I've tried this design out under both ISE 11.5 and 12.1 with the same results. Anyone have any ideas on one/both of these problems? -- Rob Gaddi, Highland Technology Email address is currently out of order
From: John McCaskill on 2 Jun 2010 21:07 On Jun 2, 6:12 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > I've got a Spartan-6 design with two different clocks. They're > generated from the same 20 MHz reference on two PLLs, and are called > WB_SYS.CLK_I (50 MHz) and clk128. They're treated as entirely > asynchronous by the design logic, and data passing between them is safe > by design, and so in order to get rid of the slew of timing errors > thrown by MAP I've added the following to my UCF: > > ============================================================= > NET "WB_SYS.CLK_I" TNM_NET = FFS "BUS_FLOPS"; > NET "clk128" TNM_NET = FFS "FAST_FLOPS"; > TIMESPEC "TS_ASYNC1" = FROM "BUS_FLOPS" TO "FAST_FLOPS" TIG; > TIMESPEC "TS_ASYNC2" = FROM "FAST_FLOPS" TO "BUS_FLOPS" TIG; > ============================================================= > > When I try to map this design, I'm getting two different, but possibly > related, batches of timing errors. I've got a whole mess like this > first one, which always represents a hold violation from a flop output > to the address input of a LUTRAM, both on the same clock. > > ============================================================= > Slack (hold path): -0.152ns (requirement - (clock path skew + > uncertainty - data path)) > Source: M68K_BRIDGE/WB_OUT.ADDR_2 (FF) > Destination: > CHANNEL/CHANS[4].CHAN_ON.CHAN/FIFO_FLT/Mram_ram_k_lo12/DP (RAM) > Requirement: 0.000ns > Data Path Delay: -0.152ns (Levels of Logic = 0) > Positive Clock Path Skew: 0.000ns > Source Clock: WB_SYS.CLK_I rising at 20.000ns > Destination Clock: WB_SYS.CLK_I rising at 20.000ns > Clock Uncertainty: 0.000ns > ============================================================= > > The second is a batch of setup violations located inside of the > instantiated asynchronous FIFO cores. These are a bunch of copies of a > CoreGen, specifically "Fifo_Generator family Xilinx,_Inc. 5.3". I'm not > enough of a masochist to try to roll my own asynch FIFO after all of > Peter's warnings. The violation is in going across the clock boundary; > I had assumed that the TIG should have taken care of these. > > ============================================================= > Slack: -2.172ns (requirement - (data path - clock path > skew + uncertainty)) > Source: CHANNEL/ltrigmux_1 (FF) > Destination: > CHANNEL/CHANS[1].CHAN_ON.CHAN/FIFO/FIFO/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[0].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram > (RAM) > Requirement: 0.312ns > Data Path Delay: 1.690ns (Levels of Logic = 2)(Component delays > alone exceeds constraint) > Clock Path Skew: -0.094ns (1.519 - 1.613) > Source Clock: WB_SYS.CLK_I rising at 320.000ns > Destination Clock: clk128 rising at 320.312ns > Clock Uncertainty: 0.700ns > > Clock Uncertainty: 0.700ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE > Total System Jitter (TSJ): 0.070ns > Discrete Jitter (DJ): 0.489ns > Phase Error (PE): 0.453ns > ============================================================= > > I've tried this design out under both ISE 11.5 and 12.1 with the same > results. Anyone have any ideas on one/both of these problems? > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Hello Rob, Your second issue is because you only put the FFS into your time groups that you TIG. Put RAMS in the time groups as well to get rid of that. Regards, John McCaskill www.FasterTechnology.com
From: maxascent on 3 Jun 2010 03:53 If you look in the fifo user guide I believe it gives you some ucf constraints to use when using async fifos. Also its not quite as hard as you think to create an async fifo. Jon --------------------------------------- Posted through http://www.FPGARelated.com
|
Pages: 1 Prev: How good are Actel tools Next: Spartan6 power consumption |