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

Correction below.

On Thu, Jun 30, 2011 at 10:36 PM, Daniel Kho <daniel.kho@gmail.com> wrote:

> Hi Chris,
> You have interesting suggestions. I'm not sure if I am also trying to head
> the same direction as yourself - I have been also trying to use record types
> with synthesisable bus functional models.
>
> Anyway, below is what I currently have. This is a modification of one of
> Jonathan Bromley's response in a forum (I don't quite remember the exact
> location). I changed a few things in his code that aren't synthesisable
> (such as waits in procedures, etc).
>
> /* In my package declaration, I declared a record type and procedures to
> read/write from a bus. */
> package busFuncModel is
> type axi_ctrl_record is record
> address:std_logic_vector(31 downto 0);
> info:std_logic_vector(31 downto 0);
> end record axi_ctrl_record;
>
> procedure axi_write(signal request:out axi_ctrl_record;
> address: in std_logic_vector(31 downto 0);
> data: in std_logic_vector(31 downto 0));
>
> procedure axi_read(signal request:out axi_ctrl_record;
> signal response:in axi_ctrl_record;
> address : in std_logic_vector(31 downto 0);
> signal data : out std_logic_vector(31 downto 0));
> end package busFuncModel;
>
> /* Then, in my package body, I have the following definitions: */
> package body busFuncModel is
> procedure axi_write(signal request:out axi_ctrl_record;
> address:in std_logic_vector(31 downto 0);
> data: in std_logic_vector(31 downto 0)) is
> begin
> request.address<=address;
> request.info<=data;
> end procedure axi_write;
>
> procedure axi_read(signal request:out axi_ctrl_record; --only the
> address (base+offset) is used, data field is left empty.
> signal response:in axi_ctrl_record; --only the
> data is received, address fields are left empty.
> address : in std_logic_vector(31 downto 0);
> signal data : out std_logic_vector(31 downto 0)) is
> begin
> request.address<=address;
> data<=response.info; --save new data.
> end procedure axi_read;
> end package body busFuncModel;
>
>
>
> /* In your core design, you could then have these processes to read/write
> to/from the bus. */
> axiTx: process(reset,axiTxClk) is
> /* Local procedure to map core signals with the package axi_write
> procedure. */
> procedure axi_write(address:in std_logic_vector(31 downto 0);
> data: in std_logic_vector(31 downto 0)) is
> begin
> axi_write(request,address,data);
> end procedure axi_write;
>
> begin
> if rising_edge(axiTxClk) then
> /* You can have another process to feed the address and
> data, and other more complex logic here too. */
> axi_write(axiAddr,wData);
> end if;
> end process axiTx;
>
>
> axiRx: process(reset,rData,axiRxClk) is
> /* Local procedure to map core signals with the package axi_read
> procedure. */
> procedure axi_read(address:in std_logic_vector(31 downto 0);
> signal data: out std_logic_vector(31 downto 0)) is
> begin
> axi_read(requestRx,responseRx,address,data);
> end procedure axi_read;
>
> begin
> if rising_edge(axiRxClk) then
> /* You can have another process to feed the address and
> data, and other more complex logic here too. */
> axi_read(axiAddr,rData);
> end if;
> end process axiRx;
>
>
>
> I may have missed some things here or there, but this is the basic idea.
> Anyway, I managed to successfully synthesise and simulate a design that uses
> this technique. I haven't verified this on hardware though.
> For a more detailed explanation on how this works, I will need to dig out
> Jonathan Bromley's original forum post.
>
> If you are familiar with Jim's Interfaces proposal, I think this should be
> similar.
>
> Regards,
> Daniel
>
>
>
> On Thu, Jun 30, 2011 at 7:53 PM, Higgs, Chris <Chris.Higgs@detica.com>wrote:
>
>> 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<https://development.standards.ieee.org/myproject/Public/mytools/mob/slid%0Aeset.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.