On Aug 22, 2007, at 2:28 PM, Dieter wrote:
Very interesting idea. The obvious advantage of FireWire is guaranteed
bandwidth, which would be very nice, and I was not
aware that FW800 supports being run over CAT5e!
More importantly, they claim that
Mar&Long> it can maintain 400 Mbps over 75 meters of cable and
Mar&Long> 200 Mbps up to 100 meters.
1394a is limited to only 5 meters, not even close to long enough.
This is the reason I decided on Ethernet rather than 1394 in the
first place. 1394b's 75 meters would be acceptable. We will need
to confirm this, but it sounds promising. A 1394b solution might
be less expensive than an Ethernet solution.
How does that follow? It uses the same cabling, so that would not
cost less, and I doubt that the interface IC would be less given the
prevalence of 10/100.
The only problem I see is that we won't support ethernet, something
that a lot of people will want.
I assume you can't run both Ethernet and 1394b over the same cable
at the same time. So if you need both, you'd need to run yet another
cable through the walls. And most computers have Ethernet these days,
while 1394a is rare and 1394b is very rare.
Agreed. 1394a is pretty common these days, but as you mention it is not
what we are looking for.
Solution: Have both FW800 and GBE on the board.
A more flexible solution, although it may increase the cost.
It doesn't have to be gigabit, 100 Mbps is enough. (e.g. if a chip
already has 100 Mbps we don't need to add gigabit)
I think that we should not worry too much about FireWire just yet.
There is
no way that ethernet is going away any time soon, and the device would
be much more compatible with it. If we want to support FireWire,
however,
we might want to look into it (I have no sense of the interface, except
that it
allows for dedicated bandwidth, has some extra bandwidth for
non-dedicated
stuff, and provides +18V at an amp or two).
We should not replace 10/100 with FireWire, but if it is financially
viable we
should consider augmenting 10/100 with FireWire.
TCP with some buffer memory works fine.
Yes, it does. Of course, FireWire is more reliable and works better.
We should actually be able to integrate some sort of switch to have
them come out of the same CAT5e/RJ-45 port.
What would be the advantage of doing this?
It would mean only one cable, and possibly reduced cost, but you are
right --
it wasn't a very good idea.
Since there has not been any consensus about what chips we are going
to
use
We have several candidates but very little info on them. I'm
beginning to
fear that the decoder chips have the same problem as the GPU chips, no
documentation available.
Yes, I have been finding that this is true.
I assume the idea is to use a small FPGA to magically offload enough
that
the TI DSP can then do what we need?
Well, kind of. I was thinking, after reading articles of similar
projects, that the
FPGA should play a more active role than we previously planned.
A simple 720p decoder from http://www.ocean-logic.com/downloads.htm
claims to require:
Virtex4-12 4100 slices + 1 multipliers + 21 RAM blocks ~110 MHz
(I am suspicious of the 1 multipliers, for obvious reasons)
The lowest Spartan-3 that meets these requirements is the X3S1000 --
this is close to other sources, so it seems to be reasonable. The other
similar models we could consider are the XC3SD1800A Spartan-3A DSP
or the X3S1200E, the high logic low pin version of the spartan 3.
Looking simply at the 1000/1500 and 1200E/1600E (the 1800A is not
available on digikey), the per unit costs are:
Cheapest = 1200E w/304 IO = $31.70
Most expensive = 1500 w/487 IO = $121 (most IO)
cheapest spartan 3 non-E = 1000 w/173 IO = $46.60
1600E w/250 IO = $50.80
etc
so we are probably going to pay around $50- to get the
processing from an FPGA to implement 720p without a DSP.
Cyclones with the gates/mem needed for 720p in the 200-500 pin range
(there
are many more options, so I had to restrict somewhere), and you get the
cheapest being $46 (315 IO). It is about equivalent to the 1200E, $15
less.
The equivalents of the 1600E are more in the $80-115 range.
(though right now it looks as if Spartan-3/DSP,
Cyclone III, or XP2 is the right family level for FPGAs,
Cost? Power consumption?
Power consumption is harder to measure, but the 1000/1500 list at
around 30-45 mA normal, 200-300 mA worst case (internal supply,
not including I/O).
That is not very good, but not too bad considering you are decoding a
full 720p stream with it...
eek! turns out that is quiescent current, so the actual (using as much
information as I could from that Ocean Logic article) estimate is more
like 600 mA, not including I/O! (700 mW)
That is not _too_ bad, since the ASIC linked to later [1] uses 116 mW
(I don't know what resolution, but it says 40 mW for SD), but is still
a lot.
TMS640C6412 DSP since it is 4000-4800 MACs for $40),
Is this faster or slower than TMS320DM6446 ?
It is in about the same ballpark (the 6446 is 4700 MACs), but the
6446 also has a Coprocessor for the DSP called the VICP (something
Image Coprocessor), which I could not find _any_ (objective) information
on except references to its memory space on the memory map. I imagine,
however, that it would improve the situation (it is said to help
improve color
space transform, etc -- IDCT is NOT listed) and increase speed at least
a
little, if we could get docs.
The 6446 also has a ARM920 on it, which is nice (a more familiar
interface,
at least for me, than the DSP) and would be put to use.
Finally, the 6446 has an "FPGA Interface", which appears to be a
full-duplex
100Mhz 4 bit read, 4 bit write memory mapped interface from the docs -
not
too useful, but it might be all we need.
Oh, and the 6446 costs in the mid-$30s. I say we use that instead :-)
Some useful links I found that attempt to quantify HD AVC:
http://www.cast-inc.com/cores/h264-ld/index.shtml
[1] http://edageek.com/2007/02/19/arc-bdti-h264-decoder-benchmark/
http://www.embedded.com/columns/technicalinsights/197700672?
_requestid=135827
This says that encoding only takes 1.6 billion ops/sec for SDTV on
P3.
Thoughts?
(Sorry about the double send, Dieter.)
_______________________________________________
Open-hardware-ethervideo mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-hardware-ethervideo
