Thanks for the reply, Niket.
Actually I don't need the bit-level "values", but I want to know the bit length of each field in a message. For example, a control message possibly contains requester ID, destination ID, some flags, ect, and I am wondering how to know the bit length of each of these fields. In other words, I want to know the "format" of a message. As you mentioned, it depends on the protocol. To my understanding, GEMS treats a message as a "bulk" structure,
i.e. it defines the contents of a message, but transmits it as a whole thing (8 bytes or 64+8 bytes). Am I right?
How does the new network model deal with the messages? Do you have any idea about this?
Thanks,
Lide
On 1/17/08, Niket <niketa@xxxxxxxxxxxxx> wrote:
Hi Lide,
The control messages are all 8 bytes but are dynamically casted depending on the protocol. For instance, a request message might be a token request in a token coherence protocol or an invalidation in a
directory protocol. You can figure that out by making minor modifications.
The data messages are basically 64 byte cache lines + 8 byte control information. If you are looking for data values, I am not sure whether
Ruby carries the data values around. From what I understand, it is a timing interface and hence cache line values do not fly around. I remember reading some old posts mentioning that some previous version had the interface but I am not sure it is any longer present.
But why do you need these bit-level values ? I presume you want to do some power calculations ?
As regards the detailed network model inside GEMS, it should be out pretty soon.
Regards, Niket
Lide Duan wrote: > Hi everyone, > > I am wondering if there is any bit-level configuration/analysis of the > messages traversing across the on-chip network in GEMS. I notice that, > for the various on-chip messages, GEMS specifies the control message
> as 8 bytes and the data message as 64+8 bytes, but I need more > detailed information about what these bytes/bits should be. I also > notice that, for each protocol, there is a file that specifies the
> message structures used in this protocol, but it does not contain the > bit length information. > > Besides, I am also wondering when the next version GEMS that > incorporates a detailed network model will be released. I am quite
> expecting it. > > Thanks, > Lide > ------------------------------------------------------------------------ > > _______________________________________________ > Gems-users mailing list
> Gems-users@xxxxxxxxxxx > https://lists.cs.wisc.edu/mailman/listinfo/gems-users > Use Google to search the GEMS Users mailing list by adding "site:
https://lists.cs.wisc.edu/archive/gems-users/" to your search. > >
_______________________________________________ Gems-users mailing list
Gems-users@xxxxxxxxxxx https://lists.cs.wisc.edu/mailman/listinfo/gems-users Use Google to search the GEMS Users mailing list by adding "site:
https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|