05-30-2020 04:28 PM
Hello, I'm taking a Xilinx On Demand course: Designing with Ultrascale and am currently in the HDL Coding Techniques. I wanted to ask the members if there is any further documentation on HDL Coding for Ultrascale devices.
05-30-2020 05:13 PM
05-30-2020 05:13 PM
06-01-2020 09:02 AM
Hello, quick question for you concerning Reset signals. Am I to understand that the new recommendation is that your resets should be Active High and not Active Low? My System Reset on my Custom Board is Active Low, so is it correct to say that I should run it through a Inverter on my FPGA so that all Resets are Active High?
06-01-2020 09:40 AM
Most components in Xilinx FPGAs have active-high resets. So, using active-high resets (instead of action-low resets) will use less FPGA resources.
There is lots to think about when it comes to resets. My 08-13-2019 post in the following thread summarizes my thoughts on resets.
06-02-2020 09:33 AM
Hello and thank you for responding to my post. Most people use an Active Low Reset so it will be a little difficult getting people to change when they are using an Ultrascale+ device. What if I run the Active Low Reset through two flip flops this would synchronize the reset to the system clock, would that be an option? Or, is it just better to invert the reset and use it as an Active High reset?
Would below be okay if areset_n is passed through two fliip flops?
always @ (posedge clk or negedge areset_n)
data_buf <= 0;
data_buf <= data;
If areset is active high is the below okay?
always @ (posedge clk)
data_buf <= 0;
data_buf <= data;
06-02-2020 10:26 AM - edited 06-02-2020 10:27 AM
Traditionally active low reset was used as holding something at VCC drew less power than holding it at GND. so making signals active low would draw less power. But I think those days are mostly past. Other than required interfaces (AXI!) eveything is active high, and everyone I know uses active high reset.
FPGAs have had active high resets for as long as ive been in industry and even the ASIC work I did was using all active high reset. The reason active low reset still persists is the historical workthats out there and everyone learns by example, and a lot of people rarely update their examples. (Active low reset still makes sense on a circuit board for the power reasons, but inside a chip its signal transistions that eat all the power).
Dont bother inverting the resets manually. Inverting signals is effectively free in an FPGA. Each slice has the option to invert a signal on input, so if you have an active low reset in the code, the compiler will just invert the reset into the slice.
06-02-2020 04:10 PM
As Richard and you say, many boards have resets that are active-low. However, almost all resets in the FPGA are active-high. So, when your active-low board reset enters the FPGA, I recommend that you immediately invert it (with a LUT) before using it inside the FPGA.
Further, resets need to undergo and pass timing analysis. To help a reset pass timing analysis, it is common to route the reset signal through a component called a reset-synchronizer (aka reset-bridge).
The reset-synchronizer looks like the 2-flip-flop synchronizer that you have probably used when crossing data from one clock-domain to another clock-domain. However, the reset-synchronizer is not the same as the 2-flip-flop synchronizer (see <this> post for details). For active-high resets, the reset-synchronizer passes the reset-rising-edge through asynchronously (ie. immediately) but passes the reset-falling-edge through synchronously and with a delay of N clock cycles where N is the number of flip-flops used to build the reset-synchronizer.
To ensure that the reset-synchronizer is implemented properly in Vivado, we must set the property, ASYNC_REG=TRUE, for each digital register used to build the reset-synchronizer. -and sometimes we place a set_false_path constraint on the path coming into the reset-synchronizer.
Xilinx provides a macro called XPM_CDC_ASYNC_RST (see page 9 of UG974(v2019.2)). This macro makes it easy to place reset-synchronizers in your design. Also, this macro writes the necessary ASYNC_REG=TRUE constraints for you.
06-03-2020 09:40 AM
Wow! Thank you very for the detailed response. In these days with the super complex devices I may be a "newbie" until I retire.
06-03-2020 10:21 AM
Hello, I like using the Block Design tool for my designs, it is easier to see what is happening. So, can I make a module with the macro and pass in the active low reset and then output the active high and then use that reset in my design? Here is my module:
//Xilinx Parameterized Macro,version2018.1
.RST_ACTIVE_HIGH(0) //DECIMAL;0=activelowreset,1=active highreset
The output would be an active high reset and I would write all my RTL module for active high inputs.
Am I on the right track here?
06-03-2020 10:46 AM
As @richardhead and firstname.lastname@example.org pointed out, most resets are active high. There are a couple Xilinx IP that have active low resets, in particular, the FIR Compiler and the CIC Filter. You could add an active high output to your block if you use these. You might also want to look at the Processor System Reset IP which has both polarities and has controllable reset pulse widths.
06-03-2020 03:59 PM
I am not familiar with the Block Design method. I am also not very familiar with Verilog.
However, I do recognize your instantiation for the xpm_cdc_async_rst macro. Currently, you have ".RST_ACTIVE_HIGH(0)", which means that the macro expects an active-low reset on the input and will produce an active-low reset on the output.
If you want to use active-high resets in your design then you need to have ".RST_ACTIVE_HIGH(1)", and you need to send an active-high reset to the input of xpm_cdc_async_rst. This means that you must invert your active-low board reset before sending it to the input of xpm_cdc_async_rst.
Finally, don't forget to always test new code (like this reset synchronizer) using Vivado simulation.
06-03-2020 04:00 PM
Thank you very much. So I agree that one needs an Active High Reset. What I included and the image is that correct by using the macro? Or, should I inverted the reset and then run it through the macro?
06-03-2020 04:08 PM
Since you want active-high resets in your design, then you need to:
1) invert your active-low board reset and send it to "input src_arst" of your module.
2) use ".RST_ACTIVE_HIGH(1)" in the instantiation for xpm_cdc_async_rst
3) simulate your module to ensure it is doing what you want
06-04-2020 06:13 AM
Hello, thank you very much. I will make the change ".RST_ACTIVE_HIGH(1)".
Have a great day,