Reference Designs with 13MHz clock @ 500MHz PLL Settings

[bearcat]

Ross, I would use:

USB -> reference design analog out -> analog in on another device -> RMAA.

If you use a digital output, the jitter would follow to the input. I would look at the THD+noise and harmonics difference between the two PLL settings.

[Ross]

Generally I would expect there to be no difference, with only the jitter of the audio master clock having any impact.

[bearcat]

I had gone back and reviewed the reference design and is a little different than I remembered, and I suspect you are right Ross. The reference design is tied to the MCLK, which is generated from the crystal. I did not review if the DAC's and ADC's use the MCLK for sampling, but I suspect they do. If they use BCLK, then jitter would be relevant.

Newer DAC's are self generating the MCLK from the BCLK to keep the higher frequency signal from being needed. Having the XMOS generate the BCLK and LRCLK would require careful design.

Thanks for all the comments.

[Ross]

I had gone back and reviewed the reference design and is a little different than I remembered, and I suspect you are right Ross. The reference design is tied to the MCLK, which is generated from the crystal. I did not review if the DAC's and ADC's use the MCLK for sampling, but I suspect they do. If they use BCLK, then jitter would be relevant.

Agreed. Though there are plenty of people that would argue otherwise..

Newer DAC's are self generating the MCLK from the BCLK to keep the higher frequency signal from being needed. Having the XMOS generate the BCLK and LRCLK would require careful design.

Again, agreed. In this case you could use an external flop to resync with the master clock.

Thanks for all the comments

.

np. Interested to hear your findings. :)

[bearcat]

Well, after more testing with V13, there is still a timing issue with the loader code in V13 final. At increasing temperature, there is more delay in startup of the cores (did not take any actual measurements, so can't say with complete confidence). The loader code in XFLASH does not handle this for my 10 tile design.

V13 loader code is much improved, but even at room temperature, would still sometimes not boot my project maybe 5% of the time.

I wanted to look at the loader code, but could not find any way to dis-assemble it. It blocks in the same code each time, when it does.

I believe I have finally a workaround. The blocking happens between tile 0 and 1. So I set the link speed to 100 in the XN file for this channel. I then restart the link in my application after everything is running, to a delay value of 8. Booting takes a couple seconds longer.

Project has now booted successfully 50 or so times, and now boots at elevated temperatures.

Great...

[segher]

I wanted to look at the loader code, but could not find any way to dis-assemble it.

xflash has an option to dump the image to file. It's bit-reversed.
Send me a copy if you want (my email is easy to find); if you
cannot find the option, holler and I'll dig it up.

Happy new year,

Segher

[bearcat]

Thanks Segher for the reply. I had found the way to have XFLASH write a file instead of flash. But taking that file to xobjdump gave an error that there was no elf's.

I will try bit reversing it and see if that works.

[segher]

But taking that file to xobjdump gave an error that there was no elf's.

Ugh, yes. It's not an ELF file; it is a raw binary with #words
in front and a checksum at the end. xobjdump cannot handle
that as far as I know; use some other disassembler. I can do
it for you?

[richard]

Ugh, yes. It's not an ELF file; it is a raw binary with #words
in front and a checksum at the end. xobjdump cannot handle
that as far as I know; use some other disassembler. I can do
it for you?

There is a roundabout way of disassembling raw binary using xobjdump:

Code: Select all

# Create a single tile binary
xcc main.xc -target=XS1-L8A-64-TQ128-C5 -o image.xe
# Convert ELF sectors into binary sectors (converts image.xe to image.xb)
xobjdump --strip image.xe
# Inject binary image you want to disassemble.
xobjdump --replace 0,0,image.bin image.xb
# Disassemble
xobjdump -D image.xb

If you want to disassemble an xflash image you'll still need to reverse the bits in each byte beforehand.