Closed rpadler closed 4 years ago
TileLink Spec v1.8.1 calls for a_code
Assume it is typo, fixing.
d_param
is present in TL-{UH, C}, and not present in TL-UL profile.
d_sink
is only present in TL-C profile. Has no meaning in TL-{UL, HL} profiles.
It looks like a typo since the next line in that table refers to a_opcode, which otherwise is not mentioned ;o(
Henry/Wes:
What’s this TL 1.8.1 spec that’s floating around? Can one of you confirm a_code as it as a typo? The equivalent table in 1.8 calls it a_opcode.
Thanks!
-Robbie
From: Aliaksei Chapyzhenka notifications@github.com Sent: Wednesday, September 16, 2020 2:20 PM To: sifive/duh-bus duh-bus@noreply.github.com Cc: Robbie Adler robbie.adler@sifive.com; Author < author@noreply.github.com> Subject: Re: [sifive/duh-bus] TL bus def issues (#31)
TileLink Spec v1.8.1 calls for a_code
[image: image] https://user-images.githubusercontent.com/511872/93393528-89f26a80-f827-11ea-827d-420d146dfb99.png
Assume it is typo
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sifive/duh-bus/issues/31#issuecomment-693671250, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANZ4FMEY2QVUL4O3E7H5XMLSGETWFANCNFSM4QUG2QGQ .
All I know is that our TL xbar generates this signal for the interface that we get from a TL_Fuzzer.
It’s also not clear from the spec whether the signal doesn’t actually exist in all profile – or whether it just gets tied off. I read it as being tied off in most cases.
Henry/Wes – could you clarify when this signal exists?
Thanks!
-Robbie
From: Aliaksei Chapyzhenka notifications@github.com Sent: Wednesday, September 16, 2020 2:23 PM To: sifive/duh-bus duh-bus@noreply.github.com Cc: Robbie Adler robbie.adler@sifive.com; Author < author@noreply.github.com> Subject: Re: [sifive/duh-bus] TL bus def issues (#31)
d_param is present in TL-{UH, C}, and not present in TL-UL profile.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sifive/duh-bus/issues/31#issuecomment-693672694, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANZ4FMBEG276YXMDN4KHT7DSGEUCRANCNFSM4QUG2QGQ .
It's a typo. a_opcode always exists for the conformance levels defined in the spec. a_code is never a thing. 1.8.1 is the current version; why the top google hit for "tilelink" still returns the 1.8.0 spec from our own website almost a year after releasing 1.8.1 is a mystery to me. Between 1.8.0 and 1.8.1 the spec was converted to ASCIIDoc. The source of the spec is controlled in arch-specs now, I think this is it: https://github.com/sifive/arch-specs/blob/master/tilelink_spec.adoc. Poking around it looks like that is just a one-off error and all other references are to x_opcode so I am not sure how that one snuck in.
On Wed, Sep 16, 2020 at 8:29 PM Robbie Adler robbie.adler@sifive.com wrote:
All I know is that our TL xbar generates this signal for the interface that we get from a TL_Fuzzer.
It’s also not clear from the spec whether the signal doesn’t actually exist in all profile – or whether it just gets tied off. I read it as being tied off in most cases.
Henry/Wes – could you clarify when this signal exists?
Thanks!
-Robbie
From: Aliaksei Chapyzhenka notifications@github.com Sent: Wednesday, September 16, 2020 2:23 PM To: sifive/duh-bus duh-bus@noreply.github.com Cc: Robbie Adler robbie.adler@sifive.com; Author < author@noreply.github.com> Subject: Re: [sifive/duh-bus] TL bus def issues (#31)
d_param is present in TL-{UH, C}, and not present in TL-UL profile.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sifive/duh-bus/issues/31#issuecomment-693672694, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANZ4FMBEG276YXMDN4KHT7DSGEUCRANCNFSM4QUG2QGQ .
-- /Henry
fixed in dfb5fe8be01a4cc91b3f2ee8164720e7f437c56f v0.10.0