FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-22-2005, 07:19 PM
johnp
Guest
 
Posts: n/a
Default 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

Reply With Quote
  #2 (permalink)  
Old 11-22-2005, 07:26 PM
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

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

Reply With Quote
  #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
  #4 (permalink)  
Old 11-22-2005, 07:37 PM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...


"johnp" <[email protected]> schrieb im Newsbeitrag
news:[email protected] ps.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












Reply With Quote
  #5 (permalink)  
Old 11-22-2005, 09:46 PM
John_H
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

"Antti Lukats" <[email protected]> wrote in message
news:[email protected]
>
> "johnp" <[email protected]> schrieb im Newsbeitrag
> news:[email protected] ps.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.


Reply With Quote
  #6 (permalink)  
Old 11-22-2005, 11:53 PM
Antti Lukats
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

"John_H" <[email protected]> schrieb im Newsbeitrag
news:[email protected]
> "Antti Lukats" <[email protected]> wrote in message
> news:[email protected]
>>
>> "johnp" <[email protected]> schrieb im Newsbeitrag
>> news:[email protected] ps.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

































Reply With Quote
  #7 (permalink)  
Old 11-23-2005, 12:22 AM
johnp
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

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

Reply With Quote
  #8 (permalink)  
Old 11-23-2005, 01:20 AM
Duane Clark
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

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.

Reply With Quote
  #9 (permalink)  
Old 11-23-2005, 02:57 AM
JustJohn
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

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;

Reply With Quote
  #10 (permalink)  
Old 11-23-2005, 04:16 AM
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

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.

Reply With Quote
  #11 (permalink)  
Old 11-23-2005, 04:25 AM
johnp
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

Since my 'sig3' vector is four bits wide, the signal from the CE logic
needs to
fan out to the 4 flip flops. Now we get routing delay.

Antti's example may be correct, but for the 4 bit wide destination, I
think
I get a performance penalty.

I love synthesis, but... It sure would be nice to have any easier way
to
direct it! In any event, it sure beats schematics.

John Providenza

Reply With Quote
  #12 (permalink)  
Old 11-23-2005, 08:59 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Disabling Xilinx clock enable usage...

johnp wrote:

> I love synthesis, but... It sure would be nice to have any easier way
> to direct it! In any event, it sure beats schematics.


It not only beats them, It draws them for me:
http://home.comcast.net/~mike_treseler/uart.pdf

-- Mike Treseler
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
clock domain : DDR read enable Ibrahim Magdy FPGA 0 06-19-2005 10:13 AM
Partial Reconfiguration clock enable problem Florian FPGA 0 06-03-2004 12:07 PM
Chipscope with clock enable. Symon FPGA 0 05-19-2004 08:12 PM


All times are GMT +1. The time now is 06:35 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved