Output signals not synchronized

I have 23bit wide RAM that I use as ROM inferred from the code. When I
use the logic analyser (Agilent 16903A) with the finest resolution of
2.5ns I see that signals on the output header are not read
synchronously - some of them are 2.5 or 5ns delayed and that is a
problem.
I have used this line in constraints UCF file

NET ctrl_data<*> TNM=ctrl_data_group;
TIMEGRP "ctrl_data_group" OFFSET = OUT 100 ps AFTER "SYSCLK_100MHZ"
HIGH ;

but this did not help. This SYSCLK_100MHZ clock is divided by 16 in
order to read the ctrl_data that is 23bit wide memory.

Any suggestions?

Thanks,
Dan

there are also UCF lines:

NET ctrl_data<*> SLEW = FAST;
NET ctrl_data<*> DRIVE = 2;
NET ctrl_data<*> IOSTANDARD = LVCMOS33;

"EEngineer" <maricic@gmail.com> wrote in message 
news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
> there are also UCF lines:
>
> NET ctrl_data<*> SLEW = FAST;
> NET ctrl_data<*> DRIVE = 2;
> NET ctrl_data<*> IOSTANDARD = LVCMOS33;

To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not 
something that will make your outputs happen coincident with your clock, 
it's a specification that will simply fail in the place & route and timing 
analyzer.  Take a look.  The fastest your outputs will go depend on how fast 
an IOB register can deliver its output relative to your global clock.  These 
numbers are documented and easy to prototype.

Second, the 2 mA drive level will give you a slower rise/fall.  The skew in 
your output signal time can - depending on your load - be a noticeable time 
difference.

Third, the logic analyzer is an asynchronous device which will usually 
provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns 
difference not explained by the test equipment.

Please find the online documentation (or a Xilinx class) that describes what 
you can and cannot do with constraints.  This fundamental information 
usually is only understood after an engineer can't understand why their 
design isn't working.  Learn it. 

On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> "EEngineer" <mari...@gmail.com> wrote in message
>
> news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > there are also UCF lines:
>
> > NET ctrl_data<*> SLEW = FAST;
> > NET ctrl_data<*> DRIVE = 2;
> > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> something that will make your outputs happen coincident with your clock,
> it's a specification that will simply fail in the place & route and timing
> analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> an IOB register can deliver its output relative to your global clock.  These
> numbers are documented and easy to prototype.
>
> Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> your output signal time can - depending on your load - be a noticeable time
> difference.
>
> Third, the logic analyzer is an asynchronous device which will usually
> provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> difference not explained by the test equipment.
>
> Please find the online documentation (or a Xilinx class) that describes what
> you can and cannot do with constraints.  This fundamental information
> usually is only understood after an engineer can't understand why their
> design isn't working.  Learn it.

If you need your outputs to have very low skew, your only hope
is to place all of the output flip-flops in the IOB's (IOB=TRUE
attribute on the flip-flop or net).  You can also globally place
registers in IOB's using the synthesis and map properties.  If
your outputs are generated by fabric flip-flops it is very hard
to get your skew below 2.5 nS

By the way, why do you need such low skew on these lines?  Is the
driven device asynchronous with respect to your clock?

Regards,
Gabor

On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
> On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
>
>
> > "EEngineer" <mari...@gmail.com> wrote in message
>
> >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > there are also UCF lines:
>
> > > NET ctrl_data<*> SLEW = FAST;
> > > NET ctrl_data<*> DRIVE = 2;
> > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > something that will make your outputs happen coincident with your clock,
> > it's a specification that will simply fail in the place & route and timing
> > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > an IOB register can deliver its output relative to your global clock.  These
> > numbers are documented and easy to prototype.
>
> > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > your output signal time can - depending on your load - be a noticeable time
> > difference.
>
> > Third, the logic analyzer is an asynchronous device which will usually
> > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > difference not explained by the test equipment.
>
> > Please find the online documentation (or a Xilinx class) that describes what
> > you can and cannot do with constraints.  This fundamental information
> > usually is only understood after an engineer can't understand why their
> > design isn't working.  Learn it.
>
> If you need your outputs to have very low skew, your only hope
> is to place all of the output flip-flops in the IOB's (IOB=TRUE
> attribute on the flip-flop or net).  You can also globally place
> registers in IOB's using the synthesis and map properties.  If
> your outputs are generated by fabric flip-flops it is very hard
> to get your skew below 2.5 nS
>
> By the way, why do you need such low skew on these lines?  Is the
> driven device asynchronous with respect to your clock?
>
> Regards,
> Gabor

I need those signals to control the analog CMOS circuit that has a
requirement for some signals not to overlap - this happens when the
output from the FPGA is not synchronous enough.

On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
> On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
>
>
> > "EEngineer" <mari...@gmail.com> wrote in message
>
> >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > there are also UCF lines:
>
> > > NET ctrl_data<*> SLEW = FAST;
> > > NET ctrl_data<*> DRIVE = 2;
> > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > something that will make your outputs happen coincident with your clock,
> > it's a specification that will simply fail in the place & route and timing
> > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > an IOB register can deliver its output relative to your global clock.  These
> > numbers are documented and easy to prototype.
>
> > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > your output signal time can - depending on your load - be a noticeable time
> > difference.
>
> > Third, the logic analyzer is an asynchronous device which will usually
> > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > difference not explained by the test equipment.
>
> > Please find the online documentation (or a Xilinx class) that describes what
> > you can and cannot do with constraints.  This fundamental information
> > usually is only understood after an engineer can't understand why their
> > design isn't working.  Learn it.
>
> If you need your outputs to have very low skew, your only hope
> is to place all of the output flip-flops in the IOB's (IOB=TRUE
> attribute on the flip-flop or net).  You can also globally place
> registers in IOB's using the synthesis and map properties.  If
> your outputs are generated by fabric flip-flops it is very hard
> to get your skew below 2.5 nS
>
> By the way, why do you need such low skew on these lines?  Is the
> driven device asynchronous with respect to your clock?
>
> Regards,
> Gabor

I need those signals to control the analog CMOS circuit that has a
requirement for some signals not to overlap - this happens when the
output from the FPGA is not synchronous enough.

On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote:
> On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > > "EEngineer" <mari...@gmail.com> wrote in message
>
> > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > > there are also UCF lines:
>
> > > > NET ctrl_data<*> SLEW = FAST;
> > > > NET ctrl_data<*> DRIVE = 2;
> > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > > something that will make your outputs happen coincident with your clock,
> > > it's a specification that will simply fail in the place & route and timing
> > > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > > an IOB register can deliver its output relative to your global clock.  These
> > > numbers are documented and easy to prototype.
>
> > > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > > your output signal time can - depending on your load - be a noticeable time
> > > difference.
>
> > > Third, the logic analyzer is an asynchronous device which will usually
> > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > > difference not explained by the test equipment.
>
> > > Please find the online documentation (or a Xilinx class) that describes what
> > > you can and cannot do with constraints.  This fundamental information
> > > usually is only understood after an engineer can't understand why their
> > > design isn't working.  Learn it.
>
> > If you need your outputs to have very low skew, your only hope
> > is to place all of the output flip-flops in the IOB's (IOB=TRUE
> > attribute on the flip-flop or net).  You can also globally place
> > registers in IOB's using the synthesis and map properties.  If
> > your outputs are generated by fabric flip-flops it is very hard
> > to get your skew below 2.5 nS
>
> > By the way, why do you need such low skew on these lines?  Is the
> > driven device asynchronous with respect to your clock?
>
> > Regards,
> > Gabor
>
> I need those signals to control the analog CMOS circuit that has a
> requirement for some signals not to overlap - this happens when the
> output from the FPGA is not synchronous enough.


These signals will never be "synchronous enough" to guarantee zero
overlap when changing on the same clock cycle.  Use a faster clock
if you need to, but certainly add a clock cycle between assertion
of signals that must not overlap.

On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote:
> On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote:
>
>
>
> > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
>
> > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > > > "EEngineer" <mari...@gmail.com> wrote in message
>
> > > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > > > there are also UCF lines:
>
> > > > > NET ctrl_data<*> SLEW = FAST;
> > > > > NET ctrl_data<*> DRIVE = 2;
> > > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > > > something that will make your outputs happen coincident with your clock,
> > > > it's a specification that will simply fail in the place & route and timing
> > > > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > > > an IOB register can deliver its output relative to your global clock.  These
> > > > numbers are documented and easy to prototype.
>
> > > > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > > > your output signal time can - depending on your load - be a noticeable time
> > > > difference.
>
> > > > Third, the logic analyzer is an asynchronous device which will usually
> > > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > > > difference not explained by the test equipment.
>
> > > > Please find the online documentation (or a Xilinx class) that describes what
> > > > you can and cannot do with constraints.  This fundamental information
> > > > usually is only understood after an engineer can't understand why their
> > > > design isn't working.  Learn it.
>
> > > If you need your outputs to have very low skew, your only hope
> > > is to place all of the output flip-flops in the IOB's (IOB=TRUE
> > > attribute on the flip-flop or net).  You can also globally place
> > > registers in IOB's using the synthesis and map properties.  If
> > > your outputs are generated by fabric flip-flops it is very hard
> > > to get your skew below 2.5 nS
>
> > > By the way, why do you need such low skew on these lines?  Is the
> > > driven device asynchronous with respect to your clock?
>
> > > Regards,
> > > Gabor
>
> > I need those signals to control the analog CMOS circuit that has a
> > requirement for some signals not to overlap - this happens when the
> > output from the FPGA is not synchronous enough.
>
> These signals will never be "synchronous enough" to guarantee zero
> overlap when changing on the same clock cycle.  Use a faster clock
> if you need to, but certainly add a clock cycle between assertion
> of signals that must not overlap.

