nldb lives on ...

I got an email from gburdell77@gmail.com regarding nldb:

grabbed source from //http://sourceforge.net/projects/nldb
(thanx kpfalzer), and started adding some jni stuff.
Plan on using jni to hook to C/C++ to add tcl cli

This is great news, since I have heard grumbles from others that they
like the idea of nldb, but would prefer to use tcl!

So, here's to george for adding this!

Check for port differences

I uploaded to http://nldb.sourceforge.net a script bin/portdiff (see ruby/srcs/portdiff.rb for details):

Usage: portdiff topModule gold.v rev.v libs.v ...

Load gold.v and rev.v and any remaining libraries: libs.v.
Link each (gold and rev) at level topModule.

Print ports which are not in the intersection set of ports
of gold and rev.

This utility is useful for communicating a block's pin changes to a place and route team, for example; since they will always want to know if there are new or removed block pins which could trigger a new floorplan exercise.

Once you download and install:

[karl@localhost nldb]$ pwd
/home/karl/projects/local/nldb
[karl@localhost nldb]$ cd tests/t2
[karl@localhost t2]$ java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)
[karl@localhost t2]$ jruby -v
jruby 1.2.0 (ruby 1.8.6 patchlevel 287) (2009-03-16 rev 9419) [amd64-java]
[karl@localhost t2]$ ../../bin/portdiff block block.gv block.rev.gv
Info: block.gv: processed in 0 (secs).
Info: linking references ...
Info: link (references) time: 0 (secs).
Info: linking connections ...
Info: link (connections) time: 0 (secs).
Info: 0 (secs): total elapsed.
Info: block.rev.gv: processed in 0 (secs).
Info: linking references ...
Info: link (references) time: 0 (secs).
Info: linking connections ...
Info: link (connections) time: 0 (secs).
Info: 0 (secs): total elapsed.
Info: block: 2 added, 1 removed in revised
Warn: block: port "i4" added in revised
Warn: block: port "i5" added in revised
Warn: block: port "z3" removed in revised

That's all for now.

Remove all unreachables

I uploaded to http://nldb.sourceforge.net/ a more comprehensive solution to the unreachable removal issue I detailed in my earlier blog.

The details of the unreachable algorithm are in file ruby/srcs/unreach.rb.

I made the nldb system more irb friendly, which required a little hack so I could pass -Xmx arguments through to the jvm.

So, we can go interactive to remove unreachables:

> java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)
> jruby -v
jruby 1.2.0 (ruby 1.8.6 patchlevel 287) (2009-03-16 rev 9419) [amd64-java]
> pwd
/.../nldb/tests/t2

## Launch irb after loading nldb
> ../../bin/nldb

## Load xlnx.lib.gv library and unreach.xlnx.gv netlist and link top 'unreach'
irb(main):001:0> top = Vmodule.new('unreach', '--lib xlnx.lib.gv unreach.xlnx.gv'.split)
Info: xlnx.lib.gv: processed (as a library) in 0 (secs).
Info: unreach.xlnx.gv: processed in 0 (secs).
Info: linking references ...
Info: link (references) time: 0 (secs).
Info: linking connections ...
Info: link (connections) time: 0 (secs).
Info: 0 (secs): total elapsed.

## Load 'unreach.rb'
irb(main):003:0> require 'unreach'
=> true

## Delete all unreachable cells in design referenced in top (we loaded above).
irb(main):004:0> delete_all_unreachable(top, true, nil) {c true}
Info: Unreachable pass 1 ...
Info: unrch_d1_2_3: unreachable (deleted)
Info: unrch_d1_2_2: unreachable (deleted)
Info: unrch_d1_2_1: unreachable (deleted)
Info: unrch_d1_2_0: unreachable (deleted)
Info: Unreachable pass 2 ...
Info: \Madd_unrch_d1_2_add0000_xor<3>11: unreachable (deleted)
Info: Madd_unrch_d1_2_add00001: unreachable (deleted)
Info: \Madd_unrch_d1_2_add0000_xor<2>11: unreachable (deleted)
Info: \Madd_unrch_d1_2_add0000_xor<1>11: unreachable (deleted)
Info: Unreachable pass 3 ...
Info: Madd_unrch_d1_2_add000071: unreachable (deleted)
Info: \Madd_unrch_d1_2_add0000_cy<1>11: unreachable (deleted)
Info: unrch_d1_1_2: unreachable (deleted)
Info: Unreachable pass 4 ...
Info: unrch_d1_1_0: unreachable (deleted)
Info: unrch_d1_1_1: unreachable (deleted)
Info: unrch_d1_1_3: unreachable (deleted)
Info: Unreachable pass 5 ...
Info: After pass 1: 4 unreachable cell(s) deleted
Info: After pass 2: 4 unreachable cell(s) deleted
Info: After pass 3: 3 unreachable cell(s) deleted
Info: After pass 4: 3 unreachable cell(s) deleted
Info: 14 unreachable cell(s) deleted
=> 14

## Save our updated top design into 'unreach.save.gv' netlist
irb(main):005:0> top.save(top.to_s+'.save.gv')
Info: unreach.save.gv: generating ...

irb(main):006:0> exit

To be continued...

Verilog netlist manipulations begin

I posted the 1st (re-written) version of the nldb project to: http://nldb.sourceforge.net.
As I had last mentioned at my other (related) project: http://v2kparse.blogspot.com, I realized a need (and opportunity) to solve an immediate issue, so re-architected nldb to use Java and Ruby.

The first use I found was to indentify and remove unreachable flip-flops from a netlist. There is a simple example in the download:

1) download release: nldb-1.0.tar.gz
2) unload and install
  mkdir nldb
   cd nldb
   tar zxvf ../nldb-1.0.tar.gz
3) make sure you have a java JRE and jruby installed:
  java -version
      java version "1.6.0_11"
      Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
      Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode)
  jruby -v
      jruby 1.2.0 (ruby 1.8.6 patchlevel 287) (2009-03-16 rev 9419) [amd64-java]
4) run the testcase (which is based on a Xilinx generated netlist):
  cd tests/t2
   ../../bin/nldb unreach --lib xlnx.lib.gv unreach.xlnx.gv
      Info: xlnx.lib.gv: processed (as a library) in 0 (secs).
      Info: unreach.xlnx.gv: processed in 0 (secs).
      Info: linking references ...
      Info: link (references) time: 0 (secs).
      Info: linking connections ...
      Info: link (connections) time: 0 (secs).
      Info: 0 (secs): total elapsed.
      Info: Unreachable pass 1 ...
      Info: unrch_d1_2_3: unreachable (deleted)
      Info: unrch_d1_2_2: unreachable (deleted)
      Info: unrch_d1_2_1: unreachable (deleted)
      Info: unrch_d1_2_0: unreachable (deleted)
      Info: Unreachable pass 2 ...
      Info: unrch_d1_1_0: unreachable (deleted)
      Info: unrch_d1_1_2: unreachable (deleted)
      Info: unrch_d1_1_1: unreachable (deleted)
      Info: unrch_d1_1_3: unreachable (deleted)
      Info: Unreachable pass 3 ...
      Info: After pass 1: 4 unreachable cell(s) deleted
      Info: After pass 2: 4 unreachable cell(s) deleted
      Info: 8 unreachable cell(s) deleted
      Info: unreach.save.gv: generating ...

NOTE: While I did use Xilinx ISE to generate a netlist from Verilog RTL (see tests/t2/unreach.v), be advised that the Xilinx synthesis tool does normally remove unreachable logic automatically (by default).

I coerced the tool to retain unreachable flops by embedding KEEP meta-comments in the RTL.

If I did not add the KEEP, the generated netlist would have removed the unreachables; and, this nldb example would not have been very interesting...

(Phew, hopefully that disclaimer will keep the Xilinx fans and lawyers from accusing me of spreading FUD!)

Now, in my normal day job, I synthesize for ASIC implementation (not FPGAs, currently). The ASIC synthesis tools often generated netlists w/ unreachable logic. Most times, it is a user/flow issue: i.e., there are dont-touches, desire for simpler FEC (formal equivalency checking), constraints, etc.

For whatever reason, my need was simply to find out any unreachables and then delete them. As is stated in the usage of my example:

#from tests/t2 directory
../../bin/nldb
  ...
  The unreachable algorithm repeatedly removes any unreachable flops until there
  are no more unreachable flops remaining.  This *repeat* operation is required,
  since there may be "pipelines" which are ultimately unreachable.

  A side-effect of removing (only) the unreachable flops could yield orphan
  (combinational) logic (which formerly fed into the now removed unreachable
  flops).  A future enhancement (or your own ruby code!) could add that
  enhancement.

So, that's all for now.
Enjoy!