Difference: NewTriggerBusMedia (1 vs. 11)

Revision 11
31 Dec 2009 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusConcept"

New Trigger Bus Media

General IO interface

Changed:
<
<
To make the NewTriggerBus independent from any media, a standard IO interface is proposed.
>
>
To make the DaqNetwork independent from any media, a standard IO interface is proposed.
  The interface follows the principle, that data words are never pushed into the next stage, but always offered and read be the next stage. In detail, the interface should look like:
Line: 21 to 21
  (the INT_ERROR_OUT will be used only for the 1st output)

As one can see, there are 2 symmetric directions: One for the direction to the internal logic,
Changed:
<
<
one for the data direction to the media. All entities of the NewTriggerBus should follow this
>
>
one for the data direction to the media. All entities of the DaqNetwork should follow this
  principle (sometimes however one one-directional, and the width "DATA_WIDTH" might change)

The 8 missing spare bits to complete 64Bit might use for additional error detection/correction if needed.
Revision 10
28 Dec 2007 - Main.JanMichel
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="NewTriggerBus"
>
>
META TOPICPARENT name="NewTriggerBusConcept"
 

New Trigger Bus Media

Revision 9
27 Mar 2007 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

New Trigger Bus Media

Line: 17 to 17
 
INT_DATAREADY_IN Data word is offered by the internal logic or FIFO
INT_DATA_IN[0...55] Data word
INT_READ_OUT Media interface reads a word
Changed:
<
<
INT_ERROR_IN[0..2] Status bits
>
>

(the INT_ERROR_OUT will be used only for the 1st output)
 

As one can see, there are 2 symmetric directions: One for the direction to the internal logic, one for the data direction to the media. All entities of the NewTriggerBus should follow this
Changed:
<
<
principle (sometimes however one one-directional, and the width might change)
>
>
principle (sometimes however one one-directional, and the width "DATA_WIDTH" might change)
 

The 8 missing spare bits to complete 64Bit might use for additional error detection/correction if needed.
Line: 34 to 35
 
011 Fatal error, not recoverable
100 Media not connected
Added:
>
>

Slices

To avoid the big register logic of all entities which are using really big buses, the generic "SLICES" should be used.
  • SLICES=0: Do not use slices, only the big bus
  • SLICES>0: Scramble the bus into several slices

In addition, the generic "BUS_WIDTH" has to be used. It is very clear, that for the SLICES=0 the BUS_WIDTH have to match the DATA_WIDTH. Otherwise, the bus bits have a different meaning: The first bits are the slice number, so if SLICES=4 (matching to 100MHz with the optical link), 2 bits are needed. In addition, for 56 data bits, 14 bus bits are needed in addition. This makes 16 bits!
 

Optical Link

The use of an optical links has many advantages:
Revision 8
20 Nov 2006 - Main.TiagoPerez
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"
Changed:
<
<

General IO interface

>
>

New Trigger Bus Media

General IO interface

 

To make the NewTriggerBus independent from any media, a standard IO interface is proposed. The interface follows the principle, that data words are never pushed into the next stage, but always offered and
Line: 31 to 34
 
011 Fatal error, not recoverable
100 Media not connected
Changed:
<
<

Optical Link

>
>

Optical Link

 

The use of an optical links has many advantages:
Line: 50 to 53
  These bits can even be reconstructed if a word is completely corrupted, the data content is then lost, but who cares...
Changed:
<
<

SCSI cable and trb add-on lvds links.

>
>

SCSI cable and trb add-on lvds links.

 

A standard SCSI cable is used for the connection of the AcromagModule. From the 32 IO lines, 16 lines are used for each direction.
Line(s) Signal
Line: 66 to 69
 

Changed:
<
<

Additional Media?

>
>

Additional Media?

 

* RJ45:
Line: 89 to 92
  The use of the signals in this way makes sure that even if by accident a crosover cable is used, only CLK and DATA of one direction is mixed.
Changed:
<
<
-- IngoFroehlich - 10 Feb 2006

>
>
-- TiagoPerez - 20 Nov 2006
 

META FILEATTACHMENT attr="h" comment="RJ45" date="1139567093" name="rj45.jpg" path="rj45.jpg" size="4420" user="IngoFroehlich" version="1.1"
Revision 7
30 Oct 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

General IO interface

Line: 50 to 50
  These bits can even be reconstructed if a word is completely corrupted, the data content is then lost, but who cares...
Changed:
<
<

SCSI cable

>
>

SCSI cable and trb add-on lvds links.

 

