UCInterfaceDocRTLSimpleIF < P1076

P1076 Web>Vhdl2019CollectedRequirements>InterfaceAndBundleEnhancements>UCInterfaceDocRTLSimpleIF (2016-01-21, BrentHahoe) (raw view)EditAttach

---+ 3.2. RTL Design, Subprogram Usage, and Hardware Creation

---++ 3.2.3. Simple Interfaces

A simple interface packages subprograms with bundles. A block (such as B1) calls a subprogram to create the interface behavior. Hence the interface behavior is hidden from B1. Note that since B1 calls the subprogram, the actual hardware will be created in block B1. The hardware created by the subprogram call is shown with dotted lines below to indicate that most likely it does not create any hierarchical boundaries.

<img width="520" alt="" src="%ATTACHURLPATH%/IFDocRTLSimpleInterfaces.png" height="180" />

Bus behavior is a sequence of actions. A sequence of actions implies multiple clocks. If a subprogram were to implement a sequence of actions, it would require multiple waits containing clock. This is a coding style that IEEE 1076.6-2004 calls an implicit statemachine. This coding style will work for some simple interfaces, however, it could get challenging to implement a statemachine with many independent cycles. Even straightforward things like a UART receiver can be difficult.

This methodology seems to work well for testbenches and system level design, however, it would only be usable for very simple RTL designs.

---++ 3.2.4. Concurrency in Interfaces

Hardware creation requires a concurrent region. Other languages suggest that hardware creation can be done in the interface as shown below.

<img width="520" alt="" src="%ATTACHURLPATH%/IFDocRTLHardwareInterfaceTop.png" height="180" />

If an interface construct is to create hardware, it would have to have a concurrent region. If it does, would it be a primary unit? Would it have a secondary unit?

An alternative to an interface containing a concurrent region is to use a separate entity/architecture pair to implement the concurrent portion of the interface. The interface entity would have an interface to each connected block (B1 and B2 above). In this approach, the main function subprograms in each interface would be to hand off data values to the interface entity. This could be by a simplified protocol. While it may be possible to implement the simple hardware handshaking elements in the interface, there may also be some benefit from having a library of handshaking components for this purpose. Using components allows different handshaking elements to be interchanged using configurations. For example at the system level view there may be only one clock and handshaking without registers can be accomplished. As the system evolves, the block that implements a function may have a different clock from the interface and a more sophisticated component can be selected. Would the handshaking components be instantiated in the block or the interface? Does it matter?

Another alternate view is for the interface hardware to be created as a subblock of B1 and B2 as shown below.

<img width="520" alt="" src="%ATTACHURLPATH%/IFDocRTLHardwareInSubblockTop.png" height="180" />

In this case, the SB1 is a subblock of B1 and is implemented as an entity/architecture. The required features of the interface between B1 and B2 is similar to a bundle. By having a standardized interface between B1 and SB1 and abstracting the connection as an interface/bundle, multiple different types of interfaces can be swapped in and out.

---++ 3.2.5. Limitations

For RTL design, bundles seem to offer a large amount of value. It is not clear how much value an interface methodology/feature would bring. In order to be able to interchange different blocks (USB, Firewire, ethernet) the information provided to each interface must be identical. This means the interface cannot be externally configurable. If the interfaces are externally configurable, the information exchanged is no longer the same and interchanging blocks is no longer a simple exchange one for the other.

Attachments

I	Attachment	Action	Size	Date	Who
png	IFDocRTLHardwareInSubblockTop.png	manage	15.6 K	2015-07-21 - 15:01	BrentHahoe
png	IFDocRTLHardwareInterfaceTop.png	manage	13.9 K	2015-07-21 - 14:58	BrentHahoe
png	IFDocRTLSimpleInterfaces.png	manage	13.9 K	2015-07-21 - 14:56	BrentHahoe

Topic revision: r4 - 2016-01-21 - 11:46:05 - BrentHahoe

P1076