hwacha-template icon indicating copy to clipboard operation
hwacha-template copied to clipboard

Error running default Hwacha assembly tests

Open aignacio opened this issue 6 years ago • 8 comments

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

aignacio avatar Feb 26 '19 09:02 aignacio

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.

a0u avatar Mar 04 '19 17:03 a0u

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

aignacio avatar Mar 05 '19 10:03 aignacio

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

colinschmidt avatar Mar 05 '19 16:03 colinschmidt

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

aignacio avatar Mar 07 '19 08:03 aignacio

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.

a0u avatar Mar 07 '19 11:03 a0u

@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 avatar Mar 07 '19 13:03 aignacio

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

aignacio avatar Mar 10 '19 23:03 aignacio

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.

colinschmidt avatar Mar 11 '19 02:03 colinschmidt