Register with a default Value

Discussion in 'VHDL' started by Nemesis, Dec 18, 2008.

  1. Nemesis

    Nemesis Guest

    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?
     
    Nemesis, Dec 18, 2008
    #1
    1. Advertising

  2. Nemesis

    jeppe

    Joined:
    Mar 10, 2008
    Messages:
    348
    Location:
    Denmark
    Try this:

    signal Register: std_logic_vector( 7 downto 0) := "10001000";

    Jeppe
     
    jeppe, Dec 18, 2008
    #2
    1. Advertising

  3. Nemesis <> 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.

    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

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.net/electronics.html
     
    Martin Thompson, Dec 18, 2008
    #3
  4. Nemesis

    Nemesis Guest

    On Dec 18, 2:17 pm, Martin Thompson <> wrote:
    > Nemesis <> 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
     
    Nemesis, Dec 18, 2008
    #4
  5. Nemesis

    Tricky Guest

    On 18 Dec, 14:28, Nemesis <> wrote:
    > On Dec 18, 2:17 pm, Martin Thompson <> wrote:> Nemesis <> 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


    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.
     
    Tricky, Dec 18, 2008
    #5
  6. Nemesis

    Nemesis Guest

    On Dec 18, 3:37 pm, Tricky <> wrote:

    > > 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.
     
    Nemesis, Dec 18, 2008
    #6
  7. Nemesis

    Tricky Guest

    On 18 Dec, 15:55, Nemesis <> wrote:
    > On Dec 18, 3:37 pm, Tricky <> wrote:
    >
    > > > 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.


    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.
     
    Tricky, Dec 18, 2008
    #7
  8. Nemesis

    Sean Durkin Guest

    Tricky wrote:
    > On 18 Dec, 15:55, Nemesis <> wrote:
    >> On Dec 18, 3:37 pm, Tricky <> wrote:
    >>
    >>>> 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.

    >
    > 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.


    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?
     
    Sean Durkin, Dec 19, 2008
    #8
  9. Nemesis

    Guest

    I used to use ROC component of the top of my design to connect the
    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.
     
    , Dec 19, 2008
    #9
  10. Nemesis

    Guest

    On Dec 18, 9:28 am, Nemesis <> wrote:
    > On Dec 18, 2:17 pm, Martin Thompson <> wrote:> Nemesis <> 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


    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).
     
    , Dec 19, 2008
    #10
  11. >> On 18 Dec, 15:55, Nemesis <> wrote:
    >>>>> 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 <> 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
     
    Mike Treseler, Dec 19, 2008
    #11
  12. Nemesis

    Nemesis Guest

    On Dec 18 2008, 5:16 pm, Tricky <> wrote:
    > On 18 Dec, 15:55, Nemesis <> wrote:
    >
    > > On Dec 18, 3:37 pm, Tricky <> wrote:

    >
    > > > > I do use XST, I will try with thedefaultvalueon the net, thanks

    >
    > > > 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 ...
     
    Nemesis, Jan 2, 2009
    #12
  13. Nemesis

    Guest

    On Jan 2, 4:29 am, Nemesis <> wrote:
    > On Dec 18 2008, 5:16 pm, Tricky <> wrote:
    >
    >
    >
    > > On 18 Dec, 15:55, Nemesis <> wrote:

    >
    > > > On Dec 18, 3:37 pm, Tricky <> wrote:

    >
    > > > > > I do use XST, I will try with thedefaultvalueon the net, thanks

    >
    > > > > 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 ...


    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
     
    , Jan 2, 2009
    #13
  14. Nemesis

    Andy Peters Guest

    On Jan 2, 7:24 am, 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
     
    Andy Peters, Jan 8, 2009
    #14
  15. Nemesis

    Ken Cecka Guest

    Andy Peters wrote:

    > On Jan 2, 7:24 am, 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
     
    Ken Cecka, Jan 8, 2009
    #15
  16. Nemesis

    Guest

    On Jan 8, 5:47 pm, Ken Cecka <> wrote:
    > Andy Peters wrote:
    > > On Jan 2, 7:24 am, 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
     
    , Jan 9, 2009
    #16
  17. Nemesis

    Ken Cecka Guest

    wrote:

    > On Jan 8, 5:47 pm, Ken Cecka <> wrote:
    >> Andy Peters wrote:
    >> > On Jan 2, 7:24 am, 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
     
    Ken Cecka, Jan 9, 2009
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. C Gillespie
    Replies:
    3
    Views:
    426
    Peter Hansen
    Mar 22, 2005
  2. ose

    Default type for "register" variable

    ose, Sep 1, 2007, in forum: C Programming
    Replies:
    3
    Views:
    333
    Gordon Burditt
    Sep 2, 2007
  3. Jan Pech
    Replies:
    7
    Views:
    683
    Nemesis
    Jan 5, 2009
  4. Peter Otten
    Replies:
    0
    Views:
    209
    Peter Otten
    Sep 5, 2012
  5. Mark Lawrence
    Replies:
    0
    Views:
    189
    Mark Lawrence
    Sep 5, 2012
Loading...

Share This Page