see https://bugs.libre-soc.org/show_bug.cgi?id=731#c23 for context
SwizzledSimdValue has emerged as an optimisation that, once SimdSignal
version 1 has moved off of critical path and allowed multiple other
developers to proceed with converting ALUs over to it, will become
a high priority for reducing gate count.
however as an optimisation it is currently classified as non-essential
due to SimdSignal being a far higher priority critical path task.
therefore this bugreport is being created with a series of high priority
blockers that is it absolutely essential to complete first in order to
move SimdSignal off off critical path, at which point this task's
priority can be altered.
this task will also be a "critical blocker" for the 2nd ASIC to make
sure that it does get done, but done at an appropriately-scheduled
setting a very weird combination of "critical" importance but LOW priority,
to recognise the fact that completing a version 1 SimdSignal is a much
higher (critical path) priority.
(edit: i also need to work out where the heck to get some budget from,
for this. i know. NGI POINTER will do. solve that one later)