UART Tests on VC707

[Devon White]

Hi,
I'm currently trying to run tests over UART on my VC707. Unfortunately, it isn't working. Right now, what's happening is:
1) Program the FPGA
2) Run: pitonstream -b vc707 -f lsu_misses.s
3) It prompts me to press the reset button and waits, but pressing the CPU_RESET button does nothing, so I'm not sure which to press

On a similar note, once I get this to work, I'm specifically interested in looking at the cache coherency in a multi-core system on this FPGA. Are there any premade tests that I could use to do this?
Thanks in advance,
-Devon White

[Devon White]

I managed to get the reset button working, but now I'm having a new issue. Upon trying to run a test, I'm getting an error saying that the test compilation failed. Checking the log, I see the cause of this is:
Can't exec "bw_cpp": Not a directory at /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims,1.262 line 4057.
Is there something I need to source to get this to work?

[Alexey Lavrov]

Hi Devon,

2) Run: pitonstream -b vc707 -f lsu_misses.s

-f flag for pitonstream expect a file with assembly test names, not a name of assembly test file itself.

Can't exec "bw_cpp": Not a directory at /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims,1.262 line 4057.

Which OS are you running on?

Have you tried to configure your OS according to guidelines in FPGA manual?  (Section 1.2.1 - SW Requirements)

Alexey

[Devon White]

We are now using a diaglist file and we have matched our linux ubuntu 16.04 to the guidelines.
It is still not working.

[Alexey Lavrov]

Hi Devon,

Can you please elaborate what are you running and which error do you get?

Alexey

[Devon White]

Can't exec "bw_cpp": Not a directory at /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims,1.262 line 4062.
sims: Caught a SIGDIE. Could not open /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims.config at /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims,1.262 line 4062.

[Devon White]

pitonstream -b vc707 -f ~/Research/openpiton/piton/verif/diag/princeton/princeton_c_tests.diaglist
We modified the princeton_c_tests.diaglist to only contain our assembly file.
None of the other lists work as they dont compile.

[Devon White]

