| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Bus implementation and descriptions how to use it are introduced.
10.1 Bus Implementation 10.2 Using Bus
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Bus is consisting of packets on a bus and input/output ports for path of packets.
bus_packet_base class.
This class is an abstract class, and it does not provide any states
other than address and data. State query function is supported with
pure virtual functions or pre-defined virtual functions. To implement
a packet with real states, a derived class with additional state
should be provided. By defining pure virtual functions only, a object
of a derived class can be instantiated. However, to reduce the
calling cost in the execution time, other virtual functions should be
re-defined. See section 5.2 bus_packet_base class.
bus_packet class is a concrete derived class of
bus_packet_base class, which has concrete functions provided in
bus_packet_base class only. traditional bus transaction can be
implemented with bus_packet class. See section 5.3 bus_packet class.
port class and bus_packet_base class,
but it is a cumbersome job to access them directly. It is provided to
conceal such complexity. Accessing bus with bus_port_base
class functions, its implementation can be independent from
port class and bus_packet_base class.
bus_port_base only provides an interface for abstract
bus_packet_base class, and functions such as for packet
generation are not provided. bus_port_base class is a concrete
derived class of bus_port_base class which is an interface of
bus_packet, the sending packet function is added.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
bus_packet_base class supports five basis packet types:
request, grant, ack, nack and data. A bus transaction is done with
transferring some of them between a sender and a receiver.
10.2.1 Single Bus Master 10.2.2 Multiple Bus Master 10.2.3 Split Transaction
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An example of single bus master is shown. The packet reference
is done in clock_in phase, while the packet sending or
bus release is done in clock_out phase.
The requester sends read_request packet.
The responder receives read_request packet.
The responder sends read_ack packet after 1 clock before the
clock when data becomes available.
The requester receives read_ack packet. The requester must be
ready to receive data after 1 clock.
The responder sends read_data packet.
The requester receives read_data packet.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus. Requester can initiate next transfer directly if required.
The requester sends write_request packet.
The responder receives write_request packet.
The responder sends write_ack packet after 2 clock before the
clock when it becomes ready to receive data.
The requester receives write_ack packet. The requester will be
able to send data after 1 clock.
The requester sends write_data packet.
The responder receives write_data packet.
The requester terminates the transaction. The reason why the termination is not processed by the responder but done by the requester is that the requester can start next transaction without releasing the bus. When data transfer is done, the requester removes the packet on the bus. Requester can initiate next transfer directly if required.
The requester sends read_request packet.
The responder receives read_request packet.
The responder sends read_ack packet after 1 clock before the
clock when data becomes available.
The requester receives read_ack packet. The requester must be
ready to receive data after 1 clock.
The responder sends the first read_data packet.
The requester receives the first read_data packet.
The above-mentioned processing is repeated the times of data size.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus. Requester can initiate next transfer directly if required.
The requester sends write_request packet.
The responder receives write_request packet.
The responder sends write_ack packet after 2 clock before the
clock when it becomes ready to receive data.
The requester receives write_ack packet. The requester will be
able to send data after 1 clock.
The requester sends the first write_data packet.
The responder receives the first write_data packet.
The above-mentioned processing is repeated the times of data size.
The requester terminates the transaction. The reason why the termination is not processed by the responder but done by the requester is that the requester can start next transaction without releasing the bus. When data transfer is done, the requester removes the packet on the bus. Requester can initiate next transfer directly if required.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If there are multiple bus masters, one of them must be an owner before
transfer. After the transaction, the bus must be released. The
exclusive operation of the bus is implemented with port_base
class. See section Port Ownership.
The followings are examples of a single read transaction and a single write transaction.
The requester requests an ownership.
The requester checks whether it becomes the owner or not. If failed, it retries after the next clock.
The requester sends read_request packet.
The responder receives read_request packet.
The responder sends read_ack packet after 1 clock before the
clock when data becomes available.
The requester receives read_ack packet. The requester must be
ready to receive data after 1 clock.
The responder sends read_data packet.
The requester receives read_data packet.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus and releases the ownership. Requester can initiate next transfer without releasing the ownership directly if required.
The requester requests an ownership.
The requester checks whether it becomes the owner or not. If failed, it retries after the next clock.
The requester sends write_request packet.
The responder receives write_request packet.
The responder sends write_ack packet after 2 clock before the
clock when it becomes ready to receive data.
The requester receives write_ack packet. The requester will be
able to send data after 1 clock.
The requester sends write_data packet.
The responder receives write_data packet.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus and releases the ownership. Requester can initiate next transfer without releasing the ownership directly if required.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When split transaction is executed, releasing the bus during the
transaction is added with ownership management. Transaction
identifier supported by port, which adds an unique identifier
to every transaction is used.
The requester takes the bus ownership, then transfer requesting packet storing its transaction ID. The responder stores the transaction ID and returns grant packet which requests temporal waiting. The requester removes the packet on the bus when grant packet is received, and releases the ownership. The responder returns the ack with the stored transaction ID after requiring interval. The requester receives the ack checking its ID is matched to the previous transaction ID. The succeeding processes are similar to that of multiple-master transaction.
The followings are examples of a single read transaction and a single write transaction.
The requester requests an ownership.
The requester checks whether it becomes the owner or not. If failed, it retries after the next clock. If succeeded, it remembers the transaction ID.
The requester sends read_request packet.
The responder receives read_request packet and remembers the
transaction ID.
The responder sends read_grant, which means encouraging to
release the ownership.
The requester receives read_grant packet.
the requester removes the packet on the bus and releases the ownership, and then waits resuming the transaction by the responder.
The responder requests an ownership after 2 clock before the clock when data becomes available.
The responder checks whether it becomes the owner or not. If failed, it retries after the next clock.
The responder restores the transaction ID and sends read_ack
packet.
The requester checks the transaction ID and receives read_ack
packet. The requester must be ready to receive data after 1 clock.
The responder sends read_data packet.
The requester receives read_data packet.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus and releases the ownership. Requester can initiate next transfer without releasing the ownership directly if required.
The requester requests an ownership.
The requester checks whether it becomes the owner or not. If failed, it retries after the next clock. If succeeded, it remembers the transaction ID.
The requester sends write_request packet.
The responder receives write_request packet and remembers the
transaction ID.
The responder sends read_grant, which means encouraging to
release the ownership.
The requester receives read_grant packet.
the requester removes the packet on the bus and releases the ownership, and then waits resuming the transaction by the responder.
The responder requests an ownership after 3 clock before the clock when data becomes available.
The responder checks whether it becomes the owner or not. If failed, it retries after the next clock.
The responder restores the transaction ID and sends write_ack
packet.
The requester checks the transaction ID and receives write_ack
packet. The requester will be able to send data after 1 clock.
The requester sends write_data packet.
The responder receives write_data packet.
The requester terminates the transaction. When data transfer is done, the requester removes the packet on the bus and releases the ownership. Requester can initiate next transfer without releasing the ownership directly if required.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |