VHDL style question

V

vu_5421

Guest
Hi,

I have an internally generated clock (CLKDIV) produced by a DCM. I
bring this clock through a global clock buffer and distribute it to
the rest of my logic.

At the same time, I also want to bring this clock to an external IO
pad for monitoring.

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."

Thanks for any advice.
 
On Jul 19, 2:06 pm, vu_5421 <nugentof...@gmail.com> wrote:
Hi,

I have an internally generated clock (CLKDIV) produced by a DCM. I
bring this clock through a global clock buffer and distribute it to
the rest of my logic.

At the same time, I also want to bring this clock to an external IO
pad for monitoring.

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."
Click to expand...
The only solution to this that I've found is to use a second DCM to
drive the output pin.

-a
 
On Jul 19, 6:39 pm, Andy Peters <goo...@latke.net> wrote:
On Jul 19, 2:06 pm, vu_5421 <nugentof...@gmail.com> wrote:



Hi,

I have an internally generated clock (CLKDIV) produced by a DCM. I
bring this clock through a global clock buffer and distribute it to
the rest of my logic.

At the same time, I also want to bring this clock to an external IO
pad for monitoring.

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."

The only solution to this that I've found is to use a second DCM to
drive the output pin.

-a
Click to expand...
Andy,

You are suggesting that I bring this internally generated clock into
another DCM's CLKIN pin, and then bring the CLK0 output of this second
DCM to my output PAD?

How will affect the timing of the signal? Will my internal clock and
the output clock still be exactly phase aligned?

Thanks again.
 
vu_5421 wrote:

How will affect the timing of the signal? Will my internal clock and
the output clock still be exactly phase aligned?
Click to expand...
No, but you can specify delay constraints
and see if they are met.

-- Mike Treseler
 
On Thu, 19 Jul 2007 14:06:48 -0700, vu_5421 <nugentoffer@gmail.com>
wrote:

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."
Click to expand...
Some technologies provide a DDR output register in the IO block, which
can be clocked from the clock, with the two data inputs wired to 1 and
0. This provides a (slightly delayed) clock output with only synchronous
loads on the clock signal.

Alternatively instantiating an OBUF (output buffer) might suppress the
warning.

- Brian
 
On Jul 20, 5:42 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
On Thu, 19 Jul 2007 14:06:48 -0700, vu_5421 <nugentof...@gmail.com
wrote:

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."

Some technologies provide a DDR output register in the IO block, which
can be clocked from the clock, with the two data inputs wired to 1 and
0. This provides a (slightly delayed) clock output with only synchronous
loads on the clock signal.

Alternatively instantiating an OBUF (output buffer) might suppress the
warning.

- Brian
Click to expand...
Mike,

What about using the clock feedback deskew feature of the DCM? Would
this guarantee a match between output clock and input clock?


Brian,

No dice on OBUF, it was one of the first things I tried.

Appreciate all the help.
 
vu_5421 wrote:

Mike,

What about using the clock feedback deskew feature of the DCM? Would
this guarantee a match between output clock and input clock?
Click to expand...
That's an fpga question, but it sounds plausible.
Check the error specs vs your monitor requirements.

-- Mike Treseler
 
On Jul 19, 7:34 pm, vu_5421 <nugentof...@gmail.com> wrote:
On Jul 19, 6:39 pm, Andy Peters <goo...@latke.net> wrote:



On Jul 19, 2:06 pm, vu_5421 <nugentof...@gmail.com> wrote:

Hi,

I have an internally generated clock (CLKDIV) produced by a DCM. I
bring this clock through a global clock buffer and distribute it to
the rest of my logic.

At the same time, I also want to bring this clock to an external IO
pad for monitoring.

What is the best VHDL style to implement this? Should I directly
assign the output of the global clock buffer to the output pad?

It is currently giving me a warning during "translate" about mixing of
synchronous and PAD elements. Also, there are warnings during MAP
about "clock buffer is designated to drive clock loads.... there are
some non clock loads connected..."

The only solution to this that I've found is to use a second DCM to
drive the output pin.

-a

Andy,

You are suggesting that I bring this internally generated clock into
another DCM's CLKIN pin, and then bring the CLK0 output of this second
DCM to my output PAD?
Click to expand...
Yes.

How will affect the timing of the signal? Will my internal clock and
the output clock still be exactly phase aligned?
Click to expand...
See Mike's reply.

-a
 
On Jul 20, 3:42 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

Alternatively instantiating an OBUF (output buffer) might suppress the
warning.
Click to expand...
It doesn't ...

-a
 
On Fri, 20 Jul 2007 11:11:40 -0700, Andy Peters <google@latke.net>
wrote:

On Jul 20, 3:42 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

Alternatively instantiating an OBUF (output buffer) might suppress the
warning.

It doesn't ...
Click to expand...
Bummer.

The DDR register might work, though one time it failed for me because
the tile was shared with a confliction IOB (and I couldn't change the
board layout)

- Brian
 
On Sat, 21 Jul 2007 13:14:42 +0100,
Brian Drummond <brian_drummond@btconnect.com> wrote:

The DDR register might work, though one time it failed for me because
the tile was shared with a confliction IOB (and I couldn't change the
board layout)
Click to expand...
If this is only for monitoring, wouldn't it be OK to use the internal
clock to clock a divide-by-2 (toggle) flop and drive its output
through the OBUF? Then *every* edge on the output corresponds
to an *active* edge of the internal clock.

Sure there would be some delay, but I would have
thought that the FF clock-to-output delay would be completely
negligible by comparison with the pad delay, which you would
be suffering in any event.

Obviously, if you actually need the clock signal outside
the FPGA for some reason other than monitoring, this isn't
going to work.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top