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: 
Observer flux
Observer
558 Views
Registered: ‎02-02-2018

OSERDES2 Async Reset

Jump to solution

I have an Artix-7 Verilog design that uses two linked OSERDES2 to serialize 10-bit TMDS values.

The OSERDES2 documentation, page 164 in UG471 (v1.10), states that:

"Every OSERDESE2 in a multiple bit output structure should therefore be driven by the same reset
signal, asserted asynchronously, and deasserted synchronously to CLKDIV to ensure that
all OSERDESE2 elements come out of reset in synchronization."

In my design (included, below) I wait for clocks to be locked, then I have an async reset assert followed some cycles later a sync deassert. It works in simulation and on actual hardware, but I'm not happy with the design (async set of reg), and it produces a methodology warning:

"LUTAR #1 Warning LUT cell display_clocks_inst/rst_cnt[3]_i_3, with 2 or more inputs, drives asynchronous preset/clear pin(s) dvi_out/serialize_ch0/rst_cnt_reg[0]/CLR... The LUT may glitch and trigger an unexpected reset, even if it is a properly timed path."

I've tried to find a definitive example of the correct way to reset OSERDES2 without success. Can someone clarify what the correct approach is? Why is reset assertion required to be asynchronous?

I've included the reset design below and you can see the full module on GitHub.

TIA
Will

localparam ENABLE_DELAY_TICKS = 8; // clock cycles to wait before deassert
reg [3:0] rst_cnt; // reset delay counter
reg rst_oserdes; // oserdes reset

always @ (posedge i_clk or posedge i_rst)
begin
    if (i_rst)
    begin
        rst_oserdes <= 1;
        rst_cnt <= ENABLE_DELAY_TICKS;
    end
    else
    begin
        if (rst_cnt != 0)
            rst_cnt <= rst_cnt - 1;
        else
            rst_oserdes <= 0;
    end
end

0 Kudos
1 Solution

Accepted Solutions
Observer flux
Observer
285 Views
Registered: ‎02-02-2018

Re: OSERDES2 Async Reset

Jump to solution

Thanks for this advice; I had overlooked the ASYNC_REG attribute. Looking at the implemented plan, Vivado had placed all three reg in the same slice, but I don't want to risk them being separated.

I was only using three registers in my implementation rather than four in my previous macro instance:

reg [2:0] rst_shf;          // reset shift reg

While two in usually enough for such situations, the simulation of OSERDES2 has been very fussy in the past: at one point I was using eight registers for the reset!

However, the current design on Vivado 2019.1 seems to work with just two as you suggest, so that's what I'm now using. The following has proved robust so far in simulation and on actual hardware:

    // asynchronous reset
    reg rst_oserdes;            // oserdes reset (active high)
    (* ASYNC_REG = "TRUE" *) reg [1:0] rst_shf;  // reset shift reg

    initial rst_oserdes = 1'b1; // start of with reset asserted
    initial rst_shf = 2'b11;    //  and reset shift reg populated

    always @(posedge i_clk or posedge i_rst)
    if (i_rst)
        {rst_oserdes, rst_shf} <= 3'b111;
    else
        {rst_oserdes, rst_shf} <= {rst_shf, 1'b0};

I hope I can now put resets aside for a while and get on with my 2D graphics. :)

0 Kudos
9 Replies
531 Views
Registered: ‎01-22-2015

Re: OSERDES2 Async Reset

Jump to solution

@flux 

Welcome to the Xilinx Forum !

     Can someone clarify what the correct approach is?
In short, we normally use a separate reset-synchronizer (aka reset-bridge) to bring a common power-ON-reset (POR) into each clock domain of an HDL-project.  Xilinx provides a primitive called XPM_CDC_ASYNC_RST (see pg9, UG953) for creating the reset-synchronizer.  As you are doing, the common POR is often an inverted version of the “locked” output of the Clock Management Tile (eg. MMCM or PLL) used to create the HDL-project clocks.

     Why is reset assertion required to be asynchronous?
The reset-synchronizer is asynchronous-ON(assert) and synchronous-OFF(de-assert).  There is difference of opinion about the asynchronous-ON part.  However, I think it should be used.  With the POR method described above, asynchronous-ON ensures that all resets for your project will go on shortly after power is applied to the FPGA – and stay ON (typically) for a few seconds.  A few seconds is plenty of time for any instability caused by asynchronous-ON to settle out – resulting in a clean reset-ON. 

There is almost universal agreement that resets must be synchronous-OFF.  This ensures a clean reset-OFF (no setup and hold violations) at registers in our design that use the reset – which is of course what we want when the FPGA finally starts to do something useful after power-up.