Yes, I was thinking of using 16 times faster clock to add one clock
cycle in between, but I have checked signals with the 500MHz scope
(10Mohm, 9.5pF probes) and it looks like that digital analyser is
giving misleading waveforms - there is almost no delay between these
two signals (less then 1ns). The rise time is same for both signals,
and this can be improved by increasing the drive in UCF file from the
minimum 2mA, I don't know the load yet.

On Aug 30, 10:35 am, EEngineer <mari...@gmail.com> wrote:
> On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote:
>
> > > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
>
> > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > > > > "EEngineer" <mari...@gmail.com> wrote in message
>
> > > > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > > > > there are also UCF lines:
>
> > > > > > NET ctrl_data<*> SLEW = FAST;
> > > > > > NET ctrl_data<*> DRIVE = 2;
> > > > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > > > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > > > > something that will make your outputs happen coincident with your clock,
> > > > > it's a specification that will simply fail in the place & route and timing
> > > > > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > > > > an IOB register can deliver its output relative to your global clock.  These
> > > > > numbers are documented and easy to prototype.
>
> > > > > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > > > > your output signal time can - depending on your load - be a noticeable time
> > > > > difference.
>
> > > > > Third, the logic analyzer is an asynchronous device which will usually
> > > > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > > > > difference not explained by the test equipment.
>
> > > > > Please find the online documentation (or a Xilinx class) that describes what
> > > > > you can and cannot do with constraints.  This fundamental information
> > > > > usually is only understood after an engineer can't understand why their
> > > > > design isn't working.  Learn it.
>
> > > > If you need your outputs to have very low skew, your only hope
> > > > is to place all of the output flip-flops in the IOB's (IOB=TRUE
> > > > attribute on the flip-flop or net).  You can also globally place
> > > > registers in IOB's using the synthesis and map properties.  If
> > > > your outputs are generated by fabric flip-flops it is very hard
> > > > to get your skew below 2.5 nS
>
> > > > By the way, why do you need such low skew on these lines?  Is the
> > > > driven device asynchronous with respect to your clock?
>
> > > > Regards,
> > > > Gabor
>
> > > I need those signals to control the analog CMOS circuit that has a
> > > requirement for some signals not to overlap - this happens when the
> > > output from the FPGA is not synchronous enough.
>
> > These signals will never be "synchronous enough" to guarantee zero
> > overlap when changing on the same clock cycle.  Use a faster clock
> > if you need to, but certainly add a clock cycle between assertion
> > of signals that must not overlap.
>
> Yes, I was thinking of using 16 times faster clock to add one clock
> cycle in between, but I have checked signals with the 500MHz scope
> (10Mohm, 9.5pF probes) and it looks like that digital analyser is
> giving misleading waveforms - there is almost no delay between these
> two signals (less then 1ns). The rise time is same for both signals,
> and this can be improved by increasing the drive in UCF file from the
> minimum 2mA, I don't know the load yet.

You might want to learn how a logic analyzer works.  It sounds like
your analyzer has a 400 MHz sample clock because of your noted 2.5 ns
uncertainty.  This sample clock is of course asynchronous to your
circuit.  So even if your FPGA's outputs are skewed less than 1 ns (as
you point out), that window might include the logic analyzer's sample
point, and as such signals that are in reality only 500 ps apart
appear on the analyzer to be 2.5 ns apart.

So you should ensure that all of your signals are registered by a low-
skew clock in the IOBs and ensure that your PCB routing has equal
length lines from the FPGA to the load.  This should result in quite
good skew matching.  Also make sure the output s set to FAST, and
increase the drive strength.  Read your timing analyzer's report for I/
O clock-to-out times.

And if the requirement is to ensure that two outputs are never enabled
simultaneously, then do as Gabor says and insert a one-clock dead time
between the deassertion of one output and the assertion of the other.

-a

