search

ucb-bar / hwacha-template

Template for projects using the Hwacha data-parallel accelerator
http://hwacha.org/
Other
34 stars 10 forks source link

Error running default Hwacha assembly tests #5

Open aignacio opened 5 years ago

aignacio commented 5 years ago

Hi all, After building the right toolchain (esp-tools repo) I tried to run only the Hwacha assembly tests but there is some error in the Makefrag file, so I removed the last true condition ([ $$PIPESTATUS -eq 0 ]) and then the tests start running as it should be, I guess so... screenshot from 2019-02-26 10-31-29

So, when it finishes to run all tests, I read one of the output examples and the log was stucked in the first instruction and it happened with all tests executed. Also, when you try to run some hello world example compiled with the custom toolchain, the same behavior happens with the hwacha core emulator (stucked in the first asm instruction). screenshot from 2019-02-26 10-32-31 screenshot from 2019-02-26 10-35-58

commit hash: 1b26b5cad051f8265956ebc816b8e0146014fa4d

a0u commented 5 years ago

This should be fixed as of 94ca56ca74ddf3a64488fd709cb4aeab24b7dac5. The verilator test harness originally from testchipip did not support using the DTM to load the test program and release the cores from the bootrom loop.

aignacio commented 5 years ago

Hi @a0u, Thanks for the feedback, so now are we able to use DTM to load the program and also parse syscalls through tohost memory space? I tested during this morning but now it's crashing with the following message:

Error: Could not find or load main class barstools.tapeout.transforms.GenerateHarnessError: Could not find or load main class barstools.tapeout.transforms.GenerateTopError: Could not find or load main class barstools.tapeout.transforms.GenerateTop

colinschmidt commented 5 years ago

The recent merge added a new submodule barstools that you may not have initialized. Please try that with: git submodule update --init --recursive barstools

aignacio commented 5 years ago

Hi @colinschmidt, you were right, now I could build the emulator as expected. After I executed the benchmarks in the emulator the output log files are giant (>1.8GB), is that expected behavior? screenshot from 2019-03-07 09-12-42 Also, there are still some issues in the Makefrag file that cannot parse the output command... screenshot from 2019-03-07 09-25-33

a0u commented 5 years ago

Also, there are still some issues in the Makefrag file that cannot parse the output command...

/bin/sh on some distros (Debian, Ubuntu) defaults to dash instead of bash. PIPESTATUS is a bashism that is not supported by stricter POSIX shells, so [ $PIPESTATUS -eq 0 ] in the make recipe expands to [ -eq 0], which accounts for that syntax error.

Set the shell explicitly by adding SHELL := /bin/bash to the top of verisim/Makefile.

aignacio commented 5 years ago

@a0u , I'm using Debian 9 with bash but the make it's using /bin/sh instead of as you mentioned, now it's ok! Thanks!

aignacio commented 5 years ago

@a0u and @colinschmidt, When running the tests, is that normal took so long and huge amount of size to generate the final logs?

colinschmidt commented 5 years ago

The benchmarks take many millions of cycles and each cycle prints at least 100 characters, so >1GB isn't unreasonable. They can be run without printing that log, see the run-asm-tests-fast make target for an example.