Friday, June 24, 2016

Let's Silicon

As the title may suggest , most part of the next part pf my GSoC will be making hardware modules for RISC-V cores and interfacing them to make a processor !. 

I already have a working and tested myHDL based decoder in place. I am now in discussions with my mentor to finalize a RISC-V module which I can port to myHDL. This will embark the next phase of my coding in GSoC. 

We will be selecting a RV32I based core to implement in the coming weeks as the HDL decoder fully supports RV32I at the present.

I have also shifted my development on the `dev` branch keeping my `master` up to date with the main repository. 

See you next week. 
MS 
  

Sunday, June 12, 2016

Developer's Den

This week was a fun filled week. I had to setup continous integration, documentation, test coverage and code quality tags for my repository.

I always wanted to have those tags for my repository like the professinal OS repositories on github. Turns out this was my chance.

We chose travis for CI, coveralls for test coverage, landscape.io for code quality and readthedocs for documentation. It was a bit difficult to get all in place at first , but once I got a hold of it, it became very easy to setup.

One another important progress this week was that I got my First PR merged into the main repo :). with the python decoder, I am looking forward to get the hdl decoder working as soon as possible so that I can move on to the real RISC-V processor design.

This week was majorly getting the PRs and repo workflow in place with some interaction with my mentor and invaluable tips from his end.

With all things cleared up I think I am good to go for the coming weeks !.

See you next week,
MS

Friday, June 3, 2016

The Code has been broken !


The RISC-V is one of the most structured ISA I have come across so far , hence it was easy for me to design a structural module for the decoder. Like any other RISC instruction set, RISC-V also has a family of instructions with similar family-code and argument list. These instructions which belong to a particular family are distinguished by their own instruction opcodes.

Since the number of families in the ISA was not very large , I chose to segregate the instructions by their family first and then to decode the exact instruction by extracting its individual opcode.

This sounded all fine when I planned it. But the implementation was a bit difficult than I had thought. I had to come up with a data structure that can efficiently store multiple hierarchies of keys and values as the bitwise difference of different instructions was quite varied especially in the non logical and arithmetic instructions.

I decided to go with the multiple-key dictionary available directly in python. I made a hierarchy of keys , each differentiating one instruction from each other, First key being the family-code. Maximum number of keys that I had to use per instructions was 4, in very large families [0x14, 0x1C] etc.

Sample Decode Logic :

`addw rd rs1 rs2 31..25=0 14..12=0 6..2=0x0E 1..0=3`

My decoder will extract the 5 bit family-code from `6 to 2`, the 7 bit slice and the 3 bit slice from `31 to 27` and `14 to 12` respectively. Thus as you can probably guess, the order of the keys will be family-code-> 3-bit slice -> 7-bit slice. 

Thus when these keys are fed to the decoder table, it spits out the instruction name. Once we have the instruction name we can easily extract the arguments it takes from the 32 bit instruction.

I got a lot of help from the opcode repository from risc-v as it listed down the args, opcodes and instruction names in a very lucid readable manner.

Then came the testing part. I created the tests for each instruction and test method for each family. Thankfully they all passed :).

So I guess the code has indeed been broken. Now I have to move on with the remaining RISC-V implementation.

See you next week,
MS