I am confused about "internal" and "external" in systemRDL register component property usage. from SystemRDL 2.0 reference manual, it says:
Registers can be instantiated in three forms.
— **internal** implies all register logic is created **by the SystemRDL compiler** for the instantiation (the default form).
— **external** signifies the register/memory is implemented by the designer and the interface is inferred from instantiation.
how to understand them? I understand this property will impact RTL module generation from an RD file
my confused point is "systemRDL compiler" statement in "internal" part description. if we say systemRDL compiler is to interpret rd file and put all related properties into a plain database, user can define customized generator base on these plain database, so seems like these "internal" and "external" keyword will be only used when we write generator for RTL register module part, is my understanding correct?
any guidance to define "internal" and "external" for register in RD file?
Thanks
Your understanding is correct. The internal and internal component modifiers are there to influence the output of the RTL generator.
By default, registers, regfiles, and fields are internal, so they would be included in the output of a RTL generator.
If you mark a component as external, you are signalling to the compiler that you want to define the implementation of the register/field/etc yourself. The compiler would then provide some form of interface for you to implement the component externally, but still have it be part of the address space of the parent being exported to RTL.
Worth mentioning that addrmap components are implicitly external by default since they are intended to describe a physical boundary between RTL components.
Related
My component diagram is mostly components, ports, and interfaces. The interfaces have operations and attributes. They do not capture any class based OO at the moment. What's the right way of doing that?
My options as I see them is either:
Add the class constructors to the component interfaces, and let the type carry remaining details like class operations.
Duplicate class interfaces into the component interfaces, e.g. having the class object as first parameter.
From the two the former is least work obviously. But perhaps there is a better way I've overlooked.
Notation
The easiest way to do this is to capture the interfaces in a separate class diagram, with only «interface» classifiers. The advantage is that these classifiers give a (hopefully short) name to an interface, and describe the attributes and operations that are needed, with all required details, including constructors (keep in mind that in UML constructors should be preceded with «Create»)
You can then show for the components in your component diagram the interfaces provided (lollipop) and required (socket) just referring to the named interfaces, without cluttering the diagram with lots of redundant interface specifications.
Design
When you refer to duplicating class interfaces at the component level, I understand that you mean to add attributes (parts?) and operations to the component.
Of course, components implementing the same implicit interface could in principle be interchangeable. However, this approach does not allow to have a clear understanding of the dependencies, and in particular use dependencies, that are practical to decouple components. In other words, your components would be hard-wired.
Adding class constructors at the component level seems cleaner in this regard, since your class constructor would reuse classes that are defined somewhere else. But if you're going into that direction, you could go one step further and consider using a factory class:
The factory class constructs objects of a given class or a given interface
Your component would be initialized or configured with such factory provided from outside. The factories could be interchanged to construct different kind of objects that meet the requirements.
*. If you go that way, I come back to the notational topic: the lolipo/socket notation would then allow to highlight better the decoupling that this design would offer.
I didn't understand the options you describe. Maybe a diagram would help. Here is how I would do it:
The specification component has two ports and is indirectly instantiated. For the realization component I select two classes that are realizing the component. Class1 has an operation that uses the service defined by interface I1. Class2 implements the service promised by I2. Since port p2 has a multiplicity of 16, the part typed by Class2 also has at least this multiplicity. The constructors (with the «create» stereotype), don't have parameters, so that the component can be constructed without any additional logic.
If you need additional logic, you can use directly instantiated components. They have constructors that could call the parametrized constructors of realizing classes and also create the wiring.
I am reading Swift Evolution proposal 244 (Opaque Result Types) and don't understand what the following means:
"... expanding the surface area of the library"
The underlying concrete type is hidden, and can even change from one
version of the library to the next without breaking those clients,
because the underlying type identity is never exposed to clients.
Unlike an existential, though, clients still have access to the type
identity. This allows the library to provide a
potentially-more-efficient design that leverages Swift's type system,
without expanding the surface area of the library or making
implementors of the library's protocols rely on exposing verbose
implementation types.
Source: https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md#introduction
The "surface area" of a library is basically the list of things that are exposed to the user. This quote is saying that this proposal allows substantial internal changes to a library without it having a large effect on the users of the library.
I do not understand the meaning of class in Modelica context.
From the Modelica Tutorial, version 1.4 on https://modelica.org/publications.html:
In Modelica, the basic structuring element is a class. There are seven restricted classes with specific names, such as model...". Anyone have a simpler explanation? I am very new to Modelica.
If you open the Modelica library in a tool like Dymola or OpenModelica, everything you see in the package or library browser are classes.
As soon as you use one of these classes, e.g. with drag and drop in the diagram layer, you create a new component of this class type.
The instantiated component is not a copy of the class, but a reference to it. Therefore, if you update the class definition, you also update the behavior of all components that are instances of this class.
There are several kinds of classes available. The most general class is actually called class, but it’s not used very often.
It has no restrictions, so it can contain everything that is possible with Modelica: equations, algorithms, public and protected components, etc.
There are more specific class types, which restrict the usage. This helps to make correct use of a class. A function or a record for example cannot be simulated.
The most important restricted class types are:
package: used to group other classes
model: typically used for components with physical connectors and for examples which are simulated
block: used for components with causal connectors (only inputs and outputs, so everything you have in Modelica.Blocks)
function: used for function calls, comparable to other programming languages
record: often used to contain data sets for other components (which allows to quickly change a complete data set)
connector: used to define the interface variables which are needed to connect different components of a domain (e.g. v and i in the electric domain)
type: typically used to define physical quantities like mass, length or time with their unit (e.g. all units in the package Modelica.Units)
More information can be found in chapter 4.6 of the Modelica specification: Specialized Classes
This is just a collection of links to prove that there is an ongoing discussion on class within the Modelica Association:
class still a valid Modelica class type to use?
model no longer identical to class
What is the usage recommendation for class?
Restricted class for parameter record with initial equation
I am a bit confused as to if it is legal, from a standards stand point, to read a parameter from an interface.
Like so
interface foo_if #(parameter BAR=5)();
...
logic [BAR-1:0] data;
modport slave(input data, ...);
endinterface
module foobar(foo_if.slave s);
...
logic [s.BAR-1:0] bar;
logic [$bits(s.data)-1:0] m_data;
...
endmodule
I have a problem where a major synthesis tool vendor can not even handle this. And they explicitly tell you in the help message that it is not allowed to use $bits() with a interface member.
However a simulation tool from another vendor handles this perfectly as does another synthesis tool I have.
However in SystemVerilog for Design by S. Sutherland et al. it is stated:
Because the design hierarchy may not be yet fully resolved during
elaboration, it is illegal to assign a parameter, specparam, or
localparam constants a value that is derived from elsewhere in the
design hierarchy
However if I am not allowed to use parameters from interfaces, it really cripples the usefulness of interfaces.
The SystemVerilog 1800-2012 Standard on the other hand states:
25.10 Access to interface objects
Access to objects declared in an interface shall be available by
hierarchical name reference, regardless of whether the interface is
also accessed through a port connection or through a virtual
interface, and regardless of the existence of any declared modports in
that interface. A modport may be used to restrict access to objects
declared in an interface that are referenced through a port connection
or virtual interface by explicitly listing the accessible objects in
the modport. However, objects that are not permissible to be listed in
a modport shall remain accessible.
The issue here is not about access, but what is allowed in places that require constant expressions. The LRM is not very clear that interface port references are not considered hierarchical references. But the tool is not complaining about s.BAR, it is complaining about s.data, which is a variable, not a parameter. Normally, you can't use variables in constant expressions, but the LRM 20.6.2 says
The $bits function can be used as an elaboration time constant when
used on fixed-size data types; hence, it can be used in the
declaration of other data types, variables, or nets.
So $bits(s.data) should have been treated like a parameter expression.
BTW, you should be using the latest freely available IEEE 1800-2012 LRM.
I use CodeSmith for the PLINQO templates, to build my DAL from my DB objects; it works great!
I believe that's the primary use of code generator apps, but I'm curious... what other code would you consider using a code generator for? Do you have any CodeSmith templates that you use frequently (if so, what does it do)?
I haven't used CodeSmith, but I've done a fair bit of code generation. Noteably I wrote most of a configuration management (CM) system for a WiMAX system, where the CM code was generated for 3 different platforms. The only difference was the CM model for each platform.
The model was in a custom Domain Specific Language (DSL) that we built had a parser for. The language was a basic container/element style where containers could nest and have an identifier, and elements were of pre-defined types. Documentation was an attribute of elements and containers. You could add Lua snippets to the element and container definitions to do semantic validation (e.g., the value is in the correct range, if it's an IP address is it in a CIDR range defined elsewhere, etc.).
The parser generated a syntax tree that we then pushed at templates. The template language was a partial C implementation of StringTemplate. We used it to generate:
A model specific C API that applications could call into to get configuration values,
The collected Lua code for validating the model and providing useful error messages,
Two "backends" for the API that would manage values in memory (for temporary manipulation of a model), and in a database system (for sharing amongst processes),
Configuration file parser and writer,
HTML documentation, and
Command Line Interface (CLI) implementation for interactive viewing and changing of a configuration.
In retrospect, I should have simply used Lua directly as the DSL. It would have been more verbose, but having the parser already there and lots of Lua templating choices available to me would have saved a lot of development effort.
For things that have a repetivie structure and well defined rules about what those things need to do, code generation can be a wonderful thing.