Difference: NewTriggerBusApplicationNotes (1 vs. 8)

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

Howto implement to OLD_TO_NEW converter

Changed:
<
<
The OLD_TO_NEW converter has the old trigger bus as an input, configured in "DTU-mode". On the NewTriggerBus it has to emulate the CTS (central trigger system).
>
>
The OLD_TO_NEW converter has the old trigger bus as an input, configured in "DTU-mode". On the DaqNetwork it has to emulate the CTS (central trigger system).
 
Changed:
<
<
First, the converter entity has to wait for a trigger on the old bus. The trigger tag and the trigger code have to be reconstructed and stored in a register. The converter entity is attached to a TrbNetAPI (active). To perform a short transfer on the API, first the trigger code has to be connected to DTYPE_IN. ERROR_PATTERN, TARGET_ADDRESS_IN, DATA_IN[0...50] and WRITE_IN can be hard wired to 0x0. SHORT_TRANSFER_IN has to be set to 1. The SEND_IN should be raised for 1 clock cycle in order to cause the API sending a short transfer on the NewTriggerBus.
>
>
First, the converter entity has to wait for a trigger on the old bus. The trigger tag and the trigger code have to be reconstructed and stored in a register. The converter entity is attached to a TrbNetAPI (active). To perform a short transfer on the API, first the trigger code has to be connected to DTYPE_IN. ERROR_PATTERN, TARGET_ADDRESS_IN, DATA_IN[0...50] and WRITE_IN can be hard wired to 0x0. SHORT_TRANSFER_IN has to be set to 1. The SEND_IN should be raised for 1 clock cycle in order to cause the API sending a short transfer on the DaqNetwork.
 

To have a fast reaction, READ_IN can be pulled up. DATA_OUT[0...50] has to be latched when DATAREADY_OUT is high, and TYP_OUT is equal to TRM. Then the entity can extract the error pattern, and the seqence number (macros are provided in trb_net_std.vhd). If the error pattern is not 0x0, or the sequence number is not matching the registered trigger tag, this is an severe error, and the error line on the old trigger bus should be raised.
Revision 7
06 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusNetwork"
Changed:
<
<

How a LVL1 trigger is performed

>
>

Howto implement to OLD_TO_NEW converter

The OLD_TO_NEW converter has the old trigger bus as an input, configured in "DTU-mode". On the NewTriggerBus it has to emulate the CTS (central trigger system).

First, the converter entity has to wait for a trigger on the old bus. The trigger tag and the trigger code have to be reconstructed and stored in a register. The converter entity is attached to a TrbNetAPI (active). To perform a short transfer on the API, first the trigger code has to be connected to DTYPE_IN. ERROR_PATTERN, TARGET_ADDRESS_IN, DATA_IN[0...50] and WRITE_IN can be hard wired to 0x0. SHORT_TRANSFER_IN has to be set to 1. The SEND_IN should be raised for 1 clock cycle in order to cause the API sending a short transfer on the NewTriggerBus.

To have a fast reaction, READ_IN can be pulled up. DATA_OUT[0...50] has to be latched when DATAREADY_OUT is high, and TYP_OUT is equal to TRM. Then the entity can extract the error pattern, and the seqence number (macros are provided in trb_net_std.vhd). If the error pattern is not 0x0, or the sequence number is not matching the registered trigger tag, this is an severe error, and the error line on the old trigger bus should be raised.

There is one caveat: It still has to be discussed, if the begrun-tiggers should go in a dedicated channel. Then, of course, the converter entity of the LVL1 bus has to be attached to 2 APIs, and care has to be taken about the numbering.

The old busy signal should be connected to RUN_OUT.
 
