CPLD, wireless digital audio...

[Buriedcode]

cs4340 project

Hi, I posted a similar question in the DSP forum, probably the wrong place to post it, no-one replied

Well, I have designed a system to convert an audio signal into digita, send this across some sort of wireless link (radio, IR etc..) and then convert it back to analogue. Forward error correction is also implemented.

The system is built, put on boards and all chips have been programmed.
Doesn't work at all.

There are several areas which could be at fault, but I'm sure its either:
The ADC/DAC, or the CPLD's. I'm using Lattices MACH4A5, a 64/32 for the transmitter, and a 32/32 +64/32 at the receiver (a whole CPLD was needed to decode the stream).
As far as conversion goes, using the CS5330A, and its sister chip the CS4330A, both being stereo sigma-delta convertors.

Could the problem be hardware? I've got both boards running from little 5V 100ma regulators, so on the Tx, this must power the CPLD, the ADC and some small analogue stuff. But....on the Rx, 100ma has to power 2 CPLD's as well as the DAC and opamp etc..

Could it be the clocks? I'm using a C-MAC crystal oscillator 12.288Mhz which is connected directly to the CPLD (via internal clock buffer) for both the Tx and the Rx. It's meant to be very accurate with low jitter, but I measured the output at about 9v p-p 8O

I'm confident that these CPLD's can easily do the job of controlling the ADC/DAC, but maybe my design is having trouble in the 'communication' department :roll: The datarate from Tx to Rx is 1.5MB/s. For testing purposes, this is simply a connection from a CPLD pin on the Tx board to a CPLD pin on the Rx board, and then a ground return.

Lastly, the code. I used schematics and ABEL code, which were then connected in a toplevel schematic for each CPLD. It's quite simple. The Tx CPLD reads the ADC data, splits it into 2 bytes, then encodes each byte using hamming coding. These 2 bytes (now 13 bits each) are transmitted each with a start bit, and a stop bit. The Rx simply reads in the bit stream, decodes and merges the two bytes back into a 16-bit word, then writes this to the DAC.
In simulation (lattice) it looks pretty much perfect, with everything well timed and insignificant propegation delay, but alas, the only thing coming out the DAC is very quiet noise (its getting the right control signals, just not the data)

I realise its a lot of information, but I could go on for days, so if anyone has any suggestions of what may be screwing this thing up. Or any ways of circuit debugging that could help me narrow down the problem I would be grateful, I can't sleep untill this is done. (its not important, it just bugs me :evil: ).

Thankyou,

BuriedCode.

 

[dll_embed]

cpld sound

To narrow down your problem, it's better to test your system block by block. I would like to suggest you to test the wireless link and baseband seperately. As you have simulated the design, to make sure the audio-ad-digital transmitter- digital receiver-da-audio link works fine should not be so difficult for you. Then we've to make sure the quality of the wireless link is enough to support your application. Measure the BER and bandwidth to confirm that.

regards

 

[martin]

bypass cpld

Hi,

I try to give some simple suggestions, maybe you already know that:

1. Make sure the CS5333/CS4340 are configured in the right way. This means you should check if the settings for both ADC/DAC ("sample rate", "digital interface format", "clock mode" ...etc) are correct. For example, a 47k ohm pull-up resister on pin1 (SDATA) will force CS5333x into master mode after power-up and a stable SCLK signal will force CS4340 into external clock mode after reset pin goes high.

2. Make sure your ADC/DAC works fine. For example, just connect ADC to DAC (bypass CPLD), input a tone signal to ADC and check the output from DAC to see if the result is correct.

3. If both of ADC and DAC work fine, the problem is "CPLD" !!

4. If current consumption is a possible problem, use power supply to test.

 

[Buriedcode]

cpld spdif transmitter

Thankyou both for your replies, it always good to receive helpful information

Originally I experimented with SAR convertors, and I did exactly what Martin suggested simply connecting the ADC to the DAC directly and used a PIC micro to control them, this worked a treat :wink: but the SAR ADC needed a very complex (13-pole) filter for antialiansing which is why I used the Sigma-delta convertors.

By the way, I still have no wireless link, I can worry about that later, for now I just want the Tx and Rx (baseband) to work when connected to eachother.

Both the ADC and DAC are operated in SLAVE mode, no 47R resister needed for that I believe. I'm working with SLAVE mode because then I can have 48 SCLK's per FSCLK (24 per channel), allowing the output of the transmitter to be syncronous with the ADC, because the output packet is exactly 48 bits in length. Maybe I could try using MASTER mode, which has 64 SCLK's per sample, that way I can divide SCLK by 2 and have 32 bits in the output packet. This gives me less room to work with (error correction takes up 10 bits) but will probably make the system more reliable.

To narrow down your problem, it's better to test your system block by block

well, the Tx has a Statemachine and a couple of couters as well as shiftregisters, Each block was created individually and then the whole was put together, debugged, and in *simulation* at least, it looks perfect.

As for the Rx, this could be my problem, it gets a bit tricky.......

Looking at the datasheets for the ADC and the DAC, its a bit more complicated to control these rather than a standard mono SAR convertor.
Both the ADC and DAC are STEREO, however, I only need one channel, so all I'm doing is writing data once every FSCLK.

The ADC is easy, the left channel can be read in the first 18 SCLK's when FSCLK is high, the right channel does not need to be read at all and is ignored. I think I'll forget about the Tx for now, as I think its working properly.