On Aug 30, 3:22 pm, Andy Peters <goo...@latke.net> wrote:
> On Aug 30, 10:35 am, EEngineer <mari...@gmail.com> wrote:
>
>
>
>
>
> > On Aug 30, 11:12 am, Gabor <ga...@alacron.com> wrote:
>
> > > On Aug 30, 10:14 am, EEngineer <mari...@gmail.com> wrote:
>
> > > > On Aug 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
>
> > > > > On Aug 29, 7:40 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
>
> > > > > > "EEngineer" <mari...@gmail.com> wrote in message
>
> > > > > >news:1188426999.764557.233750@k79g2000hse.googlegroups.com...
>
> > > > > > > there are also UCF lines:
>
> > > > > > > NET ctrl_data<*> SLEW = FAST;
> > > > > > > NET ctrl_data<*> DRIVE = 2;
> > > > > > > NET ctrl_data<*> IOSTANDARD = LVCMOS33;
>
> > > > > > To start with, your timing constraint of OFFSET = OUT 100 ps AFTER is not
> > > > > > something that will make your outputs happen coincident with your clock,
> > > > > > it's a specification that will simply fail in the place & route and timing
> > > > > > analyzer.  Take a look.  The fastest your outputs will go depend on how fast
> > > > > > an IOB register can deliver its output relative to your global clock.  These
> > > > > > numbers are documented and easy to prototype.
>
> > > > > > Second, the 2 mA drive level will give you a slower rise/fall.  The skew in
> > > > > > your output signal time can - depending on your load - be a noticeable time
> > > > > > difference.
>
> > > > > > Third, the logic analyzer is an asynchronous device which will usually
> > > > > > provide a 2.5 ns uncertainty in your results leaving only a 2.5 ns
> > > > > > difference not explained by the test equipment.
>
> > > > > > Please find the online documentation (or a Xilinx class) that describes what
> > > > > > you can and cannot do with constraints.  This fundamental information
> > > > > > usually is only understood after an engineer can't understand why their
> > > > > > design isn't working.  Learn it.
>
> > > > > If you need your outputs to have very low skew, your only hope
> > > > > is to place all of the output flip-flops in the IOB's (IOB=TRUE
> > > > > attribute on the flip-flop or net).  You can also globally place
> > > > > registers in IOB's using the synthesis and map properties.  If
> > > > > your outputs are generated by fabric flip-flops it is very hard
> > > > > to get your skew below 2.5 nS
>
> > > > > By the way, why do you need such low skew on these lines?  Is the
> > > > > driven device asynchronous with respect to your clock?
>
> > > > > Regards,
> > > > > Gabor
>
> > > > I need those signals to control the analog CMOS circuit that has a
> > > > requirement for some signals not to overlap - this happens when the
> > > > output from the FPGA is not synchronous enough.
>
> > > These signals will never be "synchronous enough" to guarantee zero
> > > overlap when changing on the same clock cycle.  Use a faster clock
> > > if you need to, but certainly add a clock cycle between assertion
> > > of signals that must not overlap.
>
> > Yes, I was thinking of using 16 times faster clock to add one clock
> > cycle in between, but I have checked signals with the 500MHz scope
> > (10Mohm, 9.5pF probes) and it looks like that digital analyser is
> > giving misleading waveforms - there is almost no delay between these
> > two signals (less then 1ns). The rise time is same for both signals,
> > and this can be improved by increasing the drive in UCF file from the
> > minimum 2mA, I don't know the load yet.
>
> You might want to learn how a logic analyzer works.  It sounds like
> your analyzer has a 400 MHz sample clock because of your noted 2.5 ns
> uncertainty.  This sample clock is of course asynchronous to your
> circuit.  So even if your FPGA's outputs are skewed less than 1 ns (as
> you point out), that window might include the logic analyzer's sample
> point, and as such signals that are in reality only 500 ps apart
> appear on the analyzer to be 2.5 ns apart.
>
> So you should ensure that all of your signals are registered by a low-
> skew clock in the IOBs and ensure that your PCB routing has equal
> length lines from the FPGA to the load.  This should result in quite
> good skew matching.  Also make sure the output s set to FAST, and
> increase the drive strength.  Read your timing analyzer's report for I/
> O clock-to-out times.
>
> And if the requirement is to ensure that two outputs are never enabled
> simultaneously, then do as Gabor says and insert a one-clock dead time
> between the deassertion of one output and the assertion of the other.
>
> -a- Hide quoted text -
>
> - Show quoted text -

2.5ns did not bother me, as that is the finest resolution of the logic
analyser. But 5ns did bother me as that is longer than the sampling
resolution. Scope has given me more precise reading - propagation
dealy is 700ps and the rise and fall times for both the signals aprox.
2.5ns which is perfectly fine.