Xilinx "something's wrong" error

Discussion in 'VHDL' started by Sergey Katsev, Oct 31, 2006.

  1. Hi All,

    I'm trying to synthesize a pretty complex system which simulates fine in
    ModelSim (I know that this doesn't mean it's synthesizable, but I'm
    trying to get to that point).

    Part-way through the synthesis (on the second component that it actually
    tries to do HDL synthesis on, after it does all the generics
    instantiation and all that), ISE gives me it's famous "something went
    wrong... contact support" error message.

    Is there any indication about *where* it went wrong, so I can at least
    try to re-write that code? What's the best way of trying to tackle this
    issue?

    Thanks,

    Sergey
     
    Sergey Katsev, Oct 31, 2006
    #1
    1. Advertising

  2. Sergey Katsev wrote:

    > Is there any indication about *where* it went wrong, so I can at least
    > try to re-write that code? What's the best way of trying to tackle this
    > issue?


    With vhdl simulation.
    Maybe you gave synthesis an impossible task
    that it hasn't seen before.
    Start with a working example or
    design the uut using a synchronous template
    that has a chance to work.
    Write and run a testbench that shows the logic is right.
    Run synthesis and view the RTL schematic.


    http://home.comcast.net/~mike_treseler/
     
    Mike Treseler, Oct 31, 2006
    #2
    1. Advertising

  3. Thanks for your response Mike.

    As far as I know, the code is synchronous and should be synthesizable.
    It's several components comprised of generically generated systolic
    arrays, but the array elements are just arithmetic operations.

    The element that it "dies" on should just be two flip-flops:

    entity A1circ is
    port( clk : in std_logic := '0';
    X : in sfixed_c := (others=> '0'); -- input
    flag_in : in std_logic := '0';
    Y : out sfixed_c := (others=> '0'); -- output
    flag_out : out std_logic := '0'
    );
    end A1circ;

    architecture behav of A1circ is

    begin
    process(clk)
    begin
    if rising_edge(clk) then
    Y <= X;
    flag_out <= flag_in;
    end if;
    end process;
    end behav;

    Is there anything wrong with that piece of code?... or does the fact
    that the fatal error occurs when synthesizing this unit doesn't
    necessarily imply that this is where the problem resides?

    Thanks again...

    Here's the XST output (the last few lines):

    =========================================================================
    * HDL Synthesis *
    =========================================================================

    Performing bidirectional port resolution...

    Synthesizing Unit <validator>.
    Related source file is
    "C:/thesis/SDRE/VHDL/FINAL/final/validator.vhdl".
    Unit <validator> synthesized.


    Synthesizing Unit <A1circ>.
    Related source file is "C:/thesis/SDRE/VHDL/FINAL/final/A1circ.vhdl".
    FATAL_ERROR:Xst:portability/export/Port_Main.h:127:1.16 - This
    application has discovered an exceptional condition from which it cannot
    recover. Process will terminate. To resolve this error, please consult
    the Answers Database and other online resources at
    http://support.xilinx.com. If you need further assistance, please open a
    Webcase by clicking on the "WebCase" link at http://support.xilinx.com

    Process "Synthesize" failed



    Mike Treseler wrote:
    > Sergey Katsev wrote:
    >
    >> Is there any indication about *where* it went wrong, so I can at least
    >> try to re-write that code? What's the best way of trying to tackle
    >> this issue?

    >
    > With vhdl simulation.
    > Maybe you gave synthesis an impossible task
    > that it hasn't seen before.
    > Start with a working example or
    > design the uut using a synchronous template
    > that has a chance to work.
    > Write and run a testbench that shows the logic is right.
    > Run synthesis and view the RTL schematic.
    >
    >
    > http://home.comcast.net/~mike_treseler/
     
    Sergey Katsev, Oct 31, 2006
    #3
  4. Sergey Katsev

    Ben Jones Guest

    "Sergey Katsev" <> wrote in message
    news:p...
    > Hi All,
    >
    > I'm trying to synthesize a pretty complex system which simulates fine in
    > ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
    > to get to that point).
    >
    > Part-way through the synthesis (on the second component that it actually
    > tries to do HDL synthesis on, after it does all the generics instantiation
    > and all that), ISE gives me it's famous "something went wrong... contact
    > support" error message.


    We all hate this error.

    Could you specify what version of ISE you are using

    > Is there any indication about *where* it went wrong, so I can at least try
    > to re-write that code? What's the best way of trying to tackle this
    > issue?


    A few ideas:

    Try synthesizing the subcomponent in isolation (rather than in the context
    of the larger system) and see if the issue still occurs.

    Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
    constants using complicated functions, using records, arrays of records,
    records of records, anything that's not straight out of a textbook).

    Try the "binary search" method - comment out half your file and re-run
    synthesis; if it starts working then the error is in the commented-out half;
    iterate until you've found the line it doesn't like.

    If you can post some of your code at any stage of the debugging process, you
    might find that someone in this newsgroup can tell you exactly what the
    problem is straight away. These sorts of banging-head-against-the-wall
    issues tend to stick in the mind somewhat... :)

    Cheers,

    -Ben-
     
    Ben Jones, Oct 31, 2006
    #4
  5. Thanks for your response Ben...

    I'm using ISE 8.2i

    I posted the piece that I think it's getting stuck on in a previous
    message... but (unless I'm missing something obvious), I don't really
    see how it could get stuck on that code...

    -- Sergey

    Ben Jones wrote:
    > "Sergey Katsev" <> wrote in message
    > news:p...
    >> Hi All,
    >>
    >> I'm trying to synthesize a pretty complex system which simulates fine in
    >> ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
    >> to get to that point).
    >>
    >> Part-way through the synthesis (on the second component that it actually
    >> tries to do HDL synthesis on, after it does all the generics instantiation
    >> and all that), ISE gives me it's famous "something went wrong... contact
    >> support" error message.

    >
    > We all hate this error.
    >
    > Could you specify what version of ISE you are using
    >
    >> Is there any indication about *where* it went wrong, so I can at least try
    >> to re-write that code? What's the best way of trying to tackle this
    >> issue?

    >
    > A few ideas:
    >
    > Try synthesizing the subcomponent in isolation (rather than in the context
    > of the larger system) and see if the issue still occurs.
    >
    > Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
    > constants using complicated functions, using records, arrays of records,
    > records of records, anything that's not straight out of a textbook).
    >
    > Try the "binary search" method - comment out half your file and re-run
    > synthesis; if it starts working then the error is in the commented-out half;
    > iterate until you've found the line it doesn't like.
    >
    > If you can post some of your code at any stage of the debugging process, you
    > might find that someone in this newsgroup can tell you exactly what the
    > problem is straight away. These sorts of banging-head-against-the-wall
    > issues tend to stick in the mind somewhat... :)
    >
    > Cheers,
    >
    > -Ben-
    >
    >
     
    Sergey Katsev, Oct 31, 2006
    #5
  6. Sergey Katsev

    Ben Jones Guest

    "Sergey Katsev" <> wrote in message
    news:...
    > Thanks for your response Ben...
    >
    > I'm using ISE 8.2i
    >
    > I posted the piece that I think it's getting stuck on in a previous
    > message... but (unless I'm missing something obvious), I don't really see
    > how it could get stuck on that code...


    Yes, it does look like the simplest of the simple...

    Is sfixed_c just an explicitly ranged subtype of std_logic_vector?

    -Ben-
     
    Ben Jones, Oct 31, 2006
    #6
  7. Ben Jones wrote:
    > "Sergey Katsev" <> wrote in message
    > news:...
    >> Thanks for your response Ben...
    >>
    >> I'm using ISE 8.2i
    >>
    >> I posted the piece that I think it's getting stuck on in a previous
    >> message... but (unless I'm missing something obvious), I don't really see
    >> how it could get stuck on that code...

    >
    > Yes, it does look like the simplest of the simple...
    >
    > Is sfixed_c just an explicitly ranged subtype of std_logic_vector?
    >
    > -Ben-
    >
    >

    The sfixed_c type is from David Bishop's fixed point library... and that
    synthesizes fine in a smaller test case I have.

    -- Sergey
     
    Sergey Katsev, Oct 31, 2006
    #7
  8. Sergey Katsev wrote:
    > Thanks for your response Mike.


    > The element that it "dies" on should just be two flip-flops:
    >
    > entity A1circ is
    > port( clk : in std_logic := '0';
    > X : in sfixed_c := (others=> '0'); -- input


    I expect that sfixed_c type requires
    a more specific assignment than (others=> '0');
    Run vcom on the source for a better error description.

    -- Mike Treseler
     
    Mike Treseler, Oct 31, 2006
    #8
  9. Hmm...

    sfixed_c is just a subtype defined to sfixed(32 downto -32).

    However, when I try to do
    in1, in2 : in sfixed(32 downto -32) := (others=>'0')

    ISE tells me that "type of in1 is incompatible with type of aggregate".
    Could it be that when I "mask" the type by using a subtype, ISE gets
    confused?

    (I can't actually test on the other code right now since I dont have it
    with me)

    How would I assign the inputs more explicitly? Or, do you mean just do
    it inside of a process?

    Thanks,

    Sergey

    Mike Treseler wrote:
    > Sergey Katsev wrote:
    >> Thanks for your response Mike.

    >
    >> The element that it "dies" on should just be two flip-flops:
    >>
    >> entity A1circ is
    >> port( clk : in std_logic := '0';
    >> X : in sfixed_c := (others=> '0'); -- input

    >
    > I expect that sfixed_c type requires
    > a more specific assignment than (others=> '0');
    > Run vcom on the source for a better error description.
    >
    > -- Mike Treseler
     
    Sergey Katsev, Oct 31, 2006
    #9
  10. Sergey Katsev

    Jim Lewis Guest

    Sergey,
    Perhaps you could consider not initializing all of the
    inputs and outputs.

    If you are using this to imply
    some form of power-on reset, keep in mind that this is
    a Xilinx specific feature and will not port to other
    FPGA technologies. I would recommend instead coding
    reset explicitly (with a reset line).

    Cheers,
    Jim

    > Hmm...
    >
    > sfixed_c is just a subtype defined to sfixed(32 downto -32).
    >
    > However, when I try to do
    > in1, in2 : in sfixed(32 downto -32) := (others=>'0')
    >
    > ISE tells me that "type of in1 is incompatible with type of aggregate".
    > Could it be that when I "mask" the type by using a subtype, ISE gets
    > confused?
    >
    > (I can't actually test on the other code right now since I dont have it
    > with me)
    >
    > How would I assign the inputs more explicitly? Or, do you mean just do
    > it inside of a process?
    >
    > Thanks,
    >
    > Sergey
    >
    > Mike Treseler wrote:
    >> Sergey Katsev wrote:
    >>> Thanks for your response Mike.

    >>
    >>> The element that it "dies" on should just be two flip-flops:
    >>>
    >>> entity A1circ is
    >>> port( clk : in std_logic := '0';
    >>> X : in sfixed_c := (others=> '0'); -- input

    >>
    >> I expect that sfixed_c type requires
    >> a more specific assignment than (others=> '0');
    >> Run vcom on the source for a better error description.
    >>
    >> -- Mike Treseler



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Oct 31, 2006
    #10
  11. Sergey Katsev wrote:

    > How would I assign the inputs more explicitly? Or, do you mean just do
    > it inside of a process?


    I would package a subtype:

    subtype f32_t is sfixed(32 downto -32);
    then declare the ports

    in1, in2 : in f32_t := (f32_t'range=>'0');

    Note that this init is ignored for synthesis
    anyway, so another option might be to get rid of it.

    -- Mike Treseler
     
    Mike Treseler, Oct 31, 2006
    #11
  12. Mike Treseler wrote:

    > subtype f32_t is sfixed(32 downto -32);
    > then declare the ports
    >
    > in1, in2 : in f32_t := (f32_t'range=>'0');


    Sorry, I just noticed that your sfixed_c
    is already a subtype such a subtype.

    In that case

    in1, in2 : in sfixed_c := (sfixed_c'range=>'0');

    but as Jim just noted, you probably really want
    to use a real reset.


    -- Mike Treseler
     
    Mike Treseler, Oct 31, 2006
    #12
  13. Sergey Katsev

    Andy Guest

    Ben Jones wrote:
    > "Sergey Katsev" <> wrote in message
    > news:...
    > > Thanks for your response Ben...
    > >
    > > I'm using ISE 8.2i
    > >
    > > I posted the piece that I think it's getting stuck on in a previous
    > > message... but (unless I'm missing something obvious), I don't really see
    > > how it could get stuck on that code...

    >
    > Yes, it does look like the simplest of the simple...
    >
    > Is sfixed_c just an explicitly ranged subtype of std_logic_vector?
    >
    > -Ben-


    Does ISE accept negative indices on SLV? It seems like I've heard it
    has problems with the ieee candidate fixed point package for that
    reason.

    Andy
     
    Andy, Oct 31, 2006
    #13
  14. Sergey Katsev

    Ben Jones Guest

    "Andy" <> wrote in message
    news:...
    >
    > Does ISE accept negative indices on SLV? It seems like I've heard it
    > has problems with the ieee candidate fixed point package for that
    > reason.


    Unfortunately, you heard correctly.

    In fact std_logic_vector is defined as an "array(natural range <>) of
    std_logic"; consequently, negative indices are not allowed for slv anyway.
    However, you can define your own logic array type (using integer range <>)
    to get around this... and then XST will go ahead and barf at it.

    I believe that the development team have been made aware of this (the
    synthesizable fixed-point and floating-point libraries from the forthcoming
    VHDL standards will certainly require support for this).

    -Ben-
     
    Ben Jones, Nov 1, 2006
    #14
  15. Sergey Katsev

    Andy Guest

    Ben,

    Thanks for jogging my memory. Yes, SLV is defined as having only
    natural (non-negative) indices. The fixed point package solves that,
    but brings along the extra baggage of extended results ranges. For
    result := a + b; result'width = max(a'width, b'width) + 1. This makes
    using fixed point types for most integer arithmetic rather complicated
    and verbose.

    I would rather have fixed point scaler types, maybe borrowing the ada
    style, converted from "digits" to "bits" of course. The arithmetic
    syntax would be much cleaner, and the results just as precise
    (bit-accurate) as these vectors are, without the sizing headaches.
    They'd simulate much faster than vectors too, approaching the
    simulation performance of integers.

    Andy


    Ben Jones wrote:
    > "Andy" <> wrote in message
    > news:...
    > >
    > > Does ISE accept negative indices on SLV? It seems like I've heard it
    > > has problems with the ieee candidate fixed point package for that
    > > reason.

    >
    > Unfortunately, you heard correctly.
    >
    > In fact std_logic_vector is defined as an "array(natural range <>) of
    > std_logic"; consequently, negative indices are not allowed for slv anyway.
    > However, you can define your own logic array type (using integer range <>)
    > to get around this... and then XST will go ahead and barf at it.
    >
    > I believe that the development team have been made aware of this (the
    > synthesizable fixed-point and floating-point libraries from the forthcoming
    > VHDL standards will certainly require support for this).
    >
    > -Ben-
     
    Andy, Nov 1, 2006
    #15
  16. Thanks!

    .... getting rid of the initialization (I'll worry about putting in a
    reset later) made each individual component synthesize...

    (and then my system ran out of RAM doing low-level synthesis, but I'll
    try on a more powerful computer today and report back).

    Thanks all!

    -- Sergey

    Mike Treseler wrote:
    > Mike Treseler wrote:
    >
    >> subtype f32_t is sfixed(32 downto -32);
    >> then declare the ports
    >>
    >> in1, in2 : in f32_t := (f32_t'range=>'0');

    >
    > Sorry, I just noticed that your sfixed_c
    > is already a subtype such a subtype.
    >
    > In that case
    >
    > in1, in2 : in sfixed_c := (sfixed_c'range=>'0');
    >
    > but as Jim just noted, you probably really want
    > to use a real reset.
    >
    >
    > -- Mike Treseler
    >
     
    Sergey Katsev, Nov 1, 2006
    #16
  17. Sergey Katsev

    Jim Lewis Guest

    Andy,
    > I would rather have fixed point scaler types, maybe borrowing the ada
    > style, converted from "digits" to "bits" of course. The arithmetic
    > syntax would be much cleaner, and the results just as precise
    > (bit-accurate) as these vectors are, without the sizing headaches.
    > They'd simulate much faster than vectors too, approaching the
    > simulation performance of integers.


    I don't doubt any of this other than the "without the sizing headaches."
    When you start working with sized objects (for synthesis), you need
    to somehow specify how to handle the boundaries (saturating vs modulo
    based wrap around, rounding vs truncation). Consider the following:

    entity e is
    end e ;
    architecture a of e is

    -- Numeric_std
    signal Y_uv, A_uv, B_uv : unsigned(7 downto 0) ;
    signal Z_uv : unsigned(8 downto 0) ;

    -- fixed_pkg - in Accellera vhdl-2006
    signal Y_uf, A_uf, B_uf : ufixed(7 downto 0) ;
    signal Z_uf : ufixed(8 downto 0) ;

    -- integer based math
    signal Y_int, A_int, B_int : integer range 0 to 255 ;
    signal Z_int : integer range 0 to 511 ;

    begin

    -- Numeric_Std natively does modulo based math
    Y_uv <= A_uv + B_uv ;
    Z_uv <= ('0' & A_uv) + B_uv ;

    -- fixed_pkg natively does full precision math
    Z_uf <= A_uf + B_uf ;
    Y_uf <= resize(
    arg => A_uf + B_uf, -- value
    size_res => Y_uf, -- size of result
    overflow_style => fixed_saturate, -- alternately fixed_wrap
    round_style => fixed_round -- alternately fixed_truncate
    ) ;

    -- integer based math does full precision math:
    Z_int <= A_int + B_int ;
    Y_int <= (A_int + B_int) mod 255 ; -- fixed_wrap

    end a ;

    How do I generate a saturated value for Y_int and Y_uv?
    With the current resize, synthesis tools will need to be
    somewhat smart as we don't need rounding for some operations
    such as addition. The example above gets more interesting
    when the integers have a signed range. A long range goal
    would be for the methods that are used for the integer/scalar
    fixed point/real based approach be the same as for the
    package based approached (assume nothing is written in
    stone - meaning we can add to the packages if necessary).

    If I size integers, fixed point scalars (proposed by Andy)
    and real, will I still get the simulation speed-up?
    What if I need an integer bigger than 32 bits?
    Do I need a switch or methodology that allows me to run
    fast sims which ignore the sizing (but being big enough)
    and accurate sims which use the sizing?

    I think you have the start of something that is a good
    idea. What we need is a passionate person who can champion
    a language request into the Accellera VHDL requirements
    committee and then work on the enhancement in the enhancements
    group - note the enhancement is not the LRM text - LRM
    changes are handled by a different group.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 1, 2006
    #17
  18. Sergey Katsev

    Andy Guest

    Jim,

    With integers, the simulator is obliged to do, arithmetically, exactly
    what you asked it to "or die trying". If I told it I wanted to put a +
    b into a holder no bigger than b, it will do it or die trying. I don't
    have to explicitly tell it that I want it to do the addition and then
    resize the results to fit into something different.

    Saturation with integers is similar to wrap, assuming you have a min()
    function:

    Y_int <= min(255, a_int + b_int); -- fixed_saturate

    If these had been signed operands, it's a little more complex, but
    still not too bad:

    y_int <= max(0,min(255, a_int + b_int)); -- signed saturate

    Alternatively, if there were additional attributes built in for
    integers that indicated whether failure, saturation, or wrap was
    desired behavior (with failure being the default for backwards
    compatibility), then this would become moot. Like bounds checking, this
    behavior would be applied only on assignment, not at the operator
    level.

    Even with the over/underflow resolution, whether it is done manually or
    "behind the scenes", these integer operations will still simulate much
    faster for any data size of more than a very few bits (maybe even 3 or
    4 bits?). After all, the bounds checking is happening already,
    executing the behavior is not much more work than that.

    I have also been looking at the ada fixed point type declaration
    mechanism to see if it is applicable/extendable to vhdl for hardware
    specification. It seems pretty close as is, but I don't know enough
    about how/if ada fixed point types can be subtyped, to allow a master
    typedef (akin to integer) that is subtyped for synthesis size
    constraints, to allow operations between different fixed point operands
    (WRT bits and precision).

    Andy

    Jim Lewis wrote:
    > Andy,
    > > I would rather have fixed point scaler types, maybe borrowing the ada
    > > style, converted from "digits" to "bits" of course. The arithmetic
    > > syntax would be much cleaner, and the results just as precise
    > > (bit-accurate) as these vectors are, without the sizing headaches.
    > > They'd simulate much faster than vectors too, approaching the
    > > simulation performance of integers.

    >
    > I don't doubt any of this other than the "without the sizing headaches."
    > When you start working with sized objects (for synthesis), you need
    > to somehow specify how to handle the boundaries (saturating vs modulo
    > based wrap around, rounding vs truncation). Consider the following:
    >
    > entity e is
    > end e ;
    > architecture a of e is
    >
    > -- Numeric_std
    > signal Y_uv, A_uv, B_uv : unsigned(7 downto 0) ;
    > signal Z_uv : unsigned(8 downto 0) ;
    >
    > -- fixed_pkg - in Accellera vhdl-2006
    > signal Y_uf, A_uf, B_uf : ufixed(7 downto 0) ;
    > signal Z_uf : ufixed(8 downto 0) ;
    >
    > -- integer based math
    > signal Y_int, A_int, B_int : integer range 0 to 255 ;
    > signal Z_int : integer range 0 to 511 ;
    >
    > begin
    >
    > -- Numeric_Std natively does modulo based math
    > Y_uv <= A_uv + B_uv ;
    > Z_uv <= ('0' & A_uv) + B_uv ;
    >
    > -- fixed_pkg natively does full precision math
    > Z_uf <= A_uf + B_uf ;
    > Y_uf <= resize(
    > arg => A_uf + B_uf, -- value
    > size_res => Y_uf, -- size of result
    > overflow_style => fixed_saturate, -- alternately fixed_wrap
    > round_style => fixed_round -- alternately fixed_truncate
    > ) ;
    >
    > -- integer based math does full precision math:
    > Z_int <= A_int + B_int ;
    > Y_int <= (A_int + B_int) mod 255 ; -- fixed_wrap
    >
    > end a ;
    >
    > How do I generate a saturated value for Y_int and Y_uv?
    > With the current resize, synthesis tools will need to be
    > somewhat smart as we don't need rounding for some operations
    > such as addition. The example above gets more interesting
    > when the integers have a signed range. A long range goal
    > would be for the methods that are used for the integer/scalar
    > fixed point/real based approach be the same as for the
    > package based approached (assume nothing is written in
    > stone - meaning we can add to the packages if necessary).
    >
    > If I size integers, fixed point scalars (proposed by Andy)
    > and real, will I still get the simulation speed-up?
    > What if I need an integer bigger than 32 bits?
    > Do I need a switch or methodology that allows me to run
    > fast sims which ignore the sizing (but being big enough)
    > and accurate sims which use the sizing?
    >
    > I think you have the start of something that is a good
    > idea. What we need is a passionate person who can champion
    > a language request into the Accellera VHDL requirements
    > committee and then work on the enhancement in the enhancements
    > group - note the enhancement is not the LRM text - LRM
    > changes are handled by a different group.
    >
    > Cheers,
    > Jim
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Andy, Nov 2, 2006
    #18
  19. Sergey Katsev

    Jim Lewis Guest

    Andy,
    > With integers, the simulator is obliged to do, arithmetically, exactly
    > what you asked it to "or die trying". If I told it I wanted to put a +
    > b into a holder no bigger than b, it will do it or die trying. I don't
    > have to explicitly tell it that I want it to do the addition and then
    > resize the results to fit into something different.


    Exactly, so while the following assignment to Y_int will
    work for many simulation runs, it will "die trying" if
    A_int + B_int > 255. So if this condition never happens,
    leaving it alone is ok, however, I also hope your testbench
    generates all of the worst case values.

    signal Y_int, A_int, B_int : integer range 0 to 255 ;
    ....
    Y_int <= A_int + B_int ;


    > Even with the over/underflow resolution, whether it is done manually or
    > "behind the scenes", these integer operations will still simulate much
    > faster for any data size of more than a very few bits (maybe even 3 or
    > 4 bits?). After all, the bounds checking is happening already,
    > executing the behavior is not much more work than that.


    My concern is that a 7 bit integer may simulate slower than
    a 32 bit integer. Hence, for best speed, use a convenient
    size that fits the value (but does not do fine grained bounds
    checking - at 7 bit boundaries for example) and for accuracy,
    use the exact size with exact bounds checking.


    > I have also been looking at the ada fixed point type declaration
    > mechanism to see if it is applicable/extendable to vhdl for hardware
    > specification. It seems pretty close as is, but I don't know enough
    > about how/if ada fixed point types can be subtyped, to allow a master
    > typedef (akin to integer) that is subtyped for synthesis size
    > constraints, to allow operations between different fixed point operands
    > (WRT bits and precision).


    Same problem with real, so something other than range would need to be
    defined.

    Long term, it would be beneficial if we had a usage methodology
    that handled scalar and array numeric values in the same way.
    This way, switching between scalar and array numeric types could
    be as easy as switching a package and that contains a subtype
    declaration:

    package my_math_pkg is
    subtype my_math_type is integer range 0 to 255 ;
    end package my_math_pkg ;

    Alternately in a separate file:
    library ieee ;
    use ieee.numeric_std.all ;
    package my_math_pkg is
    subtype my_math_type is unsigned(7 downto 0) ;
    end package my_math_pkg ;

    A more interesting case would to switch between a
    a scalar fixed point type and real.

    Cheers,
    Jim

    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 2, 2006
    #19
  20. Sergey Katsev

    Andy Guest

    Jim,

    Good discussion!

    If I designed a circuit that should never need to roll over, I would
    want to know about it as soon as it does, not have it silently roll
    over all by itself. (That elementary arithmetic rule about a + 1 > a
    always being true is important to me, and I want to know about it if it
    is not going to be true) If it has the possibility of rolling over,
    then I should handle that case they way I want to (i.e. saturate or
    roll over), not the way signed/unsigned vectors do (always roll over).
    The "extra" coding necessary to specify that behavior is small price to
    pay (in performance, readability and typing) especially when compared
    with that required of vector arithmetic, particularly if you wanted
    saturation.

    Incomplete testbenches are a fact of life, whether your
    hardware/simulation automatically rolls over or not. If you did not
    test the rollover with vectors in simulation, how do you know that is
    acceptable? At least the integer simulation will tell you something is
    wrong if it tried to do something you had not specified. The vector
    simulation will happily, silently roll over and keep going, and you may
    or may not notice the effects downstream. Consider what happens when SL
    meta-values are encountered in an SLV based simulation: the synthesized
    hardware does not behave the same there either. Pick your poison. I
    prefer the poison that comes with blazing simulation speed.

    As long as a 7 bit integer simulates many times faster than a 7 bit
    vector, why worry about whether it simulates as fast as a 32 bit
    integer? Some simulators do allow you to turn off bounds checking,
    which would then simulate 7 bit integers as fast as 32 bit ones.

    I too would like to be able to interchange scalar and vector types for
    simulation efficiency vs hardware accuracy (i.e. 'X' resolution, etc.)
    tradeoffs. Except for direct assignments using literals, you can do
    that today in many cases: "a := (a + 1) mod 255"; works the same for
    unsigned and natural today (assuming you're not using Synopsys!).
    Unfortuanely, "a := 0" does not, nor does "a := (others => '0')". And
    "a := min(255, a + 1)" does not work the same for both fixed(saturate)
    and natural either. In an FPGA, with hardware initialization built in,
    and no tri-state signals, the value of resolving 'X' is pretty low
    compared to the speed of simulating integers. Consider how many more
    corner cases you can excersize when your simulation is several times
    quicker!

    Switching between fixed and floating scalar types should be trivial...?
    I hadn't even thought of that! It could come in really handy! Imagine
    comparing two implementations of a design, one implemented with fixed
    point, the other with floating point, in the same simulation...

    Andy
     
    Andy, Nov 2, 2006
    #20
    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. Sachin
    Replies:
    1
    Views:
    731
  2. Rakesh Sharma
    Replies:
    2
    Views:
    2,996
    Thomas Rudloff
    Oct 22, 2004
  3. Ivan C.
    Replies:
    4
    Views:
    972
    David Bishop
    Nov 21, 2004
  4. Luka Milkovic
    Replies:
    14
    Views:
    500
    Luka Milkovic
    Sep 13, 2004
  5. fpgaengineer
    Replies:
    7
    Views:
    3,922
    Mike Treseler
    Mar 12, 2007
Loading...

Share This Page