Instead of using XPM_CDC_ASYNC_RST, you can easily write your own reset-synchronizer in Verilog.  I use VHDL (and am not proficient in Verilog).  You’ll find VHDL code for a reset-synchronizer in <this> thread as well as other thoughts about resets.

So, try driving the reset-input to OSERDES2 directly from the output of a reset-synchronizer.

Cheers,
Mark

Tags (1)
474 Views
Registered: ‎01-22-2015

Re: OSERDES2 Async Reset

Jump to solution

@flux 

Is this now safe to ignore, or am I overlooking something?
We should investigate further since (as the warning says) the LUT can glitch and cause unexpected reset of the OSERDES.

Can you open the implemented design and see the LUT that is driving RST of the OSERDES?  -and identify/describe all inputs to this LUT?

Again, I apologize for not being a Verilog programmer (and thus unable to check details of your code).

Mark

0 Kudos
Observer flux
Observer
466 Views
Registered: ‎02-02-2018

Re: OSERDES2 Async Reset

Jump to solution

Thanks for the speedy reply markg@prosensing.com. My reply that you've just referenced has apparently been removed by the spam filter. I have asked the moderators to re-instate it. Otherwise this thread isn't going to make much sense.

The async_reset is driven by the hardware reset button and the clock locked signal. This handles the requirement laid out in UG471: "The reset signal should only be deasserted when it is known that CLK and CLKDIV are stable and present."

I have included the schematic, below:

Screenshot from 2019-06-11 13-27-07.png

0 Kudos
447 Views
Registered: ‎01-22-2015

Re: OSERDES2 Async Reset

Jump to solution

The order of things should be that both resets enter the LUT and the the output of the LUT goes through your reset-synchronizer and into the OSERDES.  -but it seems the reset-synchronizer is missing.

Are you get any warnings about your use of the reset-synchronizer macro?  Did you include the XPM library (see UG953) in the file where you instantiate the macro?

0 Kudos
Observer flux
Observer
397 Views
Registered: ‎02-02-2018

Re: OSERDES2 Async Reset

Jump to solution

Apologies if that screenshot was misleading: it only showed the sources of the cell Vivado was complaining about. I have attached two screenshots showing the overall serialization process as well as the detail of the async reset via xpm_cdc_async_rst.

The moderators haven't reinstated my earlier reply yet, so I've reposted the relevant code and error message below:

wire rst_oserdes; // oserdes reset

// asynchronous reset macro
xpm_cdc_async_rst #(
    .DEST_SYNC_FF(4),
    .INIT_SYNC_FF(1),
    .RST_ACTIVE_HIGH(1)
)
async_reset (
    .dest_arst(rst_oserdes),
    .dest_clk(i_clk),
    .src_arst(i_rst)
);

Complete module source: serializer_10to1.v

Error message

LUTAR #1 Warning LUT cell display_clocks_inst/async_reset_i_1, with 2 or more inputs, drives asynchronous preset/clear pin(s) dvi_out/serialize_ch0/async_reset/arststages_ff_reg[0]/PRE, dvi_out/serialize_ch0/async_reset/arststages_ff_reg[1]/PRE, dvi_out/serialize_ch0/async_reset/arststages_ff_reg[2]/PRE, dvi_out/serialize_ch0/async_reset/arststages_ff_reg[3]/PRE... The LUT may glitch and trigger an unexpected reset, even if it is a properly timed path.

Thanks again for your help.

Screenshot from 2019-06-13 16-26-22.pngScreenshot from 2019-06-13 16-19-25.png

375 Views
Registered: ‎01-22-2015

Re: OSERDES2 Async Reset

Jump to solution

@flux 

Good job providing all the info we need to assist you!

For your reference, resetting the OSERDESE2 of the Artix-7 is described on page-164 of UG471 (v1.10).  There it says that RST for OSERDESE3 should be “…asserted asynchronously, and deasserted synchronously to CLKDIV …and… should only be deasserted when it is known that CLK and CLKDIV are stable and present.”  -which is exactly what you have done with the XPM_CDC_ASYNC_RST macro.  If you were using the OSERDESE3 in an UltraScale FPGA, then a more complicated reset procedure would be needed.

So, from an engineering point-of-view you have properly reset the OSERDESE2 – and you can safely ignore the “LUTAR #1 Warning”.  The XPM synchronizer macros usually place a timing-exception on inputs to the macro to suppress ignorable-warnings (but seemingly not in your case).  If you tire of seeing the “LUTAR #1 Warning”, then you might be able to suppress it by placing the following timing-exception in your project XDC file.