Deleted:
<
<
  • After a signal arrived to the CTU, and the LVL1 is not busy, trigger tag and code are prepared, this is still the old CTU functionality
    • Set one word: CID=0001, P=0, Type=TRM, source=0x0000, target address=0xFFFF, Bit Data = Trigger Tag and Code,
    • This word should be stored in the HDR register of the IOFIFO.
  • If the media is blocked, due to a running transfer, the words will be stored in a buffer (IBUF). Unfortuanally in that case the LVL1 trigger is delayed by one 64Bit cycle. Remember, the LVL1 channel has highest priority.
  • The LVL1 channel will be locked. This can be seen using the BUSY line of the IOFIFO.
  • The lock will in addition go back to the old CTU functionality to block the lemo input.
  • In each hub the bits are split for the different ports.
  • In addition, the bits are transported to the internal endpoint, unpacked and interpreted. However, the hubs have no reason to block the channel and answer immediately.
  • If the endpoint is reached, the data is also stored, unpacked and interpreted. The 64bit data word (or only the 12bit tag/code) is forwared to the old DTU design as it would come from the old trigger bus.
  • The old DTU releases the internal channel lock. From that point on, the normal hub implementation is doing the job as for each hub. Remember a DTU is an endpoint with no extra ports.
  • After some time (>10us) all endpoints have been released via the intermediate hubs.
  • The internal hub in the CTU releases the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free.
  • In addition, the CTU should read out the IOFIFO to get the error pattern. If this is not done, at some point the REPLY path will be plugged.
 

Revision 6
14 Jun 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusNetwork"

How a LVL1 trigger is performed

  • After a signal arrived to the CTU, and the LVL1 is not busy, trigger tag and code are prepared, this is still the old CTU functionality
Changed:
<
<
    • Set one word: CID=0000, I=0, D=0, Bit Data = Trigger Tag and Code, address=0xFFF
  • If the media is blocked, the words will be stored in a buffer (IBUF). Unfortuanally in that case the LVL1 trigger is delayed by one 32Bit cycle.
  • If the media in empty, prepare the data on the LVL1 channel. The LVL1 channel has highest priority.
  • Send the buffer content to the internal hub functionality.
  • The internal hub (like each other hub) will transport the bits downstream. The LVL1 channel will be locked
>
>
    • Set one word: CID=0001, P=0, Type=TRM, source=0x0000, target address=0xFFFF, Bit Data = Trigger Tag and Code,
    • This word should be stored in the HDR register of the IOFIFO.
  • If the media is blocked, due to a running transfer, the words will be stored in a buffer (IBUF). Unfortuanally in that case the LVL1 trigger is delayed by one 64Bit cycle. Remember, the LVL1 channel has highest priority.
  • The LVL1 channel will be locked. This can be seen using the BUSY line of the IOFIFO.
 
  • The lock will in addition go back to the old CTU functionality to block the lemo input.
  • In each hub the bits are split for the different ports.
  • In addition, the bits are transported to the internal endpoint, unpacked and interpreted. However, the hubs have no reason to block the channel and answer immediately.
Changed:
<
<
  • If the endpoint is reached, the data is also stored, unpacked and interpreted. The 32bit data word (or only the 12bit tag) is forwared to the old DTU design as it would come from the old trigger bus.
>
>
  • If the endpoint is reached, the data is also stored, unpacked and interpreted. The 64bit data word (or only the 12bit tag/code) is forwared to the old DTU design as it would come from the old trigger bus.
 
  • The old DTU releases the internal channel lock. From that point on, the normal hub implementation is doing the job as for each hub. Remember a DTU is an endpoint with no extra ports.
  • After some time (>10us) all endpoints have been released via the intermediate hubs.
Changed:
<
<
  • The internal hub in the CTU releases the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free
>
>
  • The internal hub in the CTU releases the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free.
  • In addition, the CTU should read out the IOFIFO to get the error pattern. If this is not done, at some point the REPLY path will be plugged.
 
Deleted:
<
<

Reset the system

  • Master should prepare a 32bit word:
    • Set word1: CID=0000, I=1, D+Bit Data = "reset-command", address=0xFFF
  • Interrupt words have highest priority and should be transmitted to all endpoints
  • All hubs reset all ports:
    • Do not clean the handshake logic
    • Enable all ports
  • The master should programm hub-by-hub in the order of the levels (e.g. disable unconnected or broken ports). This should be done by the control program.
  • Stalled handshakes due to broken endpoints can now propagate to the master. I.e. modules can be removed on-the-fly

Clean the system

  • Master should prepare a 32bit word:
    • Set word1: CID=0000, I=1, D+Bit Data = "clean-command", address=0xFFF
  • All hubs clean all ports:
    • Clean the handshake logic
    • Do not touch port configuration
  • A normal clean should be enough for a DAQ restart (if configuration did not changed)

