I use the Xilinx ISE9.1 and a Spartan3.
The synthesis (XST) was ok, but the Translate process shows
this error:
ERROR:NgdBuild:455 - logical net 'clk10mhz' has multiple driver(s):
pin O on block clk10mhz1 with type LUT3,
pin PAD on block clk10mhz with type PAD
ERROR:NgdBuild:924 - input pad net 'clk10mhz' is driving non-buffer
primitives:
pin O on block clk10mhz1 with type LUT3
When I put the selected clock to an output and read it from
another input and put it direct to the DCM then my design
works very well.
What is my fault?
Mathias
Did you use the architecture wizard (or CoreGen) to "create"
your DCM? This method has a habit of adding the input pin
buffer, which you obviously don't want if the input to the
DCM comes from an internal signal.
Regards,
Gabor
Thank you very much: Yes, I use the wizard and there is a checkbox if
the clkin source is internal or external. But after a change of this
checkbox it is necessary to make a little change in the source code.
A view to the intantiation template is helpful.
Mathias.
> Mathias
I am slightly confused with your suggestion. To generate a 200mhz
clock signal from a 10 (or 60) mhz clock input, you have just to set
the DCM frequency multiplication to 20(or 20/6). Am I mistaken?
The issue would be switching clock sources on the fly. The DCM
at least before Virtex 5 was completely programmed by the bitstream,
so you couldn't change the multiplication / division factors without
at least a partial reconfiguration. So the idea of creating the same
input frequency from two sources seems sound. What you might lose
is any constant phase relationship to the input clocks. However if
this is just a frequency synthesis problem that shouldn't matter.
There's no reason not to use a fabric signal to feed the DCM if
you don't need that phase relationship back to the input source.
I suppose the original idea was to allow two sources so the 200 MHz
would be available even if only one of the two clocks is running.
One note of caution, if you have two clocks and want to switch
between them using a BUFGMUX, then you should be aware
that the glitch prevention circuitry can prevent the switch
from occurring if one of the clocks is not running. So it may be
better to use a fabric-based mux followed by a simple BUFG.
Regards,
Gabor