SRL as a synchroniser

[Allan Herriman]

Hi,

At a client's site I have some legacy VHDL code that is being synthesised
with Xilinx XST 13.1 with Virtex 6 as a target.

This code has some clock domain crossing circuits that use two flip flops
cascaded in the destination clock domain (it's the usual synchroniser
that you've all seen before).

This code worked fine in whatever version of XST it was originally
written for, but with 13.1 I find that these flip flops are being
replaced by SRL32 primitives, the default inference rule being that
whenever XST sees two or more flip flops (without a reset and with the
same control inputs) in series, it replaces them with an SRL.

Obviously, the XST team thought that this was an appropriate thing to do,
but anyone with a modicum of experience should know better.


Question: just how bad are the SRL for this application? Have they even
been characterised?


BTW, there are many possible fixes:

- Put an attribute (SHREG_something_or_other) on each and every
synchroniser to disable SRL inference.

- Disable SRL inference globally (not good).

- Change the XST setting (SHREG_something_else) to 3 so that chains of 2
flip flops are left alone.

- Add a reset (or other control signal that will stop SRL inference) to
each and every synchroniser in the design.

- Wait for XST to be fixed (but don't hold your breath).


Thanks,
Allan

 

[AleĹĄ Svetek]

On 22/03/2011 13:27, Allan Herriman wrote:

Hi,

At a client's site I have some legacy VHDL code that is being synthesised
with Xilinx XST 13.1 with Virtex 6 as a target.

This code has some clock domain crossing circuits that use two flip flops
cascaded in the destination clock domain (it's the usual synchroniser
that you've all seen before).

This code worked fine in whatever version of XST it was originally
written for, but with 13.1 I find that these flip flops are being
replaced by SRL32 primitives, the default inference rule being that
whenever XST sees two or more flip flops (without a reset and with the
same control inputs) in series, it replaces them with an SRL.

Obviously, the XST team thought that this was an appropriate thing to do,
but anyone with a modicum of experience should know better.


Question: just how bad are the SRL for this application? Have they even
been characterised?

Exactly the same question was asked quite some time ago (7 years). You
can read the discussion at:

http://www.fpgarelated.com/usenet/fpga/show/4224-1.php


Also, Austin Lesea (Principal Engineer at Xilinx) said:

"The SR16 is not a chain of master slave flip flops, so their
metastability resolution is not going to very good at all. In fact,
they may be exactly the wrong choice to use as asynchronous signal
synchronizers!"

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/e7148c35e7313032/b7e62b1e636df590?q=avoid+metastability+austin&lnk=nl&#

So, I would conclude that for clock-domain crossing one should avoid
using SRLs and use fabric flip-flops placed relatively closely together.

Regards,
~ Ales

 

[Muzaffer Kal]

On 22 Mar 2011 12:27:10 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

Question: just how bad are the SRL for this application? Have they even
been characterised?

As far as I understand SRL is made from a small block of SRAM which

exists for the LUT so it would be a rather poor synchronizer. A series
of closely packed DFFs are best for synchronization.

BTW, there are many possible fixes:

- Put an attribute (SHREG_something_or_other) on each and every
synchroniser to disable SRL inference.

- Disable SRL inference globally (not good).

- Change the XST setting (SHREG_something_else) to 3 so that chains of 2
flip flops are left alone.

- Add a reset (or other control signal that will stop SRL inference) to
each and every synchroniser in the design.

- Wait for XST to be fixed (but don't hold your breath).

I am a heavy user of X parts but I would never go with the last
choice. Individual attributes or reset are the best options in my
opinion.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

 

[rickman]

On Mar 22, 8:27 am, Allan Herriman <allanherri...@hotmail.com> wrote:

Hi,

At a client's site I have some legacy VHDL code that is being synthesised
with Xilinx XST 13.1 with Virtex 6 as a target.

This code has some clock domain crossing circuits that use two flip flops
cascaded in the destination clock domain (it's the usual synchroniser
that you've all seen before).

This code worked fine in whatever version of XST it was originally
written for, but with 13.1 I find that these flip flops are being
replaced by SRL32 primitives, the default inference rule being that
whenever XST sees two or more flip flops (without a reset and with the
same control inputs) in series, it replaces them with an SRL.

Obviously, the XST team thought that this was an appropriate thing to do,
but anyone with a modicum of experience should know better.

Question: just how bad are the SRL for this application?  Have they even
been characterised?

BTW, there are many possible fixes:

- Put an attribute (SHREG_something_or_other) on each and every
synchroniser to disable SRL inference.

- Disable SRL inference globally (not good).

- Change the XST setting (SHREG_something_else) to 3 so that chains of 2
flip flops are left alone.

- Add a reset (or other control signal that will stop SRL inference) to
each and every synchroniser in the design.

- Wait for XST to be fixed (but don't hold your breath).

Interesting. I just had a conversation about synchronizing across
clock domains and I recalled being told by some knowledgeable folks
from Xilinx that with "modern" FPGAs (this was maybe 7 years ago) the
gain-bandwidth product of the buffer was high enough that even running
with data and clock running at 100 MHz the MTTF would be in the ball
park of a million years.. or was it a billion years?

The FFs were intentionally designed to minimize issues with clock
domain crossing. I have no idea if the SRLs are good for this at all
really. I'm pretty sure they are a very different design optimized
for minimum die size. I would say, talk to Xilinx... or add the
resets.

Rick

 

[Hal Murray]

In article <4d88959e$0$11105$c3e8da3@news.astraweb.com>,
Allan Herriman <allanherriman@hotmail.com> writes:

This code has some clock domain crossing circuits that use two flip flops
cascaded in the destination clock domain (it's the usual synchroniser
that you've all seen before).

This code worked fine in whatever version of XST it was originally
written for, but with 13.1 I find that these flip flops are being
replaced by SRL32 primitives, the default inference rule being that
whenever XST sees two or more flip flops (without a reset and with the
same control inputs) in series, it replaces them with an SRL.

Good catch. How did you notice it?

BTW, there are many possible fixes:

- Put an attribute (SHREG_something_or_other) on each and every
synchroniser to disable SRL inference.

Can you kill two birds with one stone by requiring timing that
the SRLs can't meet? That would also constrain the FFs to be
close together so you didn't use up all the slack time routing
across the chip.

--
These are my opinions, not necessarily my employer's. I hate spam.

 

[Allan Herriman]

On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:

Hi,

At a client's site I have some legacy VHDL code that is being
synthesised with Xilinx XST 13.1 with Virtex 6 as a target.

This code has some clock domain crossing circuits that use two flip
flops cascaded in the destination clock domain (it's the usual
synchroniser that you've all seen before).

This code worked fine in whatever version of XST it was originally
written for, but with 13.1 I find that these flip flops are being
replaced by SRL32 primitives, the default inference rule being that
whenever XST sees two or more flip flops (without a reset and with the
same control inputs) in series, it replaces them with an SRL.

Obviously, the XST team thought that this was an appropriate thing to
do, but anyone with a modicum of experience should know better.


Question: just how bad are the SRL for this application? Have they even
been characterised?


BTW, there are many possible fixes:

- Put an attribute (SHREG_something_or_other) on each and every
synchroniser to disable SRL inference.

- Disable SRL inference globally (not good).

- Change the XST setting (SHREG_something_else) to 3 so that chains of 2
flip flops are left alone.

- Add a reset (or other control signal that will stop SRL inference) to
each and every synchroniser in the design.

- Wait for XST to be fixed (but don't hold your breath).

The relevant attributes are:


SHREG_EXTRACT (yes/no) applies to signals or entities (in HDL source) or
globally (as an XST option).

SHREG_MIN_SIZE (default of 2) global XST option. This defines the
smallest number of flip flops in a chain that will be converted to SRL.

(I consider the default SHREG_MIN_SIZE value of 2 to be low for a target
that has four flip flops for every SRL, but perhaps it has more to do
with the routing than the logic.)


The fix I applied to the client's design was to put the SHREG_EXTRACT
attribute on every synchroniser flip flop. This required more code
changes than I would have liked, because many of the flip flops were
inferred from variables, and XST doesn't allow the attribute to be
applied to variables, only signals.


The problem was discovered by a co-worker (hi Adrian!) during a review of
the tool report files.


The long term fix (for us) involves two steps:

1. Modify the in-house coding standard to require that those attributes
be used on synchronising flip flops in the HDL source.

2. Add an automated check of the extracted gate-level netlist that will
be run at the end of our (fully scripted) build process which will
identify and warn of SRLs being used inappropriately.


Regards,
Allan

 

[RCIngham]

On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:
[elided]

The long term fix (for us) involves two steps:

1. Modify the in-house coding standard to require that those attributes
be used on synchronising flip flops in the HDL source.

2. Add an automated check of the extracted gate-level netlist that will
be run at the end of our (fully scripted) build process which will
identify and warn of SRLs being used inappropriately.


Regards,
Allan

As I am concerned that this is happening to our designs, I had a trawl o
the Xilinx web-site, and found the following:
http://www.xilinx.com/support/answers/35967.htm

Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it!



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Gabor]

On Thursday, March 24, 2011 7:27:14 AM UTC-4, RCIngham wrote:

On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:
[elided]

The long term fix (for us) involves two steps:

1. Modify the in-house coding standard to require that those attributes
be used on synchronising flip flops in the HDL source.

2. Add an automated check of the extracted gate-level netlist that will
be run at the end of our (fully scripted) build process which will
identify and warn of SRLs being used inappropriately.


Regards,
Allan

As I am concerned that this is happening to our designs, I had a trawl on
the Xilinx web-site, and found the following:
http://www.xilinx.com/support/answers/35967.htm

Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it!



---------------------------------------
Posted through http://www.FPGARelated.com

My code generally has a reset term for everything
whether it needs one or not. I only leave out the
reset if I explicitly want to generate SRL-based
shift registers. Neither XST nor Map can use
an SRL when the register needs a reset.

-- Gabor