On Wed, Mar 4, 2015 at 5:40 AM, Tristan Gingold <tgingold@free.fr> wrote: > On 04/03/15 00:32, Brent Hayhoe wrote: >> >> >> From your interface suggestions, I thought that I'd detail and adapt >> them to a possible solution. >> >> It looks quite concise and a nice first attempt. >> >> What do you think? >> >> So the record and signals:- >> >> type r_cpu_bus is record >> adr: std_logic_vector(15 downto 0); -- Address >> dat: std_logic_vector(15 downto 0); -- Data between master and >> slave >> cs: std_logic_vector(7 downto 0); -- ChipSelect-bus from master >> we: std_logic; -- Write enable from master >> en: std_logic; -- Enable from master >> ack: std_logic; -- Acknowledge from slave >> err: std_logic; -- Error from slave >> end record r_cpu_bus; >> >> signal s_rst: std_logic; >> signal s_clk: std_logic; >> signal s_cpu_bus: r_cpu_bus; >> >> >> >> The interface definition to associate the modes for master and slave >> ports with the record type. >> >> I've included the short attribute option (defining the slave port) as a >> comment >> with an attribute of converse/conjugate/inverse/opposite etc, at the end:- >> >> interface i_cpu_bus of r_cpu_bus is >> port master( >> adr: out; >> dat: inout; >> cs: out; >> we: out; >> en: out; >> ack: in; >> err: in >> ); >> port slave( >> adr: in; >> dat: inout; >> cs: in; >> we: in; >> en: in; >> ack: out; >> err: out >> ); >> -- port slave(master'converse); >> end interface i_cpu_bus; >> >> >> >> This is how they would be used to encapsulate the mode and type together >> in an >> entity declarations:- >> >> entity cpu_master is >> port( >> rst: in std_logic; >> clk: in std_logic; >> cpu_bus: i_cpu_bus.master >> ); >> end entity cpu_master; >> >> entity cpu_slave is >> port( >> rst: in std_logic; >> clk: in std_logic; >> cpu_bus: i_cpu_bus.slave >> ); >> end entity cpu_slave; >> >> >> >> And finally the normal record use when instantiating components:- >> >> cpu_master_inst: cpu_master >> port map( >> rst => s_rst, >> clk => s_clk, >> cpu_bus => s_cpu_bus >> ); >> >> cpu_slave_inst: cpu_slave >> port map( >> rst => s_rst, >> clk => s_clk, >> cpu_bus => s_cpu_bus >> ); > > > From a language point of view, this looks fine. > > My concern is from a user point of view: this is more verbose than the > initial proposal: you need to declare a record and then an interface. > I think this is a critical point, but I'd like to heard from others on > that point. > > Tristan. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > Hi guys, It's great to see that you're getting close to a syntax for this. I got a few comments on the latest proposal 1. Looking at the entity declaration, are we using the dot notation like this anywhere else? Classic ports uses <name> : <mode> <type>, so why not go with that, e.g. cpu_bus : master i_cpu_bus . My first worry here was that this would need unique names for all interfaces, but type inference should sort that out for us. 2. Regarding conjugated or converse. Someone suggested mirrored, and I think that is a better name. My main (only) reason for that is that this is how things are named in IP-XACT. 3. I agree that it would be nice to make it a little less verbose, but I dont' think the proposal is that bad. It will still save me a ton of writing by no longer having to do an artificial split between input and output ports. Also, I'm not sure how much smaller it could be and still retain all the needed information. We most likely need to have the record anyway, and adding 1-3 interfaces isn't that big deal Cheers, Olof -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Mar 3 23:52:32 2015
This archive was generated by hypermail 2.1.8 : Tue Mar 03 2015 - 23:53:09 PST