Hi Jim, Brent, and all, I was just reading about the SPI Example <http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/SpiExample> use case, and generally, I like the idea of having record views, and the idea of applying the discriminated record syntax to a record view. While I favor the concept of having record views to indicate direction, one thing that bothers me is the possible conflict between the syntax of the record view and a record. Two things crossed my mind: - syntax consistency with existing VHDL constructs, such as the "record" construct - an earlier proposal regarding conjugated modes I know the proposal's main focus was to describe the concept and not really about getting the syntax correct (yet). Nonetheless, I was still thinking about the syntax while reading the proposal. From the SPI Example, we have a directionless record (made mosi and miso serial): type spi_r is record mosi : std_logic; -- Data from master to slave miso : std_logic; -- Data from slave to master sclk : std_logic; -- Serial clock ssel : ssel_vst -- Chip selects end record spi_r; and a record view of the Master interface (renamed to "spi_master_view" to indicate that the SPI Master is a generic interface): record view spi_master_view of spi_r is element( mosi : out; miso : in; sclk : out; ssel : out ); end record view spi_master_view; Consider the syntax for the usual record construct: type record_type_simple_name is record identifier {, identifier } : subtype_indication ; {identifier {, identifier } : subtype_indication ;} end record [record_type_simple_name ] ; If we use an "end record view" for the proposed record view construct, to be consistent with existing VHDL, I believe we should follow the syntax of the record type construct of VHDL. Otherwise, parsers may have difficulty distinguishing whether an "end record" ends a normal VHDL record or the proposed record view. To be consistent with the record construct, I was thinking a syntax along the lines of: type spi_master_view of spi_r is record view mosi : out; miso : in; sclk : out; ssel : out; end record view spi_master_view; and do without the "element" clause. Another thing that crossed my mind was an earlier proposal <http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceAttributes> by John Aasen regarding the use of conjugated modes. In that proposal, the use of improved subtypes offers the same concept of a view. subtype spi_master_view is spi_r port( mosi : out; miso : in; sclk : out; ssel : out ); I personally don't fancy having to specify modes for all individual signals for both master and slave views whose directions are conjugates of each other. Using John's concept of conjugated modes, we could have a slave view as such: -- For a conjugated view of all signals from master: subtype spi_slave_view is spi_master_view'conjugated; -- For a conjugated and partial view of master: subtype spi_slave_view is spi_master_view'conjugated generic( IDX : ssel_rng ); port( ssel : std_logic is ssel(IDX); others : <> ); Or, if we really want the "record-like" view, we can have: type spi_slave_view of spi_master_view'conjugated is record view generic( IDX : ssel_rng ); ssel : std_logic is ssel(IDX); others : <>; end record view spi_slave_view; Implementing these interfaces would follow the same syntax as in the SPI Example proposal: entity qspi_flash generic ( pkg : spi_bus_pkg; CS : pkg.ssel_rng; Tpd : time := 1 ns; Ts : time := 1 ns; ); port ( spi : view pkg.qspi_slave_view generic map (IDX => CS); wren : in std_logic := 1 ); end entity qspi_flash; entity spi_adc generic ( CS : spi_bus_3slv.ssel_rng; VREF: real; Tpd : time := 5 ns; Ts : time := 5 ns; ); port ( spi : view spi_bus_3slv.spi_slave generic map (IDX => CS); ain : in real; ); end entity spi_adc; Drawing from the RTL implementation in the SPI Example, we can connect any custom-designed (or pre-existing SPI designs) to our SPI bus by using port maps: entity Testbench end entity Testbench; architecture TB of Testbench is signal clk : std_logic; signal rst : std_logic; signal spi : spi_bus_3slv.spi_r; -- Let's assume we already have these pre-existing QSPI signals. signal din : std_logic; signal dout : std_logic; signal sclk : std_logic; signal cs : std_logic; begin ... MEMORY: entity work.qspi_flash port map ( clk => clk, rst => rst, -- This mapping is where the chip select is selected -- using the CS generic above. spi => spi_slave view of spi generic map (IDX => 0) port map ( * mosi => din, miso => dout, sclk => sclk, ssel => cs,* ) ); ADC: entity work.spi_adc generic map ( VREF => 3.0 ) port map ( spi => spi_slave view of spi generic map (IDX=> 1), adc => monitored_voltage ); DAC: entity work.spi_dac generic map ( VREF => 3.0 ) port map ( spi => spi_slave view of spi generic map (IDX=> 2), aout => driven_voltage ); -- And our resistive pullups. spi.miso <= (others => 'Z'); end architecture TB; Cheers, Daniel On Wed, 25 Nov 2015 at 05:16 Jim Lewis <jim@synthworks.com> wrote: > Hi Brent and All, > I was thinking of a different example from constraining an array. > To me the discriminated record syntax is just a simpler way of > applying a value to something than a generic and it seems to be > able to be applied at usage time. > > In addition, I was thinking of applying discriminated record syntax to > a record view. Drawing from Rob Gaddi's SPI example, this simplifies > it to: > > record view qspi_slave (IDX : ssel_rng) of spi_r is > mosi : in; > miso : out; > sclk : in; > cs : in std_logic is ssel(IDX) > end record view qspi_slave; > > record view spi_slave (IDX : ssel_rng) of spi_r is > din : in std_logic is mosi(0); > dout : out std_logic is miso(0); > sclk : in; > cs : in std_logic is ssel(IDX) > end record view spi_slave; > > > Then on the entity interface it becomes: > > entity qspi_flash > generic ( > pkg : spi_bus_pkg; > CS : pkg.ssel_rng; > Tpd : time := 1 ns; > Ts : time := 1 ns; > ); > port ( > spi : view pkg.qspi_slave (IDX => CS); > wren : in std_logic := 1 > ); > end entity qspi_flash; > > > However, the SPI example seems to expose some flaws. In Rob's SPI > example, the base type assumes a QSPI. How do I connect that QSPI > bus with an already designed SPI model? I should not have to redefine > the type of the SPI model in terms of QSPI. > > Hence, it seems like we need a separate association between the types > that perhaps works in a fashion similar to the conversion function that > Lieven has in his proposal. > > Also how do I connect to a model that does not use a bundle/interface? > > I think I will start a separate thread for these. > > Cheers, > Jim > > > > On 11/22/2015 2:56 AM, Brent Hayhoe wrote: > > Some thoughts: > > > > -- So this is the Ada 'discriminated record' type that I presume we are > > -- discussing. The way it looks to me is just a 'constant generic' > applied to -- the record type: > > > > type Discriminated_Record (Size : Natural) is > > record > > A : String (1 .. Size); > > end record; > > > > -- So if I VHDL'asize this we could have a generic block preceding the > record > > -- block in the type declaration. > > > > -- We then need to 'generic map' the 'Size' value through when we > declare a > > -- constant and signals: > > > > type MyRecType is > > generic( > > Size : Natural > > ); > > record > > A : String (1 to Size); > > end record MyRecType; > > > > constant MyRecConst : MyRecType generic map(10) := (A => > "0123456789AB"); > > > > signal MyRecSig1 : MyRecType generic map(10) := MyRecConst; > > > > signal MyRecSig2 : MyRecType generic map(Size => 10); > > > > > > -- Bearing in mind the ability to have a arrays of records, we need to > be able > > -- to apply generics to arrays in a similar manner. > > > > -- Now in the type declaration we need to pass the generic through to the > > -- record elements using a generic map construct: > > > > type MyArryType is > > generic( > > Size : Natural > > ); > > array(1 to 20) of > > MyRecType generic map(Size); > > > > constant MyArryConst : MyArryType generic map(10) := > > (1 to 20 => (A => > "0123456789AB")); > > > > signal MyArrySig1 : MyArryType generic map(10) := MyRecConst; > > > > signal MyArrySig2 : MyArryType generic map(Size => 10); > > > > > > -- The syntax suggested above is meant to be similar to that of entities > with > > -- generics and the mapping of the generics done at an equivalent > instantiation > > -- point. > > > > -- The alternative is to instantiate similar to packages or maybe we > allow both > > -- optional forms? > > > > -- Let's assume 'MyRecType' is declared in a package somewhere. We > instantiate > > -- it as shown: > > > > type MyRecType_10 is new MyRecType > > generic map(Size => 10); > > > > constant MyRecConst : MyRecType_10 := (A => "0123456789AB"); > > > > signal MyRecSig1 : MyRecType_10 := MyRecConst; > > > > signal MyRecSig2 : MyRecType_10; > > > > -- For the array we may want to now define it as: > > > > type MyArryType_10 is > > array(1 to 20) of > > MyRecType_10; > > > > -- This is fine unless we want to keep the generic nature of the array > type and > > -- declare it within the package. In this case we need to to use the > first > > -- embedded 'generic map' syntax within the array declaration syntax. > > > > -- Maybe we should allow both? > > > > Regards, > > > > Brent. > > > > > > On 19/11/2015 22:05, Jason Borland wrote: > >> That would work very well. > >> > >> Jason > >> > >> Sent from my iPhone > >> > >>> On 19 Nov 2015, at 9:12 p.m., Jim Lewis <Jim@synthworks.com> wrote: > >>> > >>> Hi, > >>> In this weeks meeting some expressed concerns about generics on > interfaces. > >>> > >>> ADA has a concept of discriminants that actually may address the > situation we > >>> are working with well. See the web page: > >>> https://en.wikibooks.org/wiki/Ada_Programming/Types/record > >>> > >>> Cheers, > >>> Jim > >>> > >>> -- > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> Jim Lewis > >>> VHDL Training Expert, SynthWorks > >>> IEEE 1076 VHDL Working Group Chair > >>> Open Source VHDL Verification Methodology (OSVVM), Chief Architect and > Co-founder > >>> > >>> 1-503-590-4787 > >>> Jim@SynthWorks.com > >>> http://www.SynthWorks.com > >>> > >>> VHDL Training on leading-edge, best coding practices for hardware > design and verification. > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jim Lewis Jim@SynthWorks.com > VHDL Training Expert http://www.SynthWorks.com > IEEE VHDL Working Group Chair > OSVVM, Chief Architect and Cofounder > 1-503-590-4787 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- Best regards, Daniel - Sent from my Samsung mobile -Received on Fri, 27 Nov 2015 03:28:08 +0000
This archive was generated by hypermail 2.1.8 : Thu Nov 26 2015 - 19:28:52 PST