EE295 - ASIC Design Using VHDL
Sub Programs & Packages
Assignment:
- Read Ch 5
- Pg 123 - Rewrite Resolution Function on Pg 120 as Described
- Note Brief Discussion of Synthesis Tool Limitations
- Pg 128-9 - Does procedure vector_to_int Behave Correctly? If Not,
Show How to Re-write it.
Outline:
Functions & Procedures
- Body is Sequential
- From the External View Functions ( and Procedures ) are:
- Sequential Statement When Inside a Process ( or Other Sub-Program )
- Concurrent Statement When Outside a Process
- Declared in Package - Reusable
- Declared in an Architecture - Local
Functions
- All Parameters are IN ; No Need to Declare Mode
- Signals Passed Into Functions as Arguments Carry Attributes
- Returns Only One Argument of the Declared Type
- Used Usually as Part of a Signal Assignment or Expression Evaluation
- parity_bit <= parity ( data_bus );
- --an event on data_bus triggers an assignment to parity_bit
- Declaring a Function:
- FUNCTION foo ( arg1, arg2 : arg type; .. ) RETURN return_type IS
- -- a declarative region
- VARIABLE, CONSTANT
- BEGIN
- .. calculates a return value
- RETURN (value);
- END foo;
In the last class we discussed the strongly enforced Typing
that's part of VHDL. Conversion Functions are your means of satisfying
these type matching requirements.
- Very Popular
- Vendors Often Provide These in a Package
- Underlying Assumption: Types have a Straightforward Relationship
- ie. Natural to Bit
- Would you try Real to Integer?
- Typical Structure:
- FUNCTION t1_to_t2 ( a : t1 ) RETURN t2 IS
- BEGIN
- CASE a IS
- WHEN t1_val => RETURN t2_val
- ...
- repeat as necessary
- END CASE;
- END t1_to_t2;
-
- In a Component Port Map
- ARCHITECTURE portfunc IS
- TYPE my_type
- COMPONENT AND PORT ( A1 : bit;..
- SIGNAL my_sig : my_type;
- FUNCTION my_to_bit ( s : my_type ) RETURN bit IS
- BEGIN
- U1:AND PORT MAP ( A1 => my_to_bit( my_sig ), ...
- END portfunc;
-
- Example on Pg 110
- Including the Functions in the Package is More Typical
Multiply Driven Signals are Pervasive in System Architecture.
A Typical MicroProcessor Architecture Would Impliment the Data and
Address Bus as Having Multiple Sources. A Function is used to Descibe
how the Bus Behaves for all Possible Combinations of Drivers.
- Determine How Multiply-Driven Signals Behave.
- NOTE - There is NO IMPLICIT BEHAVIOR - ie Dotted AND
- That Would Compromise the Technology Independence of VHDL
- Note - Multiply Driven Signals in an ASIC are Untestable Using ATPG
- Foundries may Restrict Their Use
- The Input is an Unconstrained Array of the Driver's Base Type.
- The Result is the Driver's Base Type
-
- Example:
- TYPE my_type IS ( X, Z, 0, 1 );
- TYPE my_type_vector IS ARRAY ( natural RANGE <> ) OF my_type;
-
- FUNCTION resolve_my_type ( a : my_type_vector ) RETURN my_type IS
- VARIABLE temp : my_type := my_type'LEFT;
- --initalize temp to the lowest strength value
- BEGIN
- FOR i IN a'range LOOP --Loop through the possible driving signals
- CASE temp IS
- WHEN my_type_val => CASE a(i) IS
- WHEN my_type_val => temp := my_typ_val;
- -- For every Possible Driving Value Determine a New Value of temp
-
- END CASE;
- END CASE;
- END LOOP;
- RETURN temp;
- END resolve_my_type;
-
- Use ( Resolved SubType ):
- PACKAGE resolved_types
- TYPE my_type IS ( X, Z, 0, 1 );
- TYPE my_type_vector IS ARRAY ( natural RANGE <> ) OF my_type;
- FUNCTION resolve_my_type ( a : my_type_vector ) RETURN my_type IS
- SUBTYPE res_my_type IS resolve_my_type my_type;
- Events on Signals of Type res_my_type Trigger Function resolve_my_type to Evaluate
-
- Use ( Explicit Declaration ):
- SIGNAL another_resolved_signal : resolve_my_type my_type;
-
- Simple Rules: ( from pg 120 )
- Strongest Strength Wins
- If 2 Drivers Have Same Strength ( A tie ) and Different Values..
- ..Return 'X' of Same Strength
- Parameters may be IN, OUT & INOUT and so Must Have a Mode Declared
- Returns Multiple Arguments
- Used Usually as a Stand-alone Statement
- Example:
- Procedure foop ( arg1, arg2 : arg type; arg3.. ) IS
- -- a declarative region
- BEGIN
- ... Does Something
- END foop;
- Encapsulates Objects that can be Shared or Re-Used
- IEEE Defines Some
- Technology Providers and CAD Vendors Can To
- Organized into 2 Parts:
- Header
- Declaration Section
- Provides a Visible Interface
- PACKAGE pack_name IS
- --Declarative Region
- TYPE | FUNCTION | SUBTYPE | CONSTANT
- END pack_name;
- Body ( Optional )
- Invisible Specification
- Enables Deferred Specification
- Hides Intellectual Property
- PACKAGE BODY pack_name IS
- --Implimentation of Header Objects
- --Additional SubProgram, Type, Constant, File, Alias, Use Declarations
- END pack_name;
How was the class? Send your comments to jswift@vnet.ibm.com
Return to Class Home Page
Copyright 1995, James Swift
Copying this document without the permission of the author is prohibited
and a violation of international copyright laws.