Subject: Re: (* synthesis, keep [=
Hi Ben,
I think keep on something, means keep it no matter what. This
For instances, it can be assumed that the "keep" makes the port connections
My question is if a synthesis tool needs to replicate an object
Thanks,
VhdlCohen@aol.com wrote:
> Krishna,
This archive was generated by hypermail 2b28
: Wed Jan 30 2002 - 18:26:11 PST
From: Krishna Garlapati (krishna@synplicity.com)
Date: Wed Jan 30 2002 - 18:15:25 PST
automatically means that the driver(s) of the kept object remain and so on.
of the instance to be kept no matter what. This would in turn keep all
the drivers
at the containing hierarchy and so on...
(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 ??
- 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 <mailto: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/ <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