.cfg files and accelerator memory

425 views
Skip to first unread message

mar...@stanford.edu

unread,
Feb 19, 2018, 10:36:50 PM2/19/18
to gem5-Aladdin users
Hi,

I have three questions:

1) Is there documentation as to the format of Aladdin .cfg files? I've seen some information on the Aladdin GitHub readme, but the information provided does not appear to explain all possibilities (partition, spad, cache, cyclic, complete, etc.). I have also read the Aladdin and gem5-aladdin workshop slides. I'm not sure what these mean, and I'm not sure what all the available possibilities for configuration are.

2) I have an error that says two arrays' address ranges overlap in the accelerator memory. Is there a way for me to move one of the arrays in memory?

3) The simulator is forcing me to allocate accelerator memory in the .cfg for variables/arrays that I do not see in any code I am running. Do you know why this may be? Please see code snippet from .cfg below. These lines got rid of the errors.

partition,complete,.01,1000

partition,complete,.0,1000

partition,complete,st.1,1000

partition,complete,1,1000

partition,complete,Fout0.06,1000

partition,complete,.1,1000



Thank you,

Mark

Sam Xi

unread,
Feb 20, 2018, 12:21:28 AM2/20/18
to mar...@stanford.edu, gem5-Aladdin users
Hi Mark,

Thanks for your questions. I agree that we need documentation for your questions - they are asked quite often and aren't immediately clear or at all obvious in some cases. We'll get on it.

As for the configuration file: the format is pretty simple. The types of partitioning are explained here. We directly used the terminology from Vivado HLS in this case.

The format of the partition lines are:
partition,cyclic,array_name,array_size_in_bytes,element_size_in_bytes,partition_factor
partition,block,array_name,array_size_in_bytes,element_size_in_bytes,partition_factor
partition,complete,array_name,array_size_in_bytes,element_size_in_bytes

so, as an example, an array declared like int myarray[32] would have array_size_in_bytes = 32*4 = 128, element_size_in_bytes=4, and partition_factor whatever you wanted it to be (generally pick a power of 2).

The loop unrolling/pipelining lines are also pretty simple - the first term describes what you want to do. Again, see  here for details.

unrolling,function_name,loop_label,unrolling_factor
flatten,function_name,loop_label
pipeline,function_name,loop_label

Keep in mind that even if you don't want to unroll a loop (i.e. loop unrolling factor = 1), it MUST be specified as so in the cfg file, or Aladdin will actually flatten the loop by default due to the way it constructs the initial DDG.

Your array address ranges: that means that two arrays detected by Aladdin overlap in their base address + size. You'll want to be careful if you are accessing one of those two arrays. The base address is the actual virtual address of that pointer when you were building the trace.

As for your mysterious variable names: if you see strange names like ".01", "someword.somenumber", etc, which don't appear in your code, those are LLVM's autogenerated register names. This is because of an Aladdin coding style restriction: you cannot assign a pointer to another variable and dereference it via that variable, or Aladdin won't be able to associate the original array name (which has an SRAM structure backing it) to that memory access. As an example:

void foo(int* array) {
    int value = array[1];  // this is OK.
    int offset = /* some value */;
    value = array[offset + 4];  // this is OK.

    int* newptr = array;
    value = newptr[1];  // NOT OK. this may cause LLVM to generate a temporary variable with an arbitrary name that you're seeing.
    int* newptr2 = array + 4;
    value = newptr2[4];  // NOT OK. same reason here.
}

void bar(int* myarray) {
    foo(myarray);  // this is OK: aladdin knows that myarray in function bar == array in function foo.
    foo(&myarray[4]);   // NOT OK; Aladdin will not be able to resolve memory accesses in foo() correctly. you would need to pass 4 as an separate function argument.
}

So in short: all memory operations within a function that is being turned into HW must be based from the original pointer that was passed to the top level function.

Sam

--
You received this message because you are subscribed to the Google Groups "gem5-Aladdin users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gem5-aladdin-us...@googlegroups.com.
To post to this group, send email to gem5-alad...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gem5-aladdin-users/8971e093-3626-455d-a4e0-7ff391626f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Thanks,

Sam Xi
Harvard University
Computer Science, Ph.D. Candidate

mar...@stanford.edu

unread,
Feb 20, 2018, 11:57:42 AM2/20/18
to gem5-Aladdin users
Sam,

Thank you so much for your quick response and thorough answer. I appreciate it!

All the best,

Mark
To unsubscribe from this group and stop receiving emails from it, send an email to gem5-aladdin-users+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages