Tyler Anderson 
Tue Mar 10 09:47:04 EDT 2015
cmd_testing2

For testing ideas to simplify and clean up some of the interfaces 
(e.g., the command interface). We're trying to stick with only 
Verilog 2001. (SystemVerilog and VHDL have their own abstract 
data types to do this a little more cleanly.)

I've settled on using macros to do the job. 

The downside of using macros is that they are in the global 
namespace, so collisions are possible. 

The solution is to give all macros descriptive and unique names. 

I'd prefer using something like a verilog function and localparam. 
The problem with this strategy is that functions only return values, 
so you can't do things like use a function to slice a vector on the 
left side of an assignment.  

There's a nice paper on using Verilog macros included here.

-----------------------------------------------------------------
Tue Mar 10 15:47:34 EDT 2015

A few thoughts:
--- The idea would be that all macros to parse command structures
    would go in cmd_defs.vh. This has the appropriate guards to 
    be included any old place. 

--- A state machine for each module to parse and handle commands
    can be kept in <module name>_cmds.v. It will have inputs that
    are cmd, sts, busy; outputs that are ctl, req.   

--- Originally, I had added clock domain crossing resources for
      all modules. However, it seems that our data rates are
      low enough that we can probably run all the core logic at
      1/4 the sampling frequency. 

--- If we do end up having to cross clock domains, this should
      be done seemlessly in FCR. 

--- There are three types of commands: control, status, and run.
      Control is shown in the examples for TAP here. 
      Status is easy, just latch whatever is requested.
      Run will require some req and busy handshaking.