XS1-L8A-64-LQ64 Clock Input

[JasonWhiteman]

I'm looking at the datasheet and notice the following parameters:

4.22MHz < Freq < 100 MHz
Slew Rate 0.10 V/nS MIN (no max)
TJ(LT) Longterm jitter 2% of clk period

I do not see the buffer properties although the SliceKit schematics show the CLK buffer input as driven by 3.3V logic.

Given these constraints, it looks like there are 100MHz Oscillators that can be matched with XMOS without adding much cost overhead vs. the xtal solution.

However, I have not seen any 100MHz reference designs as of yet.

Question: Does XMOS have experience with some "known good" clock solutions for max Freq (100MHz)?

I've reviewed more documents than just the appropriate XS-L8A datasheet - X1433A for example - and no further details were found.

Regards,
Jason Whiteman

[lilltroll]

I'm not sure that I understand, but the XMOS has an internal PLL, so it can generate the needed internal frequency from a wide span of input clock-frequencies.

If you have another circuit that needs a clock as well, for an example Ethernet, you can share for an example a 25 MHz clock with the Ethernet chip and the XMOS chip.

What is the reason to use a clock > 25 MHz, is 100 MHz lower priced compared to other speeds ?
Anyway, as long that you set the mode pin correct at the XMOS chip any frequency within that span should work.

[JasonWhiteman]

My external logic is >25MHz so in order to reduce my clock domains - I am feeding both 100MHz.

I understand the clock question -- and I've been on the fence of using the internal PLL to reach the desired rate.

However - in addition to the above rationale:

1) Not sure XMOS I/O buffers can supply CLK output on a GPO pin >60MHz to take advantage of the PLL (internal use only)

2) When I was building internal clocks - I believe external clock (not sys-clock) was part of the equation. Therefore, granulator is improved with higher clock rate.

3) Even though I/O is capped at 60MHz, I have also seen XMOS supports higher data input rates using an external clock. I'm not sure how much of this information is "vapor" or "wishware" as it seems to conflict with the stated 60MHz max.

At the end of the day, I'd like to pump 100MHz data into the device and am looking to maximize the chances for success. Betting on identified "wishware" has me prepared for a slower datarate than desired.

My backup plan is to register the data and use more I/O although I have run out of pins and the fix for this is doable - although presents another layer of complexity to mux and handle I/O direction depending on mux value. Cost adder for external parts also has me backing off of this requirement in which case I'll live within the 60MHz boundary and feed my external logic an output pin to drive its clock at a slower rate.

Regards,
Jason Whiteman

[JasonWhiteman]

... and to follow-up on the rationale for the question:

25MHz is the sweet spot for designs. So I see a lot of validation using a 25MHz clock - and likely from an array of vendors/etc. Part of the question was fishing for another max-clock reference that has been through the ringer (testing, validation) to build confidence in "living on the edge" (of spec). When clock issues are seen during the product development of a microprocessor (from the vendor's side - XMOS, etc), the vendor will sometimes dictate a list of "known good" parts to choose from. Due to the niche purpose for using a 100MHz clock in the first place -- there's just not a lot of information so I have concerns over validation coverage.

Regards,
Jason Whiteman

[lilltroll]

First, let's separate some different block's of the XMOS.

The pin for clocking the chip internally uses a PLL to achieve the internal frequency of 400-500 MHz. (XCore clock)
https://www.xmos.com/en/download/public ... 33A%29.pdf

But you also have clock-blocks on each tile.
The port-logic can either have a clock generated internally based on the internal clock or from an external clock-source on a 1 bit port. Using the 1 bit port option with external clock has a limit in maximum frequency.

You can sets the source for a clock to the reference clock with:

Code: Select all

void set_clock_ref(clock clk);

An example with internal and external clock is showed here
https://www.xmos.com/en/support/documen ... 806&page=3

An advanced trick to get higher port frequencies is to combine several threads with the same port.

[lilltroll]

At the end of the day, I'd like to pump 100MHz data into the device and am looking to maximize the chances for success. Betting on identified "wishware" has me prepared for a slower datarate than desired.

Try to use up to 4 active threads "sampling" the same port. I do not know if that is possible in XC in the new 13.Beta release, you might need to write it in assembler.

It might be some test code available for that regarding PWM/motor control.

How is your indata encoded ? Do you have a clock pin and a serialized data-pin ?

[JasonWhiteman]

The clock domains are/were understood. My options were:

1) Run everything slow - use 10MHz<=clkfreq<=50MHz. This gives option of using either a clk tree from the original clock to the interfacing logic or using an XMOS pin output as micro generated clk.

Pro(s): a) Saves parts (only one clock source)
b) Power savings

Con(s): a) Speed is slowed down to match XMOS limits for producing cascaded CLK output

2) Run XMOS @ slower speed (25MHz for example), external logic at fast speed (100MHz)

Pro(s): a) Balanced power - XMOS clk'd at slower speed, external at high spd

Con(s): a) More external parts required

3) Feed both external logic and XMOS faster clock (100MHz)

Pro(s): a) Parts / speed optimized (least parts with high speed)

Con(s): a) Highest power

-----

It's worth mentoning that I was clear that XMOS's input clock (for sys CLK) and the external logic need not use the same clock domain. The rationale for using the same clock is simply to reduce parts count knowing there is a tradeoff with power and also other side-effects of higher frequency signals on the board (EMI, xtalk, etc).

-----

Also, I've used X1009B.PDF as part of my development reference. The frequency limits are not described. The implication from forum posts is that the clock speed using an external clock can exceed the 60MHz max I/O speed. However, this is untested here so I am still designing to the 60MHz max assumption as a possibility.

I thought about using multiple threads -- ideally I would be able to access the same pins with multiple threads. Therefore I could align thread "A" with clock + 0 offset (ie rising edge of clock) and align thread "B" with clock + 1/2 period offset (ie falling edge of clock). If using a 50MHz clock (within the 60MHz limit) - skewing one thread by 50% would achieve a 100MHz effective.

The bus is not unlike the LCD.

Regards,
Jason Whiteman