Question

**Verilog**

What is an instantiation template and what is it used for?

What is and what does a behavior wrapper file do?

With this said how do a netlist, behavior wrapper file, and Instantiation syntax help support the HDL simulation?

Answer 1

The act of creating a new definition of a function, class, or member of a class from a template declaration and one or more template arguments is called template instantiation. The definition created from a template instantiation to handle a specific set of template arguments is called a specialization.

emplate instantiation has two forms: explicit instantiation and implicit instantiation.

Explicit instantiation (C++ only)
Implicit instantiation (C++ only)

Explicit instantiation declaration
The explicit instantiation declarations feature is introduced in the C++11 standard. With this feature, you can suppress the implicit instantiation of a template specialization or its members. The extern keyword is used to indicate explicit instantiation declaration. The usage of extern here is different from that of a storage class specifier.
The following example demonstrates this concept:

//sample1.h:
template
union A{
T func();
};
extern template union A;

template
T A::func(void){
return val;
}

//sampleA.C"
#include "sample1.h"

template union A;

//sampleB.C:
#include "sample1.h"

int main(void){
return A().func();
}Copy
sampleB.C uses the explicit instantiation definition of A().func()in sampleA.C.

If an explicit instantiation declaration of a function or class is declared, but there is no corresponding explicit instantiation definition anywhere in the program, the compiler issues an error message. See the following example:

// sample2.C
template
struct A{
virtual T func();
virtual T bar();
}

extern template int A::func();

template
T A::func(void){
return val;
}

template
T A::bar(void){
return val;
}

int main(void){
return A().bar();
}Copy
When you use explicit instantiation declaration, pay attention to the following restrictions:
You can name a static class member in an explicit instantiation declaration, but you cannot name a static function because a static function cannot be accessed by name in other translation units.
The explicit instantiation declaration of a class is not equivalent to the explicit instantiation declaration of each of its members
Explicit instantiation definition
An explicit instantiation definition is an instantiation of a template specialization or its members.
Here is an example of explicit instantiation definition:
template class Array { void mf(); };
template class Array; /* explicit instantiation definition */
template void Array::mf(); /* explicit instantiation definition */

template void sort(Array& v) { }
template void sort(Array&); /* explicit instantiation definition */

namespace N {
template void f(T&) { }
}

template void N::f(int&);
// The explicit instantiation definition is in namespace N.

int* p = 0;
template T g(T = &p);
template char g(char); /* explicit instantiation definition */

template class X {
private:
T v(T arg) { return arg; };
};

template int X::v(int); /* explicit instantiation definition */

template T g(T val) { return val;}
template void Array::mf() { }
Copy
An explicit instantiation definition of a template is in the same namespace where you define the template.

Access checking rules do not apply to the arguments in the explicit instantiation definitions. Template arguments in an explicit instantiation definition can be private types or objects. In this example, you can use the explicit instantiation definition template int X::v(int) even though the member function is declared to be private.

The compiler does not use default arguments when you explicitly instantiate a template. In this example, you can use the explicit instantiation definition template char g(char) even though the default argument is an address of the type int.

Implicit instantiation (C++ only)

Unless a template specialization has been explicitly instantiated or explicitly specialized, the compiler will generate a specialization for the template only when it needs the definition. This is called implicit instantiation.
f the compiler must instantiate a class template specialization and the template is declared, you must also define the template.

For example, if you declare a pointer to a class, the definition of that class is not needed and the class will not be implicitly instantiated. The following example demonstrates when the compiler instantiates a template class:
template class X {
public:
X* p;
void f();
void g();
1};

X* q;
X r;
X* s;
r.f();
s->g();
Copy
The compiler requires the instantiation of the following classes and functions:
X when the object r is declared
X::f() at the member function call r.f()
X and X::g() at the class member access function call s->g()
Therefore, the functions X::f() and X::g() must be defined in order for the above example to compile. (The compiler will use the default constructor of class X when it creates object r.) The compiler does not require the instantiation of the following definitions:
class X when the pointer p is declared
X when the pointer q is declared
X when the pointer s is declared
The compiler will implicitly instantiate a class template specialization if it is involved in pointer conversion or pointer to member conversion. The following example demonstrates this:
template class B { };
template class D : public B { };

