spdif conversion

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Re: Re: spdif conversion

Jocko Homo said:
I saw inside the Theta prototype. You don't want to know how much stuff was inside. Some of it was probably gate arrays of some sort, as not all of the chips were 14/16 DIP.

Jocko


rfbrw said:



It can be done but why would you want to?


I just wanna know if somebody has done that, and i wanna try it too.

I got interest on this when i saw the innards of a theta pearl cdp from a friend. but i can't scrutinize it coz its not mine. it has a data and mclock input taken from a decoder board and output to spdif coax and balance.
its different from other converters because it uses only two input, data and mclock, unlike others with sdata, lrck and mclk, and it uses logic ICs. its pcb is 3" x 5" approx.
 
Re: Re: Re: spdif conversion

jondavis said:






I just wanna know if somebody has done that, and i wanna try it too.

I got interest on this when i saw the innards of a theta pearl cdp from a friend. but i can't scrutinize it coz its not mine. it has a data and mclock input taken from a decoder board and output to spdif coax and balance.
its different from other converters because it uses only two input, data and mclock, unlike others with sdata, lrck and mclk, and it uses logic ICs. its pcb is 3" x 5" approx.


In this case you have a transmitter that only has to support a single data rate and need not concern itself with user data and other such flummery. This makes things considerably simpler.
 
I worked on this very implementation in 1996 and submitted my findings to Electronics World which was published in June of 1997

The basic idea is to extract LRCK BitClOCK and DATA feed them
individually into 74AC74 flipflops from a CD player
You then need to buffer those signals enabling 75 ohm
transfer using a Maxim Max 497. Then at reception the DAC
end the aforementioned signals feed 74AC74 devices again
the advantage here is that differnt clock speeds can be accomodated relative to the ics at each end.ie you can tailor
clock speed for the DF1700 or equivalent., leaving the players
MCK to feed the transmission end flip flops.

There is as a result of this no CS8412 or other SPDIF
multiplexing ic. The only downside i can see is that
the player and DAC are tied together - there is no
convenient way of changing this DAC for another.
But there is no need in any case.

Cheers / Chris
 
Thanks Chris 719
We may need to ask jondavis
why would you need to fabricate
an SPDIF multiplex when transfer
of BCK DATA and LRCK
can be achieved more simply.

To help with the thread starters question
if you actually need to construct this you would need
to carefully study Sony and Phillips data to guage
the extent of what you are entering into

Taking this light heartedly .........
Carefully invite their executives to dinner
to plan the circuits construction. Invite James Bond
or Lara Croft along too ,to get all the after hours
details.

I personally dont think you would ever get to the
end of it, such a circuit breadboarded may well be of such
a size that you may have to ask your neighbour
to move out.

Cheers / Chris
;)
 
Hello!

Has anybody successfully implemented the cores from opencores.org?
As my FPGA experience with bigger designs is still limited I would be interested in some hints from experts, just to find a starting point for my work and estimate the necessary effort.

Apart from this, are there any further vendors of IP-cores for digital audio on FPGA beside coreworks.pt?

Any hints would be greatly appreciated!
Holger
 
Hello bitrate,
thank you for your hint with edaboard.com, at first sight it seems quite interesting, I'll have a closer look at it tomorrow. c.a.fpga is already known.

My project should run on a Xilinx Spartan3 starter board with a XC3S200.
The need for a controller makes this project even more complex, it seems like taking the commercial core is the only realistic option for me at the moment.

Cheers,
Holger
 
hwb said:
Hello!

Has anybody successfully implemented the cores from opencores.org?
As my FPGA experience with bigger designs is still limited I would be interested in some hints from experts, just to find a starting point for my work and estimate the necessary effort.

Apart from this, are there any further vendors of IP-cores for digital audio on FPGA beside coreworks.pt?

Any hints would be greatly appreciated!
Holger


I would have thought knowing how a SPDIF encoder or decoder works would give a far better clue as to what level of effort or size of device is required.
 
I have read Your message on comp.arch.fpga and I know that You want to build receiver so there is at least one more reason why these cores are unsuitable for You :there are both bidirectional and lot of logic on FPGA never were to used.You may try to rebuild these cores to meet Your specific needs but it will be hard work in my opinion , every HDL coder has his own style of programming and it is in detail sometimes hard to trace all.
 
@rfbrw

I've done enough research to know how SPDIF receivers work, but I'd like to hear some statements from others before going in a certain direction. This is no hobby work but a project which hast to be done in a given time, so experiences from others will help me to plan my work.
Apart from a good clock recovery I see no major problem in coding the receiver myself, it's just a question of time.


@bitrate
As I said, the need for some kind of controller, either externally or as a soft core on the FPGA, is too much for the moment. I'll evaluate the commercial core first, if there's time left, I'll have another look at opencores.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.