mem: a serial link model for the HMC

Information
Submitter:	Erfan Azarkhish
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

SerialLink is simply a copy of gem5's Bridge class with the ability to account for serialization

latency of the packets. I did not inherit SerialLink from Bridge, because it required

some modifications in the Bridge.

This patch and the subsequent chain of patches aim to model a simple Hybrid Memory Cube device in gem5

Please apply the complete chain before running the simulation.

Testing Done

Issue Summary

Description	From	Last Updated	Status
Do we also need lane width? Lane signalling rate? No need to add right now, merely wondering if we should ...	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
I think we should really be paying for both, but do so on the request side, and here simply check ...	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
Could you add a comment here. What is it you are trying to model? De-serialisation?	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
We have added schedTimingResp with a boolean to force in-order insertion for coherency reasons. I can post that patch and ...	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
I would suggest we sink any packets with memInhibitAsserted here, and also any CleanEvicts (see other patches).	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
We should really pay for the serialisation delay from the crossbar here, and any headerDelay as well.	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open
Comments please :-)	Andreas Hansson	July 1, 2015, 8:19 a.m.	Open

src/mem/SerialLink.py (Diff revision 1)

Do we also need lane width? Lane signalling rate?

No need to add right now, merely wondering if we should not try and get these things in place.

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

May be the default value of 1 for this parameter is confusing. num_lanes means lane_width, and in the HMC.py script it is assigned to num_lanes_per_link which is 16 in HMC.
I can change its name or its default value if you say so.

src/mem/serial_link.cc (Diff revision 1)

I think we should really be paying for both, but do so on the request side, and here simply check that they are 0.

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

I agree that we should account for this delay, but since it will be a global change and it may break things, I suggest to address it in a separate patch.

src/mem/serial_link.cc (Diff revision 1)

Could you add a comment here. What is it you are trying to model? De-serialisation?

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

Yes exactly, I assume that the serializer component at the transmitter side does not need to receive the whole packet to start the serialization (this assumption is consistent with the standard). But the deserializer waits for the complete packet to check its integrity first. So everytime a packet crosses a serial link, we should account for its deserialization latency only.
I will added a comment for this line.

src/mem/serial_link.cc (Diff revision 1)

We have added schedTimingResp with a boolean to force in-order insertion for coherency reasons. I can post that patch and we can use the same thing here.

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)
```
That would be great.
```

src/mem/serial_link.cc (Diff revision 1)

I would suggest we sink any packets with memInhibitAsserted here, and also any CleanEvicts (see other patches).

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

Could you please explain more what is required? I took a look at other components and in the recvTimingResp() I did not see any sinking for the packets with memInhibitAsserted.

src/mem/serial_link.cc (Diff revision 1)

We should really pay for the serialisation delay from the crossbar here, and any headerDelay as well.

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

I agree, and would like to try to address this in a separate patch.

src/mem/serial_link.cc (Diff revision 1)

Comments please :-)

Show all issues

Erfan Azarkhish July 8, 2015, 12:42 a.m. (July 8, 2015, 12:42 a.m.)

This is similar to what happens for the request packets: The serializer will start serialization as soon as it receives the first flit, but the deserializer (at the host side in this case), will have to wait to receive the whole packet. So we only account for the deserialization latency.
I added a comment for this line.

Change Summary:

I have added comments. From now on, I will use MQ for my patches

Diff:

Revision 2 (+814)

Show changes

	src/mem/SerialLink.py
	src/mem/serial_link.hh
	src/mem/serial_link.cc

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Issue Summary

Change Summary:

Diff:

Status: Discarded