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.
Reference Designs with 13MHz clock @ 500MHz PLL Settings
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
-
- XCore Expert
- Posts: 967
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Generally I would expect there to be no difference, with only the jitter of the audio master clock having any impact.
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
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.
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.
-
- XCore Expert
- Posts: 967
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Agreed. Though there are plenty of people that would argue otherwise..bearcat wrote: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.
Again, agreed. In this case you could use an external flop to resync with the master clock.bearcat wrote: 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.
.bearcat wrote: Thanks for all the comments
np. Interested to hear your findings. :)
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
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...
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...
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
xflash has an option to dump the image to file. It's bit-reversed.bearcat wrote:I wanted to look at the loader code, but could not find any way to dis-assemble it.
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
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
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.
I will try bit reversing it and see if that works.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Ugh, yes. It's not an ELF file; it is a raw binary with #wordsbearcat wrote:But taking that file to xobjdump gave an error that there was no elf's.
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?
-
- Respected Member
- Posts: 318
- Joined: Tue Dec 15, 2009 12:46 am
There is a roundabout way of disassembling raw binary using xobjdump:segher wrote: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?
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