Disabling Xilinx clock enable usage...

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?

Thanks!

John Providenza

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

allanherri...@hotmail.com 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

"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
news:1132683556.070517.8010@g44g2000cwa.googlegroups.com...
> 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?
>
> Thanks!
>
> John Providenza
>

Hi John,

in your example XST does exactly what it should do given your code.

if you want the synthesis to avoid using clock enable then you should 
rewrite your code

antti

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dlvoi7$5kq$1@online.de...
>
> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
> news:1132683556.070517.8010@g44g2000cwa.googlegroups.com...
>> 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?
>>
>> Thanks!
>>
>> John Providenza
>>
>
> Hi John,
>
> in your example XST does exactly what it should do given your code.
>
> if you want the synthesis to avoid using clock enable then you should 
> rewrite your code
>
> antti

I would respectfully disagree.

A decent synthesizer should *not* produce an extra level of logic with an 
actual increase in area unless - and it's hard to see this as the case - the 
extra fanout for a heavily loaded signal causes timing problems elsewhere in 
the design.

In a properly constrained design, a decent synthesizer should *not* produce 
logic that violates the timing constraints if there's an available solution 
that meets the timing.  Unfortunately we have to spend much of our time 
tuning things manually to get the "obvious" to happen. 

"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag 
news:ZsLgf.36$LT5.98@news-west.eli.net...
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dlvoi7$5kq$1@online.de...
>>
>> "johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
>> news:1132683556.070517.8010@g44g2000cwa.googlegroups.com...
>>> 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?
>>>
>>> Thanks!
>>>
>>> John Providenza
>>>
>>
>> Hi John,
>>
>> in your example XST does exactly what it should do given your code.
>>
>> if you want the synthesis to avoid using clock enable then you should 
>> rewrite your code
>>
>> antti
>
> I would respectfully disagree.
>
> A decent synthesizer should *not* produce an extra level of logic with an 
> actual increase in area unless - and it's hard to see this as the case - 
> the extra fanout for a heavily loaded signal causes timing problems 
> elsewhere in the design.
>
> In a properly constrained design, a decent synthesizer should *not* 
> produce logic that violates the timing constraints if there's an available 
> solution that meets the timing.  Unfortunately we have to spend much of 
> our time tuning things manually to get the "obvious" to happen.

Dear John (and John),

I am glad to see someone to disagree with me once in a while, but the issue 
isnt that simple

the way XST does synthesize the example in the original posting DOES NOT add 
extra delay
and is in most cases the most effective coding. The flip flops are feed 
either by direct connect
bypassing the LUT in their slices, or from feeding logic that is packed into 
the slice where
the FF is, in what case the delay before the FF is absolutly minimal (LUT to 
FF in same slice).
In most cases the timing delays in clock enable and data path will somewhat 
overlay and
cancel out a bit from timing budget so the clock enable version would be 
faster, that is
implementing the clock enable emulation in the D input would make one delay 
path longer
and overall timing worse.

OTOH in some cases the no clock enable version may yield to better overall
timing depending where the critical path is, but here my bet is that there 
is no
"decent" synthesizer that would optimize the clock enable out from the 
sample
code based on critical path analyze alone. It would be possible, yes - but I 
would
be surprised to see some synthesis tool to actually do that without explicit
coding or constraining. Hm, maybe am wrong and some synthesis tool is
as smart already :)

I do AGREE that the syntesis tools do not the best and in cases where
solution to meet timing is available, that solution is not used 
automatically
and needs manual 'tuning'.

Antti

All -

Of course, I realize that my code sample REALLY wants to map to the
Enable pin:
always @(posedge clk)
    if (condition)
        sig4 <= sig3;

The suggestion to recode the Verilog to look like:
always @(posedge clk)
    sig4 <= (sig1 & ~sig2) ? sig3 : sig4;

concerns me since a smart synthesizer would recognize this to be
EXACTLY
the sime code, just written in an odd way.

