Editor's Note: If you're a new ESNUG member and you want past ESNUG posts,
  send me a concise e-mail saying: "Waaaa!  I want past ESNUG posts!" and
  I'll reply with the canned instructions how to get them.  - John Cooley

( ESNUG 175 Item 1 ) ---------------------------------------------- [2/3/93]

Subject: (ESNUG 174 #6) "How To Infer R/S flip-flops In Synopsys"

> I would like to know if any Synopsys users had been able to infer R/S
> flip-flop in Synopsys using Verilog or VHDL RTL code.  (Prefer Verilog)
> Please post the solution on ESNUG.  Thanks...

                    ---   ---   ---   ---

From: rm@hoy.nsc.com (Robert Marshall)

Simple question; what follows is the simple answer.  But be warned it gets
more complicated if you pursue it!

Verilog RTL input:

  module rsff(q, d, s, r, ck);
   output q;
   input d,s,r,ck;
   reg q;
   always @(posedge ck or negedge s or negedge r)
     if (!r) q = 1'b0;
     else if (!s) q = 1'b1;
     else q = d;
  endmodule

Verilog output from Synopsys version 3.0b-12954:

  module rsff ( q, d, s, r, ck );
  input  d, s, r, ck;
  output q;
    DFFB q_reg ( .Q(q), .CLK(ck), .CLRZ(r), .D(d), .PREZ(s) );
  endmodule

Less simply, if you swap the "set" and "reset" clauses, you will find
synosys generating extra logic to take care of the case where both set
and reset are on together (the conditions for adding the extra logic are
dependant on the f/f model in the library you are using - ours has a f/f
cell which gives reset a higher priority than set).   Very soon you can
end up with logic with built-in trailing edge glitchers on the cell
set/reset pins which will thwart the intended operation of your circuit;
so use the above constructs with great care.
 
  - Robert Marshall & Phil Derrick
    National Semiconductor, Greenock UK. 

                    ---   ---   ---   ---

From: alpo@atitech.ca (Al Porter)

John, the following is a VHDL example which will infer a RS latch (at
least in the SGS Thomson library).  It is important to note the commented
lines which indicate how to compile this block (LSR1 was the RS latch to
be inferred).  This is the only combination which we currently know that
works.  This block was originally coded for V2.2 but has been rerun on
V3.0b.  Since the compile strategy seems critical to successful inferal,
these latches would have to be coded as a level of hierarchy and compiled
separately (at least for first pass).  If a dont_touch is added to the
library component inferred (the RS latch cell), this extra hierarchical
level could then be removed.

  library ieee;
  use ieee.std_logic_1164.all;
  use ieee.std_logic_arith.all;

  -- for sgs library
  -- set_register_type -latch LSR1 -exact LSR1
  -- set_structure false
  -- set_flatten true
  -- compile

  entity rslatch2 is
  port (
     R, S : in std_ulogic;
     Q : out std_ulogic
     );
  end rslatch2;

  architecture behaviour of rslatch2 is
  begin
   x_reg : process (R, S)
   variable en : std_ulogic_vector(1 downto 0);
   begin
    en := (R,S);
    if ((not R or not S) = '1') then
     case en is
      when "01" => Q <= '0';
      when "10" => Q <= '1';
      when others => Q <= 'X';
     end case;
    end if;
   end process;
  end;

A by-product of the way the block is coded is some extra logic to
prioritize set over reset.  This may be possible to correct by recoding
the block somewhat.  I hope this helps.

  - Al Porter
    Atitech


( ESNUG 175 Item 2 ) ---------------------------------------------- [2/3/93]

Subject: ( ESNUG 174 #7) Latch Timing Issues And Forced Into Buying DC-Expert

>We are seeing a problem with latch timing and dc-professional.
> 
>Synopsys is timing our latches, and reporting setup violations to the
>falling edge of the clock.  (Yet the Toshiba databook clearly specs setup
>for an LD2 to the rising edge.)  To make matters worse if we happen to run
>on a machine with a dc-expert license, the compile invokes "time borrowing"
>and masks the problem!  We feel that timing setup to the wrong clock edge
>is clearly a bug and users should not have to spend more money for a
>dc-expert license that we do not need.  Does anyone have a money saving
>workaround so we're not...  - [ Being Forced Into Buying DC-Expert ]
> 
> [ Editor's Note: Reading this letter I'm not sure if there is a problem with 
> not having DC-Expert as much as an error in the Toshiba Synopsys libraries.
> I don't know this for a fact -- just a gut hunch because one accidental 
> switch of "rising edge" to "falling edge" in the lib would do this.  If you
> can access the Toshiba ".lib" source, you should look into this.  - John ]

                    ---   ---   ---   ---

From: [ Being Forced Into Buying DC-Expert? ]

John, we did initially suspect the Toshiba Synopsys libraries but it turns out
that they're fine.  After all was said and done, the Synopsys hotline has
confirmed that this is a bonafide bug with DC Professional that doesn't show
up in DC Expert.  They claim it'll will be fixed in version 3.1.  They also
said the only way to do proper latch timing until then in version 3.0 is to
use DC Expert.

  - [ Being Forced Into Buying DC-Expert? ]

                    ---   ---   ---   ---

From: martint@sei.com (Martin Taylor)

John, I agree with you that the first step in the diagnosis is to ask
Toshiba if they have mistakenly put a modeling error in their library.

But at least one cheap fix can help; it's something like the following:

 set_false_path -setup -rise -to find(lib_pin, *LIB/PIN_NAME*, -hierarchy)

Where LIB is the library cell name.  This command would turn off the setup
time checking for the rising edge at a particular library pin.

  - Martin Taylor
    Silicon Engineering Inc.


( ESNUG 175 Item 3 ) ---------------------------------------------- [2/3/93]

Subject: (ESNUG 173 #5 174 #2) - "Xilinx synthesis with Synopsys"

>We spent a couple of weeks recently taking a design that had been compiled
>with Design Compiler and recompiling (from the source) with FPGA compiler.
>What we got after a lot of pain was an even larger, slower design!
>
>Design Compiler is useful, as long as you can live with it's limitations.
>In my opinion, I do not believe FPGA compiler is a working product yet.
>
>  - David Burleson
>    Scientific Atlanta

From: jwk@melardc.net.netcom.com (John Kesterson)

John, we also constantly use Synopsys to synthesize Verilog to Xilinx FPGA's.
Our use of Xilinx is primarily as a prototyping mechanism for ASIC designs.
Our experience with FPGA compiler has been much different than Mr. Burleson's.

We started out 2 years ago using Valid tools (which are now Cadence tools) to
schematically enter designs using a Xilinx design kit library which worked
with the Concept schematic editor.  Two years ago, there were not very good
retargeting solutions available.  We desired to write some form of HDL which
would originally target FPGA's and would later synthesize to ASIC's.  

Last year we migrated to Verilog not only as a language but as a simulator
as well.  This has proven very successful for us.  We have found the
Synopsys FPGA compiler to be the answer to our retargetability needs.  We
have several designs which utilize 90% of an XC4010.  These same designs
were approximately the same size when done through the schematic entry
method with a Xilinx library.  They are now synthesized from Verilog code.

We have noticed in some cases the route of a design is more difficult.
This is due to the extensive use of hard macro's by FPGA compiler especially
if the synthetic XBLOX library is used.  When XBLOX is used, just about
everything in the design is a hard macro.  Since routing cannot transcend
the boundaries of hard macro's, many existing routing resources are not
available.  When I brought this up with Synopsys, they indicated to me that
this is due to the fact that the hard macro's are more efficient in area
as well as timing.  However, I do not believe that they are considering
the impact on routing of their over use.  I have gotten around the problem
in most cases by using the synthetic libraries that came with Synopsys
for Xilinx and disabling the XBLOX synthetic libraries.  

I have done some 20 and 40 MHz designs as well as some DSP designs which
include many arithmetic functions and found FPGA compiler to perform well.
I believe FPGA compiler to be a more mature product than what Mr. Burleson
found it to be.  However I will add, there are some subtle things which 
after learned (such as the use of synthetic libraries) which do enhance
its operation.  I was fortunate to have an excellent AE when we first
took the plunge.  We are happy with our choice in the use of FPGA compiler.

In the original posting, the question was raised as to what other tools are
necessary to fully simulate the design and generate the bit stream.  As Mr.
Burleson pointed out, the Synopsys tools DO NOT remove the need for the 
Xilinx router and bit stream generators, i.e. APR/PPR, makebits, and/or
makeprom.  As mentioned before, we use the Cadence simulator Verilog.  We have
a Cadence product called "timenet" & "timesim" which converts a Xilinx XNF
file to a Verilog netlist with an appropriate timing backannotation (SDF)
file.  This has worked out to be a pretty clean solution but it does
require some editing of the Verilog stimulus environment file since Xilinx
capitolized the names of all signals and it breaks out all busses.  This is
a nuisance, but it is relatively easy to overcome.

  - John Kesterson
    Mitsubishi R&D Center


( ESNUG 175 Item 4 ) ---------------------------------------------- [2/3/93]

From: ajt@iit.com (Andrew Tao)
Subject: Want More "Don't Care" Options In Behavioral Synthesis

John, I'm compiling behavioral verilog through Synopsys and would like to
specify the output of a case statement as "don't care".  (Synopsys doesn't
seem to recognize the 1'hx or any other form of don't care.)  When I run the
same logic through Synopsys in a PLA format it works fine, but I'd like
to be able to do it in verilog.  Here's an example of what I'd like to do:

   reg [3:0] a;     reg out;

   case (a) // full_case parallel_case
           4'h5, 4'hc :  out = 1'h1;
     4'h8, 4'h9, 4'hd :  out = 1'hx;  // specified don't care conditions
              default :  out = 1'h0;
   endcase

I can't seem to get this funtionality from Synopsys synthesis.

  - Andrew Tao
    IIT


( ESNUG 175 Item 5 ) ---------------------------------------------- [2/3/93]

From: cadieux@brooktree.com (kevin cadieux)
Subject: How About Infering M/S FF's Along With Test Compiler?

I have a design in whichI want to infer a Master/Slave flip flop that has
two clock input pins "clk" and "clkn."  Is this possible using Verilog and
Synopsys?  In addition will Synopsys Test Compiler support such an inference?

  - Kevin Cadieux
    Brooktree


( ESNUG 175 Item 6 ) ---------------------------------------------- [2/3/93]

From: paolini@sisun9.CSELT.STET.IT (Maurizio Paolini)
Subject: Synopsys 3.0c Doesn't Like Making Clocking Networks Anymore

Hello, John.  I am having problems with the balance_buffer command.  I have
a design in which different clock nets have to be buffered.  After having
set the driving cells for each clock,  I issue the commands:

	balance_buffer -from { CLK1 }
	balance_buffer -from { CLK2 }
	...
	balance_buffer -from { CLKn }

The Design Compiler processes the circuit for a very short while, displays
the message "Building balanced buffer tree(s) in Design 'my_design'" and
then transfers the whole design hierarchy to the internal database.  But
when I inspect the design, I notice that nothing has changed! - massive
fanout violations everywhere and no buffers at all were inserted!

I set a max_fanout constraint first on the CLKn ports, then on the whole
design.  Nothing changed.  I am using the same library and command script
that worked under Synopsys 3.0b - so, this should not be a library or
script problem.

Did anybody else see this problem under 3.0c?  Does anybody have a solution
for this?

  - Maurizio Paolini
    CSELT - Centro Studi E Laboratori Telecomunicazioni



 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)