I've been playing with simulating the timing for emulating peripherals. I'm using the simulator because it's easier at this stage than holding an oscilloscope to the hardware, which in my case currently is the Explorer 200.
I've been exploring what clock frequencies are allowed and was surprised that the simulator at least will allow me to set an internal clock block to run at 250MHz, and then I can use a while loop with "timed output" (ie p_out @ count <: 1) with 4ns step control. This seems very useful.
For example, a loop that totals 5669 steps for one complete up/down cycle, where each step is 4ns, gives a frequency of 44099.5Hz, which is only 12ppm short of 44100Hz. This is as good as the crystal driving it. True, this is useless for SigmaDelta ADCs with oversample clocks, but it's plenty useful for SAR ADCs and most DACs.
Is the simulator accurately representing the capability of the part?
Are there any pitfalls to avoid in running an internal clock block at 250MHz?
Clock Block at 250MHz?
I'd be interested to know the answer to the the upper limit freq. of a clock block. It should be documented somewhere like the IC datasheet but those tend to be scant.
I'm not sure I follow you on the rest. I find some of the terminology confusing and some of the names of resources have been changed in documentation over the years ( for example core changed to tile and thread changed to core). When you say "clock block" I think you're actually referring to the system "reference clock", which I think is always the reference for port counters and optionally the reference for clock blocks. (?) I may have some of this wrong.
In your example ( p @ count <: 1 ), I believe this is the port's counter that uses the system reference clock.
In your projects .xn file:
<Node Id="0" Type="XS1-L1A" oscillator="24Mhz" systemfrequency="500Mhz" referencefrequency="100MHz">
You can change the 500MHz and 100MHz with some granularity. I can't remember how fine but the tools will tell you what frequencies it rounds-to.
Just for fun I re-compiled one of projects (targets XS1-L2A),changing referencefrequency to 250 and then 300. Tools enforce 250 as the limit. Can all of the logic in the IC that's derived from the reference clock run reliably at 250MHz? Would be interesting to know.
For you application, is jitter critical? In audio applications yes - perhaps unless it's just a matter of operating an IIS interface to a converter that also has a low-jitter mclk source. There is uncertainty of execution due to thread scheduling. But the ports also contribute granular jitter - typically +/- 2ns (system frequency). I don't know why but it's easy to observe with a high-frequency sampling oscilloscope. I don't think that this behavior is documented but I may have missed something there.
If you just need a 44.1kHz frequency reference and jitter (and duty cycle) don't matter, you can modulate count to fine-tune the frequency. If you need to output a 44.1kHz clock then you need to execute toggling between 0 and 1 at a rate of 88.2kHz.
fun times with xmos
I'm not sure I follow you on the rest. I find some of the terminology confusing and some of the names of resources have been changed in documentation over the years ( for example core changed to tile and thread changed to core). When you say "clock block" I think you're actually referring to the system "reference clock", which I think is always the reference for port counters and optionally the reference for clock blocks. (?) I may have some of this wrong.
In your example ( p @ count <: 1 ), I believe this is the port's counter that uses the system reference clock.
In your projects .xn file:
<Node Id="0" Type="XS1-L1A" oscillator="24Mhz" systemfrequency="500Mhz" referencefrequency="100MHz">
You can change the 500MHz and 100MHz with some granularity. I can't remember how fine but the tools will tell you what frequencies it rounds-to.
Just for fun I re-compiled one of projects (targets XS1-L2A),changing referencefrequency to 250 and then 300. Tools enforce 250 as the limit. Can all of the logic in the IC that's derived from the reference clock run reliably at 250MHz? Would be interesting to know.
For you application, is jitter critical? In audio applications yes - perhaps unless it's just a matter of operating an IIS interface to a converter that also has a low-jitter mclk source. There is uncertainty of execution due to thread scheduling. But the ports also contribute granular jitter - typically +/- 2ns (system frequency). I don't know why but it's easy to observe with a high-frequency sampling oscilloscope. I don't think that this behavior is documented but I may have missed something there.
If you just need a 44.1kHz frequency reference and jitter (and duty cycle) don't matter, you can modulate count to fine-tune the frequency. If you need to output a 44.1kHz clock then you need to execute toggling between 0 and 1 at a rate of 88.2kHz.
fun times with xmos
psupine wrote: ↑Fri Aug 30, 2019 10:32 am I've been playing with simulating the timing for emulating peripherals. I'm using the simulator because it's easier at this stage than holding an oscilloscope to the hardware, which in my case currently is the Explorer 200.
I've been exploring what clock frequencies are allowed and was surprised that the simulator at least will allow me to set an internal clock block to run at 250MHz, and then I can use a while loop with "timed output" (ie p_out @ count <: 1) with 4ns step control. This seems very useful.
For example, a loop that totals 5669 steps for one complete up/down cycle, where each step is 4ns, gives a frequency of 44099.5Hz, which is only 12ppm short of 44100Hz. This is as good as the crystal driving it. True, this is useless for SigmaDelta ADCs with oversample clocks, but it's plenty useful for SAR ADCs and most DACs.
Is the simulator accurately representing the capability of the part?
Are there any pitfalls to avoid in running an internal clock block at 250MHz?
I'm not changing the 100MHz reference clock.
From what I can work out, the 6 clock blocks per tile are simply 8 bit division from the 500MHz system frequency. The minimum divisor is 2, so 250MHz is selectable. I believe that the "Reference Clock" is just one of these clock blocks configured to a default 100MHz. This is why you could only configure the "Reference Clock" to 250MHz.
Any clock block can then be chosen as the clock source for a port, and the port counter is clocked at that rate.
The reason I wanted this is to emulate a peripheral in loop back that is *not* in perfect synch with another port clocked at the usual 100MHz, so that the interface would drift around on clock edges. I don't have a high speed sampling scope, but your observation of the 2ns jitter is not surprising.
For my own real application I use an external clock source.
From what I can work out, the 6 clock blocks per tile are simply 8 bit division from the 500MHz system frequency. The minimum divisor is 2, so 250MHz is selectable. I believe that the "Reference Clock" is just one of these clock blocks configured to a default 100MHz. This is why you could only configure the "Reference Clock" to 250MHz.
Any clock block can then be chosen as the clock source for a port, and the port counter is clocked at that rate.
The reason I wanted this is to emulate a peripheral in loop back that is *not* in perfect synch with another port clocked at the usual 100MHz, so that the interface would drift around on clock edges. I don't have a high speed sampling scope, but your observation of the 2ns jitter is not surprising.
For my own real application I use an external clock source.