Altera ACEX chip wide reset

Rick,

When the ACEX device is initialized after configuration, or when you assert the Chip Wide Reset, the FFs are all set to 0. There are two ways of achieving your goal of having an FF power up to 1.

1. You can code the VHDL so that you end up with a NOT gate before the D of the FF, and another NOT gate after the Q of the FF. Any logic that the FF drives would actually be driven by the NOT gate in the HDL. When the FF powers up at 0, it will appear as 1 by the rest of the logic. But in normal operation, the double-negation will have no effect. You'll have to be careful with simulation however, since the FF's value will be the opposite of what you expect. This works in MAX+PLUS II or Quartus II as it's simply an HDL code.

1. Quartus II has an ACF setting called "POWER_UP_LEVEL". You can set this to HIGH or LOW for an individual register. You can apply this setting using the Assignment Editor or in the HDL using the "altera_attribute" syntax. Here's an example:

signal my_reg : std_logic attribute altera_attribute : string; attribute altera_attribute of my_reg : signal is "POWER_UP_LEVEL=HIGH";

Either approach works - just depends on whether you would rather modify the HDL or change assignments.

Sincerely, Greg Steinke snipped-for-privacy@altera.com Altera Corporation

IIRC the 10K, on which the 1K is based, cannot do a preset without NOT gates anyway, irrespective of whether it's a chip-side reset, or not. If you write an aync reset clause that initialises something to a '1', Synplify (at least) will put the appropriate NOT gates in for you. Which will then hammer your tco for any pins you want to default to a '1' - like ooh, maybe a chip-select.... Not that I bear the scars or anything :-)

I assume this only affects the configuration bitstream, not how the chip-wide reset behaves? Or have I misunderstood the chip-wide reset?

Cheers, Martin

Martin, The ACEX 1K (and FLEX 10K) LE has an async clear and an async load. An async preset could be implemented by the NOT technique or by using the async load. A design that uses just the preset will generally end up using the NOT technique, whereas a design that uses a preset and a clear will use the async load technique.

The IO Element has a programmable inversion in it to accomodate the NOT technique. So for example if an LE register drives a pin, and the design calls for the register to be async preset, the compiler will use the NOT technique and implement the after-register NOT in the IOE. However, the best tCO is obtained by using the IOE register, and the programmable inversion is before the D of the IOE register. So there is no way to implement an async preset in the IOE, which is probably the reason for the tCO pushout that you saw - the register was moved into an LE which increases tCO.

If you see a design where an async-preset LE drives a pin, and there's an extra LE put into the path to implement the NOT gate, this is a bug and should be reported to Altera and/or Synplicity. But I'll bet that the tCO pushout is due to the register moving from the IOE to the LE.

You will be happy to know that we have enhanced the IOE registers of the Stratix and Cyclone FPGAs. In these devices, you can choose to have an async clear or async preset on an IOE. This is selectable per IOE. Furthermore, an IOE register that uses the async preset will power up high. Perfect for your active-low chip select.

For the second question - In ACEX 1K FPGAs, on the silicon level, the chip-wide reset sets all the registers to zero. The NOT technique that I proposed simply modifies the LUT that feeds the register, and the LUTs that the register feeds, to add the NOT gates. (Through the configuration bitstream as you suggest.) If you were to microprobe the register, you would see it go low when chip-wide reset is asserted. But every case where that register is used now would have a NOT gate, so it would seem to go high.

Sincerely, Greg Steinke snipped-for-privacy@altera.com Altera Corporation

True - my memory was only of the IOEs. However, if you want a preset, you have to sacrifice DATA3 in the LUT according to my datasheet (as implicated by the use of the term "load" rather than "preset"). I knew I'd recalled something about presets not being quite as "free" as resets :-)

Yes, that is what was happening - it was a while ago, I remember now! What happens to the power-up (not reset) behaviour? Does it still power up low until the reset occurs?

Good stuff!

OK, that's clear enough (although Figure 12 of the datasheet implies that chip-wide reset *can* do a preset of the FF)

But does the POWER_UP_LEVEL technique infer NOT gates as in solution

Cheers, Martin

The data sheet is one thing. But I was asking about how to get the FF to use whatever is available. From what I read in the data sheet, it looks like a preset can be done by putting a 1 on DATA3. This will also become part of the power on reset as well as the reset pin function. But it also appears that to use it I have to provide an async set in my code separate from the global reset.

Either way this does not look good.

One small detail - on these Async resets, how is reset recovery ( trailing edge of ASYNC RST, to any appearing Clocks ) handled inside the device ?

-jg

It's not, just like any other async reset. You need to either provide a sync reset to critical logic or design it so that it has a couple of post reset states that only vary by one FF, like a gray code.

Rick, If you do a preset by putting the 1 on the DATA3 and doing an async load, then the register will power up low, and the Chip Wide Reset will force the register low. The advantage here is that you can have async preset and async clr as separate controls. The disadvantage is that it takes up one of the LUT inputs.

If you do the preset by putting a NOT gate before the D, and another after the Q, then the register will appear to power up high, and the Chip Wide Reset will appear to force the register high. (In reality it is low, but it seems high due to the NOT.) The advantage here is that it is free (unless you need fast tCO as this technique can't be done in the ACEX IOE). The disadvantage is that you cannot have a preset and clear on the same FF.

Sincerely, Greg Steinke snipped-for-privacy@altera.com Altera Corporation

At this point, I understand the ACEX hardware. But I can't put gates anywhere. I am asking how to control this from my VHDL. In the Xilinx parts, you use a symbol to drive a global reset net. The tools then remove the symbol and use the GSR feature to control the FFs reset function. I have no idea how to do this in VHDL for the ACEX parts.

Hi Rick, sorry that I didn't understand the question!

To use the chip wide reset, you turn on an option in the tool (whether Quartus II or MAX+PLUS II). You do not code it in VHDL. In MAX+PLUS II, this is enabled through the Enable Chip-Wide Reset option in the MAX+PLUS II software under Global Project Device Settings (Assign menu). In Quartus II you can do this through the Assignment Editor.

If you want to use some of the global reset lines (different from the chip wide reset), you can code that in VHDL and they will be used automatically as long as you don't use more than exist. If you use more than exist than the non-global routing will be used.

Sincerely, Greg Steinke snipped-for-privacy@altera.com Altera Corporation

Ok, thanks. But I am still a bit confused about how to get a FF preset. Even if this uses the inverter method, how does the synthesis tool know my FF output is active low vs. active high? Everything I read seems to indicate that this is only controled if you are using explicit signals to preset/clear the FF and the chipwide reset will operate the same way this explicit signal works. I don't want to use an explicit reset signal, I only want to use the chipwide signal, but I still want to make some FFs presettable. Do I have to make my HDL code reflect this explicitly by making every signal default state a '0'?

Rick, for what it's worth: I got totally screwed by this. I implemented what I thought was a pretty simple four-state one-hot machine. Leonardo and Precision Synthesis did the right thing with it, and Quartus told me I met timing -- yet in the real hardware the state machine hung in an illegal state.

The good thing was that the back-annotated timing simulation using my test bench failed in the same way as the real hardware, but it wasn't clear why until I spoke with an Altera FAE. Yeah, my one-hot state machine came out of reset in an illegal state: 4'b0000. So I haven't quite figured out how to fix this.

I was going to try a couple of the fitter magic switches, and maybe force it to use binary encoding, but I've been busy with something else.

This is exactly what I am talking about. Even though the synthesis tool is capable of inverting a FF input and output in the logic equations so that a reset to zero operates as a preset to one, there has to be a way to tell the tool in your HDL that it needs to do this on a given FF.