[linux-dvb] [RFC] Should a DVB frontend report the board name?
abraham.manu at gmail.com
Wed Feb 7 06:55:25 CET 2007
On 2/7/07, CityK <CityK at rogers.com> wrote:
> I don't want to derail the underlying discussion at hand (although it
> strikes me as not everyone talking about the same thing), but I do want
> to just pick up on a particular point:
> Manu Abraham wrote:
> > for the average person, frontend = RF module, inclusive of the demod
> And if that is what the average person believes, then they would indeed
> be correct. (Although I have serious doubts that the average person
> knows what a frontend is ;) )
> A Frontend is just an abstraction. In some cases a frontend can be
> described entirely by a NIM/RF module such as the LGH06xF (which is
> inclusive of the demodulator) or, in the case of older designs like the
> pcHDTV HD-2000 or DVICO FusionHDTV3 series, both the RF module AND the
> external demodulator comprise the frontend.
There are different cases, for example
* a complete tuner is never in one chip, unless it is a silicon tuner
* a silicon tuner and a demod is never in one chip, unless it is a
Direct Conversion receiver, similar to the Superhet radio's, no
Intermediate Frequencies in such a case.
when you have a device implemented in silicon and the integration is
high, similarly to your integration constant "C" the greater the
integration, the greater the "noise floor".
when you have a demod, these days many demods are implemented on a
FPGA . In such cases the operational noise is too high for the analog
core to be very near the digital core.
In any RF design, looking at the electrical side of it, we do have
separate electrical grounds such as Analog RF ground and Digital RF
ground separately, to avoid loops which create
So the concept of a frontend /nim/dc receiver are all names which are
used in different contexts for different categories of devices. But it
is quite hard to draw a distinct line, in such a case. It could be
argued either ways. (Just like painting the bikeshed green)
> > frontend = demod name (that's what we have currently),
> And that would technically be wrong ... although if it works into the
> coding framework, then so be it.
> > Tuner is unimportant in this case as it doesn't have much of ops.
> I'm not certain what you mean by "ops", but I gather that its minor role
> is what has lead to the project's definition of frontend to equal demod
The project has never stated that at any place. Or is there ?
But i don't understand what your argument is -- for example when i
have a "tuner module" (tin can inclusive of the demod) say one based
on a STV0299, what advantage do you get by telling the user that it
uses a TSA5059 PLL in the RF stage ?
> Lastly, as some food for thought -- we're already starting to see the
> move towards multi-purpose IC's. Examples:
> - Xceive 3028 tuner and analog demod;
> - ATI theater 650 analog demod, A/V decoder & mpeg encoder.
> It likely will be a few years yet, but pretty soon we WILL run into the
> case where the traditional frontend and "backend" components on the DTV
> devices merge into one IC. How then does one define the abstraction?
even though the entire thing is in one chip, it is an abstraction, so
it doesn't matter whether the MPEG decoder and the demodulator are on
the same chip. Still they are separate functional blocks requiring
separate control (You can't ask a MPEG decoder to do some job on a RF
> At that point, the concept will only refer to the relevant processing
> stages carried out in that single IC.
IC = Integrated Circuit. Integration doesn't mean that you loose
control. Of course noise is added into the system. The greater the
integration the greater the noise, in a constant environment.
> > With this it gives the bridge name, Generic name and the frontend
> > name, all in it's own relevant place and not in the frontend. it will
> > be just messing up the frontend to a state where it will be hopeless.
> > for example:
> > bridge name = "Mantis PCI rev 1.0"
> > Generic name = "VP-1034"
> > frontend name = "MB86A16 DVB-S/DSS DC receiver"
> > It additionally fixes some other issues as well, such as handling
> > bridge reset 's etc.
> Will this solution account for a single, multifunctional IC, as I have
> just described?
Why not ? look at the MB86A15/16 (tuner + demod in a single chip in that sense)
More information about the linux-dvb