From: suzanne@world.std.com (Suzanne Southworth)

 >Jean, John and I are going to send you some dog-food for your hilarious
 >drive. I am making up my own label with my face, my son's face and one
 >of my shelties' faces on an alpo can!
 >
 >  - Suzanne Southworth

 Although 23 letters were positive reactions like Suzanne's, 2 were negative.
 One of the two negative being from "dean@rb.unisys.com" (Dean Ranger) with:

 >John, I'm puzzeled; why the dog food drive for Joe Costello?  Do you also
 >feel threatened by Cadence's Services Division or is this just a ploy to
 >get more publicity for your consulting business?  Since Art feels so
 >threathened by Cadence's competion that he refuses to let Cadence Spectrum
 >Design (formerly Unisys employees) use Synopsys software, might he not
 >also consider your own "consulting" (services) business a threat and
 >refuse to let you use Synopsys software?  It seems to me that we need to
 >realize that it's Art De Gues who is acting like a dog fighting over a
 >bowl of dog food; so I propose a dog food drive for Art.  Better yet,
 >split the dog food between Cadence, Mentor, and Synopsys.
 >
 >  - Dean Ranger, Unisys/Cadence Spectrum Design

 Whoa!  Dean!  WHOA!!!  I'm completely lost here.  I didn't say a single word
 about Cadence Spectrum Design in the dog food drive announcement.  Joe's the
 one who brought up the dog food metaphor which raised quite a few chuckles
 and caused the humorous reactions.  Everyone talked about it.  It was even
 in that week's EE Times.  Joe & I have never been shy around each other.  By
 rights, since Joe created the metaphor, I felt he deserved the good natured
 fun associated with it.  (And I'm simply stumped as to *what* this has to do
 with Cadence Spectrum services...)
                                         - John Cooley
                                           the ESNUG guy

 P.S. Anyway, keep those cans of / checks for dog food coming!  :^)


( ESNUG 222 Item 1 ) ---------------------------------------------- [7/95]

From: fiedler@nvidia.com (Larry Fiedler)
Subject: A Collection Of Five 3.3a Fatals

John, 

We got bit by one 3.3a bug which results from unmapped logic being timed.
This happened by having a Flip-flop in a previous technology that had
a reset and clear but in the next technology there are reset *or* clear,
but not *both* types of flip-flops.  This caused unimplemented logic in 
synthesis which caused a fatal during timing.

There was also a 3.3a bug which had to do with reading a variable in two
Verilog "always" blocks.

Personally, I hate the new Synopsys Verilog 3.3a parser.  With the following:

  always@ (A0 or M)
        case (A0)       // synopsys full_case
                3'b 000 :       z0 = 0;
                3'b 001 :       z0 = M[0];
                3'b 010 :       z0 = M[1];
                3'b 100 :       z0 = M[2];
                default :       z0 = 1'bX;
        endcase

It has a "default" statement therefore it is complete by definition -- yet I
get the following message:

	Warning: You are using the \fBfull_case\fP directivewith a case
		statement in which not all cases are covered.  (HDL-370)

What is "\fBfull_case\fP" ??  Not all cases covered???   It has a "default"!
(Fortunately, the resulting logic seems correct.)

There's also a 3.3a bug that has to do with using a Verilog parameter as an
index to a vector.

	parameter N = 3;
	zn = Z[N];

the error being:  "Error: Untyped variable 'N' used"  -- huh?

The supposed solutions is to use a pre-3.3a reader or to change the source
code. This makes me mad!  It parsed well before, its very standard Verilog
not esoteric at all, and now it doesn't parse!  I hope this gets fixed for
3.3b.  Could I encourage proper Verilog parameter handling with "defparam"
at the same time?  I know I won't get this, but I ask at SNUG every year.
(Besides, if they fix it, then what will I get to complain about?)

After all of this my collegue is still getting an unknown 3.3a fatal during
the optimization stage.

  - Larry Fiedler
    NVidia


