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

Hi Peter,

While the capabilities exist in VHPI for record introspection and access
to signal attributes, I want to write synthesisable VHDL so calling out
to VHPI isn't an option.

I'm proposing that we make record introspection available in VHDL
itself. The current situation makes it difficult to write universal
entities that manipulate record types. Although type generics allow an
entity to have an arbitrary record-based port, it is not possible to
manipulate the record members unless you already know about the type
that has been passed to you via the generic. With vectors and arrays we
can iterate over the entries but there is no equivalent mechanism for
working with records.

Thanks,

Chris

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Peter Flake
Sent: 30 June 2011 15:34
To: vhdl-200x@eda.org
Subject: 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

<snip>

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.