15 Dec
2004
15 Dec
'04
5:59 p.m.
On 15 Dec 2004 13:03:24 -0800, Fernando Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
OK, so as I see it we have a few choices:
(Internal)
- PCI
(External)
- PCI - Carbus variant - some physical interface to the box
- USB 2.0 (480Mb/S)
- 1394a (400Mb/S)
- 1394b (800+Mb/S)
Doing this
as a 1394-based external unit is really interesting, but
is more complicated. Maybe PCI is the best for now.
I'm not so sure PCI would be the best answer for a project like this
one, and that was the point of the question. I would be concerned about
the tools. Xilinx arrays will probably need closed source and expensive
software.
Possibly. I'm not sure yet, but it's a very valid concern. If we were
concerned about this then we should investigate other FPGA vendors
(Altera, Lattice & others) to see if it's the same story. I don't
know. I did a quick search in Google's Advance page for
Xilinx
Open Source Tools
and found a large number of pages talking about this stuff. It may not
be as bad as we are worrying about. I'll check more later.
What I was thinking about was this:
- 1394 chip (off the shelf, no programming)
not true exactly. more in a minute.
- (high speed?) ucontroller (off the shelf, use one
that has open
source tools for programming it).
Yes.
- line drivers for spdif and/or ADAT (driven from the
ucontroller)
Yes.
- DA/AD chips (driven from the ucontroller)
If we go with local conversion. More noise issues, etc., but
manageable if we want to deal with it. Probably this ends up with a
lower cost for a 2-4 I/O sound card, but for higher port count it will
get ore expensive and I don't think we add much value doing that part.
You used to be able to buy an AI-3 on EBay for around $200 IIRC. Right
now there are none so maybe all of those are gone and we need to find
acceptable external conversion units in different price ranges.
So, this approach would reduce the problem to hardware interconnection
of logic parts (rather easy) and firmware for the ucontroller (hard).
OK, this is where I think it gets difficult. I'll give some overview
ideas and then we can go from there.
Asynchronous 1394 is a 'memory mapped' packet. The packets are
addressed to a specific device on the bus (Bus #, ID #) and then they
carry an address. The 1394 model assumes that the packet is delivered
to memory in the remote device and then the remote device does with it
what it wants to do with it. If you delve a bit deeper into the
hardware behind this idea what you eventually run into is that the
1394 controller has/needs a DMA unit and the box has memory. The 1394
chip delivers the packet to memory and then the uC deals with it when
it can. This is generally needed since the uC cannot respond fast
enough to keep up with all the packets. This is the basic idea behind
a 1394 OHCI controller. All the processor is doing is setting up a
linked list of memory addresses. The OHCI controller is accessing that
list, using the address in the DMA controller, and moving data in and
out of memory. It works fine except it assumes an OHCI stack (implying
at least part of an OS) and it assumes memory. Both of these are
expensive in different ways when you talk about high speed data
packets and personally I'd rather avoid it. However I cannot
completely ignore Async operation as it's required to be recognized on
the bus.
On the other hand, Isochronous 1394 just delivers data on a channel.
There is a destination address again, but it's just a channel number.
(0-63, 63 being broadcast) Any device that wants the data just watches
for packets with the right channel number, chunks it into a FIFO and
uses it for whatever purpose. If data is missing then you get a
crackle, snap or pop. However there is no real processor intervention
(or doesn't technically have to be) with the data. Conceptually it
could just arrive as a serial bit stream, be reformatted by some
simple hardware machine into 24-bit parallel data, and be delivered to
the D/A and you get sound. It could also be reformatted and delivered
to s/pdif or ADAT and sent on again.
The CPU overhead with Iso 1394 is basically very low which is why it
works for video, etc.
So, I guess the point here is that making a complete, 1394-based
device is fairly difficult and possibly a bit more expensive than
doing something in an FPGA. There are 1394 devices that are uC-based
but I don't know if they are supported by Open Source tools.
The other thing is that, again, as FPGAs improve you get more
functionality over time and can add more capability to the boards.
(Ala Creamware, etc.) Personally I like that idea even if it costs me
a bit more, but I'm not making the final decision here. It's
completely open. What I can *possibly* do it try to work out some part
costs.
I think this would, like all other projects, require a web site to
post ideas, drawings, schematics, etc. How would we do that?
Sourceforge? Somewhere else? I can draw system diagrams very quickly
but they need to be posted somewhere for others to look at and vote
on.
The question would be, it this doable with available ucontrollers that
have open source compiler toolchains?
Dunno. We could leverage the Linux 1394 stack and try to do this with
a uC and an OHCI controller. If it's not OHCI then the Linux stack
does us very little good.
Via and others make peripheral oriented 1394 chips. They get used in
many embedded devices and are probably about right for this sort of
project. I could look into that over the next few weeks. Good project
when sitting in front of the TV late at night. After we find a few
we'd have to cross reference against Open Source tools. That would
take some help from others.
And we haven't discussed it, but maybe there are completely different
architectural ideas we should look at. For instance, what about a
device that ONLY worked with Jack? I have a suspicion that this might
be interesting and less expensive, but that's just a guess right now.
Would be sort of cool to make a card that DIDN'T work with Windows.
;-)
- Mark