RE: [vhdl-200x] Request for Input

Hi Ryan,

Apologies, I should have been more explicit. My example code is to
demonstrate how a hierarchical library system might look if implemented.
The suggested change to VHDL is to make this code legal.

Thanks,

Chris

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of ryan.w.hinton@L-3com.com
Sent: 10 January 2011 20:26
To: vhdl-200x@eda.org; Jim Lewis
Subject: RE: [vhdl-200x] Request for Input

Chris,

I do not understand what is "flat" about your example for point (1)?
(Repeat example for convenience:)

<code>
library protocol.packet.ethernet;
use protocol.packet.ethernet.constants.all;
</code>

It appears that you are flattening a hierarchy, but you don't *have* to.
You can refer to objects as
'protocol.packet.ethernet.constants.BUS_WIDTH' and maintain hierarchy if
you prefer. The only non-standard VHDL I see in your example is the
hierarchical library name. That sounds like a nice language addition.
I think I saw another suggestion on the list to allow more levels of
hierarchy within a library as well. (This is currently limited to the
package name.)

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Chris Higgs
Sent: Monday, January 10, 2011 7:13 AM
To: Jim Lewis; vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Request for Input

All,

If you can bear with me, I would like to belatedly add my tuppence to
the discussion.

I believe that it will be very difficult for VHDL to directly compete
with SystemVerilog, C/C++ and other languages in the verification arena.

VHDL is excellent as an HDL but for common tasks expected of a decent
verification environment it is lacking. Nobody sane would attempt to
write VHDL code to read a PCAP file into a testbench, a common
requirement in the packet-based networking field in which I work. It's
not even possible to communicate over sockets using pure VHDL AFAIK but
as testbenches become more complex these deficiencies will only become
more pronounced.

However, none of this weakens the case for choosing VHDL when embarking
on a new hardware design. As long as it is straightforward to interface
to other languages more suited particular tasks, VHDL remains an
excellent HDL choice with many advantages. For example, reading a PCAP
file and squirting the packets onto a bus can straightforward in python
with appropriate VHPI/PLI infrastructure:

<code>

from vhdl.bus import PacketBus

import scapy.all

def squirt_pcap(filename, bus, clk):
    """Drive packets from a pcap file onto a bus with data and
        bytesvalid members synchronous to clk"""

    for packet in scapy.utils.rdpcap(filename):
        for word, bytesvalid in PacketBus(packet, len(bus.data)):
            yield clk.edge(1)
            bus.data <= word
            bus.bytesvalid <= bytesvalid

        yield clk.edge(1)
        bus.valid <= 0

</code>

Trying to provide constructs in VHDL to allow engineers to write more
complex testbenches will result in huge pile of work for tool vendors,
which based on the existing support for VHDL 2008 will take many years
to implement (is there even a single vendor with full VHDL 2008
compliance on their roadmap let alone implemented?). We should focus on
making VHDL more useful to the majority of users.

Promoting use of VHPI to encourage engineers to utilise the collection
of libraries and models already available in other languages will be
more profitable in the long term than facilitating more complicated
testbenches written in pure VHDL. Providing reference/example code for
some common tasks might sway the decision of designers who have avoided
using VHPI to date due to difficulties deciphering documentation or
fighting incomplete implementations and encourage tool vendors to
support at minimum the examples.

Improving VHDL should certainly happen but should specifically target
hardware related development (ie adding timing constructs) or improve
ease of use rather than increase the available complexity of
non-synthesisable code.

In terms of ease of use / convenience I have 2 specific suggestions:

1. As mentioned earlier in this group, fully hierarchical namespaces are
an urgent requirement and quite their omission a serious limitation of
VHDL. When working on a large project involving many libraries the
flatness of VHDL breaks any nice mappings between VHDL code, directory
structure and C++/python namespaces and makes naming clashes more
likely.

<code>
library protocol.packet.ethernet;
use protocol.packet.ethernet.constants.all;
</code>

2. A mechanism for converting arbitrary records to and from vectors. I
have seen many examples of engineers either writing or automatically
generating to_vector(my_type) and corresponding from_vector(vector)
functions for each record type declared. This is required in quite a
large number of scenarios if record types are used in a design (fifos
etc) and is both time consuming and frustrating. See these sources for
other examples of this requirement and solutions:

comp.lang.vhdl post "Mapping a std_bit_vector to a record" 05-02-2006
http://stackoverflow.com/questions/3985694/serialize-vhdl-record

Can we provide this functionality in VHDL itself? There is no reason
that a defined vector cannot be created from any arbitrary record type
(which may be nested) provided any unknown types also have to_vector
functions themselves defined. For example:

<code>

type state_t is (IDLE, BUSY);

-- This function must be defined because it is not possible to
automatically
-- determine how to convert an arbitrary type into a vector
function to_vector(i : state_t) return std_logic_vector is
    variable v : std_logic_vector(1 downto 0);
begin
    if state = IDLE then
        v := '0';
    else
        v := '1';
    end if;
    return v;
end function;

type my_record_t is record
    state : state_t;
    some_vec : std_logic_vector(SOME_GENERIC-1 downto 0);
    some_record : another_record_t;
end record;

signal my_record : my_record_t;

-- We have some new attribute to determine the size of a vector
signal my_record_vector : std_logic_vector(my_record_t'vlength downto
0);

-- These functions are implicit based on some defined algorithm to
convert
-- between a record and vector
my_record_vector <= to_vector(my_record);
my_record <= from_vector(my_record_vector);

</code>

Regards,

Chris

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Jim Lewis
Sent: 18 December 2010 09:23
To: vhdl-200x@eda.org
Subject: [vhdl-200x] Request for Input

Hi,
During the last meeting Victor Berman requested that
the study group provide a report to accompany the PAR
that further elaborates on the purpose of the PAR:

  "The VHDL language was defined for use in the
   design and documentation of electronics systems. It is being
   revised to incorporate capabilities that improve the language's
   usefulness for its intended purpose as well as extend it to address
   design verification methodologies that have developed in industry.
   These new design and verification capabilities are required to
   ensure VHDL remains relevant and valuable for use in electronic
   systems design and verification."

In reality, the PAR is this general since the working group
will vote on and decide exactly what this means, however,
since it is likely that I will asked to answer this during
the DASC meeting it would be nice to have ideas from the
study group.

For example, what is intended by verification enhancements?
This could mean something like:
Create an API/interface/package that allows interfacing
VHDL to SystemC and/or SystemVerilog/UVM.

It could also mean we implement full OO and UVM-like
stuff in VHDL.

What I present to DASC may end up being a range of
ideas that the working group will have to decide on.

With that, let the discussion begin.

I hope to present this at the January 6 DASC meeting.

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.
Please consider the environment before printing this email.
This message should be regarded as confidential. If you have received
this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard
copy by an authorised signatory.  The contents of this email may relate
to dealings with other companies within the Detica Limited group of
companies.
Detica Limited is registered in England under No: 1337451.
Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP,
England.
-- 
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.
Please consider the environment before printing this email.
This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Limited group of companies.
Detica Limited is registered in England under No: 1337451.
Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.