This week I was working on designing web APIs. An API was an “application programming interface” and it was needed to exchange information between different parties. The API paradigm that I focused on was Remote Procedure Call (RPC).

Previously, the API paradigm used by AESTE was Representational State Transfer (REST). REST was all about resources and basic HTTP methods were implemented to do Create, Read, Update and Delete (CRUD). Thus, the four basic fundamental HTTP verbs were GET, PUT, POST and DELETE. In addition, the server would respond status code to show success or failure, e.g. 200 OK or 404 NOT FOUND.

An example of REST API request was shown below.

PUT /api/UUID HTTP/1.1
Authorization: xxxxxxxxxx
Content-Type: multipart/mixed

Thus, the server might give response as such.

HTTP/1.1 202 OK
Location: /api/UUID
ETag: "xxxxxxxxxxxxxxxxxxxxxx"

However, I was advised by Dr Shawn to design another API paradigm called Remote Procedure Call (RPC) instead. As REST was about resources, RPC was about actions. A method name and arguments would be passed by a client to a server and a collection of methods were in the form /api/workspace.method. Moreover, RPC typically involved GET and POST. The RPC I created allowed several action, such as compile, elaborate and synthesise.

Method Description
workspace.bitstream Generates bitstream for the netlist file.
workspace.compile Compiles the cpp source file.
workspace.elaborate Generates the Verilog top level design.
workspace.placeandroute Performs place and route on the netlist file.
workspace.synthesise Performs systhesis on the Verilog file.

For a simple illustration, a POST request for workspace.synthesise was shown below. The arguments involved the FPGA model used by the user, the details of FPGA manufacturer and a Verilog source file. The content-type was multipart/mixed because multiple files were encapsulated in a single transaction. 

POST /api/workspace.synthesise
Content-length: xxx
Content-type: multipart/mixed
Authorization: ABCDEF......0123456789

Thus, the server would send back a response including an ETag and a netlist file.

Location: /api/hdls/UUID
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Additionally, I did some reading on curl because the project that I was working on did not involve any user interface. Curl was just a command line to transfer data. Curl could also be used to download and upload data to a server. Some simple curl commands were shown below.

curl -v
curl -d data
curl --data-urlencode “name=Junwen”

Furthermore, I did some testing with nextpnr, which was a place and route tool. After the Verilog file was synthesised by Yosys, nextpnr would then perform place and route based on the generated netlist. There were three versions of nextpnr, namely nextpnr-ice40, nextpnr-ecp5 and nextpnr-generic. The place and route tool generally took two arguments, which were a netlist file and a user constraint file. Besides that, nextpnr was better than arachne-pnr because it was able to support a variety of FPGAs whereas arachne-pnr mostly focused on iCE40 family of FPGAs. A simple invoking example was demonstrated below.

# run synthesis
yosys -Q -T -s scipt.ys -l log.txt
# run place and route
nextpnr-ice40 --lp384 --json netlist.json --pcf constraints.pcf --asc output.asc 

nextpnr worked perfectly fine on a simple D flip-flop netlist. However, when I tried to run nextpnr on the project netlist file, an error was encountered.

ERROR: multiple drivers on net ’dwb_adr_o[2]’ (memif0.dwb_adr_o[0] and processor.dwb_adr_o[0])
ERROR: Loading design failed.

All in all, the progression for this week was fine and I had to fix the error encountered by nextpnr so that I could perform place and route on the netlist file generated by Yosys. I would have to do some simple testing on the iCE40 FPGA as well.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.