No More Ads, Send Tips with Bitcoin

Summary: ads are gone, send me bitcoin to say thanks instead.

I have always kept notes for myself to remind myself how to do various things. I have also kept a journal since a very young age where I often include opinions and thoughts on various matters. At some point, years ago, I got the idea that I should post some of the notes and thoughts in case they would help someone else. That requires a lot more work than just typing stuff quickly into a text file, though, so I needed a little more motivation. I mean, sharing and helping others is great motivation, but when I read about Adsense from Google, and how Google could show people links to products and services related to my posts, and I could make a few bucks if people thought those links were useful and clicked on them, and how it could help out the people providing those products and services as well, it felt like this great intertwined synergy of helping people out and possibly even gaining some monetary reward as well. And it sort of worked. I put some effort into this blog and my Adsense account started slowly accumulating some credits.

The one downside was, well, advertising. It's often more annoying than helpful. Google's adds were the least annoying I've seen, but still not always that great. To be honest, this blog isn't updated enough and isn't high traffic enough that I'm really sending a lot of business anyone's way, and I'm not making any kind of real money at all with the adds. I've thought about this on and off over the years, but haven't changed anything, until now. What happened is, I finally read up on this crazy thing I'd seen mentioned on Slashdot and Hacker News called bitcoin.

The notion of a digital currency seemed ludicrous when I first read headlines and article summaries about it, and so I ignored it for a while. Now, the more I read about it, the more it makes sense, and the more excited I get about it. You really should go to We Use Coins and learn more, they can explain it better than me. The relevant part of bitcoin to this post is that it is super easy to send money from one person to another with bitcoin. No banks, escrow services, or credit cards are required. If you want to donate money to me to say thank you it's as simple as firing up your bitcoin wallet software and sending coins to this address: 15RNcXeuhjQRKnfLGyVZxpeER8MUmrYLMq. It's a lot like cash that way, only you don't have be standing next to the person you want to pay in order to make the transaction. Way cool. Liberating, in fact. That's what really appeals to me. The lack of central control, and the ease and freedom it provides. Nothing crazy about that.

Now, I didn't just put that bitcoin address in the sidebar of my blog, I used a Coinbase payment button. Coinbase is an online wallet, which is a little more convenient (but less decentralized and free) than running the bitcoin software on your own machine (of course, you can do both). The cool thing the button of theirs provides is a unique bitcoin address for every transaction. That just makes the payments more anonymous. I could have written software to generate those addresses and the button myself, but I'm OK with letting them handle that for me. At least for now as I'm testing the bitcoin waters.

List Foreign Keys in Your Postgresql Database

I wanted to know which tables referenced a certain other table in my database, but being a very occasional user of SQL, I didn't know where to begin to find that. Fortunately, the internet had the answer, from Tom Lane himself actually. Just run this query on your Postgresql database:

select confrelid::regclass, af.attname as fcol,
       conrelid::regclass, a.attname as col
from pg_attribute af, pg_attribute a,
  (select conrelid,confrelid,conkey[i] as conkey, confkey[i] as confkey
   from (select conrelid,confrelid,conkey,confkey,
                generate_series(1,array_upper(conkey,1)) as i
         from pg_constraint where contype = 'f') ss) ss2
where af.attnum = confkey and af.attrelid = confrelid and
      a.attnum = conkey and a.attrelid = conrelid;

That shows all foreign key relationships in your database. If you just want to see which tables reference a particular table, do this (replace my_table and my_referenced_column with the table column you want to see the references to):

select confrelid::regclass, af.attname as fcol,
       conrelid::regclass, a.attname as col
from pg_attribute af, pg_attribute a,
  (select conrelid,confrelid,conkey[i] as conkey, confkey[i] as confkey
   from (select conrelid,confrelid,conkey,confkey,
                generate_series(1,array_upper(conkey,1)) as i
         from pg_constraint where contype = 'f') ss) ss2
where af.attnum = confkey and af.attrelid = confrelid and
      a.attnum = conkey and a.attrelid = conrelid 
  AND confrelid::regclass = 'my_table'::regclass AND af.attname = 'my_referenced_column';

I love that I can get personal attention from the main developers of software tools that I use. Even if it was really only personal for the original person who asked the question :-)

Free Verilog Simulators

At DVCon 2013 I asked JL Gray's panel if we would ever have Free tools, like the software world. None of panelists seemed to think so, one of the panelists, a Mentor employee, scoffed, "you get what you pay for with free tools." Never mind that their (and Cadence's and Synopsys's) products are very likely developed with tools that contain millions of lines of Free software.

So, to work towards answering my own question, I spent a little time and looked for Free/Open Source verilog simulators. Here's what I found:

Icarus Verilog

GPL Cver

PVSim Verilog Simulator

VeriWell Verilog Simulator

I have personally used Icarus and Cver before, but not very extensively.  They were usable and seemed pretty complete, for Verilog.  None of the above claim any support of SystemVerilog except for Icarus.  The Icarus developer at one point expressed abhorrence at SystemVerilog but it seems support for some parts of the language have been added.

PVSim and VeriWell were new to me.  I'll give them a try, hopefully soon, and post more information.

