UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor ks0ze
Visitor
13,385 Views
Registered: ‎06-22-2017

Understanding ASYNC_REG attribute

Jump to solution

I've designed a synchronizer to bring a single bit pulse from one clock domain to another. I have set the ASYNC_REG attribute on the destination FFs and the cell properties show ASYNC_REG is checked. Shouldn't this essentially create a "false_path" constraint on the clock crossing and prevent hold time violations, or am I misunderstanding what the attribute was designed to do?

 

ASYNC_REG.png

 

entity CDC is
	port
	(
		-- Async Reset
		RESET		: in	std_logic;
		-- Clock A domain
		CLK_A		: in	std_logic;
		PULSE_A		: in	std_logic;
		-- Clock B domain
		CLK_B		: in	std_logic;
		PULSE_B		: out	std_logic
	);
end CDC;

architecture behavioral of CDC is

signal Q_a				:	std_logic;
signal D_b				:	std_logic_vector(2 downto 0);

attribute ASYNC_REG : string;
attribute ASYNC_REG of Q_a : signal is "TRUE";
attribute ASYNC_REG of D_b : signal is "TRUE";

begin


-- Domain A process
process(CLK_A,RESET)
begin
	if RESET = '1' then
		Q_a <= '0';
	elsif rising_edge(CLK_A) then
		Q_a <= Q_a XOR PULSE_A;
	end if;
end process;

