From: ed on
Hi all,

I'm having a problem where I'm not getting initialized how I expect
after startup on a Spartan-3E.

For example, one of my state machines is not in its initial state
after startup, even though that state is coded all zeros.

I don't have access to an external reset, so I have to generate one
internally somehow...

Does anyone have any ideas?

Thanks,
Ed
From: Gabor on
On Nov 3, 2:25 pm, ed <ed.agu...(a)gmail.com> wrote:
> Hi all,
>
> I'm having a problem where I'm not getting initialized how I expect
> after startup on a Spartan-3E.
>
> For example, one of my state machines is not in its initial state
> after startup, even though that state is coded all zeros.
>
> I don't have access to an external reset, so I have to generate one
> internally somehow...
>
> Does anyone have any ideas?
>
> Thanks,
> Ed

Standard practice on Xilinx devices when you have no reset signal
is to instantiate a few flip-flops to form a short shift register.
For an active high reset, use FDP (asynch preset, also preset on
start-up / config). In verilog it looks like:

wire [2:0] rst_sr;
wire sys_reset;

FDP rst_ffs [3:0]
(
.D ({rst_sr,1'b0}), // shift in zero from right
.Q ({sys_reset,rst_str}),
.PRE (1'b0), // Only preset on config
.C (clock)
);

If you have trouble with state machine startup it's also a
good practice to have a post-reset state that does nothing
but drop into the idle state. This extra state acts like
a synchronous reset to the remainder of the FSM. This is
especially important with Xilinx tools which usually one-hot
encode your state logic (so starting up "all zero" doesn't
make any difference).

HTH,
Gabor
From: backhus on
On 3 Nov., 20:25, ed <ed.agu...(a)gmail.com> wrote:
> Hi all,
>
> I'm having a problem where I'm not getting initialized how I expect
> after startup on a Spartan-3E.
>
> For example, one of my state machines is not in its initial state
> after startup, even though that state is coded all zeros.
>
> I don't have access to an external reset, so I have to generate one
> internally somehow...
>
> Does anyone have any ideas?
>
> Thanks,
> Ed

Hi Ed,
Xilinx FPGAs have a primitive element called STARTUP which provides
you with a global Reset signal and other stuff.
Check the library guide or the ISE template browser on how to
instantiate it.

Another (Xilinx XST specific) option is to assign default values to
your FSM signals:
e.g.
signal mystate : state_type := INITIAL_STATE;

This value is normally only used for simulation, but XST also puts it
into the bitstream as an initial value for the FFs after power up.

Also, If you use DCMs you can use the LOCKED signal for resetting
purposes.


Have a nice synthesis.
Eilert
From: ed on
On Nov 3, 10:50 pm, backhus <goo...(a)twinmail.de> wrote:
> On 3 Nov., 20:25, ed <ed.agu...(a)gmail.com> wrote:
>
> > Hi all,
>
> > I'm having a problem where I'm not getting initialized how I expect
> > after startup on a Spartan-3E.
>
> > For example, one of my state machines is not in its initial state
> > after startup, even though that state is coded all zeros.
>
> > I don't have access to an external reset, so I have to generate one
> > internally somehow...
>
> > Does anyone have any ideas?
>
> > Thanks,
> > Ed
>
> Hi Ed,
> Xilinx FPGAs have a primitive element  called STARTUP which provides
> you with a global Reset signal and other stuff.
> Check the library guide or the ISE template browser on how to
> instantiate it.
>
> Another (Xilinx XST specific) option is to assign default values to
> your FSM signals:
> e.g.
>  signal mystate : state_type := INITIAL_STATE;
>
> This value is normally only used for simulation, but XST also puts it
> into the bitstream as an initial value for the FFs after power up.
>
> Also, If you use DCMs you can use the LOCKED signal for resetting
> purposes.
>
> Have a nice synthesis.
>   Eilert

I thought that if enumerated states are used, then most synthesis
tools will use the left-most state as it's initial state. Isn't that
correct?

I'm not using XST. I'm using Synplify Pro and it is sequentially
coding the initial state to all zeros, which is what I would expect
the device to be in after configuration... but that's not the case.
After configuration, the state is reading "110". I don't understand
why this is happening.

Thanks for the shift-register reset tip. I will try that.
From: ed on
Just implemented the shift-register reset. Worked like a champ!
Thanks :)

But I still want to know why the state machine didn't start in its
initial state after configuration....