NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/vhdl/623

Text File | 1993-01-04 | 5.5 KB | 196 lines

Newsgroups: comp.lang.vhdl
Path: sparky!uunet!noc.near.net!viewlog.viewlogic.com!sunder
From: [e-mail] (Sunder Singhani)
Subject: Re: type conversion and configuration
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: saab
Organization: Viewlogic Systems, Inc., Marlboro, MA
References: <[e-mail]>
Date: Mon, 4 Jan 1993 22:59:57 GMT
Lines: 183

>
> I compiled them on VANTAGE spreadsheet and Model Technology V-System
> and got different results.
>
> -EXAMPLE 1
> **********
>
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
>
> PACKAGE bizarre IS
>
> CONSTANT X : std_ulogic:= std_ulogic'(to_x01(bit_vector'("00"))(1));
>
> CONSTANT Y : std_ulogic:= to_x01(bit_vector'("00"))(1);
>
> END bizarre;
>
> One of the tools gives the report below while the other compiles it OK.
>
> Error: LINE 6 * More than one interpretation found for this indexed expression
> Error: LINE 8 * More than one interpretation found for this indexed expression
>
> My opinion is that there is no ambiguity.
> At worse the indexing operation needs to explicitly know the type and then only
> line 6 is OK.

The above IS ambiguous. Explanation follows -
Here are the few lines included from ieee.std_logic_1164 VHDL file
to help explain the problem.

-- 1    FUNCTION To_X01  ( s : std_logic_vector  ) RETURN  std_logic_vector;
-- 2    FUNCTION To_X01  ( s : std_ulogic_vector ) RETURN  std_ulogic_vector;
-- 3    FUNCTION To_X01  ( s : std_ulogic        ) RETURN  X01;
-- 4    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
-- 5    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;
-- 6    FUNCTION To_X01  ( b : BIT               ) RETURN  X01;

Of these you are choosing 4, 5 explicitly by using type qualification -
ie bit_vector'("00"). 5 returns std_logic_vector and 4 returns std_ulogic_vector.
The first one when indexed gives you an element of std_ulogic, and the latter
gives std_logic. Now, std_logic is a subtype of std_ulogic, which implies
both have the same base type which is std_ulogic. Hence, you end up
with two interpretations, which is erroneous. The final type qualification
doesn't help in line 6 - std_ulogic'...  In fact that is redundant, 'cos
the LHS type is std_ulogic, and can be used to resolve overloading.

So, one of the systems is showing incorrect behavior (bug!). Our (Viewlogic)
full VHDL analyser caught this ambiguity correctly.

A workaraound -

PACKAGE bizarre IS

   CONSTANT X_ARR : std_ulogic_vector := to_x01(bit_vector'("00"));
   CONSTANT X : std_ulogic:= X_ARR(1);

END bizarre;



>
> -EXAMPLE 2
> **********
>
> -----------------------------------------
> ENTITY circuit IS
> END circuit;
>
> -----------------------------------------
> ENTITY framegen IS
> PORT (
>       dclreg  : IN bit_vector(7 DOWNTO 0)
>      );
> END framegen;
>
> -----------------------------------------
> ARCHITECTURE cpu68302 OF framegen IS
>
> BEGIN --architecture
> END cpu68302;
>
> -----------------------------------------
> ENTITY micint IS
> PORT (
>       dclreg  : OUT bit_vector(7 DOWNTO 0)
>      );
> END micint;
>
> -----------------------------------------
> ARCHITECTURE structural OF circuit IS
> COMPONENT micint
> PORT (
>       dclreg  : OUT bit_vector(7 DOWNTO 0)
>      );
> END COMPONENT;
>
> FOR c1:micint USE ENTITY WORK.micint(structural);
>
> COMPONENT framegen
>
> PORT (
>       dclreg  : IN bit_vector(7 DOWNTO 0)
>      );
> END COMPONENT;
>
> SIGNAL dclreg  : bit_vector(7 DOWNTO 0);
>
> BEGIN
>
> C1 : micint
>
> PORT MAP(
>        dclreg   =>  dclreg
>         );
>
> C2 : framegen
>
> PORT MAP(
>        dclreg   =>  dclreg
>         );
>
> END structural;
>
> -----------------------------------------
> ARCHITECTURE structural OF micint IS
> BEGIN --architecture
> END structural;
>
> -----------------------------------------
> CONFIGURATION conf68302_0 OF circuit IS
> FOR structural
>     FOR c2 : framegen
>         USE ENTITY WORK.framegen(cpu68302);
>     END FOR;
> END FOR;
> END conf68302_0;
>
> DESCRIPTION
>
> I have a testbench named circuit made of 2 components
> framegen and micint.
> The component c1 is bound to the entity micint by a
> configuration specification.
>
> The component c2 is bound to the entity framegen by
> a configuration declaration.
>
> For one tool i notice that if i reanalyze the architecture
> of micint, then the configuration declaration must be reanalyzed,
> whereas the other tool does not recompile the configuration.
>
> Now per LRM PARAGRAPH 11.4 a given library unit is potentially
> affected by a change in any library unit whose name is referenced
> within the given library unit....
> If a library unit is changed,then all library units potentially
> affected by such changes must be reanalyzed before they can be
> used again.
>
> HERE micint is not referenced at all in configuration
> called conf68302_0.
> To my opinion there is no need to reanalyze the configuration
> after a change in a design unit which does not affect it.
>

YOU ARE RIGHT!! In fact if you have a configuration specification
(not declaration), the enclosing design unit doesn't depend on the
architecture at all (even if you name the architecture) according to
new VHDL92 rules. This makes more sense, 'cos you didn't step inside
the architecture to configure it. And this is the way we support it.


--
Sunder Singhani
Viewlogic Systems,
[e-mail]

--
--
Sunder Singhani
Viewlogic Systems,
[e-mail]