Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 Khz - Page 58 - diyAudio
Go Back   Home > Forums > Commercial Sector > Vendor Forums > Vendor's Bazaar
Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Vendor's Bazaar Commercial Vendors large & small hawking their wares

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 28th November 2014, 01:22 PM   #571
diyAudio Member
 
andrea_mori's Avatar
 
Join Date: Jan 2005
Location: Italy
Quote:
Originally Posted by esgigt View Post
Andrea,
Can you expand on that, please?
I understand that the phase noise between 0Hz and 20Khz is very relevant in audio applications, but on the other hand I also see the numbers for Period jitter (RMS and pk-pk) which are in the range from 1.3ps to 11ps (max. values)...

Is this period jitter (how do I have to understand that term?) the number Soekris refers to?

Thanks in advance..
Jitter is the integration of the phase noise, so it depends on the integration bandwidth used to do the test. Since any decent oscillator shows a phase noise better than -140dBc at 1kHz from the carrier, the upper limit of the bandwidth is not relevant. But the pain starts when you fall down close to the carrier, where the phase noise increases considerably. So the lower frequency of the integration bandwidth chosen for the test affects strongly the jitter measured. Translated: the upper limit does not affects the jitter test, while the lower limit affects it. If you choose 12kHz for the lower limit, the jitter will be much better than if you choose 10Hz or 1Hz as the lower limit.
If you look at Crystek CCHD-957 datasheet you see they used an integration bandwidth starting at 10Hz from the carrier, that's correct for audio application.
While the lower limit used from SiLabs is suitable for telephonic application or so, not for audio.
There are several spreadsheet on the internet that helps to convert phase noise in jitter.
  Reply With Quote
Old 28th November 2014, 03:00 PM   #572
soekris is offline soekris  Denmark
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by StaticNoise View Post
The Xilinx Spartan-6 FPGA in the FTG256 package have system jitter in the range of 200ps and possibly up to 1000ps or more depending on the synthesised code, internal routing and if there are any processes that adds modulated noise to the PSU rails. This jitter adds to any clock jitter and are forwarded to the 595 shift registers that implements the DAC.
A simulation can maybe go as low as 200ps for the FPGA core, but due to the bonding wires, pads and pcb traces and the skew the practical total "jitter" may end up in the ns range.
That's a little too pessimistic.... You might be thinking about clock skew or pll jitter, not the jitter for the internal clock routing....

There will be jitter inside the FPGA and to the LVC595's, but I don't see any reason why it should be different from internal jitter in any other DAC chip....
__________________
Søren
  Reply With Quote
Old 28th November 2014, 03:14 PM   #573
Zoran is offline Zoran  Serbia
diyAudio Member
 
Join Date: Jan 2004
Location: Belgrade
All discussions can be taken like irrelevant.
Please accomplish this dac - and let us hear it
thanks
__________________
###
  Reply With Quote
Old 28th November 2014, 05:31 PM   #574
Banned
 
Join Date: Dec 2013
Quote:
Originally Posted by soekris View Post
That's a little too pessimistic.... You might be thinking about clock skew or pll jitter, not the jitter for the internal clock routing....

There will be jitter inside the FPGA and to the LVC595's, but I don't see any reason why it should be different from internal jitter in any other DAC chip....
Assuming that the total accumulated jitter only are dependent on a low jitter clock was the point I wanted to address.

With the Spartan-6 CPG196 package that have the lowest jitter and skew the lowest simulated system jitter for the internal clock routing I am able to get are 141ps.
However that is overly optimistic as it is only represents a small percentage of the real jitter on the output pads.

Quote:
Clock Uncertainty: 0.071ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.141ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
With that said the total jitter from a optimized Spartan-6 design are most possibly not higher than what a galvanic I2S isolator creates, and even a discrete D-FF re-clock chip may add significant jitter.

The quietio setting and setting of the output current drive of the output pads may improve the jitter on the DAC output, and also using all of the un-assigned pads as virtual GND and virtual VCC may improve jitter, noise and skew.
  Reply With Quote
Old 28th November 2014, 05:40 PM   #575
diyAudio Member
 
nautibuoy's Avatar
 
Join Date: Jan 2010
Location: Somerset, England
Quote:
Originally Posted by acko View Post
Quote:
Originally Posted by nautibuoy View Post
I disagree, though I'm not sure what you actually asked Acko. You can use the SO3 perfectly well between a Beaglebone and the R2R DAC, you just can't run it in full sync mode. You just use the SO3 to reclock the Beaglebone to ensure you keep native sampling rates, then feed the I2S from the SO3 to the R2R. Admittedly some functions on the SO3 are superfluous because the R2R isolates and reclocks but I don't think they will do any harm.

Soren,

I hope you do not mind my posting some explanation to clarify. I do not have all the details of your implementation but piecing together all that you have indicated so far this is what I think your front end processing is doing. (Correct me if I am wrong):

Basically a FIFO buffer- Reclocker similar to IanCanada's implementation.
Firstly, input I2S stream gets dumped into a deep FIFO and thereby decimating all the timing associating with the data (and so any incoming jitter or other latencies).

Next, new data is regenerated with respect to a reference audio clock and I would think this will be 22.5792MHz/24.576MHz to cover both 44.1k and 48k based frequencies. This could be what the Si514 is doing

So practically all benefits and concepts associated with Ian's FIFO are applicable to your implementation. You have just gone a step ahead to integrate this unique R-2R DAC on board as well. Just as well as it makes sense to package a complete FIFO-DAC system.


So with regards to the above queries, it would be pointless to connect the S03 to Soren's DAC just like you would not do so with Ian's board as both are standalone and complete system. By action of the FIFOs they completely decouple the signal flow from the source (transport) and does not need to interact with the transport clock but provide Full Sync operation of the DAC.

