epu timing tool

[notzed]

I've been hacking on a tool which can be used to display some timing information about instruction sequences as shown in the last update on this post:

http://a-hackers-craic.blogspot.com.au/ ... -tool.html

If you used the spu-timing-tool from the IBM for the CELL B.E. the final output might be familiar. It works on object files (linked or not).

I have a super-rough pipeline which tracks the register dependencies and dual issue rules based on the arch ref and some testing on the hardware. I've not tried to implement the fetch logic as yet although this also affects dual-issue rates in ways i've yet to fully determine. At this point the intention is just as a static analysis tool but i'll see where the wind takes me.

I don't have a release package yet, I want to fix a few things and pretty up the output a bit first.

This topic is for any expressions of interest and discussion.

Update: I have now published a version here:
http://www.users.on.net/~notzed/software/ezetool.html

It's not complete but it might be useful or just interesting.

[aolofsson]

Very cool! This was another one of those projects that we always wanted to do..but somehow never got around to. Amazing to see you get something working in an afternoon! Let me know if there is anything I can help out with in terms of pipeline description so that you don't have to do too much reverse engineering.

Andreas

[timpart]

One thing I've never been clear on is, as the core is doing a sequence of instructions when does the start of the pipeline fetch a new double word of instructions from memory? Since an instruction can span a double word boundary presumably it must fetch a fresh double word in good time. Presumably this is connected with the enigmatic "". (Does B stand for buffer?) I'm curious as to how easy it is to avoid a clash if you want to do a load into a register from the same bank of memory.

Does the timing of when a double word fetch is started depend on whether its address is on or off core?

Presumably Dual Issuing is still possible if the other instruction is on the following double word?

Thanks in advance,

Tim

[aolofsson]

Tim,

The IAB is something I don't want to document too much, because it is likely to change (for the better) in future versions of the chip, but here are a few more details:

-The IAB works like a FIFO with a prefetch circuit that continuously brings in 64 bits from the memory whenever it can.

-Instructions get pulled out of the FIFO by the dual issue scheduling logic.

-Detecting FIFO full by the prefetch engine was a little tricky, considering that the "pull rate" depends on the instructions being single issue, double issue, 16/32.

-The IAB gets "flushed" on branches.

Notes:
-Align critical code sections on double word boundaries. (loop starts for example)
-Using 16 bit instructions help, since it's possible the IAB can fetch 4 instructions per clock cycle
-It is possible to load a word from same bank as instruction without suffering a penalty (but it depends on scenario)

Andreas

[shodruk]

spu_timing! I used to love it.

[timpart]

[notzed]

[aolofsson]

notzed,

Good catch!! I had forgotten about that "optimization". This was one of the critical path so I took some liberties, load stores work on register pairs.

For good measure, here is the complete decode logic Dual issue happens only if none of these conditions are true:
--RAW CODE

//load-->load
assign iab_waw_00_de = iab_op0_wr_rd0_write_de &
iab_op1_wr_rd0_write_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_wr_rd0_addr_de[RFAW-1:1]);

//load-->ialu/fpu
assign iab_waw_01_de = iab_op0_wr_rd0_write_de &
iab_op1_wr_rd1_write_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_wr_rd1_addr_de[RFAW-1:1]);

//ialu/fpu-->load
assign iab_waw_10_de = iab_op0_wr_rd1_write_de &
iab_op1_wr_rd0_write_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:1]==iab_op1_wr_rd0_addr_de[RFAW-1:1]);

//ialu/fpu-->ialu/fpu
assign iab_waw_11_de = iab_op0_wr_rd1_write_de &
iab_op1_wr_rd1_write_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:0]==iab_op1_wr_rd1_addr_de[RFAW-1:0]);

//ialu-fpu-->rn-read
assign iab_raw_10_de = iab_op0_wr_rd1_write_de & iab_op1_rd_rn_read_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:0]==iab_op1_rd_rn_addr_de[RFAW-1:0]);

//ialu-fpu-->rn-read
assign iab_raw_11_de = iab_op0_wr_rd1_write_de & iab_op1_rd_rm_read_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:0]==iab_op1_rd_rm_addr_de[RFAW-1:0]);

//ialu-fpu-->store
//note: matching on odd/even
assign iab_raw_12_de = iab_op0_wr_rd1_write_de & iab_op1_rd_rs_read_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:1]==iab_op1_rd_rs_addr_de[RFAW-1:1]);

//ialu-fpu-->acc-fpu
assign iab_raw_13_de = iab_op0_wr_rd1_write_de & iab_op1_rd_acc_read_de &
(iab_op0_wr_rd1_addr_de[RFAW-1:0]==iab_op1_rd_acc_addr_de[RFAW-1:0]);

//load-->rn-read
assign iab_raw_00_de = iab_op0_wr_rd0_write_de & iab_op1_rd_rn_read_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_rd_rn_addr_de[RFAW-1:1]);

//load-->rm-read
assign iab_raw_01_de = iab_op0_wr_rd0_write_de & iab_op1_rd_rm_read_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_rd_rm_addr_de[RFAW-1:1]);

//load-->store
assign iab_raw_02_de = iab_op0_wr_rd0_write_de & iab_op1_rd_rs_read_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_rd_rs_addr_de[RFAW-1:1]);

//load-->acc-fpu
assign iab_raw_03_de = iab_op0_wr_rd0_write_de & iab_op1_rd_acc_read_de &
(iab_op0_wr_rd0_addr_de[RFAW-1:1]==iab_op1_rd_acc_addr_de[RFAW-1:1]);

//store-->ialu/fpu write
assign iab_war_hazard_de = iab_op0_rd_rs_read_de & iab_op1_wr_rd1_write_de &
(iab_op0_rd_rs_addr_de[RFAW-1:1]==iab_op1_wr_rd1_addr_de[RFAW-1:1]);

[notzed]