reset

There are many ways to do this--here's one idea:

You can use the conf_done pin to trigger a reset chip (maxim/dallas has plenty of choices) and tie it to the appropriate pin on the FPGA, probably the DEV_CLRn (device wide asynchronous reset).

or use something like

ff_resetn:process(boot_clk) begin if (boot_clk'event and boot_clk='1') then if (reset_cnt/="111") then reset_cnt

How do you know which value "reset_cnt" will start with after configuration ? Rgds Andr=E9

If you are reconfiguring the part on reset, why do you want to reset the design again? The design will come up in the "reset" state after configuration. Perhaps I'm missing something, but it seems redundant to async reset an FPGA right after configuration?

you just write

signal reset_cnt : std_logic_vector(2 downto 0) := (others=>'0');

so that when the FPGA is configured it always starts at 0

No.

:= (others=>'0');

in signal declarations are not synthesizable.

Rgds

Whether or not it is synthesizable depends on the synthesis tool and the target device. Specifying the power up default value for the output of a clocked register certainly can be synthesizable. In fact both brand 'A' and brand 'X' (and I'm sure others) FPGAs do specify that registers are reset at the completion of configuration which is the FPGA equivalent of 'power up' so the construct certainly is synthesizable.

One should tread with care though and probably limit the usage of default values to only those signals that have to do directly with generating the internal reset signal as was mentioned earlier in the post. One should probably also only try to only use a default value of '0' as well since most (all?) FPGAs will clear the flip flops not set some of them to '0' and others to '1'. There is a very simple technique that can be used that would allow a default value of '1' to be specified in the code even though the flip flop resets to '0' but then you'll be counting on the synthesis tool to implement this.

KJ

The synthesis tools I have used correctly synthesize even non '0' declaration initializations, and X does support non '0' initialization. And this is very handy in a lot of places. For example, I often use this to set the default value of registers, since I know that software will not attempt to change the registers until long after the FPGA has initialized.

One case might be when you want the reset behaviour to set a flip flop to '1' instead of '0' (like in a one hot state machine encoding) and the synthesis tool/target device combo doesn't happen to support this. If you have this, then the problem is with the synthesis tool (so open a service request and raise your beef) but in the mean time you need a work around. So if you happen to have that particular scenario, but your device globally clears all flip flops to 0 then you could use the "reset to 0 coming out of configuration" to create an internal reset signal for the rest of the design. Then you use that internal reset signal to put the entire design into the state that you want as specified by your HDL instead of as specified by the device manufacturer.

KJ

Or just invert the inputs and outputs of the ff you need initialized to a '1'.

That can work in certain instances, but you'll have difficulty 'inverting' an enumerated type signal that gets encoded via a one hot (or any other) encoding. See the following code snippet below for a good example. Generating the reset signal itself is much cleaner and puts the device into a state as defined by the HDL code itself and not in some arbitrary (but useful) predefined state that has been defined by the FPGA/CPLD vendor.

type t_FOO is (Init, Idle, Do_Something, Do_Something_Else, Phone_Home); signal My_State_Variable: t_FOO; ... process(Clock) begin if rising_edge(Clock) then if (Reset = '1') then My_State_Variable

That depends on your synthesiser. If you are initalising to some constant value that the synth can figure out, XST can do it and I think Synplify does it as well.

About time too, given that the hardware has been able to use it for years (or even decades!)

Cheers, Martin

Don't know about Stratix, but I guess there may be timing problems with the configuration reset, so you might want to do a proper timed reset afterwards.

Many Xilinx devices will let you set a F/F to one level on GSR, and the opposite level on a 'normal' reset, by setting SRHIGH(LOW) differently from INIT1(0). What's the point of that? Beats me.

Curiously, in the Spartan-3 you get an INIT attribute to set SRHIGH/SRLOW, but no attribute to set INIT1/INIT0. To set those you have to manually instantiate an FDSE/FDPE or an FDRE/FDCE component. Did Xilinx give us the wrong attribute? If we had something to set INIT1/0 instead, then SRHIGH/LOW would automatically default "correctly", and you wouldn't need to manually select a set or a reset F/F.

And how about a sync/async attribute? I can't find one of those either.

Evan

But in that case, you don't care what the encoding is, so you don't need to be specifying a particular flip flop get set to '1'.

For the xilinx devices, you can use the ROC primitive to generate a power on reset in your HDL code. The tools pull it out, but in the process in guarantees the setting of the initial values to the states you want them in.

POR: roc port map(O => power_on_reset);

process(clk,power_on_reset) begin if power_on_reset = '1' then elsif rising_edge(clk) then