Thursday, June 25, 2015

Mid-June update

It's been a busy month on the home front.  I fell behind on CS100.1x and decided to put that effort on hold.

Here is a wonderful article about goal setting and how it may not be optimal: http://jamesclear.com/goals-systems

The synopsis of the article is to focus on a system (i.e. weekly blogging) rather than having a singular focus on a goal.  This would have helped me, more than you can imagine, in my previous life as a competitive distance runner.

Monday, June 8, 2015

We^D^D Monday Night Hack #16 - N/A

I reached the anti-climactic end of the Google foobar challenge.  Quite unfortunate.  Last night, I was working on a level 3 problem (spring_cleaning).  I had 4 of 5 test cases passing and, fast forward a day, had a good hunch idea on why the last test case was failing.


I found out after the fact that Google was using this challenge as a recruiting tool.  Brilliant!  I honestly had no idea.  I am not sure how it works, but I would assume that breaking level 5 in the predefined period of time might indicate an exceptional computer scientist - at which point they'd engage their army of recruiters :P  I am humbled by those that can pull that off.

Tomorrow, I will be participating in Qualcomm's (my employer) first ever Data Mining Competition.  I'll spend the rest of the evening working on CS100.1x in preparation.

Wednesday, June 3, 2015

Wednesday Night Hack #15 - foobar and CS100.1x

Tonight, I spent time on Google's foobar coding challenge.  It was good opportunity to hone my Python skills.  I'll update once I crack level 3.


I have also registered and started another massively online course.  This time CS100.1x, Introduction to Big Data with Apache Spark offered by BerkeleyX.  Time commitment for this one looks minimal. The syllabus estimates 25 hours over 5 weeks.  I'll update with a recap afterwards.

Wednesday, May 20, 2015

Wednesday Night Hack #14 (Part 2) - Chisel Blob Arbiter

Part 2 of my Wednesday Night Hack!

I remember reading an old article about arbiter coding styles.  There is a section where he refers to coding the arbiter as a big blog.  The results state that the big blog coding style offers better timing, area, and compile time than the novel approaches he presents.  I quote: "a sixty-four requester version of this coding style was not implemented due to the amount of tedious typing it would have required".  I thought this to be the perfect example to try with a chip generator tool.  Chisel in this case.

Here is the 4 requester version of his code :


always@(pointer_reg or req) begin
  case (pointer_reg)
  2'b00 :
    if (req[0]) grant = 4'b0001;
    else if (req[1]) grant = 4'b0010;
    else if (req[2]) grant = 4'b0100;
    else if (req[3]) grant = 4'b1000;
    else grant = 4'b0000;
  2'b01 :
    if (req[1]) grant = 4'b0010;
    else if (req[2]) grant = 4'b0100;
    else if (req[3]) grant = 4'b1000;
    else if (req[0]) grant = 4'b0001;
    else grant = 4'b0000;
  2'b10 :
    if (req[2]) grant = 4'b0100;
    else if (req[3]) grant = 4'b1000;
    else if (req[0]) grant = 4'b0001;
    else if (req[1]) grant = 4'b0010;
    else grant = 4'b0000;
  2'b11 :
    if (req[3]) grant = 4'b1000;
    else if (req[0]) grant = 4'b0001;
    else if (req[1]) grant = 4'b0010;
    else if (req[2]) grant = 4'b0100;
    else grant = 4'b0000;
  endcase
end

Nothing special here.  It is clear that code would explode with larger input vectors.

Here is my untested Chisel implementation :


class BlobArb(width: Int) extends Module {
  val io = new Bundle {
    val request = UInt(INPUT, width)
    val pointer = UInt(INPUT, log2Up(width))
    val grant = UInt(OUTPUT, width)
  }

  io.grant := UInt(0)  // Chisel complains if no default value is specified

  for (i <- 0 until width) {
    when(io.pointer === UInt(i)) {
      for (j <- 0 until width) {
        var x = (i + j) % width
        when(io.request(x)) {
          io.grant := UInt(1 << x)
        }
      }
    }
  }
}

I'll re-iterate.  This isn't tested.  I simply don't have the time.  But, I do have time for some quick commentary.

I kind of expected that I could look at the generated Verilog code (link) and visually check whether my Chisel implementation matched the reference implemented in Verilog.  I did not find it to be the case.

From the perspective of a seasoned verification engineer, I observe the following major flaw.  There will come a time where the Chisel-based design will need to be simulated at the full-chip level.  When (not if) there is a bug, I am not sure how one correlates a node the generated Verilog netlist to Chisel source.  I would assume this has been solved because the great folks at Cal have done multiple chip tapeouts using Chisel as their primary HDL.

As interesting of an HDL that Chisel is... Gosh... I have mixed feelings.  I am intimately familiar with Verilog coding guidelines for synthesis.  I barely wrote any code and I found myself asking whether the final Verilog output would match my expectations.  There is an order of magnitude of additional freedom.  Freedom in describing hardware does not come without consequences. More hands on experience would obviously help here.

To the key issue of chip generators.  Verilog parameters aren't nearly enough.  Perl and Verilog can take you pretty far and Genesis2 (Perl and Verilog on steroids, though unsupported) can take you even further.  My crystal ball is that some design-by-committee solution will result in to improvements to SystemVerilog.  The improvements, of course, will take a decade to roll out.

Next steps for Chisel and I? I don't know.  My blog is means to get creative juices flowing, not necessarily for deep dives.  Hoping that one day some topic will call for more a move in-depth investigation.

Wednesday Night Hack #14 (Part 1) - Home Automation Fail!

I recently purchased a Raspberry Pi and companion Razberry daughter board for the purposes of building up my home automation network (HAN).  The daughter board hosts a Sigma Designs ZM5202 Z-Wave transceiver module with custom (read: proprietary) firmware.  A well featured low-level software stack (middleware) is also provided.  This software provides different ways for users to access the devices on their HAN.  In addition to a web service, there is a C API and JSON API available.  The web service allows users to setup and debug their network without writing a single line of code.  Sample programs (and Android, IOS app) are also provided.

All in all, I am impressed.  I was not expecting this level of software support.  My one caveat is that the board's firmware appears to be closed source.  This would mean that any software written using the provided API would be bound to the vendor's product.  For the average hobbyist who is looking to get something done, quickly, I guess there is no harm.  I would think twice about using this platform to develop a commercial product.  Luckily, there appears to be a open source alternative.

Given that I do not have any commercial intentions, I'll continue on... or not..

I couldn't include the device on the network.  I tried for a good hour.  I'll be returning deadbolt I purchased and try again another time.  Next time, I will make sure to pair the device before installing the deadbolt on my front door, oops!