( ESNUG 222 Item 2 ) ---------------------------------------------- [7/95]

From: kurt@wsfdb.com (Kurt Baty)
Subject: 3.2b Lame Verilog To VHDL Translation Even With Bug Fix

John,

As you know, a lot of people use Design Compiler as one of the world's most
expensive Verilog to VHDL translators at times.  Doing this, I found:

    module test(ins,outs);
    parameter  width = 8;
    input   [width-1:0] ins;
    output  [width-1:0] outs;
    wire    [width-1:0] outs;
      assign  outs = ins;
    endmodule

Translated into VHDL as

    library IEEE;   use IEEE.std_logic_1164.all;
    package CONV_PACK_test is
      type typeId_0 is array (7 downto 0) of std_logic;
      type typeId_1 is array (7 downto 0) of std_logic;
    end CONV_PACK_test;

    library IEEE;   use IEEE.std_logic_1164.all;
    use work.CONV_PACK_test.all;

    entity test is
      generic( width : INTEGER:=8);
      port( ins : in typeId_0;  outs : out typeId_1);
    end test;

    architecture SYN_verilog of test is
    begin
      outs <= ( ins(7), ins(6), ins(5), ins(4), ins(3),
                ins(2), ins(1), ins(0) );
    end SYN_verilog;

When I try to hook this up to anything else, the weird "type typeId_0 is
array (7 downto 0) of std_logic;" is BAD NEWS.  By setting:

    dc_shell>vhdlout_single_bit = VECTOR

I now get an improved:

    library IEEE;   use IEEE.std_logic_1164.all;

    entity test is
      generic( width : INTEGER:=8);
      port( ins  : in std_logic_vector (0 to 7);
            outs : out std_logic_vector (0 to 7));
    end test;

    architecture SYN_verilog of test is
    begin
      outs <= ( ins(0), ins(1), ins(2), ins(3), ins(4),
                ins(5), ins(6), ins(7) );
    end SYN_verilog;

Which used the correct type (std_logic_vector) but the original Verilog [7:0]
bit order has been replaced by a reversed VHDL (0 to 7) bit order!  Ugh!

  - Kurt Baty
    WSFDB Consulting


( ESNUG 222 Item 3 ) ---------------------------------------------- [7/95]

From: [ Some Things Never Change ]
Subject: (ESNUG 221 #5)  DB2EDDM Chokes When Nets In Region Is High

>Synopsys supplies DB2EDDM as part of the SIFF software, which is a schematic
>translator.  When I use DB2EDDM for a design which has feedthroughs or
>shorted nets, DB2EDDM is expected to put a NETCON in the EDDM schematic that
>it creates.  I have a netcon symbol in the ".sdb" symbol lib that I use to
>create schematic.  I have a "-NETCON" entry in the "library.map" file used
>by DB2EDDM. It works properly when the designs having feedthroughs etc are
>small, but fails when the congestion is high, i.e. number of nets in 
>that region is large.  DB2EDDM gives :  "(warning) Unable to fix all
>feedthroughs on sheet <XXX> of design <YYY>."


John, As per norm, please keep me anonymous... some things may never change.

When transfering designs from Synopsys to Mentor here are the variables and
setups that we use in our .dc_setup file.  These were worked out over a
couple of years and to date work pretty well.

  /* Set up variables for db2eddm */
  single_group_per_sheet = "true";
  bus_naming_style = "%s(%d)";
  bus_range_separator_style = ":";
  gen_cell_pin_name_separator = "_";
  gen_match_ripper_wire_widths = "true";
 
  default_schematic_options = "-size infinite";
  compile_fix_multiple_port_nets = "true";
  write_name_nets_same_as_ports = true;

  /* Template name rule for Mentor environment */
  define_name_rules mentor -special siff
  define_name_rules mentor -replacement_char "_"
  define_name_rules mentor -equal_ports_nets -case_insensitive
  define_name_rules mentor -max_length 512
  define_name_rules mentor -type net -prefix "N" \
                        -allowed "A-Z a-z _ 0-9 ()" \
                        -first_restricted "0-9 _" -last_restricted "_"
  define_name_rules mentor -type port -prefix "P" \
                        -allowed "A-Z a-z _ 0-9 ()" \
                        -first_restricted "0-9 _" -last_restricted "_"
  define_name_rules mentor -type cell -prefix "I" \
                        -allowed "A-Z a-z _ 0-9" \
                        -first_restricted "0-9 _ ()" -last_restricted "_" \
                        -remove_chars

  default_name_rules = "mentor";

Note that the best way to transfer from Synopsys to Mentor is to have
Synopsys use infinite sheet size.  This also makes it a little easier to
debug on the Mentor side since you don't have to constantly change sheets
to see any signal you're trying to trace.  The specific variable for the
question asked is:

  compile_fix_multiple_port_nets = "true";

This forces Synopsys to add buffers on feedthroughs and outputs that are
logically identical, yet need to be considered differently.

  - [ Some Things Never Change ]


( ESNUG 222 Item 4 ) ---------------------------------------------- [7/95]

From: p_fiacco@emulex.com (Peter Fiacco)
Subject: BSDL File Creation

John, I've read ESNUG with great interest in the past, but have never
submitted a question.  So here goes....

Does anyone know of a 'good' way to generate a BSDL file to describe a design
that's been built using Synopsys Test Compiler / Design Compiler ?   Synopsys
is talking about a product (feature) that does this automatically that will
be introduced at some point in the future, but I'm looking for a more
immediate solution that doesn't require us to create the BSDL files manually.

  - Pete Fiacco
    Emulex


( ESNUG 222 Item 5 ) ---------------------------------------------- [7/95]

From: [ Nihongo-Man ]
Subject:  JK Flip-Flop Synthesizes Only With Bad Verilog

Hello John, Please keep this anonymous.

I've a question about synthesizing JK Flip-Flop with Design Compiler.  I
can't synthesize appropriate circuit with following Verilog description.

    module jkff(j, k, q, ck);
    input  j,k,ck;
    output q;
    reg    q;

    always @(posedge ck) begin
    case( {j, k} )
      2'b01:    q = 1'b0;   // Reset
      2'b10:    q = 1'b1;   // Set
      2'b11:    q =   ~q;   // Toggle
      2'b00:    q =    q;   // Hold
    endcase
    end
    endmodule

The result of this can't remove 'X' until Reset Condition.  But deleting Hold
Condition ( 2'b00: q = q ), the result seems good. (?)  I'd like to know what
difference of algorithm whether writing Hold Condition or not, in 'case'
statement.  I'm using synopsys ver3.0c

  - [ Nihongo Man ]


( ESNUG 222 Item 6 ) ---------------------------------------------- [7/95]

From: jtran@ATVL.Research.Panasonic.COM (Jimmy Tran)
Subject: How To Code Verilog & VHDL For Neg Edge Flip-Flops?

Hi John,

I have to raise some old questions again, and hope that you can help me to
put this issue to bed for good (I don't want to see it come back in any
future revision of DC Compiler!)

I have a design that mostly uses pos edge clock.  However, I also need to
have couple neg edge flip-flops.  V3.2b always gave me random circuitry.
Sometimes, I get an inverter on a clock line (which I don't want it),
sometimes I get a correct neg edge FF inferred (thank God !)

I went back to some of the ESNUG articles (ESNUG-151).  People recommended
attribute "neg_edge_flip_flop_opt".  However, I could not find any info
related to this attribute from Synopsys OnLine Doc V3.2b(?)  Could you help
me to clarify this issue ?  What's the best way to code for neg edge FF's?

  - Jim Tran
    Panasonic Advanced Television Video Laboratories, Inc.



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)