Hardware Reference
In-Depth Information
Note the difference between this example and Example 2.7 . In Example 2.7
the property p_req_granted is written in the scope of a clocking block, and to
instantiate it assertion a1 needs to specify the name of the clocking block cblk
as part of the hierarchical property name. In this example property p_req_granted
does not belong to the scope of the clocking block, and its name is directly visible by
assertion a1 . In Example 2.7 the clocking event of the clocking block is inferred for
property p_req_granted , and assertion a1 inherits this clock from the property .
Assertion a2 there has to specify its clock explicitly. In the current example the
clocking event of the default clocking is inferred for all assertions in the module,
because no assertion here has an explicitly specified clock.
t
2.4
Interfaces
This section contains an introduction to interfaces —design elements aimed to
encapsulate the communication between modules. The reader can find the details
in [ 61 ] and the LRM. The interface groups signals together, and it may also contain
assertions and communication logic. Unlike the modules, interfaces may be passed
via ports as a group.
The contents of an interface are not limited to signals. In fact, it may contain
most entities allowed in modules such as
￿ Data types and variables
￿ Clocking blocks, functions and tasks
￿ Initial, always, and final procedures to define additional behavior
￿ Sequences, properties, and assertions
In the simplest case the interface is just a named bundle of signals, as shown in
Example 2.9 .
Search WWH ::




Custom Search