Difference: TrbNetAddresses (1 vs. 9)

Revision 9
28 Oct 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetEntities"

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.
Line: 14 to 14
 

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 ...).
Changed:
<
<
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        
>
>
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      
 
Changed:
<
<
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Board Info Hub (1) / Endpoint (0) uses channel 0 uses channel 1 uses channel 2         Hardware Version Board type        
>
>
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
Changed:
<
<
00 SET_ADDRESS & endpoint_id fixed at compile time
>
>
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
Changed:
<
<
06 board_info_0 & endpoint_id 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.
Line: 47 to 47
  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)
Changed:
<
<
init: SET_ADDRESS 1111 %SET_ADDRESS% endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 trb_net_address CRC?
>
>
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)
Changed:
<
<
init: READ_ID 1111 %READ_ID% 0 0  
>
>
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?
Revision 8
13 Oct 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetEntities"

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.
Line: 14 to 14
 

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 ...).
Changed:
<
<
Name word0 word1 word2 word3 word4 word5
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    
>
>
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
Line: 46 to 46
  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.
Changed:
<
<
Name dtype word0 word1 word2 word3 word4 word5
init: SET_ADDRESS 1111 %SET_ADDRESS% & endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 trb_net_address
reply: ACK_ADDRESS 1111 %ACK_ADDRESS% 00 & board_info_0 board_info_1  
>
>
Name dtype F0 F1 F2 F3 F0 (2) F1 (2) F2 (2) F3 (2)
init: SET_ADDRESS 1111 %SET_ADDRESS% endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 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:
Changed:
<
<
Name dtype word0 word1 word2 word3 word4 word5
init: READ_ID 1111 %READ_ID% 0 0  
reply:SEND_ID 1111 unique.id0 unique.id1 unique.id2 unique.id3 unique.id4 board_info_0 board_info1
>
>
Name dtype F0 F1 F2 F3 F0 (2) F1 (2) F2 (2) F3 (2)
init: READ_ID 1111 %READ_ID% 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

Line: 70 to 70
 

Changed:
<
<
-- JanMichel - 03 Apr 2008
>
>
-- JanMichel - 13 Oct 2008
 
Revision 7
04 Apr 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetEntities"

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.
Line: 42 to 42
 

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.
Changed:
<
<

Network startup

On 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
>
>

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 word0 word1 word2 word3 word4 word5
Changed:
<
<
SET_ADDRESS 1111 %SET_ADDRESS% & endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 trb_net_address
ACK_ADDRESS 1111 %ACK_ADDRESS% 00 & board_info_0 board_info_1  
>
>
init: SET_ADDRESS 1111 %SET_ADDRESS% & endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 trb_net_address
reply: ACK_ADDRESS 1111 %ACK_ADDRESS% 00 & board_info_0 board_info_1  
  (The values of %set_address% and %ack_address% are defined in trb_net_std.vhd)
Added:
>
>

Reading unique id

To find out a boards id, one can send a READ_ID command:
Name dtype word0 word1 word2 word3 word4 word5
init: READ_ID 1111 %READ_ID% 0 0  
reply:SEND_ID 1111 unique.id0 unique.id1 unique.id2 unique.id3 unique.id4 board_info_0 board_info1
 

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.
Revision 6
03 Apr 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetEntities"

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.
Line: 32 to 32
 
03 unique_id_2 written from TrbNetOnewire
04 unique_id_3 written from TrbNetOnewire
05 ACK_ADDRESS fixed at compile time
Changed:
<
<
06 00 & board_info_0 fixed at compile time
>
>
06 board_info_0 & endpoint_id 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.
Line: 51 to 51
 
ACK_ADDRESS 1111 %ACK_ADDRESS% 00 & board_info_0 board_info_1  
(The values of %set_address% and %ack_address% are defined in trb_net_std.vhd)
Added:
>
>

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.
Revision 5
03 Apr 2008 - Main.JanMichel
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="TrbNetUsersGuide"
>
>
META TOPICPARENT name="TrbNetEntities"
 

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.
Changed:
<
<
The logic for this will be included into TrbNetRegIO, which is used on the control channel of every endpoint.
>
>
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.
Line: 22 to 22
 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Board Info Hub (1) / Endpoint (0) uses channel 0 uses channel 1 uses channel 2         Hardware Version Board type        
Added:
>
>

This information is stored inside a small memory according to the following map

Address Content
00 SET_ADDRESS & 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 00 & 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.
Line: 43 to 59
 

Changed:
<
<
-- JanMichel - 31 Mar 2008
>
>
-- JanMichel - 03 Apr 2008
 
Revision 4
31 Mar 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetUsersGuide"

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.
Line: 6 to 7
 

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.
Changed:
<
<
FFFF is the broadcast address to all devices, while FF00 to FFFE are used as broadcasts to parts of the 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