Hardware reset

  • Very often, a power cycle has to be done to recover crashed modules.
  • The SYSTEM interrupt logic could be connected hardwired to a board hardware reset (e.g reset the ETRAX?)
 

-- IngoFroehlich - 10 Feb 2006
Revision 5
20 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusNetwork"
Changed:
<
<

AN1: How a LVL1 trigger is performed

>
>

How a LVL1 trigger is performed

 

  • After a signal arrived to the CTU, and the LVL1 is not busy, trigger tag and code are prepared, this is still the old CTU functionality
Changed:
<
<
    • Set word1: CID=00 and SQR=0, Bit Data = 0x1, address=0xFFFF
    • Set word2: Trigger Tag and Code
  • If the media is blocked, the words have to be stored in a buffer (not in a FIFO!). Unfortuanally in that case the LVL1 trigger is delayed.
>
>
    • Set one word: CID=0000, I=0, D=0, Bit Data = Trigger Tag and Code, address=0xFFF
  • If the media is blocked, the words will be stored in a buffer (IBUF). Unfortuanally in that case the LVL1 trigger is delayed by one 32Bit cycle.
 
  • If the media in empty, prepare the data on the LVL1 channel. The LVL1 channel has highest priority.
  • Send the buffer content to the internal hub functionality.
  • The internal hub (like each other hub) will transport the bits downstream. The LVL1 channel will be locked
Line: 17 to 16
 
  • After some time (>10us) all endpoints have been released via the intermediate hubs.
  • The internal hub in the CTU releases the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free
Changed:
<
<

AN2: Reset the system

>
>

Reset the system

 

  • Master should prepare a 32bit word:
Changed:
<
<
    • Set word1: CID=10 and SQR=1, Bit Data = X, address=0xFFFF
  • Streaming Request words have highest priority and should be transmitted to all endpoints
>
>
    • Set word1: CID=0000, I=1, D+Bit Data = "reset-command", address=0xFFF
  • Interrupt words have highest priority and should be transmitted to all endpoints
 
  • All hubs reset all ports:
    • Do not clean the handshake logic
    • Enable all ports
Deleted:
<
<
  • All hubs should go into streaming mode. This avoids deadlock situations!!!
 
  • The master should programm hub-by-hub in the order of the levels (e.g. disable unconnected or broken ports). This should be done by the control program.
Deleted:
<
<
  • Go back into handshake mode
 
  • Stalled handshakes due to broken endpoints can now propagate to the master. I.e. modules can be removed on-the-fly
Changed:
<
<

AN3: Clean the system

>
>

Clean the system

 
  • Master should prepare a 32bit word:
Changed:
<
<
    • Set word1: CID=11 and SQR=1, Bit Data = X, address=0xFFFF
  • Streaming Request words have highest priority and should be transmitted to all endpoints
>
>
    • Set word1: CID=0000, I=1, D+Bit Data = "clean-command", address=0xFFF
 
  • All hubs clean all ports:
    • Clean the handshake logic
    • Do not touch port configuration
Deleted:
<
<
  • Go back into handshake mode
 
  • A normal clean should be enough for a DAQ restart (if configuration did not changed)
Added:
>
>

Hardware reset

  • Very often, a power cycle has to be done to recover crashed modules.
  • The SYSTEM interrupt logic could be connected hardwired to a board hardware reset (e.g reset the ETRAX?)
 

-- IngoFroehlich - 10 Feb 2006
Revision 4
14 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="NewTriggerBusLink"
>
>
META TOPICPARENT name="NewTriggerBusNetwork"
 

AN1: How a LVL1 trigger is performed

  • After a signal arrived to the CTU, and the LVL1 is not busy, trigger tag and code are prepared, this is still the old CTU functionality
Line: 43 to 43
 

-- IngoFroehlich - 10 Feb 2006
Added:
>
>
META TOPICMOVED by="IngoFroehlich" date="1139917159" from="DaqSlowControl.NewTriggerBusLinkApplicationNotes" to="DaqSlowControl.NewTriggerBusApplicationNotes"
Revision 3
13 Feb 2006 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusLink"

