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      

0 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
Board Info Hub (1) / Endpoint (0) uses channel 0 uses channel 1 uses channel 2         Hardware Version Board type                

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.



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:
Name dtype F0 F1 F2 F3 F0 (2) F1 (2) F2 (2) F3 (2)
init: READ_ID 1111 %READ_ID% 0 0 0  
reply:SEND_ID 1111 unique.id0 unique.id1 unique.id2 unique.id3 unique.id4 board_info_0 board_info1 CRC?

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
Topic revision: r9 - 28 Oct 2008, JanMichel
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)