cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Advisor
Advisor
2,600 Views
Registered: ‎10-10-2014

UG949 - UFDM - (Global) reset in a Zynq design

Jump to solution

I'm reading through UG949 chapter 3. This chapter has some recommendations on control signals, more in specific for my question on synchronous/asynchronous/global reset signals.

 

Looking at a simpel Zynq design, I have a few questions regarding reset signals :

zynq reset.png

Reset starts at FCLK_RESET0_N from the Zynq IP, enters the Processor System Reset IP. That Reset IP generates 2 reset signals, one for interconnects, and one for peripherals.

 

I'm wondering about the following :

 

1) is FLCK_RESET0_N actually what UG949 calls 'GSR' (Global Set Reset)

2) why is there a separate reset for interconnect and peripheral needed, as everything runs on the same clock?

3) the reset signals have a name '_aresetn' : does this indicate that this output of the Processor System Reset IP is an 'asynchronous' reset? 

 

UG949 says to avoid reset wherever possible. But I can see almost all Xilinx IP having a reset input ... I can see that it's straightforward to avoid or limit resets on datapaths when there's no feedback in the datapath. However with typical control logic (FSM's, counters, ... ) it's hard to avoid a reset, or am I wrong?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
3,616 Views
Registered: ‎01-22-2008

 

1) is FLCK_RESET0_N actually what UG949 calls 'GSR' (Global Set Reset)

No, GSR is a configuration signal, it occurs once the FPGA goes through the startup sequence

2) why is there a separate reset for interconnect and peripheral needed, as everything runs on the same clock?

This is to resolve the problem of sequencing. If the interconnect is not awake when peripherals start accessing it, the system may be locked.

There are more details in PG164 chapter 2.

 

3) the reset signals have a name '_aresetn' : does this indicate that this output of the Processor System Reset IP is an 'asynchronous' reset? 

Yes, asynchronous active low. AXI specification requires the reset to be async active low.

 

Indeed, it is hard to avoid reset on control signals, or on datapath with accumulator or feedback.

The key is to control your resets: know how many cycles you need to reset each blocks, reset state and first deassertion, create local resets, etc...

Essentially, plan resets at the same time as the clocking scheme.

Vincent.

View solution in original post

5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
3,617 Views
Registered: ‎01-22-2008

 

1) is FLCK_RESET0_N actually what UG949 calls 'GSR' (Global Set Reset)

No, GSR is a configuration signal, it occurs once the FPGA goes through the startup sequence

2) why is there a separate reset for interconnect and peripheral needed, as everything runs on the same clock?

This is to resolve the problem of sequencing. If the interconnect is not awake when peripherals start accessing it, the system may be locked.

There are more details in PG164 chapter 2.

 

3) the reset signals have a name '_aresetn' : does this indicate that this output of the Processor System Reset IP is an 'asynchronous' reset? 

Yes, asynchronous active low. AXI specification requires the reset to be async active low.

 

Indeed, it is hard to avoid reset on control signals, or on datapath with accumulator or feedback.

The key is to control your resets: know how many cycles you need to reset each blocks, reset state and first deassertion, create local resets, etc...

Essentially, plan resets at the same time as the clocking scheme.

Vincent.

View solution in original post

Highlighted
Advisor
Advisor
2,572 Views
Registered: ‎10-10-2014

thanks @vve for the clear explanation.

 

1 last question : you wrote that the output ot the Processor Systems Reset IP is 'asynchronous active low'. Are you sure it is asynchronous? Isn't it synchronized by the IP to the input 'slowest sync clock' ?

 

Wouldn't we otherwise need some reset synchronizer in all peripheral IP's? When I'm creating for example a custom AXI IP, I use the peripheral_aresetn as reset input for my custom IP. I was this reset was synchronous to my clock (in this case FCLK0)?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,558 Views
Registered: ‎01-22-2008

Yes, sorry for the confusion.

The de-assertion is synchronous to "slowest_sync_clk". It connects to the async reset of the peripheral (or interconnect).

 

Capture.PNG

Highlighted
Advisor
Advisor
2,551 Views
Registered: ‎10-10-2014

thanks @vve, all clear now!

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Advisor
Advisor
137 Views
Registered: ‎10-10-2014

@vve I'd like to come back to this post ... by default, Vivado's design assistant / autocomplete seems to route all interconnect and IP resets to the 'peripheral_aresetn' pin of the Processor System Reset IP. 

Screenshot 2020-11-02 at 23.02.20.png

Would it then be more appropriate to route the interconnect_aresetn to the interconnects, like this (green line) :

Screenshot 2020-11-02 at 23.03.28.png

At first this doesn't look to be a problem the way Vivado routes the reset, as by the time software has booted to and starts to init the DMA controller, reset will long be over. But maybe in cases where there is some special AXI master IP in the PL that immediately tries to access the AXI bus things could go wrong? Is that correct? Is there any practical example or case you can think of?

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos