@MSGID: <6zCRM.67038$fUu6.58754@fx47.iad>
a9688659
@REPLY: 1@dont-email.me> be752993
@REPLYADDR EricP
<ThatWouldBeTelling@thevillage.com>
@REPLYTO 2:5075/128 EricP
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
@RFC-Message-ID:
<6zCRM.67038$fUu6.58754@fx47.iad>
@TZUTC: -0400
@PID: Thunderbird 2.0.0.24 (Windows/20100228)
@TID: FIDOGATE-5.12-ge4e8b94
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.

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.

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.



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