( ESNUG 469 Item 6 ) -------------------------------------------- [09/27/07]
From: Lorenzo Cali <lorenzo.cali=user domain=st hot mom>
Subject: One user's first look at the Dafca ClearBlue silicon debugging IP
Hi, John,
We started using Dafca's ClearBlue 2 years ago. ClearBlue is a chunk of
silicon IP that helps with silicon debug. It instruments your RTL design
or gate level netlist to let you control/observe signals post-silicon.
Our goal at ST was to verify the design on silicon before mask fixes by
having ClearBlue increase the number of observable signals; we wanted to
selectively modify the behavior of the signals at the silicon debug phase.
Because we could directly reconfigure the behavior in silicon, we were able
to implement small changes without a mask fix.
We used ClearBlue on our 90 nm CMOS multi-processor design. The design
contains a 600 K gate standard cell part and a 1 million gate configurable
mask programmable part. The design had 3 synchronous clocks, a processor,
a bus and a programmable clock for the configurable part.
Set up:
ClearBlue was very simple to use, we could execute Dafca's GUI or use a TcL
script. The most time consuming part was identifying which signals we
wanted to observe and control, which is a critical part of this approach.
This process took about 1 week.
ClearBlue added extra modules to our RTL; the new files were synthesizable
and we compared it to the original to verify functional correctness. It
introduces combinational loops with their revised RTL. Because P&R tools
don't perform well with combinational loops, we needed a way to manage them
within our flow. Dafca added constraint files to fix the combinational
loops introduced by debug logic, e.g. case analysis and multi-cycle paths,
so it fits well with our placement and routing. We use Synopsys Astro.
Debugging:
We specifically implemented this design to test ClearBlue. We used fault
injection in our logic, intentionally generating bugs within the 1M gate
configurable area, in order to fix them with ClearBlue.
We wanted to change the behavior of the fault injection. We could also
select the kind of errors to insert. We configured the Dafca trigger engine
for the particular event we wanted to observe. By downloading the content
of the memory trace buffer through the JTAG port we were able to visualize
it through a waveform viewer.
ClearBlue's fixing aspects were powerful: we described the fix using Verilog
and configured ClearBlue through the JTAG port, describing the behavior of
the logic fix.
RTL and Gate Level validation:
To verify our system, we connected ClearBlue to a behavioral model of the
JTAG port. ClearBlue communicated through a simulation bridge to the model.
We dumped ClearBlue's VCD files and viewed them with Mentor's ModelSim.
Long term we may move to Novas, since Dafca has a tight integration with
that viewer, letting you look at the RTL source and see statements in it.
We were able to test the complete environment without having silicon back,
because we mapped our entire design onto Cadence's Palladium hardware
emulator and viewed the design with ClearBlue as if we already had silicon.
Other stuff:
ClearBlue did not require special pins. It generated RTL so we didn't need
to generate or include special libraries.
Reconfigurable triggers. ClearBlue's trigger engine is like a state
machine; we chose to use 16 configurable states. We can do complex trigger
functions with it, mixing signals together to implement complex events.
Dafca supports multi-clock domains, but the signals we tested all belonged
to same clock domain, so we were not able to test this feature.
ClearBlue's best feature was allowing us to instantly observe several
signals without needing to add I/O pins at the chip level. With one JTAG
port, we were able to monitor 1000's of signals. Dafca could improve
ClearBlue's visual representation of the design in the GUI. It would be
helpful to have a more graphical look at what you are going to implement.
ClearBlue was very stable - we had no issues there. It instrumented the
signals that were connected through our main system on the on-chip bus,
adding 32 kilobytes of memory trace buffer for our instrumented signals.
We used a dedicated JTAG port to control all the Dafca logic. We tested
the debug logic directly through this JTAG port and the design was fully
functional. Our critical path was not affected by the debug logic inside
and we met our 100 MHz goal for the test chip, with worst case temperature
and worse case voltage.
We are now promoting our positive experience with it internally in ST.
- Lorenzo Cali
STMicroelectronics Milan, Italy
Index
Next->Item
|
|
