07-21-2019 04:09 PM
I am using ISE 14.7 to design for an XC2C256 Coolrunner II part using schematic entry. I am trying to use a couple of the global clock lines in the part to distribute a pair of clock signals to a number of flip flops and counters.
The clocks are not coming directly from IO pins. There are several clock sources (not all on GLCK pins) that go through a MUX to select one of them. I then want to use the output of the mux as a master clock, and an inverted version of that signal as a second master clock. (nets named MCLK and MCLK_NEG).
My first attempt was to place BUFG schematic symbols after the mux (for MCLK) and after an inverter (for MCLK_NEG). This gave me several errors.
So I did some more searching and found something saying that internal signals can be routed to the global clock lines by adding a BUFG = CLK attribute to the nets.
So I dropped the BUFG symbols and added a BUF symbol to isolate the MCLK net from the mux. So the MUX goes to both an inverter and a BUF. The output of the BUF is net MCLK and the output of the inverter is net MCLK_NEG. I then clicked on each net, selected properties, and added a new attribute of BUFG to each with property CLK.
The result is that during Fitting I get the following error:
INTERNAL_ERROR:Cpld::0:1.112 - Net 'MCLK' attached BUFG is not assigned to global CLOCK.
So, what am I doing wrong? The two nets in question are only connected to the clock inputs of flip flops and counters. They don't connect to any pins that are not clock inputs. What is the best way using schematic entry for a Coolrunner II part to make a pair of internal nets (driving only clock pins) use the global clock lines?
07-22-2019 01:48 PM
Does anybody have any experience using the global clock lines to distribute an internally generated clock within a Coolrunner II CPLD, even if it's not in a schematic. In Verilog/VHDL or schematic?
Even though I can't find anything in any docs about it, I am getting the impression that when you use a BUFG in a Coolrunner II for an internal net that you can not use the external pin that the BUFG is normally connected to.
If I delete the I/O Marker and IBUF for one of my external signals that is connected to the specific pin which can be either an I/O or GCK0, I can then asign the BUFG=CLK attribute to an internal net and it gets fitted and the report shows that net using Global Clock GCK0. If I define a signal coming into that external pin, then fitting fails, I'm guessing it fails because there aren't any global clock lines available to meet what I told it to do.
I tried unchecking the Use Global Clocks setting in the Fitting Process Properties, as described in one of the Xilinx documents that says that will prevent ISE from automatically adding a BUFG to the GCKx input pins. Didn't help.
I can't change the physical design. The product has been in production for a couple of years. I'm just trying to improve how it works.
So, anybody out there that has used a BUFG for an internal clock on a Coolrunner that knows if doing that means those external GCK pins become unavailable as general I/O pins if the corresponding BUFG is used internally?
07-25-2019 07:05 AM
Nobody uses Coolrunners?
Or nobody has used global clock lines on them for internally generated clock signals while using the GCKx lines for regular I/O?
07-27-2019 08:19 AM
The clocks are not coming directly from IO pins. There are several clock sources (not all on GLCK pins) that go through a MUX to select one of them. Does anybody have any experience using the global clock lines to distribute an internally generated clock within a Coolrunner II CPLD
I don’t have experience with the Coolrunner but my reading of the datasheet, DS090, suggests that true clocks must enter this CPLD via the three clock pins (GCKx) and that (unlike FPGAs) CPLDs have no internal clock management tiles (CMTs) for creating new clocks (except for the clock division circuit connected to GCK2).
So, the “several clock sources” that you talk about are probably digital signals that look like clocks and are created in the logic(fabric) of the CPLD. In the FPGA world, we refer to these clock-like signals as toggles. Instead of placing a toggle in the FPGA global clock tree (which is considered bad), we use a toggle as shown by the VHDL code snippets below.
-- Create toggle, tog1, in the CLK1 clock-domain P1: process(CLK1) constant CNTMX : integer := 1000; --divider for CLK1 variable cnt : integer range 0 to CNTMX-1; begin if rising_edge(CLK1) then if(cnt = 0) then tog1 <= '1'; cnt := CNTMX-1; else tog1 <= '0'; cnt := cnt - 1; end if; end if; end process P1; -- -- Proper use of tog1 blink the P2: process(CLK1) begin if rising_edge(CLK1) then -- you could do something here at the rate of CLK1... if(tog1 = '1') then led_ctrl <= not(led_ctrl); --led_ctrl toggles at rate of tog1 end if; end if; end process P2; -- -- An example of how *NOT* to use a toggle P3: process(tog1) -- <<< DON’T DO THIS begin if rising_edge(tog1) then -- <<< DON’T DO THIS -- do something here ???... end if; end process P3
Perhaps, by thinking of your “several clock sources” as toggles, you can do what you want - and will no longer feel the need to place them in the global clock tree of the CPLD.
07-28-2019 07:50 AM
Thanks for replying. Just to clarify what I mean by "several clock sources", and why I want to use the global clock lines within the CPLD:
There are several external clock signals that come into the CPLD. Only one will be used at a given time. The sources are true clock signals, such as the output of a TCXO (temperature compensated crystal oscillator), the output of a PLL inside a video decoder chip, etc... I have full confidence in the stability and cleanliness of these signals. No glitches on the edges, minimal jitter in the timing.
When the circuit board was designed, the designer did not take care to place those clocks on global clock inputs (one is, but not others). And the hardware has been in production for a couple of years, so there is no changing the input pins being used now. All of the global clock input pins do have signals on them (not clocks), so it is not possible to do something internally in the CPLD that requires those pins contain no signals.
I wish to use a global clock bus in the CPLD specifically to reduce latency between flip-flop clock inputs throughout the CPLD. One of the external clock sources is being selected by a mux in the CPLD and that selected clock source is what I would like to feed to the global clock lines.
BTW, I am doing all of this using schematic entry.
The issue that I'm having is that it seems the tools will only let me put an internal signal onto one of the global clock buses if I am not already using the associated GLCK pin as a general I/O. Which appears to mean that the input the to BUFG driving that global clock bus is perhaps hard wired to that input pin, and can only be fed an internal signal by placing that internal signal onto that pin. I am just trying to verify if that is true or not.
07-28-2019 12:45 PM
Which appears to mean that the input the to BUFG driving that global clock bus is perhaps hard wired to that input pin, and can only be fed an internal signal by placing that internal signal onto that pin.
I think the answer is hidden between the words in AR#5572. To me, this AR says we can route internal signals to the global clock bus by assigning the BUFG attribute to the signal (see UG625 (v.14.5), pg 63). However, when you do this then one (the AR doesn't say which one) of the GCK pins of the CPLD also remains connected to the global clock bus - and cannot be used (ie. "Be sure that a global pin used in this way is unconnected on the board.").
AR#5572 refers to the obsolete XC9500 CPLD. I assume that AR#5572 applies to your XC2C256 whose datasheet, DS090, says "Xilinx CoolRunner™-II CPLDs deliver the high speed and ease of use associated with the XC9500/XL/XV CPLD family with the extremely low power versatility of the XPLA3 family in a single CPLD." I also assume that AR#5572 applies to your XC2C256 because the general Q&A site for CoolRunner-II refers to AR#5572.
So, I give myself a C+ for this answer. Perhaps your bench testing or a Xilinx person will fill in the missing pieces.
07-28-2019 03:09 PM
Thanks. I hadn't seen that AR. I was only looking at ones specifically for the Coolrunner II and hadn't thought about the possibilty that ones for the earlier series would also apply.
But from what you found it seems likely that the same architecture was used in the Coolrunner, and it probably does have that restriction.
Oh well, I'll have to live with the general routing for my clock and not get the optimized clock buses I was hoping for.
Thanks for your help.