Lattice MachXO2 reset

Question

After reading about GSR/PUR facilities in Lattice FPGAs, I'm still a bit puzzled about how to actually get the proper GSR/PUR-based reset functionality on an actual physical FPGA chip.

In the How to Use GSR and PUR application note, they show this Verilog example:

GSR  GSR_INST (.GSR (<global reset sig>));

suggesting that .GSR corresponds to an input, thus <global reset sig> would be mapped to an external pin (as I understood it).

But then, how do I use the output of that GSR_INST ? I distinctly remember that they say that the reset is active-low given the underlying circuitry. However, in the HDL Coding Guidelines, page 38/39, they show (Verilog version):

reg[1:0] state;
reg dout;

always @(posedge clk or posedge rst)
    if (rst) begin
        state <= idle;
        dout <= 1'b0;
    end
    else begin
    case (state)
    // ···

That rst looks like an active-high reset signal (otherwise the code wouldn't make sense / wouldn't work). So, is rst a reserved keyword that corresponds to the output of the GSR_INST, and it is implicitly available anywhere I need it?

In short: how do I put the pieces together? (taking advantage of the GSR functionality, that is). I'm ok with or without automatic/implicit power-up reset (I can externally assert the reset pin of the FPGA for a few milliseconds after power-up). But I would still like to know about how to set it up both ways.

I mean, it's on page 2 of the "How to Use" document. Unless your confusion is that you think that because you write a consistent active-high reset, it will also reach the GSR high after synthesis? — DonFusili, Oct 09 '19 at 14:29
@DonFusili -- What is on page 2? Page 2 talks about use cases and how to choose the right use case; but, e.g., with inferred GSR: it does not say what inferred GSR really is/means, or how do I use it. There is the **Note** that talks about "connect elements with an asynchronous reset to GSR. I have no idea what that is supposed to tell me in terms of _how do I implement the functionality_. It sounds like the tool would determine from the HDL code that something is an asynchronous reset; but how could it do that? (e.g., in the sample; how does it know that `clk` is not the async. reset?) — Cal-linux, Oct 09 '19 at 15:13
If you don't instantiate the GSR, Diamond just routes your reset like any other signal. If you pass the name of the reset to the GSR module input, Diamond now knows to use the GSR hardware and not waste resources you might otherwise need for non-reset purposes. — Bort, Oct 09 '19 at 15:17
Also, something that I forgot to explicitly mention in the original question: I'm a beginner with FPGA and HDL (I mean, not an absolute beginner, but still). I'm getting the feeling that there are certain basic things that, if I knew them, then what the document says should be obvious to me? — Cal-linux, Oct 09 '19 at 15:17

score 1 · Answer 1 · answered Oct 09 '19 at 14:46

The wire/signal passed to the instantiation of the GSR module just tells Lattice Diamond that that signal is the signal that should use the resource-saving GSR hardware. You can call it whatever you want. There is no output of the GSR module; it's not a buffer or something.

You can also pass nothing into it, e.g., GSR GSR_INST (.GSR ());, so it's a) simulatable (sometimes Diamond/Active-HDL throws errors if you don't instantiate a GSR block in your design, even if you're not using it) and b) an option for later. I've done this so it doesn't slip my mind but before my reset scheme is totally nailed down.

Lattice MachXO2 reset

1 Answers1