WebPACK post-PAR min clock period?

I'm using WebPACK 6.3.01i.  The synthesis report tells me the
minimum clock period is about 17 ns.

How do I get the same kind of static timing info after place and route?
The P&R report shows max clock delay, net skew, pin delay, etc., but
I don't see min period or max frequency.  The async delay report says
that the max delay is about 6.6 ns; am I supposed to infer a minimum
clock period from that?

Thanks,
Eric

Eric,
You must constrain your design before the P&R tools try to meet timing. In 
the Xilinx tools I add a line like:-
NET "CLOCK" PERIOD = 10ns;
or something like that. Read the Xilinx constraints guide.
Cheers, Syms.
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message 
news:qhlle8euqq.fsf@ruckus.brouhaha.com...
> I'm using WebPACK 6.3.01i.  The synthesis report tells me the
> minimum clock period is about 17 ns.
>
> How do I get the same kind of static timing info after place and route?
> The P&R report shows max clock delay, net skew, pin delay, etc., but
> I don't see min period or max frequency.  The async delay report says
> that the max delay is about 6.6 ns; am I supposed to infer a minimum
> clock period from that?
>
> Thanks,
> Eric 

I wrote:
> I'm using WebPACK 6.3.01i.  The synthesis report tells me the minimum
> clock period is about 17 ns.  [...] How do I get the same kind of
> static timing info after place and route?

"Symon" <symon_brewer@hotmail.com> writes:
> You must constrain your design before the P&R tools try to meet timing. In 
> the Xilinx tools I add a line like:-
> NET "CLOCK" PERIOD = 10ns;
> or something like that. Read the Xilinx constraints guide.

Thanks, I'll give that a try.  It seems somewhat surprising that they
don't report the clock period without an explicit constraint; Cypress
WARP does.

Eric Smith wrote:
> 
> I wrote:
> > I'm using WebPACK 6.3.01i.  The synthesis report tells me the minimum
> > clock period is about 17 ns.  [...] How do I get the same kind of
> > static timing info after place and route?
> 
> "Symon" <symon_brewer@hotmail.com> writes:
> > You must constrain your design before the P&R tools try to meet timing. In
> > the Xilinx tools I add a line like:-
> > NET "CLOCK" PERIOD = 10ns;
> > or something like that. Read the Xilinx constraints guide.
> 
> Thanks, I'll give that a try.  It seems somewhat surprising that they
> don't report the clock period without an explicit constraint; Cypress
> WARP does.

I am not aware that they *don't* report a max clock speed, but it is
very unusual to care about clock speed if you don't spec a requirement. 
If you don't use a speed constraint, the tool assumes you don't care
about the speed and just does a route without any optimization.  Isn't
that obvious? 

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Dear Eric,

You can get the clock period in Timing Analyzer by selecting "Against Auto
Generated Design Constraints..." whatever you have added the PERIOD
constraints or not,  even if that is recomanded.



"Eric Smith" <eric-no-spam-for-me@brouhaha.com> ????
news:qhoej4jzix.fsf@ruckus.brouhaha.com...
> I wrote:
> > I'm using WebPACK 6.3.01i.  The synthesis report tells me the minimum
> > clock period is about 17 ns.  [...] How do I get the same kind of
> > static timing info after place and route?
>
> "Symon" <symon_brewer@hotmail.com> writes:
> > You must constrain your design before the P&R tools try to meet timing.
In
> > the Xilinx tools I add a line like:-
> > NET "CLOCK" PERIOD = 10ns;
> > or something like that. Read the Xilinx constraints guide.
>
> Thanks, I'll give that a try.  It seems somewhat surprising that they
> don't report the clock period without an explicit constraint; Cypress
> WARP does.

rickman <spamgoeshere4@yahoo.com> writes:
> I am not aware that they *don't* report a max clock speed, but it is
> very unusual to care about clock speed if you don't spec a requirement. 
> If you don't use a speed constraint, the tool assumes you don't care
> about the speed and just does a route without any optimization.  Isn't
> that obvious? 

No, it's not obvious.  You could just as easily say that an automaker
shouldn't include a speedometer in a new car unless you tell the dealer
how fast you plan to drive.

If I give an explicit constraint, I want the tools to work harder (if
necessary) to try to meet it, but that doesn't mean that if I don't give
a constraint that I don't care about it at all.  By that reasoning it
would be fine for the tools to produce a design with a minimum clock
period of a fortnight.

Eric Smith wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> > I am not aware that they *don't* report a max clock speed, but it is
> > very unusual to care about clock speed if you don't spec a requirement.
> > If you don't use a speed constraint, the tool assumes you don't care
> > about the speed and just does a route without any optimization.  Isn't
> > that obvious?
> 
> No, it's not obvious.  You could just as easily say that an automaker
> shouldn't include a speedometer in a new car unless you tell the dealer
> how fast you plan to drive.
> 
> If I give an explicit constraint, I want the tools to work harder (if
> necessary) to try to meet it, but that doesn't mean that if I don't give
> a constraint that I don't care about it at all.  By that reasoning it
> would be fine for the tools to produce a design with a minimum clock
> period of a fortnight.

I don't understand your point.  If you don't tell the tool what an
acceptable clock period is, then how is the tool supposed to know the
difference between a nanosecond and a fortnight?  Tools are not people,
they can't reason.  Besides, how would *I* know what you find an
acceptable clock period if you don't tell me?  I still see systems that
are clocked well below 10 MHz.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

>I don't understand your point.  If you don't tell the tool what an
>acceptable clock period is, then how is the tool supposed to know the
>difference between a nanosecond and a fortnight?  Tools are not people,
>they can't reason.  Besides, how would *I* know what you find an
>acceptable clock period if you don't tell me?  I still see systems that
>are clocked well below 10 MHz.  

The tools could at least tell me what the worst case clock-clock
time is for each clock.  That's not rocket science.  And maybe
even give a warning for not specifying the appropriate constraints.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> 
> >I don't understand your point.  If you don't tell the tool what an
> >acceptable clock period is, then how is the tool supposed to know the
> >difference between a nanosecond and a fortnight?  Tools are not people,
> >they can't reason.  Besides, how would *I* know what you find an
> >acceptable clock period if you don't tell me?  I still see systems that
> >are clocked well below 10 MHz.
> 
> The tools could at least tell me what the worst case clock-clock
> time is for each clock.  That's not rocket science.  And maybe
> even give a warning for not specifying the appropriate constraints.

Who said the tool does not give you the results?  I belive at least one
post here said that info *was* available.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

rickman <spamgoeshere4@yahoo.com> writes:
> I don't understand your point.  If you don't tell the tool what an
> acceptable clock period is, then how is the tool supposed to know the
> difference between a nanosecond and a fortnight?  Tools are not people,
> they can't reason.

I don't expect it to reason.  I just expect it to tell me the result.

> Besides, how would *I* know what you find an
> acceptable clock period if you don't tell me?  I still see systems that
> are clocked well below 10 MHz.  

I never said that 10 MHz was an unacceptable outcome.  That has nothing
to do with whether the tool should provide me with the result of a
static timing analysis.