key not found: SPATIAL_HOME

[Minnie Ho]

My basic bug in setting up Spatial is a missing SPATIAL_HOME.

Anyone seen this error before?   

When I run:  /bin/spatial HelloSpatial --sim, I get the following error:

key not found: SPATIAL_HOME

[Minnie Ho]

Hi all,

I'm trying to get the basic Matrix Multiply from the Spatial tutorials to compile:

I installed spatial-quickstart, and I added the following program from the Spatial website to /src/main/scala:

https://spatial-lang.org/gemm

This gives me a compilation error.  I'm not sure if my installation is incorrect - does anyone have a suggestion?

[Ruizhe Zhao]

Hi, I've met this problem before and got it fixed by following the compiler error message, i.e., I add `.buffer` after the `SRAM` declaration. However, I'm not sure whether it should be `buffer` or `nonbuffer`.

[Matt F]

Hi Minnie,

The installation is correct.  You probably have a pattern that looks like this in the app (after the MemFold/MemReduce/load/store syntax is boiled down to accesses):

Pipeline{
  Stage0 {tileC(i,j) = ...}
  ...
  Stage1 {tileC(i,j) = tileC(i,j) + ...}
  ...
  Stage2 {... = tileC(i,j)}
}

The compiler crashes with the buffering error because it wants to know if the programmer actually intended to write to a memory at different stages of a pipeline.  In this case, that is the intended behavior, since you initialize a tile, accumulate on that tile, and then store the tile back to dram.  Adding .buffer is the correct thing to do here.  You basically have three different tiles of DRAM in-flight, and they can all be processed independently

If you had a case where you need some kind of coherency between the stages of the pipeline (i.e. random reads and random updates, or different stages operate on different regions of tileC), then you would not want the compiler to create three independent buffers of the memory.  As a programmer, you know that there needs to be one global view of tileC across all stages of the pipeline, and that the app is programmed so that there are no conflicts at runtime.  This is where you would use .nonbuffer.

The .buffer case is the most common, but we decided to make the compiler crash with this error to confirm the programmer knows what kind of buffering is going on.  Most apps write to a memory in an early stage of a pipeline, and read from it at a later stage.  Having writes occur at multiple stages can cause the program to have unexpected, incorrect answers if the programmer is not thinking in terms of pipelining and buffering.  For example, something that looks like this would give different results depending on how many stages are between the two accesses:

Pipeline{
 Stage0 {... = tileC(i,j)}
 ...
 StageN {tileC(i,j) = ...}
}