RE: [vhdl-200x] Meeting Reminder: June 30, 8 am Pacific

Hi Chris,

Could the second and third of your requirements be met by allowing access to
VHPI functions directly from VHDL?

Regards,

Peter.

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Higgs, Chris
Sent: 30 June 2011 12:53
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Meeting Reminder: June 30, 8 am Pacific

All,

Unfortunately due to an unavoidable work commitment I won't be able to dial
into the meeting today. I'd like to circulate some of the points I was
hoping to raise in the meeting. Ironically I was going to mention that I'd
be happy to take on any of the administrator roles...

There has been some activity on the collected requirements page (apologies
for the HTML Jim!). It would be good to flesh out some of the suggestions
with justification, implications, comments, alternatives, code examples etc.
but the page is already long and likely to get messy.
Perhaps we should create a new page template and migrate each requirement to
a separate page to allow more detailed discussion.
CollectedRequirements would then become a set of links to the detailed
pages, perhaps with a short summary.

Below is an embryonic discussion about register interfaces which I felt was
too general and vague to put on the CollectedRequirements page. I'd be very
interested to hear any thoughts or suggestions about the best way to create
re-usable and parameterisable register definitions and interfaces, which
seems currently to be very clunky in VHDL.
 
The ideal situation is to have a single register mapping entity for each bus
type (AXI4-lite, Wishbone, custom bus format etc) which takes the read and
write register types as generics, and an offset address at which to map the
register set onto the bus. Read and write registers are defined by record
types (which could be autogenerated from SystemRDL), and the mapping of the
registers onto control bus is handled automatically. Please refer to the
example at the bottom of this e-mail.

The advantage of this system is that it would allow developers to create an
entity taking the control bus as a generic. So I might design some IP with
well defined control/status registers which could be used without
modification on any SoC, regardless of the control bus protocol used. I
think that the lack of this capability is hampering the creation of useful
libraries of components. I believe the following changes to VHDL would make
this possible:

Firstly, a mechanism for automatically converting between record types and
vectors needs to exist (see collected requirements).

Secondly, a mechanism for iterating over members of an arbitrary record type
(this is particularly pertinent with the introduction of type generics).
Since the type of the record is known at compile time it is still possible
to perform strict compile time type checking.

Finally, a mechanism for accessing user defined attributes (this may
currently be defined but I could find any information and it definitely
isn't supported by my simulator). This could be used to indicate
side-effects of reads/writes to various registers. For example:

type write_register_t is record
    enable : std_ulogic;
    reset : std_ulogic; -- Active high, automatically cleared to
0
    reserved: std_ulogic_vector(13 downto 0); end record;

-- Indicate which record members auto-clear on write attribute auto_clear :
boolean; attribute auto_clear of write_register_t.reset : type is true;

Then using a hypothetical member iterator, we can do this:

for member in write'members loop
    if write'members(member)'auto_clear then
        write'members(member) <= (others => '0');
    end if;
end loop;

Simplified example of an rfile entity to map read/write records onto a
control bus:

library axi4;
use axi4.interfaces.all;

entity axi4_lite_rfile is
        generic (
                type read_register_t;
                type write_register_t;
                base_offset : memory_address_t);
        port (
                clk : in std_ulogic;
            srst : in std_ulogic;

            read : in read_register_t;
            write : out write_register_t;

            axi4_cmd : in axi4_cmd_bus;
            axi4_resp : out axi4_resp_bus);
end;

The architecture of this entity would (using the proposed changes) be able
to handle arbitrary read and write registers defined as record types. The
mapping onto address space is deterministic. Each components containing
software-accessible registers can instantiate an rfile and not need to worry
about how the record <-> bus translation occurs.

Thanks,

Chris

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Jim Lewis
Sent: 28 June 2011 15:39
To: vhdl-200x@eda.org
Subject: [vhdl-200x] Meeting Reminder: June 30, 8 am Pacific

Hi,
_Next Meeting_: Thursday June 30 at 8 am Pacific Daylight Time.

_Dial-in details_ - note these may change as I am looking into options for
web based conferencing.
   Dial in 1-800-637-5822
   Intl Access: +1 647-723-3937
   Passcode: 6850837

_Meeting minutes from May 26, 2011 meeting_
   http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/MeetingMay26

_Action Items from May 26 Meeting_
     All: Review VASG Working Group Operating Procedures
         http://www.eda-twiki.org/vasg/docs/p1076_wg_pp.pdf
         Discuss on reflector. Vote after next meeting.
     All: Officer elections soon. We need chair, vice-chair, and secretary.
         All of these are non-technical administrator type roles
     All: Please add your information to the working group roster.
          The roster is working group private,
          so you need to login to get there. You can access it through
          the link on the main page to the Working Group Roster (under
          Working Group Administration).
          If you do not yet have a TWIKI account, send me an email.
     All: Post questions for Harry for him to answer in the presentation on
          the Mentor verification survey. This will allow him to be
prepared.
          It wastes time if he needs to research answers after the meeting.
     All: Take ownership of items that interest you and update the collected
          requirements list
 
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/CollectedRequirements
          This is TWIKI, login and add to the list.
          If you do not have a TWIKI login, send me email.

_Initial Agenda for June 30 meeting_
    Please review IEEE patent policy as you sign in, you will be
    certifying that you have read it and made any required
    disclosures.
 
https://development.standards.ieee.org/myproject/Public/mytools/mob/slid
eset.pdf

   approve May 26, 2011 meeting minutes
     -- You can do this prior to the meeting

   Review Action Items
   Continue discussion of language change requirements.

Best,
Jim Lewis
VHDL Study Group Chair

If you are reading this on the website and wish to receive these via email,
see the following link to sign-up for the reflector:
    http://www.eda-twiki.org/vasg/index.html#Participation

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 under the control of Detica Limited, details
of which can be found at http://www.detica.com/statutory-information.
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.