Nick Jones

I bought a Yubikey with the intention it's another way to login and not necessarily required to login. The idea is that if I turn over dead one day, my family could recover the artifacts of my digital life and it's crazy password arrangements. Amidst searching and reading just about everything I could find on how to properly integrate a Yubikey into my OSX authentication left me unsatisfied; either it was required for authentication or it didn't work at all.

I was looking to enable Yubikey login as an optional way of logging in on OSX but also allowing so offline thus requiring the use of challenge-response mode. I configured the second slot of my key to offer this mode and left slot one for the online YubiCloud OTP authentication. The online OTP works like a champ on Ubuntu as desired. On OSX, I wanted to enable offline challenge-response mode authentication as an optional way to authenticate.

This morning I took the plunge and upgraded from 13.10 to 14.04 on Xubuntu x64. Everything went fairly well in package swaps but a curious new feature in 14.04 caused some headaches: gpu-manager and ubuntu-drivers-common. Turns out that there's a nifty bit of code part of ubuntu-drivers-common that re-initializes xorg.conf each boot; great if you have a super simple config... If you would like to keep your custom xorg.conf each boot, add nogpumanager to /etc/default/grub in GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nogpumanager"

Beer of the night - 12/23/2013

Today I encountered some an interesting behavior related to updating a UVM scoreboard to use backdoor register accesses.  The original implementation timed behavior changes in the RTL with cycles on the bus as seen by updates to the register database model. For instance, the write function would sample the current register state of the enable bit. If there was a change, the scoreboard could predict the change in output accordingly; register changes always created a two clock delay in behavior change.  This prediction model worked well until a recent change that made the delay variable. No problem, switch to backdoor accesses that require zero time and instantly reflect the value used by the DUT.

Wrong. Well, at least based on having implemented all of the scoreboard checking using functions. The get_mirrored_value method is a function but both methods (peek and read) for reading the backdoor are tasks! Ok, so just make everything a task in the scoreboard outside the write function.

Done. But wait a minute... why does the clock change in the middle of my scoreboard routine if a register read cycle hits the bus? I have no idea...

Turns out the UVM library makes all accesses atomic through their API and thus can serialize the scoreboard peek behind a frontdoor read. Luckily, the design I'm verifying updates the backend register logic in a single atomic access, so I ripped up the UVM library's DPI access mechanism and implemented a non-semaphore version within the scoreboard class. No more random timing issues and up-to-date samples for the scoreboard.

UVM Backdoor DPI Read Code

I was doing some work on a branch this week that involved some fairly heavy changes to a tree structure and the contents to it (think starting from scratch sorta).  I wanted to make sure I had only committed changes to files as intended on the branch.  The following alias will give a summary diff of the branch as a delta to master:

bstats-master = "!f() { git rev-parse —abbrev-ref HEAD; }; git diff —stat —color master..$f"

The prior alias works well if master is only as up to date (locally) as when the branch was created I had come to find out.  This version is based on branch parent (regardless of where master is currently):

Awhile back, I posted an article about quickly translating the current buffer in Vim to HTML using the following:

:runtime! syntax/2html.vim

However, there's an even better way (at least for me to memorize):

:TOhtml

Beer of last night.  I won't recommend it but it was good to try another gluten free beer at least.  I'm not sure it's really the fault of the Sorgham that makes the beer less enjoyable as it is the recipe of hops.  The grassy and citrus flavors are not unwelcome; however, the final bitter aftertaste is definitely unpleasant.