PrincetonUniversity/openpiton

Error:Can not open serial device

Hooopper opened this issue · 21 comments

Hi,

I got errors by using pitonstream command to run tests on the board.
"Can not open serial device /dev/ttyUSB1"
"Provide correct device name using -p option"
But USB1 is actually the right serial port.
How could I solve this problem?
Thank you all.

Likely this is because of the permissions on /dev/ttyUSB1. Perhaps you can add your user to the appropriate group for the device (which you can see with ls -l /dev/ttyUSB1)

Likely this is because of the permissions on /dev/ttyUSB1. Perhaps you can add your user to the appropriate group for the device (which you can see with ls -l /dev/ttyUSB1)

Thanks, it works.
Update: with command I could jump out he reset step to execute the assembly test but still waiting for test results

The assembly test just get stuck at "TEST OUPUT" on VCU118. does pitonstream actually work with this board? or did I something wrong?
How could I run assembly riscv tests on VCU118 board?
Thanks for your help.

If you have the appropriate DIP switch flipped to 1 (just the first switch, I think it's numbered as switch 1), connect a serial terminal directly to /dev/ttyUSB1, and hit reset, do you see DONE printed on the terminal? If so, then pitonstream should work as intended when used with the same setup.

fei-g commented

You see TEST OUTPUT >>>, which means Loading a test... 100% is also printed? That means your assembly/c test has successfully loaded into the FPGA board. Which test are you running?

I just confirmed that hello_world.c could be run on VCU118.
just to make sure you added these flags for protosyn when you generate the bitstream: --uart-dmw ddr --define PITONSYS_DDR4

If you have the appropriate DIP switch flipped to 1 (just the first switch, I think it's numbered as switch 1), connect a serial terminal directly to /dev/ttyUSB1, and hit reset, do you see DONE printed on the terminal? If so, then pitonstream should work as intended when used with the same setup.

Yes, i fllipped the gpio dip sw1 on my board but didn't see anything printed on the terminal.

You see TEST OUTPUT >>>, which means Loading a test... 100% is also printed? That means your assembly/c test has successfully loaded into the FPGA board. Which test are you running?

I just confirmed that hello_world.c could be run on VCU118.
just to make sure you added these flags for protosyn when you generate the bitstream: --uart-dmw ddr --define PITONSYS_DDR4

I'm trying to run the precompiled riscv tests and hello world on the board.
When I skip the reset step, I could see Loading a test ...100% is printed and the system awaits for the test output.
But if i try to excute the reset step with flipping the switch sw1, i could see anything. The system awaits for the reset...

I use the branch openpiton-dev,
and the following command are all what i used for the implementation and running :
1.cd $PITON_ROOT/
2.source piton/ariane_setup.sh
3.piton/ariane_build_tools.sh
4.protosyn -b vcu118 -d system --core=ariane --uart-dmw ddr
5.pitonstream -b vcu118 -d system -f ./piton/design/chip/tile/ariane/ci/riscv-benchmarks.list --core=ariane --precompiled
6.pitonstream -b vcu118 -d system -f ./tests.txt --core=ariane

Now I will run protosyn command again with your specific flags and give you updates later.
Thanks.

No surprises.
sw1 on the board didn't work.
when I skip the reset with command, the test get stuck with "test output". even for hello_world.

What Vivado version are you using to build the bitfile? Perhaps Fei can share his bitfile too so we can see whether it's a synthesis or an environment issue

What Vivado version are you using to build the bitfile? Perhaps Fei can share his bitfile too so we can see whether it's a synthesis or an environment issue

I use 2019.1. It would be great if you could share a bitfile for vcu118 board. I'll give a try asap.

fei-g commented

No surprises.
sw1 on the board didn't work.
when I skip the reset with command, the test get stuck with "test output". even for hello_world.

Here is the bit file I used, it was build on an older commit da687b3 on openpiton-dev branch.
openpiton-dev.bit.zip

You should always keep the switch on (the first switch in SW12), or pitonstream will not do the work. BTW, you might need to install the UART driver on your host machine. Try to unplug and plug the UART cable, see how many new devices appear. If there are two, try both.

your bit file is partially working. Now I can see "hello world" and "done" on the terminal. hello_world test passed. However, sw1 still doesn't work. I had to skip the reset step.
And for precompiled riscv test: I got always TIMEOUT for all test.
May I ask which commit is stable and working for VCU118? At the moment I'd love to get assembly tests running on this board...
Thanks

Are you using riscv-tests compiled from elsewhere, or is it the version built from ariane_build_tools.sh?

Are you using riscv-tests compiled from elsewhere, or is it the version built from ariane_build_tools.sh?

I think I used the one from your project. because I didn't change anything but just running the command directly: pitonstream -b vcu118 -d system -f ./piton/design/chip/tile/ariane/ci/riscv-benchmarks.list --core=ariane --precompiled :

for example for dhrystone test, I got the following output:Loading a test...
100%
TEST OUTPUT >>>
Microseconds for one run through Dhrystone: 479
Dhrystones per Second: 2084
core 0: mcycle = 240104

<<< END OF TEST OUTPUT
dhrystone.riscv : TIMEOUT

I'm not sure if this TIMEOUTaffects the result. As mentioned, this test output is associated with your bit file. does your core run at 100MHz? If yes, i think this result is a little lower but perhaps reasonable?

I believe the assembly tests should pass and fail whereas the precompiled benchmarks will not. The emulated test harness has to look for the load to the address of the pass/fail label and I think the benchmarks had no such label.

We saw the same TIMEOUT for those precompiled tests. Sorry, we need to fix this

It would be great if i could be informed when this bug is fixed.

I believe the assembly tests should pass and fail whereas the precompiled benchmarks will not. The emulated test harness has to look for the load to the address of the pass/fail label and I think the benchmarks had no such label.

so is the benchmark result I listed above valid for the core?

fei-g commented

We saw the same TIMEOUT for those precompiled tests. Sorry, we need to fix this

It would be great if i could be informed when this bug is fixed.

Sorry I didn't make it clear. It's not a bug on our side, but we need to make the documentation more clear.

The result you got is expected. Precompiled test will have the TIMEOUT result for pitonstream. Those precompiled tests were not build via our tools, so they do not have the pass/fail labels we are looking for. They are still valid tests, and can be used in the simulation (use tool sims).

You can write your own benchmark in our setting, just like hello_world.c.

We saw the same TIMEOUT for those precompiled tests. Sorry, we need to fix this

It would be great if i could be informed when this bug is fixed.

Sorry I didn't make it clear. It's not a bug on our side, but we need to make the documentation more clear.

The result you got is expected. Precompiled test will have the TIMEOUT result for pitonstream. Those precompiled tests were not build via our tools, so they do not have the pass/fail labels we are looking for. They are still valid tests, and can be used in the simulation (use tool sims).

You can write your own benchmark in our setting, just like hello_world.c.

Ok, i got it now. Thanks to your quick replies. So i have to revert to the old commit to get it work with this board. and I assume your core frequency is 100MHz,right? I hope the up-to-date brank will also work soon. Thanks again!

fei-g commented

openpiton-dev.bit 2.zip
Yes, the core frequency is 100MHz. I just generated another bitfile on the latest commit of openpiton-dev. Hello_world runs well.
This is the command I used
protosyn -b vcu118 -c ariane --uart-dmw ddr

The vivado version we used is 2018.2.
I don't understand what means sw1 still doesn't work. I had to skip the reset step. Do you mean you made the hello_world.c run without setting DIP switch? How could you skip the reset?

openpiton-dev.bit 2.zip
Yes, the core frequency is 100MHz. I just generated another bitfile on the latest commit of openpiton-dev. Hello_world runs well.
This is the command I used
protosyn -b vcu118 -c ariane --uart-dmw ddr

The vivado version we used is 2018.2.
I don't understand what means sw1 still doesn't work. I had to skip the reset step. Do you mean you made the hello_world.c run without setting DIP switch? How could you skip the reset?

I will use your command to try again.
Yes, even if I flipped sw1, i cant see "done" printed, so i have to use --no_wait_fpga_config to make it work(sw1 is also on).