search

openhwgroup / core-v-xif

RISC-V eXtension interface that provides a generalized framework suitable to implement custom coprocessors and ISA extensions
https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/en
Other
53 stars 23 forks source link

[Review Comment]: X_ISSUE_REGISTER_SPLIT definition #182

Closed ntribie-bosch closed 3 months ago

ntribie-bosch commented 3 months ago

Comment

As far as I understand, X_ISSUE_REGISTER_SPLIT is a parameter defined by the CPU implementation, and passed to the coprocessor.

When X_ISSUE_REGISTER_SPLIT=0 : “In this case, the CPU will speculatively provide all possible source registers” : I guess that if the provided registers value were wrong , the CPU will send a kill request to the coprocessor using the x_commit_t interface ?

When X_ISSUE_REGISTER_SPLIT=1 . How does the CPU supporting this mode can know that “ the coprocessor is able to accept multiple issue transactions before receiving the registers “ ? It would be nice if the coprocessor could have a signal / parameter to restrict this behavior to the ISSUE_REGISTER_SPLIT=0 mode , for back compatibility reasons. That is, getting the instruction and its operands values at the same time , at the expense of performance.

Proposed Resolution

N/A

Addition Info

N/A

christian-herber-nxp commented 3 months ago

_ISSUE_REGISTER_SPLIT=0 : “In this case, the CPU will speculatively provide all possible source registers” : I guess that if the provided registers value were wrong , the CPU will send a kill request to the coprocessor using the x_commit_t interface ?

The CPU only provides correct values when the according valid signal is asserted. Thus, no need to kill.

When X_ISSUE_REGISTER_SPLIT=1 . How does the CPU supporting this mode can know that “ the coprocessor is able to accept multiple issue transactions before receiving the registers “ ? It would be nice if the coprocessor could have a signal / parameter to restrict this behavior to the ISSUE_REGISTER_SPLIT=0 mode , for back compatibility reasons. That is, getting the instruction and its operands values at the same time , at the expense of performance.

If the coprocessor is not able to buffer issue offloads, it will not accept another issue before receiving the registers. No accepting would be achieved by not asserting the issue_ready signal. This would stall the CPU until the registers have been provided for the preceding instruction.

ntribie-bosch commented 3 months ago

Ok, thanks for your quick feedback . So we can solve back – compatibility.

Sincères salutations / Best regards,

Nicolas Tribie

Mobility Electronics, IC Architecture (ME-IC/PAY1.2) Robert Bosch (France) SAS | 1180 route des Dolines | 06560 Valbonne-Sophia Antipolis | FRANCE | www.bosch.frhttp://www.bosch.fr/ @.**@.>

Registered Office: 32 avenue Michelet - 93404 St Ouen cedex France Société par Actions Simplifiée au capital de 140.400.000 € - SIREN 572 067 684 RCS Bobigny N° TVA France : FR 09 572 067 684 ​ From: christian-herber-nxp @.> Sent: Friday, March 1, 2024 2:42 PM To: openhwgroup/core-v-xif @.> Cc: Tribie Nicolas (ME-IC/PAY1.2) @.>; Author @.> Subject: Re: [openhwgroup/core-v-xif] [Review Comment]: X_ISSUE_REGISTER_SPLIT definition (Issue #182)

_ISSUE_REGISTER_SPLIT=0 : “In this case, the CPU will speculatively provide all possible source registers” : I guess that if the provided registers value were wrong , the CPU will send a kill request to the coprocessor using the x_commit_t interface ?

The CPU only provides correct values when the according valid signal is asserted. Thus, no need to kill.

When X_ISSUE_REGISTER_SPLIT=1 . How does the CPU supporting this mode can know that “ the coprocessor is able to accept multiple issue transactions before receiving the registers “ ? It would be nice if the coprocessor could have a signal / parameter to restrict this behavior to the ISSUE_REGISTER_SPLIT=0 mode , for back compatibility reasons. That is, getting the instruction and its operands values at the same time , at the expense of performance.

If the coprocessor is not able to buffer issue offloads, it will not accept another issue before receiving the registers. No accepting would be achieved by not asserting the issue_ready signal. This would stall the CPU until the registers have been provided for the preceding instruction.

— Reply to this email directly, view it on GitHubhttps://github.com/openhwgroup/core-v-xif/issues/182#issuecomment-1973227804, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BE2ECG2FQL2FUWF3XD7S7SDYWCAUJAVCNFSM6AAAAABEBYV6GCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGIZDOOBQGQ. You are receiving this because you authored the thread.Message ID: @.**@.>>