Tuesday, July 14, 2015

Weeknight Hack #17 - Keeping a Pulse

No rocket science tonight.  Just some easy hacking.

I finally root caused the Z-wave device interview failure that I was facing.  The reason for failure was defective daughter board from zwave.me.  It was a hunch that I had a few weeks back.  On a whim, I obtained a replacement board and only got around to trying it tonight.

Also, I resolved networking issues on my Raspberry Pi.  My home router (a very basic one that I've had since college) doesn't support port forwarding to DHCP clients.  I will need the port forwarding to control my HAN from outside the home.  The workaround was setup the Pi to use a static IP.  The router supports port forwarding to static IPs.

It is work in progress to schedule in a weeknight to work on off-the-clock projects.  I hope to resolve this soon (requires coordinating with the wife).  The other issue has been lack of A/C in my office / workshop (garage actually!).

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;

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.