stanfordaha / cgraflow Goto Github PK

install.sh should prompt the user to edit their shell configuration file (e.g. .bashrc) and append the proper configuration commands (e.g. exporting environment variables).

Test infrastructure should be generic over simulators, which will allow designers to use their simulator of choice. In particular, we should be able to run the end-to-end Halide->CGRA flow using ncsim and verilator.

Requested by @cdonovick

@jameshegarty, @phanrahan, and I had discussed using submodules. Our main concern was that they would require an explicit PR to bump the submodule commit whenever a repo pushed changes to master. If the person responsible for initiating this PR did not do it, the flow could be silently broken (that is, if they had bumped the submodule commit, we would've seen the flow break). In our current model, the nightly run would catch an offending master branch that has broken the flow, so if we have a silent breakage, at least it only lasts less than 24 hours.

Using submodules could work, but I believe it would require that we institute and enforce a policy that any changes to a master branch be accompanied by a PR to bump the submodule commit in the CGRAFlow repo.

I'd be open to hearing other solutions that prevent the flow from being broken silently.

We can use derp

Halide Changes: updated library file, fixed linebuffer issue
CoreIR Changes: Mostly changes with verilog generation
Mapper Changes: Fixes ASHR, and mux issues. Now only outputs configuration strings (instead of bits)
PnR/bitstream generator (TODO) correctly parse PE configuration from mapper.

The configuration strings should exactly conform to what is in the CGRAGenerator wiki for PE (as requested from Keyi)
@Kuree, @steveri, please update your repos to conform to this, and use the examples from the mapper dev branch to test these changes.

• Characterize a set of target applications
  • Data types (frequency)
  • Operations
  • Memory access patterns (if easy)
    • Arithmetic intensity (how many ops on a single element of data)
• Create a set of applications of interest

See build 165 https://travis-ci.org/StanfordAHA/CGRAFlow/builds/220647889

$ make -C apps/coreir_examples/pointwise/ clean design_top.json out.png

make: Entering directory `/home/travis/build/StanfordAHA/CGRAFlow/Halide_CoreIR/apps/coreir_examples/pointwise'
rm -f pipeline run run_zynq
rm -f out.png out_zynq.png
rm -f pipeline_native.h pipeline_native.o
rm -f pipeline_hls.h pipeline_hls.cpp hls_target.h hls_target.cpp
rm -f pipeline_coreir.h pipeline_coreir.cpp
rm -f pipeline_cuda.h pipeline_cuda.o
rm -f pipeline_zynq.h pipeline_zynq.c pipeline_zynq.o run_zynq.o
rm -f rigel_target.h rigel_target.t coreir_target.h coreir_target.t
rm -f *.html *.json
g++-4.9 -std=c++11 -I ../../../include/ -I ../../../tools/ -I ../../../apps/support/  -Wall -g pipeline.cpp ../../../lib/libHalide.a /home/travis/build/StanfordAHA/CGRAFlow/coreir/build/coreir.a -o pipeline  -ldl -lpthread -lz -ltinfo 
../../../lib/libHalide.a(CodeGen_CoreIR_Testbench.o): In function `getStdlib(CoreIR::Context*)':
CodeGen_CoreIR_Testbench.cpp:(.text._Z9getStdlibPN6CoreIR7ContextE+0x15a): undefined reference to `CoreIR::Namespace::newTypeGen(std::string, std::string, std::unordered_map<std::string, CoreIR::Param, std::hash<std::string>, std::equal_to<std::string>, std::allocator<std::pair<std::string const, CoreIR::Param> > >, CoreIR::Type* (*)(CoreIR::Context*, std::unordered_map<std::string, CoreIR::Arg*, std::hash<std::string>, std::equal_to<std::string>, std::allocator<std::pair<std::string const, CoreIR::Arg*> > >, std::unordered_map<std::string, CoreIR::Param, std::hash<std::string>, std::equal_to<std::string>, std::allocator<std::pair<std::string const, CoreIR::Param> > >))'
CodeGen_CoreIR_Testbench.cpp:(.text._Z9getStdlibPN6CoreIR7ContextE+0x273): undefined reference to `CoreIR::Namespace::newGeneratorDecl(std::string, std::unordered_map<std::string, CoreIR::Param, std::hash<std::string>, std::equal_to<std::string>, std::allocator<std::pair<std::string const, CoreIR::Param> > >, CoreIR::TypeGen*)'
collect2: error: ld returned 1 exit status
make: *** [pipeline] Error 1
make: Leaving directory `/home/travis/build/StanfordAHA/CGRAFlow/Halide_CoreIR/apps/coreir_examples/pointwise'

The command "make -C apps/coreir_examples/pointwise/ clean design_top.json out.png" exited with 2.

Since https://github.com/phanrahan/pe has now been integrated into the testing flow, I propose that we migrate the spec to be in the pe package. This resolves issues such as https://github.com/StanfordAHA/CGRAGenerator/pull/43 where there is a mismatch between the "spec" (Google Doc), the verilog, and the pe definition. We should maintain a single copy of the spec, and since the pe Python package is used to test, I propose we use that. It can generate collateral to be used by genesis (such as a table), so that the implementation can programmatically reflect the spec.

• Rebase on top of tree
• Leverage analysis
• Merge Xuan/Jeff's codebases

• install.sh will install system-level dependencies. These are third party dependencies that can be retrieved via apt-get on Ubuntu and theoretically brew install on MacOS. This will also install a system level copy of internal dependencies such as the coreir binaries.

• setup.sh will setup a local development environment that is unique for each user. This includes a Python virtual environment.

Open to comments on the naming scheme and partitioning of roles for the two scripts, but this should move us closer towards easily setting up local dev environments.

• CoreIR definitions of the PE primitives
• Simulate the post mapped graph
• Formally verify the post mapped graph

Pat recommended (and I agree) that we clean up the travis script by wrapping each flow stage into a called or sourced shell script e.g. instead of

  - git clone https://github.com/jeffsetter/Halide_CoreIR.git
  - export CXX=${CXX_}
  - export CC=${CC_}
  - export LLVM_CONFIG=${TRAVIS_BUILD_DIR}/llvm/bin/llvm-config
  - export CLANG=${TRAVIS_BUILD_DIR}/llvm/bin/clang
  - export CORECONFIG="g++-4.9"
  - export COREIR_DIR=${TRAVIS_BUILD_DIR}/coreir

it might read something like

  - echo "INSTALL COREIR"
  - git clone https://github.com/jeffsetter/Halide_CoreIR.git
  - echo "Setup env vars (CXX, CC, LLVM_CONFIG...)"
  - source Halide_CoreIR/.travis_before_install.sh

Also, there seems to be some leftover script bits that are not directly related to the current CGRA flow, e.g. see below. Could someone (James?) please verify that these are no longer required and if so maybe remove them. Thanks!

> before_install:
>   - echo "INSTALL RIGEL"
>   - git clone https://github.com/jameshegarty/rigel.git
>   - export PKG_CONFIG_PATH=${TRAVIS_BUILD_DIR}/rigel/platform/verilator
>   - pkg-config --cflags verilator
>   - pkg-config --variable=includedir verilator
> 
> script:
>    # coreir
>   - cd coreir/tests
>   - ./run
>   - pytest  # Test python bindings
>   - cd ../..
>   
>     # rigel
>   - cd rigel/examples
>   - make out/pointwise_wide_handshake.verilator.bmp
>   - cd ../../

In Jeff's app spreadsheet (https://docs.google.com/spreadsheets/d/1GLqlCGaTXMDLW3QqCXK0XX1zOzP0UyoJ9eXDo75xpDg/edit#gid=0) in addition to the working/not working status for the apps, it would be useful to report some metrics for the apps running on the current CGRA that will inform design decisions for the next CGRA, for example

• Utilization for
  • PE
  • Memory
  • Routing
• Clock frequency
• Throughput (pixels processed per clock cycle)
• Latency (in clock cycles)
• Energy per pixel
  • For this we need to generate a switching activity file
• Some description of the inputs of the app like frame size, precision, etc,
• Breakdown between configuration cycles and processing cycles

coreir-dev branch is using an out of date pycoreir (master). Could we extract specifying the version of this up to the install.sh script in the flow? I need to use pycoreir based on dev.

Because apt requirements are not listed in .travis.yml but instead in install.sh we lose out on the ability to cache apt packages.

We want to be able to express the schedule at a higher level in a way that is more intuitive and translate it into a lower level schedule that uses as much of the built-in Halide primitives as is reasonable.

Cast scheduling problem into SMT setting.

Due to: rdaly525/coreir#161

CoreIR Dev (Lots and lots of new features and a few API changes)
is being merged into master. This will definitely affect @jeffsetter and myself (mapper) and might affect @cdonovick

@jeffsetter, @cdonovick Can you both get your stuff working with coreir dev branch?

• Test coreir output of halide compiler using simulation or formal verification (against x86 halide backend)

Everybody please tell what hacks they used to get the flow working, that we will need to fix/address later.

This issue will deal with trying to merge in changes from CoreIR and the mapper to interface with both Halide and P&R.

High level overview of changes:
Added back in generators into json file.
Added CGRA primitives
Changed bin to lib (because shared libraries should probably be in lib)
Some minor API changes to make names more consistent.
A chunk of API additions.

My changes are in
coreir: branch 'dev'
mapper: branch 'cgralib'

@jeffsetter (likely changes)
bin is now lib.
includes may be slightly different (check in one of the tests)
Some minor API name changes and a few api additions.
-addDef -> setDef,
-Can now do something like def->wire("self.in.0","in0.data.in.1")
-Slight difference in how you define generators (come talk to me)

@cdonovick (likely changes)
bin is now lib
Added back generators into the json file. This means you will need to do a call to load_library("cgralib") and potentially load_library("stdlib") before you load the json file.
Changed some API names to be less confusing get_ancestors -> get_selectpath

There are probably other things, but stay on slack and we can figure them all out!

Thanks again!

Jeff, please create a branch for your stuff and then verify using the coreir/libreorg branch of CGRAFlow

items that will likely need to be fixed:

Add to Makefile:
Add -lcoreir -lcoreir-stdlib -lcoreir-passes (Make sure to add at END of command)
Add -L<Path to coreir/bin>
Add -I<Path to coreir/incldue>

change getStdlib -> CoreIRLoadLibrary_stdlib
Look at one of my tests (coreir/tests/unit/*.cpp) to see how to redo your includes for cpp/hpp files

• Merge Pat's PE testing infrastructure into CGRAGenerator
• Abstract simulator used for testing (should be able to swap ncsim with verilator)

When Jeff changes the name of the const from "const" to "const_186" the flow breaks. I (steveri) added a hack in the travis script to undo the name, but this is of course not the right fix. I suspect the problem is either in the mapper or in one of the pnr scripts, respectively. You can see source for working and non-working design_top.json in builds 145 (https://travis-ci.org/StanfordAHA/CGRAFlow/builds/219574814) and 146 (https://travis-ci.org/StanfordAHA/CGRAFlow/builds/219898992) respectively---the only difference is one line where the working version says "const" and the nonworking version says "const_186"

diff design_top_145.json design_top_146.json
< "const"

"const_186"

• Random stalls

  • find issues that are asynchronous (events) not necessarily datapath
  • different stall cases
  • different configurations
  • watchpoints
  • randomly stall a suite of tests

• (From SR) It would be great if, along with "random" and "complete" vectors, you could also generate random-ish directed vectors centered on or around various combinations of MAXINT, MININT and zero, since this often creates the corner cases where ALU's trip up...

As has been requested for while can we please move to TTTT FF RR instead of RR FF TTTT address format. This is supported by P&R.

https://travis-ci.org/StanfordAHA/CGRAFlow/builds/344582583

Filing an issue on myself - I will get rid of my timer and bypass hacks in favor of a cleaner travis script (also I think the existing script is sufficiently agile that I don't need it anymore anyway (which is the preferred solution)).

• add PE spec information to cgra_info.txt (Taeyoung)
• use PE info from cgra_info.txt in unit tests (Lenny)

@rdaly525 and I had an initial discussion about this.

It would speed things up by avoiding having to compile coreir, but then depend on the fact that release binary is maintained to be in sync with coreir's master branch.

An alternative that I proposed is a fast branch that uses the current coreir release binary to build so we can do quicker travis runs, then merge to master with confidence that the build from coreir's master source will pass (given that the release matches master).

Ideally we have all setup logic outside of the makefile, currently the call to generate.csh will result in a git clone for genesis2 if it's not present.

Appears to be the results of changes to CGRAGenerator on august 14