harvard-acc/gem5-aladdin

How to fix error; build/X86/gem5.opt configs/example/se.py -c tests/test-progs/hello/bin/x86/linux/hello

peterhchen opened this issue · 49 comments

peterhchen commented

in /workspace/gem5-addlin,

build/X86/gem5.opt configs/example/se.py -c tests/test-progs/hello/bin/x86/linux/hello
Error:
AttributeError: Values instance has no attribute 'accel_cfg_file'
How to fix this error?
071_CompileRun_Gem5_Aladdin_C_code_CommonZone.pptx

xyzsam commented

Can you try configs/example/aladdin_se.py instead?

peterhchen commented

i complied already.
I fixed this by:

build/X86/gem5.opt configs/aladdin/aladdin_se.py -c tests/test-progs/hello/bin/x86/linux/hellp

Hello World!
See below attached document/
071_CompileRun_Gem5_Aladdin_C_code_CommonZone_V02.pptx
d!

peterhchen commented

For me, it seems two steps for all designs (written in C code):

  1. Use gcc to compile the c code into binary code.
  2. Use gem5.opt with aladdin_se.py to setup the X86 architecture.
  3. there is addition configuration L1 Cache, L2 Cache, etc. which is independent for step 1 and step 2?
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
xyzsam commented

gem5-aladdin/configs/example:
No aladdin_se.py.

Sorry, I meant configs/aladdin/aladdin_se.py, but you figured this out already.

In test_load_store.c, how to print a message in the application?

printf("Hello test_load_store\n");

Yes.

there is addition configuration L1 Cache, L2 Cache, etc. which is independent for step 1 and step 2?

Yes, it depends on what you want to do. If you just want to adjust the cache sizes on the CPU cluster, there are flags to do this, see here. If you want to modify the cache sizes on the accelerator, this is done via the gem5.cfg file.

I modify the c file and make.
It has the error when include the *h
Cannot find the include header in the test_load_store

Without attaching the patch you made to the file and including instructions on how you are attempting to build, there is no way I can help debug your problem.

peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
xyzsam commented

The instructions to build the integration tests are not clear, I agree. Here are the Make targets you have available:

  • gem5-cpu: Builds a version of the binary that runs on the CPU in gem5
  • gem5-accel: Builds a version of the binary that runs the accelerated function in Aladdin and the rest on the CPU.
  • gem: Builds both gem5-cpu and gem5-accel.
  • dma-trace-binary: Builds a version of the binary that is instrumented with LLVM-Tracer. Run this binary to generate a new dynamic_trace.gz. This binary is NOT meant to be simulated in gem5, so do not replace this with test_load_store - they serve completely different purposes.

So to rebuild and rerun a simulation of one of the integration tests:

> make clean
> make dma-trace-binary
> ./test_load_store-instrumented
# This will generate a new dynamic_trace.gz
> make gem5-accel
> sh run.sh
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
peterhchen commented
xyzsam commented

For some reason GitHub notifications are not working for me so I was not aware of any of these comments. Sorry for the very delayed response. I just happened to think about this issue today. I've gotten a bit lost on where you are at the moment, but I'll try.

  1. test_mmap: this actually does not involve an accelerator, which is why there is no dynamic trace generated. It simply tests that the emulated mmap syscall function works as intended.
  2. You have indicated some assertion failures in a few of the integration tests; however, you attached an image, and those images are missing from the comments. Please include the text of the assertion instead of a screenshot.
  3. Regarding cache area: this is estimated from CACTI, which requires a configuration file that specifies all the parameters of the cache. Unfortunately this is a poorly integrated aspect of gem5-aladdin: if you change flags like --l1d_size, gem5 does not update the CACTI configuration file, so you don't see any change in area. You'll need to update the config files like test_cacti_cache.cfg, or make a copy of them for your project and set them appropriately.
  4. The common directory is simply to store CACTI configuration files that all the integration tests share.
peterhchen commented
peterhchen commented
peterhchen commented
xyzsam commented

Is this "size 65536" equal to "the sum of all l1i_size, l1d_size, l2_size,
l3_size, etc.?"
If not, what is the relationship of "size 65536" with "i_size, l1d_size,
l2_size, l3_size, etc."?

This is just the size for the L1 cache for the accelerator. It has nothing to do with i_size, l1d_size, etc - those are for the CPU. The L1 cache for the accelerator (if it is used) is configured via the gem5.cfg file.

It's possible for you to add more caches to your accelerator but for power modeling purposes in Aladdin, we only handle the first level cache (there's an infinite number of possibilities).

Regarding cache area: this is estimated from CACTI, which requires a
configuration file that specifies all the parameters of the cache.
Unfortunately this is a poorly integrated aspect of gem5-aladdin: if you
change flags like --l1d_size, gem5 does not update the CACTI configuration
file, so you don't see any change in area. You'll need to update the config
files like test_cacti_cache.cfg, or make a copy of them for your project
and set them appropriately

Indeed, this is not well integrated; however, note that by default, gem5 does not provide any power modeling capabilities to begin with. All those flags you mentioned apply to the CPUs, not to the accelerators. gem5-aladdin only models power for the accelerator subsystem; if you want to include CPU power you'll need to handle that yourself. I wrote a ton of scripts in the past to do this for my projects (but they're not very reusable and I don't have access to them anymore).

There in the common directory, there are cache.cfg, lq.cfg (Load Queue),
sq.cfg (Store Queue), and tlb.cfg (table lookahead buffer).
Which parameters in run.sh will be associated with these sizes?, such as,
l1i, l1d, l2, l3 size sum to get cache size? and etc?

These are all set in the gem5.cfg file. They apply to the accelerator only, and ONLY when using the caches instead of scratchpads for local memory.

peterhchen commented
peterhchen commented
xyzsam commented

gem5-aladdin does not support ARM or RISC-V and we don't have plans to add support. Although that is a popular feature request, it's not something we have the time to commit to building and maintaining, unfortunately.

peterhchen commented
peterhchen commented
xyzsam commented

I assume you want to simulate a workload running on an ARM or RISC-V system. If so, then the answer is no, we do not support it. X86 as you have described ("the running platform we are currenlty using right now") is the host architecture. That does not matter here as you can compile gem5 to run on an ARM system too. What matters is the simulated architecture. We only support simulating X86.

peterhchen commented
peterhchen commented
xyzsam commented

The purpose of using gem5-aladdin instead of regular gem5 is the ability to simulate loosely-attached accelerators in the SoC. The CPU needs to communicate with the accelerator. For this, we have only tested with X86. It's possible to make this work with other ISAs of course, but we don't have the time to do it, and I'm not sure how much effort would be required.

peterhchen commented
peterhchen commented
peterhchen commented
xyzsam commented

I test l3_size and L3_assoc. There is no effect for L3_size and L3_assoc?

gem5-aladdin's default system only contains L1 and L2 caches. You can modify this yourself to add a third level cache if you want.

cacti tlb size, lq size, sq size, l3_size, and l3_assoc have no effect on output.

The CACTI config files are only used for power estimation. If you want to see the effect on IPC, you need to change them in gem5.cfg.

For CUP type: only DerivO3CPU and TimingSimpleCPU worked. Others, caused the core dumped in test_store_load.c [image: image.png]

Again, I cannot see the image you attached, please paste the text of the core dump. I know we use one CPU type for fast forwarding and another for detailed simulation.

For the memory type below, the OK list are worked. Others causes core dumped in test_load_store.c [image: image.png]

Again, cannot see the image. Please paste the text of the error, not a screenshot.

peterhchen commented
peterhchen commented
peterhchen commented