Register with a default Value

[Nemesis]

On Jan 5, 9:56 am, Nemesis <gnemesis2...@gmail.com> wrote:

I missed the attribute INIT (it is Xilinx specific right?).
Now it is working in simulation, I hope to test it on the board today.
Thanks.

.... no I'm wrong it's not working even in simulation, that's the code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity top_reg is
Port ( clk : in STD_LOGIC;
reset : in STD_LOGIC;
d : in STD_LOGIC_VECTOR (23 downto 0);
load : in std_logic;
q1 : out STD_LOGIC_VECTOR (23 downto 0)

);
end top_reg;

architecture Behavioral of top_reg is
signal not_reset : std_logic;
attribute INIT : string;
signal q_int_1 : std_logic_vector(23 downto 0) :"101010101010101010101010";
attribute INIT of q_int_1 : signal is "101010101010101010101010";


component LE_REG
generic (N_bit : integer);
port(CLK : in std_logic;
D : in std_logic_vector(N_bit-1 downto 0);
Q : out std_logic_vector (N_bit-1 downto 0);
ENABLE : in std_logic;
LOAD : in std_logic;
RESET : in std_logic
);
end component;

begin
not_reset <= not reset;

reg_1: LE_REG
generic map (N_bit => 24)
port map(
CLK => CLK,
RESET => RESET,
ENABLE => not_reset,
LOAD => load,
D => D,
Q => q_int_1
);

q1 <= q_int_1;
end Behavioral;

where LE_REG is:

library ieee;
use ieee.std_logic_1164.all;

entity LE_REG is
generic (N_bit : integer);
port(CLK : in std_logic;
D : in std_logic_vector(N_bit-1 downto 0);
Q : out std_logic_vector (N_bit-1 downto 0);
ENABLE : in std_logic;
LOAD : in std_logic;
RESET : in std_logic
);
end entity LE_REG;

architecture BEHAVIORAL of LE_REG is

-- attribute keep_hierarchy : string;
-- attribute keep_hierarchy of BEHAVIORAL : architecture is
"yes";


begin
process (clk, reset)
begin
if (reset='1') then
Q <= (others => '0');
elsif clk='1' and clk'event then
if (enable='1') then
if (load='1') then
Q <= D;
end if;
end if;
end if;
end process;
end architecture BEHAVIORAL;

 

[Nemesis]

On Jan 5, 9:23 am, Jan Pech <inva...@void.domain> wrote:

On Fri, 2009-01-02 at 21:51 +0000, Nemesis wrote:
Jan Pech wrote:

I use only Xilinx Tools, to be more precise XILINX ISE 8.2.

I do not believe that solution with thedefaultvaluedoes not work with
ISE. I use it sometimes and it works well with ISE 6.3/7.1/8.2/9.2/10..1.

Do you have any code snippets?

I just created aregisterwith async reset, and set thedefaultvalueon its
output net ... and with the simulation I saw that thevalueis ignored, I also
tested the solution on the target board and got the same result.

If I need aregisterwith presetvalue, I simply assign it thedefaultvaluelike in the following code snippet. It works fine with both
ModelSim simulation and ISE XST synthesis.

.... hmmm but I tried a similar approach, it didn't work for me ...

 

[Nemesis]

On Jan 5, 10:11 am, Nemesis <gnemesis2...@gmail.com> wrote:

On Jan 5, 9:56 am, Nemesis <gnemesis2...@gmail.com> wrote:

I missed the attribute INIT (it is Xilinx specific right?).
Now it is working in simulation, I hope to test it on the board today.
Thanks.

... no I'm wrong it's not working even in simulation, that's the code:
....

OK I figured out the problem.

I have to move all the initialization stuff inside the external module
LE_REG.VHD

Thanks to all.

 

[Andy Peters]

On Jan 2, 7:24 am, kennheinr...@sympatico.ca wrote:

In my personal opinion, it's a bad idea to try to do this in the first
place. One of the commandments that came down from the Mount on stone
tablets was "Thou shalt have an external reset on every device which
dang well resets the thing!". If you rely on power-up or load
conditions that cannot be repeated when you externally reset the
device, then your reset is, by definition, not really a reset and
violates the commandment. If you don't have a reset, then you can't
control the state of your FPGA, and you're just asking for trouble in
a big way.

One could argue that if the FPGA goes so tits-up (perhaps from x-rays
or other weirdness) that it requires a global reset, it might be
better to simply reconfigure the device.

-a

 

[Ken Cecka]

Andy Peters wrote:

On Jan 2, 7:24 am, kennheinr...@sympatico.ca wrote:

In my personal opinion, it's a bad idea to try to do this in the first
place. One of the commandments that came down from the Mount on stone
tablets was "Thou shalt have an external reset on every device which
dang well resets the thing!". If you rely on power-up or load
conditions that cannot be repeated when you externally reset the
device, then your reset is, by definition, not really a reset and
violates the commandment. If you don't have a reset, then you can't
control the state of your FPGA, and you're just asking for trouble in
a big way.

One could argue that if the FPGA goes so tits-up (perhaps from x-rays
or other weirdness) that it requires a global reset, it might be
better to simply reconfigure the device.

-a

Yes - along those lines, I've recently taken the stance that a board reset should clear the FPGA since that's the state it would be in at power-up, and I just use a configuration reset as my hard reset. Then I have a register-controlled soft reset.

Ken

 

On Jan 8, 5:47 pm, Ken Cecka <cec...@alumni.washington.edu> wrote:

Andy Peters wrote:
On Jan 2, 7:24 am, kennheinr...@sympatico.ca wrote:

In my personal opinion, it's a bad idea to try to do this in the first
place. One of the commandments that came down from the Mount on stone
tablets was "Thou shalt have an external reset on every device which
dang well resets the thing!". If you rely on power-up or load
conditions that cannot be repeated when you externally reset the
device, then your reset is, by definition, not really a reset and
violates the commandment. If you don't have a reset, then you can't
control the state of your FPGA, and you're just asking for trouble in
a big way.

One could argue that if the FPGA goes so tits-up (perhaps from x-rays
or other weirdness) that it requires a global reset, it might be
better to simply reconfigure the device.

-a

Yes - along those lines, I've recently taken the stance that a board reset should clear the FPGA since that's the state it would be in at power-up, and I just use a configuration reset as my hard reset.  Then I have a register-controlled soft reset.

Ken

Not entirely sure what you mean... that board reset kills the bitfile
in the FPGA, leaving it in its unprogrammed state? Draconian, bit I
agree with the philosophy (laughs evilly), at least in some cases.

I see something like soft errors (Xray) causing two very distinct
classes of problems: (1) LUTs themselves get corrupted, which means
the device now implements a different logic function than it was
supposed to, and (2) state-holding variables change in bad/unexpected/
nondeterministic ways. If case (1) happens, then you're screwed and
the reset-as-total-FPGA-annihilation strategy makes sense. But if case
(2) happens, its' really immaterial if it was due to Xrays, clock
glitches, or just bad design. My philosophy around (2) is that you
ought to be able to hit the design with with a simple reset and get
the chip up and running again without all the pain and elapsed time of
a full FPGA reconfiguration. By "pain" I mean losing more data than
you really needed to, as well as stuff like syncing software drivers
to the fact that the FPGA vanished from the face of the earth, the PCI
bus may have gone non-responsive (and caused fatal exceptions to be
raised in various micros), etc etc.

