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?
GEMS does transfer the message in a 'bulk' at a time. If you want to
know the bit length, you can look at the protocol and the system
configuration and come up with your own bit lengths for your
calculations. But as Mike said, GEMS doesn't care about the individual
field lengths. It assumes that the control information can be fit into
the 8 bytes and seems to be a fair assumption.
How does the new network model deal with the messages? Do you have any
idea about this?
In the detailed network, although the messages will be broken into
network level units, I do not think the fields will be mapped
separately. Actually the latency of packet delivery is not dependent on
these fields.
Thanks,
Lide
On 1/17/08, *Niket* <niketa@xxxxxxxxxxxxx
<mailto: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 <mailto: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 <mailto: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.
|