Replacing xilinx "ASYNC_REG" directive with a TCL script method.

[Edward Fisher]

Hi all,

The Xilinx tools allow an attribute called "ASYNC_REG" to be applied to FFs to constrain their placement for clock domain crossing synchroniser FFs. The attribute also ensures that various optimisations are not applied to these registers (e.g. register balancing etc).

For a dual flip-flop synchroniser, I could apply the attribute to the two FFs in the VHDL. However the style guide for my current role states that directives are to be avoided (e.g. DONT_TOUCH, KEEP etc) and instead scripts can be used. This is because such directives may not be portable between synthesis tools (Xilinx, Intel, Mentor etc).

Question:
- Assuming that we want to use register balancing (retiming) within the design globally. We need some method to prevent this optimisation being applied to the CDC synchroniser logic. If I can't use the compile directive how could I achieve the same using TCL?

- If the TCL knew the synthesis route, it could select the correct compile time directive and then boot up the relevant tool (Vivado vs Quartus vs Precision). That way in all cases the attribute would match the tool. However, after some digging, I cannot find the Intel equivalent of the Xilinx "ASYNC_REG" attribute.

Many thanks,
Ed

[HT-Lab]

Hi Ed,

I think the reason you can't find it because it is generally know as
register retiming. Quartus QNS has the dont_retime attribute which you
put on your synchroniser FFs.

signal my_reg : std_logic;
attribute dont_retime : boolean;
attribute dont_retime of my_reg : signal is true;

I don't believe there is a universal method (nothing in SDC) to apply
this to the various synthesis tools. There are no checks on attributes
so I can understand why some coding styles wants you to avoid them.

VHDL2018 will have the `define option which allows you to perform
various actions depending on the vendor. For the moment you could use
one of many pre-parsers until VHDL2018 becomes available.

Personally I would use attributes and then before the project completion
purchase a short term CDC tool license and check all your synchronisers.
Getting it right is surprisingly difficult.

Good luck,
Hans
www.ht-lab.com




>
> Many thanks,
> Ed
>

[gtwrek]

In article <d1bbcc17-23ac-4098...@googlegroups.com>,

I don't have a comment specific to your proposal, but rather just a
warning regarding inferring logic with respect to CDC circuits and other
similar strategies - i.e. places where you need to use these types of
attributes in the first place.

Originally, we had the synthesis tool infer our "n-stage" back-to-back
synchronizers. We carefully applieid the ASYNC_REG attribute, as you've
noted. Further reading, we noticed we needed the "KEEP=true" attribute
to prevent synthesis from sharing or otherwise optimizing these
circuits.

As we always had full register retiming on, we decided that the
KEEP_HIERARCHY attribute was needed as well. The SHREG_EXTRACT = "no",
also needed to be added to prevent the inferrence of SRLs (which have
poor metastability performance).

However, after all this when we put a full, and proper CDC checker into
our flows, it was still flagging some errors. Reading more, it looks like we
needed the DIRECT_ENABLE="yes", and DIRECT_RESET="yes" attributes
applied to the module level CE, and RESET ports too.

That reduced or CDC LINT flagging even more,... But not to zero. It
seems that in Vivador, all these attrbutes are mostly taken by the tools
as suggestions only. These last two seem to be the most problematic -
Vivado was consistently optimizing the CE, or, RESET circuitry along
with any of the other upstream synchronous logic, ignoring our directives,
and violating the CDC rules.

In the end, we still have all those attributes, set, but we ended up
just instanciating the proper flip-flop (Vendor, and sometimes product
specific) in our synchronizer module, and hard dont__touching the entire
module.

Your mileage may vary, etc., but that's our findings.

Regards,

Mark

[Allan Herriman]

If your style guide doesn't allow you to use vendor-specific attributes
in your source, you might be able to work around it by creating your own
user-defined attribute (e.g. MY_ASYNC_REG).
You can write code / scripts to scan the compiled netlist for this
attribute, and convert it to whatever vendor-specific attribute is needed
by the vendor's back end tools.

I have done something similar in Vivado to generate complicated timing
constraints that were completely controlled by HDL source, to avoid the
need to keep my HDL and XDC source files aligned.
(I eventually dropped the idea because scanning the database for
attributes using TCL in Vivado kinda sucks and is exceedingly slow.)


BTW, if your style guide actualy stops you from making maintainable
designs (e.g. it requires that you have source and attributes for that
source in separate files), it's time to get a new style guide.


Regards,
Alan

[HT-Lab]

On 16/07/2019 13:15, Allan Herriman wrote:
> On Mon, 15 Jul 2019 07:32:04 -0700, Edward Fisher wrote:

.. snip

>
>
> BTW, if your style guide actualy stops you from making maintainable
> designs (e.g. it requires that you have source and attributes for that
> source in separate files), it's time to get a new style guide.

I suspect he might not have a choice. It would be interested to find out
which coding style he must adhere to, probably some high DAL DO-254
standard style. As I mentioned the problem is that RTL attributes are no
guarantee for the final bitstream. This is one of the reasons most CDC
vendors now offer a gatelevel version as P&R does all sort of clever
stuff to make your design fit and achieve timing closure. Add some
DFT/BIST and you may have a glitch fest.

Every Wilson survey showed that CDC errors are the number 2 reason for
designs failing, given the price of formal CDC tools I believe this will
continue for a long long time.....

Regards,
Hans
www.ht-lab.com

>
> Regards,
> Alan
>