Re: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list

Jim,

> *If the intent is to abstract an interface, then records cannot handle a
> bus with multiple request and grant lines where each slave interface only
> drives one request and reads one grant. I don't think SV does either.*
>
[Ben] In SystemVerilog you can have interface signals that are wire, and
have multiple drivers. Modports allow you to specify which signals are
inputs, output, or inout.
For example:
interface fifo_if(input wire clk,
                  input wire reset_n);
 wire push; // push data into the fifo
  wire pop; // pop data from the fifo
  wire full; // fifo is at maximum level
  wire empty; // fifo is at the zero level (no data)
  wire almost_empty, almost_full;
  wire error; // fifo push or pop error
  // word_t data_in;
  wire [WIDTH-1:0] data_in;
  wire [WIDTH-1:0] data_out;
...
modport fslave_if_mp (
                        output empty,
                        output full,
                        output data_out,
                        output error,
...
                        input pop);
...
endinterface : fifo_if

In the RTL
module fifo (input clk, input reset_n, fifo_if.fslave_if_mp f_if,
// fifo_csr_if.fifo_ctl_mp f_csr_if
     fifo_csr_if.fifo_ctl_mp f_csr_if
     );
...
 assign f_if.data_out=data_out_reg;
  assign f_if.error = error_reg;
..
endmodule : fifo

>
> * So while records can solve many problems. I think we need some more
> sophistication to solve the general case. Since SV interfaces look a little
> like a class, I was thinking that it would be good to Integrate interfaces
> with classes*
>
> [Ben] I don't think that SystemVerilog interface looks a bit like a class,
they look more like a module in that once instanced, they cannot be
destroyed or delinked. Classes can be created an destroyed. Thus, in
classes, you cannot have interface instances. However, you can declare a
virtual interface that is linked to an actual interface in the the new.
From LRM:* "A virtual interface allows the same subprogram to operate on
different portions **of a design and to dynamically control the set of
signals associated with the subprogram. Instead of referring **to the actual
set of signals directly, users are able to manipulate a set of virtual
signals. Changes to the underlying **design do not require the code using
virtual interfaces to be rewritten. By abstracting the connectivity **and
functionality of a set of blocks, virtual interfaces promote code reuse." *
For example:
class Fifo_cmd_xactor extends vmm_xactor;
 * virtual fifo_if.fdrvr_if_mp f_if;*
  ...
  function new(..
               *virtual fifo_if.fdrvr_if_mp new_vir_if,*
* ...*
               );
     * this.f_if = new_vir_if;*
     ...
  endfunction : new

Ben Cohen SystemVerilog.us

> Best,
> Jim
> ~~~~~~~~~~~~~
> Jim Lewis
> SynthWorks VHDL Training
>
> -----Original Message-----
> From: "Jones, Andy D" <andy.d.jones@lmco.com>
> Sender: owner-vhdl-200x@eda.org
> Date: Tue, 08 Mar 2011 10:23:39
> To: 'vhdl-200x@eda.org'<vhdl-200x@eda.org>
> Reply-To: vhdl-200x@eda.org
> Subject: RE: EXTERNAL: Re: [vhdl-200x] VHDL enhancements wish list
>
> Named composite modes would be "invoked" within a port list, but they need
> not be declared within the port or component/entity/procedure declaration.
> The mode could be defined in the context of a record type (thereby limiting
> its use to connect to objects of that type, but allowing its use on any port
> of that type). More than one mode (e.g. master, slave) could be defined for
> that record type. And the same way a port type must be visible to the
> component entity declaration, so must the port mode, so it would seem
> logical to place both the record type and its associated modes in a package
> invoked by the both the entity and the instantiating architecture.
>
> Proposed usage model:
>
> 1. Declare a record type (e.g. bus_type)
>
> 2. Declare one or more modes (e.g. master_mode, slave_mode) for that record
> type which define the mode to be used for each element of the record (in,
> out, inout, etc.).
>
> 3. Declare one or more signals of that record type (e.g. my_bus).
>
> 4. Declare one or more entities/components/procedures with ports using the
> record type and mode(s) (e.g. slave_device, master_device).
>
> 5. Instantiate one or more entities/components or call procedures, and bind
> their port(s) to the signal(s).
>
> Arrays and/or arrays of records:
>
> Should named modes be usable with composite types in general (arrays and
> records), or just with records?
>
> How would we handle a port for an array of records, for which each array
> element uses the same named mode, as opposed to a named mode declared for an
> array of records (assuming a named mode could include other named modes for
> sub-elements)? Maybe it would be as simple as declaring a mode for the array
> type that is just (others => mode). Would an array mode definition such as
> (1 => master, others => slave) make sense?
>
> Could/should we be able to declare a named mode for an unconstrained array
> type (probably only if it was of the form (others => mode)), or would the
> sub-element record's mode be implicitly applicable to all elements of an
> array of same (the same way in, out, inout, etc. work)? Think of a component
> that instantiates an array of devices connected to an array of busses; it
> would be beneficial to be able to parameterize the number of devices/busses,
> but perhaps not necessary to be able to invoke different modes on different
> records within the array.
>
> Maybe the first-order approach would be that a named mode can only be
> declared for a record type, but that mode is applicable both to ports of
> that type and also to ports of any array of that type on a per-record basis.
>
> Andy D Jones
> Electrical Engineering
> Lockheed Martin Missiles and Fire Control
> Dallas TX
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.