1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
$Id: protocol.txt,v 1.2 2009-03-02 15:22:20 potyra Exp $
# Copyright (C) 2002-2009 FAUmachine Team <info@faumachine.org>.
# This program is free software. You can redistribute it and/or modify it
# under the terms of the GNU General Public License, either version 2 of
# the License, or (at your option) any later version. See COPYING.
expect - node - tracer communication protocol
*********************************************
structure of protocol packet:
=============================
-------------------------------------------------------------
| 2 byte |1b. | variable number of bytes |'\0'| |
| | | | | |
-------------------------------------------------------------
size type signal name val
* size (2 bytes): length of complete packet in bytes
* type (1 byte): type of packet, possible types are defined in expect/expect.h
EXPECT_TYPE_NONE: ???
EXPECT_TYPE_CONTINUE:
just tells the tracer to let stopped CPU#-process continue.
no more data.
EXPECT_TYPE_EVENT:
really an event, event (signal) name and value follow.
* signal name (variable number of bytes with terminating 0-byte (c-string)):
possible signal names and values are listed below.
* val (variable number of bytes):
value of the signal (depends on which signal it is)
signal names
============
Unless otherwise noted signals are generate by expect/GUI and sent to
tracer/component via node.
??? signal names should be defined in a single place (currently it is in 2
places, expect/simulator.c, frontend/expint.c in independent non-compatible
datastructures)
??? only first part of name should be used as index into signal-table to find
corresponding function, rest of name should be given to function
(change expect_event(), signal-functions)
* cpu
cpu/<num>/<reg>/<bit>
cpu/%d/%s/%d
<num> a valid CPU ID (0 for mono-processor, between 0 and (number of
processors - 1) for multi-processor)
<reg> a valid (Intel architecture) register name, e.g. eax, ebx, ecx,
<bit> a valid bit for the chosen register
Value: on/off/pulse
Action: will flip <bit> in <reg> of cpu<num>
* ctrl
ctrl/<type>
ctrl/%s
<type> is one of poweron, power_supply, reset (defined in
expect/simulator.c and frontend/expint.c)
Value: on/off
Action: will power machine on/off,
turn power_supply on/off,
reset machine
* eth
eth/<num>/<type>/<percent>
eth/%d/%s/%d
<num> valid interface number (usually 0 for one installed ethernet
interface)
<type> is one of send, receive, scramble_send, scramble_receive
<percent> percentage of packets affected
Value: on/off
Action: as long as signal is on, will
not send <percent> packets,
not receive <percent> packets,
send scrambled packets <percent> of the time,
receive scrambled packets <percent> of the time.
??? in setup/components.c eth is called ethcard ...
* hd
hd/<device>/<start>/<range>
hd/%c/%d/%d
<device> character identifying available device (e.g. a if hda is present)
<start> first byte of defective range, or all (in this case, <range> will be
ignored and access to all bytes will produce errors)
<range> number of defective bytes, or all (in this case, <range> will be all
bytes following <start>)
Value: on/off
Action: as long as signal is on, will produce errors when defective bytes
are accessed.
??? in setup/components.c hd is called idecdrom/idedisk ...
* keyboard
keyboard/key
Value: a single character
Action: equivalent to pressing this key on the virtual keyboard
* memory
memory/<byte>/<bit>
memory/%d/%d
<byte> valid byte in memory (word aligned)
<bit> valid bit in a word
Value: on/off/pulse
Action: will flip <bit> in memory word started by <byte>
if value was pulse, will flip bit once only.
if value was on, will keep bit in the state it has after flip until
signal is turned off (basically a stuck at)
* mouse
mouse/xtics
mouse/ytics
Value: integer delta to current mouse position
Action: equivalent to moving the virtual mouse by delta pixels
* ser
ser/pattern
ser/match (ser -> expect/GUI)
ser/send
Value:
pattern: abstract datatype describing pattern
match: boolean value (true if a pattern was matched, false if not)
send: byte to send out over serial interface
Action:
pattern: ser will watch for the given pattern in data sent/received
match: ser will notify expect that a pattern was found.
send: ser will send the given byte out over the serial interface.
??? do we want to distinguish between sending and receiving when watching for
patterns?
??? can we watch for several different patterns at a time?
??? do we need to know, which pattern was matched, if we are waiting for
several?
??? do we need to be able to specify a timeout?
* video
video/pattern
video/match (gfx -> exp)
Value:
pattern: abstract datatype describing pattern
match: boolean value (true if a pattern was matched, false if not)
Action:
pattern: gfx will watch for the given pattern in data displayed on
screen
match: gfx will notify expect that a pattern was found.
??? can we watch for several different patterns at a time?
??? do we need to know, which pattern was matched, if we are waiting for
several?
??? do we need to be able to specify a timeout?
communication patterns or who sends what where
==============================================
-r-> read
-g-> generate
-s-> signal
system.vhdl (system description) --r--> setup --g--> node#-directory
expect.vhdl (action description) --r--> expect
expect ([1]) --s--> node (expect_handle_event()) --s--> (expect_recv()) tracer
node/GUI ([2]) (expect_send()) --s--> (expect_recv()) tracer
[1]: expect uses the functions defined in components[] and subtables to send
stuff to node
[2]: GUI uses a number of different functions which all eventually call
expect_send() to send stuff to tracer
|
