using fpga for sampling audio

The planned architecture:
    telephone line -> ADCs (8k samples pre second)-> FPGA (samples into
ram) -> AXIS controller (with Ethernet)

The goal is to tap several (about 8) telephone channels and convert them
into TCP/IP stream. TCP server will run on Axis controller. I consider to
use FPGA for polling ADCs and storing samples into Block RAM. When FPGA
buffers are say 50% full, the FPGA would interrupt the controller. AXIS runs
at 100MHz. The interrupted controller would address FPGA by address bus and
reads all samples from FPGA memory. I think 1 kbyte sample buffer would be
enaught for an audio channel.

I'm new to this filed and want to ask whether the architecture choosen is
feasible? Which FPGA families suit better for the task?

AXIS is a risk processor; I'm thinking to implement addressing scheme where
there is an address for each audio channel. That is, any two sequential
reads from the same address would read two sequential samples from FPGA. It
it normal solution?

Thanks, any references are highly appretiated!

> The goal is to tap several (about 8) telephone channels and convert them
> into TCP/IP stream.

OK, what about control signal bits? Are you using CAS or CCS? Signalling?
R2? What does your far-end look like? What type of telephone network do you
want to connect to? You may need CCS if your far past the PSTN and in a
private network . Is your box going to appear as an FXS and FXO? If so the
context of the signal bits are different. Your going to need a ring
generator and voltage sources for talk and ring, do you also need cadence
control?

I would strongly suggest you look at some of the third generation
codec/audio processors out there.

Another issue, regarding buffering is echo - the depth of your buffer
affects the impulse response time in an FIR filter. There are Bell Pub.
specs for this. Do you want ADPCM?

I developed an FXS and FXO cards with no processor for a drop/insert  T1/E1
box as well as a broadband wireless network , with just a Spartan XC2S200,
so if you want to go on the cheap (processors take up board space and
silicon) let me know. I can tell you that your going to have to clarify you
requirements a great deal more.

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c0qnad$1ac2h2$1@ID-212430.news.uni-berlin.de...
> The planned architecture:
>     telephone line -> ADCs (8k samples pre second)-> FPGA (samples into
> ram) -> AXIS controller (with Ethernet)

I've never designed telephone stuff, but considering the speeds and speech
quality requirements I think you can get away with a single A/D and an
analog mux at the input. There are some A/D chips with the mux onboard.

> The goal is to tap several (about 8) telephone channels and convert them
> into TCP/IP stream. TCP server will run on Axis controller. I consider to
> use FPGA for polling ADCs and storing samples into Block RAM. When FPGA
> buffers are say 50% full, the FPGA would interrupt the controller. AXIS
runs
> at 100MHz. The interrupted controller would address FPGA by address bus
and
> reads all samples from FPGA memory. I think 1 kbyte sample buffer would be
> enaught for an audio channel.

The things will be a little easier if you use a FIFO structure for storing
your data. Perhaps that's what you actually meant.

> I'm new to this filed and want to ask whether the architecture choosen is
> feasible? Which FPGA families suit better for the task?

If what you describe is the only task for this FPGA, then you can use pretty
much any FPGA, which has enough RAM. I would probably use something like
XC2S50E. On the other hand you could choose Virtex-II Pro and run your TCP
stack on the embedded PowerPC...

/Mikhail
-- 
To reply directly:
matusov at square peg ca
(join the domain name in one word and add a dot before "ca")

Some references...



Scott Keagy, Integrating Voice and data Networks, Cisco Press, 2000



 ANSII / EIA/TIA-464-B-1996, Requirements for Private Branch Exchange (PBX)
Switching Equipment.



AT&T PUB 43801, Digital Channel Bank Requirements and Objectives, 1982







R2 Signalling, in case you're interested:



ITU Q.400, Specifications of Signaling System R2: Definitions and
Functions of Signals - Forward Line Signaling Equipment, 1993



  ITU Q.421, Specifications of Signaling System R2 Line Signaling, Digital



 Version - Digital Line Signaling Code, 1993



ITU Q.422, Specifications of Signaling System R2 Line Signaling, Digital
Version - Clauses for Exchange Line Signaling Equipment, 1993



ITU Q.440, Specifications of Signaling System R2 Inter-register Signaling -
General, 1993



 ITU Q.441, Specifications of Signaling System R2 Inter-register Signaling -
Signaling Code, 1993

On Mon, 16 Feb 2004 11:50:38 -0500, "MM" <mbmsv@yahoo.com> wrote:

>"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
>message news:c0qnad$1ac2h2$1@ID-212430.news.uni-berlin.de...
>> The planned architecture:
>>     telephone line -> ADCs (8k samples pre second)-> FPGA (samples into
>> ram) -> AXIS controller (with Ethernet)
>
>I've never designed telephone stuff, but considering the speeds and speech
>quality requirements I think you can get away with a single A/D and an
>analog mux at the input. There are some A/D chips with the mux onboard.

