Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST


Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | Spartan-6 hold time problems (multipost to Xilinx forums)

There are 3 messages in this thread.

You are currently looking at messages 0 to 3.

Spartan-6 hold time problems (multipost to Xilinx forums) - Rob Gaddi - 2010-06-02 19:12:00

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



Re: Spartan-6 hold time problems (multipost to Xilinx forums) - John McCaskill - 2010-06-02 21:07:00

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
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: Spartan-6 hold time problems (multipost to Xilinx forums) - maxascent - 2010-06-03 03:53:00

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