VHDL simulator error message - please help

Discussion in 'VHDL' started by Daku, Nov 30, 2009.

  1. Daku

    Daku Guest

    Could some VHDL guru please help ? My VHDL simulator is giving error
    message as:
    "multiple driver on unguarded signal `index 0`"
    What would be a good way to get around this problem ? The source code
    is below for reference:

    library IEEE;
    use IEEE.STD_LOGIC_1164.ALL;
    use IEEE.STD_LOGIC_arith.ALL;
    use IEEE.STD_LOGIC_unsigned.ALL;
    use IEEE.NUMERIC_STD.ALL;


    ENTITY ram IS
    port ( CEB : in std_logic;
    WEB : in std_logic;
    REB : in std_logic;
    INN : in std_logic_vector(0 to 31);
    OUTT : out std_logic_vector(0 to 31)
    );
    END ram;

    ARCHITECTURE dataflow_view OF ram IS
    CONSTANT MAX : integer := 32;
    SIGNAL index : std_logic_vector (0 to 31) :=
    ('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0');
    SIGNAL cpriority : std_logic_vector (0 to 7) :=
    ('0','0','0','0','0','0','0','0');
    SIGNAL spriority : std_logic_vector (0 to 7) :=
    ('0','0','0','0','0','0','0','0');

    SUBTYPE TYPE_WORD IS std_logic_vector (0 to 31);
    TYPE TYPE_RAM IS ARRAY(0 TO 31) OF TYPE_WORD;
    SIGNAL memory : TYPE_RAM := ((OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    (OTHERS=>'0'),
    (OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),
    (OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'));



    BEGIN

    RAM_0 : PROCESS( WEB )
    BEGIN
    IF RISING_EDGE(WEB) THEN
    IF (REB='0') THEN
    FOR I IN index'RANGE LOOP
    IF index(I) = '0' THEN
    index(I) <= '1';
    cpriority <= INN(24 TO 31);
    memory(I) <= INN;
    EXIT;
    END IF;
    END LOOP;
    END IF; -- REB='0'
    IF (CONV_INTEGER(spriority) <
    CONV_INTEGER(cpriority)) THEN
    spriority <= cpriority;
    END IF;
    END IF; -- rising_edge
    END PROCESS RAM_0;

    RAM_1 : PROCESS( REB )
    BEGIN
    IF RISING_EDGE(REB) THEN
    IF (WEB='0') THEN
    FOR I IN index'RANGE LOOP
    IF index(I) = '1' THEN
    index(I) <= '0';
    EXIT;
    END IF;
    END LOOP;
    OUTT <= memory(I);
    END IF; -- WEB='0'
    END IF; -- rising
    END PROCESS RAM_1;

    END dataflow_view;

    Any hints, suggestions would be of immense help. Thanks in advance for
    your help.
    Daku, Nov 30, 2009
    #1
    1. Advertising

  2. Daku

    Tricky Guest

    On 30 Nov, 03:38, Daku <> wrote:
    > Could some VHDL guru please help ? My VHDL simulator is giving error
    > message as:
    > "multiple driver on unguarded signal `index 0`"
    > What would be a good way to get around this problem ? The source code
    > is below for reference:
    >
    > library IEEE;
    > use IEEE.STD_LOGIC_1164.ALL;
    > use IEEE.STD_LOGIC_arith.ALL;
    > use IEEE.STD_LOGIC_unsigned.ALL;
    > use IEEE.NUMERIC_STD.ALL;


    Dont load Numeric std and std_logic_arith/unsigned at the same time.
    You're liable to confuse all sorts of things. These libraries are not
    compatible with each other. Preferably - use numeric_std.


    >
    > ENTITY ram IS
    >   port ( CEB      : in std_logic;
    >          WEB      : in std_logic;
    >          REB      : in std_logic;
    >          INN      : in  std_logic_vector(0 to 31);
    >          OUTT     : out std_logic_vector(0 to 31)
    >   );
    > END ram;
    >
    > ARCHITECTURE dataflow_view OF ram IS
    >     CONSTANT MAX   : integer := 32;
    >     SIGNAL index   : std_logic_vector (0 to 31) :=
    > ('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0');


    Why not initialise to (others => '0') ? instead of the overly long
    expression? If you need access to individual bits, why not just use
    hex notation? index := x"0000_0000" ;

    >     SIGNAL cpriority : std_logic_vector (0 to 7) :=
    > ('0','0','0','0','0','0','0','0');
    >     SIGNAL spriority : std_logic_vector (0 to 7) :=
    > ('0','0','0','0','0','0','0','0');
    >
    >     SUBTYPE TYPE_WORD IS std_logic_vector (0 to 31);
    >     TYPE TYPE_RAM IS ARRAY(0 TO 31) OF TYPE_WORD;
    >     SIGNAL memory : TYPE_RAM := ((OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
    > (OTHERS=>'0'),
    > (OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),
    > (OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'));



    You really like to be explicit dont you. whats wrong with ( others =>
    (others => '0') ); ?

    >
    > BEGIN
    >
    >    RAM_0 :  PROCESS( WEB )
    >      BEGIN
    >       IF RISING_EDGE(WEB) THEN
    >        IF (REB='0') THEN
    >          FOR I IN index'RANGE LOOP
    >            IF index(I) = '0' THEN
    >              index(I) <= '1';
    >              cpriority <= INN(24 TO 31);
    >              memory(I) <= INN;
    >              EXIT;
    >            END IF;
    >          END LOOP;
    >        END IF; -- REB='0'
    >        IF (CONV_INTEGER(spriority) <
    >            CONV_INTEGER(cpriority)) THEN
    >             spriority <= cpriority;
    >        END IF;
    >      END IF; -- rising_edge
    >    END PROCESS RAM_0;
    >
    >    RAM_1 :  PROCESS( REB )
    >      BEGIN
    >       IF RISING_EDGE(REB) THEN
    >        IF (WEB='0') THEN
    >          FOR I IN index'RANGE LOOP
    >            IF index(I) = '1' THEN
    >             index(I) <= '0';
    >             EXIT;
    >            END IF;
    >          END LOOP;
    >         OUTT <= memory(I);
    >        END IF; -- WEB='0'
    >      END IF; -- rising
    >    END PROCESS RAM_1;
    >
    > END dataflow_view;
    >
    > Any hints, suggestions would be of immense help. Thanks in advance for
    > your help.



    The problem with the code is that you have the index signal assigned
    in 2 separate processes You are only allowed to assign a signal from 1
    process. In addition you're reading reb and web as if they were
    clocks. You are likely to get some potential timing failures if you
    tried this on an FPGA.
    Tricky, Nov 30, 2009
    #2
    1. Advertising

  3. Daku

    Daku Guest

    On Nov 30, 2:02 pm, Tricky <> wrote:

    >
    > The problem with the code is that you have the index signal assigned
    > in 2 separate processes You are only allowed to assign a signal from 1
    > process.

    This is very hard to believe.
    The VHDL language reference clearly states that VHDL's model
    of a system consists of a static network of concurrent processes
    communicating via signals. A process has drivers for certain
    processes and a signal may be driven by multiple processes.
    Daku, Nov 30, 2009
    #3
  4. Daku wrote:

    > The VHDL language reference clearly states that VHDL's model
    > of a system consists of a static network of concurrent processes
    > communicating via signals. A process has drivers for certain
    > processes and a signal may be driven by multiple processes.


    True, but for synthesis, this only applies to
    tri-state device pin descriptions.

    -- Mike Treseler
    Mike Treseler, Nov 30, 2009
    #4
  5. Daku wrote:

    > On Nov 30, 2:02 pm, Tricky <> wrote:
    >
    >>
    >> The problem with the code is that you have the index signal assigned
    >> in 2 separate processes You are only allowed to assign a signal from 1
    >> process.


    > This is very hard to believe.


    Your beliefs are irrelevant here and I'm not interrested in them in the
    slightest.
    ;-)

    > The VHDL language reference clearly states that VHDL's model
    > of a system consists of a static network of concurrent processes
    > communicating via signals. A process has drivers for certain
    > processes and a signal may be driven by multiple processes.


    As long as the signal is of a resolved type, or in case of an aggregate
    signal its members must be resolved. The latter is the case in your code.
    So the error message of your simulator is not correct. Get a decent
    simulator.

    Then you will find the next compile error:

    FOR i IN index'RANGE LOOP
    IF index(i) = '1' THEN
    index(i) <= '0';
    EXIT;
    END IF;
    END LOOP;
    outt <= memory(i); <=== ERROR

    ERROR: Unknown identifier "i"

    A loop indentifier is a constant that only lives within the loop. Outside it
    it does not exits. If you want the value of i after the exit, you must
    assign it in the loop to another variable. And the name of that variable
    must be different from i, otherwise it will be hidden by the loop constant
    i. And by the way, I think you also must take care of the case where there
    is no '1' bit in the index vector.

    And then if you get your code compiling, you will find it will not work due
    to the multiple drivers on signal index (as already spotted by Tricky). The
    result will be all 'X'. Why? Read up on multiple drivers and resolution
    functions.

    A good way to get around the multiple driver problem: don't do it. Drive a
    signal only from one process. How? Depends what your design intent is. What
    is the purpose of your VHDL anyway? Should it be synthesizable? Or
    testbench code (behavioral)?

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
    Paul Uiterlinden, Nov 30, 2009
    #5
  6. Daku <> writes:

    > On Nov 30, 2:02 pm, Tricky <> wrote:
    >
    >>
    >> The problem with the code is that you have the index signal assigned
    >> in 2 separate processes You are only allowed to assign a signal from 1
    >> process.

    > This is very hard to believe.
    > The VHDL language reference clearly states that VHDL's model
    > of a system consists of a static network of concurrent processes
    > communicating via signals. A process has drivers for certain
    > processes and a signal may be driven by multiple processes.
    >
    >


    To refine some other comments: yes, VHDL the elegant parallel simulation
    language lets you do that, and more. However, the subset of VHDL which
    can be used as the front-end language for gate-grinding hardware guys is
    considerably less flexible. Key words are "resolution function" and
    "multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
    pretty well.

    However, in your case, it *does* look like your code should not give the
    error you describe - both drivers contend for a std_logic scalar signal
    (which *is* resolved, and so should be OK). Some simulators or
    synthesizers will give a *warning* just to point out to you that you
    might be heading off the rails.

    Unfortunately, I suspect that if you try to synthesize this you're in
    for a lot of pain for a lot of other reasons - the handling of clocks
    and timing is going to give you a lot of trouble. The biggest issue I
    see in this code is not simply that you're driving the same signal from
    two processes (which *can* be safe in very limited contexts), but that
    it's driven from two processes which operate *asynchronously* to each
    other, on different clocks. And worse than that, they each check each
    other's clock. This has all the hallmarks of a metastable,
    race-condition-filled, train wreck if you try to synthesize it.

    - Kenn

    --
    ---------------------------------
    Remove NOSPAM from email address.
    Kenn Heinrich, Nov 30, 2009
    #6
  7. Daku

    Daku Guest

    Thank you sir for your insightful comments. I
    agree fully with you about the "asynchronous" nature of the design.
    However, I did not expect
    the signal resolution problem, as you have
    pointed out. Looks like the Alliance 5.0 compiler/
    simulator is a piece of crap/junk/shit.


    On Nov 30, 11:09 pm, Kenn Heinrich <> wrote:
    > To refine some other comments: yes, VHDL the elegant parallel simulation
    > language lets you do that, and more. However, the subset of VHDL which
    > can be used as the front-end language for gate-grinding hardware guys is
    > considerably less flexible. Key words are "resolution function" and
    > "multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
    > pretty well.
    >
    > However, in your case, it *does* look like your code should not give the
    > error you describe - both drivers contend for a std_logic scalar signal
    > (which *is* resolved, and so should be OK). Some simulators or
    > synthesizers will give a *warning* just to point out to you that you
    > might be heading off the rails.
    >
    > Unfortunately, I suspect that if you try to synthesize this you're in
    > for a lot of pain for a lot of other reasons - the handling of clocks
    > and timing is going to give you a lot of trouble. The biggest issue I
    > see in this code is not simply that you're driving the same signal from
    > two processes (which *can* be safe in very limited contexts), but that
    > it's driven from two processes which operate *asynchronously* to each
    > other, on different clocks. And worse than that, they each check each
    > other's clock. This has all the hallmarks of a metastable,
    > race-condition-filled, train wreck if you try to synthesize it.
    >
    > - Kenn
    >
    > --
    > ---------------------------------
    > Remove NOSPAM from email address.
    Daku, Dec 1, 2009
    #7
  8. Daku

    Tricky Guest

    On 1 Dec, 03:25, Daku <> wrote:
    > Thank you sir for your insightful comments. I
    > agree fully with you about the "asynchronous" nature of the design.
    > However, I did not expect
    > the signal resolution problem, as you have
    > pointed out. Looks like the Alliance 5.0 compiler/
    > simulator is a piece of crap/junk/shit.
    >
    > On Nov 30, 11:09 pm, Kenn Heinrich <> wrote:
    >
    > > To refine some other comments: yes, VHDL the elegant parallel simulation
    > > language lets you do that, and more.  However, the subset of VHDL which
    > > can be used as the front-end language for gate-grinding hardware guys is
    > > considerably less flexible.  Key words are "resolution function" and
    > > "multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
    > > pretty well.

    >
    > > However, in your case, it *does* look like your code should not give the
    > > error you describe - both drivers contend for a std_logic scalar signal
    > > (which *is* resolved, and so should be OK). Some simulators or
    > > synthesizers will give a *warning* just to point out to you that you
    > > might be heading off the rails.

    >
    > > Unfortunately, I suspect that if you try to synthesize this you're in
    > > for a lot of pain for a lot of other reasons - the handling of clocks
    > > and timing is going to give you a lot of trouble. The biggest issue I
    > > see in this code is not simply that you're driving the same signal from
    > > two processes (which *can* be safe in very limited contexts), but that
    > > it's driven from two processes which operate *asynchronously* to each
    > > other, on different clocks. And worse than that, they each check each
    > > other's clock. This has all the hallmarks of a metastable,
    > > race-condition-filled, train wreck if you try to synthesize it.

    >
    > >  - Kenn

    >
    > > --
    > > ---------------------------------
    > > Remove NOSPAM from email address.

    >
    >


    But it is a problem:

    Consider this: at 5ns WEB has a rising edge event and index(0) = '0';
    web then falls to '0'. REB then has a rising_edge event at 10ns .
    Because index(0) is already being driven with '0' from RAM_0, you're
    now trying to drive '1' on it. The output result will mean index(0) is
    now 'X'. This is the multiple constant driver problem.

    The alliance compiler seems to be working fine.
    Tricky, Dec 1, 2009
    #8
  9. Tricky <> writes:

    > On 1 Dec, 03:25, Daku <> wrote:
    >> Thank you sir for your insightful comments. I
    >> agree fully with you about the "asynchronous" nature of the design.
    >> However, I did not expect
    >> the signal resolution problem, as you have
    >> pointed out. Looks like the Alliance 5.0 compiler/
    >> simulator is a piece of crap/junk/shit.
    >>
    >> On Nov 30, 11:09 pm, Kenn Heinrich <> wrote:
    >>
    >> > To refine some other comments: yes, VHDL the elegant parallel simulation
    >> > language lets you do that, and more.  However, the subset of VHDL which
    >> > can be used as the front-end language for gate-grinding hardware guys is
    >> > considerably less flexible.  Key words are "resolution function" and
    >> > "multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
    >> > pretty well.

    >>
    >> > However, in your case, it *does* look like your code should not give the
    >> > error you describe - both drivers contend for a std_logic scalar signal
    >> > (which *is* resolved, and so should be OK). Some simulators or
    >> > synthesizers will give a *warning* just to point out to you that you
    >> > might be heading off the rails.

    >>
    >> > Unfortunately, I suspect that if you try to synthesize this you're in
    >> > for a lot of pain for a lot of other reasons - the handling of clocks
    >> > and timing is going to give you a lot of trouble. The biggest issue I
    >> > see in this code is not simply that you're driving the same signal from
    >> > two processes (which *can* be safe in very limited contexts), but that
    >> > it's driven from two processes which operate *asynchronously* to each
    >> > other, on different clocks. And worse than that, they each check each
    >> > other's clock. This has all the hallmarks of a metastable,
    >> > race-condition-filled, train wreck if you try to synthesize it.

    >>
    >> >  - Kenn

    >>
    >> > --
    >> > ---------------------------------
    >> > Remove NOSPAM from email address.

    >>
    >>

    >
    > But it is a problem:
    >
    > Consider this: at 5ns WEB has a rising edge event and index(0) = '0';
    > web then falls to '0'. REB then has a rising_edge event at 10ns .
    > Because index(0) is already being driven with '0' from RAM_0, you're
    > now trying to drive '1' on it. The output result will mean index(0) is
    > now 'X'. This is the multiple constant driver problem.


    This is a true physical problem in the design. I would still expect
    that the simulator should happily, and with full approval of the
    language spec, spit out an 'X' here, since ' X' is the official
    resolution of two drivers spitting out an std_logic '0' and a '1'. The
    user can then ask "why the heck does it go to 'X'?" and discover his
    timing problem.

    >
    > The alliance compiler seems to be working fine.


    I still don't agree with that. If I'm wrong, I'd like to see the proper
    reference from the LRM so I can understand why. True, the compiler had
    a beneficial *human* function, sending this poor soul out onto the
    internet for help, whereby numerous other problems were found. But I
    still suspect the compiler itself should not be indicating an error
    here.

    - Kenn

    ---------------------------------
    Kenn Heinrich, Dec 1, 2009
    #9
  10. Daku

    KJ Guest

    On Dec 1, 7:45 am, Kenn Heinrich <> wrote:
    > Tricky <> writes:


    > > The alliance compiler seems to be working fine.

    >


    > I still don't agree with that.
    > But I
    > still suspect the compiler itself should not be indicating an error
    > here.
    >


    Since Alliance is "a VHDL compiler and simulator, logic synthesis
    tools, and automatic place and route tools." [1] then whether or not
    the reported error of "multiple driver on unguarded signal `index 0`"
    is valid or not would depend on whether Daku is simulating or
    synthesizing. If Daku is simulating, then there should be no error
    since it will simulate just fine...that is, once you get rid of the
    syntax errors in the posted code, one being the use of loop variable
    'i' that is used outside of the loop (as pointed out by Paul), the
    other being the initialization constant of '0-' as one of the bits to
    initialize the index vector. On the other hand, if Daku is trying to
    synthesize something then the error is valid if the target technology
    does not support internal tri-state drivers.

    If the error reported actually is the one reported by Alliance when
    compiling the posted code 'as-is', then Alliance would seem to be
    rather poor in reporting simple syntax errors. Using Modelsim, I got
    the following...

    ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    \ZPhase1_EM1_PCBA_Cadence.vhd(1378): near "'": syntax error
    ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    \ZPhase1_EM1_PCBA_Cadence.vhd(1405): (vcom-1136) Unknown identifier
    "index".
    ....more errors because of unknwn 'index'.

    This is caused by one of the bits in index being initialized to '0-'.
    Fixing that leads to...

    ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    \ZPhase1_EM1_PCBA_Cadence.vhd(1433): (vcom-1136) Unknown identifier
    "i".
    ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    \ZPhase1_EM1_PCBA_Cadence.vhd(1439): VHDL Compiler exiting

    This is caused by loop variable being used outside the loop. Fixing
    that and it compiles just fine (for simulation, since this is
    Modelsim).

    Kevin Jennings

    [1] http://www-asim.lip6.fr/recherche/alliance/
    KJ, Dec 1, 2009
    #10
  11. >> The alliance compiler seems to be working fine.

    Kenn Heinrich wrote:
    >
    > I still don't agree with that. If I'm wrong, I'd like to see the proper
    > reference from the LRM so I can understand why.


    It's not a language error.
    It's a synthesis error.
    Two outputs shorted together.

    -- Mike Treseler
    Mike Treseler, Dec 1, 2009
    #11
  12. Daku

    Daku Guest

    The Alliance package consists of a set of tools
    to be run in sequence to perform the synthesis task.
    First of all, Alliance package provides a tool called 'genpat' to
    generate test input for the circuit to be tested, and the test
    pattern specification is a simple C file. With the test input file in
    place,
    1. Use Alliance 'vasy' tool to convert the "as-is" VHDL code to a set
    of boolean equations
    2. Use Alliance 'asimut' tool (the main simulator)
    on the set of boolean equations and the test input
    to check if the set of generated boolean equations works with the
    test input - NO error messages at
    this stage
    3. Use Alliance 'boom' tool to
    optimize (factorize/minimize) the boolean equations based on user
    specified area/delay requirements
    4. Use Alliance 'boog' tool to map boolean nodes to a set of standard
    cells - using pseudo 0.35 u technology
    5. Use Allinace 'loon' tool to insert buffers in critical path and
    using standard cell library (see 4. above) and generate structural
    netlist
    6. Run asimut simulator on structural netlist from step 5. ERROR
    GENERATED AND SIMULATOR FAILS

    So, the errors about loop index 'i' are not caught in steps 1 and 2
    above, not to mention the timing bugs.



    On Dec 1, 6:40 pm, KJ <> wrote:

    >
    > Since Alliance is "a VHDL compiler and simulator, logic synthesis
    > tools, and automatic place and route tools." [1] then whether or not
    > the reported error of "multiple driver on unguarded signal `index 0`"
    > is valid or not would depend on whether Daku is simulating or
    > synthesizing. If Daku is simulating, then there should be no error
    > since it will simulate just fine...that is, once you get rid of the
    > syntax errors in the posted code, one being the use of loop variable
    > 'i' that is used outside of the loop (as pointed out by Paul), the
    > other being the initialization constant of '0-' as one of the bits to
    > initialize the index vector. On the other hand, if Daku is trying to
    > synthesize something then the error is valid if the target technology
    > does not support internal tri-state drivers.
    >
    > If the error reported actually is the one reported by Alliance when
    > compiling the posted code 'as-is', then Alliance would seem to be
    > rather poor in reporting simple syntax errors. Using Modelsim, I got
    > the following...
    >
    > ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    > \ZPhase1_EM1_PCBA_Cadence.vhd(1378): near "'": syntax error
    > ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    > \ZPhase1_EM1_PCBA_Cadence.vhd(1405): (vcom-1136) Unknown identifier
    > "index".
    > ...more errors because of unknwn 'index'.
    >
    > This is caused by one of the bits in index being initialized to '0-'.
    > Fixing that leads to...
    >
    > ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    > \ZPhase1_EM1_PCBA_Cadence.vhd(1433): (vcom-1136) Unknown identifier
    > "i".
    > ** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
    > \ZPhase1_EM1_PCBA_Cadence.vhd(1439): VHDL Compiler exiting
    >
    > This is caused by loop variable being used outside the loop. Fixing
    > that and it compiles just fine (for simulation, since this is
    > Modelsim).
    >
    > Kevin Jennings
    >
    > [1]http://www-asim.lip6.fr/recherche/alliance/
    Daku, Dec 3, 2009
    #12
    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. Basuki Endah Priyanto

    Free VHDL Simulator

    Basuki Endah Priyanto, Aug 15, 2003, in forum: VHDL
    Replies:
    1
    Views:
    5,337
    Tuukka Toivonen
    Aug 15, 2003
  2. Mike Kopp

    VHDL Simulator Options

    Mike Kopp, Sep 22, 2003, in forum: VHDL
    Replies:
    3
    Views:
    742
  3. Chaos Master

    Free VHDL simulator

    Chaos Master, Jun 17, 2004, in forum: VHDL
    Replies:
    5
    Views:
    19,153
    Chaos Master
    Jun 18, 2004
  4. Tristan Gingold

    [ANN] GHDL 0.13 - a free VHDL simulator

    Tristan Gingold, Jun 26, 2004, in forum: VHDL
    Replies:
    0
    Views:
    650
    Tristan Gingold
    Jun 26, 2004
  5. Gandu
    Replies:
    1
    Views:
    1,320
    Victor Bazarov
    Nov 17, 2004
Loading...

Share This Page