In VHDL some signal attributes (eg 'TRANSACTION) are implicit signals. Others (eg 'EVENT) are not. Why is this?
The returned VHDL object, its type and value is not restricted by the language. Wheras user-defined attributes are restricted to be constant values.
6.7 Attribute declarations
An attribute is a value, function, type, range, signal, or constant that may be associated with one or more named entities in a description. There are two categories of attributes: predefined attributes and user-defined attributes. Predefined attributes provide information about named entities in a description. Clause 16 contains the definition of all predefined attributes. Predefined attributes that are signals shall not be updated.
User-defined attributes are constants of arbitrary type. Such attributes are defined by an attribute declaration.
§ 6.7 on p. 92, IEEE Standard VHDL Language Reference Manual, IEEE Standard 1076-2008
So built-in attributes can map to almost everything. In case of 'transaction the return object is a signal of type bit.
The attribute or tick syntax is a nice compact thing in the VHDL language. It's used for several purposes.
Related
Does VHDL provide a simple mechanism for duplicating enumeration types to allow the creation of objects that can hold the same set of values but cannot be connected or assigned to one another?
The use case would be to have logic types that would represent signals that should not be connected except to a certain other set of signals - e.g. clocks of various frequencies or resets that should not be tied to each other or to a data bit. This way, the compiler can check for those sorts of connection errors and the type names in the code can carry meaning themselves, e.g. clk40mhz_t.
It seems as though one could just copy-paste define an enumeration similar to that for std_ulogic for any such type and define suitable conversion functions. Is there a handier way than that, though?
I’ve tried a straightforward declaration like
type clock_t is std_ulogic;
But since std_ulogic is not a range, this isn’t a valid type declaration.
So I also tried a few other ill-conceived and ill-fated constructions such as std_ulogic’range, range std_ulogic’range, range std_ulogic’left to std_ulogic’right, and (std_ulogic’range).
All were understandably met with compiler errors (compiling with Quartus Prime Pro 22.3).
"Sets can be declared using instances of the Set and RangeSet classes or by assigning set expressions. The simplest set declaration creates a set and postpones creation of its members."
That isn't a definition, what should a set be used for?
A set is an indexing mechanism. If you are familiar with basic python, you index lists by a numerical index. You can “index” a dictionary by keys that are hashable, etc.
So in most models you have collections of things, perhaps products, with variables and parameters (constants) that are related to these collections. So you might have a group of products {pc, tablet, iphone} and parameters that are logically indexed by this set…. cost[pc], cost[tablet], etc.
In Pyomo, you can declare a set and use that set to index a variable or parameter, etc. At the simplest level, you can just use a range of numbers, but you might use something more logical, depending on the model.
If this is confusing, you might consider locating an introductory textbook on Linear Programming.
The Pyomo Documentation Release 6.4.2 defines Set as A component used to index other components. (cf page 255)
Pyomo Set objects are compatible with Python set objects. It might help to look at the Python documentation:
A set is an unordered collection with no duplicate elements.
Sets can be used to model the presence or absence of properties (colors, brands, etc). Sets are basic data structures for all sorts of algorithms. They can be used to model the relations between other objects. The theory of sets was historically promoted/discussed as the basis of mathematics (Wikipedia link).
Reading through the LRM, and it appears to imply anything can be aliased, but when I try the following, ActiveHDL tells me a design unit is expected:
entity some_entity is
.....
end entity;
alias another_name is some_entity;
The LRM states (in 6.6.1) that
An object alias is an alias whose alias designator denotes an object (i.e., a constant, a variable, a signal, or a
file). A nonobject alias is an alias whose alias designator denotes some named entity other than an object.
An alias can be declared for all named entities except for labels, loop parameters, and generate parameters.
Or is it just the case that because an alias is a declarative item, it must exist in an declarative region? But given that an alias takes on the same class as the aliased item, surely it should be allowed in the same region? This appears to compile ok:
package alias_package is
alias another_name is work.some_entity;
end package;
Explanation for the above request: Lets say I want to rename some_entity, but it is used all over my design. Creating an alias to it would allow this, keeping the old name as an alias to the new one. Using the package would be unsuitable here as it would still require name modification at instantiation.
Is this worthy of a request for the next LRM?
Or is it just the case that because an alias is a declarative item, it must exist in an declarative region?
Yes. A design file is comprised of one or more design units and an entity declaration is a design unit. A design unit is comprised of one or more nested declarative regions. The root declarative region (with an optional context clause encompasses the design unit itself and any subordinate secondary design units.
There's no delimiter for declarative regions other than the end of a design unit.
But given that an alias takes on the same class as the aliased item, surely it should be allowed in the same region?
No. A declaration doesn't take effect (it's name doesn't become visible) until after the declaration is complete. Here, after end [entity_simple_name] ;.
A new design unit begins with optional context items (beginning with reserved words library, use or context) followed by a primary unit declaration or secondary unit body (indicated by one of the reserved words entity, architecture, package, configuration, context (here ignoring PSL, tool directives and comments).
Design units are independently analyzed.
The classes of aliases are object and non-object. An alias declaration targets the declaration of a named entity (and some name declarations are implicit).
Is this worthy of a request for the next LRM?
This question is a request for a subjective opinion without a clear use case (providing examples, particularly in a design hierarchy). The reason isn't clear. What work are you trying to avoid?
As an opinion otherwise, no.
There are also parts of the standard that are poorly supported by synthesis vendors that already address modifying binding from the default by exception (configuration declarations containing context specifications or component instantiation with the reserved word configuration).
Our simulator allows VHDL / Verilog mixed and our design uses an IP that written in VHDL (otherwise, our design is mostly in Systemverilog).
We are having problems as parameter overriding is not correctly working and we found the following statements from Simulator's documentation:
"By default, when a Verilog module is instantiated inside a VHDL design unit and default binding is done, VHDL generics are mapped to Verilog parameters using positional mapping."
It is saying that mappings of VHDL generics to Verilog parameters are done using positional mapping, not named mapping. The simulator offers a special option to change the binding rule to "named mapping" and that solved our problem.
My question is which standard specifies the binding rule when it comes to Verilog inside VHDL (or VHDL inside Verilog)?
Or, is this an arbitrary choice the simulator vendor made?
The unfortunate truth is there is no standard for interoperability between standards. Why this is the case may be highly opinionated. But I can say that if more people bring this issue up to their vendors, the more likely it may get addressed.
I am working on a design (VHDL-2002) where user-defined attributes are attached to different design units. The attribute values may be passed through the design hierarchy.
Is there a (common) way to list the values of these attributes at synthesis time? Something like VHDL's report statement, but to be evaluated during synthesis...
My problem is with regard to design analysis, changes to the code, e.g. switching to generics instead of attributes, are undesired.
At the moment Xilinx XST 14.4 is used for synthesis, but I'm open to alternatives.
I'm asking since XST does report the attribute "Detected unknown constraint/property custom_attr", but unfortunately not its value.