-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CoreIR Dev merge #85
Comments
@rdaly525 I tested I looked through the commit log, it seems like |
@Kuree Sorry, there was a mapper branch that was not merged into dev. It should work now. Although it does have a dependency on coreir dev branch. |
If/when @Kuree tests complete successfully I think I'm good... |
@rdaly525 @steveri It seems like something is broken in the flow, see: https://travis-ci.org/StanfordAHA/CGRAFlow/builds/451253598. The simulation result didn't match with the CPU reference. I will find out which part is not functioning properly. The problem is I cannot reproduce the PnR result on my VM instance so it might take a while to locate the bug. |
Why can't you reproduce the PnR result? Is it a non-determinism issue? You could try dumping the PnR files from travis (easiest way would just be to You can also try running the travis job in debug mode. Since it's a public repo, you have to do it through the API, info here: https://docs.travis-ci.com/user/running-build-in-debug-mode/#restarting-a-job-in-debug-mode This gives you a job where you can SSH into the travis VM to poke around |
My implementation only guarantees deterministic result for an environment. For instance, if you change Python version or g++, you will get different result. I haven't made any efforts to ensure it's consistent across all the platforms since it's deterministic if the environment is fixed. I believe it's due different implementation on random and hash, but I'm not so sure. The flow bug doesn't seem to relate to PnR since it passed all the checks. My educated guess would be one of the mapping/bsb is incorrect. |
@steveri @leonardt Found a bug that's irrelevant to this issue:
I have fixed this bug and will send a PR soon. |
There are several inconsistency between the new mapper and the downstream tools that caused the build failure. I've have branches pushed that fixed bugs mentioned in the thread. These branches need to merge into master. @@ -47,22 +50,22 @@ python scripts/repo_manager.py
--halide master \
--halide-remote github.com/jeffsetter/Halide_CoreIR.git \
\
- --coreir master \
+ --coreir dev \
--coreir-remote github.com/rdaly525/coreir.git \
\
--pycoreir master \
--pycoreir-remote github.com/leonardt/pycoreir.git \
\
- --mapper master \
+ --mapper ashr \
--mapper-remote github.com/StanfordAHA/CGRAMapper.git \
\
- --cgra-generator master \
+ --cgra-generator fix_io_config \
--cgra-generator-remote github.com/StanfordAHA/CGRAGenerator.git \
\
--test-bench-generator master \
--test-bench-generator-remote github.com/StanfordAHA/TestBenchGenerator.git \
\
- --cgra-pnr master \
+ --cgra-pnr dev \
--cgra-pnr-remote github.com/Kuree/cgra_pnr.git \ |
It's supposed to work if you simply precede the opcode name with an optional 'u' or 's' ('u' is default)...examples:
Signed:
|
@steveri, can you update your bsbuilder to take as input a bool as to whether each op is signed? This is how it is described in the PE spec and we should consider that the truth and have our tools be consistent with it. For your human readable output, I think what you have above (prepending an 's') is fine. |
haha what you call "human readable output" is actually the input to bsbuilder...it's an old-school assembler :) if you want to be strictly formal with the input syntax then each op should be specified as follows:
i.e. you would not use the shorthand TL;DR there is a bool it is the u/s prepended to the opcode name |
Updated diff: diff --git a/install.sh b/install.sh
index 283e432..496f39c 100755
--- a/install.sh
+++ b/install.sh
@@ -50,22 +50,22 @@ python scripts/repo_manager.py
--halide master \
--halide-remote github.com/jeffsetter/Halide_CoreIR.git \
\
- --coreir master \
+ --coreir dev \
--coreir-remote github.com/rdaly525/coreir.git \
\
--pycoreir master \
--pycoreir-remote github.com/leonardt/pycoreir.git \
\
- --mapper master \
+ --mapper dev \
--mapper-remote github.com/StanfordAHA/CGRAMapper.git \
\
- --cgra-generator master \
+ --cgra-generator fix_io_config \
--cgra-generator-remote github.com/StanfordAHA/CGRAGenerator.git \
\
--test-bench-generator master \
--test-bench-generator-remote github.com/StanfordAHA/TestBenchGenerator.git \
\
- --cgra-pnr master \
+ --cgra-pnr dev \
--cgra-pnr-remote github.com/Kuree/cgra_pnr.git \
@rdaly525 would you please go ahead and merge coreir and mapper to master? I will merge |
Keyi, presumably you generate the Steve-specific input format? Can you generate the way he wants? When we integrate this with garnet, these formats are going to need to be more explicitly defined and be as consistent as possible across tools. For now let’s just get it working. |
For now I'm reading signed bit and using u/s to specifying either signed or unsigned. I agree that in future this has to be consistent and defined by garnet. I will close this issue for now. |
@rdaly525 Ross can you merge mapper and coreir? The flow master branch is failing because I removed my fix script in |
@Kuree Merged |
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.
The text was updated successfully, but these errors were encountered: