reset strategy FPGA Igloo

Not familiar with Igloo family, so can't offer specific advice, but I do have general advice on the "lock" signal coming out of PLLs.

These signals are notoriously unreliable from many families. They tend to "chatter" going into lock (i.e. indicating a lock, then falling out of lock, then back in). This all, of course, can vary by design. But I now almost always take the tact of casting a suspicicious eye on a PLL's lock indicator, and usually qualify it with something else rather than using it raw.

Often, I just take the data sheet "max lock time" spec. I wait for this time to pass, AND the lock signal to indicate true before truly declaring lock.

Your mileage may vary - and as I said, I'm not familiar with the igloo family, so don't know its PLL design at all. But my experience with PLLs here is from many various designs, in many various technologies (ASICs at various nodes/various FPGAs).

The second piece of advice I can offer is to have your STA tool check the timing. You should synchronize your reset, then treat it like any other signal that's timing checked - you'll know quickly whether or not you'll need to treat that high-fanout net with special handing.

Regards,

Mark

First, I agree with what Mark says.

In addition, note that most FPGA families have a global reset line similar to the global clock lines. They usually keep all the FF held at reset until configuration is done, and also allow you to use that reset line. It is there, it is free, and you might was well use it.

You do still have to get the timing right, so you release it at the right time relative to the clock edge.

-- glen

The timing provided by the global reset line is not good.. it's nowhere near as good as a global clock line as far as I understand.

One way to deal with this is to have all of your state machines start in a reset state which does nothing but wait for a synchronous "start" edge which is generated after reset with a counter or a shift register.

This has a big advantage that you no longer have to worry about global reset timing. On the other hand, if you use libraries you may have no choice since you can't change the logic.

Hi Mark,

On 11/10/2013 18:46, Mark Curry wrote: []

That's a big hint! In the past I typically had a 'powerup reset' done with an external RC line with a big time constant, enough to allow the clock to be stable. The current design I'm working on had already been written and I thought the idea of using the internal pll lock signal was not too bad, but I was not aware of these reliability issues.

That might explain why every third power up nothing works!

Uhm... and how do you reset the counter you need to rely on? Certainly I can use the 'not lock' signal to keep the counter reset and then add the extra margin.

Since I do not have any experience with this strategy at all I guess that your point is already discouraging enough to continue stubbornly along this path.

I'll try the 'max lock time' approach and see what it leads to.

Checked and found timing violations. Fan-out is ~400. I've seen in the past reset signals routed through a clockbuffer, is this a wise move?

Hi Glen,

On 11/10/2013 19:52, glen herrmannsfeldt wrote: []

and I also start to believe my reset strategy is weak!

Apparently I have not found a 'global reset line' for the igloo family, but there's an interesting application note from Actel/Microsemi on their Flash-based devices which I find quite interesting:

It boils down to exploiting the difference in power up between input buffer and output buffer, therefore leading to the possibility to drive two states for an active/deactive reset.

In the AN it refers to the possibility to extend the reset line with a counter which is 'preset' by the Power-on Reset (POR), potentially useful to wait for external circuitry to reach to an operational state before the FPGA logic starts.

It's unfortunate that in my case I do not have an unused pulled-up pin and I'm wondering whether I can use the same technique profiting of the 'weak pull-up' capabilities that can be programmed in the I/O. From this AN:

it seems that 'weak pull-up/down' will be activated as soon as Vcc and Vcci are above functional threshold, which is essentially enough to have a logic '1' driven at the input of the POR proposed in the other note.

This is something I typically do. I keep a couple, if not more, of clock tics to deactivate the reset. This makes the reset signal like any other one and no special time constraints are needed.

The counter needs to explictly NOT be connected to "lock" at all. The counter should be initialized whenever the PLL begins it's acquisition. If no explicit reset pin exists, then device init? You need a one shot or something at end of config. Check docs for Igloo - like I said, I'm not familiar with the family. Xilinx let you use init values for this i.e.:

reg one_shot = 1; always @( posedge clk ) one_shot >

Depends on FPGA architecture. I believe in Xilinx this wouldn't work, as the clockbuffer only routes to clocks, not data pins (or resets). Replicate the source FF maybe? Can you have the tools do this for you? i.e. create your qualified lock. Pipeline delay it a few cycles, then let the tool replicate the final stage as much as neccesary. Depends on the synthesis/PAR tools.

Regards

Mark

Wow, if Actel doesn't have a global reset line I have no idea how they make their parts work. I haven't read the above app note, but the way most brands of FPGAs work, there is a global reset line which holds the user logic in reset until the end of config. This like is similar to a global clock line, but without the high speed drive. When the reset is released the entire chip can start. The problem is the delay on this line is long enough to cause problems releasing the entire design on the same clock cycle.

It is seldom that an entire FPGA design has to start on the same clock edge. I design individual circuits to start up on a local copy of the reset. Or better still is to design them so they start in an idle state waiting for something else to happen which will take a clock cycle or two providing enough delay that they don't need a synchronous reset.

Are you saying you have designed the board without consideration to resetting the FPGA? I can't imagine the Actel parts require an external reset. I'm glad I am finding this out now.

Yes.

Actel/Microsemi FPGAs are FLASH so don't need configuration. You have to reset them in the same way you would an ASIC.

Designing for all-IDLE FSMs is the proper approach but doesn't eliminate the need to have an explicit reset. Global resources are typically used for the RESET even when timing is not an issue to remove the routing burden of thousands of loads. The locally copied RESETs are usually only useful if you need to support synchronous resets.

On 13/10/2013 05:18, rickman wrote: []

please do not take my words for granted. Maybe I haven't looked careful enough. OTOH I've worked with Actel components since a lot and found them very easy to handle (provided the board designer puts in a powerup reset circuitry!).

They are 'live at power up' (LAPU). See here for more information:

(warning: it took me a long time to download the file even though the size is relatively small - 727KB)

I agree with what Alan says: "Designing for all-IDLE FSMs is the proper approach but doesn't eliminate the need to have an explicit reset"

I jumped in the project far after those details were left out of the design phase. How do you reset your logic only through the internal resources of your device?

I don't think that is relevant to the discussion. What you call it doesn't matter, the point is that the device must have some way to reset all the user FFs at power up and also when controlled by the user. In the Xilinx devices the problem comes from the fact that this global reset signal is not fast enough to assure all FFs are reset or released from reset in the same clock cycle. That is the issue.

So do the Actel devices have a global reset/set signal? Is it fast enough to control all FFs in the same clock cycle?

Yes, I agree, but I don't get your point. I am discussing the global reset signal, does the Actel devices have one.

The local resets are for things that *do* need to start up on the same clock cycle; call it a synchronous reset then. A free running state machine is a good example. A counter is another.

I'm trying to understand what you *are* saying about the reset. Does Actel provide a mechanism so that each FF is brought out of reset on the same clock cycle? This makes a *big* difference in how you design your reset operation.

I think you are saying the FPGA has an external reset pin which the board controls. Good. Does your board control that? What does the reset do on the FPGA exactly?

I don't care if they are live at power up. Is that relevant? I'm trying to understand the reset process.

Maybe I don't understand what you are saying at all. Hopefully you will explain exactly what the problem is. Is there *no* reset to the FPGA on your board?

So are you saying there is no external reset on the board for the FPGA? Why can't you add one? The need for this seems like a no-brainer even if it is a white wire job.

If there is no reset, what can you know about the state of the FFs on powerup? If they are random, I don't think you can make this work without a power up reset.

Ah! I went back to your initial post about the PLL lock signal. Assuming this signal is meaningful at all times I would expect it to be "unlock" (as opposed to "lock") at power up. If that is true then I think you can condition it to give you a reset to your logic.

A small circuit consisting of a long period counter can be held in reset while the PLL is not locked. The rest of the design is held in reset by the counter. When the counter reaches its final state, implying the PLL lock signal has been valid long enough to actually indicate a true PLL lock, the reset to the rest of the logic is released.

Maybe this is obvious to you. If so, I don't understand what your question is.

To tell you the truth, I would try discussing this with an Actel FAE. Hopefully they know the answer.

Non-FLASH FPGAs have to be configured on power-on so the reseting of FFs is a by-product of that activity which allows for the deassertion of the configuration RESET *after* every FF has been configured to a known value. Like an ASIC, Actel parts require and explicit POR because they do not have a configuration sequence. If the POR signal (or logic output) is placed on a global net and your design frequency is below insertion delay plus skew of the global net and the POR is synchronously deasserted then every FF in the chip will be in the reset state in the same clock cycle. Again, this is the same consideration you have to use when reseting an ASIC.

No configuration sequence means no global reset.

This is a perfectly reasonable approach and one that I have used when the stability of LOCK was a potential issue.

Thanks. I don't need an explanation of what a Flash or RAM based FPGA is, I need to know what mechanism is provided in the Actel FPGAs for resetting all the FFs in your design on power up or external reset signal. Is there *any* specific resource for this? Or is it up to the synthesis tool to use the otherwise available routing? This makes it sound like there are no specific features to support reset of the FFs.