set_false_path -to [get_cells -hier {arststages_ff_reg[*]}] 

Mark

0 Kudos
Observer flux
Observer
334 Views
Registered: ‎02-02-2018

Re: OSERDES2 Async Reset

Jump to solution

Alas the XDC suggestion didn't work: the warning still occurs.

Given the warning occurs with the xpm_cdc_async_rst macro, I thought I might as well create my own implementation:

// asynchronous reset
reg rst_oserdes;            // oserdes reset (active high)
reg [2:0] rst_shf;          // reset shift reg

always @(posedge i_clk or posedge i_rst)
if (i_rst)
    {rst_oserdes, rst_shf} <= 4'b1111;
else
    {rst_oserdes, rst_shf} <= {rst_shf, 1'b0};

This has worked well in simulation and on actual display hardware. It also has the advantage of using fewer resources than my original counter-based implementation. So, despite being unable to avoid the warning, I'm happy with the outcome.

Thanks again for all your help, markg@prosensing.com. I'll mention your contribution when I merge the new display-controller into the master branch.

Best wishes,
Will

0 Kudos
Highlighted
308 Views
Registered: ‎01-22-2015

Re: OSERDES2 Async Reset

Jump to solution

@flux 

     Alas the XDC suggestion didn't work: the warning still occurs.
It was worth a try.  I still say that the LUTAR warning for cells of the reset-synchronizer can be ignored.

     I thought I might as well create my own implementation:
I encourage this.  However, here are some reminders and details:

  1. The OSERDESE2 uses an “active high” reset. So, make sure the output of your reset-synchronizer goes high when your inputs to the reset-synchronizer indicate that the “reset is ON”. 
  2. The implemented circuit that you showed for the XPM_CDC_ASYNC_RST has an output that goes high when its input=1. So, for you, if “input=1” means “reset is ON”, then the XPM_CDC_ASYNC_RST is creating a circuit that is “logically correct” for your application.
  3. If the implemented circuit that you showed for the XPM_CDC_ASYNC_RST is “logically correct”, then the implemented circuit for your custom reset-synchronizer must match the implemented circuit for the XPM_CDC_ASYNC_RST (no exceptions!).
  4. One small concession to 3): You configured the XPM_CDC_ASYNC_RST to use four registers.  You can configure XPM_CDC_ASYNC_RST to use a few as two registers and it will still work properly for your application.  So, your custom reset-synchronizer could also use as few as two registers.
  5. For each register in your custom reset-synchronizer, you must set the property, ASYNC_REG=”TRUE”. This can be done in Verilog as shown on page-46 of UG901(v2019.1).   
  6. After doing all of the above, you should open your implemented design and verify that your ASYNC_REG=”TRUE” commands were used correctly. That is, the ASYNC_REG=”TRUE” commands should cause all registers of your reset-synchronizer to be physically placed in the same FPGA slice - which is a necessary condition for a clean release of the reset by the reset-synchronizer.  The Vivado Device view screenshot below for the XPM_CDC_ASYNC_RST shows how its four registers have all been placed in the same FPGA slice. 
    4regs_in_slice.jpg

 

Observer flux
Observer
286 Views
Registered: ‎02-02-2018

Re: OSERDES2 Async Reset

Jump to solution

Thanks for this advice; I had overlooked the ASYNC_REG attribute. Looking at the implemented plan, Vivado had placed all three reg in the same slice, but I don't want to risk them being separated.

I was only using three registers in my implementation rather than four in my previous macro instance:

reg [2:0] rst_shf;          // reset shift reg

While two in usually enough for such situations, the simulation of OSERDES2 has been very fussy in the past: at one point I was using eight registers for the reset!

However, the current design on Vivado 2019.1 seems to work with just two as you suggest, so that's what I'm now using. The following has proved robust so far in simulation and on actual hardware:

    // asynchronous reset
    reg rst_oserdes;            // oserdes reset (active high)
    (* ASYNC_REG = "TRUE" *) reg [1:0] rst_shf;  // reset shift reg

    initial rst_oserdes = 1'b1; // start of with reset asserted
    initial rst_shf = 2'b11;    //  and reset shift reg populated

    always @(posedge i_clk or posedge i_rst)
    if (i_rst)
        {rst_oserdes, rst_shf} <= 3'b111;
    else
        {rst_oserdes, rst_shf} <= {rst_shf, 1'b0};

I hope I can now put resets aside for a while and get on with my 2D graphics. :)

0 Kudos