I2S transcoder
Posted 7th July 2013 at 12:57 PM by abraxalito
Updated 16th September 2013 at 01:32 AM by abraxalito (Schematics added, pic of 2nd build added)
Updated 16th September 2013 at 01:32 AM by abraxalito (Schematics added, pic of 2nd build added)
Here's a circuit that's been a long time in gestation - some logic that converts I2S from 64fs (32bits per sample) down to 32fs (16bits).
Almost all the S/PDIF receiver chips nowadays output a bit clock at 64fs (2.8MHz for RBCD) because the format has the potential to support up to 24bits. When being driven from a CD player though, there's no chance of any useful information occupying those spare bits. As my interest is to run all signals as slow as possible to keep noise to the absolute minimum, 64fs to me is profligate generation of RF when 32fs will do the job. But only the WM8805 supports this format and then only when software programmed.
The other reason for wanting the slower bit clock is that my LAID design relies on shift registers and the 32fs clock gives me twice as good utilization of the serial storage - no bits are being wasted on zero padding.
This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1. The 'traditional' way to implement such a design would be via serial-parallel and then parallel-serial conversion at half the original clock speed but the number of chips needed to go this route would be higher, mainly because latency is being introduced in the conversion to parallel, latency means storage and storage means chips. Here I present a way of doing this 'on-the-fly' with reduced complexity owing to the omission of any conversion to parallel. If for any reason you're concerned about latency (I'm not), then I reckon this is the lowest latency solution
The central core is 16 bits of shift register (two HC595s) with outputs tapped off into an 8-way mux (HC4051). 5bits of counter (HC161 plus a f/f) keep the mux and other logic sync'd to the incoming audio and increase the operative delay on a clock-by-clock basis. The result is a 'time stretching' function on the incoming datastream
Initial listening tests into a TDA1387 DAC give a more involving sound than when fed with 64fs but I'm blowed if I can put my finger on what the differences are. Needless to say I'm not going to feed any 16bit DACs in future with 64fs
Schematic notes......
IC list 74HC595 * 2; 74HC161; 74HC4051; 74HC86; 74HC04; 74HC74 * 2
For clarity, not all pins are shown. HC74 set/reset (1,4,10 & 13) to logic 1 when not shown. Preset pins on HC161 (3-6) are don't care, enables (7,9 & 10) to logic 1. HC595 MRs (10) to logic1. Unused inputs on logic gates should be tied to 0 or 1.
Update - I've added a photo of the 2nd build - here I've modified the design very slightly to accomodate the EIAJ serial format used by the TDA1545A. One HC74 has been replaced by an HC175 giving the extra cycle of delay to WS. I've also added an HC86 as a buffer stage, so the total's now 9 chips.
Incidentally I just used the SDcard player as a test bed for verifying its operation - I haven't noticed any SQ changes in driving the TDA1543. Recommended for CMOS DACs only
Almost all the S/PDIF receiver chips nowadays output a bit clock at 64fs (2.8MHz for RBCD) because the format has the potential to support up to 24bits. When being driven from a CD player though, there's no chance of any useful information occupying those spare bits. As my interest is to run all signals as slow as possible to keep noise to the absolute minimum, 64fs to me is profligate generation of RF when 32fs will do the job. But only the WM8805 supports this format and then only when software programmed.
The other reason for wanting the slower bit clock is that my LAID design relies on shift registers and the 32fs clock gives me twice as good utilization of the serial storage - no bits are being wasted on zero padding.
This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1. The 'traditional' way to implement such a design would be via serial-parallel and then parallel-serial conversion at half the original clock speed but the number of chips needed to go this route would be higher, mainly because latency is being introduced in the conversion to parallel, latency means storage and storage means chips. Here I present a way of doing this 'on-the-fly' with reduced complexity owing to the omission of any conversion to parallel. If for any reason you're concerned about latency (I'm not), then I reckon this is the lowest latency solution
The central core is 16 bits of shift register (two HC595s) with outputs tapped off into an 8-way mux (HC4051). 5bits of counter (HC161 plus a f/f) keep the mux and other logic sync'd to the incoming audio and increase the operative delay on a clock-by-clock basis. The result is a 'time stretching' function on the incoming datastream
Initial listening tests into a TDA1387 DAC give a more involving sound than when fed with 64fs but I'm blowed if I can put my finger on what the differences are. Needless to say I'm not going to feed any 16bit DACs in future with 64fs
Schematic notes......
IC list 74HC595 * 2; 74HC161; 74HC4051; 74HC86; 74HC04; 74HC74 * 2
For clarity, not all pins are shown. HC74 set/reset (1,4,10 & 13) to logic 1 when not shown. Preset pins on HC161 (3-6) are don't care, enables (7,9 & 10) to logic 1. HC595 MRs (10) to logic1. Unused inputs on logic gates should be tied to 0 or 1.
Update - I've added a photo of the 2nd build - here I've modified the design very slightly to accomodate the EIAJ serial format used by the TDA1545A. One HC74 has been replaced by an HC175 giving the extra cycle of delay to WS. I've also added an HC86 as a buffer stage, so the total's now 9 chips.
Incidentally I just used the SDcard player as a test bed for verifying its operation - I haven't noticed any SQ changes in driving the TDA1543. Recommended for CMOS DACs only
Total Comments 28
Comments
-
I made chip count a priority because I took your boast, “This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1.” as a challenge. While I reduced the chip count, I did not neglect proper clocked circuit design rules. With fewer chips there are shorter PCB traces and fewer power-hungry output gates. That means less power consumed and less noise created. Count the output pins that change state with each clock: That’s the biggest source of noise.
I was afraid you’d be unable or unwilling to understand an alternative way of looking at a circuit. Like most engineers you appear to be locked into the schematic view of the world. Schematics are inadequate for digital circuits. There is no value to the pictorial representation. Most of the symbols are rectangles. The only difference between a DAC, microprocessor, counter, and shift register is the number of pins. Unless you are familiar with the signal names and function of the chip, you must refer to the datasheet to know what the component does. The time spent creating a pretty schematic layout is wasted because the schematic layout is rarely transferable to the PCB layout. And, most importantly, the lines that connect one pin to another are missing a very important dimension: Time. I think that’s why you think you can latch a data bit any time you want and the value latched will always be what you think it should be.
I don’t use schematics. I use software that converts the information from the annotated timing diagram into a BoM, net-load analysis, and two net lists; one to aid the point-to-point wiring of a perf-board circuit and another formatted for my preferred PCB layout program.
Just for you, I created a schematic of the latest four-chip, all CMOS version of my transcoder.
Posted 23rd September 2013 at 11:02 PM by Tam Lin
-
Thanks for your schematic, and also your perception of the way I do ciruit design. Wrong on practically every remark you made - which of course raises a chuckle.
Firstly its not a boast to minimize the chip count, as you claim, rather an aim. Secondly your remarks about power consumed only apply to CMOS not to your choice of ALS. With ALS the static power is considerable even with no clock applied, and that was your choice. Lastly your estimation of my 'being locked into the schematic view of the world' is pure fantasy. I only tend to draw schematics when communicating the circuits to others.
Since you've now presented a low enough power design to be interesting, I'll take a look.Posted 24th September 2013 at 01:31 PM by abraxalito
-
On examining this, it gets an unequivocal thumbs down. I'll not waste my breath explaining why as my earlier remarks seem to have gone unheeded. Rather I'll just leave you a couple of words as a hint - matchstick, chainsaw.
I'll look into the HC590 as a replacement for the HC161 though in my own design.Posted 25th September 2013 at 06:28 AM by abraxalito
-
Postscript:
You say you are concerned about circuit noise but I don’t see that concern reflected in your work. For example, in an earlier blog you show a project using 16 shift registers with 142 output pins needlessly flip-flopping with every clock. At the time you dismissed my suggestion to use a HC7731 instead because of cost. Doesn’t a single HC7731 use less power, need fewer bypass caps, create less noise, and occupy less board space with fewer solder pads than 16 HC595? Isn’t one chip easier to solder and later unsolder for reuse than 16? Isn’t that worth $1, which is about what the price differential is today?
You began this blog with a lecture on why the traditional shift register transcoding method is bad because it uses storage and storage is bad. What about all the HC595s used in your designs? Each bit is clocked and stored twice; once in the shift register and again in the latch. In most cases the stored bit is never used.
Your transcoder has latency and, as you say, latency is bad. Maybe if you spent a little time looking at timing diagrams you could see how the latency can be avoided. Here is a timing diagram of a transcoder using shift registers similar to your approach. It uses 6 chips and has zero latency. Oh yes, it doesn’t need five inverters in a row to correct a design error and it doesn’t latch the data bits when they a likely to be unstable. The two extra vertical lines, labeled ‘A’ and ‘B’, highlight the relationship between the data bits and the clocks that latch them. The diagram is not annotated because annotating takes time and I doubt you will look at it, anyway.
Posted 25th September 2013 at 09:29 PM by Tam Lin
-
You just don't get it do you? No matter how many times I explain your misunderstandings of what I write, you simply will not listen.
Here's a thought though - you might put your design skills to good use in the service of this guy who says he knows nothing about logic design ; https://www.diyaudio.com/forums/digit...ml#post3644464Posted 25th September 2013 at 10:41 PM by abraxalito
Updated 25th September 2013 at 10:57 PM by abraxalito -
What a surprise. Your transcoder gives different results with different I2S sources. That’s exactly what I predicted.
Do you expect me to take your critique seriously? You don’t even know how to latch a bit in a serial data stream! Maybe you should look again at the designs I presented and study my design methods to learn something instead of scoffing because they don’t meet your warped ideals.
The design process is the same regardless of the logic family used. My goal was minimum chip count because you mention that ideal numerous times in your blogs. ALS won the first round because it has higher ‘functional density’ and that simplifies the process. (I study changes in ‘functional density’ across different technologies through history.) I applied what I learned from the ALS version to improve the CMOS version. For me it was an exercise. Exercising my brain to solve a new problem and looking through the parts catalog getting acquainted with different logic chips. That’s something you don’t do, otherwise you’d be familiar with the HC590 and the other CMOS synchronous counters. Each has different characteristics that can be exploited in the proper design context. Like most engineers, you have a very small bag of tricks. The only counter you know is the ‘161 and your favorite shift register is the ‘595; both of which you misuse over and over again.
I hoped you would learn something from this exchange but apparently not. Like most diyAudio big shots, you think you know it all. Your data bit latching goof puts you in the top ten Stupid Logic Tricks but you are outclassed by ecdesigns who has the first five places. Keep trying. I look forward to you next attempt.
Actually, the need for an I2S transcoder the remove unnecessary padding bits is stupid. Philips created the I2S protocol to eliminate the need for the source and destination of the sample data stream to agree on the frame size. Read the spec. Any I2S transmitter that uses a fixed frame size and either inserts pad bits or truncates sample bits is broken. Any I2S receiver that depends on a fixed frame size is broken. That’s just one of the reasons I don’t like I2S.Posted 26th September 2013 at 03:12 PM by Tam Lin
-
Thanks, that's some of the best irony I've read in quite a whilePosted 26th September 2013 at 11:04 PM by abraxalito
-
Apropo this latest discussion, savvy readers might be interested in this article - about digitization helping in the design of automobiles : General Motors is literally tearing its competition to bits | Ars Technica
The key take-away for me here:
The first vehicle to come fully from the new digitally driven engineering process was the 2003 Chevrolet SSR roadster-pickup truck. It went straight from the digital drawing board (a surface model in Alias StudioTools, now Autodesk Alias) to fabrication as a prototype for the 2000 Detroit Auto Show floor. Only 60 full prototypes were built before it started coming off the assembly line at GM's Lansing Craft Centre in September 2002.
and:
Despite the innovations behind the SSR a decade ago, it wasn't the car GM needed at the time. Its timing was awful, arriving a year after the 9/11 attacks in the midst of throttled-back expectations and ballooning gas prices. After the initial excitement in its first limited model year, sales tanked in 2004. Only 9,000 were sold and nearly another 9,000 remained in inventory. In 2005, GM announced it would be closing the Lansing Craft Centre and shutting down the SSR's production. The company booked a $10 billion loss.
Update - a couple more book recommendations along the lines of the earlier one - Roger Martin's 'The Opposable Mind' and 'Design of Business' look to be excellent though I've read neither. Just going on the Amazon blurb and feedback. One book I have read, many years back 'The Mind of the Strategist' by Ohmae is recommended for laying out how analytical thinking doesn't cut it.
Here's a clip from one of the reviews of 'Opposable Mind' that for me nicely sums up how to approach these issues of design. Here the subject being spoken of is the habit of Abraham Lincoln and his associates to...
"face constructively the tension of opposing ideas and, instead of choosing one at the expense of the other, generate a creative resolution of the tension [whatever its causes may be] in the form of a new idea that contains elements of the opposing ideas but is superior to each."
This seems to me to be a neat summary of why true design is not about compromise, which would be something at the expense of something else.
Here's another (wonderful, as Glen's an excellent engineer for getting the design right) example of what happens when a particular metric becomes a target - An experimental 4-th order linear audio power amplifier - Page 1
Its the ultimate low-THD amplifier, with zero concern for how it'll perform in a real system, playing real music with a real speaker load My guess is he's sold the rights to Silicon Chip magazine which wants the kudos of publishing the lowest ever THD amp for DIYers to build.Posted 28th September 2013 at 01:53 AM by abraxalito
Updated 11th October 2013 at 03:10 AM by abraxalito
