| ??? 04/23/07 17:00 Read: times |
#137831 - True, but only sometimes ... Responding to: ???'s previous message |
Erik Malund said:
That's easily done with the FPGA, once it's there. sure, but if you separate the 'loading' and the 'driving' functions to two devices, the 'driving' function will never have a timing problem because of some circumstance in the 'loading'. in a video display subsystem, the driving and loading functions are synchronous. I am, still being cost conscious, in favor of separating functions to separate units. The cost of having to fix umpteen units in the field because you found that a timing glitch had shown up with your last enhanecement is far highte than $3 in the initial manufacture of the unit.
I'm not so sure ... a pixel-based video display, as I said before, is completely synchronous, being based on the pixel rate. Glitches arise due to poor design in such a system, and, in fact, are difficult to generate without some discrete effort to cause them. They also show up immediately in simulation. They're only a problem in THIS case when someone tries to cut corners. Once you have an FPGA involved, owing to the extremely large resource pool they offer you can include the MCU, if you really think you need one, into the FPGA, rather than adding, and coding for, an additional, external, MCU. The risk of being cost conscious in the wrong place (this does not apply to toys) is that a 'savings' not fully and totally thought through may come back, possibly after years, to bite you in your largest muscle.
Erik My position remains that, generally, it's an either/or situation. If you have a microcontroller that can do the whole job, right down to the pixel generation in analog format, then it's a no-brainer. Lacking that, however, and assuming there's already an intelligence of some sort loading the display RAM, specifying the color shades, and doing the high-level things, using a microcontroller to generate the timing, translate from display data ram content to pixellated video, is not only a challenge, but, hard to justify in terms of cost, since a device capable of that will have to be pretty fast, and have some pretty fast DAC's on board as well. The SiLabs parts aren't up to the task. That's for sure. Once you add external hardware, the whole process becomes more complex. Do you use the traditional RAMDAC? How do you structure the memory? How would you keep a microcontroller synchronized with the process? How many instructions per pixel? RE |
