Bug 14 - EINT interface needed (PLIC)
Summary: EINT interface needed (PLIC)
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 2
  Show dependency treegraph
 
Reported: 2018-03-03 09:00 GMT by Luke Kenneth Casson Leighton
Modified: 2019-04-15 12:26 BST (History)
2 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for completion of task (excludes budget allocated to subtasks): 0
parent task for budget allocation:
child tasks for budget allocation:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2018-03-03 09:00:05 GMT
http://libre-riscv.org/shakti/m_class/EINT/
Comment 1 Luke Kenneth Casson Leighton 2019-04-05 23:10:01 BST
see:

https://groups.google.com/a/groups.riscv.org/d/msg/hw-dev/EimCdsKMFOo/E28VwmAeCAAJ

Dear Palmer, 

I appreciate your pragmatic decision to adopt the specification of the 
SiFive PLIC as a working model of how things should be done. However at 
Cambridge and ETHZ we recently observed a problem with the PLIC claim 
mechanism if the idempotency PMA is not implemented. Since I assume the 
latter is an optional and perhaps rather complicated feature, we were 
wondering whether it would be possible to support an optional 
specification to the PLIC to use a write operation to claim an interrupt 
instead of a read. The bug arises because, to maximise performance, 
speculative load instructions are initiated at the beginning of the 
pipeline, this will have the effect of claiming the interrupt whether or 
not that instruction reaches the commit stage. As you know in Linux this 
claim routine happens with interrupts off but there is always the 
possibility of a machine mode interrupt or other event causing a 
pipeline flush. Another option would be to force the PLIC to support 
atomic reads. I appreciate backward compatibility is an issue and there 
could be sound architectural reasons why your group chose to do it this way. 

Regards, 

Jonathan Kimmitt