AN1: How a LVL1 trigger is performed

  • After a signal arrived to the CTU, and the LVL1 is not busy, trigger tag and code are prepared, this is still the old CTU functionality
    • Set word1: CID=00 and SQR=0, Bit Data = 0x1, address=0xFFFF
    • Set word2: Trigger Tag and Code
Changed:
<
<
  • If the media is blocked, the words has to be stored in a buffer (not in a FIFO!). Unfortuanally in that case the LVL1 trigger is delayed.
>
>
  • If the media is blocked, the words have to be stored in a buffer (not in a FIFO!). Unfortuanally in that case the LVL1 trigger is delayed.
 
  • If the media in empty, prepare the data on the LVL1 channel. The LVL1 channel has highest priority.
Changed:
<
<
  • Semd the buffer content to the internal hub functionality.
>
>
  • Send the buffer content to the internal hub functionality.
 
  • The internal hub (like each other hub) will transport the bits downstream. The LVL1 channel will be locked
  • The lock will in addition go back to the old CTU functionality to block the lemo input.
Changed:
<
<
  • In each hub the bits are splitted for the different ports.
>
>
  • In each hub the bits are split for the different ports.
 
  • In addition, the bits are transported to the internal endpoint, unpacked and interpreted. However, the hubs have no reason to block the channel and answer immediately.
  • If the endpoint is reached, the data is also stored, unpacked and interpreted. The 32bit data word (or only the 12bit tag) is forwared to the old DTU design as it would come from the old trigger bus.
Changed:
<
<
  • The old DTU releases the internal channel lock. From that point on, the normal hub implementation is doing the job as for each hub. Remember an DTU is an endpoint with no extra ports.
>
>
  • The old DTU releases the internal channel lock. From that point on, the normal hub implementation is doing the job as for each hub. Remember a DTU is an endpoint with no extra ports.
 
  • After some time (>10us) all endpoints have been released via the intermediate hubs.
Changed:
<
<
  • The internal hub in the CTU is release the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free
>
>
  • The internal hub in the CTU releases the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free
 

AN2: Reset the system

Line: 26 to 26
 
    • Do not clean the handshake logic
    • Enable all ports
  • All hubs should go into streaming mode. This avoids deadlock situations!!!
Changed:
<
<
  • The master should programm hub-by-hub in the order of the levels (e.g. diable unconnected or broken ports). This should be done by the control program.
>
>
  • The master should programm hub-by-hub in the order of the levels (e.g. disable unconnected or broken ports). This should be done by the control program.
 
  • Go back into handshake mode
  • Stalled handshakes due to broken endpoints can now propagate to the master. I.e. modules can be removed on-the-fly
Revision 2
13 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusLink"

AN1: How a LVL1 trigger is performed

Line: 17 to 17
 
  • After some time (>10us) all endpoints have been released via the intermediate hubs.
  • The internal hub in the CTU is release the lock for the LVL1 channel, this directly goes to the CTU which makes the LVL1 free
Added:
>
>

AN2: Reset the system

 
Added:
>
>
  • Master should prepare a 32bit word:
    • Set word1: CID=10 and SQR=1, Bit Data = X, address=0xFFFF
  • Streaming Request words have highest priority and should be transmitted to all endpoints
  • All hubs reset all ports:
    • Do not clean the handshake logic
    • Enable all ports
  • All hubs should go into streaming mode. This avoids deadlock situations!!!
  • The master should programm hub-by-hub in the order of the levels (e.g. diable unconnected or broken ports). This should be done by the control program.
  • Go back into handshake mode
  • Stalled handshakes due to broken endpoints can now propagate to the master. I.e. modules can be removed on-the-fly

AN3: Clean the system

  • Master should prepare a 32bit word:
    • Set word1: CID=11 and SQR=1, Bit Data = X, address=0xFFFF
  • Streaming Request words have highest priority and should be transmitted to all endpoints
  • All hubs clean all ports:
    • Clean the handshake logic
    • Do not touch port configuration
  • Go back into handshake mode
  • A normal clean should be enough for a DAQ restart (if configuration did not changed)
 

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