Changed:
<
<
Each endpoint can be identified with a 96 bit unique number. The first 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor. The next 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. The last 24 Bit 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 ...). Later, information on the channels this device is connected to can be included to increase the network speed with individually configured hubs.
>
>
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 word0 word1 word2 word3 word4 word5
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    
 
Added:
>
>
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Board Info Hub (1) / Endpoint (0) uses channel 0 uses channel 1 uses channel 2         Hardware Version Board type        
 

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.

Network startup

Changed:
<
<
On startup, the address manager sends out a broadcast, containing an unique id followed by the address it should be assigned. The board with this unique id sends back a data packet ADDRESS_SET.
>
>
On 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.
Added:
>
>
Name dtype word0 word1 word2 word3 word4 word5
SET_ADDRESS 1111 %SET_ADDRESS% & endpoint_id unique.id0 unique.id1 unique.id2 unique.id3 trb_net_address
ACK_ADDRESS 1111 %ACK_ADDRESS% 00 & board_info_0 board_info_1  
(The values of %set_address% and %ack_address% are defined in trb_net_std.vhd)
 

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.
Line: 29 to 43
 

Changed:
<
<
-- JanMichel - 14 Mar 2008
>
>
-- JanMichel - 31 Mar 2008
 
Revision 3
14 Mar 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetUsersGuide"
Deleted:
<
<
This information is a proposal only and needs further discussion
 

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.
Changed:
<
<

The real addresses are assigned by a central address server. On network startup it sends a broadcast to all devices, asking for a unique id and some basic information.

The logic for this can be included into TrbNetRegIO, which then will be obligatory for each endpoint.
>
>
The logic for this will be included into 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.
Changed:
<
<
FFFF is the broadcast address to all devices, while FF00 to FFFE can be used as broadcasts to parts of the network.
>
>
FFFF is the broadcast address to all devices, while FF00 to FFFE are used as broadcasts to parts of the network.

Board Identifiers

Each endpoint can be identified with a 96 bit unique number. The first 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor. The next 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. The last 24 Bit 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 ...). Later, information on the channels this device is connected to can be included to increase the network speed with individually configured hubs.

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.
 
Changed:
<
<

Data format

>
>

Network startup

On startup, the address manager sends out a broadcast, containing an unique id followed by the address it should be assigned. The board with this unique id sends back a data packet ADDRESS_SET. 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.
 
Changed:
<
<

Request for ids

The request for ids is a short transfer with datatype F and the 32 data bits set to REQUEST_FOR_IDS.
>
>

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.
 
Deleted:
<
<

Answer with Ids

Each network member that not has an address yet sends 96 bits of data back: First 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor.
 
Deleted:
<
<
The next 16 Bit are an identifier to distinguish between hub and the applications. These numbers can be chosen by random as long as they are unique per board. The last 16 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 ...).
 
Deleted:
<
<
Later, information on the channels this device is connected to can be included to increase the network speed with individually configured hubs.
 
Deleted:
<
<
Network members who already have been assigned an address answer with a short transfer only - this makes it possible to add new nodes without restarting the whole network.
 
Deleted:
<
<

Assigning addresses

The address server is using a database for storing information about addresses. An already known endpoint should get the same address on each startup. Now all boards that replied with an id are given their addresses. The first 32 bit contain the SET_ADDRESSES operation code, then all 80 bit unique identifiers followed by the assigned 16 bit address are sent. Each endpoint check for its unique id and saves the matching address.
 
Changed:
<
<
-- JanMichel - 28 Dec 2007
>
>
-- JanMichel - 14 Mar 2008
 
Revision 2
29 Jan 2008 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="TrbNetUsersGuide"
This information is a proposal only and needs further discussion
Line: 10 to 10
  The logic for this can be included into TrbNetRegIO, which then will be obligatory for each endpoint.

Reserved addresses

Changed:
<
<
The addresses FF00 to FFFE 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.
>
>
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 can be used as broadcasts to parts of the network.
 

Data format

Line: 19 to 19
  The request for ids is a short transfer with datatype F and the 32 data bits set to REQUEST_FOR_IDS.

Answer with Ids

Changed:
<
<
Each network member that not has an address yet send 96 bits of data back: First 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor.
>
>
Each network member that not has an address yet sends 96 bits of data back: First 64 bits are a unique id, mostly retrieved from the unique id of the onboard temperature sensor.
 

The next 16 Bit are an identifier to distinguish between hub and the applications. These numbers can be chosen by random as long as they are unique per board. The last 16 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 ...).
Changed:
<
<
Later, information on the channels this point is connected to can be included to increase the network speed with individually configured hubs.
>
>
Later, information on the channels this device is connected to can be included to increase the network speed with individually configured hubs.
 

Network members who already have been assigned an address answer with a short transfer only - this makes it possible to add new nodes without restarting the whole network.
 
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)