> On Dec. 1, 2015, 5:31 p.m., Nilay Vaish wrote: > > src/cpu/o3/probe/elastic_trace.cc, lines 682-687 > > <http://reviews.gem5.org/r/3027/diff/3/?file=51963#file51963line682> > > > > Is this correct? Should not comp_delay = completionTick - > > executionTick . Secondly, the assert should be comparing the unsigned > > values as we discussed in another thread. > > Radhika Jagtap wrote: > Changing to assert per your suggestion. This is correct because the > completion_tick corresponds to inst A while execution_tick corresponds to > execute start tick of inst B that depends on A. > > Nilay Vaish wrote: > Clearly, I did not look close enough at the code. > > Anyways, now we should make comp_delay unsigned since comp_delay can > overflow as the difference can be > greater than 2^63-1.
Realistically the difference can't be greater than 2^63 - 1. If B depends on A the distance between them is at most 3 * ROB. Comp delay depends on this distance and the latency of functional units and is of the order of 10s of CPU cycles. We trace with fast memory and large ROB so really the core would never go into Idle state. On the other hand if tracing runs into some tricky code sequence that the modelling did not cover or if someone changes the O3 cpu behaviour, I want to trap insts for which the probe does not find a dependency (data or commit order or issue order). I do this by firing the 'comp delay initial value of -1' assert on line 808. > On Dec. 1, 2015, 5:31 p.m., Nilay Vaish wrote: > > src/cpu/o3/probe/elastic_trace.cc, line 857 > > <http://reviews.gem5.org/r/3027/diff/3/?file=51963#file51963line857> > > > > Is the post decrement of any use? > > Radhika Jagtap wrote: > You are right, not used. Got rid of it. > > Nilay Vaish wrote: > I can still see it. Fixed now. - Radhika ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3027/#review7656 ----------------------------------------------------------- On Dec. 4, 2015, 5:02 p.m., Curtis Dunham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3027/ > ----------------------------------------------------------- > > (Updated Dec. 4, 2015, 5:02 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > The elastic trace is a type of probe listener and listens to probe points > in multiple stages of the O3CPU. The notify method is called on a probe > point typically when an instruction successfully progresses through that > stage. > > As different listener methods mapped to the different probe points execute, > relevant information about the instruction, e.g. timestamps and register > accesses, are captured and stored in temporary InstExecInfo class objects. > When the instruction progresses through the commit stage, the timing and the > dependency information about the instruction is finalised and encapsulated in > a struct called TraceInfo. TraceInfo objects are collected in a list instead > of writing them out to the trace file one a time. This is required as the > trace is processed in chunks to evaluate order dependencies and computational > delay in case an instruction does not have any register dependencies. By this > we achieve a simpler algorithm during replay because every record in the > trace can be hooked onto a record in its past. The instruction dependency > trace is written out as a protobuf format file. A second trace containing > fetch requests at absolute timestamps is written to a separate protobuf > format file. > > If the instruction is not executed then it is not added to the trace. > The code checks if the instruction had a fault, if it predicated > false and thus previous register values were restored or if it was a > load/store that did not have a request (e.g. when the size of the > request is zero). In all these cases the instruction is set as > executed by the Execute stage and is picked up by the commit probe > listener. But a request is not issued and registers are not written. > So practically, skipping these should not hurt the dependency modelling. > > If squashing results in squashing younger instructions, it may happen that > the squash probe discards the inst and removes it from the temporary > store but execute stage deals with the instruction in the next cycle which > results in the execute probe seeing this inst as 'new' inst. A sequence > number of the last processed trace record is used to trap these cases and > not add to the temporary store. > > The elastic instruction trace and fetch request trace can be read in and > played back by the TraceCPU. > > > Diffs > ----- > > src/cpu/o3/probe/ElasticTrace.py PRE-CREATION > src/cpu/o3/probe/SConscript 651bf9238c117a5ec138b99ca28f0458ad278444 > src/cpu/o3/probe/elastic_trace.hh PRE-CREATION > src/cpu/o3/probe/elastic_trace.cc PRE-CREATION > src/proto/SConscript 651bf9238c117a5ec138b99ca28f0458ad278444 > src/proto/inst_dep_record.proto PRE-CREATION > src/proto/packet.proto 651bf9238c117a5ec138b99ca28f0458ad278444 > > Diff: http://reviews.gem5.org/r/3027/diff/ > > > Testing > ------- > > > Thanks, > > Curtis Dunham > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
