@MSGID: Hih7.154829@fx11.iad>
1ef52c5b
@REPLY: 1@dont-email.me> b288ea7e
@REPLYADDR EricP
<ThatWouldBeTelling@thevillage.com>
@REPLYTO 2:5075/128 EricP
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<6zCRM.67038$fUu6.58754@fx47.iad> 1@dont-email.me>
@RFC-Message-ID:
Hih7.154829@fx11.iad>
@TZUTC: -0400
@PID: Thunderbird 2.0.0.24 (Windows/20100228)
@TID: FIDOGATE-5.12-ge4e8b94
BGB wrote:
> On 9/29/2023 11:02 AM, EricP wrote:
>> BGB wrote:
>>> I recently had an idea (that small scale testing doesn`t require 
>>> redesigning my whole pipeline):
>>> If one delays nearly all of the operations to at least a 2-cycle 
>>> latency, then seemingly the timing gets a fair bit better.
>>>
>>> In particular, a few 1-cycle units:
>>>   SHAD (bitwise shift and similar)
>>>   CONV (various bit-repacking instructions)
>>> Were delayed to 2 cycle:
>>>   SHAD:
>>>     2 cycle latency doesn`t have much obvious impact;
>>>   CONV: Minor impact
>>>     I suspect due to delaying MOV-2R and EXTx.x and similar.
>>>     I could special-case these in Lane 1.
>>>
>>>
>>> There was already a slower CONV2 path which had mostly dealt with 
>>> things like FPU format conversion and other "more complicated" format 
>>> converters, so the CONV path had mostly been left for operations that 
>>> mostly involved shuffling the bits around (and the simple case 
>>> 2-register MOV instruction and similar, etc).
>>>
>>> Note that most ALU ops were already generally 2-cycle as well.
>>>
>>>
>>> Partly this idea was based on the observation that adding the logic 
>>> for a BSWAP.Q instruction to the CONV path had a disproportionate 
>>> impact on LUT cost and timing. The actual logic in this case is very 
>>> simple (mostly shuffling the bytes around), so theoretically should 
>>> not have had as big of an impact.
>>>
>>>
>>> Testing this idea, thus far, isn`t enough to get the clock boosted to 
>>> 75MHz, but did seemingly help here, and has seemingly redirected the 
>>> "worst failing paths" from being through the D$->EXn->RF pipeline, 
>>> over to being D$->ID1.
>>>
>>> Along with paths from the input to the output side of the instruction 
>>> decoder. Might also consider disabling the (mostly not used for much) 
>>> RISC-V decoders, and see if this can help.
>>>
>>> Had also now disabled the LDTEX instruction, now as it is "somewhat 
>>> less important" if TKRA-GL is mapped through a hardware rasterizer 
>>> module.
>>>
>>>
>>> And, thus far, unlike past attempts in this area, this approach 
>>> doesn`t effectively ruin the performance of the L1 D$.
>>>
>>>
>>> Seems like one could possibly try to design a core around this 
>>> assumption, avoiding any cases where combinatorial logic feeds into 
>>> the register-forwarding path (or, cheaper still, not have any 
>>> register forwarding; but giving every op a 3-cycle latency would be a 
>>> little steep).
>>>
>>> Though, one possibility could be to disable register forwarding from 
>>> Lane 3, in which case only interlocks would be available.
>>> This would work partly as Lane 3 isn`t used anywhere near as often as 
>>> Lanes 1 or 2.
>>>
>>> ....
>>>
>>>
>>>
>>> Any thoughts?...
>>
>> Its not just the MHz but the IPC you need to think about.
>> If you are running at 50 MHz but an actual IPC of 0.1 due to
>> stalls and pipeline bubbles then that`s really just 5 MIPS.
>>
> 
> For running stats from a running full simulation (predates to these 
> tweaks, running GLQuake with the HW rasterizer):
>   ~ 0.48 .. 0.54 bundles clock;
>   ~ 1.10 .. 1.40 instructions/bundle.
> 
> Seems to be averaging around 29..32 MIPs at 50MHz (so, ~ 0.604 MIPs/MHz).

Oh that`s pretty efficient then.
In the past you had made comments which made it sound like
having tlb, cache, and dram controller all hung off of what
you called your "ring bus", which sounded like a token ring,
and that the RB consumed many cycles latency.
That gave me the impression of frequent, large stalls to cache,
lots of bubbles, leading to low IPC.

> Top ranking uses of clock-cycles (for total stall cycles):
>   L2 Miss: ~ 28%  (RAM, L2 needs to access DDR chip)
>   Misc   : ~ 23%  (Misc uncategorized stalls)
>   IL     : ~ 20%  (Interlock stalls)
>   L1 I$  : ~ 18%  (16K L1 I$, 1)
>   L1 D$  : ~  9%  (32K L1 D$)
> 
> The IL (or Interlock) penalty is the main one that would be effected by 
> increasing latency.

By "interlock stalls" do you mean register RAW dependency stalls?
As distinct from D$L1 read access stall, if read access time > 1 clock
or multi-cycle function units like integer divide.

> In general, the full simulation simulates pretty much all of the 
> hardware modules via Verilator (displaying the VGA output image as 
> output, and handling keyboard inputs via a PS/2 interface).
> 
> 1: The bigger D$ was better for Doom and similar, but GLQuake seems to 
> lean in a lot more to the I$. Switching to a HW rasterizer seems to have 
> increased this imbalance.
> 
> 
> At the moment, Doom tends to average slightly higher in terms of MIPs 
> scores.
> 
> 
> 
> As for emulator stats, the main instructions with high interlock 
> penalties are:
>   MOV.Q, MOV.L, ADD
> 
> MOV.Q and MOV.L seem to be spending around half of their clock-cycles on 
> interlocks, so around ~2 cycles average.

I assume these are memory moves, aka LD/ST.
In this context does interlock mean a source register RAW dependency stall?

> ADD seems to be spending around 1/3 of its cycles on interlock (the main 
> ALU ops already had a 2-cycle cost since early on).

IIUC you are saying your fpga takes 2 clocks at 50 MHz = 40 ns
to do a 64-bit add, so it uses two pipeline stages for ALU.

And by interlock you mean if an instruction following in the next 2 slots
reads that same dest register then it must stall at RR for 1 or 2 clocks,
(assuming you have a forwarding bus from ALU result to RR, otherwise more).

So 1/3 of ADD instructions have this dependency.
Is that correct?




--- Thunderbird 2.0.0.24 (Windows/20100228)
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441