Network Addresses
Each network member needs an unique 16Bit address. A network member is not necessarily equal to some piece of hardware: A normal TRB2 board has two addresses: One for the hub that allows the addon board to connect to the network, and one for the internal application. The addon board again has its own address(es). The default address for each endpoint should be FFFF, which is the broadcast address.
The logic for this can be found in
TrbNetAddresses, connected to
TrbNetRegIO, which is used on the control channel of every endpoint.
Reserved addresses
The addresses F800 to FEFF are not used by the central arbiter and can thus be used in local test setups but should not be used in the final network.
FFFF is the broadcast address to all devices, while FF00 to FFFE are used as broadcasts to parts of the network using bitmasks in every api (The bits set in this bit mask may be cleared in the broadcast to accept it)
Board Identifiers
Each endpoint can be identified with a 72 bit unique number. The first 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor. The last 8 Bits are an additional identifier. It has to be used if there is more than one endpoint on a board, for example the control port of a hub and an user application.
Another 24 Bits contain some basic information about the module to keep maintenance easy. This includes the type of application (hub control, data readout application), type of electronics (trb, hub addon, mdc-addon ...).
| Name |
F0 |
F1 |
F2 |
F3 |
F0 (2) |
F1 (2) |
F2 (2) |
F3 (2) |
| Board ID |
unique.id0 |
unique.id1 |
unique.id2 |
unique.id3 |
unique.id4 |
board_info_0 |
board_info1 |
|
| Unique ID |
temp.sens.id0 |
temp.sens.id1 |
temp.sens.id2 |
temp.sens.id3 |
endpoint_id |
|
|
|
This information is stored inside a small memory according to the following map
| Address |
Content |
|
| 00 |
endpoint_id |
fixed at compile time |
| 01 |
unique_id_0 |
written from TrbNetOnewire |
| 02 |
unique_id_1 |
written from TrbNetOnewire |
| 03 |
unique_id_2 |
written from TrbNetOnewire |
| 04 |
unique_id_3 |
written from TrbNetOnewire |
| 05 |
ACK_ADDRESS |
fixed at compile time |
| 06 |
board_info_0 |
fixed at compile time |
| 07 |
board_info_1 |
fixed at compile time |
The constants at addresses 00 and 05 to 07 are contained in this ram to reduce the space consumption of this entity and must not be changed.
Operation
Configuration
Before starting up the network, a database with all endpoints connected to the network, their unique ids, position in the detector, software versions and the addresses these boards will get must be built.
Address assignment
On network startup, the address manager sends out a broadcast SET_ADDRESS, containing an unique id followed by the address it should be assigned. The board with this unique id sends back a data packet ACK_ADDRESS
If this board is not present in the network, the address manager will make a note inside the log or print a warning on a console.
| Name |
dtype |
F0 |
F1 |
F2 |
F3 |
F0 (2) |
F1 (2) |
F2 (2) |
F3 (2) |
| init: SET_ADDRESS |
1111 |
%SET_ADDRESS% |
unique.id0 |
unique.id1 |
unique.id2 |
unique.id3 |
endpoint_id |
trb_net_address |
CRC? |
| reply: ACK_ADDRESS |
1111 |
%ACK_ADDRESS% |
00 & board_info_0 |
board_info_1 |
trb_net_address |
|
(The values of %set_address% and %ack_address% are defined in trb_net_std.vhd)
Reading unique id
To find out a boards id, one can send a READ_ID command:
Updating the unique id
The unique id saved in the RAM mentioned above is done over an data interface that can do read and write access to the memory. The unique id may be written from etrax or from
TrbNetOnewire when the temperature sensor is connected directly to the fpga.
When updating the unique id, the other memory words must not be changed.
Special modes
Others mode, like dynamically adding new modules and an automatically built address database can be implemented with small effort, but is not needed in our application.
--
JanMichel - 13 Oct 2008
DaqSlowControl