On 15 Dec 2004 13:03:24 -0800, Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> wrote: > > 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. 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) > 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
