Method and System for Modeling a Bus for a System Design Incorporating One or More Programmable Processors

• US 20080235415A1
• Filed: 01/22/2008
• Published: 09/25/2008
• Est. Priority Date: 01/22/2007
• Status: Active Grant

• Current Assignee: Synopsys Incorporated
• Original Assignee: VaST Systems Technology Corp. (Synopsys Incorporated)
• Inventors: Torossian, James R., CLARK, Neville A.
• Granted Patent: US 8,644,305 B2
• Time in Patent Office: Days
• US Class Current: 710/105
• CPC Class Codes: G06F 2119/12 Timing analysis or timing optimisation
• CPC Class Codes: G06F 30/3312 Timing analysis

Abstract

Systems and methods for modeling a bus for a system design are provided. In an embodiment, the method operates by accepting a virtual bus model, wherein the model simulates behavior for a bus master and slave device, such that the model accurately simulates the timing and behavior of the transfer of data from master to slave, and, from slave to master devices. The method routes a transaction issued by the master device to the slave device. The transaction has storage for transaction data, or a pointer to transaction data, to be transferred through the transaction. The transaction data is transferred in one or more data payloads and the sender of data sets the length of data payloads to be returned. The data payloads are sent from the sender of data to the receiver of data and may contain one or more bus data beats. This method accurately models the bus timing and behavior of the delivery of one or more data beats as one data payload.

Claims

1. A method for processing data through a virtual bus structure model for system designs including one or more programmable processors, the method comprising:

indicating that a transaction is available for transfer through the virtual bus structure model;

setting a length of a transaction data to be transferred through the virtual bus structure model, wherein the transaction data comprises a specified number of data beats;

dividing the transaction data into one or more data payloads, wherein each data payload has a data payload length;

committing to a transfer of at least one data payload of the transaction data based on the specified number of data beats in the at least one data payload; and

routing the committed at least one data payload through the virtual bus structure model.

2. The method of claim 1, further comprising:

storing the time at which a request for routing of the committed at least one data payload is made; and

storing the time at which the request for routing of the data payload is accepted.

3. The method of claim 2, wherein said storing the time at which a request for routing of the committed at least one data payload is made comprises setting a variable indicating the time.

4. The method of claim 2, further comprising;

indicating that a subsequent data payload is available for transfer; and

storing the time at which the subsequent data payload is available for transfer.

5. The method of claim 1, further comprising issuing a status identifier for each data beat in the committed at least one data payload.

6. The method of claim 1, further comprising issuing a status identifier for the entire committed at least one at least one data payload.

7. The method of claim 1, wherein said setting the length of the data payload comprises setting the data payload length such that start and end bytes of the payload are either start and end bytes of the transaction, respectively, or are located at a beat-aligned boundary between the start and end bytes of the transaction.

8. The method of claim 1, wherein said setting the length of the data payload comprises setting the data payload length such that the data payload length corresponds to a number of data beats of data that are guaranteed to be delivered on contiguous clock cycles.

9. A method for processing data in a transaction through a virtual bus structure model for system designs including one or more programmable processors, the virtual bus structure model located between a sender of data and a receiver of data, wherein the sender of data is configured to write data through the transaction and the receiver of data is configured to read data through the transaction, the method comprising:

(a) determining a number of data beats to commit to supply from a sender of data to a receiver of data;

(b) marking a data channel as busy;

(c) indicating a simulated time at which the first of the committed data beats will be available from the sender of data;

(d) signaling the receiver of data that the number of data beats is available;

(e) determining a number of data payloads needed to transfer the number of data beats;

(f) determining the point in simulated time at which the last of the data beats will be accepted by the receiver of data; and

(g) signaling the sender of data the acceptance of a data payload by the receiver of data.

10. The method of claim 9, wherein said determining in step (a) is based on at least one of:

availability of the data;

availability of the data channel;

a current simulation time;

a transaction time, a total number of data beats, a size of the transaction data to be transferred, and a state of one or more pending transactions.

11. The method of claim 9, further comprising after step (a):

indicating an intention to supply the number of data beats either directly in the transaction or indirectly through another device.

12. The method of claim 9, further comprising after step (c):

storing the committed data beats.

13. The method of claim 12, wherein storing the committed data beats comprises moving the committed data beats into a buffer associated with the transaction.

14. The method of claim 12, wherein storing the committed data beats comprises creating an association between the transaction and data beats located in an existing buffer.

15. The method of claim 9, wherein said determining in step (f) is based on at least one of:

the simulated time of availability of the data payload, a current simulation time, a transaction time, a total number of data beats in the payload, and the ability to accept the data to be transferred.

16. A system for processing data in a transaction comprising:

a virtual bus structure model;

a data sender device model;

a data recipient device model;

an indication module configured to indicate that transaction data is available for transfer through the virtual bus structure model from the data sender device model to the data recipient device model;

a data payload module configured to set a length of a data payload to be transferred through the virtual bus structure model, wherein the data payload comprises a specified number of data beats, wherein the transaction data is divided into one or more data payloads, each data payload having a data payload length, and wherein the data payload module is configured to commit to a transfer of at least one data payload of the transaction data based on the specified number of data beats in the data payload; and

a routing module configured to route the at least one data payload from the data sender device model through the virtual bus structure model to the data recipient device model.

17. The system of claim 16, further comprising:

a storage medium configured to store a time at which a request for routing of the data payload is made by the data sender device model and a time at which the request for routing of the at least one data payload is accepted by the data recipient device model.

18. The system of claim 17, wherein the indication module is configured to indicate that a subsequent data payload is available for transfer.

19. The system of claim 17, wherein the storage medium is further configured to store a pointer to a buffer containing the subsequent data payload available for transfer in the transaction.

20. The system of claim 19, wherein the routing module is further configured to call a function requesting the stored pointer.

21. The system of claim 16, wherein the routing module is further configured to route an acknowledgement of the receipt of the at least one data payload by the data recipient device model back to the data sender device model.

22. The system of claim 16, wherein the data payload module is further configured to set the data payload length such that start and end bytes of the payload are either start and end bytes of the transaction data, respectively, or are located at a beat-aligned boundary between the start and end bytes of the transaction data.

23. The system of claim 16, wherein the data payload module is further configured to set the data payload length such that the data payload length corresponds to a number of data beats of data that are guaranteed to be delivered on contiguous clock cycles.

24. A computer program product comprising a computer usable medium having control logic recorded thereon for enabling a processor to model data flow through a virtual bus structure model for system designs including one or more programmable processors, said control logic comprising:

first computer readable program code means for enabling the processor to indicate that a transaction is available for transfer through the virtual bus structure model;

second computer readable program code means for enabling the processor to set a length of a data payload to be transferred through the virtual bus structure model, wherein the data payload comprises a specified number of data beats;

third computer readable program code means for enabling the processor to divide the transaction into one or more data payloads, each data payload having the data payload length;

fourth computer readable program code means for enabling the processor to commit to a transfer of at least one data payload of the transaction based on the specified number of data beats in the data payload; and

fifth computer readable program code means for enabling the processor to route the at least one data payload through the virtual bus structure model.

25. The computer program product of claim 24, further comprising:

sixth computer readable program code means for enabling the processor to store the time at which a request for routing of the at least one data payload is made;

seventh computer readable program code means for enabling the processor to queue the at least one data payload until a data recipient device model is ready to accept the at least one data payload; and

eighth computer readable program code means for enabling the processor to store the time at which the request for routing of the at least one data payload is accepted.

26. The computer program product of claim 25, further comprising ninth computer readable program code means for enabling the processor to indicate that a subsequent data payload is available for transfer.

27. The computer program product of claim 25, wherein the seventh computer readable program code means includes ninth computer readable program code means for enabling the processor to store a pointer to a buffer containing the data available for transfer in the transaction.

28. The computer program product of claim 27, wherein the fifth computer readable program code means includes computer readable program code means for enabling the processor to call a function requesting the stored pointer.

29. The computer program product of claim 24, wherein the second computer readable program code means includes computer readable program code means for enabling the processor to set the data payload length such that start and end bytes of the payload are either start and end bytes of the transaction data, respectively, or are located at a beat-aligned boundary between the start and end bytes of the transaction.

30. The computer program product of claim 24, wherein the second computer readable program code means includes computer readable program code means for enabling the processor to set the data payload length such that the data payload length corresponds to a number of data beats of data that are guaranteed to be delivered on contiguous clock cycles.