The Verilog program here is an implemenation of this monitor. Essentially, it checks for a collection of many small PCI protocol properties.
|
|
The monitor observes the outputs of all PCI agents and decides whether
the PCI protocol rules have been upheld so far. If the correct
output is true, the corresponding rule has not been broken so far; if it is
false, the rule has been broken some time in the past.
The Verilog program here is an implemenation of this monitor. Essentially, it checks for a collection of many small PCI protocol properties. |
Only a subset of the PCI signals are observed with this monitor. The following is a list of PCI bus signals needed for this monitor with the left-hand column indicating the PCI 2.2 name for the signal, and the right-hand column listing the corresponding variable name (and an inversion when needed, indicated by !) in this Verilog monitor module.
GNT#, REQ#, and IDSEL are not bus signals but are point-to-point signals. The naming convention for these signals in the monitor code is as follows. For Agent i, gnt_i, req_i and idsel_i.
| PCI 2.2 Signal | PciMonitor() Signal |
|---|---|
| AD[31::00] | [31:0] ad |
| C/BE[3::0]# | [3:0] !cbe |
| FRAME# | !frame |
| TRDY# | !trdy |
| IRDY# | !irdy |
| STOP# | !stop |
| DEVSEL# | !devsel |
| IDSEL (for each agent) | idsel_i |
| REQ# (for each agent) | !req_i |
| GNT# (for each agent) | !gnt_i |
| CLK | clk |
There are also signals which are not stricly part of the bus but are still needed for the monitor. These are the driver signals for an agent driving the bus. The naming convention is as follows:
signalname_e_agentnumber for enable signals
signalname_o_agentnumber for output signals
When, for example, frame_e_1 is true, the monitor interprets this as Agent 1
driving the frame bus signal.
If frame_e_1 and frame_o_1 are both true, Agent 1 is driving the
frame bus asserted.
If frame_e_1 is true and frame_o_1 is false, Agent 1 is
driving the frame bus deasserted.
(Thus, again, an inverter may be needed for such signals as frame_o_1 to
connect the monitor and a PCI implementation.)
And finally, if frame_e_1 is false, Agent 1 is not driving the frame bus at
all.
Following are the enable and output signals needed for the monitor.
For Agent i,
| The Enables | The Output Value Signal |
|---|---|
| frame_e_i | frame_o_i |
| trdy_e_i | trdy_o_i |
| irdy_e_i | irdy_o_i |
| stop_e_i | stop_o_i |
| devsel_e_i | devsel_o_i |
| ad_e_i | |
| cbe_e_i |
For each agent on the PCI bus, the above signals must be provided as inputs to the monitor.
Thus, to summarize, the monitor requires all the signals in the first table, and for each agent on the PCI bus, all the signals in the second table and GNT#, REQ#, and IDESEL, as inputs.
For each PCI rule, for each agent, there is an associated correct signal.
The naming convention for the correct signals are as follows.
For rule j, for agent i, the associated correct variable is correcti_j.
The boolean value of correcti_j tells you whether the rule has been broken or not by agent i. Thus, for example if correct3_2 becomes false, we immedicately know that agent 3 was responsible for breaking the protocol. One of the appeal of our style of specification is that for all rules, there is no ambiguity in which agent to blame when a protocol is broken.
(Note, there is an exception to this naming convention. For rules correcti_0, correcti_1, and correcti_2, the responsbility lies with the arbiter and *not* agent i.)
If correcti_j is false, this indicates that agent i has broken rule j sometime in the past.
If correcti_j is true, this indicates that agent i has upheld rule j until now.