Re: [vhdl-200x] Why OOP vs Generics

Why Generics vs. OOP/AOP?
I don't view these as an either-or thing. I want to use
generics in conjunction with OOP.

To get an understanding, VHDL already has protected types,
which are a partial implementation of a class. Like packages,
a protected type has a declaration part and a body part.
The protected type declaration defines the external interface
and contains only methods (subprograms) declarations. The
protected type body contains private variables (visible only
to methods in the protected type), private subprograms, and
method bodies.

Consider the following protected type:
   type MemoryPType is protected
     procedure MemInit (
       constant AddrBits : In integer ; -- width of address
       constant DataBits : In integer -- width of data
     ) ;

     procedure MemWrite (
       Addr : In std_logic_vector ;
       Data : In std_logic_vector
     ) ;

     impure function MemRead (
       Addr : In std_logic_vector
     ) return std_logic_vector ;
   end protected MemoryPType ;

To create a memory model, we simply create a shared variable in
the architecture. To write, we call the MemWrite method and
to read we call the MemRead method. Templates are shown below.
   architecture Model of Sram is
     shared variable ptRam : MemoryPType ;
     . . .
   begin
     -- Initialize - construct the memory data structure
     ptRam.MemInit(AddrBits => ADDR_WIDTH, DataBits => DATA_WIDTH) ;

     RamWriteProc : process
     begin
       wait until ... ;
       ptRam.MemWrite(Address, Data) ; -- write
     end process RamWriteProc ;

     ReadProc : process
     begin
       wait until ... ;
       Data <= ptRam.MemRead(iReadAddress) ; -- read
     end process ReadProc ;

What is cool about protected types/OOP/AOP is that you do not
need to know anything about the implementation. You only
need to know MemWrite does a write and MemRead does a read.
That means a simulation efficient model (such as a sparse
pointer implementation) can be swapped for a more accurate
model (such as the Vital memory model) if needed. Using
protected types, memory modeling is no more difficult than
an array access.

Also note that protected types allow the data structure to
be accessed from separate processes. This also means that
if we standardize a package such as this, vendors can replace
the package body with their own more efficient implementation.

You can get similar capability with regular subprograms,
however, you will make some sacrafices. First of all, to
create a sparse memory implementation, access types will be
required. With access types, you must use a variable,
which then localizes the data structure to a single process.
So while do-able, it is much more complicated. Then if you
want to swap in a more accurate model, there can be additional
complications.

With just protected types we can easily implement memory models.
Add generics to packages (and even better, to protected types),
then scoreboards, FIFOs, content addressable memories all are
fairly straight forward.

OO extensions really will require several emails to detail, however,
I look at OO extensions to protected types as continuing to
build our tool box. One target feature to implement is coverage.
The basic class would contain private/protected variables for
storing coverage counts, coverage bin identification (for reporting),
and coverage bin data structures. This would cover the common
cases that SV and e provide. Class extensions would be used to
cover the conditions that are not so easy to count when a generic
procedure ie: where when one item is active, don't count another one.

Best,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.