EmbDev.net

Forum: FPGA, VHDL & Verilog Search for automotive FPGA or CPLD for OSD


Author: J. Hebeler (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello,

for an automotive application I have to implement an OSD for a PAL video 
signal. In theory this is not complicated, with a LM1881 I get the sync 
information, in a large enough memory there is the information if a 
pixel should show black, white or the original signal, which is read and 
put into a multiplexer, such that the correct signal is selected.

But as I am lacking experience in this field I find it rather 
complicated to find a suitable device. I would prefer something with 
legs(TQFP) rather than BGA, beeing cost effective is a huge plus.
Looking at the filtered result at farnell or digikey I can't really 
decide, which part is suited for such a task. Can I implement the memory 
interface and the controll logic on a simple CPLD, do I need an FPGA? 
Can I also add an UART/I2C interface?

If you could point me in the right direction this would be great.

P.S: I know that there are chips like the MAX7456, but as most of them 
are discontinued, I prefer not to implement them in a new design.

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
J. Hebeler wrote:
> I would prefer something with legs(TQFP) rather than BGA, beeing cost
> effective is a huge plus.
Why do you expect a BGA to be more expensive then a "wired" package?

> Can I implement the memory interface and the controll logic on a simple
> CPLD
Maybe, but if you want to
> add an UART/I2C interface
then a CPLD will get to the limits very soon. So the result is:
> do I need an FPGA?
Yes.

> Looking at the filtered result at farnell or digikey I can't really
> decide, which part is suited for such a task.
Start with an EVAL board that has your desired type of memory and a big 
FPGA on it. Then get your design running. Afterwards you can choose a 
FPGA that fits the application.

: Edited by Moderator
Author: Joe F. (easylife)
Posted on:

Rate this post
0 useful
not useful
MinimOSD in combination with an automotive ATmega might be an option 
too.

Author: derguteweka (Guest)
Posted on:

Rate this post
0 useful
not useful
Moin,

J. Hebeler wrote:
> In theory this is not complicated, with a LM1881 I get the sync
> information, in a large enough memory there is the information if a
> pixel should show black, white or the original signal, which is read and
> put into a multiplexer, such that the correct signal is selected.

Well, also in theory it'll be nice, if you have some pixelclock phase 
locked at least to h-sync, which means additional hardware/PLL.
Also PAL is interlaced. Interlaced video with an overlay in pure black 
or white will flicker like crazy.

cheers,
WK

Author: J. Hebeler (Guest)
Posted on:

Rate this post
0 useful
not useful
>Why do you expect a BGA to be more expensive then a "wired" package?
Wrong wording. I do not expect the BGA to be more expensive. I want a 
wired package as it simplifies the design and manufacturing for the 
application.

>> do I need an FPGA?
>Yes.
ok, good to know

>Start with an EVAL board that has your desired type of memory and a big
>FPGA on it. Then get your design running. Afterwards you can choose a
>FPGA that fits the application.

This is where I see myself at the start again. I can of course buy a 
ZYNQ, Virtex or Stratix 10 FPGA board and I will definitly have enough 
power, memory and peripherals, but it seems to me that this won't help 
me choose the right automotive grade(temperature range) FPGA that allows 
me to implement my functionallity, without having to put a >500 pin 
device on my board

> MinimOSD in combination with an automotive ATmega might be an option
> too.

The minimOSD still uses the MAX7456, which is a discontinued chip. 
Further the quality of the used IC on the minimOSD seem to vary a lot, 
so I don't want to use them in a product I have to support for 10 - 15 
years.

> Well, also in theory it'll be nice, if you have some pixelclock phase
> locked at least to h-sync, which means additional hardware/PLL.
> Also PAL is interlaced. Interlaced video with an overlay in pure black
> or white will flicker like crazy.

Similar systems are already in use and work flicker free.

Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
I assume you want to use an FPGA in order to avoid the extra hassle/cost 
with buffering the video (external RAM).
However when coming to Automotive, you might be better off with a signal 
processor, such as BF561 or BF549 from Analog Devices, the latter being 
specifically designed for the vertical markets with long term 
availability and all the automotive extras (MOST, CAN).
The only storage you need is the bitmap for the OSD elements, this is 
then likely to reside in a parallel flash. If the bitmap depth is like 
1-2 bits per pixel or if RLE compression is an option, bandwidth of a 
SPI flash will suffice, too.
I'm in no way affil-(nospam)-iated with ADI, but have made good 
experiences with this chip family for PAL processing (a few years ago).
If you still want to go with the FPGA, you might be better off with a 
functional simulation and nail down memory reqs before you decide for a 
specific chip.

Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Addendum: Spartan-6 LX9 are available in TQFP. Not sure if this one has 
enough memory for your app, but you can definitely do fancy hacks there 
with character ROM in SPI flash and stream it at the 27 MHz pixclk.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.