Bug 355

Summary:	game theory "state" packet engine needed
Product:	Libre-SOC's first SoC	Reporter:	Luke Kenneth Casson Leighton <lkcl>
Component:	Source Code	Assignee:	Luke Kenneth Casson Leighton <lkcl>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	libre-soc-bugs
Priority:	---
Version:	unspecified
Hardware:	Other
OS:	Linux
See Also:	https://bugs.libre-soc.org/show_bug.cgi?id=435
NLnet milestone:	---	total budget (EUR) for completion of task and all subtasks:	0
budget (EUR) for this task, excluding subtasks' budget:	0	parent task for budget allocation:
child tasks for budget allocation:		The table of payments (in EUR) for this task; TOML format:

Description Luke Kenneth Casson Leighton 2020-05-27 22:04:35 BST

it occurred to me that the branch system etc. is basically running game theory (in hardware), running new "state" ahead.

the program counter, DEC SPR, and TB SPR, these all increment and need rollback in a group.  there may also be other pieces of state information involved.

my feeling is that we will need a ring buffer, associated with the instruction queue (or actually part of it) that contains each advancement of that state, and thus we can roll it back without losing anything.

perhaps it is as simple as adding DEC and TB to the Decode2ExecuteType data structure?

Comment 1 Luke Kenneth Casson Leighton 2020-05-27 22:42:32 BST

some possible ideas which preserve the state/context:

* a ring buffer with the instruction, TB, DEC and other context as entries is created.  the index of the ring buffer entry is passed down the pipeline "ctx" (context)

* TB, PC and DEC are passed into "ctx".  as this is 3x 64 bit that is an awful lot, it will be copied right the way through the pipelines (and not actually change or be used).

* a separate instruction queue and a separate ring buffer for state.