Internal POR on MachX02

[bson]

Am I correct in my understanding that the MachX02 can't generate an internal power-on reset?  That the PUR primitive is purely a simulation of an external reset pulse?

[ataradov]

There is no dedicated reset signal, but all the initialized registers will get their values on a power up. So, you can emulate explicit POR signal via a single bit register that is set at the initialization time and is cleared on the first clock cycle.

[bson]

I use Synplify Pro which unfortunately doesn't seem to support setting initial conditions, at least not on Lattice parts...

Dedicating a pin to a reset input isn't a big deal, I was just hoping it wouldn't be necessary.

I also don't see what state pins are in prior to initial configuration, so for like the first 1ms.  I assume they're hiZ, but I find this mentioned nowhere in their documentation, but it's really hard to find anything in it as it's more or less gratuitously split over 20 PDFs, found in several different places on their site.  Makes me appreciate the very large self-contained datasheets or manuals from other vendors...  (Lattice seems to suffer from the common engineering over-normalization disease.)

[ataradov]

So, if you just write

Code: [Select]

reg test_reg = 1'b1 , you won't end up with a test_reg initialized to logic high? This seems like a serious limitation.

I think initialization value is part of the bit-stream, so it has to be set to something. I assume initialization to 0 is guaranteed in that case, so something like this would work

Code: [Select]

reg n_reset =1'b0; // initialization to 0will happen regardless

always @(posedge clk)
  n_reset <= 1'b1;

The default state is described in the main device datasheet:

During configuration of the user-programmable I/Os, the user has an option to tristate the
I/Os and enable an internal pull-up resistor. This option also applies to unused pins (or
those not bonded to a package pin). The default during configuration is for user-program-
mable I/Os to be tristated with an internal pull-up resistor enabled. When the device is
erased, I/Os will be tristated with an internal pull-up resistor enabled.

Their documentation structure is pretty much the same as for any other FPGA vendor. I had no issue finding information I needed.

[bson]

Hmm.  LSE completely ignores the initializer.  Synplify Pro actually seems to use it... that'll make things a lot easier.

[ataradov]

I only use LSE and it absolutely does not ignore the initialization.

[bson]

The default state is described in the main device datasheet:

During configuration of the user-programmable I/Os, the user has an option to tristate the
I/Os and enable an internal pull-up resistor. This option also applies to unused pins (or
those not bonded to a package pin). The default during configuration is for user-program-
mable I/Os to be tristated with an internal pull-up resistor enabled. When the device is
erased, I/Os will be tristated with an internal pull-up resistor enabled.

It doesn't say what the state is on power-on but before the device has booted/configured itself.  One can guess that it's the erased state, but in reality I will need to check this assumption.

[ataradov]

It starts configuration on power-on, so this is the state on power on.

[bson]

I only use LSE and it absolutely does not ignore the initialization.

Ooh, that's interesting.  That means I've done something stupid...  Thanks!

[bson]

One thing I have a hard time finding documentation for is what the startup looks like... I see mentioned that it's "less than 1ms".

Is this a reasonable assumption?

• At power-on it internally holds the declared GSR net active during boot
• Pads are Hi-Z'd during boot
• Once it has booted the pads are enabled and my logic becomes active
• This occurs at less than 1ms following power-on (however that is defined)

This is important, because the MXO2 performs all address decoding and generates chip selects, data and latch controls, and so until it's active everything else absolutely needs to be held in reset.  A weak pulldown on the global reset should do fine, if my assumptions above are correct... Never mind that it's also the source of a couple of clocks, so if without it running nothing would work anyway (and would get into a weird state that definitely needs a reset to get out of).

The GSR net is not routed to an external pin, instead that is a logical product of various things (for example if the PLL loses lock it produces an external reset but not an internal one).

[ataradov]

At power up all pins are Hi-Z. After voltage reaches minimal POR level, device assets INIT and DONE pins and starts the configuration process (assuming INIT is not held low externally).  What specific voltages are monitored depends on the device variant (HC vs non-HC). After configuration is done, DONE pin is released and the I/O pins take their state based on the user config. This process takes less than 1 ms (the value is only true for 256 and 640 versions, 7000 takes up to 3.8 ms).

What happens inside the device during configuration is irrelevant, since I/O pins are Hi-Z.

[bson]

Thank you, this is exactly what I needed to know!

[bson]

Of course, no sooner did I post that than I found the documentation for this...  It's described in good detail in Section 5 of TN-02155 (MachXO2 Programming and Configuration User Guide).  Especially the Wake-up stage in 5.4 has the meat and potatoes details.

Immediately after loading the flash into SRAM the device enables user pins at the same time as it asserts GSR and GWDIS# (global write disable).

The reason for GWDIS# is that as soon as the user pins are enabled inputs become active and external signals controlling logic not gated or reset by GSR could cause internal RAM to be written to and corrupted.  Especially with parts of the logic inactive due to GSR.  GWDIS# gates RAM write enables/strobes.

The GSR is hard tied to all logic state (FFs etc) and causes them to take on their initialization values.

GSR and GWDIS# are simultaneously deasserted.

DONE is asserted to indicate the device is in User Mode.

[ataradov]

GSR primitive is not an actual connection to the GSR net. It is just a virtual primitive for simulation purposes. I don't know if there us a way to assert GSR from the user logic.

[SiliconWizard]

GSR primitive is not an actual connection to the GSR net. It is just a virtual primitive for simulation purposes. I don't know if there us a way to assert GSR from the user logic.

Well, if you use an asynchronous reset in all or some of your processes, it will usually be tied to the GSR tree. If you use only one async reset signal in your whole design, it's likely what will happen (but check the reports). If you use several different async reset signals, the tool will pick the one that makes the most "sense" to it - usually the one that's distributed across the most LUTs.

Now the "source" of this async reset signal matters. If it's an IO (used as a reset pin), selected appropriately (usually one of the global clock things), that should work. If it's an internal signal, not necessarily. Again, check the reports.

And whether you're comfortable using async resets is another story. If done with care, it's usable.
I've never used any signal initialization in HDL with these chips and have only initialized signals in async resets in processes and it's always worked as expected. Whether it's the right approach in any particular case is yours to determine.