Clarification needed for the logic among mip.SEIP, sip.SEIP, and mideleg.SEI states
129 views
Skip to first unread message
chuanhua.chang
Jan 3, 2018, 2:15:23 AM1/3/18
to RISC-V ISA Dev
I would like to see if the following logic among mip.SEIP, sip.SEIP, and mideleg.SEI states is correct or not.
(Assuming mie.SEIE and sie.SEIE are all 1)
--------------------+--------------------------------------------------+
| mip.SEIP |
mideleg.SEI=0 +--------------------+-----------------------------+
| 0 | 1 |
--------------+-----+--------------------+-----------------------------+
| 0 | no action | generate M-mode interrupt |
sip.SEIP +-----+--------------------+-----------------------------+
(Read Only) | 1 | impossible state | impossible state |
--------------+-----+--------------------+-----------------------------+
--------------------+--------------------------------------------------+
| mip.SEIP |
mideleg.SEI=1 +--------------------+-----------------------------+
| 0 | 1 |
--------------+-----+--------------------+-----------------------------+
| 0 | no action | impossible state |
sip.SEIP +-----+--------------------+-----------------------------+
(Read/Write) | 1 | impossible state | generate S-mode interrupt |
--------------+-----+--------------------+-----------------------------+
The architecture spec implies, but does not mention explicitly that when mideleg.SEI is 1, if mip.SEIP is 1, sip.SEIP will be 1 too.
And the M-mode mip.SEIP interrupt will be masked out and only generate S-mode sip.SEIP interrupt.
As for the read and write behavior of the sip.SEIP bit field,
In section 4.1.5 of v1.10 architecture spec (page 52), it has the following sentence:
------------------
All bits besides SSIP, USIP, and UEIP in the sip register are read-only.
------------------
This implies that sip.SEIP is read-only.
But in the RISC-V Reader book, page 109~110, the last 2 sentences say that:
----------------
The sie and sip CSRs are S-mode CSRs that are subsets of the mie and mip CSRs. They have the same layout as
their M-mode counterparts, but only the bits corresponding to interrupts that have been delegated in mideleg are readable
and writable through sie and sip. The bits corresponding to interrupts that haven't been delegated are always zero.
----------------
This implies that sip.SEIP is a R/W bit field, if mideleg.SEI is 1. And this conflicts with the read-only definition in the architecture spec.
Which is correct? The spec or the RISC-V Reader book?
Thanks for help.
Chuanhua Chang
(Assuming mie.SEIE and sie.SEIE are all 1)
--------------------+--------------------------------------------------+
| mip.SEIP |
mideleg.SEI=0 +--------------------+-----------------------------+
| 0 | 1 |
--------------+-----+--------------------+-----------------------------+
| 0 | no action | generate M-mode interrupt |
sip.SEIP +-----+--------------------+-----------------------------+
(Read Only) | 1 | impossible state | impossible state |
--------------+-----+--------------------+-----------------------------+
--------------------+--------------------------------------------------+
| mip.SEIP |
mideleg.SEI=1 +--------------------+-----------------------------+
| 0 | 1 |
--------------+-----+--------------------+-----------------------------+
| 0 | no action | impossible state |
sip.SEIP +-----+--------------------+-----------------------------+
(Read/Write) | 1 | impossible state | generate S-mode interrupt |
--------------+-----+--------------------+-----------------------------+
The architecture spec implies, but does not mention explicitly that when mideleg.SEI is 1, if mip.SEIP is 1, sip.SEIP will be 1 too.
And the M-mode mip.SEIP interrupt will be masked out and only generate S-mode sip.SEIP interrupt.
As for the read and write behavior of the sip.SEIP bit field,
In section 4.1.5 of v1.10 architecture spec (page 52), it has the following sentence:
------------------
All bits besides SSIP, USIP, and UEIP in the sip register are read-only.
------------------
This implies that sip.SEIP is read-only.
But in the RISC-V Reader book, page 109~110, the last 2 sentences say that:
----------------
The sie and sip CSRs are S-mode CSRs that are subsets of the mie and mip CSRs. They have the same layout as
their M-mode counterparts, but only the bits corresponding to interrupts that have been delegated in mideleg are readable
and writable through sie and sip. The bits corresponding to interrupts that haven't been delegated are always zero.
----------------
This implies that sip.SEIP is a R/W bit field, if mideleg.SEI is 1. And this conflicts with the read-only definition in the architecture spec.
Which is correct? The spec or the RISC-V Reader book?
Thanks for help.
Chuanhua Chang
Stefan O'Rear
Jan 3, 2018, 2:29:01 AM1/3/18
to chuanhua.chang, RISC-V ISA Dev
On Tue, Jan 2, 2018 at 11:15 PM, chuanhua.chang
<chuanhu...@gmail.com> wrote:
> I would like to see if the following logic among mip.SEIP, sip.SEIP, and
> mideleg.SEI states is correct or not.
> (Assuming mie.SEIE and sie.SEIE are all 1)
>
> --------------------+--------------------------------------------------+
> | mip.SEIP |
> mideleg.SEI=0 +--------------------+-----------------------------+
> | 0 | 1 |
> --------------+-----+--------------------+-----------------------------+
> | 0 | no action | generate M-mode interrupt |
> sip.SEIP +-----+--------------------+-----------------------------+
> (Read Only) | 1 | impossible state | impossible state |
> --------------+-----+--------------------+-----------------------------+
>
> --------------------+--------------------------------------------------+
> | mip.SEIP |
> mideleg.SEI=1 +--------------------+-----------------------------+
> | 0 | 1 |
> --------------+-----+--------------------+-----------------------------+
> | 0 | no action | impossible state |
> sip.SEIP +-----+--------------------+-----------------------------+
> (Read/Write) | 1 | impossible state | generate S-mode interrupt |
> --------------+-----+--------------------+-----------------------------+
Looks right to me.
<chuanhu...@gmail.com> wrote:
> I would like to see if the following logic among mip.SEIP, sip.SEIP, and
> mideleg.SEI states is correct or not.
> (Assuming mie.SEIE and sie.SEIE are all 1)
>
> --------------------+--------------------------------------------------+
> | mip.SEIP |
> mideleg.SEI=0 +--------------------+-----------------------------+
> | 0 | 1 |
> --------------+-----+--------------------+-----------------------------+
> | 0 | no action | generate M-mode interrupt |
> sip.SEIP +-----+--------------------+-----------------------------+
> (Read Only) | 1 | impossible state | impossible state |
> --------------+-----+--------------------+-----------------------------+
>
> --------------------+--------------------------------------------------+
> | mip.SEIP |
> mideleg.SEI=1 +--------------------+-----------------------------+
> | 0 | 1 |
> --------------+-----+--------------------+-----------------------------+
> | 0 | no action | impossible state |
> sip.SEIP +-----+--------------------+-----------------------------+
> (Read/Write) | 1 | impossible state | generate S-mode interrupt |
> --------------+-----+--------------------+-----------------------------+
> The architecture spec implies, but does not mention explicitly that when
> mideleg.SEI is 1, if mip.SEIP is 1, sip.SEIP will be 1 too.
> And the M-mode mip.SEIP interrupt will be masked out and only generate
> S-mode sip.SEIP interrupt.
>
be read in its entirety as MIP but accessing it as SIP hides
interrupts not delegated to S-mode.
> As for the read and write behavior of the sip.SEIP bit field,
> In section 4.1.5 of v1.10 architecture spec (page 52), it has the following
> sentence:
> ------------------
> All bits besides SSIP, USIP, and UEIP in the sip register are read-only.
> ------------------
> This implies that sip.SEIP is read-only.
>
> But in the RISC-V Reader book, page 109~110, the last 2 sentences say that:
> ----------------
> The sie and sip CSRs are S-mode CSRs that are subsets of the mie and mip
> CSRs. They have the same layout as
> their M-mode counterparts, but only the bits corresponding to interrupts
> that have been delegated in mideleg are readable
> and writable through sie and sip. The bits corresponding to interrupts that
> haven't been delegated are always zero.
> ----------------
> This implies that sip.SEIP is a R/W bit field, if mideleg.SEI is 1. And this
> conflicts with the read-only definition in the architecture spec.
>
> Which is correct? The spec or the RISC-V Reader book?
matter. Otherwise I'm not sure.
-s
Allen J. Baum
Jan 3, 2018, 4:21:45 AM1/3/18
to Stefan O'Rear, chuanhua.chang, RISC-V ISA Dev
If it hasn't been delegated, then how can any SEIP bit get set at all, either in mip or in sip?
But, if it is not delegated, then the trap is taken in MMode, and not in S-mode, so .SEIP should never be set.
The mip.MEIP bit could get set, but not the mip.SEIP, right?
So perhaps the labels are wrong?
If it has been delegated, then shouldn't this looks correct: sip.SEIP and mip.SEIP will have the same value (assuming you're looking at it from M-mode)
>
>> The architecture spec implies, but does not mention explicitly that when
>> mideleg.SEI is 1, if mip.SEIP is 1, sip.SEIP will be 1 too.
>> And the M-mode mip.SEIP interrupt will be masked out and only generate
>> S-mode sip.SEIP interrupt.
>>
>
>The intended behavior is that there is only one IP register, which can
>be read in its entirety as MIP but accessing it as SIP hides
>interrupts not delegated to S-mode.
So reading sip from M-mode will give the same result as if it were being read from S-mode.
> > As for the read and write behavior of the sip.SEIP bit field,
>> In section 4.1.5 of v1.10 architecture spec (page 52), it has the following
>> sentence:
>> ------------------
>> All bits besides SSIP, USIP, and UEIP in the sip register are read-only.
>> ------------------
>> This implies that sip.SEIP is read-only.
>>
>> But in the RISC-V Reader book, page 109~110, the last 2 sentences say that:
>> ----------------
>> The sie and sip CSRs are S-mode CSRs that are subsets of the mie and mip
>> CSRs. They have the same layout as
>> their M-mode counterparts, but only the bits corresponding to interrupts
>> that have been delegated in mideleg are readable
>> and writable through sie and sip. The bits corresponding to interrupts that
>> haven't been delegated are always zero.
>> ----------------
>> This implies that sip.SEIP is a R/W bit field, if mideleg.SEI is 1. And this
>> conflicts with the read-only definition in the architecture spec.
>>
>> Which is correct? The spec or the RISC-V Reader book?
>
>If your core doesn't implement SEIP virtualization then it doesn't
>matter. Otherwise I'm not sure.
>
>-s
>
>You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
>To post to this group, send email to isa...@groups.riscv.org.
>Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
>To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CADJ6UvMxRDtdYcsjj0eLHr3C_fezeku9TXW8nbuHRRcizfXTXA%40mail.gmail.com.
--
**************************************************
* Allen Baum tel. (908)BIT-BAUM *
* 248-2286 *
**************************************************
Stefan O'Rear
Jan 3, 2018, 4:31:03 AM1/3/18
to Allen J. Baum, chuanhua.chang, RISC-V ISA Dev
On Wed, Jan 3, 2018 at 1:21 AM, Allen J. Baum
<allen...@esperantotech.com> wrote:
> Not to me.
> If it hasn't been delegated, then how can any SEIP bit get set at all, either in mip or in sip?
> But, if it is not delegated, then the trap is taken in MMode, and not in S-mode, so .SEIP should never be set.
>
> The mip.MEIP bit could get set, but not the mip.SEIP, right?
> So perhaps the labels are wrong?
>
> If it has been delegated, then shouldn't this looks correct: sip.SEIP and mip.SEIP will have the same value (assuming you're looking at it from M-mode)
The labels have nothing to do with the mode the trap is taken in.
<allen...@esperantotech.com> wrote:
> Not to me.
> If it hasn't been delegated, then how can any SEIP bit get set at all, either in mip or in sip?
> But, if it is not delegated, then the trap is taken in MMode, and not in S-mode, so .SEIP should never be set.
>
> The mip.MEIP bit could get set, but not the mip.SEIP, right?
> So perhaps the labels are wrong?
>
> If it has been delegated, then shouldn't this looks correct: sip.SEIP and mip.SEIP will have the same value (assuming you're looking at it from M-mode)
You're expected to delegate SEI and not delegate MEI, but there's
nothing in principle stopping you from delegating both or neither
(it'd be a bad idea, and may be forbidden by the current spec, but
it's semantically well-defined).
-s
chuanhua.chang
Jan 4, 2018, 3:58:52 AM1/4/18
to RISC-V ISA Dev, sor...@gmail.com, chuanhu...@gmail.com
Allen,
Thanks for your reply. My comment is below.
Thanks for your reply. My comment is below.
The platform I have in mind is that the mip.SEIP is directly connected to an interrupt request line from the PLIC device. So mip.SEIP will be set by PLIC. Under this condition, I would like to see if the logic state relations in my table conform to the architecture spec or not. And it seems that there is some inconsistent descriptions in this part between the architecture spec and the RISC-V reader book written by David Patterson and Andrew Waterman.
Chuanhua
Allen Baum
Jan 4, 2018, 1:40:20 PM1/4/18
to chuanhua.chang, RISC-V ISA Dev, Stefan O'Rear
Stefan and I disagreed on how this works, and Stefan turned out to be correct.
The PLIC can send interrupts that set SEIP directly, or attempt to set MDIP and have them delegated to SEIP.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3841ba18-f474-4a73-bcec-e681b413b3dc%40groups.riscv.org.
Reply all
Reply to author
Forward
0 new messages