Clock Gen questions

I think I have it sorted in my head how the clkgen works, but I would like to confirm it. So please let me know if anything below is incorrect.

It seems the CLKGEN does:
sysclk/extclk --> MUL|DIV --> CLKGEN output
Is sysclk the fixed clock that the Controller runs at?
(ie always 30MHz for CWRev2)

It appears that the hardware can read back the current frequency on either the EXTCLK pin or as generated by the CLKGEN. Which frequency to read would be selected by toggling the 0x08 bit in byte 3 of the ADDR_ADVCLK data. Then the frequency is the 32bits read from ADDR_FREQ.

The function that selects which frequency to read is:
def setFreqSrc(self, src):
result = self.oa.sendMessage(CODE_READ, ADDR_ADVCLK, maxResp=4)
result[3] = result[3] & ~(0x08)
result[3] |= src << 3
self.oa.sendMessage(CODE_WRITE, ADDR_ADVCLK, result, readMask=self.readMask)

The resultant CLKGEN output is available for use for clocking the ADC. Can it also be sent out to be used as a clock for your target?

Is the CLK SMA connector on the front of the CW kit for EXTCLK in? Or for CLK out?

Are the FPGA-HS1 and FPGA-HS2 pins on the target connector for EXTCLK and CLK out?

Is the PLL related to CLKGEN? Or totally separate?

Oh and is the DCM separate to the CLKGEN?
How are they related?
Why does the DCM need to be locked or reset?


Your assumptions are correct! The remaining questions:

The DCM is the internal block which generates the clock. The FPGA has a number of DCMs, they are used for generation of the optional phase shift on the ADC clock too.

The DCM can become ‘unlocked’ when it is no longer maintaining the proper phase/frequency relationship. If the input to the DCM is turned off or changes in frequency, it causes the block to become unlocked. At this point you need to reset it, and the lock should come back. The ‘lock’ flag is a read only.

Yup - this is done via the ‘HS-2’ pin. It is the only output which you can send that clock over. The others (the SMA on the front-panel and HS-1) are configured as inputs, but that is purely a FPGA thing, not a hardware limitation. You could modify the FPGA design to send it over those pins.

Totally different - it’s used to generate a new frequency based on some other input frequency. It uses an external chip as well which has some different abilities from the internal FPGA blocks (primarily it can operate at lower frequencies).



If I wanted to connect to a real world device, ie one that isn’t on a breadboard or on the target device board etc, am I better off getting the clock from the DUT and providing it to the OpenADC via the EXTCLK input, or generate the clock using CLKGEN and pass this to both the OpenADC and your DUT?

Are there any special connections and/or hardware that may be required for either case?
I assume the usual “keep wires as short as possible” and “don’t route wires alongside other noisy lines”.

As a specific case, a device I have here I want to run some tests on has a resonator circuit running at 25MHz. The datasheet shows that this can be replaced by a generated clock passed into the EXTAL pin and leave the XTAL pin unconnected. My current thoughts are that I would be better off cutting the traces to the resonator and wiring in a generated clock. This would allow me to run the device at different (lower) speeds if required. If I do this can I just use a normal wire to provide the clock signal, and of course a ground connection? Or should I use some kind of coax/shielded cable?

Also while I am on it, can I just use normal wires for the trigger connection (to a GPIO on my device) and for the connection to gnd/vcc for measuring the voltages?

As you guessed - ‘it depends’. Using the CLKIN is handy if you don’t want to modify the board too much - i.e. you might want to use the PCB afterwards. When using CLKIN you might need to add a small buffer right at the oscillator too, as the wire to the ChipWhisperer + buffer input circuits adds a lot of capacitance. This depends a lot on the device… if it’s an external oscillator it’s not so bad, if it’s just a crystal they are normally much more sensitive.

In your case - it does sound easier to insert the clock in. Using coax is nice if possible, but if you are talking <10cm an easy solution is just some twisted pair wire. This could be out of a CAT-5 cable for example, or just twist two wires together. This can easily be connected to the breakout board.

You might need a resistor in the drive output too (around 10-100 ohm), as the chipwhisperer output has a lot of drive strength that can cause ringing. This would mean something like:


You could also add the resistor as a ‘parallel termination’, which would mean across the output wire and GND wire at the device. i.e. (hopefully the ASCII art holds up):

CW-->Breakout(HSOUT)-->wire-------------------------------+->Device Pin
                                                          / (Resistor)
CW-->Breakout(GND)-->wire---------------------------------+->Device Gnd

Should be all fine there!

If doing the twisted pair for CLK, you might also want another separate wire for GND too. Whether that would actually help I don’t know, but hopefully the high-frequency clk return current will flow along the twisted pair…

I plan to position it such that all wires are <=10cm, so:

  1. Twisted pair where one wire is clock and other wire is ground for clock signal.
  2. Normal wire for trigger connection (Do I need a separate ground for trigger connection or will the twisted pair ground from above be enough?)
  3. And what about for measuring the power usage? Will a normal single wire do? I am not sure if I will be measuring the vcc or gnd line at this stage, I might try both so I can try the different probes.

Yup… actually even two side-by-side wires would work as well in this case (since it’s not differential), but it’s normally easier to find some random twisted pairs (or to make them) so I default to that!

Shouldn’t as the trigger is just a basic digital IO level, so existing ground will be fine.

Ideally coax again for the shield, although a single wire will work but be a little noisier. If you had a shielded wire (microphone cable for example) even would be helpful. Route it away from your clock lines. Although for short distances I’ve used a single wire without issue.

w.r.t. VCC/GND: that basically just requires some experimentation on your side. Some devices work better with one vs. the other…

Thanks for your clarifications.

I don’t have a separate scope to check the lines for noise or to see which of the multiple gnd/vcc lines gives the best signal etc, so I want to ensure my setup is as correct as it can be before I start investigating. :slight_smile:

I might look at buying a pack of these for future use with the CW kit. … 52918.html

I cannot seem to get the CLKGEN to work.
I am using v0.09 of cw sw, cw rev2 hw and GoLogic XP Logic Analyser.

I start the CW Capture software.
I set scope type to ChipWhisperer/OpenADC.
I hit scope connect on toolbar, it shows connected ok. (i also tried master connect at this step)
On the scope settings tab I set the desired CLKGEN frequency to 25MHz.
If I set the Freq Counter Src to CLKGEN output, it shows that it is 25MHz.
DCMS are locked.

At this point if I connect my LA to pin6 (FPGA-HS2 / Clock out) of the 20pin target connector pinout, and also connect an LA ground to pin 2 (GND) and capture at 500MHz, then I do not see any action on this line. It stays at logic low for the entire log.

I have attached a screenshot of the CW Capture settings.
Note that I used the same LA settings on the crystal from my DUT and can correctly see the clock cycling with a 40ns period.

Screenshot of CLKGEN settings:

Sorry that’s an issue with my “Wall of settings” parameters :confused: There is one called “HS IO-Out”, you need to set it to CLKGEN!

I tried setting “Target HS IO-OUT” to CLKGEN but it still has no effect, there is no clock on pin 6.
(I actually tried this the other day when I was trying to get it to work, and it didnt work then. But I tried again today just to make sure.)
So any other ideas?
Is someone able to test if they can generate a clock and see it coming out the back on pin6?


Solved by email but thought I’d post for others searching…

The VREF pin needs to be connected to your target voltage. If you want to get a signal this can just mean connecting the VREF pin to the 3.3V supply pin on the 20-pin cable. That VREF is used to set the output voltage of the driver chip - if it’s left unconnected I think the chips turn the output off.

Anyway another thing I need to document, but for anyone else running into the issue you need to connect the VREF pin! If using the breakout board this is done by setting the jumper to either ‘3.3V’ or ‘5V’, depending if you want 3.3V or 5V logic. If you want to use another voltage on the breakout board just leave that jumper disconnected, and apply the appropriate voltage into the VREF pin using the terminal block (max of 5V).