RE: EXTERNAL: RE: [vhdl-200x] Records with directional subtypes

The resolved subtype serves to identify the resolution function, which is not called until run-time. Some implementations only report unresolved signals with multiple drivers at run-time. There is now a proposal to include mode info in subtypes. FWIW I think this is dirty.

I am in line with the folks who want to "package up" mode info for record elements so it can be re-used by name, rather than being repeated as records propagate up and down the hierarchy. How about we declare the modes in some totally new kind of thing that can be declared in a package and then called out by name?

Just an opinion.

Cheers,

John A

-----owner-vhdl-200x@eda.org wrote: -----
To: "vhdl-200x@eda.org" <vhdl-200x@eda.org>
From: "Jones, Andy D"
Sent by: owner-vhdl-200x@eda.org
Date: 08/23/2012 02:50PM
Subject: RE: EXTERNAL: RE: [vhdl-200x] Records with directional subtypes

       
 I have no problem with directional subtypes. We have had resolved subtypes since the beginning of VHDL. Are they substantially more “pure” than directional subtypes? What about protected types, are those also unclean?
  
 And as indicated previously, this method allows a clean syntax, largely consistent with existing parsers.
  
 The way I see it, the default mode for a port of any type is “in”. Directional subtypes (even of non-composite types) are simply a way of defining the default mode of a port of that subtype as something other than “in”. In terms of ease of implementation, I think this makes it pretty simple.
  
 We should consider whether it is an error to specify a standard mode on a port of a directional subtype.  Or should a specified standard mode silently override the directional subtype’s inherent mode? I can’t think of a real use for the latter off the top of my head, but it is more consistent with the existing behavior of default vs. explicit port modes.
  
 We also need to develop a way of defining a port subtype for a record of records (a complex composite type). One could define subtypes from the bottom up for the various element records, but how would we indicate the subtype names in the port definition of the higher level subtype? Borrowing from the existing default port mode syntax, the following could work:
                                                                                                                                                  
 Subtype t_slave of t_complex_composite is port (scalar_element: in [t_scalar], composite_element: t_composite);
  
 t_composite is the name of a directional subtype of the base type of the element.
  
 In general terms, the syntax would look like:
  
 Subtype t_slave of t_composite is port (element1 : [mode] [type_mark]; element2: …);
  
 It would be an error if a port element’s specified type_mark was neither the name of the base type’s element’s type, nor the name of a directional subtype of the base type’s element’s type. If neither mode nor type_mark is specified for an element, then the element defaults to mode IN.
  
 I tend to agree with the sentiment that trying to handle a multi-drop, bidirectional bus seamlessly within a single type and its subtypes is of limited utility, especially compared to the complexity of a suitable solution, at least for synthesis. And outside of synthesis, we have custom resolved types that can solve this problem much more easily. Let’s not lose sight of the primary goal that this issue started with: named composite modes for record types.
  
 That said, the idea of generic (sub)types has huge merit in and of itself. If we can have types defined in generic packages, what’s so different about generic types? I see this issue as largely orthogonal to directional subtypes, though it could enhance the utility of them. But this really needs to be a separate issue for consideration.
  
 Andy D Jones
 Electrical Engineering
 Lockheed Martin Missiles and Fire Control
 Dallas TX
  
  
  
 
 
 From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Peter Flake
 Sent: Thursday, August 23, 2012 5:26 AM
 To: vhdl-200x@eda.org
 Subject: EXTERNAL: RE: [vhdl-200x] Records with diectional subtypes
    
 I agree that drivers must be determined statically.  So one could make port subtypes a special case and resolve them statically. An alternative is to define a new category of type, with new rules for port maps.
  
 If you regard a subtype as a restriction on a type, restricting the direction can be seen as keeping to the spirit of VHDL.
  
 Regards,
  
 Peter Flake
  
  
 From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of john.aynsley@doulos.com
 Sent: 22 August 2012 12:10
 To: vhdl-200x@eda.org
 Cc: vhdl-200x@eda.org
 Subject: Re: [vhdl-200x] Records with diectional subtypes
  
 Don't you have an issue with the concepts of type vs subtype and the determination of drivers? Types get resolved statically, subtypes are not (in general) determined until run-time. Is it not the case that pushing mode info into the subtype makes it too late to determine the drivers of the signals? How is this supposed to be implemented (in the tool)?
 
 Apart from that, the notion of pushing modes into subtypes seems to contradict the conceptual framework of VHDL. But perhaps that's just me being unimaginative ;-)
 
 Cheers,
 
 John A
 
 --
 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.

=

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.