The implications are very interesting:
You can connect any I2S transport to Soren's DAC simply without worrying about quality of source clock or signals as the clock on the DAC and the FPGA processing determine the final outcome. Of course the isolation helps to block all the nasties from source side.

I am making a bold statement here:
Regardless of the type of transport used (as long as bit perfect types - native Fs with dual clocks) they will all sound the same on Soren DAC (similar to Ian's). So Amanero, BBB-Botic, M2tech, EDEL NMR, WaveIO etc will all sound the same as a result of the FIFO-reclocking action. So if you have any one of the above that will be good enough!
Excuse me for back-tracking the thread a little but I would like to check I’m not misunderstanding something…

Acko, I don’t disagree with the points you have made about the FIFO/reclocker inherent in the Soekris R2R DAC delivering consistent results through the DAC and it was the same functions on your SO3 board that I was suggesting would therefore be superfluous if used with the Soekris R2R DAC, however, my suggestion for using your SO3 in front of the Soekris DAC was specifically in the context of using a Beaglebone Black (BBB) as the transport.

My understanding is that, because of the limitations of the BBB’s onboard clock it will resample all 44.1KHz family data to a 48KHz related rates – this may be audible – and, if the BBB is connected directly to the R2R DAC inputs the DAC will process the data at 48KHz, i.e. it will process the previously compromised data ‘as is’.

I was suggesting the use of an SO3 between the BBB and R2R DAC only as a means of keeping the native sample rates of the data processed through the BBB (in conjunction with the miero driver obviously) - are you saying this is wrong?

Thanks

Ray
  Reply With Quote
Old 28th November 2014, 06:10 PM   #576
diyAudio Member
 
Join Date: Jul 2010
Default Hmmm

Quote:
Originally Posted by StaticNoise View Post
The Xilinx Spartan-6 FPGA in the FTG256 package have system jitter in the range of 200ps and possibly up to 1000ps or more depending on the synthesised code, internal routing and if there are any processes that adds modulated noise to the PSU rails. This jitter adds to any clock jitter and are forwarded to the 595 shift registers that implements the DAC.
A simulation can maybe go as low as 200ps for the FPGA core, but due to the bonding wires, pads and pcb traces and the skew the practical total "jitter" may end up in the ns range.
I think this discussion of internal jitter in a Spartan 6 probably deserves it's own thread, but it is relevant here as well. Static, if what you are suggesting is accurate, how come commercial DACs fully realized via a Spartan 6 actually measure with jitter levels well below what you are suggesting is the theoretical limitation of the FPGA chip? Consider Chord for instance. Perhaps the solution would be to re-clock directly before the D/A conversion via a flip-flop from a direct masterclock feed? But what about DACs where the actual D/A process is internal to the FPGA?
  Reply With Quote
Old 29th November 2014, 03:34 AM   #577
diyAudio Member
 
Join Date: Feb 2005
Location: California
Quote:
Originally Posted by barrows View Post
I think this discussion of internal jitter in a Spartan 6 probably deserves it's own thread, but it is relevant here as well. Static, if what you are suggesting is accurate, how come commercial DACs fully realized via a Spartan 6 actually measure with jitter levels well below what you are suggesting is the theoretical limitation of the FPGA chip? Consider Chord for instance. Perhaps the solution would be to re-clock directly before the D/A conversion via a flip-flop from a direct masterclock feed? But what about DACs where the actual D/A process is internal to the FPGA?
Well that's why I suggested (some pages back) that a simple, high quality flip-flop be inserted right after the FPGA. Such would then leave no doubt about what the final jitter into the R2R network would be. If he needs room, then just move all those FPGA PS pin bypass caps to the bottom side of the board--closely encircling the FPGA where they can do some good--they are too far away now to much anyway.
  Reply With Quote
Old 29th November 2014, 12:17 PM   #578
TNT is offline TNT  Sweden
diyAudio Member
 
Join Date: Apr 2003
Location: Sweden
I attest to the influence of stable clocks close to Fs. Sören, I don't think you will achieve your design goals in terms of SQ if you dont consider the offered insights above...

Reclocking after FPGA and better close in phase noise will probably be needed...

//
  Reply With Quote
Old 29th November 2014, 02:54 PM   #579
esgigt is offline esgigt  Netherlands
diyAudio Member
 
Join Date: Dec 2013
Quote:
Originally Posted by TNT View Post
I attest to the influence of stable clocks close to Fs. Sören, I don't think you will achieve your design goals in terms of SQ if you dont consider the offered insights above...

Reclocking after FPGA and better close in phase noise will probably be needed...

//
Can you tell me if implementing these insights would have big impact on cost?
  Reply With Quote
Old 29th November 2014, 05:55 PM   #580
TNT is offline TNT  Sweden
diyAudio Member
 
Join Date: Apr 2003
Location: Sweden
Flip-flops are cheap, clocks are expensive.... One good 50-500 euro.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
e18 DAC - 8 channels at 32bit /384 kHz exa065 exaDevices 30 29th June 2012 05:11 PM
384 Khz DAC? SunRa Digital Source 8 1st October 2009 11:14 PM
24 bit/192 kHz via USB? gentlevoice Everything Else 3 22nd December 2008 06:24 AM
sign magnitude DAC Bernhard Digital Source 0 30th January 2007 01:40 PM
24 bit / 192 kHz Tube DAC questions Overlord Digital Source 4 29th April 2003 05:14 PM


New To Site? Need Help?

All times are GMT. The time now is 08:47 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Copyright ©1999-2017 diyAudio

Content Relevant URLs by vBSEO 3.3.2
Wiki