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

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,resetRequested,s_axi_aclk) 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,resetRequested_anlysr,reset_complete,rdata,aux_clk) 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.