Hi, What's the interface to the scratchpad? Are you adding new ISA extensions, or is it a memory-mapped device. If it's a memory-mapped device, you should be able to connect it to the CPU via the ports interface. Something like add a crossbar between the CPU and the L1D and have the L1D only respond to a subset of physical addresses and your scratchpad respond to the other physical addresses.
If you're adding ISA extensions... I doubt you're going to convince us to modify an ISA with non-standard extensions. I guess my question is this: In a real implementation, what would the interface be, and how much would you really need to modify the CPU implementation? Again, it's best if you can find a way to decouple the interface from a specific CPU implementation as much as possible. The idea of a scratchpad is definitely interesting, and if we can find a way to integrate your code as an optional device I think it would be good to have in gem5! Cheers, Jason On Wed, Oct 26, 2016 at 8:09 AM Pierre-Yves Péneau < [email protected]> wrote: > Hi Jason, > > On 10/26/2016 12:27 AM, Jason Lowe-Power wrote: > > Hello, > > > > Could you give us some more details on what you're proposing. What is > this > > "component"? Do you expect that many people in the community will > need/want > > to use this component? If so, then it may make sense to incorporate some > > changes to the BaseCPU object. > > I would like to implement a generic scratchpad memory (SPM) module. For > sure, not everyone will use these feature, but it's something lacking in > gem5 (other simulator also). SPM are under investigation in the > electronic research community for many years and I can't find a > reasonably good implementation on the web. > > For now I am using an homemade implementation in gem5 but it's not clean > enough to be published. I am thinking of refactoring my code and propose > it to the community. > > > The way I see it is you have three high-level options: > > 1) Make changes to the BaseCPU. This will likely be the most work to get > > the community to accept. Unless it's a change that almost everyone will > be > > using, I doubt we will want to incorporate it. > > 2) Make your changes very modular. Modular in the sense that if someone > > wants to use gem5 without using your new component they'll never knew you > > added it. This should be more that just adding a default "off" parameter. > > The key goal is to be the least invasive as possible. > > 3) Post your code on a fork of gem5. Sometimes you have to make major > > modifications to central components to complete your research objective. > In > > this case, it may be better just to post your code somewhere like github. > > Or to go the route we did with gem5-gpu and make it an "external" > > component. Though this has the drawback of trying to keep it up to date > > with the mainline. > > Thanks for the advices. > > > In conclusion, if you can give us more information we'll be able to guide > > you better. > > > > Cheers, > > Jason > > > > On Tue, Oct 25, 2016 at 9:29 AM Pierre-Yves Péneau < > > [email protected]> wrote: > > > >> Hi all, > >> > >> I would like to add a new hardware component in gem5. This component > >> will be at the same level than L1 caches. I am planning to modify the > >> base cpu to add a new port and use it to communicate with my component. > >> > >> Eventually, I would like to share my work with the gem5 community. > >> Louisa Bessad (from my lab) had a discussion with Gabor Dozsa from ARM > >> and told me that any modification to the base cpu must be strongly > >> justified to the developers, and so could be very hard to merge in gem5. > >> > >> So, my questions are: > >> - can I do what I want without modifying the base cpu ? > >> - if not, what are the chances that my work will be accepted ? > >> > >> Thank you all. > >> > >> -- > >> +-------------------------------------------------------------+ > >> | Pierre-Yves Péneau - PhD student | first.last at lirmm.fr | > >> | LIRMM / CNRS - SYSMIC team | + 33 4 67 41 86 33 > <+33%204%2067%2041%2086%2033> > >> <+33%204%2067%2041%2086%2033> | > >> | Building 4 Office H2.2 | http://walafc0.org | > >> +-------------------------------------------------------------+ > >> _______________________________________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > >> > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > -- > +-------------------------------------------------------------+ > | Pierre-Yves Péneau - PhD student | first.last at lirmm.fr | > | LIRMM / CNRS - SYSMIC team | + 33 4 67 41 86 33 > <+33%204%2067%2041%2086%2033> | > | Building 4 Office H2.2 | http://walafc0.org | > +-------------------------------------------------------------+ > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
