Brad, This how protocol trace would look like. I actually did not some such thing exists. I was currently relying on DPRINTF statements for checking the events that occurred. This is certainly easier to read and much more compact.
1395: system.l1_cntrl3: 1395 3 L1Cache L1_Replacement IM>IM [0x15c0, line 0x15c0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IM>IM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IM>IM [0x3ac0, line 0x3ac0] 1395: system.l1_cntrl2: 1395 2 L1Cache L1_Replacement IM>IM [0x3ac0, line 0x3ac0] 1396: system.l1_cntrl1: 1396 1 L1Cache L1_Replacement IM>IM [0x2ac0, line 0x2ac0] 1397: system.ruby.cpu_ruby_ports2: 1397 2 Seq Done > [0x3ae8, line 0x3ac0] 1386 cycles 1397: system.l1_cntrl2: 1397 2 L1Cache Data_all_Acks IM>M [0x3ac0, line 0x3ac0] 1397: system.l1_cntrl3: 1397 3 L1Cache L1_Replacement IM>IM [0x15c0, line 0x15c0] 1397: system.l2_cntrl0: 1397 0 L2CacheL2_Replacement_clean MT_MB>MT_MB [0x3ac0, line 0x3ac0] 1400: system.l2_cntrl0: 1400 0 L2Cache L1_GETX MT_MB>MT_MB [0x400, line 0x400] 1401: system.l2_cntrl0: 1401 0 L2CacheL2_Replacement_clean MT_MB>MT_MB [0x3ac0, line 0x3ac0] 1402: system.l1_cntrl0: 1402 0 L1Cache L1_Replacement IM>IM [0x4dc0, line 0x4dc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IM>IM [0xdc0, line 0xdc0] 1402: system.l1_cntrl2: 1402 2 L1Cache L1_Replacement IM>IM [0xdc0, line 0xdc0] On Wed, January 5, 2011 10:26 am, Beckmann, Brad wrote: > 1. Below is a snip of a protocol trace that I recently used. I > think it is important for us maintain that there is no DPRINTF information > prepended to each line. The initial motivation for the protocol trace, > was that tracing protocol transitions using standard debug print was too > verbose. These traces can be 100âMB if not GBs in size, so reducing the > information printed to each line is important. Nilay, could you send a > snip of the trace with the patch applied? > > 2233850 3 L1Cache Load I>IS [0x409ec0, line > 0x409ec0] > 2233850 3 L1Cache L2_Replacement M>MI [0x40cfc0, line > 0x40cfc0] > 2233866 3 L1Cache Writeback_Ack MI>I [0x10bd40, line > 0x10bd40] > 2233866 3 L1Cache Writeback_Ack MI>I [0x40cfc0, line > 0x40cfc0] > 2234458 3 Seq Done > [0x4033c3, line > 0x4033c0] 3380 cycles > 2234458 3 L1Cache Exclusive_Data IM>MM_W [0x4033c0, line > 0x4033c0] 0Directory-0 > 2234458 3 Seq Begin > [0x40f883, line > 0x40f880] ST > 2234459 3 L1Cache All_acks_no_sharers MM_W>MM [0x4033c0, line > 0x4033c0] > 2234508 3 L1Cache Exclusive_Data IS>M_W [0x409ec0, line > 0x409ec0] 0Directory-0 > 2234509 3 L1Cache All_acks_no_sharers M_W>M [0x409ec0, line > 0x409ec0] > 2234510 3 L1Cache L1_to_L2 MM>MM [0x4033c0, line > 0x4033c0] > 2234510 3 L1Cache Load I>IS [0x407ec0, line > 0x407ec0] > 2234510 3 L1Cache L2_Replacement M>MI [0x40b4c0, line > 0x40b4c0] > 2234510 3 L1Cache L1_to_L2 M>M [0x409ec0, line > 0x409ec0] > 2234510 3 L1Cache Load I>IS [0x100c40, line > 0x100c40] > 2234510 3 L1Cache L2_Replacement MM>MI [0x4033c0, line > 0x4033c0] > > > > 2. Just for my own knowledge⦠Nate, you mentioned that handling > the SIGABRT signal is the right way to make this feature work for all of > M5. Why is that? Is it just the preference not to use macros that > overwrite the meaning of assert, or is it something more fundamental? > > Thanks, > > Brad > > From: Nilay Vaish [mailto:ni...@cs.wisc.edu] > Sent: Tuesday, January 04, 2011 7:24 PM > To: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert > Cc: Nilay Vaish; Default; Beckmann, Brad > Subject: Re: Review Request: ruby: get rid of ruby's Debug.hh > > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/367/ > > > > On January 4th, 2011, 4:31 p.m., Brad Beckmann wrote: > > Hi Nate, > > > > I have a couple questions: > > > > 1. Have you looked at the protocol trace output after your change? Does > it look exactly like it did before? It seems that the output should be > the same based on my brief inspection of your patch, but I would like to > be sure about that. It may not be obvious, but there is a specific > rational behind the format of the protocol trace and I want to make sure > that stays the same. > > > > 2. With your patch applied, what happens if one hits an assert when > running interactively? Previously, the process would abort allowing one > to attach gdb and examine what is going on. I liked that feature and it > would be great if we could maintain it. Could we port that feature to all > of M5? > -- Nilay _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