Removed bw_cpp and started using just cpp in the sims file. This seems to fix some of the issues but now we are encountering a fatal error.
midas: bw_m4  --include=. --include=.. < diag.cpp > diag.m4
midas: rm -f mem.image diag.ev symbol.tbl diag*.exe
midas: ###########################################################
midas: ##  SECTION PARSING PHASE
midas: ###########################################################
midas: goldfinger -v -splitsec diag.m4 -midasfile diag.midas -prefix 'midas: '
midas: goldfinger: Writing midas directives to diag.midas
midas: goldfinger: Writing section RED_SEC to sec0.red_sec.s
midas: goldfinger: Writing section RED_EXT_SEC to sec1.red_ext_sec.s
midas: goldfinger: Writing section HPRIV_RESET to sec2.hpriv_reset.s
midas: goldfinger: Writing section HTRAPS to sec3.htraps.s
midas: goldfinger: Writing section TRAPS to sec4.traps.s
midas: goldfinger: Writing section KERNEL to sec5.kernel.s
midas: goldfinger: Writing section USER_HEAP to sec6.user_heap.s
midas: goldfinger: Writing section MAIN to sec7.main.s
midas: At pkg=Midas::Interface, file=/home/cmuresearch/Research/openpiton/piton/tools/perlmod/Midas/3.30/lib/site_perl/5.8.0/Midas/Interface.pm, line=370
midas: FATAL ERROR: M_ILLEGALPARAM (#9): Illegal parameter.
midas: FATAL ERROR: SECTION '.MAIN': No such attribute '#1360"/home/cmuresearch/Research/openpiton/piton/verif/diag/assembly/include/hboot.s"'
midas: FATAL ERROR:   At File=diag.m4, Line=34799
midas: Finding sections in diag.midas
midas: Processing directives in diag.midas
sims: Caught a SIGDIE. midas compilation error at /home/cmuresearch/Research/openpiton/piton/tools/src/sims/sims,1.262 line 4309.

[Alexey Lavrov]

Hi Devon,

We recently installed Ubuntu 16.04 on one of our machine and managed to configure is using $DV_ROOT/tools/src/proto/syscfg.sh script.

We did not encounter any problems during the setup.

Can you provide me with what is in your diaglist file?

[Devon White]

<princeton_c_tests>
custom custom.s
</princeton_c_tests>

[Alexey Lavrov]

There should be only filename.s per line. You have to remove <princeton_c_tests> closures.

Can you please put only

uart16550-hello-world.s

princeton-test-test.s

in the file and tell me if it works for you?

On Monday, April 3, 2017 at 4:00:57 PM UTC-4, Devon White wrote:

<princeton_c_tests>
custom custom.s
</princeton_c_tests>

[Devon White]

It does not work. Same error

[Alexey Lavrov]

Can you revert back your change of bw_cpp and check that you have all perl packages listed in syscfg.sh installed?

[Devon White]

We have all the packages installed.

[Devon White]

We have been debugging a bit more and found that it complaining about this line.
hboot.s

1360: TTE_G=1, TTE_Context=[0x]eval(PCONTEXT + i, 16), TTE_V=1, TTE_Size=PART0_I_NZ_PS0_PAGE_SIZE, TTE_NFO=0,

[jbalkind]

To ask an earlier stage question, in case I missed it - did you set $PITON_ROOT and source piton_settings.bash? These errors really aren't making sense to me, I don't understand why they would be occurring.

Jon

[Devon White]

Yes we set piton root and sourced piton_settings.bash

[Alexey Lavrov]

Hi Devon,

We have been using pitonstream for more than a year in different setups.
In patricular, we tried it on VM runing Ubuntu 14.04, host running 16.04, host running Arch Linux.
The errors which you are decribing are related to compilation phase (hboot.s problem and midas problem you specified), and we didn't modify this flow provided by OpenSpar T1.
This makes me think that you have a particular environment which causes these problems.

So, can you please try to create a new Piton working folder (just untar archive from release 4), source Piton settings and run
sims -vcs_build -sys=manycore
sims -vcs_run -sys=manycore princeton-test-test.s
and tell us what is the test PASS?

After this works, you can be sure that piton tools can correctly compile and execute assembly tests.
Having that working, we will be able to move forward with pitonstream.

Alexey

[Devon White]

We do not have vcs.

[jbalkind]

In this case could you clear your bashrc of scripts that might be sourced other than the vivado, piton_settings.bash, etc? We've had occasional issues with PATH or other environment variables getting polluted in such a way that our tools don't run.

[Devon White]

There are not any other scripts being sourced.

[jbalkind]

Hm. Looking back at the other errors, I'm not sure that using cpp without the extra flags defined in bw_cpp is going to work.

Does `cpp -V < /dev/null >& /dev/null; echo $?` print 1? If so then you need the extra nonsense when using cpp which is what bw_cpp is trying to do.

[Devon White]

It does print 1.
What is it trying to do exactly?

[Devon White]

I ask because we cannot get it to load.

[jbalkind]

[jbalkind@della2 master]$ md5sum piton/tools/bin/bw_cpp

b56fd07af5e2e8bbfac524e2524c2f93  piton/tools/bin/bw_cpp

Do you see the same hash? I don't believe we've changed the file in almost two years as it came with the T1 code.

If you see the command I showed return 1, then your machine's cpp is GNU and not "traditional" and thus it needs some additional arguments and postprocessing to behave correctly. bw_cpp is a simple script that does this for you and thus if you just replace it with GNU cpp it won't work quite right.

[Devon White]

when sims trys to do
 open (SIM_CONFIG, "bw_cpp -P -B $confcppargs -undef -I$dv_root/$proj_vars{sims_config} $sims_config | ") or die "DIE. Could not open $sims_config" ;

It will fail to find bw_cpp

[Devon White]

And no I do not see the same hash
md5sum bw_cpp
9bb26c67a438ef6d570226e07a1e9da0  bw_cpp

[jbalkind]

In this case your copy of the code is likely corrupted. Try downloading a new copy as Alexey suggested.

[Devon White]

Okay, so doing what bw_cpp does in the sims command itself seems to let the script compile but now it is hanging.
The reason our hash is a bit different is because I put in comment in the bw_cpp. However, I am fairly sure our copy is not corrupt.
When I do bw_cpp -V < /dev/null >& /dev/null; echo $? it responds with 0.

[jbalkind]

I don't think bw_cpp tries to duplicate the return value of "traditional" cpp using gnu cpp, it just tries to duplicate the behaviour. When you change bw_cpp back do you see the same hash? When you say it is hanging, what do you mean? Please share the full output with us so we can understand.

Also does bw_cpp have the correct permissions? I still don't understand why it won't execute in sims for you.

Jon

[Devon White]

We redownlaoded everything and tried running pitonstream again on the previous design. The tests failed, but the compilation was successful. We are now recompiling the design with protosyn and are going to try running the tests again once it finishes.

[Devon White]

We reprogrammed the board and all tests are failing
after running the princeton_rst.diaglist all tests failed with this
Can't use existent storage_addr_trans.v
Specifically,
mapped in /home/cmuresearch/Research/sadpiton/piton/design/chipset/rtl/storage_addr_trans_unified.v
ERROR: Address 0x2dde50 is not mapped in /home/cmuresearch/Research/sadpiton/piton/design/chipset/rtl/storage_addr_trans_unified.v

[Devon White]

Actually only some of them are failing.

[Alexey Lavrov]

Which tests are you running?

The error about storage_addr_trans.v appears because for each test there is limited set of addresses which can be mapped to ddr.

A good starting point is take princeton-test-test.s and modify it for your needs.

Alexey

[Devon White]

I am in particular running the princeton_rst.diaglist. One such error is:
Running wmr_dc_tag_no_par_check.s: 37 out of 52 test

ERROR: Address 0x2dde50 is not mapped in /home/cmuresearch/Research/sadpiton/piton/design/chipset/rtl/storage_addr_trans_unified.v

ERROR: Can't use existent storage_addr_trans.v for wmr_dc_tag_no_par_check.s
ERROR: Test compilation failed
ERROR: Skipping wmr_dc_tag_no_par_check.s
ERROR: See /home/cmuresearch/Research/sadpiton/build/uart_piton.log for more information

I have taken your advice and made a copy of princeton-test-test.s and a new diaglist to use for our need, and it seems to work fine. Do you think I should ignore this error with the rst tests?


On another note, how would I, in both the synthesizing of the model and the assembly test, go about getting a two or four core design? Thanks again for all your help,
-Devon

[Devon White]

So, I have successfully gotten the two-core design to synthesis and load onto my V707. I have princeton-test-test running, now I am wondering how to enable running threads on multiple cores, as I am trying to work with the cache coherence protocols. Thanks for your help.

[jbalkind]

Hi Devon,

You should be able to make use of some midas arguments to make this happen. You can pass `--midas args "-some -arguments" ` to pitonstream to do this. The arguments you'd want in particular are -DTHREAD_COUNT=N and -DTHREAD_STRIDE=M (I think both are explained in our simulation documentation).

Do note that pitonstream doesn't have a way of detecting good trap from multiple threads just yet. We check for good trap by looking for the address requested at the memory controller but if multiple threads hit good trap, the instructions may be cached and thus we might not see it (I haven't checked on this for sure yet). You might look into modifying good trap instead if you need to check on this. If you don't want to tinker with that, you can alternatively just place debug probes on the PCs of the two cores.

As for multithreaded designs, there are a few bugs with this in release 4. We should be coming out with a new release soon that will fix some of these. Defining THREADS_2/THREADS_3/THREADS_4 and CONFIG_NUM_THREADS should do it but will require some tinkering to get compiling.

[Devon White]

We are having issues with the helloworld uart test.
It passes but it only prints H.