This week I mainly focused on the back-end. In this post I would also like to discuss about some Wt classes since Wt currently lacked community support.
First and foremost, I would like to discuss about curl. Since the project did not involve any user interface, I had to use curl to transfer data to the server. Unfortunately, I made a mistake at the beginning because I did not implement MIME encoding into the curl command. For example, the curl command I executed previously was in the form below.
curl -i -X POST -H “Content-Type: multipart/mixed” -d @source.v http://127.0.0.4:8080/api/workspace.elaborate
As a result, I was advised by Dr Shawn to implement multipart formpost instead, e.g. -F “name=value”. The final form of curl which would implement MIME encoding was shown below.
curl -F “lang=vlog” -F “[email protected]” -kv http://127.0.0.4:8080/api/workspace.elaborate
Below was a summary of curl commands and I hoped these would help future interns to continue on the project. All should follow Remote Procedure Call (RPC). The linux shell script was shown below (run chmod 755 filename to directly execute the shell script).
#!/bin/bash curl -F ‘arch=riscv’ -F ‘lang=cpp’ -F ‘[email protected]’ -F ‘[email protected]’ -kv http://127.0.0.4:8080/api/workspace.compile curl -F ‘lang=vlog’ -F ‘[email protected]’ -kv http://127.0.0.4:8080/api/workspace.elaborate curl -F ‘fpga=ice40’ -F ‘manufacturer=lattice’ -F ‘[email protected]’ -kv http://127.0.0.4:8080/api/workspace.synthesise curl -F ‘fpga=ice40’ -F ‘device=lp384’ -F ‘[email protected]’ -F ‘[email protected]’ -kv http://127.0.0.4:8080/api/workspace.placeandroute
After getting all curl commands correctly, i continued to work on the back-end to interpret MIME multipart messages, which was supported by Wt:Http::Request class. To access a parameter, I could call request.getParameter("name")->data() and this would return a constant string containing the query parameter. In addition, I could also call request.getParameterMap() and this would give me a parameter map consisting all parameters in the MIME multipart message. The parameter map was in the form of std::map<std::string, Wt::Http::ParameterValues>. To access all elements in the parameter map (also std::map), I could use the following code.
std::map<std::string, Wt::Http::ParameterValues> parameterMap = request.getParameterMap();
for (auto& element:parameterMap) {
for (unsigned i = 0; i < element.second.size(); i++){
std::cout << element.first << “\t” << element.second[i] << std::endl;
}
}
Additionally, I also had to deal with the file I uploaded to the server. To access the file, I could simply call request.getUploadedFile("vlogFile"), and hence it would return a constant pointer to the class Wt::Http::UploadedFile. This Wt::Http::UploadedFile class had several member functions.
const Wt::Http::UploadedFile* uploadedFile = request.getUploadedFile("vlogFile");
uploadedFile->spoolFileName();
uploadedFile->clientFileName();
uploadedFile->contentType();
Thus, the results were shown below.
/tmp/wt0SXK2Q source.v application/octect-stream
On a side note, I could go directly to /tmp/wt0SXK2Q (instead of /tmp/wt0SXK2Q/source.v) to access the file which was stored temporarily on the server. Only when I called the function uploadedFile->stealSpoolFile(), the file would not be deleted automatically by Wt afterwards.
Moreover, I could call request.uploadedFiles()to get an uploaded file map. The uploaded file map was in the form of std::multimap<std::string,Wt::Http::UploadedFile>. Thus, I would have to navigate through the std::multimap in order to access functions of all the uploaded files at once. It was demonstrated by the code below.
std::multimap<std::string, Wt::Http::UploadedFile> uploadedFileMap = request.uploadedFiles(); for (std::pair<std::string, Wt::Http::UploadedFile> element:uploadedFileMap) std::cout << element.first << element.second.spoolFileName() << element.second.clientFileName() << element.second.contentType() << std::endl;
Furthermore, I worked on nextpnr to perform place and route for the wishbone switch. When I executed nextpnr-ice40, I received the following error.
Device utilisation ICESTORM_LC: 187/1280 14% ICESTORM_RAM: 0/16 0% SB_IO: 317/112 283% SB_GB: 5/8 62% ICESTORM_PLL: 0/1 0% SB_WARMBOT: 0/1 0%
This clearly showed that SB_IO was overutilised. Only when I reduced both the address width and the data width of the wishbone switch from 32 bits to 8 bits, I managed to perform place and route with nextpnr-ice40. At this point I was still not very sure about utilisation of nextpnr so I had to continue to work on it.
All in all, the progression for this week was decent. I hoped that this post could provide some support towards the Wt community.
0 Comments