Right, the DAC at the reciever also needs SCLK, FSCLK, and MCLK, using the exact same control signals as the ADC. But...in my system, the FSCLK is controlled by a counter (0 to 47, when it reaches 23 FSCLK is flipped) and this counter is itself controlled by the incoming data. So..if the receiver is not connected to the transmitter, it will not write anything to the DAC, it won't even provide a FSLCK. This is intentional 8)

Do you think it would be wise to use FIFO buffers? This means that no matter what, the receiver will always provide SCLK, FSCLK and MCLK to the DAC whatever the situation, and data can be read in anytime (given the proper preamble) stored in a FIFO, and then written to the DAC when the data should be written (6 SCLK's after FSCLK changes, right-justified).

If someone could point me in the right direction with regards to Synchronous communication I would be grateful. I don't know why but it seems my system isn't quite 'solid' enough as most standards. And no it appears I've confused myself :? I don't even know what I'm asking anymore.

Dazed and confused,

BuriedCode

 

[martin]

Do you think it would be wise to use FIFO buffers? This means that no matter what, the receiver will always provide SCLK, FSCLK and MCLK to the DAC whatever the situation, and data can be read in anytime (given the proper preamble) stored in a FIFO, and then written to the DAC when the data should be written (6 SCLK's after FSCLK changes, right-justified).

For CS4340, while power-up, reset or incorrect clocks, the mute control pin (pin 16) goes high. This could be a way to check if the data sent from CPLD to DAC is correct.
In my opinoin, MCLK, SCLK, FSCLK should always be stable. All you need to do is keep the correct output sound and mute the un-wanted!. Some DAC has a input pin to mute itself but CS4340 has a mute output for external circuit. In wireless communication, receiver should be quiet if the transmitter is not present. The baseband processor should have known that and make the right control of the output sound.
When testing a stereo DAC but only a single chanel is needed, I'll often let controller send the same data to both L/R channel to make a "complete format".
I had been working on a similar project as you did. Sometimes a troublesome problem is made by a very simple mistake. I'm not good enough to solve your problem but only some suggestions!

regards,
martin

 

[eltonjohn]

RF + a buch of other stuff?? ....uhmmm
You know before you get into the RF stuff be shure that all works .,.RF is an ALIEN thing .. something like talking with spirits ..ANYBODY COULD DROP BY !

I think that you should connect all without the RF link at first to be shure that all works in standard conditions .. Then move to the RF .. The way you designed this things using PLDs leads me to believe that your protocol is not very RELIABLE !.. ..

sometimes things in the DESIGN WORLD ( the brain !) work marvelous ,But in the real world they perform very poorly .So you have to come back to the drawing board and add BORING STUFF!

that's life !

CHEERS

 

[Buriedcode]

Hi people, thanks for your comments

I didn't realise elton john was into electronics, no doubt he'll release a single soon entitled 'FPGA in the wind'

Well, you're right of course, I'm not even gonna touch any RF until the baseband works and is reliable, I can worry about interfacing with RF later as well. So the will no be RF questions from me.

However, I redesigned my project slightly, it is still based on S/PDIF with a little variation.

The data sent is a 48-bit packet which is manchester encoded (preamble 'n' all), I went for manchester encoding because, to me at least, it just seems a better idea, since data is sent at regular intevals, hence its completely synchronous (isynchronous?). Its a pretty simple setup.
8 bits preamble. 26 bits data (16 bits audio, 10 bits error correction) and some tail bits. 48 bits is the number because that means that the data output can be in sync with SCLK, making it easier to control with a statemachine.

Now, the crunch....

sometimes things in the DESIGN WORLD ( the brain !) work marvelous ,But in the real world they perform very poorly .So you have to come back to the drawing board and add BORING STUFF!

Damn right, I'll be the first to agree, theory and practicality are two different things. But, I've got the toplevel schematic for bith the TX and RX and stuck them both on another schematic, so basically I could simulate the entire system under 'ideal' conditions, and it worked like a charm. I even added a small block which randomly made errors in the data every 100 bits or so, the receiver corrected every one. Remeber thats 'ideal' condidtions. When it comes to testing it practically, its screwed. Ok, for now I'm ignoring the ADC and DAC interfaces and just concetrating on the serial link between the two CPLD's, because the statemachine in the receiver should go through all its states 'if' it gets the right preamble, once it has this, its designed to just go through the program, regardless of whether any real data is present. But when I connect them with just a couple of wires (data and GND) the receiver doesn't get more than 3 bits into the preamble before reseting, which means its not getting the right data. (tested by checking the state machine registers which I put on pins to test)

Is this a hardware problem ??! The datarate is 1.536MB/s, with machester encoding (basically 3.072MB/s), thats alot of bandwidth, (1.5Mhz) so I'm thinking that the two wires, which are croc-clips connecting the Tx and Rx are just not good for this datarate.

I've tried routing the signal through a 74HC244 buffer, just incase its an 'analogue' problem but alas, still nothing. And I don't own any line transformers that are sometimes used in S/PDIF.
Any suggestions for a simple, reliable link between the Tx and Rx for testing would be appreciated.

I really don't thing its my CPLD design, since the manchester encoder/decoder are quite reliable in simulation, but I've never tested something in hardware that runs at such a high datarate.

Regards,

BuriedC+ode