cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
8,846 Views
Registered: ‎01-22-2015

GSR net and flip-flop initialization

Jump to solution

The image below is a page from the Xilinx video found at <this link>.   A note at the bottom of this page says, "The ability to extract the INIT value from the RTL code is relatively new, and may not be supported by all synthesis tools".

 

Do the current synthesis tools used by Vivado "extract the INIT value from the RTL code" when the FPGA Global Set/Reset (GSR) is asserted (ie. when the FPGA is configured)?     -for all FPGAs supported by Vivado?

Xilinx1.jpg

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
14,499 Views
Registered: ‎01-23-2009

Re: GSR net and flip-flop initialization

Jump to solution

This slide was written 6 years ago (or more) ... At the time XST had just started supporting it, but some of the 3rd party synthesis tools weren't yet (i.e.  Synplify). 

 

Vivado has always supported this, and, while I don't know for certain, I assume all the major 3rd party synthesis to do as well. 

 

Avrum 

View solution in original post

Tags (2)
0 Kudos
10 Replies
Highlighted
Guide
Guide
14,500 Views
Registered: ‎01-23-2009

Re: GSR net and flip-flop initialization

Jump to solution

This slide was written 6 years ago (or more) ... At the time XST had just started supporting it, but some of the 3rd party synthesis tools weren't yet (i.e.  Synplify). 

 

Vivado has always supported this, and, while I don't know for certain, I assume all the major 3rd party synthesis to do as well. 

 

Avrum 

View solution in original post

Tags (2)
0 Kudos
Highlighted
8,808 Views
Registered: ‎01-22-2015

Re: GSR net and flip-flop initialization

Jump to solution

Avrum - thanks for the reply.

 

Suppose, in the processes shown, that RST comes only from the GSR net.  That is, I have no reason to assert RST after the FPGA is up and running.  Then, isn't the RST=1 part of the "if - else" completely redundant to the HDL INIT?

0 Kudos
Highlighted
Guide
Guide
8,798 Views
Registered: ‎01-23-2009

Re: GSR net and flip-flop initialization

Jump to solution

Suppose, in the processes shown, that RST comes only from the GSR net.

 

I am not sure I follow this. The whole point of this slide is that the GSR initialization and the user coded explicit reset are two separate things.

 

The GSR is "invisible" - it doesn't show up in the RTL code at all. The manifestation of the GSR is that it is the mechanism by which the INIT value is loaded into the flip-flop during configuration.

 

So if you have a flip-flop that relies only on GSR (initialization), the code fragment would be

 

reg Q = 1'b1;  // This is the GSR initialization

always @(posedge CLK)
  Q <= D;

Avrum

Tags (2)
0 Kudos
Highlighted
8,774 Views
Registered: ‎01-22-2015

Re: GSR net and flip-flop initialization

Jump to solution
Thanks Avrum!
Yes, in some RTL (eg. mine) I have seen that the RST clause and the GSR are doing the same thing (ie. initializing the flip-flop during or shortly after FPGA configuration). No need to have them both - right?

-a related question, please:
Timing analysis aside, can synthesis ever produce something which cannot be implemented inside the FPGA?
0 Kudos
Highlighted
Guide
Guide
8,748 Views
Registered: ‎01-23-2009

Re: GSR net and flip-flop initialization

Jump to solution

Yes, in some RTL (eg. mine) I have seen that the RST clause and the GSR are doing the same thing (ie. initializing the flip-flop during or shortly after FPGA configuration). No need to have them both - right?

 

Again, I don't understand this. The GSR always exists and always initializes the flip flops to the initialization value during (or just at the end of) the configuration process. There is nothing in the RTL code that controls or manages this; the only control you have over it is the INIT value (as we described above).

 

The only other thing that can be done with the GSR is to re-trigger it after initialization using the GSR pin of the STARTUP module - but it is very unusual to use this feature...

 

So, the GSR/INIT always exists. The only question to ask is whether you also need a global reset. Take a look at this thread on the use of initialization and when an explicit reset is necessary.

 

Timing analysis aside, can synthesis ever produce something which cannot be implemented inside the FPGA?

 

Yes. There are a whole bunch of structurally illegal things that cannot be implemented, that can be generated by synthesis if your RTL explicitly codes for them. For example, if your RTL results in two drivers for the same net, there are ways for the synthesis to pass (particularly if the two drivers are in different out-of-context modules), but implementation will fail with an error on this. There are other DRC checks that are done (like illegal connections to and from input/output blocks and to clocking resources) that will only be done during the placement phase, and even others that are only done when the bitstream is generated.

 

There is also the obvious "will it fit into the FPGA". The entire FPGA (including out-of-context IP blocks) isn't assembled until after (depending on the flow, possibly at the end of) synthesis. So, the final "does it fit in the FPGA" check is only done during device placement.

 

But all of these are specifically errors in your RTL code or constraints. If your code and constraints are correct and legal (and not bigger than the device), then the synthesis tool will always generate implementable systems.

 

Avrum

Tags (2)
Highlighted
8,723 Views
Registered: ‎01-22-2015

Re: GSR net and flip-flop initialization

