Re: How many dedicated clock pins EP20K1500EBC652 device?

[EMAIL PROTECTED] (enq_semi) wrote in message news:<[EMAIL PROTECTED]>...
> Hi, Vaughn,
> 
> > 
> > Their skew should be much better than that.  Try the experiment above
> > to make sure you are really using the Fast networks.
> > 
> 
> I made sure it should use the Fast networks:
> 
> 1. In assignment manager I have the following settings:
>    -- aclk_in  => Clock Settings = my_clk @ 56MHz
>    -- aclk_in  => Global Signal = Global Clock
>    -- aclk_in  => Auto Global Clock = On

Should really use 
aclk_in => Global Signal = On 

for APEX.

Global clock etc. are really for Stratix where there are multiple
types of globals; from the message below, it looks like they do not
get interpreted as "Global signal = on" for APEX.

> 2. During compile, I saw this message:
>    --Info: Promoted cell aclk_in to global signal automatically

Yup, looks like Quartus automatically promoted it to use global
routing.  If it had recognized your global signal assignment, this
should have been done by your constraints though, and wouldn't require
the automatic global processing.  Just FYI; the end effect is fine.

> I doubted that the timing parameters used by Quartus might not be
> accurate, however, I verified two skews on oscilloscope against the
> timing report by Quartus, the difference is very small (around 0.2 ns
> or so).
> 
> I also tried non-clock and non-fast I/O pin, the skew is much larger.
> So, maybe the 1ns skew with fast I/O pin is considered "useable as
> clock"? (I certainly NOT hope so.)

Hmmm ... I guess the 1 ns skew is correct then.  The Fast networks in
APEX do have higher skew than the dedicated clock networks, so they do
hurt performance a bit.  They still certainly do work as clocks with
no hold violations, since many designs use them that way -- the 1 ns
skew must be between cells that are separated by enough distance that
they have to use enough routing that the data delay is comfortably
above the clock skew.

Vaughn