Hey folks! I've been looking at some device models recently, both to fix
them and to develop them, and I've seen a lot of boilerplate code which
tries to figure out what size of data to extract from the packet, how to
map that to registers, sometimes handling accesses that aren't on register
boundaries, sometimes handling partial register writes/reads, etc. It's a
real mess much of the time, and I think people usually write some code
that's stretched juuuuuuuust far enough to cover the way, for instance, a
Linux kernel driver pokes at their device.

To simplify that boiler-plate and to make device models significantly more
robust in general, I thought it would be a good idea to add a RegisterBank
abstraction which collects a contiguous bunch of registers together. It
figures out what registers are touched by an access, and divies up the
access to send the right data to the right registers, aligned to their base
offset and expanded to their full size. The registers themselves by default
act as dumb storage locations, but it's easy to add callbacks which let
them implement whatever behavior they need to on reads or writes, or to
mark some/all bits as read only. Partial reads/writes are handled
automatically with masking and read/modify/write operations for reads, but
that can be overridden too. The registers can be different sizes, have no
alignment requirements, and can have arbitrary endianness, although the
will have a default based on the settings of their containing RegisterBank.

I have this written up, and with the very VERY limited testing I've done so
far it seems to work. I think tomorrow I'll continue working on a unit
test, and you should hopefully see a review in the not too distant future.

Suggestions welcome, mostly I wanted to give people the 10 second elevator
pitch before tossing another review on the pile!

Gabe
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to