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.Received on Thu Jun 30 04:54:13 2011
This archive was generated by hypermail 2.1.8 : Thu Jun 30 2011 - 04:55:53 PDT