void g(D* p, D* q)
{
B* r = p;
delete q;
}Copy
The assignment B* r = p converts p of type D* to a type of B*; the compiler must instantiate D. The compiler must instantiate D when it tries to delete q.
If the compiler implicitly instantiates a class template that contains static members, those static members are not implicitly instantiated. The compiler will instantiate a static member only when the compiler needs the static member's definition. Every instantiated class template specialization has its own copy of static members. The following example demonstrates this:
template class X {
public:
static T v;
};

template T X::v = 0;

X a;
X b;
X c;Copy
Object a has a static member variable v of type char*. Object b has a static variable v of type float. Objects b and c share the single static data member v.
An implicitly instantiated template is in the same namespace where you defined the template.

If a function template or a member function template specialization is involved with overload resolution, the compiler implicitly instantiates a declaration of the specialization.

2ANS) The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. As a result, developers can get up and running with a Gradle project quickly without having to follow manual installation processes saving your company time and money.

n a nutshell you gain the following benefits:

Standardizes a project on a given Gradle version, leading to more reliable and robust builds.

Provisioning a new Gradle version to different users and execution environment (e.g. IDEs or Continuous Integration servers) is as simple as changing the Wrapper definition.

So how does it work? For a user there are typically three different workflows:

You set up a new Gradle project and want to add the Wrapper to it.

You want to run a project with the Wrapper that already provides it.

You want to upgrade the Wrapper to a new version of Gradle.

The following sections explain each of these use cases in more detail.

Generating the Wrapper files requires an installed version of the Gradle runtime on your machine as described in Installation. Thankfully, generating the initial Wrapper files is a one-time process.

Every vanilla Gradle build comes with a built-in task called wrapper. You’ll be able to find the task listed under the group "Build Setup tasks" when listing the tasks. Executing the wrapper task generates the necessary Wrapper files in the project directory.

Running the Wrapper task
$ gradle wrapper
> Task :wrapper

BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed

The generated Wrapper properties file, gradle/wrapper/gradle-wrapper.properties, stores the information about the Gradle distribution.

The server hosting the Gradle distribution.

The type of Gradle distribution. By default that’s the -bin distribution containing only the runtime but no sample code and documentation.

The Gradle version used for executing the build. By default the wrapper task picks the exact same Gradle version that was used to generate the Wrapper files.

gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-5.4.1-bin.zip
All of those aspects are configurable at the time of generating the Wrapper files with the help of the following command line options.

--gradle-version
The Gradle version used for downloading and executing the Wrapper.

--distribution-type
The Gradle distribution type used for the Wrapper. Available options are bin and all. The default value is bin.

--gradle-distribution-url
The full URL pointing to Gradle distribution ZIP file. Using this option makes --gradle-version and --distribution-type obsolete as the URL already contains this information. This option is extremely valuable if you want to host the Gradle distribution inside your company’s network.

--gradle-distribution-sha256-sum
The SHA256 hash sum used for verifying the downloaded Gradle distribution.

Let’s assume the following use case to illustrate the use of the command line options. You would like to generate the Wrapper with version 5.4.1 and use the -all distribution to enable your IDE to enable code-completion and being able to navigate to the Gradle source code. Those requirements are captured by the following command line execution:

Providing options to Wrapper task
$ gradle wrapper --gradle-version 5.4.1 --distribution-type all
> Task :wrapper

BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed
As a result you can find the desired information in the Wrapper properties file.

Example: The generated distribution URL
distributionUrl=https\://services.gradle.org/distributions/gradle-5.4.1-all.zip
Let’s have a look at the following project layout to illustrate the expected Wrapper files:

.
├── build.gradle
├── settings.gradle
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat
A Gradle project typically provides a build.gradle and a settings.gradle file. The Wrapper files live alongside in the gradle directory and the root directory of the project. The following list explains their purpose.

gradle-wrapper.jar
The Wrapper JAR file containing code for downloading the Gradle distribution.

gradle-wrapper.properties
A properties file responsible for configuring the Wrapper runtime behavior e.g. the Gradle version compatible with this version.

gradlew, gradlew.bat
A shell script and a Windows batch script for executing the build with the Wrapper.

You can go ahead and execute the build with the Wrapper without having to install the Gradle runtime. If the project you are working on does not contain those Wrapper files then you’ll need to generate them.

Using the Gradle Wrapper
It is recommended to always execute a build with the Wrapper to ensure a reliable, controlled and standardized execution of the build. Using the Wrapper looks almost exactly like running the build with a Gradle installation. Depending on the operating system you either run gradlew or gradlew.bat instead of the gradle command. The following console output demonstrate the use of the Wrapper on a Windows machine for a Java-based project.