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 MIME-DATA
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 MIME-FILE
Thus, the server would send back a response including an ETag and a netlist file.
Location: /api/hdls/UUID ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" NETLIST-FILE
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 https://web.aeste.my/ curl -d data https://web.aeste.my/ curl --data-urlencode “name=Junwen” https://web.aeste.my/
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.
0 Comments