VME in CMS
Printable (pdf)
|
|
VME in CMS |
Printable (html) Printable (pdf) |
|
SBS PCI-to-VME bridgeModels 618 and 620Info about the SBS interface modulesThe SBS controler is supported by the CMS online software, in particular by the HAL, the Hardware Access Library used in CMS and XDAQ. Model 618 has some loopback diagnostics feature in order to test the optical link which is missing in model 620. For the rest models 618 and 620 are identical.
The SBS interface in CMSThe HAL uses single word and block transfer accesses of the SBS module and uses the user-level linux library which comes with the module. Interrupt support is currently being implemented. It uses the SBS library support for interrupt handling (via callbacks to a user routine). CMS wants to build/use VME64x modules which allow for plug and play crate configuration. With the SBS module it is possible configure a VME64x crate with VME64x modules which implement the VME64x-plug-and-play specification. (This means: it is possible to generate accesses with AM=2F.) The software is included in the HAL library. It has been tested with the first two VME64x VME modules of ECAL. You should know that the SBS modules do not support D64, A64 or A40 accesses. You cannot expect terrific performance with it (see the measurements: 25-27 Mb/sec with a RAMix memory; SBS claims to have achieve 35Mb/sec (???!!!)). Another disadvantage might be, that you cannot chain the modules. If you want to have some minimal performance in the local data aquisition you may be do not want to do this anyway. (You can plug in principle many adapters in the same PC. Be aware that you need an old conventional PCI 32 bit slot with 5V in order to be able to plug the module in the PC (there exists now modern servers which only have 3.3V PCI-64 bit connectors). The latest versions of the bridge (Model 620-3) also support 3.3V PCI slots. This is important for you if you also want to operate for example a Fedkit in the same PC: the GIII needs a 64 bit slot with 3.3V. But there are many motherboards which have a mixture of different slots. With the current driver of SBS (v2p3p0) there is an issue if you want to use the user level interrupt callback mechanism in order to do plug and play according to the VME64 (NOT VME64x) specification. The specification requires that after power up you handle the interrupts of all boards one after the other: You must not acknowledge an interrupt of a board before having set the relevant registers for the module configuration. Unfortunately the SBS driver works in an incompatible for this procedure: The interrupts are all acknowledged and the calls of the user level interrupt handling routine are queued. When the handler is called the first time, the interrupts of all modules are already acknowledged. The SBS bridge is in many repects better suited for CMS than the National MXI bridge. The latter are made for use with VXI which we do not use in CMS. In addition the NI/MXI module has the following disadvantages: The software is only partly public, nobody ever succeeded to generate a large block transfer, software updates seem to cost a lot of money, the LVDS cables are extremly unhandy, it seems to be impossible to generate the 0x2f address modifier, people have reported difficulties to use it in XDAQ-applications. |
||||||||
|