AWS F1 Examples

[chadbrewbaker]

I've got an AWS F1 beta account. NDA, but Xilinx generic code isn't.

I'm looking for Clash examples that the community would like to have working on day 1 when AWS F1 goes public.

[chadbrewbaker]

Some examples out there we could port:
https://github.com/vtsynergy/OpenDwarfs
https://github.com/IT302/cho

Anything good coming out of FPGA2017 this week?
http://www.isfpga.org/fpga2017-printed-program.pdf

[christiaanb]

Most of the code I have lying around is geared towards the smaller FPGAs... because I never got to work on a project where I needed a big one.

I think for the Amazon AWS F1 instances, it's going to be important to have primitives/templates (http://hackage.haskell.org/package/clash-prelude-0.11/docs/CLaSH-Tutorial.html#g:14) for the DRAM/Ethernet; so that we can actually get data on and off the FPGA.

Also, are you asking for code? or are you offering to write some? Either way, you could also ask on the mailing list: https://groups.google.com/forum/#!forum/clash-language

[chadbrewbaker]

Asking for Clash examples that would be a good Stack template for AWS F1. I was thinking of calling it clash-aws-f1. Fair warning I'm a noob to FPGA development. I understand how to compile OpenCL code to a Xilinx FPGA, but I could use some some help on how to feed Clash output into Xilinx tooling.

Or, spike on an OpenCL back end for Clash so you can also use the output on multicore/GPU.

[thoughtpolice]

I think that realistically, most of the samples you're going to find for Clash will probably synthesize fine for the F1's FPGA. (Actually the FPGAs in the F1 are like $50,000-per-unit, so if you can find something that doesn't work, I'm impressed :) So any of them will do. You can use almost any of them for an actual demo and it'll work fine and synthesize correctly under Vivado.

However, the trickier bit with something like the F1, like any FPGA, is the peripheral components like Christiaan mentioned -- in particular, you need a lot of Clash code for all the peripherals, if you truly want to highlight its capabilities over alternatives. This is really the case for most FPGAs -- a lot what Clash currently lacks right now is interfaces to commonly used peripherals, for both Xilinx and Intel FPGAs. For example, you need interfaces to the common Xilinx ethernet, SDRAM, etc interfaces.

For example, the F1 likely primarily uses a screaming-fast PCIe interface from the host CPU to the F1, for communication -- so we'd need to write some Clash primitives to wrap the FPGA's PCIe interface, so our own circuits can talk over it. The Linux-side will then need a driver or something to map addresses, and communicate with the circuit on the other side (something like Xillybus can likely take care of this easily, however, so it's not really our problem.)

However, many of the peripherals and components on the F1 are NOT specific to it. Many FPGAs, like the Xilinx ones on my desk, use a lot of the same HDL interfaces to talk to ethernet, SDRAM,or PCIe controllers. So, a lot of the work to be done isn't necessarily specific to the F1 -- a lot of it could be shared among any Xilinx FPGA, for example.

Unfortunately since you're under NDA, I assume you're generally not allowed to mention anything including what interfaces and speeds it has. :) So any F1-specific stuff we might not be able to help you with at all... However! I strongly suggest just spending some time with Vivado and trying to wrap some basic IP interfaces.

I've got an Artix-7 "Arty" FPGA on my desk with DRAM and Ethernet, so I could at least look at perhaps wrapping them with Clash to help get it started...

[chadbrewbaker]

I have been in discussion with AWS-FPGA folks advocating for users that want to do board layout on AWS then apply the layouts to their own Xilinx devices. Forget the F1 for now.

Assume the same as for AWS Codebuild. Upload the design to an AWS S3 bucket and store the FPGA layout in another AWS S3 bucket.

How would you configure a the FPGA build server? What is the grocery list dependencies it would need?

[thoughtpolice]

The main thing you're going to need is actually having Vivado. If you have that, it's "just" a matter of automating the synthesis and place-and-route, using Tcl scripts. You can do this via the command line, so that isn't the biggest issue, and most Vivado projects can be described almost entirely with Tcl (including IP cores). It would really be no different than running make on a particular C project; your toolchain is just different (and more annoying). I'm not familiar with Codebuild but I imagine you can pull something like this off very easily (I'd hope).

But the tricky part is that Vivado's license only allows free synthesis for certain boards and chips. This means if you download the free version of Vivado, you will not be able to synthesize for the same set of boards/hardware as the commercial version. In particular, the F1 has an UltraScale Virtex-7 core, which requires a fully licensed Vivado. Systems like the Arty board, however, can use a free Vivado (Artix-7 core).

In practice, this probably means you either need to A) run your own server that has Vivado installed, with support for your particular board (free or not), or B) use the F1 instance itself, with a licensed Vivado pre-installed, to do your CI/synthesis. I'm not sure how Amazon is dealing with Vivado licensing, to be honest, so I don't know if e.g. you can install Vivado on a non-F1 instance to save yourself billing rates (I'd be surprised if you could, due to the licensing, but you never know.)

So, really, you shouldn't need much more than just the synthesis tools -- you just need to be clear on what you're synthesizing for. But that's impossible to get around; due to size, space, and I/O constraints, you always need a clear vision of the hardware you're targeting, CI system or not...

[thoughtpolice]

Oh, and there's also the minor fact that you of course would have to still run real device tests on the F1, since that's the only place your FPGA is actually going to be. However I don't know if most people actually really do "hands off device testing" -- personally I do run my simulations and testbenches in a CI system, but actual on-device testing is something I always do manually.

So ultimately, using the F1 instance itself to do your CI (maybe a separate F1 instance, apart from your "deployment" one if you use that) is probably your best bet; especially because you can just spin up the F1 AMIs I assume as part of your CI pipeline, don't attach any FPGAs -- and go to town. (Also, since the F1 will have a licensed Vivado that can target any device -- you could reuse this CI pipeline and build server for almost any Xilinx device, even personal ones, so that would be a bonus).

[chadbrewbaker]

Vivado + tcl scripts is fine. Vivado output is enough, don't worry about deployment.