RE: (* synthesis, keep [=<optional_value>] *)

Subject: RE: (* synthesis, keep [=] *)
From: Muzaffer Kal (muzaffer@dspia.com)
Date: Thu Jan 31 2002 - 08:43:35 PST

My take is no. In my opinion the main reason one uses "keep" is
predictability. For some reason or another, one wants that double inverter,
that extra/unused DFF etc. remain in the design and not have the synthesizer
change it in any way. So I think keep means "don't touch" and this includes
replication. If it turns out that a net/reg I am keeping needs to be
replicated, I'd rather do it by hand because I am paying special attention
to it to start with and I'd like to know exactly what the result will be.

thanks,

Muzaffer
  -----Original Message-----
  From: owner-vlog-synth@server.eda.org
[mailto:owner-vlog-synth@server.eda.org]On Behalf Of Krishna Garlapati
  Sent: Wednesday, January 30, 2002 6:15 PM
  To: VhdlCohen@aol.com
  Cc: vlog-synth@server.eda.org
  Subject: Re: (* synthesis, keep [=<optional_value>] *)

  Hi Ben,

       I think keep on something, means keep it no matter what. This
  automatically means that the driver(s) of the kept object remain and so
on.

  For instances, it can be assumed that the "keep" makes the port
connections
  of the instance to be kept no matter what. This would in turn keep all the
drivers
  at the containing hierarchy and so on...

  My question is if a synthesis tool needs to replicate an object
  (for better timing, or to meet fanout constraints in the FPGA world)
  that has a keep on it, should it do it be allowed to replicate the
  object ??

  Thanks,
  - Krishna.

  VhdlCohen@aol.com wrote:

    Krishna,
    I am not clear as to what you mean.
    1. Wire: Is question "what if I have a 'keep' on a wire inside a level
of hierarchy, and that wire propagates all the way to the top level of the
design?
      I guess 'keep' should be maintained thru all the levels of the
hierarchy, up or down, from the level in which the 'keep' is declared.
      Good question! Perhaps you can enlighten us on this topic.

    2. Sequential element: If I have the following:
    reg [7:0] b, c, d (* synthesis, keep *);
    Then it would apply to reg a, b, and c for the 'keep'. Maybe I am not
answering the question. Wires connected to those sequential elements may be
blown away if no 'keep'. ?? Don't know! Good question!

    3. instantiated instances: Is the question : "what if I 'keep' instance
A, and ports of A connects to wires and ports at the top level. Then if
instance A is really not used, but 'keep' keeps it, then what to do about
all the wires that it connects to? If A did not have a 'keep', then A, and
all unused wires would have been blown away.
    My guess is that if A is 'keep', then signals connections to 'A' are
'keep' (i.e., inputs), but other instances connected to connections of A may
be blown away if there is no 'keep' attribute. Also, unused output wires
with no keep will be blown away if not used. Again, perhaps you can
enlighten us on this. Good question!

    Above are initial thoughts. We need to address this issue.
    Ben
    In a message dated 1/30/02 4:56:56 PM Pacific Standard Time,
krishna@synplicity.com writes:

        Having a universal "keep" is a neat idea. But what about
replication ??
      Does "keep" on an object means that it cannot be replicated as well ??

      Thanks, - Krishna.

      VhdlCohen@aol.com wrote:

        There are several objects that a user may wish to "keep" during
synthesis.
        1. Wire: This assures that (1) a wire will be kept during synthesis
and (2)
        that no optimizations will cross the wire. This is for nets and
combinational logic. Example:
        wire [7:0] out_a (* synthesis, keep *);

        2. sequential element: This assures that no optimizations cross a
sequential element. It
        is usually used break unwanted optimizations which go through
sequential
        elements. Example:
        reg [7:0] b (* synthesis, keep *);

        3. instantiated instances: This is used to assure that instantiated
instances are not optimized away. This will prevent the optimizations from
removing an unconnected instance.
        my_design my_design1 (out1, in1, clk_in)(* synthesis, keep= 1*); //
keep
        my_design my_design2 (out, in, clk_in)(* synthesis, keep= 0*); //
may optimize out

        After thinking about it, I think that we could just restrain this
attribute to just one.
        SOme vendors provide different attribute names for each class of
object.
        We'll discuss this at out meeting, but comments are always welcomed.

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

----
    Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830
    http://www.vhdlcohen.com/                  vhdlcohen@aol.com
    Author of following textbooks:
    * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
    * Component Design by Example ",  2001 isbn  0-9705394-0-1
    * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
0-7923-8474-1
    * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
0-7923-8115
    ------------------------------------------------------------------------
------

--
- Krishna.
Synplicity Inc.
(408)215-6152

This archive was generated by hypermail 2b28 : Thu Jan 31 2002 - 08:39:29 PST