The example I like to use (taken from a real design in a deployed
product a few years ago) is that of a video input chip feeding a
recovered clock and data to a brand X series 4000 FPGA. The video
input chip was a multi-standard device and would "hunt" or sweep
across various clock frequencies ranging from 10 MHz to 40 MHz when
the input cable was removed. But when proper video was connected, a
relatively clean 27 MHz was output. The FPGA guy assumed that the
clock was *always* 27 Mhz and set the constraints in the FPGA synth &
PAR to 27 MHz. Then his one-hot state machine got blown out of the
water and went into all kinds of illegal states as soon as the video
input cable was pulled, and 40 Mhz came into his clock, and the timing
constraints were all violated. The FPGA locked up and wouldn't recover
even when legal input was reconnected. The problem was, he couldn't
reset the state machine in the FPGA, because he assumed "why would I
ever need to reset the state machine?", not realizing that the
physical one-hot-hardware in the FPGA could be in states his state
machine never described in the nice little VHDL model.

Now arguably, this design was architecturally flawed from day one and
would have required one of a number of possible solutions, potentially
(1) a hard PLL to limit the clock frequency when the input went
hunting, (2) more paranoid clock constraints of 40 MHz on the FPGA
synth run, which may or may not have been achievable at the time, or
(3) a simple reset, just like I said was on the stone tablet. A simple
reset that the micro (or in this case the "loss-of-carrier" signal)
could have fired is always a good design principle, IMHO. No need to
wait 500 ms for a reload. I strongly encourage all FPGA designs to
have a reset input which is capable of recovering all state-holding
elements so that FPGA reconfig is never required.

- Kenn

 

[Ken Cecka]

kennheinrich@sympatico.ca wrote:

On Jan 8, 5:47 pm, Ken Cecka <cec...@alumni.washington.edu> wrote:
Andy Peters wrote:
On Jan 2, 7:24 am, kennheinr...@sympatico.ca wrote:

In my personal opinion, it's a bad idea to try to do this in the first
place. One of the commandments that came down from the Mount on stone
tablets was "Thou shalt have an external reset on every device which
dang well resets the thing!". If you rely on power-up or load
conditions that cannot be repeated when you externally reset the
device, then your reset is, by definition, not really a reset and
violates the commandment. If you don't have a reset, then you can't
control the state of your FPGA, and you're just asking for trouble in
a big way.

One could argue that if the FPGA goes so tits-up (perhaps from x-rays
or other weirdness) that it requires a global reset, it might be
better to simply reconfigure the device.

-a

Yes - along those lines, I've recently taken the stance that a board
reset should clear the FPGA since that's the state it would be in at
power-up, and I just use a configuration reset as my hard reset. Then I
have a register-controlled soft reset.

Ken

Not entirely sure what you mean... that board reset kills the bitfile
in the FPGA, leaving it in its unprogrammed state? Draconian, bit I
agree with the philosophy (laughs evilly), at least in some cases.

Yep - that's it exactly. Board reset is connected to the Xilinx PROG pin.

glitches, or just bad design. My philosophy around (2) is that you
ought to be able to hit the design with with a simple reset and get
the chip up and running again without all the pain and elapsed time of
a full FPGA reconfiguration. By "pain" I mean losing more data than
you really needed to, as well as stuff like syncing software drivers
to the fact that the FPGA vanished from the face of the earth, the PCI
bus may have gone non-responsive (and caused fatal exceptions to be
raised in various micros), etc etc.

In the case of a board reset, all the syncing is lost anyway as the CPU just got reset too and is in the process of rebooting.

(3) a simple reset, just like I said was on the stone tablet. A simple
reset that the micro (or in this case the "loss-of-carrier" signal)
could have fired is always a good design principle, IMHO. No need to
wait 500 ms for a reload. I strongly encourage all FPGA designs to
have a reset input which is capable of recovering all state-holding
elements so that FPGA reconfig is never required.

I agree completely. I just lean towards implementing the logic reset as a register bit and save myself from consuming an extra GPIO on my CPU. My comments are skewed a little by the hardware designs I'm working with - I pretty much always have a very simple local bus available that I can hang a register with a reset bit off of. If your only interface to the FPGA was something more complex like a PCIe bus, I would lean towards a dedicated reset pin too.

Ken