0
\$\begingroup\$

I've synthesized a design for a Coolrunner II CPLD. I intend to use the CPLD's internal clock. I have an input named CLK. I look at the fitter report and I see this:

** Global Control Resources **

GCK         GSR         GTS         DGE
Used/Tot    Used/Tot    Used/Tot    Used/Tot
1/3         0/1         0/4         0/0

Signal 'CLK' mapped onto global clock net GCK0.

** 16 Inputs **

Signal                                    Bank Loc     Pin   Pin       Pin     I/O      I/O
Name                                                   No.   Type      Use     STD      
(snip)
CLK                                       1    FB2_7   43    GCK/I/O   GCK     LVCMOS18 KPR

Of course, CLK is indeed the name of the input I'd like mapped to the clock. But how did it know to do this?

One 'gimme' is that CLK is a standard name and XST made a good guess. So I renamed every CLK signal in the design to 'XXX'.

I re-synthesized (?) and now the report says:

Signal 'XXX' mapped onto global clock net GCK0.

So what gives here. How is this working?

All that being accepted, will XXX now be the hardware clock, or is there some other step I must take?

EDIT: where XXX is used.

always@(posedge foo)    //create 1 and 2 pipe delays of inputs
begin
    aq2 <= aq1;
    aq1 <= aquad;
    bq2 <= bq1;
    bq1 <= bquad;
end

This is in a quadrature decoding module. XXX is passed as an argument. foo is XXX here. Of course, this is just Verilog, I don't know what it's doing under the hood.

Edit 2 - enlightenment has occurred.

I have misunderstood what GCK is. I thought it was a clock signal generated by and internal to the CPLD. It is not. The GC stands for 'Global Control'. It's an architectural mechanism that allows a signal to be propagated around the CPLD's macrocells at very low cost and low skew. It's a network, not a clock. The CoolRunner II does not have an internal clock. I will have to conjure a clock and connect it to pin #43 (the GCK pin) of my xc2c64a CPLD.

\$\endgroup\$
3
  • \$\begingroup\$ OK -- glad you worked out what's going on. Now an extra note. Check your datasheet because you may need to connect your externally generated clock signal to the chip though specific designated pins. \$\endgroup\$
    – The Photon
    Nov 17 '12 at 18:55
  • \$\begingroup\$ Yes. Pin 43 on the VQ44 package is for GCK. Confirmed by (God forbid) reading the data sheet and by checking the output of the fitter to confirm that pin was produced by the fitter. \$\endgroup\$
    – Tony Ennis
    Nov 17 '12 at 19:34
  • \$\begingroup\$ You've got it. Actually I saw after writing my comment that you had checked the pin, but decided to leave my comment for future readers. \$\endgroup\$
    – The Photon
    Nov 18 '12 at 18:19
3
\$\begingroup\$

Without knowing more about your design, we can only guess.

Most likely, you connected the CLK (or XXX) signal to the clock pins of one or more flip-flops.

That is probably enough for the tool to recognize it as a clock and route it on the global clock routing.

In a comment, you add:

it's hard to imagine how a designer could make the leap that any CLK pin should be connected to a real clock.

There's no requirement that the signals on the GCK nets be "real" clocks, meaning periodic signals with 50% duty cycle. What distinguishes GCK nets is that they have high fan-out, across the whole chip (not just one region), and they have dedicated routing resources (switches) that can connect them to the clock pins of the flip-flops.

So when you route any signal to the clock pin of a flip-flop, the synthesis tool will see that as a candidate for a GCK net. If you have fewer nets connected to flip-flop clock pins than there are available GCK nets, it will probably route all of them via GCK resources. If you have more nets connected to clock pins than there are GCK nets, it will probably prioritize the ones with the highest fan-out.

The tool might also prefer to route clocks on GCK nets, in order to keep other routing available for logic signals that can't use those resources.

This can actually be a problem in some designs. GCK nets have the best propagation delays for nets with very high fan-out. But if your signal actually has low fan-out it might actually be faster to route it on regular logic routing or a regional clock net (I haven't gone back and looked exactly what kind of routing is available in Coolrunner-II). Nonetheless the tool might choose to route clock signals on dedicated clock nets. A synthesis or place & route directive may be needed to get the best performance in these situations.

Of course, the synthesis tool is extremely complicated and we can often only guess what's going on under the hood. You may be able to concoct a situation where the tool fails to recognize a clock and doesn't use the GCK nets. For example, if you route a signal to both clock pins and combinatorial logic, that might change the tool's understanding of its function.

\$\endgroup\$
1
  • \$\begingroup\$ That's a good point. But it's hard to imagine how a designer could make the leap that any CLK pin should be connected to a real clock. XXX is used in one place. I have edited the OP with the code. \$\endgroup\$
    – Tony Ennis
    Nov 17 '12 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.