From: ed on 3 Nov 2009 14:25 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 3 Nov 2009 16:57 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 4 Nov 2009 01:50 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 4 Nov 2009 13:39 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 4 Nov 2009 14:51 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....
|
Next
|
Last
Pages: 1 2 Prev: ModelSim view internal signals in instantiated verilog modules Next: Cyclone IV announced |