-- Domain B process
process(CLK_B,RESET)
begin
	if RESET = '1' then
		D_b <= (others => '0');
	elsif rising_edge(CLK_B) then
		D_b <= D_b(D_b'LEFT-1 downto 0) & Q_a;
	end if;
end process;

process(CLK_B)
begin
	if rising_edge(CLK_B) then
		PULSE_B <= D_b(D_b'LEFT) XOR D_b(D_b'LEFT-1);
	end if;
end process;
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
20,046 Views
Registered: ‎01-23-2009

Re: Understanding ASYNC_REG attribute

Jump to solution

So, you are using (and understanding) the ASYNC_REG property incorrectly. The ASYNC_REG property is not a timing constraint, it is a placement constraint. It should not be placed on the flip-flop on the source domain, but should be set on the two (or more) flip-flops on the destination domain.

 

The back-to-back flip-flop synchronizer is a mechanism of reducing the probability of a metastable event getting into the main part of your logic. For the metastable event to resolve, you need to give the metastable flip-flop time - there needs to be time between when the first flip-flop goes metastable and the second flip-flop samples it.

 

Without anything else, the tools see this as a "normal" static timing path - therefore the requirement on the path is one clock period of the destination clock. However, if the tools take a significant portion of that for routing, then there is less time for the metastable event to resolve. For any fair of flip-flops that are connected directly to each other (Q to D) that both have ASYNC_REG property set, the placer puts the flip-flops "as close together as possible" in order to minimize the routing between them and hence give as much time to metastability resolution. "As close as possible" means in the same slice, unless there is a conflict in the control set (which there usually shouldn't be).

 

The ASYNC_REG property also does some other things

  - it marks the FFs don't touch (so as not to disrupt their metsatability resolution function)

  - it informs the simulator to not have the outputs go to X (unknown) on a setup/hold violation

  - it is used by report_cdc and report_synchronizer_mtbf as part of the validation and analysis of CDCs

 

The path from the source domain to the destination domain is not affected by the ASYNC_REG property (in fact, no timing analysis is affected) - you still need a timing exception on this path.

 

Avrum

Tags (1)
8 Replies
Highlighted
Historian
Historian
20,047 Views
Registered: ‎01-23-2009

Re: Understanding ASYNC_REG attribute

Jump to solution

So, you are using (and understanding) the ASYNC_REG property incorrectly. The ASYNC_REG property is not a timing constraint, it is a placement constraint. It should not be placed on the flip-flop on the source domain, but should be set on the two (or more) flip-flops on the destination domain.

 

The back-to-back flip-flop synchronizer is a mechanism of reducing the probability of a metastable event getting into the main part of your logic. For the metastable event to resolve, you need to give the metastable flip-flop time - there needs to be time between when the first flip-flop goes metastable and the second flip-flop samples it.

 

Without anything else, the tools see this as a "normal" static timing path - therefore the requirement on the path is one clock period of the destination clock. However, if the tools take a significant portion of that for routing, then there is less time for the metastable event to resolve. For any fair of flip-flops that are connected directly to each other (Q to D) that both have ASYNC_REG property set, the placer puts the flip-flops "as close together as possible" in order to minimize the routing between them and hence give as much time to metastability resolution. "As close as possible" means in the same slice, unless there is a conflict in the control set (which there usually shouldn't be).

 

The ASYNC_REG property also does some other things

  - it marks the FFs don't touch (so as not to disrupt their metsatability resolution function)

  - it informs the simulator to not have the outputs go to X (unknown) on a setup/hold violation

  - it is used by report_cdc and report_synchronizer_mtbf as part of the validation and analysis of CDCs

 

The path from the source domain to the destination domain is not affected by the ASYNC_REG property (in fact, no timing analysis is affected) - you still need a timing exception on this path.

 

Avrum

Tags (1)
Visitor ks0ze
Visitor
13,047 Views
Registered: ‎06-22-2017

Re: Understanding ASYNC_REG attribute

Jump to solution

@avrumw, is there a recommended way to include timing constraints in VHDL source files? In my understanding, using regular expressions for constraints (which would be the case for generic CDC modules) tends to slow down synthesis/implementation, so it seems like there should be a way to scope timing exceptions to a specific component. If you were writing a module to pass a single bit pulse between clock domains how would you handle it?

0 Kudos
Historian
Historian
13,028 Views
Registered: ‎01-23-2009

Re: Understanding ASYNC_REG attribute

Jump to solution

Timing constraints cannot be embedded in RTL code.

 

However, it is possible to write a separate constraint file for a module. This constraint file can be "SCOPED_TO_REF", which means that it will be applied to every instance of the module in the design - regardless of where it exists in the hierarchy. This avoids the use of wildcards to locate cells within a module that is instantiated multiple times. See UG903, there is a section on "Constraints Scoping" (v2017.1 p.65).

 

Avrum

 

 

Tags (1)
Scholar vanmierlo
Scholar
12,718 Views
Registered: ‎06-10-2008

Re: Understanding ASYNC_REG attribute

Jump to solution

I've read the section and it says to use get_files but Vivado complains that get_files is not supported in the xdc constraint file.

0 Kudos
Historian
Historian
12,713 Views
Registered: ‎01-23-2009

Re: Understanding ASYNC_REG attribute

Jump to solution

I've read the section and it says to use get_files but Vivado complains that get_files is not supported in the xdc constraint file.

 

I don't understand your question, and I am not sure if it relates to this thread. If the question is unrelated, please ask it in a new forum post. In either case, you will need to provide more context about what you are asking.

 

Avrum

0 Kudos
Scholar vanmierlo
Scholar
12,698 Views
Registered: ‎06-10-2008

Re: Understanding ASYNC_REG attribute

Jump to solution

@avrumw wrote:

Timing constraints cannot be embedded in RTL code.

 

However, it is possible to write a separate constraint file for a module. This constraint file can be "SCOPED_TO_REF", which means that it will be applied to every instance of the module in the design - regardless of where it exists in the hierarchy. This avoids the use of wildcards to locate cells within a module that is instantiated multiple times. See UG903, there is a section on "Constraints Scoping" (v2017.1 p.65).

 


If timing constraints cannot be embedded in RTL code, then I would assume they must be applied in an XDC constraint file. If you then want to apply a constraint to a single module and every instance of it, the SCOPED_TO_REF seems to be the solution. However it requires [get_files] and that is not supported. So how am I supposed to make this work?

0 Kudos
Historian
Historian
12,686 Views
Registered: ‎01-23-2009

Re: Understanding ASYNC_REG attribute

Jump to solution

The mechanism of doing this is different in project vs. non-project mode. However, in both cases, the we are scoping an XDC file to a particular module. So the first step is to write a separate XDC file containing the constraints and properties you want applied to your module. In this XDC file, the constraints are written as if the module in question is the "top" of the hierarchy.

 

The mechanism of making it scoped is done in how the XDC file is brought into your design.

 

If you are using project mode, then you put the SCOPED_TO_REF property on the XDC file. So if you are using the GUI, after  you add the XDC file to your project, you select that XDC file in the Sources window, then go to the Source File Properties, scroll down to the property "SCOPED_TO_REF" and type in the name of the module to which you want the XDC file applied.

 

If you are using a project mode script, then you do this with the set_property command

 

set_property SCOPED_TO_REF <name_of_module> [get_files <name_of_XDC_file>

 

If you are in non-project mode, then the scoping is done by the read_xdc command you use to read in the XDC file. To use a scoped XDC file you use

 

read_xdc -ref <name_of_module> <name_of_XDC_file>

 

So in neither case does the [get_files ...] occur within the XDC file itself.

 

Avrum

 

 

0 Kudos
Scholar vanmierlo
Scholar
12,682 Views
Registered: ‎06-10-2008

Re: Understanding ASYNC_REG attribute

Jump to solution

@avrumw wrote:

If you are using project mode, then you put the SCOPED_TO_REF property on the XDC file. So if you are using the GUI, after  you add the XDC file to your project, you select that XDC file in the Sources window, then go to the Source File Properties, scroll down to the property "SCOPED_TO_REF" and type in the name of the module to which you want the XDC file applied.

 


Ah, so that's how it's done. I did not find this in the referred UG903.

 

Thanks

0 Kudos