How does it Work?¶
This section is an overview of our service, tooling and workflow. To take a more in-depth look at workflow you can jump to our tutorials, starting here: Tutorial 1 – Workflow part 1.
Reconfigure.io is a platform as a service (PaaS), which takes your Go code, compiles and optimizes it, and deploys to cloud-based FPGAs. You will code in Go and interact with the service using our simple command-line tool. We use AWS F1 instances for our cloud FPGAs, but all you need to use our service is a Reconfigure.io account and our command-line tool – we take care of the rest.
The image below describes how Reconfigure.io works. All coding is done locally in Go and you can type-check locally for compatibility before simulating, building and deploying in the cloud. The F1 instance hardware includes a host CPU with an FPGA connected via PCIe. The FPGA also has some dedicated memory (DRAM) which can be used to share data between the CPU and FPGA.
Go compilation stages¶
We take your code through several stages to get it ready to program an FPGA:
- Teak – first, your Go is translated into Teak , a data-flow language with its roots in research from the University of Manchester. This allows us (and you, using graphs) to optimize your code for the FPGA architecture.
- Verilog RTL representation - this ‘register transfer level’ description is suitable for taking your code into the traditional FPGA development process.
- Verilog netlist - we then use standard tooling to compile your code into a netlist which relates to the FPGA’s logic components.
- Place and route – this is where we decide where on the physical FPGA chip to place the components from the netlist.
- Bitstream - the last part of the process is using the place and route output to generate a bitstream capable of programming the FPGA.
CPU vs FPGA¶
The Go language is designed for writing concurrent programs, which you can read more about here. Go is normally used to write for traditional CPUs, where the concurrency in programs using goroutines, channels and select statements can take advantage of multi-core CPUs to perform several operations in parallel. But, when we optimize your Go for an FPGA, this potential for parallel processing is drastically increased.
For example, a goroutine running on a CPU is a tiny light-weight thread running within a bigger thread, with just one big thread per CPU core. There is potential for parallelism here, but only one operation can happen per core per unit of time. On an FPGA, one go routine translates to a small chunk of circuit, continuously running, so you could create a million of them and they can all do their work all the time.
Tooling and project structure¶
All access to the Reconfigure.io service is through our tool –
reco to upload and test your code, manage builds and deploy to a remote FPGA. If you need to install or update
reco you can find instructions here.
reco is a simple tool with several intuitive commands, we’ll look at some of these in the relevant sections below – commands are described in bullet points. For a full list see, Tool Usage Reference.
Projects and program structure¶
Reconfigure.io programs have a simple structure: code for the FPGA and code for the host CPU. Both are written in Go:
reco to simulate, build and deploy your programs you will work within a project. You can view builds and deployments per project, which is really useful when working on several work-streams at the same time with several builds and deployments for each.
You must create at least one project but beyond this you can structure your work however you wish. When running
run, if you do not specify a project, the results will be associated with the currently active project.
create-projectis used to create a new project
projectsdisplays a list of all active projects for your account
set-projectallows you to set a project to associate with future builds
Let’s take a look at the workflow, from coding to deployment:
All the code you write will be in Go. You can create Go files in your working directory, following our program structure, and edit with your chosen editor - If you follow our standard go setup instructions you will have in-editor checks working too. We use a streamlined subset of the Go language which is constantly being added to – any new additions will be flagged up in our Release Notes.
If you have followed our Go tooling setup instructions you can use
go test to run tests against your FPGA code and flag up any syntactic errors. You can read more about the Go testing framework here. Your
_test.go files can just be stored in a program’s top directory.
Once you are happy with your code in standard Go, you can perform a local quick-check to make sure it’s compatible with our compiler. If there are any parts of your code that don’t work with the Reconfigure.io compiler they will be flagged up here, followed by
Error: error(s) found while checking <filename.go>. If everything is fine you will see no output.
reco checklocally type checks your FPGA code.
It’s a good idea to test your code using our hardware simulator. Any errors will be highlighted and it’s considerably quicker than creating a build so will save you time during the development process. Simulations will timeout if they don’t complete within one hour.
reco test run <my_cmd>tests your code on our hardware simulator.
Our compiler takes your Go code through several stages to get it into a format suitable for flashing an FPGA. First, it’s translated into a language called Teak, then, using the Teak output we can generate dataflow graphs. Using the
graph command you can generate a dataflow graph for your program at any time, allowing you to analyze and optimize its performance.
The ability to generate graphs is a temporary feature. Due to the complexity of the output we suggest you share your graphs with us in the ‘early access’ section of our forum, where our engineers can assist you to optimize your code. We’re looking forward to see how you get on!
reco graph gengenerates a dataflow graph from the program in your current directory.
reco graph listlists all your graphs along with their unique IDs.
reco graph open <graph_ID>lets you view any graph in your default default PDF viewer.
When your program is complete and tested it needs to be built. Our compiler will check compatibility and convert it into a bit-stream format suitable for deploying to an FPGA. Builds will timeout if they don’t complete within 12 hours.
Build times are currently in the region of 4 hours. This is longer than we would like and is partly due to underlying silicon vender tools, which we are currently working to address. Although the build time is relatively long, it is not something you will have to do very often during your program development - you will mostly use our hardware simulator, which takes minutes rather than hours.
reco build runuploads the code from your current directory to the Reconfigure.io service. Building will automatically start once the upload has completed. Your Go code will be compiled and optimized to run on an FPGA.
reco build listlists all builds for the current project along with their statuses. Each build is date-stamped and given a unique ID so you can always make sure you’re using the correct build when working on large and complex projects.
Once your build is complete you can deploy it to an FPGA and run your command on the host CPU.
reco deployment run <build_ID> <cmd>will deploy your build to the FPGA and run your chosen command on the host CPU.
- If your deployment is designed to run indefinitely, it is important to remember to stop it – live deployments are charged to your account (open-source users get 20 hours/month for free). Run
reco deployment stop <deployment-ID>to stop a deployment. It is also good practice to include a timeout, just in case you forget to stop a deployment. To do this you can run
reco deployment run <build-ID> timeout 30m <cmd>to ensure that the deployment runs for 30 minutes max. You can set whatever timeout you want, using hours