Currently we have information about what the board/ default board/ virtual machine should be in various places.
This includes sdram per chip.
Once the ChipInfo is obtained from the board that Value should be used!
This is about where to store the information until ChipInfo is obtained.
As one place the information could be provided is the cfg the choice here is to use the ConfigHolder as the ONLY place to get the data until ChipInfo is read.
The standard way is for the Value in the cfg file to be None.
Then the ConfigHandler init called as part of sim.setup will detect the board type and fill in the Values.
overrides in the cfg should only be used in testing or at the users risk,
Note: as we have not yet determined how to detect a spin2 board from cfg ConfigHandler temporarily assumes spin1
The issue is then what to do with unittests that call sim.setup but do need the default values for example to create a VirtualMachine
The proposal is to have a board_type param in unittest_setup to determine which default Values to use.
There may be many unittest which only need A default and dont care which.
This could be extended for example to board_type=0 where something else is used to flip between testing spin1 vs testing spin 2. For example of the python_version as we run the tests in 4 version
Safety code checks that the the board_type is not changed while there is a Machine
This required a second has_machine method as the existing one returned true for unittests as it one would be created on demand
The current spin2 values are WRONG! so included purely for demo
Other default Values including number of processors, number of Chip, number of montor cores ect to be added later
Currently we have information about what the board/ default board/ virtual machine should be in various places. This includes sdram per chip.
Once the ChipInfo is obtained from the board that Value should be used! This is about where to store the information until ChipInfo is obtained.
As one place the information could be provided is the cfg the choice here is to use the ConfigHolder as the ONLY place to get the data until ChipInfo is read.
The standard way is for the Value in the cfg file to be None. Then the ConfigHandler init called as part of sim.setup will detect the board type and fill in the Values. overrides in the cfg should only be used in testing or at the users risk,
Note: as we have not yet determined how to detect a spin2 board from cfg ConfigHandler temporarily assumes spin1
The issue is then what to do with unittests that call sim.setup but do need the default values for example to create a VirtualMachine The proposal is to have a board_type param in unittest_setup to determine which default Values to use.
There may be many unittest which only need A default and dont care which. This could be extended for example to board_type=0 where something else is used to flip between testing spin1 vs testing spin 2. For example of the python_version as we run the tests in 4 version
Safety code checks that the the board_type is not changed while there is a Machine This required a second has_machine method as the existing one returned true for unittests as it one would be created on demand
The current spin2 values are WRONG! so included purely for demo
Other default Values including number of processors, number of Chip, number of montor cores ect to be added later
Must be done at the same time as: https://github.com/SpiNNakerManchester/SpiNNMan/pull/341 https://github.com/SpiNNakerManchester/PACMAN/pull/518 https://github.com/SpiNNakerManchester/SpiNNFrontEndCommon/pull/1086 https://github.com/SpiNNakerManchester/sPyNNaker/pull/1369 https://github.com/SpiNNakerManchester/SpiNNakerGraphFrontEnd/pull/254
tested by:
https://github.com/SpiNNakerManchester/IntegrationTests/pull/218