Jump to solution

Avrum,

 

Thanks for all that and for the link to the discussion between you and Mark Curry - which answers my question about a dedicated "Power-ON Reset(POR)" vs the GSR/INIT.  From that discussion, I conclude that a carefully crafted (in HDL) POR is a more general-purpose (and reliable?) way (than GSR/INT) to ensure that all your flip-flops and state-machines startup properly.

 

FYI - somehow/someplace I got it into my head that the RTL initialization shown in the Xilinx slide above was only useful for simulation.  With your help, I now understand that RTL initialization will be implemented inside the FPGA as part of the GSR/INIT.

-but thought I should warn others that these "alternate truths" about RTL initialization are out there floating around.

 

Mark

0 Kudos
Highlighted
8,683 Views
Registered: ‎01-22-2015

Re: GSR net and flip-flop initialization

Jump to solution
Avrum,

I hope we can talk more about the GSR. As I understand, the following sequence of events happens when the FPGA powers up:
1. Configuration is loaded into the FPGA from PROM
2. GSR is toggled and the user-specified initializations (found in RTL initialization statements) are applied to the flip-flops
3. Clocks start to come up - perhaps not all at once and perhaps not initially with proper phase.
4. Some of the circuits in the FPGA (ie. implementations of RTL processes) start to be clocked - not all at once.
5. Digital signals start to be produced- not all at once and perhaps not correct initially.
6. Finally, everything is running and we cross our fingers and hope it all works.

If I have described things correctly then the normal occurrence of the GSR seems to come to early to be of much use. Wouldn't it be better if the GSR was applied immediately after step 6?
0 Kudos
Highlighted
Guide
Guide
8,672 Views
Registered: ‎01-23-2009

Re: GSR net and flip-flop initialization

Jump to solution

When the FPGA powers up, it preforms the configuration sequence, which is a series of 8 steps. Steps 1-7 include all the stuff involved in clearing the array, downloading the bitstream, checking the CRCs, etc.. Step 8 is the Startup step.

 

There are 8 phases to the Startup step, and various different operations occur during each of the 8 phases. Most of the operations in this step are programmable, and can be assigned to one of a number of different phases, and the conditions required for transitioning from phase to phase are also somewhat programmable.

 

The configuration sequence for the 7 series devices are documented in the Configuration User Guide (UG470), in the section "Configuration Sequence" and the Startup is described in the sub-section "Startup (Step 8)".

 

In this startup step, there is no mention of the GSR (I always thought there should be), but they do talk about the GWE (Global Write Enable) - it is really the enable of this global signal that causes flip-flops to begin to behave in "functional mode" (so GSR, if it is different than the GWE, loads the INIT values "early" in the startup sequence, but the INIT values remain there until the first clock cycle after GWE is asserted).

 

In the default steps, inputs and combinatorial functions begin to operate before the GWE is asserted - so that means that any direct clocks (i.e. not through an MMCM/PLL) will be running when GWE is asserted. Furthermore MMCMs/PLLs will begin to lock before GWE is asserted - although they may not yet be locked (you can configure the Startup sequence wait for MMCMs to lock at any stage - even before the GWE if you want, but that is not the default).

 

So, net result - clocks may or may not be running and reliable at the time that the GWE is asserted.

 

More importantly, It is specifically noted in the User Guide that the assertion of the GWE is slow and asynchronous - see table 5-12, footnote 3

 

"GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique."

 

Now to your comment:

 

Wouldn't it be better if the GSR was applied immediately after step 6?

 

You can configure the Startup sequence to do this if you want, but it won't fundamentally change anything. Even if all the clocks are running and locked, and all the digital logic is ready to go, the assertion of GWE is slow and asynchronous to your user clocks. It is for this reason that you cannot use the GSR/GWE alone for the initialization of any logic that can potentially change state on the "first (user) clock after GWE is asserted"..

 

Avrum

Tags (2)
Highlighted
8,658 Views
Registered: ‎01-22-2015

Re: GSR net and flip-flop initialization

Jump to solution
Avrum,

With your help, finally feels like I'm getting my head around this.

So, instead of relying on the GSR, maybe we start with the LOCKED output of the MMCM. Delay it a little (maybe differently for each clock-domain) and run it through a reset-bridge into each clock-domain. Then, maybe we've got the start of a "proper" power-on reset for our FPGA?
Tags (1)
0 Kudos
Highlighted
Scholar
Scholar
5,151 Views
Registered: ‎09-16-2009

Re: GSR net and flip-flop initialization

Jump to solution

Mark,

 

That's what we do.  A per clock domain actual reset who's inactive edge is synchronous to the clock domain it's on. We generate ours globally in a "clocks and resets" module.

 

One of the qualifications is the Locked output of the PLL it's on (if the clock source is a PLL).  There's likely other qualifications necessary to qualify a good exit from reset.

 

Actually relying on GSR is a very rare exception in our code.  There's point use cases that are valid, but in general, you cannot relying on GSR.  It's certainly a nice-to-have, but not sufficient nor reliable by itself for the reasons avrum's listed.

 

Regards,

 

Mark