get Weights and delays for pre run values

[Christian-B]

Reminder that at some points we have to look at how this works including the values in the last_run table.

[Christian-B]

can wiat until after release especially as not sure what this was.

[Christian-B]

Ah this is a consideration to do it in Java and not python. As only needed on demand I think doing this in Java is overkill.

[rowleya]

Reading weights and delays can mean reading a lot of data, which is where using the data reading protocol could be useful, being faster in general than using SCP messages which is the current method I believe. Whether this needs to be done in Java vs. Python is debatable. The current issue is that reads "on demand" are not easy as the board needs to be set up for this to work. Maybe we should set the board to this state at the end of run in preparation for data reading in general and the reset this at the start of a new run or end.

[dkfellows]

If we have things set up to also do fast data out for recording data, the on-machine changes to support fetching arbitrary chunks of SDRAM are trivial. As in, they're not actually changes to what we have deployed, just to when we tell it to run.

The missing part is the model for the database that receives the data; it's probably got to end up saying "this is the content of region A on core B (i.e., the X,Y,Z,R coordinates) at timestamp C of run D" (the last part could be implicit in which DB file); it's snapshot semantics, not recording stream semantics.