-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
A moderately dangerous interupt domain crossing bug #3687
Comments
Can you provide a minimal chipyard config that demonstrates the issue? That would help me figure out the problem here.
|
Jerry, Thanks for your reply,
Therefore, you can modify the
We change the inXType from
My understanding is If |
Hello Community,
My team is planing to tapout a chipyard based design, and we have a different Clock Scheme from the default chipyard design:
domain1, CORE,SBUS,CBUS: 800MHZ
domain2, MBUS,L2Wrapper:400MHZ
domain3: PBUS,FBUS: 100MHZ.
All these clock domains are rational crossed. They are phase aligned with each other. Therefore, taking UART as an example, interrupt initiated by uart(at PBUS) has to cross to IBUS(the same clock domain with SBUS), see code below:
There are two dangerous bugs in code above:
1,The domain crossing logic is applied twice, the
uart.intXing(intXType)
will be converted intoIntSyncRationalCrossingSink() :*=* IntSyncNameNode(name) :*=* scope { IntSyncNameNode(name) :*=* IntSyncCrossingSource(alreadyRegistered) } :*=* node
, whileibus.fromRational
also has domain crossing facilities:I don't really think this is the intended behavior, I think domain corssing stuff should only be applied once, that is the IntSource should be at
PBUS
domain while theIntSink
should be atIBUS
domain.2, The crossing domain collateral being applied twice make the Interrupt Domain crossing moderately dangerous, when applying the first
RationalCrossing
collateral(coming out ofPBUS
), theIntSyncAsyncCrossingSink
is neither at the domain ofPBUS
nor theIBUS
, it is atwhere
which is theBaseSubsystem
, aka theDigitalTop
, theModuleImp
ofDigitalTop
isLazyRawModuleImp
, which mean there is no implicit clock and reset for thisDigitalTop
, therefore anonymous children ofDigitalTop
will not receiveclock
orreset
, this means theIntSyncAsyncCrossingSink
inwhere
will not be approperly clocked. :Can anyone in the team confirm my understanding is right? If I am right, I wonder what's the typical domain crossing scehmes used by chipyard or rocketchip teams that has been tapout verified. The reason for choosing
PBUS
at lower clock speed is that the device at PBUS is slow, therefore it's not very power effcient to make it 800MHZ(in our case). I also wonder if the rational crossing type has been used or tested at all?Any help will be appreciated, Thanks again, I am sorry to post issues recently and disrupt you guys.
@jerryz123 @sequencer @tianrui-wei
The text was updated successfully, but these errors were encountered: