sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-atomic-checkpoint/config.json

2038 lines
78 KiB
JSON
Raw Normal View History

test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
{
"name": null,
"sim_quantum": 0,
"system": {
"have_virtualization": false,
"mmap_using_noreserve": false,
"kernel_addr_check": true,
"highest_el_is_64": false,
stats: update references
2016-07-21 18:19:18 +02:00
"kernel": "/arm/projectscratch/randd/systems/dist/binaries/vmlinux.aarch32.ll_20131205.0-gem5",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"iobus": {
stats: update references
2016-07-21 18:19:18 +02:00
"forward_latency": 1,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"slave": {
"peer": [
"system.bridge.master",
"system.realview.clcd.dma",
"system.realview.cf_ctrl.dma",
"system.realview.ide.dma",
"system.realview.ethernet.dma"
],
"role": "SLAVE"
},
"name": "iobus",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"p_state_clk_gate_bins": 20,
"cxx_class": "NoncoherentXBar",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"width": 16,
"eventq_index": 0,
"master": {
"peer": [
"system.realview.uart.pio",
"system.realview.realview_io.pio",
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"system.realview.pci_host.pio",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system.realview.timer0.pio",
"system.realview.timer1.pio",
"system.realview.clcd.pio",
"system.realview.hdlcd.pio",
"system.realview.kmi0.pio",
"system.realview.kmi1.pio",
"system.realview.cf_ctrl.pio",
"system.realview.rtc.pio",
"system.realview.vram.port",
"system.realview.l2x0_fake.pio",
"system.realview.uart1_fake.pio",
"system.realview.uart2_fake.pio",
"system.realview.uart3_fake.pio",
"system.realview.sp810_fake.pio",
"system.realview.watchdog_fake.pio",
"system.realview.aaci_fake.pio",
"system.realview.lan_fake.pio",
"system.realview.usb_fake.pio",
"system.realview.mmc_fake.pio",
"system.realview.energy_ctrl.pio",
"system.realview.ide.pio",
"system.realview.ethernet.pio",
"system.iocache.cpu_side"
],
"role": "MASTER"
},
"response_latency": 2,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.iobus",
"type": "NoncoherentXBar",
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"use_default_range": false,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"frontend_latency": 2
},
"symbolfile": "",
stats: update references
2016-07-21 18:19:18 +02:00
"readfile": "/work/curdun01/gem5-external.hg/tests/testing/../halt.sh",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"have_large_asid_64": false,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"thermal_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"phys_addr_range_64": 40,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"work_begin_exit_count": 0,
stats: Update to match ARM ISA changes
2016-06-02 15:14:36 +02:00
"have_lpae": true,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "LinuxArmSystem",
stats: update references
2016-07-21 18:19:18 +02:00
"work_begin_cpu_id_exit": -1,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"load_offset": 2147483648,
"vncserver": {
"name": "vncserver",
"number": 0,
"frame_capture": false,
"eventq_index": 0,
"cxx_class": "VncServer",
"path": "system.vncserver",
"type": "VncServer",
"port": 5900
},
"multi_proc": true,
stats: update references
2016-07-21 18:19:18 +02:00
"bridge": {
"ranges": [
"788529152:805306367",
"721420288:725614591",
"805306368:1073741823",
"1073741824:1610612735",
"402653184:469762047",
"469762048:536870911"
],
"slave": {
"peer": "system.membus.master[0]",
"role": "SLAVE"
},
"name": "bridge",
"p_state_clk_gate_min": 1000,
"p_state_clk_gate_bins": 20,
"cxx_class": "Bridge",
"req_size": 16,
"clk_domain": "system.clk_domain",
"power_model": null,
"delay": 50000,
"eventq_index": 0,
"master": {
"peer": "system.iobus.slave[0]",
"role": "MASTER"
},
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
"path": "system.bridge",
"resp_size": 16,
"type": "Bridge"
},
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"early_kernel_symbols": false,
"panic_on_oops": true,
stats: update references
2016-07-21 18:19:18 +02:00
"dtb_filename": "/arm/projectscratch/randd/systems/dist/binaries/vexpress.aarch32.ll_20131205.0-gem5.1cpu.dtb",
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"panic_on_panic": true,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"enable_context_switch_stats_dump": false,
"work_begin_ckpt_count": 0,
"clk_domain": {
"name": "clk_domain",
"clock": [
1000
],
"init_perf_level": 0,
"voltage_domain": "system.voltage_domain",
"eventq_index": 0,
"cxx_class": "SrcClockDomain",
"path": "system.clk_domain",
"type": "SrcClockDomain",
"domain_id": -1
},
"mem_ranges": [
"2147483648:2415919103"
],
"realview": {
"hdlcd": {
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[6]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
"cxx_class": "HDLcd",
"enable_capture": true,
"pio_addr": 721420288,
"pixel_chunk": 32,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 10000,
"clk_domain": "system.clk_domain",
"int_num": 117,
stats: update references
2016-07-21 18:19:18 +02:00
"gic": "system.realview.gic",
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"pxl_clk": "system.realview.dcc.osc_pxl",
"type": "HDLcd",
"vnc": "system.vncserver",
"p_state_clk_gate_min": 1000,
"power_model": null,
"workaround_dma_line_count": true,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"pixel_buffer_size": 2048,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.hdlcd",
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"workaround_swap_rb": true,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"dma": {
"peer": "system.membus.slave[0]",
"role": "MASTER"
stats: update references
2016-07-21 18:19:18 +02:00
},
"name": "hdlcd",
"p_state_clk_gate_bins": 20,
"amba_id": 1314816
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"mmc_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "mmc_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[21]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.mmc_fake",
"pio_addr": 470089728,
"type": "AmbaFake"
},
"rtc": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "rtc",
"int_delay": 100000,
"pio": {
"peer": "system.iobus.master[10]",
"role": "SLAVE"
},
"amba_id": 3412017,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"gic": "system.realview.gic",
"int_num": 36,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"time": "Thu Jan 1 00:00:00 2009",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "PL031",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.rtc",
"pio_addr": 471269376,
"type": "PL031"
},
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"watchdog_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"name": "watchdog_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"pio": {
"peer": "system.iobus.master[17]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"path": "system.realview.watchdog_fake",
"pio_addr": 470745088,
"type": "AmbaFake"
},
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"vgic": {
"system": "system",
"name": "vgic",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.membus.master[3]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "VGic",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"hv_addr": 738213888,
"gic": "system.realview.gic",
"platform": "system.realview",
"vcpu_addr": 738222080,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"ppint": 25,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.vgic",
"type": "VGic",
"pio_delay": 10000
},
"cxx_class": "RealView",
"uart3_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "uart3_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[15]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.uart3_fake",
"pio_addr": 470548480,
"type": "AmbaFake"
},
"realview_io": {
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"proc_id1": 335544320,
"name": "realview_io",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[1]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "RealViewCtrl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"system": "system",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"proc_id0": 335544320,
stats: update references
2016-07-21 18:19:18 +02:00
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.realview_io",
"idreg": 35979264,
"type": "RealViewCtrl",
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"pio_addr": 469827584
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"l2x0_fake": {
"pio": {
"peer": "system.iobus.master[12]",
"role": "SLAVE"
},
"ret_data64": 18446744073709551615,
stats: update references
2016-07-21 18:19:18 +02:00
"fake_mem": false,
"clk_domain": "system.clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "IsaFake",
"pio_addr": 739246080,
stats: update references
2016-07-21 18:19:18 +02:00
"update_data": false,
"warn_access": "",
"pio_latency": 100000,
"system": "system",
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IsaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"power_model": null,
"ret_data32": 4294967295,
"path": "system.realview.l2x0_fake",
"ret_data16": 65535,
"ret_data8": 255,
"name": "l2x0_fake",
"ret_bad_addr": false,
"pio_size": 4095,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"uart1_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "uart1_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[13]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.uart1_fake",
"pio_addr": 470417408,
"type": "AmbaFake"
},
"usb_fake": {
"pio": {
"peer": "system.iobus.master[20]",
"role": "SLAVE"
},
"ret_data64": 18446744073709551615,
stats: update references
2016-07-21 18:19:18 +02:00
"fake_mem": false,
"clk_domain": "system.clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "IsaFake",
"pio_addr": 452984832,
stats: update references
2016-07-21 18:19:18 +02:00
"update_data": false,
"warn_access": "",
"pio_latency": 100000,
"system": "system",
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IsaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"power_model": null,
"ret_data32": 4294967295,
"path": "system.realview.usb_fake",
"ret_data16": 65535,
"ret_data8": 255,
"name": "usb_fake",
"ret_bad_addr": false,
"pio_size": 131071,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"system": "system",
"local_cpu_timer": {
"int_num_watchdog": 30,
"name": "local_cpu_timer",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.membus.master[4]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "CpuLocalTimer",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"gic": "system.realview.gic",
stats: update references
2016-07-21 18:19:18 +02:00
"int_num_timer": 29,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.local_cpu_timer",
"pio_addr": 738721792,
"type": "CpuLocalTimer"
},
"generic_timer": {
"int_virt": 27,
"name": "generic_timer",
"int_phys": 29,
"cxx_class": "GenericTimer",
"system": "system",
"eventq_index": 0,
"gic": "system.realview.gic",
"path": "system.realview.generic_timer",
"type": "GenericTimer"
},
"gic": {
stats: Update to match ARM ISA changes
2016-06-02 15:14:36 +02:00
"gem5_extensions": true,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"it_lines": 128,
stats: update references
2016-07-21 18:19:18 +02:00
"dist_pio_delay": 10000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "gic",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"dist_addr": 738201600,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cpu_pio_delay": 10000,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"cpu_addr": 738205696,
"platform": "system.realview",
"int_latency": 10000,
"eventq_index": 0,
"cxx_class": "Pl390",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
"path": "system.realview.gic",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.membus.master[2]",
"role": "SLAVE"
},
"type": "Pl390"
},
"timer1": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "timer1",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[4]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"amba_id": 1316868,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"clock0": 1000000,
"clock1": 1000000,
"gic": "system.realview.gic",
"eventq_index": 0,
"cxx_class": "Sp804",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.timer1",
"int_num0": 35,
"int_num1": 35,
"type": "Sp804",
"pio_addr": 470941696
},
"timer0": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "timer0",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[3]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"amba_id": 1316868,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"clock0": 1000000,
"clock1": 1000000,
"gic": "system.realview.gic",
"eventq_index": 0,
"cxx_class": "Sp804",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.timer0",
"int_num0": 34,
"int_num1": 34,
"type": "Sp804",
"pio_addr": 470876160
},
"uart2_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "uart2_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[14]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.uart2_fake",
"pio_addr": 470482944,
"type": "AmbaFake"
},
"eventq_index": 0,
"energy_ctrl": {
"name": "energy_ctrl",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[22]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "EnergyCtrl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.energy_ctrl",
"dvfs_handler": "system.dvfs_handler",
"type": "EnergyCtrl",
"pio_addr": 470286336
},
"type": "RealView",
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"pci_host": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"default_p_state": "UNDEFINED",
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"conf_size": 268435456,
"name": "pci_host",
"conf_device_bits": 16,
"pio": {
"peer": "system.iobus.master[2]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"conf_base": 805306368,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"system": "system",
"pci_dma_base": 0,
"platform": "system.realview",
"eventq_index": 0,
"cxx_class": "GenericPciHost",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"path": "system.realview.pci_host",
"pci_pio_base": 0,
"type": "GenericPciHost",
"pci_mem_base": 0
},
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"lan_fake": {
"pio": {
"peer": "system.iobus.master[19]",
"role": "SLAVE"
},
"ret_data64": 18446744073709551615,
stats: update references
2016-07-21 18:19:18 +02:00
"fake_mem": false,
"clk_domain": "system.clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "IsaFake",
"pio_addr": 436207616,
stats: update references
2016-07-21 18:19:18 +02:00
"update_data": false,
"warn_access": "",
"pio_latency": 100000,
"system": "system",
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IsaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"power_model": null,
"ret_data32": 4294967295,
"path": "system.realview.lan_fake",
"ret_data16": 65535,
"ret_data8": 255,
"name": "lan_fake",
"ret_bad_addr": false,
"pio_size": 65535,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"aaci_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "aaci_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[18]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.aaci_fake",
"pio_addr": 470024192,
"type": "AmbaFake"
},
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"mcc": {
"osc_peripheral": {
"position": 0,
"name": "osc_peripheral",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 0,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 2,
"path": "system.realview.mcc.osc_peripheral",
"freq": 41667,
"type": "RealViewOsc"
},
"name": "mcc",
"osc_mcc": {
"position": 0,
"name": "osc_mcc",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 0,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 0,
"path": "system.realview.mcc.osc_mcc",
"freq": 20000,
"type": "RealViewOsc"
},
"osc_clcd": {
"position": 0,
"name": "osc_clcd",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 0,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 1,
"path": "system.realview.mcc.osc_clcd",
"freq": 42105,
"type": "RealViewOsc"
},
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"thermal_domain": null,
"eventq_index": 0,
"cxx_class": "SubSystem",
"path": "system.realview.mcc",
"temp_crtl": {
"system": "system",
"position": 0,
"name": "temp_crtl",
"parent": "system.realview.realview_io",
"dcc": 0,
"site": 0,
"eventq_index": 0,
"cxx_class": "RealViewTemperatureSensor",
"device": 0,
"path": "system.realview.mcc.temp_crtl",
"type": "RealViewTemperatureSensor"
},
"type": "SubSystem",
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"osc_system_bus": {
"position": 0,
"name": "osc_system_bus",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 0,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 4,
"path": "system.realview.mcc.osc_system_bus",
"freq": 41667,
"type": "RealViewOsc"
}
},
"dcc": {
"name": "dcc",
"osc_hsbm": {
"position": 0,
"name": "osc_hsbm",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 4,
"path": "system.realview.dcc.osc_hsbm",
"freq": 25000,
"type": "RealViewOsc"
},
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"thermal_domain": null,
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"osc_sys": {
"position": 0,
"name": "osc_sys",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 7,
"path": "system.realview.dcc.osc_sys",
"freq": 16667,
"type": "RealViewOsc"
},
"osc_ddr": {
"position": 0,
"name": "osc_ddr",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 8,
"path": "system.realview.dcc.osc_ddr",
"freq": 25000,
"type": "RealViewOsc"
},
"eventq_index": 0,
"osc_cpu": {
"position": 0,
"name": "osc_cpu",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 0,
"path": "system.realview.dcc.osc_cpu",
"freq": 16667,
"type": "RealViewOsc"
},
"cxx_class": "SubSystem",
"path": "system.realview.dcc",
"osc_smb": {
"position": 0,
"name": "osc_smb",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 6,
"path": "system.realview.dcc.osc_smb",
"freq": 20000,
"type": "RealViewOsc"
},
"type": "SubSystem",
"osc_pxl": {
"position": 0,
"name": "osc_pxl",
"parent": "system.realview.realview_io",
"voltage_domain": "system.voltage_domain",
"dcc": 0,
"site": 1,
"eventq_index": 0,
"cxx_class": "RealViewOsc",
"device": 5,
"path": "system.realview.dcc.osc_pxl",
"freq": 42105,
"type": "RealViewOsc"
}
},
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview",
"vram": {
"range": "402653184:436207615",
"latency": 30000,
"name": "vram",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"latency_var": 0,
"bandwidth": "73.000000",
"conf_table_reported": false,
"cxx_class": "SimpleMemory",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.vram",
"null": false,
"type": "SimpleMemory",
"port": {
"peer": "system.iobus.master[11]",
"role": "SLAVE"
},
"in_addr_map": true
},
"nvmem": {
"range": "0:67108863",
"latency": 30000,
"name": "nvmem",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"latency_var": 0,
"bandwidth": "73.000000",
"conf_table_reported": false,
"cxx_class": "SimpleMemory",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.nvmem",
"null": false,
"type": "SimpleMemory",
"port": {
"peer": "system.membus.master[1]",
"role": "SLAVE"
},
"in_addr_map": true
},
"clcd": {
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[5]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
"cxx_class": "Pl111",
"enable_capture": true,
"pio_addr": 471793664,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 10000,
"clk_domain": "system.clk_domain",
"int_num": 46,
stats: update references
2016-07-21 18:19:18 +02:00
"gic": "system.realview.gic",
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"type": "Pl111",
"vnc": "system.vncserver",
"p_state_clk_gate_min": 1000,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.clcd",
stats: update references
2016-07-21 18:19:18 +02:00
"dma": {
"peer": "system.iobus.slave[1]",
"role": "MASTER"
},
"name": "clcd",
"p_state_clk_gate_bins": 20,
"pixel_clock": 41667,
"amba_id": 1315089
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"name": "realview",
"uart": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"terminal": "system.terminal",
"pio": {
"peer": "system.iobus.master[0]",
"role": "SLAVE"
},
stats: update references
2016-07-21 18:19:18 +02:00
"name": "uart",
"int_delay": 100000,
"platform": "system.realview",
"p_state_clk_gate_bins": 20,
"cxx_class": "Pl011",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"gic": "system.realview.gic",
"int_num": 37,
"eventq_index": 0,
"end_on_eot": false,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.uart",
"pio_addr": 470351872,
"type": "Pl011"
},
"intrctrl": "system.intrctrl",
"kmi1": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"vnc": "system.vncserver",
"name": "kmi1",
"int_delay": 1000000,
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[8]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"amba_id": 1314896,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"gic": "system.realview.gic",
"int_num": 45,
"eventq_index": 0,
"is_mouse": true,
"cxx_class": "Pl050",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.kmi1",
"pio_addr": 470220800,
"type": "Pl050"
},
"kmi0": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"vnc": "system.vncserver",
"name": "kmi0",
"int_delay": 1000000,
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[7]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"amba_id": 1314896,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"gic": "system.realview.gic",
"int_num": 44,
"eventq_index": 0,
"is_mouse": false,
"cxx_class": "Pl050",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.kmi0",
"pio_addr": 470155264,
"type": "Pl050"
},
"cf_ctrl": {
"PMCAPNextCapability": 0,
"InterruptPin": 1,
"HeaderType": 0,
"VendorID": 32902,
"MSIXMsgCtrl": 0,
"MSIXCAPNextCapability": 0,
"PXCAPLinkCtrl": 0,
"Revision": 0,
"LegacyIOBase": 0,
"pio_latency": 30000,
"PXCAPLinkCap": 0,
"CapabilityPtr": 0,
"MSIXCAPBaseOffset": 0,
"PXCAPDevCapabilities": 0,
"MSIXCAPCapId": 0,
"BAR3Size": 4,
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPCapabilities": 0,
"SubsystemID": 0,
"PXCAPCapId": 0,
"BAR4": 1,
"BAR1": 471466240,
"BAR0": 471465984,
"BAR3": 1,
"BAR2": 1,
"BAR5": 1,
"PXCAPDevStatus": 0,
"disks": [],
"BAR2Size": 8,
"MSICAPNextCapability": 0,
"ExpansionROM": 0,
"MSICAPMsgCtrl": 0,
"BAR5Size": 0,
"CardbusCIS": 0,
"MSIXPbaOffset": 0,
"MSICAPBaseOffset": 0,
"MaximumLatency": 0,
"BAR2LegacyIO": false,
"LatencyTimer": 0,
"BAR4LegacyIO": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPLinkStatus": 0,
"PXCAPDevCap2": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPDevCtrl": 0,
"MSICAPMaskBits": 0,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"host": "system.realview.pci_host",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"Command": 1,
"SubClassCode": 1,
"pci_func": 0,
"BAR5LegacyIO": false,
"MSICAPMsgData": 0,
"BIST": 0,
"PXCAPDevCtrl2": 0,
"pci_bus": 2,
"InterruptLine": 31,
"MSICAPMsgAddr": 0,
"BAR3LegacyIO": false,
"BAR4Size": 16,
"path": "system.realview.cf_ctrl",
"MinimumGrant": 0,
"Status": 640,
"BAR0Size": 256,
"system": "system",
"name": "cf_ctrl",
"PXCAPNextCapability": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IdeController",
"ctrl_offset": 2,
"PXCAPBaseOffset": 0,
"DeviceID": 28945,
"io_shift": 2,
"CacheLineSize": 0,
"dma": {
"peer": "system.iobus.slave[2]",
"role": "MASTER"
},
"PMCAPCapId": 0,
"config_latency": 20000,
"BAR1Size": 4096,
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[9]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"pci_dev": 0,
"PMCAPCtrlStatus": 0,
"cxx_class": "IdeController",
"clk_domain": "system.clk_domain",
"SubsystemVendorID": 0,
"PMCAPBaseOffset": 0,
"MSICAPPendingBits": 0,
"MSIXTableOffset": 0,
"MSICAPMsgUpperAddr": 0,
"MSICAPCapId": 0,
"BAR0LegacyIO": true,
"ProgIF": 133,
"BAR1LegacyIO": true,
"PMCAPCapabilities": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"ClassCode": 1,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"sp810_fake": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "sp810_fake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio": {
"peer": "system.iobus.master[16]",
"role": "SLAVE"
},
"amba_id": 0,
"ignore_access": true,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"pio_latency": 100000,
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"system": "system",
"eventq_index": 0,
"cxx_class": "AmbaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.realview.sp810_fake",
"pio_addr": 469893120,
"type": "AmbaFake"
},
"ethernet": {
"PMCAPNextCapability": 0,
"InterruptPin": 1,
"HeaderType": 0,
"VendorID": 32902,
"MSIXMsgCtrl": 0,
"MSIXCAPNextCapability": 0,
"PXCAPLinkCtrl": 0,
"Revision": 0,
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"hardware_address": "00:90:00:00:00:01",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"LegacyIOBase": 0,
"pio_latency": 30000,
"PXCAPLinkCap": 0,
"CapabilityPtr": 0,
"MSIXCAPBaseOffset": 0,
"PXCAPDevCapabilities": 0,
"MSIXCAPCapId": 0,
"BAR3Size": 0,
"rx_desc_cache_size": 64,
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPCapabilities": 0,
"SubsystemID": 4104,
"PXCAPCapId": 0,
"BAR4": 0,
"BAR1": 0,
"BAR0": 0,
"BAR3": 0,
"BAR2": 0,
"BAR5": 0,
"PXCAPDevStatus": 0,
"BAR2Size": 0,
"MSICAPNextCapability": 0,
"ExpansionROM": 0,
"rx_write_delay": 0,
"MSICAPMsgCtrl": 0,
"BAR5Size": 0,
"CardbusCIS": 0,
"MSIXPbaOffset": 0,
"MSICAPBaseOffset": 0,
"MaximumLatency": 0,
"BAR2LegacyIO": false,
"LatencyTimer": 0,
"BAR4LegacyIO": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPLinkStatus": 0,
"PXCAPDevCap2": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPDevCtrl": 0,
"MSICAPMaskBits": 0,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"host": "system.realview.pci_host",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"Command": 0,
"SubClassCode": 0,
"pci_func": 0,
"BAR5LegacyIO": false,
"MSICAPMsgData": 0,
"BIST": 0,
"PXCAPDevCtrl2": 0,
"pci_bus": 0,
"InterruptLine": 1,
"fetch_delay": 10000,
"MSICAPMsgAddr": 0,
"BAR3LegacyIO": false,
"BAR4Size": 0,
"path": "system.realview.ethernet",
"MinimumGrant": 255,
"phy_epid": 896,
"Status": 0,
"BAR0Size": 131072,
"system": "system",
"name": "ethernet",
"PXCAPNextCapability": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IGbE",
"tx_fifo_size": 393216,
"PXCAPBaseOffset": 0,
"DeviceID": 4213,
"tx_read_delay": 0,
"CacheLineSize": 0,
"dma": {
"peer": "system.iobus.slave[4]",
"role": "MASTER"
},
"PMCAPCapId": 0,
"tx_desc_cache_size": 64,
"config_latency": 20000,
"BAR1Size": 0,
"pio": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[24]",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"role": "SLAVE"
},
"pci_dev": 0,
"PMCAPCtrlStatus": 0,
"cxx_class": "IGbE",
"wb_delay": 10000,
"fetch_comp_delay": 10000,
"clk_domain": "system.clk_domain",
"SubsystemVendorID": 32902,
"PMCAPBaseOffset": 0,
"MSICAPPendingBits": 0,
"MSIXTableOffset": 0,
"MSICAPMsgUpperAddr": 0,
"MSICAPCapId": 0,
"BAR0LegacyIO": false,
"ProgIF": 0,
"BAR1LegacyIO": false,
"wb_comp_delay": 10000,
"PMCAPCapabilities": 0,
"ClassCode": 2,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"rx_fifo_size": 393216,
"phy_pid": 680
},
"ide": {
"PMCAPNextCapability": 0,
"InterruptPin": 2,
"HeaderType": 0,
"VendorID": 32902,
"MSIXMsgCtrl": 0,
"MSIXCAPNextCapability": 0,
"PXCAPLinkCtrl": 0,
"Revision": 0,
"LegacyIOBase": 0,
"pio_latency": 30000,
"PXCAPLinkCap": 0,
"CapabilityPtr": 0,
"MSIXCAPBaseOffset": 0,
"PXCAPDevCapabilities": 0,
"MSIXCAPCapId": 0,
"BAR3Size": 4,
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPCapabilities": 0,
"SubsystemID": 0,
"PXCAPCapId": 0,
"BAR4": 1,
"BAR1": 1,
"BAR0": 1,
"BAR3": 1,
"BAR2": 1,
"BAR5": 1,
"PXCAPDevStatus": 0,
"disks": [
"system.cf0"
],
"BAR2Size": 8,
"MSICAPNextCapability": 0,
"ExpansionROM": 0,
"MSICAPMsgCtrl": 0,
"BAR5Size": 0,
"CardbusCIS": 0,
"MSIXPbaOffset": 0,
"MSICAPBaseOffset": 0,
"MaximumLatency": 0,
"BAR2LegacyIO": false,
"LatencyTimer": 0,
"BAR4LegacyIO": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPLinkStatus": 0,
"PXCAPDevCap2": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"PXCAPDevCtrl": 0,
"MSICAPMaskBits": 0,
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"host": "system.realview.pci_host",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"Command": 0,
"SubClassCode": 1,
"pci_func": 0,
"BAR5LegacyIO": false,
"MSICAPMsgData": 0,
"BIST": 0,
"PXCAPDevCtrl2": 0,
"pci_bus": 0,
"InterruptLine": 2,
"MSICAPMsgAddr": 0,
"BAR3LegacyIO": false,
"BAR4Size": 16,
"path": "system.realview.ide",
"MinimumGrant": 0,
"Status": 640,
"BAR0Size": 8,
"system": "system",
"name": "ide",
"PXCAPNextCapability": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IdeController",
"ctrl_offset": 0,
"PXCAPBaseOffset": 0,
"DeviceID": 28945,
"io_shift": 0,
"CacheLineSize": 0,
"dma": {
"peer": "system.iobus.slave[3]",
"role": "MASTER"
},
"PMCAPCapId": 0,
"config_latency": 20000,
"BAR1Size": 4,
"pio": {
"peer": "system.iobus.master[23]",
"role": "SLAVE"
},
"pci_dev": 1,
"PMCAPCtrlStatus": 0,
"cxx_class": "IdeController",
"clk_domain": "system.clk_domain",
"SubsystemVendorID": 0,
"PMCAPBaseOffset": 0,
"MSICAPPendingBits": 0,
"MSIXTableOffset": 0,
"MSICAPMsgUpperAddr": 0,
"MSICAPCapId": 0,
"BAR0LegacyIO": false,
"ProgIF": 133,
"BAR1LegacyIO": false,
"PMCAPCapabilities": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"ClassCode": 1,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
}
},
"membus": {
stats: update references
2016-07-21 18:19:18 +02:00
"point_of_coherency": true,
"system": "system",
"response_latency": 2,
"cxx_class": "CoherentXBar",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"badaddr_responder": {
"pio": {
"peer": "system.membus.default",
"role": "SLAVE"
},
"ret_data64": 18446744073709551615,
stats: update references
2016-07-21 18:19:18 +02:00
"fake_mem": false,
"clk_domain": "system.clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"cxx_class": "IsaFake",
"pio_addr": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"update_data": false,
"warn_access": "warn",
"pio_latency": 100000,
"system": "system",
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "IsaFake",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
"power_model": null,
"ret_data32": 4294967295,
"path": "system.membus.badaddr_responder",
"ret_data16": 65535,
"ret_data8": 255,
"name": "badaddr_responder",
"ret_bad_addr": true,
"pio_size": 8,
"p_state_clk_gate_bins": 20
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"forward_latency": 4,
"clk_domain": "system.clk_domain",
"width": 16,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"master": {
"peer": [
"system.bridge.slave",
"system.realview.nvmem.port",
"system.realview.gic.pio",
"system.realview.vgic.pio",
"system.realview.local_cpu_timer.pio",
"system.physmem.port"
],
"role": "MASTER"
},
stats: update references
2016-07-21 18:19:18 +02:00
"type": "CoherentXBar",
"frontend_latency": 3,
"slave": {
"peer": [
"system.realview.hdlcd.dma",
"system.system_port",
"system.cpu.l2cache.mem_side",
"system.iocache.mem_side"
],
"role": "SLAVE"
},
"p_state_clk_gate_min": 1000,
"snoop_filter": null,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.membus",
"snoop_response_latency": 4,
stats: update references
2016-07-21 18:19:18 +02:00
"name": "membus",
"default": {
"peer": "system.membus.badaddr_responder.pio",
"role": "MASTER"
},
"p_state_clk_gate_bins": 20,
"use_default_range": false
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"multi_thread": false,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"iocache": {
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"cpu_side": {
stats: Update to reflect changes to PCI handling
2015-12-05 01:11:25 +01:00
"peer": "system.iobus.master[25]",
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"role": "SLAVE"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"clusivity": "mostly_incl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetcher": null,
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"write_buffers": 8,
"response_latency": 50,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"cxx_class": "Cache",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"size": 1024,
"tags": {
"name": "tags",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
"assoc": 8,
"cxx_class": "LRU",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.iocache.tags",
stats: update references
2016-07-21 18:19:18 +02:00
"hit_latency": 50,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"block_size": 64,
"type": "LRU",
"size": 1024
},
stats: update references
2016-07-21 18:19:18 +02:00
"clk_domain": "system.clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"max_miss_count": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"mem_side": {
"peer": "system.membus.slave[3]",
"role": "MASTER"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"type": "Cache",
"writeback_clean": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"hit_latency": 50,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"tgts_per_mshr": 12,
stats: update references
2016-07-21 18:19:18 +02:00
"demand_mshr_reserve": 1,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"addr_ranges": [
"2147483648:2415919103"
],
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"is_read_only": false,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetch_on_access": false,
"path": "system.iocache",
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"mshrs": 20,
stats: update references
2016-07-21 18:19:18 +02:00
"name": "iocache",
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"assoc": 8
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"dvfs_handler": {
"enable": false,
"name": "dvfs_handler",
"sys_clk_domain": "system.clk_domain",
"transition_latency": 100000000,
"eventq_index": 0,
"cxx_class": "DVFSHandler",
"domains": [],
"path": "system.dvfs_handler",
"type": "DVFSHandler"
},
"work_end_exit_count": 0,
"type": "LinuxArmSystem",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"voltage_domain": {
"name": "voltage_domain",
"eventq_index": 0,
"voltage": [
"1.0"
],
"cxx_class": "VoltageDomain",
"path": "system.voltage_domain",
"type": "VoltageDomain"
},
"cache_line_size": 64,
"boot_osflags": "earlyprintk=pl011,0x1c090000 console=ttyAMA0 lpj=19988480 norandmaps rw loglevel=8 mem=256MB root=/dev/sda1",
stats: update references
2016-07-21 18:19:18 +02:00
"system_port": {
"peer": "system.membus.slave[1]",
"role": "MASTER"
},
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"physmem": [
{
"range": "2147483648:2415919103",
"latency": 30000,
"name": "physmem",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"latency_var": 0,
"bandwidth": "73.000000",
"conf_table_reported": true,
"cxx_class": "SimpleMemory",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.physmem",
"null": false,
"type": "SimpleMemory",
"port": {
"peer": "system.membus.master[5]",
"role": "SLAVE"
},
"in_addr_map": true
}
],
"terminal": {
"name": "terminal",
"output": true,
"number": 0,
"intr_control": "system.intrctrl",
"eventq_index": 0,
"cxx_class": "Terminal",
"path": "system.terminal",
"type": "Terminal",
"port": 3456
},
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"reset_addr_64": 0,
"cpu": [
{
"do_statistics_insts": true,
"numThreads": 1,
"itb": {
"name": "itb",
"is_stage2": false,
"eventq_index": 0,
"cxx_class": "ArmISA::TLB",
"walker": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "walker",
"is_stage2": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "ArmISA::TableWalker",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sys": "system",
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.itb.walker",
"type": "ArmTableWalker",
"port": {
"peer": "system.cpu.toL2Bus.slave[2]",
"role": "MASTER"
},
"num_squash_per_cycle": 2
},
"path": "system.cpu.itb",
"type": "ArmTLB",
"size": 64
},
"simulate_data_stalls": false,
"istage2_mmu": {
"name": "istage2_mmu",
"tlb": "system.cpu.itb",
"sys": "system",
"stage2_tlb": {
"name": "stage2_tlb",
"is_stage2": true,
"eventq_index": 0,
"cxx_class": "ArmISA::TLB",
"walker": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "walker",
"is_stage2": true,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "ArmISA::TableWalker",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sys": "system",
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.istage2_mmu.stage2_tlb.walker",
"type": "ArmTableWalker",
"num_squash_per_cycle": 2
},
"path": "system.cpu.istage2_mmu.stage2_tlb",
"type": "ArmTLB",
"size": 32
},
"eventq_index": 0,
"cxx_class": "ArmISA::Stage2MMU",
"path": "system.cpu.istage2_mmu",
"type": "ArmStage2MMU"
},
"icache": {
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"cpu_side": {
"peer": "system.cpu.icache_port",
"role": "SLAVE"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"clusivity": "mostly_incl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetcher": null,
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"write_buffers": 8,
"response_latency": 2,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"cxx_class": "Cache",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"size": 32768,
"tags": {
"name": "tags",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
"assoc": 1,
"cxx_class": "LRU",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.icache.tags",
stats: update references
2016-07-21 18:19:18 +02:00
"hit_latency": 2,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"block_size": 64,
"type": "LRU",
"size": 32768
},
stats: update references
2016-07-21 18:19:18 +02:00
"clk_domain": "system.cpu_clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"max_miss_count": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"mem_side": {
"peer": "system.cpu.toL2Bus.slave[0]",
"role": "MASTER"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"type": "Cache",
"writeback_clean": true,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"hit_latency": 2,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"tgts_per_mshr": 20,
stats: update references
2016-07-21 18:19:18 +02:00
"demand_mshr_reserve": 1,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"addr_ranges": [
"0:18446744073709551615"
],
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"is_read_only": true,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetch_on_access": false,
"path": "system.cpu.icache",
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"mshrs": 4,
stats: update references
2016-07-21 18:19:18 +02:00
"name": "icache",
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"assoc": 1
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
stats: update references
2016-07-21 18:19:18 +02:00
"function_trace": false,
"do_checkpoint_insts": true,
"cxx_class": "AtomicSimpleCPU",
"max_loads_all_threads": 0,
"system": "system",
"clk_domain": "system.cpu_clk_domain",
"function_trace_start": 0,
"cpu_id": 0,
"width": 1,
"checker": null,
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
"toL2Bus": {
"point_of_coherency": false,
"system": "system",
"response_latency": 1,
"cxx_class": "CoherentXBar",
"forward_latency": 0,
"clk_domain": "system.cpu_clk_domain",
"width": 32,
"eventq_index": 0,
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
"master": {
"peer": [
"system.cpu.l2cache.cpu_side"
],
"role": "MASTER"
},
"type": "CoherentXBar",
"frontend_latency": 1,
"slave": {
"peer": [
"system.cpu.icache.mem_side",
"system.cpu.dcache.mem_side",
"system.cpu.itb.walker.port",
"system.cpu.dtb.walker.port"
],
"role": "SLAVE"
},
"p_state_clk_gate_min": 1000,
"snoop_filter": {
"name": "snoop_filter",
"system": "system",
"max_capacity": 8388608,
"eventq_index": 0,
"cxx_class": "SnoopFilter",
"path": "system.cpu.toL2Bus.snoop_filter",
"type": "SnoopFilter",
"lookup_latency": 0
},
"power_model": null,
"path": "system.cpu.toL2Bus",
"snoop_response_latency": 1,
"name": "toL2Bus",
"p_state_clk_gate_bins": 20,
"use_default_range": false
},
"do_quiesce": true,
"type": "AtomicSimpleCPU",
"fastmem": false,
"profile": 0,
"icache_port": {
"peer": "system.cpu.icache.cpu_side",
"role": "MASTER"
},
"p_state_clk_gate_bins": 20,
"p_state_clk_gate_min": 1000,
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"interrupts": [
{
"eventq_index": 0,
"path": "system.cpu.interrupts",
"type": "ArmInterrupts",
"name": "interrupts",
"cxx_class": "ArmISA::Interrupts"
}
],
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"dcache_port": {
"peer": "system.cpu.dcache.cpu_side",
"role": "MASTER"
},
"socket_id": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"max_insts_all_threads": 0,
"dstage2_mmu": {
"name": "dstage2_mmu",
"tlb": "system.cpu.dtb",
"sys": "system",
"stage2_tlb": {
"name": "stage2_tlb",
"is_stage2": true,
"eventq_index": 0,
"cxx_class": "ArmISA::TLB",
"walker": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "walker",
"is_stage2": true,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "ArmISA::TableWalker",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sys": "system",
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.dstage2_mmu.stage2_tlb.walker",
"type": "ArmTableWalker",
"num_squash_per_cycle": 2
},
"path": "system.cpu.dstage2_mmu.stage2_tlb",
"type": "ArmTLB",
"size": 32
},
"eventq_index": 0,
"cxx_class": "ArmISA::Stage2MMU",
"path": "system.cpu.dstage2_mmu",
"type": "ArmStage2MMU"
},
"l2cache": {
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"cpu_side": {
"peer": "system.cpu.toL2Bus.master[0]",
"role": "SLAVE"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"clusivity": "mostly_incl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetcher": null,
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"write_buffers": 8,
"response_latency": 20,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"cxx_class": "Cache",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"size": 4194304,
"tags": {
"name": "tags",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
"assoc": 8,
"cxx_class": "LRU",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.l2cache.tags",
stats: update references
2016-07-21 18:19:18 +02:00
"hit_latency": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"block_size": 64,
"type": "LRU",
"size": 4194304
},
stats: update references
2016-07-21 18:19:18 +02:00
"clk_domain": "system.cpu_clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"max_miss_count": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"mem_side": {
"peer": "system.membus.slave[2]",
"role": "MASTER"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"type": "Cache",
"writeback_clean": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"hit_latency": 20,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"tgts_per_mshr": 12,
stats: update references
2016-07-21 18:19:18 +02:00
"demand_mshr_reserve": 1,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"addr_ranges": [
"0:18446744073709551615"
],
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"is_read_only": false,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetch_on_access": false,
"path": "system.cpu.l2cache",
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"mshrs": 20,
stats: update references
2016-07-21 18:19:18 +02:00
"name": "l2cache",
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"assoc": 8
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"path": "system.cpu",
"max_loads_any_thread": 0,
"switched_out": false,
"workload": [],
"name": "cpu",
"dtb": {
"name": "dtb",
"is_stage2": false,
"eventq_index": 0,
"cxx_class": "ArmISA::TLB",
"walker": {
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "walker",
"is_stage2": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"cxx_class": "ArmISA::TableWalker",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sys": "system",
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.dtb.walker",
"type": "ArmTableWalker",
"port": {
"peer": "system.cpu.toL2Bus.slave[3]",
"role": "MASTER"
},
"num_squash_per_cycle": 2
},
"path": "system.cpu.dtb",
"type": "ArmTLB",
"size": 64
},
"simpoint_start_insts": [],
"max_insts_any_thread": 0,
"simulate_inst_stalls": false,
"progress_interval": 0,
"branchPred": null,
"dcache": {
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"cpu_side": {
"peer": "system.cpu.dcache_port",
"role": "SLAVE"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"clusivity": "mostly_incl",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetcher": null,
stats: update references
2016-07-21 18:19:18 +02:00
"system": "system",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"write_buffers": 8,
"response_latency": 2,
stats: updates due to recent changesets including d0934b57735a
2015-09-15 15:14:09 +02:00
"cxx_class": "Cache",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"size": 32768,
"tags": {
"name": "tags",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
"default_p_state": "UNDEFINED",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"clk_domain": "system.cpu_clk_domain",
stats: update references
2016-07-21 18:19:18 +02:00
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
"assoc": 4,
"cxx_class": "LRU",
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"path": "system.cpu.dcache.tags",
stats: update references
2016-07-21 18:19:18 +02:00
"hit_latency": 2,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"block_size": 64,
"type": "LRU",
"size": 32768
},
stats: update references
2016-07-21 18:19:18 +02:00
"clk_domain": "system.cpu_clk_domain",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"max_miss_count": 0,
"eventq_index": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"default_p_state": "UNDEFINED",
"p_state_clk_gate_max": 1000000000000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"mem_side": {
"peer": "system.cpu.toL2Bus.slave[1]",
"role": "MASTER"
},
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"type": "Cache",
"writeback_clean": false,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_min": 1000,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"hit_latency": 2,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"tgts_per_mshr": 20,
stats: update references
2016-07-21 18:19:18 +02:00
"demand_mshr_reserve": 1,
"power_model": null,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"addr_ranges": [
"0:18446744073709551615"
],
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"is_read_only": false,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"prefetch_on_access": false,
"path": "system.cpu.dcache",
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"mshrs": 4,
stats: update references
2016-07-21 18:19:18 +02:00
"name": "dcache",
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"sequential_access": false,
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"assoc": 4
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"isa": [
{
"pmu": null,
"id_pfr1": 4113,
"id_pfr0": 49,
"id_isar1": 34677009,
"id_isar0": 34607377,
"id_isar3": 17899825,
"id_isar2": 555950401,
"id_isar5": 0,
"id_isar4": 268501314,
"cxx_class": "ArmISA::ISA",
"id_aa64mmfr1_el1": 0,
"id_aa64pfr1_el1": 0,
"system": "system",
"eventq_index": 0,
"type": "ArmISA",
"id_aa64dfr1_el1": 0,
"fpsid": 1090793632,
"id_mmfr0": 270536963,
"id_mmfr1": 0,
"id_mmfr2": 19070976,
"id_mmfr3": 34611729,
"id_aa64mmfr0_el1": 15728642,
"id_aa64dfr0_el1": 1052678,
"path": "system.cpu.isa",
"id_aa64isar0_el1": 0,
stats: updates due to recent chagnesets
2015-11-16 12:08:57 +01:00
"decoderFlavour": "Generic",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"name": "isa",
"midr": 1091551472,
"id_aa64afr0_el1": 0,
"id_aa64isar1_el1": 0,
"id_aa64afr1_el1": 0,
stats: update references
2016-08-02 12:34:32 +02:00
"id_aa64pfr0_el1": 34
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
}
],
"tracer": {
"eventq_index": 0,
"path": "system.cpu.tracer",
"type": "ExeTracer",
"name": "tracer",
"cxx_class": "Trace::ExeTracer"
}
}
],
"gic_cpu_addr": 738205696,
"work_cpus_ckpt_count": 0,
stats: update stats for thermals, indirect BP
2016-04-08 18:01:45 +02:00
"thermal_components": [],
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"machine_type": "VExpress_EMM",
"flags_addr": 469827632,
"path": "system",
"cpu_clk_domain": {
"name": "cpu_clk_domain",
"clock": [
500
],
"init_perf_level": 0,
"voltage_domain": "system.voltage_domain",
"eventq_index": 0,
"cxx_class": "SrcClockDomain",
"path": "system.cpu_clk_domain",
"type": "SrcClockDomain",
"domain_id": -1
},
"cf0": {
"driveID": "master",
"name": "cf0",
"image": {
"read_only": false,
"name": "image",
"cxx_class": "CowDiskImage",
"eventq_index": 0,
"child": {
"read_only": true,
"name": "child",
"eventq_index": 0,
"cxx_class": "RawDiskImage",
"path": "system.cf0.image.child",
stats: update references
2016-07-21 18:19:18 +02:00
"image_file": "/arm/projectscratch/randd/systems/dist/disks/linux-aarch32-ael.img",
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"type": "RawDiskImage"
},
"path": "system.cf0.image",
"image_file": "",
"type": "CowDiskImage",
"table_size": 65536
},
"delay": 1000000,
"eventq_index": 0,
"cxx_class": "IdeDisk",
"path": "system.cf0",
"type": "IdeDisk"
},
stats: Update ARM stats to include programmable oscillators
2015-08-07 16:39:17 +02:00
"work_end_ckpt_count": 0,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"mem_mode": "atomic",
"name": "system",
"init_param": 0,
stats: update references
2016-07-21 18:19:18 +02:00
"p_state_clk_gate_bins": 20,
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
"load_addr_mask": 268435455,
"work_item_id": -1,
"intrctrl": {
"name": "intrctrl",
"sys": "system",
"eventq_index": 0,
"cxx_class": "IntrControl",
"path": "system.intrctrl",
"type": "IntrControl"
},
"have_security": false,
"atags_addr": 134217728,
"memories": [
"system.physmem",
"system.realview.nvmem",
"system.realview.vram"
],
stats: update stats to after GPU checkin
2016-01-22 16:42:13 +01:00
"num_work_ids": 16,
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
"boot_loader": [
stats: update references
2016-07-21 18:19:18 +02:00
"/arm/projectscratch/randd/systems/dist/binaries/boot_emm.arm"
stats: Update to reflect changes to RealView platform code
2015-12-04 01:19:05 +01:00
],
stats: update stats to after GPU checkin
2016-01-22 16:42:13 +01:00
"exit_on_work_items": false
test, arm: Add scripts to test checkpoints Add a set of scripts to automatically test checkpointing in the regression framework. The checkpointing tests are similar to the switcheroo tests, but instead of switching between CPUs, they checkpoint the system and restore from the checkpoint again. This is done at regular intervals, typically while booting Linux. The implementation is fairly straight forward, with the exception that we have to work around gem5's inability to restore from a checkpoint after a system has been instantiated. We work around this by forking off child processes that does the actual simulation and never instantiate a system in the parent process unless a maximum checkpoint count is reached (in which case we just simulate the system to completion in the parent). Checkpoint testing is currently only enabled 32- and 64-bit ARM systems using atomic CPUs. Note: An unfortunate side-effect of forking is that every new process will overwrite the stats and terminal output from the previous process. This means that the output directory only contains data from the last checkpoint.
2015-03-19 09:06:20 +01:00
},
"time_sync_period": 100000000000,
"eventq_index": 0,
"time_sync_spin_threshold": 100000000,
"cxx_class": "Root",
"path": "root",
"time_sync_enable": false,
"type": "Root",
"full_system": true
}
Reference in a new issue Copy permalink