Prev: Picking N-th ready element (e.g. in an OOO scheduler)
Next: Lolling at programmers, how many ways are there to create a bitmask ? ;) :)
From: MitchAlsup on 29 Jun 2010 12:21
On Jun 29, 6:11 am, "nedbrek" <nedb...(a)yahoo.com> wrote:
> Hello all,
>
> "MitchAlsup" <MitchAl...(a)aol.com> wrote in message
> > I advocate actively pursuing the random ordering of pipestage
> > evaluation. This randomization exposes microarchitectural race
> > conditions.
>
> That's an interesting approach.  I feel it's too close to the RUU (unless I
> am misunderstanding).

Register Update Unit = RUU

I suspect you mean the Register Transfer Level (RTL) model

And yes, I am an advocate of a software simulator more detailed than
the architectural model and less detailed than the hardware
desctiptive model. In this simulator, one is proving out the control
machine in an environment where one can run those (several) trillion
cycles that one cannot in Verilog models.

Others are free to see this model as a distraction on the RTL model.
 
> I don't like having timestamps, except for debugging.
> I am of the camp "let there be a software structure for each hardware
> structure, and code for logic" (although parts of the memory and i/o system
> often devolve into timestamped queues, due to the enormous latencies).

But these hardware structures are (essentially) orchestrated by the
pipline sequencers. And this code hierarchy enables a straightforward
means to provide this orchestration.

> If there was one crazy new idea I'd want, it's the ability to run time
> backwards.  I can't count the number of times I was tracking down a bug, and
> stepped one cycle too far!

Entropy is against you. That is is is exceedingly difficult to undo
arithmetic operations that clobber register data, or writes to machine
registers.

The only means I have found is to barf out massive data dumps and
build another tool to sift through it.

Mitch

From: Andy 'Krazy' Glew on 29 Jun 2010 17:30
On 6/29/2010 4:11 AM, nedbrek wrote:

> For IPFsim, we had a nice infrastructure (using factories) to instantiate
> scheduler and execution frameworks. It supported in-order (for our McKinley
> comparisons), P3, P4, and HSW.

I believe that the Itanium IPFsim infrastructure did not accurately model OOO. At the very least there were questions
about its accuracy.
From: Andy 'Krazy' Glew on 29 Jun 2010 17:33
On 6/29/2010 7:27 AM, Muzaffer Kal wrote:
> On Tue, 29 Jun 2010 06:11:52 -0500, "nedbrek"<nedbrek(a)yahoo.com>
> wrote:
>>
>> If there was one crazy new idea I'd want, it's the ability to run time
>> backwards. I can't count the number of times I was tracking down a bug, and
>> stepped one cycle too far!
>
> Isn't this as easy as keeping the last N cycle/instruction states and
> reload?

Yes... but, the last N instruction states may be a lot to keep around.

A slightly different approach has been to periodically fork or checkpoint. UNIX fork creates a COW copy of a single
process simulator. Keep it around for N cycles - when you want to go back, go back, and step forward. Multiple times,
if need be.



From: nedbrek on 30 Jun 2010 05:11
Hello all,

"Andy 'Krazy' Glew" <ag-news(a)patten-glew.net> wrote in message
news:4C2A65F3.8080103(a)patten-glew.net...
> On 6/29/2010 4:11 AM, nedbrek wrote:
>
>> For IPFsim, we had a nice infrastructure (using factories) to instantiate
>> scheduler and execution frameworks. It supported in-order (for our
>> McKinley
>> comparisons), P3, P4, and HSW.
>
> I believe that the Itanium IPFsim infrastructure did not accurately model
> OOO.
> At the very least there were questions about its accuracy.

We had issues with our architectural model. It was unable to provide
stateless execution, which we needed for wrong path (I was working on one
when we finally decided to stop work on Itanium).

Wrong path issues are pretty well understood, it is unlikely we were facing
any significant wrong path effects - because we were basically retreading
historical OOO designs.

I agree that moving forward with radical new designs would require wrong
path.

Ned


From: nedbrek on 30 Jun 2010 05:21
Hello all,

"MitchAlsup" <MitchAlsup(a)aol.com> wrote in message
news:175c0f8b-92ed-46a6-8737-cb0db9c0b22e(a)z8g2000yqz.googlegroups.com...
On Jun 29, 6:11 am, "nedbrek" <nedb...(a)yahoo.com> wrote:
> "MitchAlsup" <MitchAl...(a)aol.com> wrote in message
>>> Andy had said:
>>>> To accomplish this, we connect the pipestages by queues or buffers (not
>>>> necessarily in order), and timestamp queue entries with the earliest
>>>> possible time that an entry can be consumed.
>>>
>>> I advocate actively pursuing the random ordering of pipestage
>>> evaluation. This randomization exposes microarchitectural race
>>> conditions.
>>
>> That's an interesting approach. I feel it's too close to the RUU (unless
>> I
>> am misunderstanding).
>
> Register Update Unit = RUU
>
> I suspect you mean the Register Transfer Level (RTL) model

My exposure to SimpleScalar is limited, but I believe the RUU is a big queue
with timestamps in it... my objection was to Andy's queue with timestamps.

In order for a random order to work, you need queues with timestamps - or
double buffering all the data shared between pipestages (then double pumping
the clock, with a read/write)... right?

Ned


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Picking N-th ready element (e.g. in an OOO scheduler)
Next: Lolling at programmers, how many ways are there to create a bitmask ? ;) :)