Internal POR on MachX02 - Page 1
Forum section: electronics / general

author: bson
author_rank: Unknown
timestamp: August 16, 2024, 07:54:18 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2024, 08:32:28 pm
content: 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.

author: bson
author_rank: Unknown
timestamp: August 17, 2024, 06:56:10 pm
content: 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. Iassumethey'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.)

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2024, 09:41:07 pm
content: So, if you just writeCode: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 workCode:reg n_reset =1'b0; // initialization to 0will happen regardlessalways @(posedge clk)n_reset <= 1'b1;The default state is described in the main device datasheet:QuoteTheir documentation structure is pretty much the same as for any other FPGA vendor. I had no issue finding information I needed.

author: bson
author_rank: Unknown
timestamp: August 17, 2024, 10:48:18 pm
content: Hmm. LSE completely ignores the initializer. Synplify Pro actually seems to use it... that'll make things a lot easier.

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2024, 10:52:09 pm
content: I only use LSE and it absolutely does not ignore the initialization.

author: bson
author_rank: Unknown
timestamp: August 17, 2024, 10:52:26 pm
content: Quote from: ataradov on August 17, 2024, 09:41:07 pmIt doesn't say what the state is on power-on but before the device has booted/configured itself. One canguessthat it's the erased state, but in reality I will need to check this assumption.

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2024, 10:57:22 pm
content: It starts configuration on power-on, so this is the state on power on.

author: bson
author_rank: Unknown
timestamp: August 17, 2024, 11:05:13 pm
content: Quote from: ataradov on August 17, 2024, 10:52:09 pmOoh, that's interesting. That means I've done something stupid... Thanks!

author: bson
author_rank: Unknown
timestamp: September 09, 2024, 01:39:47 am
content: 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 bootPads are Hi-Z'd during bootOnce it has booted the pads are enabled and my logic becomes activeThis 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).

author: ataradov
author_rank: Super Contributor
timestamp: September 09, 2024, 02:00:11 am
content: 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.

author: bson
author_rank: Unknown
timestamp: September 09, 2024, 02:34:59 pm
content: Thank you, this is exactly what I needed to know!

author: bson
author_rank: Unknown
timestamp: September 09, 2024, 03:37:22 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 09, 2024, 04:02:46 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 09, 2024, 09:31:06 pm
content: Quote from: ataradov on September 09, 2024, 04:02:46 pmWell, 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.