Another one that should be mentioned is Verilator.  I have downloaded and played with this one too.  It only supports synthesizable Verilog, so have fun writting a testbench.  I think the intent is for you to write your testbench in C++, so if you like that idea than this could be a good one to try too.

Did I miss any?

SystemVerilog String Literal "Gotcha"

I just ran into another fun SystemVerilog Gotcha. Look this code over and see what you think should happen:

module top;
   string foo[byte];
   byte bar;
   initial begin 
      $display("%0d", "a string" == foo["not a byte"]);
      foo["e"] = "a string";
      $display("%0d", "a string" == foo["not a byte"]);
      bar = "not a byte";
      $display("bar: %0s", bar);
   end 
endmodule 

Compile error, right? You can't index into an associative array with a string when it is declared to take a byte, can you? And you can't assign a string to a variable of type byte, right?

Ha! This actually compiles and runs without any errors or warnings. String literals are packed arrays of bytes and they are automatically truncated to the width of the thing they are being assigned to. Here's the output from running the above code:

0
1
bar: e

After my last blog post I was informed that there's a book that has 101 SystemVerilog Gotchas in it. I didn't believe it, but I think I'm starting to see how it could be possible.

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either.

I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor.

OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this:

module top;
   task do_stuff(int wait_time);
      #wait_time $display("waited %0d, then did stuff", wait_time);
   endtask 
 
   initial begin 
      fork 
         do_stuff(10);
         do_stuff(5);
      join 
   end 
endmodule 

both do_stuff calls will wait for 5 time units, and you see this:

waited 5, then did stuff
waited 5, then did stuff

I suppose being static by default is a performance/memory-use optimization, but it's guaranteed to trip up programmers who started with different languages. The fix is to make the task "automatic" instead of static:

module top;
   task automatic do_stuff(int wait_time);
      #wait_time $display("waited %0d, then did stuff", wait_time);
   endtask 
 
   initial begin 
      fork 
         do_stuff(10);
         do_stuff(5);
      join 
   end 
endmodule 

And now you get what you expected:

waited 5, then did stuff
waited 10, then did stuff

Now let's get a little more tricky. Say you want to only wait until one of the forked processes finishes, so you do this:

module top;
   task automatic do_stuff(int wait_time);
      #wait_time $display("waited %0d, then did stuff", wait_time);
   endtask 
 
   initial begin 
      fork 
         do_stuff(10);
         do_stuff(5);
      join_any 
      $display("fork has been joined");
   end 
endmodule 

You'll get this output:

waited 5, then did stuff
fork has been joined
waited 10, then did stuff

That's fine, but that extra action from the slower do_stuff after the fork-join_any block has finished might not be what you wanted. You can name the fork block and disable it to take care of that, like so:

module top;
   task automatic do_stuff(int wait_time);
      #wait_time $display("waited %0d, then did stuff", wait_time);
   endtask 
 
   initial begin 
      fork : do_stuff_fork
         do_stuff(10);
         do_stuff(5);
      join_any 
      $display("fork has been joined");
      disable do_stuff_fork;
   end 
endmodule 

Unless your simulator, like mine, "in the current release" will not disable sub-processes created by a fork-join_any statement. Bummer. It's OK, though, because SystemVerilog provides a disable fork statement that disables all active threads of a calling process (if that description doesn't already make you nervous, just wait). Simply do this:

module top;
   task automatic do_stuff(int wait_time);
      #wait_time $display("waited %0d, then did stuff", wait_time);
   endtask 
 
   initial begin 
      fork : do_stuff_fork
         do_stuff(10);
         do_stuff(5);
      join_any 
      $display("fork has been joined");
      disable fork;
   end 
endmodule 

And you get:

waited 5, then did stuff
fork has been joined

Nothing wrong there. Now let's say you have a class that is monitoring a bus. Using a classes are cool because if you have two buses you can create two instances of your monitor class, one for each bus. We can expand our code example to approximate this scenario, like so:

class a_bus_monitor;
   int id;
 
   function new(int id_in);
      id = id_in;
   endfunction 
 
   task automatic do_stuff(int wait_time);
      #wait_time $display("monitor %0d waited %0d, then did stuff", id, wait_time);
   endtask 
 
   task monitor();
      fork : do_stuff_fork
         do_stuff(10 + id);
         do_stuff(5 + id);
      join_any 
      $display("monitor %0d fork has been joined", id);
      disable do_stuff_fork;
   endtask 
endclass 
 
module top;
   a_bus_monitor abm1;
   a_bus_monitor abm2;
   initial begin 
      abm1 = new(1);
      abm2 = new(2);
      fork 
         abm2.monitor();
         abm1.monitor();
      join 
      $display("main fork has been joined");
   end 
endmodule 

Note that I went back to disabling the fork by name instead of using the disable fork statement. This is to illustrate another gotcha. That disable call will disable both instances of the fork, monitor 1's instance and monitor 2's. You get this output:

monitor 1 waited 6, then did stuff
monitor 1 fork has been joined
monitor 2 fork has been joined
main fork has been joined

Because disabling by name is such a blunt instrument, poor monitor 2 never got a chance. Now, if you turn the disable into a disable fork, like so:

