search

vmware-archive / cascade

A Just-In-Time Compiler for Verilog from VMware Research
Other
433 stars 44 forks source link

[question] -march de10 still runs in CPU #234

Open yurivict opened 4 years ago

yurivict commented 4 years ago

I run

cascade --march de10 -e share/cascade/test/benchmark/bitcoin/run_25.v --enable_info --profile 3

but it runs on CPU. In De10Compiler::compile De10Compiler::block_on_compile always returns false because the RPC server is ok, so it never moves it to the FPGA.

What am I missing? What is the condition that allows the program to run on FPGA? RPC not being ok can't be such a condition.

yurivict commented 4 years ago

I think that this is a bug in Cascade that it even attempts to turn the FPGA off.

When Quartus Platform Designer builds an image it puts some compiled Verilog in it. The same probably happens when Poky builds an image. If the system is booted with a pre-programmed FPGA you can't safely turn it off. So maybe there is nothing wrong with the Terasic image, the "off" command just can never be executed. Cascade just needs to know how to program on top of what is already there, and how to then erase the program that it wrote. I didn't see the code for the latter.

eschkufz commented 4 years ago

Sorry about the slow reply. I've spent the past few weeks transitioning jobs (no longer at vmware, now at amazon).

Some good news and bad news.

The good news is that I finally built an ubuntu image for the de10. You can download it here: https://drive.google.com/file/d/1jYNiNdQVGjDHt6YGqKA72cP8gN2CuefH/view?usp=sharing. The image is configured with a single user; username and password are fpga/fpga. There's a single folder in the user's home directory which contains a checkout of cascade, which has been built and installed (via make -C build; make -C build install). I verified that all regression tests pass, and the example in the readme works as intended. Hopefully this works as a better platform for debugging.

The bad news is that since I left vmware I lost my admin privileges on the repository, so we're temporarily without an administrator. That means that I won't be able to push any changes or accept pull requests until we get things sorted out (hopefully in the next week or two).

On Sun, Jan 26, 2020 at 5:40 PM yuri@FreeBSD notifications@github.com wrote:

I think that this is a bug in Cascade that it even attempts to turn the FPGA off.

When Quartus Platform Designer builds an image it puts some compiled Verilog in it. The same probably happens when Poky builds an image. If the system is booted with a pre-programmed FPGA you can't safely turn it off. So maybe there is nothing wrong with the Terasic image, the "off" command just can never be executed. Cascade just needs to know to to program on top of what is there already, and how to then erase the program that it wrote. I didn't see the code for the latter.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vmware/cascade/issues/234?email_source=notifications&email_token=AAE3RLUVVL23F37H7S5TXEDQ7Y3PBA5CNFSM4KE6WXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ6DVVY#issuecomment-578566871, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE3RLR3OYO57TBNFEOFXVTQ7Y3PBANCNFSM4KE6WXPA .

yurivict commented 4 years ago

Congrats with your new job!

I'll try the image over the weekend.

JoshuaLandgraf commented 4 years ago

Can you verify that Google Drive didn't mess with your file? When I downloaded it, I only got a 22MB archive, which seems extremely small. Extracting the archive results in an extension-less file that says it's about 16GB large. That's twice the size of the microSD cards that come with the DE10 boards. It does seem to have some kind of filesystem on it, but the filesystem says there's only ~4.3GB of data. Should we write just that part of the image to the microSD card and ignore the rest of the file?

eschkufz commented 4 years ago

That's the right one (I'm pretty sure). The microsd card I used was 16gb, but most of the space was unused. I configured a 4gb file system.

There should be there partitions (the third is the file system --- the other two are O(10mb) boot partitions). Depending on your os it might not be recognizing them. Just use dd to copy the whole thing en masse.

I'll make an 8gb image when I get home tonight just in case.

On Fri, Feb 14, 2020, 7:25 AM JoshuaLandgraf notifications@github.com wrote:

Can you verify that Google Drive didn't mess with your file? When I downloaded it, I only got a 22MB archive, which seems extremely small. Extracting the archive results in an extension-less file that says it's about 16GB large. That's twice the size of the microSD cards that come with the DE10 boards. It does seem to have some kind of filesystem on it, but the filesystem says there's only ~4.3GB of data. Should we write just that part of the image to the microSD card and ignore the rest of the file?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vmware/cascade/issues/234?email_source=notifications&email_token=AAE3RLW2HIRB6KUZGE6GCHDRC2ZXFA5CNFSM4KE6WXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZMHYA#issuecomment-586335200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE3RLVY56UV7TEWULLHYXTRC2ZXFANCNFSM4KE6WXPA .

JoshuaLandgraf commented 4 years ago

Oh, in that case, you could just shorten the image down to the size of the filesystem. Writing zeros to the end of the disk just makes the initialization process take longer. Also, it looks like the third partition is a tiny boot partition, not the main one. Do you know if it could be relocated to before the main partition or would that break things? If the main partition is the last one on the microSD card, it's pretty easy to grow it so it can use the remaining free space. Might be handy if people want to install a few extra packages during development.

eschkufz commented 4 years ago

Ah, great. 2GB is the size of the file system that ships with the de10s. I was always running out of space with that one so I double it. I could have increased the size up to the full 8GB, but I must have reflashed my sd card about a thousand times and was getting tired of how long dd took. If you can get away with just copying the first half of the image to your card, then do that.

The partition order isn't particularly important, but we'd have to rebuild the image in order to make it work. There are boot scripts that rely on things being in one place or another. As soon we get access back to the repository I can commit the script that I used to build the image. The changes would go there and they'd be pretty easy to make I think.

On Fri, Feb 14, 2020 at 8:18 AM JoshuaLandgraf notifications@github.com wrote:

Oh, in that case, you could just shorten the image down to the size of the filesystem. Writing zeros to the end of the disk just makes the initialization process take longer. Also, it looks like the third partition is a tiny boot partition, not the main one. Do you know if it could be relocated to before the main partition or would that break things? If the main partition is the last one on the microSD card, it's pretty easy to grow it so it can use the remaining free space. Might be handy if people want to install a few extra packages during development.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vmware/cascade/issues/234?email_source=notifications&email_token=AAE3RLVOMNNUX67EUT3LKWTRC273XA5CNFSM4KE6WXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZSALY#issuecomment-586358831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE3RLXR7EBLI5T4SOFMEVDRC273XANCNFSM4KE6WXPA .

JoshuaLandgraf commented 4 years ago

Sounds great. Let me know when you push the scripts, so I can take a look.

Also, if your transfer speed is slow in macOS, check out the /dev/rdisk interface. It's an unbuffered (lower overhead) version of /dev/disk. When combined with a large dd block size (e.g. 1MB), some users have claimed speedups of up to 20x.

eschkufz commented 4 years ago

Yep. That makes a big difference. It's still O(minutes) though, which is annoying when you want to try editing a boot script, watch it crash, and then debug it over and over again.

On Fri, Feb 14, 2020 at 9:37 AM JoshuaLandgraf notifications@github.com wrote:

Sounds great. Let me know when you push the scripts, so I can take a look.

Also, if your transfer speed is slow in macOS, check out the /dev/rdisk interface. It's an unbuffered (lower overhead) version of /dev/disk. When combined with a large dd block size (e.g. 1MB), some users have claimed speedups of up to 20x.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vmware/cascade/issues/234?email_source=notifications&email_token=AAE3RLUQOEULNXYSBMDN4ULRC3JHLA5CNFSM4KE6WXPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZ2A7I#issuecomment-586391677, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE3RLVS5DWVKEIO7EDS4TTRC3JHLANCNFSM4KE6WXPA .