@MSGID: 1@dont-email.me> b288ea7e
@REPLY: <6zCRM.67038$fUu6.58754@fx47.iad>
a9688659
@REPLYADDR BGB <cr88192@gmail.com>
@REPLYTO 2:5075/128 BGB
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<6zCRM.67038$fUu6.58754@fx47.iad>
@TZUTC: -0500
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
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).


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.

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.

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).



The SHxD.x operators were increased to 2 cycles by this change, but are 
generally a bit further down the list so that they don`t hurt as much.

I did notice an increase in time spent in the millisecond counters on in 
the boot-up sequence, but this seems mostly due to the CONV operations.


This appears most likely due to the "2 register MOV" instruction, which 
itself uses around 3% of the total cycle budget (as a 1-cycle op), so 
likely isn`t helped by being demoted to 2-cycles.

I may need to add a special case here to allow either for "MOV" 
specifically, or a subset of CONV ops (such as MOV and Sign/Zero 
extension) to remain as 1-cycle ops (EXTS.L and EXTU.L often being used 
in place of MOV for "int" and "unsigned int" to make sure they remain 
properly extended).


> I don`t know what diagnostic probes you have. I would want to see
> what each stage is doing in real time as it single stepped each clock,
> see which stage buffers are valid or empty,
> where stalls are originating and propagating.
> Essentially the same info a cycle accurate simulator would show you.
> 

I have my emulator, which I try to keep cycle-accurate (though, it 
hasn`t been updated for this tweak yet).

It doesn`t display any real-time information, but rather a big mess of 
stats dumping at the end.


> That information can be used to guide where, for example,
> a limited budget of forwarding buses or extra 64-bit adders
> might best be utilized to eliminate bubbles and increase the IPC.
> 
> If whole-pipeline stalls are eating your IPC then maybe it doesn`t
> need elastic buffers on all stages, but maybe on just one stage
> after RR to decouple the MEM stalls from IF-ID-RR stages.
> 

I had considered possibly redesigning the pipeline at one point to allow 
a different mechanism for handling L1 misses. Namely marking registers 
for missed loads as "not ready" and then stalling the Fetch/Decode 
stages if the bundle would depend on a not-ready register (injecting the 
fetched data back into the pipeline once the load completes).

However, redesigning the main pipeline would not be a small task.



However, as-is, my fiddling still falls well-short of being able to 
boost the clock-speed to 75MHz.

Though, it looks like 75 MHz would be able to boost GLQuake mostly into 
double-digit territory (assuming I can do so without wrecking the L1 
caches or similar... which was always the problem in the past).


If the L1 caches are dropped to 2K or so, timing gets easier, but these 
have a significantly higher L1 miss rate and then most of the clock 
cycles end up going into dealing with L1 misses.

...

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: A noiseless patient Spider (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