-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[discuss] Why are more MDO bits not considered? #43
Comments
Hi @albertschulz - forgive me being quiet. I've seen your post, but I just now switched my RVI identify to MIPS. It is a bit too late to discuss this change - we consider this option as one of future extensions. Main reason was simplicity as very first byte will include TCODE. Also decoder (in SW) will not require very tedious shifting of everything. Now you have 2/8=25% 'waste' and with 32-bit you would have 6.25%. Also having two adjacent variable size fields (say I-CNT and HIST), you will waste a lot of bits. Let's assume you have I-CNT=1000 and HIST=30-bit. With 8-bits you will have: I-CNT will fit into 2 bytes and HIST will need 5 bytes. Total is 7. If you have TSTAMP (following I-CNT and U-ADDR), you will end-up to use 30-bits (4 bytes) for small U-ADDR. Above examples are a bit of trivialization but provides general idea. Simply running bigger busses is not always most efficient way to transport passengers 😄. Once N-Trace is ratified, I will play with reference decoder and try to generate 32-bit records. |
Hi @albertschulz - part of cleanup of all open topics ... Me and @jgamoneda discussed this. Nothing will be done now. I will NOT close this issue until I will add an option (to reference code ...) to generate 2+6/2+14/2+30 variants and see what is the 'hit'. If it proves to be 'better', then we can always add this in 'v2' of N-Trace. Let's first ratify a version 1.0.0! |
An increase of MDO are discouraged in the documentation:
https://github.com/riscv-non-isa/tg-nexus-trace/blob/master/docs/RISC-V-N-Trace.adoc?plain=1#L1858
Currently, you use 2 MSEO & 6 MDO Bits. Which results in a 25% bandwidth overhead.
In my opinion, a 2 MSEO / 30 MDO Bit configuration, would be way more bandwidth optimal. The average message size is definitely above 32 bit, as it contains at least TCode, and often a 32-Bit HIST field or an address.
I would be happy for a discussion and learn more about the motivation against this change.
The text was updated successfully, but these errors were encountered: