[MPC5777C] Understanding the instruction pipeline of the e200z759n3 core

[MatheusFranklin]

Hello!

While studuing the instruction execution path of the e200z759n3 core I came up with the following questions:

1. It seems that the e200z7 core reference manual is not very consistent about the pipeline execution units contents. In figure 17, the Integer Execution Units and the Multiply Units are separated. However, section “4.2.1 Integer execution units” covers integer multiplication and division. Section “4.6 Concurrent instruction execution” mentions the existence of “Dual scalar integer units”, but do not mention any Multiply unit. I believe that the core has two Integer Execution Units that can perform any integer operations (e.g., sum, multiplication, division). Is my conclusion correct? Can two multiplications execute simultaneously by the dual-issue pipeline?
2. I drew the following diagram to illustrate the pipeline execution flow and better understand it based on the reference manual. Did I misunderstood any concept?

Best regards,

Matheus

[davidtosenovjan · Accepted solution]

1) I don't think it would be anyhow separate from execution unit, it is just its part:

2) I cannot confirm it is exactly how you sketched it, but in principle, that is certainly correct and it fits to pipeline stages:

I could recommend following presentation that could be easier to read that e200 manuals:

https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/e200-Core-Training-relevant-to-MPC55xx-and-MPC56...

[MatheusFranklin]

Thanks for the reply, David!

A few more questions:

1. Since the pipeline has dual-issue capabilities and the execution unit has two integer units, it could start the fetch stage of two independent integer multiply or integer divide instructions at the same clock cycle?
2. When a simple instruction like an addition executes, the manual says that it finishes the execution stage in one clock cycle. Does the WB stage come in the clock cycle immediately after the E0 stage or does it have to wait three more idle clock cycles, like it had to add an idle padding to complete the entire IF0 to WB cycle using all 10 stages of the pipeline?
3. When there is data dependency between two instructions, the destination instruction starts its execution stage in the same clock cycle as the last execution stage of the source instruction or does it have to wait for the next clock cycle? I did not understand clearly how the feedfoward works.
4. Since it is the decode phase that checks for data dependencies between instructions, is it correct to conclude that all pipeline stalls occur between the D1 and E0 pipeline stages?

Best regards,

Matheus

[davidtosenovjan]

1) Certainly yes, this picture is related to e200z4 that is also dual issue

2) It is dependent on pipeline content itself. You can see it on the picture in previous answer. First instruction is short, it does not cause any stalls to another one. Second instruction is long, it causes stalls as third instruction depends on result of second instruction.

3) It’ll have to wait.

4) Basically yes. Here it can be affected also by compiler optimizations level where compiler may change order of instructions for better use of dual issue architecture (i.e. instruction scheduling) for highest level of optimization.

[MatheusFranklin]

Hello!

Going back to the pipeline padding question. If there is no padding to fill all four execution stages like the image that you sent shows, why does the reference manual diagrams shows a "FF" padding? Is not the diagram of the presentation a simplified version?

Presentation diagram without padding:

Reference manual diagrams with padding:

Best regards,

Matheus

[davidtosenovjan]

FF means fead-forward and it is not the same as STALL. I would recommend to see also e200z6 RM as it is older core variant and some topic are described a bit different way, possible more understadable.

https://www.nxp.com/webapp/Download?colCode=E200Z6RMAD&location=null

Yes, presentation may be simplified, I don't see to much difference.

[MatheusFranklin]

Hello, David!

To understand memory dependence in the instruction pipeline, I built the timing diagram for the following code snippet with dependency related to r6:

mtctr r5
.loop:
   e_addi r6, r6, 1
   e_mulli r6, r6, 1
e_bdnz .loop

However, while building the diagram (attached to this reply), I noticed that although the throughput remains constant, the instruction execution latency increases by two cycles each iteration, not seeming to have an upper bound. Did I miss something? Does the pipeline have a maximum number for instructions held in stall?

Feel free to point any other mistakes in my diagram.

Best regards,
Matheus

[davidtosenovjan]

I think it could be correct, latency specified to multiply operation is 3 or 4 cycles what you have there (every 4 cycles you have result). This situation is extreme worst case where all operations are dependent of result of previous one, additionally running in the loop, which essentially leads to the complete elimination of the pipeline. It works essentially the same as if it were completely pipelineless.

[MatheusFranklin]

Hello!

It seems that the number of instructions held in stall keeps increasing by two every loop iteration.

1. Does the pipeline have a limit for the number of stalled instructions?
2. Are they stored in some buffer?
3. If so, how many entries does this buffer have?
4. Is this somehow related to the issue buffer?
5. If the stalled instructions are held in some buffer, what happens when this buffer is full and one more instruction is stalled?

Best regards,

Matheus

[davidtosenovjan]

I think what is actually wrong in your diagram is that you are always starting from left side. I am not sure if I am able to explain is understandable way..

Using picture for e200z6 manual, after instruction buffer, there is instruction register (marked) and after that there is decode stage. When there are stalls in Execution units, it means that also instructions in the instruction buffer cannot be decoded when they cannot be put into subsequent stage.

Ideally you could consider exact status of every unit in certain points. Anyway it does not matter where you put stalls in your diagram as it always leads into same performance as a result.

Performance is limited by bottlenecks in pipeline what it is in this case stalls in EU units, influencing the system as a whole.

I am not sure if it helps. Anyway why you need to know such exact details?

Real code cannot be analyzed this way anyway, for this purposes there are tools as performance monitors, debug trace and so.

[MatheusFranklin]

Hello, David!

I am studying how inter-core interactions via shared hardware impact on execution time and resource consumption. I used performance monitors for some validation, but I could not understand my results and now I do. Thank you very much for the clarification!

Best regards,
Matheus