Re: VIS: pseudo-inputs, primary-inputs and clock

From: Fabio Somenzi (Fabio@colorado.edu)
Date: Wed Mar 13 2002 - 01:09:20 MST

  • Next message: Hess Hodge: "Re: VIS: pseudo-inputs, primary-inputs and clock"

    Hess,

    >>>>> "HH" == Hess Hodge <hhodge@cray.com> writes:

     HH> Hello,
     HH> First, here is some background: I'm using VIS-1.4, and I'm using synopsys
     HH> and edif2blif to create a blif file from verilog.

     HH> Here are a few VIS questions for you:

     HH> 1) Once I read in the design, I notice that there are a number of
     HH> pseudo-inputs associated with my registers, their names end in $INIT. So,
     HH> these pseudo-inputs are there to model nondeterminism on the initial-state
     HH> of these registers, right? How can I set these registers to a known
     HH> initial-state?

    Do you have an "initial" statement in your verilog description? I
    don't know exactly what the synopsys edif filter will do to such an
    initial statement, but that would be the first thing to look at.

     HH> 2) I also have a number of primary-inputs in my design. When I check my
     HH> design I want to place a constraint on the inputs. Say, for example, I
     HH> want to constrain inputs A and B so that it is never the case that
     HH> both are set, ie !(A=1 * B=1). Is there a way to constrain the inputs?

    The only practical way is to add an environment module, also in
    verilog, that produces A and B from some input C through a case
    statement.

     HH> 3) My verilog design has a clock input called "Lclk". I translate
     HH> the verilog to edif and then to blif. The resulting blif file has a
     HH> number of .latch statements like the following:

     HH> .latch i_reset reset_reg re Lclk 2

     HH> (input = i_reset, output = reset_reg, and it is clocked on the rising edge
     HH> of Lclk, with an initial value of "dont care")

     HH> Then, when I read this blif file into VIS, I get the following warning:
     vis> read_blif -v csi_inbound_ctrl.blif
     HH> Warning: Variable Lclk is not used in csi_inbound_ctrl.

     HH> Has my Lclk been abstracted out of the design at this point? Do I need to
     HH> edit my blif file to include a .clock statement?

    If Lclk is the only clock, all should be well. The global clock is
    indeed abstracted. If you look at the blif-MV produced by vl2mv,
    you'll see that the global clock does not appear among the module
    ports.

    Fabio

    -- 
    Fabio Somenzi          | Phone: 303-492-3466
    University of Colorado | Fax:   303-492-2758
    ECE Dept.              | Email: Fabio@Colorado.EDU
    Boulder CO 80309-0425  | WWW:   http://vlsi.colorado.edu/~fabio
    



    This archive was generated by hypermail 2b30 : Wed Mar 13 2002 - 01:15:35 MST