# Presentation: 362663

## Hardware Database

- 4/15/99

## Hardware Database

- What front-end crates exist and their properties
- What cards are in what slots in the crates
- What components/channel Ids are associated with each card
- Ability to associate calibration database info (channel ID based) with hardware modules
- What links exist between modules
- e.g. Tracer -> VRB channel
- TDC -> XFT finder
- etc.
- Previous system used VMS ISAM files, separate databases for FASTBUS and RABBIT modules
- FORTRAN API for access

## Uses

- Subset of information forms the set of resources managed by the resource manager
- Build readout lists for front-end crate processors
- Eventually including calibration database info
- Allow calibration analysis consumers (that receive channel ID oriented data) to make hardware address based reports

## Prototype Implementation

- Central calorimeter used as a test case
- Document at Online Home Page -> Database -> Hardware Database
- http://www-cdf.fnal.gov/offline/database/online_hardware_db.html
- Started with MSQL, moved to Oracle
- Made use of Oracle 2000 Designer tool
- Done by Geri Goeransson
- Tables for Crates, Cards, Components, Channels
- Accessible from Java programs using JDBC
- JDBC delivers and SQL query and provides a convenient way of parsing the result
- Higher layer above this desirable, some recent work on this.
- Feedback needed on what information is needed in what format

## Crate table

- Name (logical name) - primary key
- Number
- Type
- Tracer Slot
- Things that probably should be added include:
- node name
- crosspoint channels
- clock channels(?)

## Card table

- Name (key)
- Online
- Slot
- Type
- CrateName (key)
- Component (key)
- ChannelCount
- ID PROM string
- LinkedCardName (e.g. VRB name)
- DestinationConnection (e.g. VRB channel)
- Issues:
- SMXR has multiple components
- Some cards will want to add additional information, different information for different card types
- Could also include:
- L2 buffer addresses?
- Variable count flag?
- Maximum count to read?

## Component table

- Name
- Number (key)

## Channel table

- ChannelID (as in raw data format) (key)
- ChannelNumber (0-N)
- Block (as in raw data format)
- Subaddress on card
- CardName (key)
- Subaddress or Channel # within the card
- To deal with SMXR, move component from card table to here?
- Does block belong here? Or on card?
- How to associate with calibration database info?
- Cal DB API just has container of repeating channel ID/data
- No block structure, no hardware correlation
- The old system also worked like this, the ChannelNumber above was an effective index into the cal data bank for the channel.
- But current CDB API only has iterator access, not random access

## Readout list type query

- For some crate
- Find cards, group by component
- Find associated channelID <=> channel #
- Or just get “base” channel ID for a card, generate the rest  in the crate processor code.
- crude approximation to SQL statement would be:select slot, component, block, channelID, subaddress from channels, cards, components, crates where crates.name = ‘X’ and channels.cardname = cards.cardname

## Java API issues

- With JDBC, supply an SQL query, get back a “result set”
- User is responsible for interpreting this
- What are the standard queries, and in what format should the information be presented?
- Presumably for example if one queries what crates exist, the results are presented as a container of crate objects that contain the fields in the table.
- Likewise for modules
- If there is different optional information for many modules, this can get tedious
- Reflection API can help some (if column names = class field names)
- Then putting the relations in the results can be tricky
- C++ API needed for calibration analysis programs?
- Limited usage modes
- Any way to add in to current offline DB package?

## Other detector components

- TDCs fit in this scheme
- Need to download channel <=>“cell/wire” map
- Channel ID only unique within a block (unlike calorimeter)
- Trigger info?
- For most things, only the block # for a card is supposed to be relevant.

## Resource Manager

- Needs crate info
- Also some other “bookable” devices
- SRC
- Trigger Supervisors
- VRBs
- Must also deal with associations:
- High level logical names (CDF -> etc.)
- “Implicit” reservations
- Additional tables?
- Should anything else be added to these tables?

## Next steps

- Feedback needed
- What information is missing?
- What queries are needed?
- In what format should the data be presented?
- Add TDCs to prototype?
- Small API usage prototypes:
- Build calorimeter readout list
- Calibration reports
- Resource manager?

## Run Configuration Database

- Run Type
- Number of events (or unbounded)
- Trigger (Trigger table or external trigger input channel)
- Max event size in readout controller (more for calibrations)
- Readout controller buffer configuration (fewer larger buffers for calibrations)
- For internal calibrations, number of triggers per read out event
- Trigger Supervisor timeouts (not actually varied much)
- Clock configuration (not much to vary in Run II)
- Data correction mode (apply gain/offset correction or not)
- Readout controller program (due to limited memory had different ones for different run types/detector components)
- List of components to be enabled for readout
- Calibration controller parameters
- Interpreted on run type specific basis - no standard format
- List of consumers to be automatically started
- Commands sent to consumers kept in a different file