Register with a default Value
Nemesis
I'm using a virtex4 FPGA, I would like to create a register with a
default value. I'm not talking about a PRESET value, I want that the
register get this value when it is created.
How should I write the VHDL code?
Martin Thompson
Depends on your synthesizer. With XST (at least) you can declare it
as
signal foo : std_logic := '1';
and XST will propagate an INIT attribute onto the flop.
If your synthesizer doesn't do that, you can also use VHDL attributes
with some tools.
Or (non-VHDL) you can put something in the UCF file for the Xilinx
back-end tools to pick up on.
With either of the last two, you need to put the "proper-VHDL"
initialiser in *as well* so that your sims match your FPGA.
Cheers,
Martin
--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
Nemesis
> Nemesis <gnemesis2...@gmail.com> writes:
> > Hi all,
> > I'm using a virtex4 FPGA, I would like to create a register with a
> > default value. I'm not talking about a PRESET value, I want that the
> > register get this value when it is created.
> > How should I write the VHDL code?
>
> Depends on your synthesizer. With XST (at least) you can declare it
> as
>
> signal foo : std_logic := '1';
>
> and XST will propagate an INIT attribute onto the flop.
>
I do use XST, I will try with the default value on the net, thanks
Tricky
Often, if you put an asyncronous reset on the register (even if the
reset is never connected to anything) it will use the async reset
state as the power up state.
Nemesis
> > I do use XST, I will try with the default value on the net, thanks
>
> Often, if you put an asyncronous reset on the register (even if the
> reset is never connected to anything) it will use the async reset
> state as the power up state.
Hmmm OK ... but is it a good design practice? I don't want to write
code that can be misunterpreted.
Tricky
Maybe, maybe not, but if initial states dont work:
eg signal my_sig : std_logic := '1';
Then it may be 2nd best. faffing around with attributes can be a real
ballache. Some attributes dont carry between vendors, but then neither
does support for initial states above, but I think its becoming quite
common.
Sean Durkin
I've been looking for a "clean", portable solution for this as well.
Folks from Xilinx keep telling us that resets, especially asynchronous
ones, are useless in their FPGAs and only eat up routing resources (see
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf or
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf), but
without describing a reset, I can't initialize anything to something
other than '0' (which is the default initial state for FFs as well as
BRAMs). Setting the initial state when declaring the signal seems like a
good solution, but as you mentioned it's not supported by all the tools.
I know Precision Synthesis does not support it. Not that it would be a
technical difficulty, it more seems like a design decision they made. It
issues a warning for every declaration that the initial state will be
ignored for synthesis, so it looks like they chose not to support this
rather than not being able to, for whatever reason.
You can always instantiate every single flip flop and then assign
INIT-attributes, but that just seems rather silly to me and takes away
the advantage of designing in VHDL on a higher level of abstraction and
letting the synthesis tool deal with the low-level architecture specific
details.
The solution you describe with the reset that is not connected might
work most of the time, but it's still not "clean" and not pretty...
cu,
Sean
--
Replace MONTH with the three-letter-abbreviation for the current month.
Simple, eh?
no_sp...@yahoo.fr
global-set/reset, and as Xilinx books say "During implementation, the
signal connected to the output of the ROC component will
automatically be mapped to the Global GSR network and will not be
routed on local
routing."
So Flip-flop are initialyzed at a know state and implementation match
simulation. Moreover, for one block and for particular reason, you can
choose to disconnect this XGSR (Global Set/Reset) and connect an
internal signal (I've already done it for some designs...). I find
it's a "clean" solution.
Regards.
Petro...@hotmail.com
If you want to use straight logic, without any special attributes and
you know for a fact all flip-flops start with the value '0', you can
always invert both the input and output port of the FF.
The output will start at logic '1' and follow the input (because of
the double inversion).
Mike Treseler
>>>>> I do use XST, I will try with the default value on the net, thanks
Simulation will use the initial values from time zero,
so that is not an issue.
Synthesis will work for some FPGAs, but not for ASICs.
The code is clean but not portable.
The biggest problem, is that the "reset" event is
an image file download, not a signal.
For a portable entity, I need a real reset input port
driven by a synchronized reset pulse generator.
That pulse might come from another design entity
or from an external device.
>>> On Dec 18, 3:37 pm, Tricky <Trickyh...@gmail.com> wrote:
>>>> Often, if you put an asynchronous reset on the register (even if the
>>>> reset is never connected to anything) it will use the async reset
>>>> state as the power up state.
Nemesis wrote:
>>> Hmmm OK ... but is it a good design practice? I don't want to write
>>> code that can be misinterpreted.
As long as each design entity has a reset
input port that initializes all the local registers,
the design is fine. Generating and distributing
resets is a system issue.
> Tricky wrote:
>> Some attributes dont carry between vendors ...
Yes. I prefer vhdl code to device specific attributes,
even if a waste a LUT or two.
Sean Durkin wrote:
> Folks from Xilinx keep telling us that resets, especially asynchronous
> ones, are useless in their FPGAs
Following that advice will lock the design to brand X.
-- Mike Treseler
Nemesis
> On 18 Dec, 15:55, Nemesis <gnemesis2...@gmail.com> wrote:
>
> > On Dec 18, 3:37 pm, Tricky <Trickyh...@gmail.com> wrote:
>
>
> > > Often, if you put an asyncronous reset on theregister(even if the
> > > reset is never connected to anything) it will use the async reset
> > > state as the power up state.
>
> > Hmmm OK ... but is it a good design practice? I don't want to write
> > code that can be misunterpreted.
>
> Maybe, maybe not, but if initial states dont work:
>
> eg signal my_sig : std_logic := '1';
>
> Then it may be 2nd best. faffing around with attributes can be a real
> ballache. Some attributes dont carry between vendors, but then neither
> does support for initial states above, but I think its becoming quite
> common.
Here I'm after a while.
I just tested the solution with the default value ... and it doesn't
work, the value is ignored.
I tried the to leave the reset unconnected (with 'open') but it
doesn't compile ...
kennhe...@sympatico.ca
It won't compile unless there's an initializer defined on the reset
input to the component you're instantiating. And why would a vendor do
that? Leaving the reset open isn't very good design practice in
general, either :-)
As has been mentioned before, some vendor-specific hackery involving
attributes and tool chain kludges (UCF files, etc) usually can get you
there. Because of this specificity, I couldn't even begin to tell you
how to do it unless you describe your toolchain in more detail.
Instead, I'll use this as an excuse to climb on my soapbox...
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. There are always those sunshine-and-roses designers who
think "once it boots up OK, it will run forever and I don't need to
reset any logic at packet starts, clear FIFOs during idle times, or
put in illegal state detection-and-reset logic". Those guys are the
ones who get caught with their butt hanging in the wind once an ESD
event, a malformed or improperly handled input, or a bit of clock
jitter on a FIFO controller, come in from the big bad Real World.
Now if you don't have a proper reset coming into the chip, then my
heart goes out to you, and you owe the PCB designer/system architect a
boot to the head :-)
- Kenn
Nemesis
>> Here I'm after a while.
>> I just tested the solution with the default value ... and it doesn't
>> work, the value is ignored.
>> I tried the to leave the reset unconnected (with 'open') but it
>> doesn't compile ...
>
> It won't compile unless there's an initializer defined on the reset
> input to the component you're instantiating. And why would a vendor do
> that? Leaving the reset open isn't very good design practice in
> general, either :-)
I agree with you, so if it is possible I would avoid this solution.
> As has been mentioned before, some vendor-specific hackery involving
> attributes and tool chain kludges (UCF files, etc) usually can get you
> there. Because of this specificity, I couldn't even begin to tell you
> how to do it unless you describe your toolchain in more detail.
> Instead, I'll use this as an excuse to climb on my soapbox...
I use only Xilinx Tools, to be more precise XILINX ISE 8.2.
> 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. There are always those sunshine-and-roses designers who
> think "once it boots up OK, it will run forever and I don't need to
> reset any logic at packet starts, clear FIFOs during idle times, or
> put in illegal state detection-and-reset logic". Those guys are the
> ones who get caught with their butt hanging in the wind once an ESD
> event, a malformed or improperly handled input, or a bit of clock
> jitter on a FIFO controller, come in from the big bad Real World.
You are rigth, but I'm not talking about removing the reset from the whole
design, it's just about some registers, fifo and other potentially problematic
parts have their reset :-)
> Now if you don't have a proper reset coming into the chip, then my
> heart goes out to you, and you owe the PCB designer/system architect a
> boot to the head :-)
No no, I have a reset ... to be precise I have two resets, the board one and a
'soft' one wich is generated inside the fpga setting a particular bit..
--
Let us make a special effort to stop communicating with each other, so
we can have some conversation.
_ _ _
| \| |___ _ __ ___ __(_)___
| .` / -_) ' \/ -_|_-< (_-<
|_|\_\___|_|_|_\___/__/_/__/ http://xpn.altervista.org
Jan Pech
On Fri, 2009-01-02 at 19:18 +0000, Nemesis wrote:
> >> Here I'm after a while.
> >> I just tested the solution with the default value ... and it doesn't
> >> work, the value is ignored.
...snip...
>
> I use only Xilinx Tools, to be more precise XILINX ISE 8.2.
>
I do not believe that solution with the default value does not work with
ISE. I use it sometimes and it works well with ISE 6.3/7.1/8.2/9.2/10.1.
Jan
Nemesis
>> I use only Xilinx Tools, to be more precise XILINX ISE 8.2.
>>
>
> I do not believe that solution with the default value does 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 a register with async reset, and set the default value on its
output net ... and with the simulation I saw that the value is ignored, I also
tested the solution on the target board and got the same result.
--
To err is human; to forgive, infrequent.
Ken Cecka
> Jan Pech wrote:
>
>
>>> I use only Xilinx Tools, to be more precise XILINX ISE 8.2.
>>>
>>
>> I do not believe that solution with the default value does 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 a register with async reset, and set the default value on
> its output net ... and with the simulation I saw that the value is
> ignored, I also tested the solution on the target board and got the same
> result.
>
I haven't been following this whole thread in detail, so I don't know if this is exactly what you're looking for, but here's some code I'm using with ISE (10.1) that works in both simulation (isim) and synthesis (xst targeting V5 and S3A):
-- config_reset should initialize to 1s in simulation and synthesis
ATTRIBUTE INIT : STRING;
SIGNAL config_reset : STD_LOGIC_VECTOR(3 DOWNTO 0) := "1111";
ATTRIBUTE INIT OF config_reset : SIGNAL IS "1111";
SIGNAL hard_reset : STD_LOGIC;
-- deassert config_reset at startup
PROCESS (lb_clk)
BEGIN
IF (lb_clk'EVENT) AND (lb_clk = '1') THEN
config_reset((config_reset'LEFT - 1) DOWNTO 0) <=
config_reset(config_reset'LEFT DOWNTO 1);
config_reset(config_reset'LEFT) <= '0';
END IF;
END PROCESS;
hard_reset <= config_reset(0);
This code causes hard_reset to assert at the end of configuration and remain asserted for four lb_clk cycles. The initializer on the SIGNAL line works for simulation, but the attribute INIT is required for synthesis.
I use this in conjunction with a register-controlled soft reset since the hardware's reset net is set up to clear the FPGA.
Ken
Nemesis
>>> I do not believe that solution with the default value does 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 a register with async reset, and set the default value on
>> its output net ... and with the simulation I saw that the value is
>> ignored, I also tested the solution on the target board and got the same
>> result.
>>
>
> I haven't been following this whole thread in detail, so I don't know if
> this is exactly what you're looking for, but here's some code I'm using with
> ISE (10.1) that works in both simulation (isim) and synthesis (xst targeting
> V5 and S3A):
...
interesting code, but I don't think it's what I'm looking for.
I'm trying to get a default value for a register that should be different from
it's reset value, this default value should be the first value assumed and
should not change even if I reset the board.
--
Accomplishing the impossible means only that the boss will add it to
your regular duties.
Ken Cecka
> interesting code, but I don't think it's what I'm looking for.
> I'm trying to get a default value for a register that should be different
> from it's reset value, this default value should be the first value
> assumed and should not change even if I reset the board.
OK, but the same initialization approach should still work for you. Below is a more specific example tailored to your use case. In both simulation and synthesis, reg outputs X"AA" initially while nreset is held high, then changes to X"55" when I drive nreset low.
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY top IS
PORT
(
nreset : IN STD_LOGIC;
reg : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
);
END top;
ARCHITECTURE model OF top IS
ATTRIBUTE INIT : STRING;
SIGNAL reg_i : STD_LOGIC_VECTOR(7 DOWNTO 0) := X"AA";
ATTRIBUTE INIT OF reg_i : SIGNAL IS X"AA";
BEGIN
PROCESS (nreset)
BEGIN
IF (nreset = '0') THEN
reg_i <= X"55";
END IF;
END PROCESS;
reg <= reg_i;
END;
Jan Pech
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 the default value does 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 a register with async reset, and set the default value on its
> output net ... and with the simulation I saw that the value is ignored, I also
> tested the solution on the target board and got the same result.
>
If I need a register with preset value, I simply assign it the default
value like in the following code snippet. It works fine with both
ModelSim simulation and ISE XST synthesis.
:
:
signal sh_reg: std_logic_vector(2 downto 0) := "100";
:
:
CLK_DIV: process (clk)
begin
if rising_edge(clk) then
sh_reg <= sh_reg(1 downto 0) & sh_reg(2);
out_reg <= sh_reg(2);
end if;
end process;
:
:
Nemesis
[..]
> OK, but the same initialization approach should still work for you. Below is a more specific example tailored to your use case. In both simulation and synthesis, reg outputs X"AA" initially while nreset is held high, then changes to X"55" when I drive nreset low.
>
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
>
> ENTITY top IS
> PORT
> (
> nreset : IN STD_LOGIC;
> reg : OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
> );
> END top;
>
> ARCHITECTURE model OF top IS
> ATTRIBUTE INIT : STRING;
> SIGNAL reg_i : STD_LOGIC_VECTOR(7 DOWNTO 0) := X"AA";
> ATTRIBUTE INIT OF reg_i : SIGNAL IS X"AA";
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.
Nemesis
> 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 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.
>
> > > 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?
>
> > 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.
>
> ModelSim simulation and ISE XST synthesis.
... hmmm but I tried a similar approach, it didn't work for me ...
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:
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
> 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
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
kennhe...@sympatico.ca
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
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