I can't imagine there wouldn't be a clear explanation somewhere of how this is intended to be done.

No, no configuration means no configuration. The global reset is an entirely separate feature.

It does not resolve the issue of how the reset reaches the rest of the FFs in the device. I find it hard to believe that there is no global reset feature in an Actel device. This means the general routing or possibly clock routing must be used.

I remember when FAEs used to respond to posts here. But then some of them generated some rather bad press for their company with a rather confrontational style.

Hi Rick,

On 15/10/2013 03:59, rickman wrote: []

No. You need to take care of it on your own, externally (with dedicated circuitry) and internally (with dedicated logic).

In the design I'm working on there's no external reset circuitry on the pcb and no pin is reserved for this purpose except for an 'init' pin which can be activated upon certain conditions which, as of now, do not include power on.

I've not yet found any dedicated pin and/or buffer to route the reset in the IGLOO family.

I mentioned the 'live at power up' feature to refer to the fact that they *do not need* a configuration.

Correct, there's *no* reset to the FPGA on my board.

A white wire job will not help you since you need at least an RC pulled-up to Vcc and C might be the equivalent of 4 caps (a series of two parallel ones) to avoid single point failure and hold the FPGA in reset state permanently upon a short fault on the cap.

Besides, we are about to enter flight module production (it's a space application) and we cannot functionally deviate from the qualification module (at least this are the rules we have to follow).

In the AN I posted there's a solution the vendor proposes to implement a POR. They suggest to rely on an external weak pull-up and profit of the different time for input/output configuration during a power-up sequence. I do not have an external pull-up, but I/Os can be opted with a weak pull-up and maybe the result is the same.

I'll set the counter to count the maximum lock time as specified in the datasheet and I should be good to go. Synchronous release of the reset line should make it simple to perform STA on the reset line and let the P&R meet the time constraints.

In the OP, I was asking whether I should route the reset signal (currently coming from the 'lock' signal on the pll) to a special global net to avoid timing issues. After my post, Mark pointed out how unreliable are 'lock' signals from PLL and hence the whole discussion.

That is a valid suggestion, I used to believe that places like this one would have been good ones to get an answer from an FAE, but it seems those days are gone and companies tend to continue to lock in users within their closed circles .

Ok, I think I understand the problem now. The fact that you are working on a space application makes it more clear why you are using an Actel part. I think space applications are what kept Actel alive for so many years.

So you have a poor hardware design that you can't change and you are looking for some trick within the FPGA to generate a power on reset. I'm still not clear on why you can't use the PLL lock signal with conditioning. If the PLL lock signal is deasserted at power on, there is your power on reset. Then you simply need to condition it well enough to properly control exit from reset reliably.

Am I still missing something?

Hi Rick,

On 16/10/2013 10:29, rickman wrote: []

and automotive, avionics, defense, just to mention a few more.

correct.

Maybe you missed what I wrote in my previous post in reply to your suggestion, so I'll paste it here for your convenience:

Exactly as you proposed but specifying the length of the counter.

Indeed there's even a more subtle detail to add: since I do not know what is the state of the lock signal at power up, my counter should have a fixed value at reset and start to count when lock signal is deasserted if and only if the fixed value of the counter is present. In this way I can guarantee that a lock signal which is undefined at the beginning does not allow the counter to start from a random position and hit the target value too early. Something along these lines:

-- rst is the lock signal from PLL process (clk, rst) if rst = '0' then counter

Well one hack is to make a probabilistically correct reset pulse generator. Use a counter to generate a reset pulse and use random values for the start and end of the pulse. The counter will come up in some random state, but most of the time you will still get a good reset pulse. With enough bits you should be able to get the chance of failure to be very small.. I suspect an asynchronous counter will be better for this since (if you can make on ein Igloo) it will be less likely that a clock glitch will upset the entire count value.

I might do it if the FPGA is running an experiment. I would not do it if the FPGA is for a flight critical system: but then you should have TMR anyway.

Here is the idea in code:

reg [7:0] cntr_1; // Powers up to some random value.. reg [7:0] cntr_2; // Chance is not high that they all power up to reg [7:0] cntr_3; // their final value. reg [7:0] cntr_4;

reg reset_l_1; reg reset_l_2; reg reset_l; // Main reset net

always @(posedge clk) begin if (lock && cntr_1 != 8'h55) cntr_1

This really doesn't solve the problem. The problem is that globally resetting all the state machines in a design can tax the routing and timing of the global reset signal. If you do this the routing problem can be fixed by resynchronizing the reset to the clock before using it in a given section of logic that should be geographically local on the chip. Otherwise you can give P&R some very tough problems to solve.