 |
|
| Computers Forum Index » Computer Architecture - FPGA » initialization issues on Spartan-3E after startup... |
|
Page 1 of 1 |
|
| Author |
Message |
| ed... |
 Posted: Tue Nov 03, 2009 7:25 pm |
|
|
|
Guest
|
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 |
|
|
| Back to top |
|
|
|
| Gabor... |
| Posted: Tue Nov 03, 2009 9:57 pm |
|
|
|
Guest
|
On Nov 3, 2:25 pm, ed <ed.agu... at (no spam) gmail.com> wrote:
Quote: 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 |
|
|
| Back to top |
|
|
|
| ed... |
| Posted: Wed Nov 04, 2009 6:39 pm |
|
|
|
Guest
|
On Nov 3, 10:50 pm, backhus <goo... at (no spam) twinmail.de> wrote:
Quote: On 3 Nov., 20:25, ed <ed.agu... at (no spam) 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. |
|
|
| Back to top |
|
|
|
| ed... |
| Posted: Wed Nov 04, 2009 7:51 pm |
|
|
|
Guest
|
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.... |
|
|
| Back to top |
|
|
|
| Gabor... |
| Posted: Wed Nov 04, 2009 8:44 pm |
|
|
|
Guest
|
On Nov 4, 2:51 pm, ed <ed.agu... at (no spam) gmail.com> wrote:
Quote: 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....
A typical scenario is this:
1) Global Set & Reset is released at the end of configuration,
asynchronous to any clock in the design and with variable delay
throughout the device.
2) Your state machine is "released" from its initial state,
one bit of the state variable at a time. If your clock is
slow you might see the release of reset to all bits in the
same clock period MOST of the time.
3) If not all bits start up at once, your next state can be
different for different bits of the state variable. In the
case of a one-hot state machine, this can lead to a zero-hot
or multiple-hot state.
The effects of asynchronous start-up is magnified when the
the clock is at a higher speed and/or the state logic is
placed over a large area of the device.
Regards,
Gabor |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Tue Dec 01, 2009 5:16 pm
|
|