View Single Post
  #3 (permalink)  
Old 11-22-2005, 07:32 PM
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...


[email protected] wrote:
> johnp wrote:
> > I'm working on a high speed design in a Xilinx V2Pro and I'm running
> > into a timing
> > problem. Instead of packing logic into LUTs, XST wants to use the
> > Enable
> > signal in the CLB. To use the Enable, it needs to use an extra LUT to
> > create
> > the Enable signal, so I get routing delays and an extra CLB delay.
> >
> > Here's some sample code:
> >
> > req [3:0] sig4;
> > wire [3:0] sig3;
> >
> > always @(posedge clk)
> > if (sig1 & ~sig2)
> > sig4 <= sig3;
> >
> > Xilinx could fit this into 4 CLBs total by simply using the 4 LUTs and
> > the 4 flip-flops.
> > Each LUT would handle one bit of sig4.
> >
> > Instead, XST uses a LUT to create (sig1 & ~sig2), then feeds that
> > output to the
> > Enable pins on 4 flip-flops. I now get the delay through the LUT and
> > routing delays
> > to my flip-flops.
> >
> > Any way to tell XST to not use the Enable signal and force it to use
> > the LUTs for
> > this section of logic?

>
>
> Your coding style exactly matches the template for clock enable
> synthesis:
>
> always @(posedge clk)
> if (condition)
> sig4 <= sig3;
>
> You can work around this by coding the 'no change' action as an
> explicit feedback, as follows:
>
> always @(posedge clk)
> sig4 <= (sig1 & ~sig2) ? sig3 : sig4;
>
>
> (There really should be an attribute to support this.)
>
> Regards,
> Allan


Another approach could be to pipeline the (sig1 & ~sig2) calculation,
so the enable path doesn't need to pass through a LUT. (You may need
to make other changes to get the logic correct.)

Regards,
Allan

Reply With Quote