class a_bus_monitor;
   int id;
 
   function new(int id_in);
      id = id_in;
   endfunction 
 
   task automatic do_stuff(int wait_time);
      #wait_time $display("monitor %0d waited %0d, then did stuff", id, wait_time);
   endtask 
 
   task monitor();
      fork : do_stuff_fork
         do_stuff(10 + id);
         do_stuff(5 + id);
      join_any 
      $display("monitor %0d fork has been joined", id);
      disable fork;
   endtask 
 
endclass 
 
module top;
   a_bus_monitor abm1;
   a_bus_monitor abm2;
   initial begin 
      abm1 = new(1);
      abm2 = new(2);
      fork 
         abm2.monitor();
         abm1.monitor();
      join 
      $display("main fork has been joined");
   end 
endmodule 

You get what you expect:

monitor 1 waited 6, then did stuff
monitor 1 fork has been joined
monitor 2 waited 7, then did stuff
monitor 2 fork has been joined
main fork has been joined

It turns out that, like when you disable something by name, disable fork is a pretty blunt tool also. Remember my ominous parenthetical "just wait" above? Here it comes. Try adding another fork like this (look for the fork_something task call):

class a_bus_monitor;
   int id;
 
   function new(int id_in);
      id = id_in;
   endfunction 
 
   function void fork_something();
      fork 
         # 300 $display("monitor %0d: you'll never see this", id);
      join_none 
   endfunction 
 
   task automatic do_stuff(int wait_time);
      #wait_time $display("monitor %0d waited %0d, then did stuff", id, wait_time);
   endtask 
 
   task monitor();
      fork_something();
      fork : do_stuff_fork
         do_stuff(10 + id);
         do_stuff(5 + id);
      join_any 
      $display("monitor %0d fork has been joined", id);
      disable fork;
   endtask 
 
endclass 
 
module top;
   a_bus_monitor abm1;
   a_bus_monitor abm2;
 
   initial begin 
      abm1 = new(1);
      abm2 = new(2);
      fork 
         abm2.monitor();
         abm1.monitor();
      join 
      $display("main fork has been joined");
   end 
endmodule 

The output you get is:

monitor 1 waited 6, then did stuff
monitor 1 fork has been joined
monitor 2 waited 7, then did stuff
monitor 2 fork has been joined
main fork has been joined

Yup, fork_something's fork got disabled too. How do you disable only the processes inside the fork you want? You have to wrap your fork-join_any inside of a fork-join, of course. That makes sure that there aren't any other peers or child processes for disable fork to hit. Here's the zoomed in view of that (UPDATE: added missing begin...end for outer fork):

task monitor();
   fork_something();
   fork begin 
      fork : do_stuff_fork
         do_stuff(10 + id);
         do_stuff(5 + id);
      join_any 
      $display("monitor %0d fork has been joined", id);
      disable fork;
   end 
   join 
endtask 

And now you get what you expect:

monitor 2 fork has been joined
monitor 1 fork has been joined
monitor 1 waited 6, then did stuff
monitor 2 waited 7, then did stuff
main fork has been joined
monitor 1 waited 11, then did stuff
monitor 2 waited 12, then did stuff
monitor 2: you'll never see this
monitor 1: you'll never see this

So, wrap your fork-join_any inside a fork-join or else it's, "Gotcha!!!" (I can almost picture the SystemVerilog language designers saying that out loud, with maniacal expressions on their faces).

But wait, I discovered something even weirder. Instead of making that wrapper fork, you can just move the fork_something() call after the disable fork call and then it doesn't get disabled (you actually see the "you'll never see this" message, try it). So, you might think, just reordering your fork and disable fork calls and that will fix your problem. It will, unless (I learned by sad experience) the monitor task is being repeatedly called inside a forever loop. Here's a simplification of the code that really inspired me to write this all up:

class a_bus_monitor;
   int id;
 
   function new(int id_in);
      id = id_in;
   endfunction 
 
   function void fork_something();
      fork 
         # 30 $display("monitor %0d: you'll never see this", id);
      join_none 
   endfunction 
 
   task automatic do_stuff(int wait_time);
      #wait_time $display("monitor %0d waited %0d, then did stuff", id, wait_time);
   endtask // do_stuff 
 
   task monitor_subtask();
      fork : do_stuff_fork
         do_stuff(10 + id);
         do_stuff(5 + id);
      join_any 
      $display("monitor %0d fork has been joined", id);
      disable fork;
      fork_something();
   endtask 
 
   task monitor();
      forever begin 
         monitor_subtask();
      end 
   endtask 
 
endclass 
 
module top;
   a_bus_monitor abm1;
   a_bus_monitor abm2;
 
   initial begin 
      abm1 = new(1);
      abm2 = new(2);
      fork 
         abm2.monitor();
         abm1.monitor();
      join_none 
      $display("main fork has been joined");
      # 60 $finish;
   end 
endmodule 

The fork inside the fork_something task will get disabled before it can do its job, even though it's after the disable fork statement. Gotcha!!! Muhahahah!

My advice? Just always wrap any disable fork calls inside a fork-join.