-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2935/#review6658
-----------------------------------------------------------



src/mem/SerialLink.py (line 60)
<http://reviews.gem5.org/r/2935/#comment5752>

    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.



src/mem/serial_link.cc (line 146)
<http://reviews.gem5.org/r/2935/#comment5753>

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



src/mem/serial_link.cc (line 150)
<http://reviews.gem5.org/r/2935/#comment5754>

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



src/mem/serial_link.cc (line 155)
<http://reviews.gem5.org/r/2935/#comment5755>

    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.



src/mem/serial_link.cc (line 167)
<http://reviews.gem5.org/r/2935/#comment5756>

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



src/mem/serial_link.cc (line 201)
<http://reviews.gem5.org/r/2935/#comment5757>

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



src/mem/serial_link.cc (line 205)
<http://reviews.gem5.org/r/2935/#comment5758>

    Comments please :-)


- Andreas Hansson


On July 1, 2015, 10:32 a.m., Erfan Azarkhish wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2935/
> -----------------------------------------------------------
> 
> (Updated July 1, 2015, 10:32 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   src/mem/serial_link.hh PRE-CREATION 
>   src/mem/serial_link.cc PRE-CREATION 
>   src/mem/SerialLink.py PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/2935/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Erfan Azarkhish
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to