XC9500XL : using a GCK pin as regular IO to match long transition time clock

• XC9500XL : using a GCK pin as regular IO to match long transition time clock
  Posted by Sassa on 06 May, 2024 09:40
• Hello,
  The subject of my help request is an expansion board with a XC95144XL, that is connected to a host system with a MC68000 CPU. This host system is providing an 8MHz clock.
  I found that on earlier host system board revisions, this clock signal is weak and transition times can be up to 20 to 25ns.
  
  On the expansion this clock is routed to a GCK pin, and this is causing glitches because it does not meet maximum rise/fall times : see question "3226 - CPLD CoolRunner XC9500/XL/XV - What maximum rise/fall times are recommended for inputs?" https://support.xilinx.com/s/article/3226?language=en_US
  
  I understand that a solution is to use this clock as a standard I/O signal.
  To confirm this I installed a patch wire to route it to another standard I/O pin, and that makes it work as intended.
  
  
  Now, I am looking for a solution to solve this without hardware modification.
  
  This global clock is detected and set by ISE. I tried disabling the use of global clock, either globally in the fitter options of ISE or on the select pin (using /* synthesis syn_noclockbuf=1 */ according to https://www.xilinx.com/support/answers/4084.htm), I see that it changes few things in the implementation but the pin is still reported as used as "GCK" in the Fitter Report and the glitches are still there. Many other things I found do not work at least for CPLDs.
  
  I confirmed that adding complex combinational logic to this signal forces the ISE Fitter to use the pin as a standard input (with a warning message "Cpld:1239 - The global clock designation (BUFG) on signal is ignored"), but well I do not want this complex logic. I said complex because I have to mix it with other signals so that it is not simplified/ignored. So far I have not found how to telI ISE to keep the simple logic I try to add to this input just for my purpose, for example with the following :
  (* keep = "true" *) (* s = "true" *) wire c7m = M68K_CLK & M68K_CLK;
  
  
  Do you have an advice how to achieve either the right solution or a workaround with combinational logic ?
• #1 Reply
  Posted by PCB.Wiz on 06 May, 2024 17:46
• Why not just add a tiny logic Schmitt to get a clean clock ?
  
• #2 Reply
  Posted by Sassa on 06 May, 2024 19:59
• Thank you PCB.Wiz for your suggestion,
  Well, if one day I have the opportunity to make a new revision of the board then I will certainly just route this clock to a standard IO pin, since it is free and does not need to add a part to the BOM...
  
  The main reason of my question is that I'd like to learn, and that not finding an elegant solution to something I believed was rather simple just bugs me. There has to be a way to tell ISE to implement the design the user want, keeping the signal on this same pin.
• #3 Reply
  Posted by PCB.Wiz on 07 May, 2024 00:04
• Quote from: Sassa on 06 May, 2024 19:59

  Thank you PCB.Wiz for your suggestion,
  Well, if one day I have the opportunity to make a new revision of the board then I will certainly just route this clock to a standard IO pin, since it is free and does not need to add a part to the BOM...
  
  The main reason of my question is that I'd like to learn, and that not finding an elegant solution to something I believed was rather simple just bugs me. There has to be a way to tell ISE to implement the design the user want, keeping the signal on this same pin.
  

  
  What you have done is the right path. If you want to sidestep the default global clock in CPLDs you usually need to add some dummy logic.
  
  Keep in mind a same-pin different internal choice is unlikely to fix the slow slew issue.
  
  It is the input pin buffer and parasitic inductances inside the packages, that usually oscillate on the too-slow edges.
  
  Another option would be to craft a more assertive pin-keeper, that's another part or pin giving  positive feedback, that the driver has to overcome.
  In an ideal case, the pin-keep thresholds neatly span the CPLD logic threshold so a rapid slew occurs across the important region.
  
  Or you could look upstream - what makes the clock slew so slow ?
  
  
• #4 Reply
  Posted by BrianHG on 07 May, 2024 01:55
• Quote from: PCB.Wiz on 07 May, 2024 00:04

  Or you could look upstream - what makes the clock slew so slow ?
  

  Yes, if the source is for example a sine wave, though a 74AC14 will accelerate the output edge, that edge may have phase noise and duty cycle issues, especially if the AC14's supply is noisy.  To get rid of that phase noise from a source sine wave, a superior option may be a 1 or 2 transistor amplifier, or passing the signal through a series cap into a 74HCU04 with the output also having a resistor back to it's input to bias that cap.  Maybe even going through 2 stages of a HCU04.
  
• #5 Reply
  Posted by Sassa on 07 May, 2024 12:58
• Thank you,
  
  I finally found some logic to tell ISE to use the input as I/O and not optimize it :
     (* keep = "true" *) wire _temporary_clock = !input_clock_pin;
     wire clock = !_temporary_clock;
  In the Fitter Report the "Pin Use" is now "I" instead of "GCK/I".
  
  However the glitch is still there, so as PCB.Wiz you thought, I also believe that this maximum rise/fall time has more to do to the hardware construction of the pin than to what type of logic it is connected to, contrary to what I understood when reading https://support.xilinx.com/s/article/3226
  
  I believe this is a good thing to know about these XC9500XL devices.
  
  About my board, I now know that I have to install a patch wire to another non-GCK pin (in this case the only one left, I-m glad I attached it to a pad for future use !), or one of the solutions you proposed here.
  
  Thank you very much !