I'm not sure whether "telephone line" means "globally compliant POTS
line" or "something that will connect to a phone across the office".

If it is the former meaning, it is a requirement to support a number
of different complex termination impedances.  This may be done by
changing analog components in the line hybrid, or it may be
synthesised digitally (by feeding a filtered version of the ADC signal
back to the DAC) with different filter taps for each market.
The latency of the ADC & DAC matters a lot!  This may rule out a
multiplexed approach, and will almost certainly rule out standard "PC"
type codecs (which have large latency).

Note that some customers may expect to be able to connect V.90 type
modems to what is nominally an audio line.  IIRC, this requires at
least 14 bits of accuracy prior to mu/A law companding.

There's a large market for phone line connection devices, so it's not
all that hard to find codecs designed for the task, e.g. AD73322L

Regards,
Allan.

Nice to see someone trying to use an ETRAX. I had a look at your (employers?)
web site and the project looks interesting. Nice move to use the ETRAX MCM.
Should make for a small footprint.

For you others reading this it might be somewhat interesting to have a look at
http://developer.axis.com to see the ETRAX. And no, I do not work for Axis.
(anymore:)

  /Ulf Andersson

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in message
news:c0qnad$1ac2h2$1@ID-212430.news.uni-berlin.de...
> The planned architecture:
>     telephone line -> ADCs (8k samples pre second)-> FPGA (samples into
> ram) -> AXIS controller (with Ethernet)
>
> The goal is to tap several (about 8) telephone channels and convert them
> into TCP/IP stream. TCP server will run on Axis controller. I consider to
> use FPGA for polling ADCs and storing samples into Block RAM. When FPGA
> buffers are say 50% full, the FPGA would interrupt the controller. AXIS runs
> at 100MHz. The interrupted controller would address FPGA by address bus and
> reads all samples from FPGA memory. I think 1 kbyte sample buffer would be
> enaught for an audio channel.
>
> I'm new to this filed and want to ask whether the architecture choosen is
> feasible? Which FPGA families suit better for the task?
>
> AXIS is a risk processor; I'm thinking to implement addressing scheme where
> there is an address for each audio channel. That is, any two sequential
> reads from the same address would read two sequential samples from FPGA. It
> it normal solution?
>
> Thanks, any references are highly appretiated!
>
>

Telephone line is that one where you connect your phone at home and office.
FPGAs require an EEPROM; may be CPLD + dual-port RAM buffer is better for
the 100MHz interface than one FPGA?

> There's a large market for phone line connection devices, so it's not
> all that hard to find codecs designed for the task, e.g. AD73322L

What is analog front-end? The datasheet gives idea, this is ADC/DAC device
with capability of mixing input and output audio. Datasheet states it can be
used in telephony applications indeed. Does it mean the chip can be used as
hybrid function (DAA) directly connecting to telephone line Tip and Ring
wires? Do we still need PLD to tranfer data to a powerful system for storing
or TCP/IP conversion? Thanks.

On Tue, 17 Feb 2004 11:26:05 +0200, "valentin tihomirov"
<valentin_NOSPAM_NOWORMS@abelectron.com> wrote:

>FPGAs require an EEPROM; may be CPLD + dual-port RAM buffer is better for
>the 100MHz interface than one FPGA?

You have 2Mbyte of Flash on the AXIS controller (if it's the one I
think it is), and that can be used to hold a compressed FPGA image
along with your software.
I expect the solution involving the FPGA will be cheaper than the one
involving the CPLD.

Regards,
Allan.

On Tue, 17 Feb 2004 12:01:49 +0200, "valentin tihomirov"
<valentin_NOSPAM_NOWORMS@abelectron.com> wrote:

>
>> There's a large market for phone line connection devices, so it's not
>> all that hard to find codecs designed for the task, e.g. AD73322L
>
>What is analog front-end? The datasheet gives idea, this is ADC/DAC device
>with capability of mixing input and output audio. Datasheet states it can be
>used in telephony applications indeed. Does it mean the chip can be used as
>hybrid function (DAA) directly connecting to telephone line Tip and Ring
>wires? Do we still need PLD to tranfer data to a powerful system for storing
>or TCP/IP conversion? Thanks.

In another post, you said:
> Telephone line is that one where you connect your phone at home and office.

Does this mean that you are trying to mimic a telephone, or a
telephone exchange?  The requirements are very different.

You mention DAA, which implies that you are trying to mimic a
telephone, but I suspect that you really meant SLIC, which is the
interface to a phone line inside a phone exchange (or PABX, etc.).

BTW, all of this is off-topic for comp.arch.fpga

Regards,
Allan.