There are 3 messages in this thread.
You are currently looking at messages 0 to 3.
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
On Jun 2, 6:12=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > I've got a Spartan-6 design with two different clocks. =A0They're > generated from the same 20 MHz reference on two PLLs, and are called > WB_SYS.CLK_I (50 MHz) and clk128. =A0They'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: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NET "WB_SYS.CLK_I" TNM_NET =3D FFS "BUS_FLOPS"; > NET "clk128" TNM_NET =3D FFS "FAST_FLOPS"; > TIMESPEC "TS_ASYNC1" =3D FROM "BUS_FLOPS" TO "FAST_FLOPS" TIG; > TIMESPEC "TS_ASYNC2" =3D FROM "FAST_FLOPS" TO "BUS_FLOPS" TIG; > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > When I try to map this design, I'm getting two different, but possibly > related, batches of timing errors. =A0I'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. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Slack (hold path): =A0 =A0 =A0-0.152ns (requirement - (clock path skew + > uncertainty - data path)) > =A0 =A0Source: =A0 =A0 =A0 =A0 =A0 =A0 =A0 M68K_BRIDGE/WB_OUT.ADDR_2 (FF) > =A0 =A0Destination: > CHANNEL/CHANS[4].CHAN_ON.CHAN/FIFO_FLT/Mram_ram_k_lo12/DP (RAM) > =A0 =A0Requirement: =A0 =A0 =A0 =A0 =A00.000ns > =A0 =A0Data Path Delay: =A0 =A0 =A0-0.152ns (Levels of Logic =3D 0) > =A0 =A0Positive Clock Path Skew: 0.000ns > =A0 =A0Source Clock: =A0 =A0 =A0 =A0 WB_SYS.CLK_I rising at 20.000ns > =A0 =A0Destination Clock: =A0 =A0WB_SYS.CLK_I rising at 20.000ns > =A0 =A0Clock Uncertainty: =A0 =A00.000ns > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The second is a batch of setup violations located inside of the > instantiated asynchronous FIFO cores. =A0These are a bunch of copies of a > CoreGen, specifically "Fifo_Generator family Xilinx,_Inc. 5.3". =A0I'm no= t > enough of a masochist to try to roll my own asynch FIFO after all of > Peter's warnings. =A0The violation is in going across the clock boundary; > I had assumed that the TIG should have taken care of these. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Slack: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-2.172ns (requirement - (data p= ath - clock path > skew + uncertainty)) > =A0 =A0Source: =A0 =A0 =A0 =A0 =A0 =A0 =A0 CHANNEL/ltrigmux_1 (FF) > =A0 =A0Destination: > 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.S= IMPLE_PRIM18.ram > (RAM) > =A0 =A0Requirement: =A0 =A0 =A0 =A0 =A00.312ns > =A0 =A0Data Path Delay: =A0 =A0 =A01.690ns (Levels of Logic =3D 2)(Compon= ent delays > alone exceeds constraint) > =A0 =A0Clock Path Skew: =A0 =A0 =A0-0.094ns (1.519 - 1.613) > =A0 =A0Source Clock: =A0 =A0 =A0 =A0 WB_SYS.CLK_I rising at 320.000ns > =A0 =A0Destination Clock: =A0 =A0clk128 rising at 320.312ns > =A0 =A0Clock Uncertainty: =A0 =A00.700ns > > =A0 =A0Clock Uncertainty: =A0 =A0 =A0 =A0 =A00.700ns =A0((TSJ^2 + DJ^2)^1= /2) / 2 + PE > =A0 =A0 =A0Total System Jitter (TSJ): =A00.070ns > =A0 =A0 =A0Discrete Jitter (DJ): =A0 =A0 =A0 0.489ns > =A0 =A0 =A0Phase Error (PE): =A0 =A0 =A0 =A0 =A0 0.453ns > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I've tried this design out under both ISE 11.5 and 12.1 with the same > results. =A0Anyone 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______________________________
If you look in the fifo user guide I believe it gives you some ucfconstraints to use when using async fifos. Also its not quite as hard asyou think to create an async fifo. Jon --------------------------------------- Posted through http://www.FPGARelated.com