Main issues on FPGAs for CMS-HCAL:
- The FPGA designs should be documented following
this
template.
and published on web servers with a long
lifetime (CMS and ATLAS require to store documents in
EDMS).
- The FPGAs should be configurable from VME.
- Each FPGA design should include a register
with a version number (the documentation must explain how to access this register)
- Code and schematics should be well commented,
including the desired behaviour of each design module.
Discussion on the approaches for maintenance
1) "museum of old computers and tools":
provide legacy maintenance and keep a computer(s) and the software in cold
storage until needed.
Pros: simpler and cheaper,
Cons: risks. Known cases about legacy equipment
that didn't come back to life and was unfixable.
2) "pull forward" approach: keep ones
application current with the latest release.
Pros: possibility to use state-of-the-art tools.
Cons: requires a lot of effort and discipline.
Problems: Known cases of a new version of a tool that gave a synthesied output
drastically different from the previous version, with the same input HDL
code. New tools often do not support old devices.
3) "on demand" (or "do nothing"): run the files through the latest versions when there really is a need for it. When making modifications, it is likely to re-simulate and also have a hardware testbench to verify everything (in approach 2, you probably won't check the results), so it is sure everything went fine. Problem: new tools often do not support old devices.
There is a design style that minimize the risks of re-synthetasing on a new tool (synchronous design, as least as possible dependent on special Cores or LPMs).
Tullio Grassi - NOV 2001
Return to my HCAL CMS
working page
=============================================================