A standard SCSI cable is used for the connection of the AcromagModule. From the 32 IO lines, 16 lines are used for each direction.
Line(s) Signal
Changed:
<
<
1-8 Data0-7
9 CLK
10 TX_EN
11 TX_ER
12 Parity
13-16 res.
>
>
1-13 Data0-12
14 CLK
15 carrier
16 Parity
As it can be seen, with 13 data bits, 65 data bits can be transferred in 5 frames (9 bits can be used for error checking and correction). "carrier" is 1 for data words, and 0 for control words (like idle), needed for frame synchronization. Parity can be used for additional error detection. The order of the signal on the cable or the addon connector depend on the clk input pins and might differ for the 2 cases.
 

Revision 6
18 Aug 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

General IO interface

Line: 11 to 11
 
INT_DATA_OUT[0...55] Data word
INT_READ_IN Internal logic is reading from the FIFO
INT_ERROR_OUT[0..2] Status bits
Changed:
<
<
MED_DATAREADY_IN Data word is offered by the internal logic or FIFO
MED_DATA_IN[0...55] Data word
MED_READ_OUT Media interface reads a word
MED_ERROR_IN[0..2] Status bits
>
>
INT_DATAREADY_IN Data word is offered by the internal logic or FIFO
INT_DATA_IN[0...55] Data word
INT_READ_OUT Media interface reads a word
INT_ERROR_IN[0..2] Status bits
 

As one can see, there are 2 symmetric directions: One for the direction to the internal logic, one for the data direction to the media. All entities of the NewTriggerBus should follow this
Revision 5
14 Jun 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

General IO interface

Line: 17 to 17
 
MED_ERROR_IN[0..2] Status bits

As one can see, there are 2 symmetric directions: One for the direction to the internal logic,
Changed:
<
<
one for the data direction to the media. All entities of the NewTriggerBus are following this
>
>
one for the data direction to the media. All entities of the NewTriggerBus should follow this
  principle (sometimes however one one-directional, and the width might change)
Added:
>
>
The 8 missing spare bits to complete 64Bit might use for additional error detection/correction if needed.
  Meaning of the error bits:

Bits Description
000 Data word OK
Changed:
<
<
001 Transmission error from the 8B/10B
010 Transmission error, reconstructed by Hamming code
>
>
001 Transmission error from the 8B/10B encoding
010 Transmission error, reconstructed by additional bit
 
011 Fatal error, not recoverable
100 Media not connected
Line: 38 to 40
 
  • Fast
  • Standard technologie (SFP), many vendors
Changed:
<
<
We will use the TLK2501 as a Serdes chip: 16 Bit data bus, error and link detection makes debugging much easier.
>
>
We will use the TLK2501/TLK1501 as a Serdes chip: 16 Bit data bus, error and link detection makes debugging much easier.
  In addition, the 8B/10B encoding allows to send special symbols, like commas, carier extend, errors. This allows to separate the frames and synchronize state machines of the transmitter and receiver.

The frame content of the NewTriggerBusNetwork is always fixed on 64Bit (with 56Bit needed data bits for the protocol),
Changed:
<
<
thus it makes the decoding very easy. In addition the 8 remaining bits can used the protect
>
>
thus it makes the decoding very easy. In addition the 8 remaining bits could used the protect
  the most important 2*4 Bits (transported in 4 TLK frames) using the 4-7 Hamming code. These bits can even be reconstructed if a word is completely corrupted, the data content is then lost, but who cares...
Revision 4
24 May 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"
Added:
>
>

General IO interface

To make the NewTriggerBus independent from any media, a standard IO interface is proposed. The interface follows the principle, that data words are never pushed into the next stage, but always offered and read be the next stage. In detail, the interface should look like:

Line Decription
INT_DATAREADY_OUT Data word is reconstructed and ready to be read out by the internal logic
INT_DATA_OUT[0...55] Data word
INT_READ_IN Internal logic is reading from the FIFO
INT_ERROR_OUT[0..2] Status bits
MED_DATAREADY_IN Data word is offered by the internal logic or FIFO
MED_DATA_IN[0...55] Data word
MED_READ_OUT Media interface reads a word
MED_ERROR_IN[0..2] Status bits

As one can see, there are 2 symmetric directions: One for the direction to the internal logic, one for the data direction to the media. All entities of the NewTriggerBus are following this principle (sometimes however one one-directional, and the width might change)

Meaning of the error bits:

Bits Description
000 Data word OK
001 Transmission error from the 8B/10B
010 Transmission error, reconstructed by Hamming code
011 Fatal error, not recoverable
100 Media not connected
 

Optical Link

The use of an optical links has many advantages:
Line: 10 to 39
 
  • Standard technologie (SFP), many vendors

We will use the TLK2501 as a Serdes chip: 16 Bit data bus, error and link detection makes debugging much easier.
Changed:
<
<
In addition, the 8B/10B encoding allows to send spectial symbols, like commas, carier extend, errors. This allows to separate the frames and syncronize state machines of the transmitter and receiver.
>
>
In addition, the 8B/10B encoding allows to send special symbols, like commas, carier extend, errors. This allows to separate the frames and synchronize state machines of the transmitter and receiver.
 
Changed:
<
<
The frame content of the NewTriggerBusNetwork is always fixed on 32Bit (with 24Bit as data), thus it makes the decoding very easy. In addition a 32B/48B encoding with using XOR might even recover from error packets. In total this makes 60Bit with a real data content of 24Bit.
>
>
The frame content of the NewTriggerBusNetwork is always fixed on 64Bit (with 56Bit needed data bits for the protocol), thus it makes the decoding very easy. In addition the 8 remaining bits can used the protect the most important 2*4 Bits (transported in 4 TLK frames) using the 4-7 Hamming code. These bits can even be reconstructed if a word is completely corrupted, the data content is then lost, but who cares...
 

SCSI cable

Revision 3
03 Apr 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"
Changed:
<
<

Media

>
>

Optical Link

The use of an optical links has many advantages:

  • No charge flow
  • Long cable connections (1km!)
  • Fast
  • Standard technologie (SFP), many vendors

We will use the TLK2501 as a Serdes chip: 16 Bit data bus, error and link detection makes debugging much easier. In addition, the 8B/10B encoding allows to send spectial symbols, like commas, carier extend, errors. This allows to separate the frames and syncronize state machines of the transmitter and receiver.

The frame content of the NewTriggerBusNetwork is always fixed on 32Bit (with 24Bit as data), thus it makes the decoding very easy. In addition a 32B/48B encoding with using XOR might even recover from error packets. In total this makes 60Bit with a real data content of 24Bit.

SCSI cable

A standard SCSI cable is used for the connection of the AcromagModule. From the 32 IO lines, 16 lines are used for each direction.
Line(s) Signal
1-8 Data0-7
9 CLK
10 TX_EN
11 TX_ER
12 Parity
13-16 res.

Additional Media?

 
Deleted:
<
<
Proposal: Use RJ-45 plug and cable (the ethernet cable)
 

* RJ45:
RJ45
Line: 23 to 54
 

The use of the signals in this way makes sure that even if by accident a crosover cable is used, only CLK and DATA of one direction is mixed.
Deleted:
<
<

Clock recovery

If we use source synchronous transfer (so transmitting the clock), then we don't need a clock recovery. A serdes for clock synchronous transfer is implemented for example in the Virtex 4 architechture of Xilinx, but I assume also for Altera. If we go for a clock recovery: Needs a serdes chip with PLL and clock recovery (limited frequency range, not so flexible), Up to now we don't know any chip which allows a clock recovery below 600MHz, but we need something around 100MHz to keep the 100m length option of the cables.
 

-- IngoFroehlich - 10 Feb 2006

Revision 2
10 Feb 2006 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Media

Line: 9 to 9
 

Advantage: 4 twisted pair lines, off-the-shelf cables
Changed:
<
<
2 lines can be used for downstream (to the endpoints), and 2 for upstream (to the master). This allows to use always one line for clock (if needed) and one for data. LVDS signals should be used, the clock frequenca should be choosen that 100m cables could be used.
>
>
Two pairs can be used for downstream (to the endpoints), and 2 for upstream (to the master). This allows to use always one line for clock (if needed) and one for data. LVDS signals should be used, the clock frequency should be choosen that 100m cables could be used.
 

Signal Pin Color of Line
UpCLK+ 1 white to green
Line: 25 to 25
 

Clock recovery

Changed:
<
<
Not decided yet. Either self-build (needs more manpower) or costom serdes chip (fixed frequenca, not so flexible)
>
>
If we use source synchronous transfer (so transmitting the clock), then we don't need a clock recovery. A serdes for clock synchronous transfer is implemented for example in the Virtex 4 architechture of Xilinx, but I assume also for Altera. If we go for a clock recovery: Needs a serdes chip with PLL and clock recovery (limited frequency range, not so flexible), Up to now we don't know any chip which allows a clock recovery below 600MHz, but we need something around 100MHz to keep the 100m length option of the cables.
 

-- IngoFroehlich - 10 Feb 2006
 
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)