Achronix ACE Version 5.0 Manual de usuario descargar pdf (Pagina 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 speciﬁcation 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 ﬂoating.

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 speciﬁc behavior changes through the

debugger, then the SnapShot outputs Stimuli, Arm, and Rstn out may safely be left ﬂoating.

Verilog Instantiation:

1 /// ////// Ve r ilo g Module f o r Top−Level Design Example with SnapShot Macro ////////////

2 /// ////// as well as Users Design blo c k . T his example w il l guide the u ser how //////

3 /// ////// t o implement SnapShot macro with User ’ s Logic b lock . ///////////////////////

5 module u se r d e si g n w it h s n ap s h o t ( i nput t c k

6 , in put t r s t n

7 , in put tms

8 , in put td i

9 , output tdo

10 , in put us r c l k

11 , in put us r r s t n

12 ) ;

13 parameter MNTR WIDTH = 7 2 ;

14 ///// This above parameter should be v aried ( 3 6 , 7 2 , 1 0 8 , 1 4 4 ) depending on t h e number

15 ///// of u ser s i g n a l s to be monitored

17 parameter DUTNAME = ” us 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 the user ’ s module name .

20 parameter OUTPUTPIPELINING = 3 ;

21 ///// Sin c e we are using the SnapShot o utputs St i m u l i , Arm , and Rs t n o u t in

22 ///// u s e r s l o g i c t o dr i v e behavior , we should s e t t h i s to a value g r e a t e r

23 ///// than 0 . S e ve r a l values may need to be tr i e d bef o r e d i s co v e ri n g th e

24 ///// optima l balan c e of tim ing c r i t i c a l i t y and SnapShot a r e a .

26 wire [MNTR WIDTH− 1 : 0 ] moni tor ch ; / / / / / These si g n a l s w i l l be monitored in SnapShot ,

27 ///// with [ 7 1 : 3 6 ] captured , and [ 3 5 : 0 ] captured

28 ///// and s en t to t r i g g e r −d e t e c t o r b l o cks as

29 ///// t r i g g e r c h

30 wire [ 3 5 : 0 ] st i m u l i ; / / / / / S i g n a l providin g t e s t s t i m u l i to 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 http://www.achronix.com UG001 Rev. 5.0 - 5th December 2012

1 2 ... 294 295 296 297 298 299 300 301 302 303 304 ... 388 389

Achronix ACE Version 5.0 Manual de usuario Pagina 299

Comentarios a estos manuales

Achronix ACE Version 5.0 Manual de usuario Pagina 299

Comentarios a estos manuales

Relacionado con productos y manuales para Hardware De La Computadora Achronix ACE Version 5.0