The safest approach (which I've change to) is to add another level of
pipelining.

It just seems sad that even when the LUTs are available, the
synthesizer put
in an extra logic level so it could use the Enable pin.

BTW, this is with XST 6.2.03.  It could be that the newer versions are
better.

John Providenza

johnp wrote:
> All -
> 
> Of course, I realize that my code sample REALLY wants to map to the
> Enable pin:
> always @(posedge clk)
>     if (condition)
>         sig4 <= sig3;
> 
> The suggestion to recode the Verilog to look like:
> always @(posedge clk)
>     sig4 <= (sig1 & ~sig2) ? sig3 : sig4;
> 
> concerns me since a smart synthesizer would recognize this to be
> EXACTLY the sime code, just written in an odd way.

That would require that the synthesis tool specifically look for the 
default value on the right be the same signal as is being assigned to. 
While I suppose it is possible that a synthesis tool might do that, I 
kind of doubt it. That would seem to me to require that the tool 
designer deliberately coded the tool to de-optimize (is that a word ;) 
the code.

Duane wrote:
> johnp wrote:
>> The suggestion to recode the Verilog to look like:
>> always @(posedge clk)
>>     sig4 <= (sig1 & ~sig2) ? sig3 : sig4;
>>
>> concerns me since a smart synthesizer would recognize this to be
>> EXACTLY the sime code, just written in an odd way.
>That would require that the synthesis tool specifically look for the
>default value on the right be the same signal as is being assigned to.
>While I suppose it is possible that a synthesis tool might do that, I
>kind of doubt it.

I'd bet it would. I am continually amazed at how good the synthesis
optimizers are getting.

OP can probably force the results he's asking for by using a 'keep'
attribute, if he really wants to. I don't know how to express it in
Verilog, but the VHDL code follows. See 'KEEP' in the constraints guide
for Verilog syntax.

I couldn't resist on this one, had to do the experiment, and Antti is
100% right in this instance. P/R into an XC2V40-5 with CE logic in the
same LUT along with the CE MUX gives _slower_ results than putting only
the CE logic into a LUT and using the CE pin and and its built-in CE
MUX:

Using CE pin: under 2 ns.
Using LUT :   over 2 ns.

An odd thing is that XST infers 2 FFs for the LUT version.
(Did someone say pushing a rope?)

Nice that the synthesis tools keep getting better, and there are less
opportunities to second guess them.

Regards,
John

entity CE_Inferral is
    Port ( clk   : in std_logic;
           rst   : in std_logic;
           a_in  : in std_logic;
           b_in  : in std_logic;
           c_in  : in std_logic;
           q_out : out std_logic);
end CE_Inferral;

architecture Behavioral of CE_Inferral is
signal  q       : std_logic;
signal  a       : std_logic;
signal  b       : std_logic;
signal  c       : std_logic;
signal  d_lut   : std_logic;
attribute keep  : string;
attribute keep  of d_lut  : signal  is "true";
begin
q_out <= q;
--d_lut <= c  when a = '1' and b = '0' -- Uncomment these two lines
--    else q;           -- for 'CE' in LUT logic (slower)
process( clk )
begin
  if RISING_EDGE( clk ) then
    a <= a_in;  -- sync port inputs
    b <= b_in;
    c <= c_in;
    if rst = '1' then
      q <= '0';
    else
--      q <= d_lut; -- Uncomment this 1 line for 'CE' in LUT logic
      if a = '1' and b = '0' then -- Uncomment these 3 lines
        q <= c;     --  to use CE pin on FF with only
       end if;        -- 'a and not b' function in a LUT
  end if; end if;
end process;
end Behavioral;

JustJohn wrote:
> Duane wrote:
> > johnp wrote:
> >> The suggestion to recode the Verilog to look like:
> >> always @(posedge clk)
> >>     sig4 <= (sig1 & ~sig2) ? sig3 : sig4;
> >>
> >> concerns me since a smart synthesizer would recognize this to be
> >> EXACTLY the sime code, just written in an odd way.
> >That would require that the synthesis tool specifically look for the
> >default value on the right be the same signal as is being assigned to.
> >While I suppose it is possible that a synthesis tool might do that, I
> >kind of doubt it.
>
> I'd bet it would. I am continually amazed at how good the synthesis
> optimizers are getting.

The OP is using XST 6.2.03.  It's not that smart.

Regards,
Allan.