Achronix ACE Version 5.0 User Manual
Page 299
Running the SnapShot Debugger
Chapter 4. Tasks
The user may optionally modify their Design Under Test (DUT) to respond to external data sent via the
SnapShot interface. The Rstn out, Arm, and Stimuli signals may be used to create desired events, which
may then be observed in the trace buffers. If any of these outputs are used, then the OUTPUTPIPELINING
parameter value will usually need to be increased above its default value of 0.
The OUTPUTPIPELINING parameter is included to minimize the timing impact of SnapShot on the Design
Under Test, when the design depends upon SnapShot output signals. Typical use of the Rstn out, Stimuli
and Arm outputs introduces a timing critical loop between the user’s Design Under Test and the SnapShot
logic. To mitigate such loops OUTPUTPIPELINING is available as a convenient way to add latency into
such loops, thereby relaxing the timing criticality. This comes at the expense of logic resources, so setting
this parameter to a large value (e.g. 20) may waste many resources if many of the Stimuli are used and the
usr clk frequency is low. For smaller size designs, and/or when the usr clk speed specification is within
the 100-200 MHz range, it is possible to use lower value for this parameter (for example 2 or 3). For larger,
higher speed designs (e.g. 30 kLUTs running at 500 MHz) the user may need to increase this parameter to
a value of 7 or 8, depending on the total delay introduced in the loop. The default parameter value is 0 to
minimize resource usage in designs which leave the Rstn out, Stimuli and Arm outputs floating.
The Arm signal is asserted when the SnapShot logic starts observing the monitor channels (Monitor ch )
and trigger values (trigger ch ). Arm is de-asserted when the SnapShot logic is reset via the GUI. The reset
is indicated by the macro’s Rstn out output signal. The reset will happen prior to arming, and again once
sample collection is completed successfully. A reset will also occur if the armed state is canceled via the
GUI.
The Stimuli signal is a 36-bit bus meant to send test stimulus to the design under test. Presently it is sent
once, when SnapShot is armed. The Stimuli is valid only while Arm is high, and will remain stable (the
stimuli will not change values) until SnapShot is reset. Note that Stimuli is currently limited, in that it uses
the same communication channel as the third sequential trigger pattern; this data is always interpreted as
both the third trigger pattern and as the value of Stimuli. Exercise caution when attempting to use all three
Triggers plus Stimuli during the same SnapShot arming session.
Example SnapShot Macro Instantiation
In the following example, we’ve connected the Design-Under-Test (DUT) to SnapShot. The example shows
the SnapShot outputs (Stimuli, Arm, and Rstn out ) being used by the DUT to cause test behavior.
If the user only wants to trace existing signals, and not cause specific behavior changes through the
debugger, then the SnapShot outputs Stimuli, Arm, and Rstn out may safely be left floating.
Verilog Instantiation:
1
///////// V e r i l o g Module f o r Top−Level Design Example with SnapShot Macro ////////////
2
///////// as w e l l as Users Design b l o c k . This example w i l l guide t h e u s er how //////
3
///////// t o implement SnapShot macro with User ’ s Logic b l o c k . ///////////////////////
4
5
module u s e r d e s i g n w i t h s n a p s h o t ( i np ut
t c k
6
, in pu t
t r s t n
7
, in pu t
tms
8
, in pu t
t d i
9
, output tdo
10
, in pu t
u s r c l k
11
, in pu t
u s r r s t n
12
) ;
13
parameter MNTR WIDTH = 7 2 ;
14
///// This above parameter should be v a r i e d ( 3 6 , 7 2 , 1 0 8 , 1 4 4 ) depending on t h e number
15
///// o f u s e r s i g n a l s t o be monitored
16
17
parameter DUTNAME = ” u s e r s l o g i c b l o c k i n s t a n c e ” ;
18
///// This should match t h e user ’ s module name .
19
20
parameter OUTPUTPIPELINING = 3 ;
21
///// S i n c e we a r e using t h e SnapShot outputs S t i m u l i , Arm , and R s t n o u t i n
22
///// u s e r s l o g i c t o d r i v e behavior , we should s e t t h i s t o a value g r e a t e r
23
///// than 0 .
S e v e r a l v a l u e s may need t o be t r i e d b e f o r e d i s c o v e r i n g t h e
24
///// optimal b a l a n c e o f timing c r i t i c a l i t y and SnapShot a r e a .
25
26
wire [ MNTR WIDTH− 1 : 0 ] monitor ch ; / / / / / These s i g n a l s w i l l be monitored i n SnapShot ,
27
///// with [ 7 1 : 3 6 ] captured , and [ 3 5 : 0 ] captured
28
///// and s e n t t o t r i g g e r −d e t e c t o r b l o c k s as
29
///// t r i g g e r c h
30
wire [ 3 5 : 0 ] s t i m u l i ; / / / / / S i g n a l providing t e s t s t i m u l i t o u s e r l o g i c from SnapShot
31
wire r s t n o u t ; / / / / / S i g n a l i n d i c a t e s SnapShot i s r e s e t t i n g
287
UG001 Rev. 5.0 - 5th December 2012