Micro with DMA output engine?

"larwe" <zwsdotcom@gmail.com> writes:

> mhahn@hvc.rr.com wrote:
>
>> Now the trick will be to find an FPGA to do the scanline buffer that
>> doesn't cost more than just doing a CRTC with a RAM and a handful of
>> counters.
>
> The RAM-and-counters method is easier for me to wrap my head around, to
> be honest.

>
> There's kind of a long grayscale that stretches from:
>
> * 100% CPU-driven output
> * Single-scanline buffer, CPU generates sync timing and reloads line
> buffer every scanline
> * Entirely external video RAM, CPU generates sync timing and resets the
> RAM counter only. CPU is allowed to update video RAM during blanking
> intervals.
> * Full CRTC doing everything
>
> I could do (up to) 512 x 256 video very easily with a 128K SRAM and two
> counters, if I just use the CPU to generate the sync.

<snip>

Why not use say a LH79520 with built in LCD controller? You can use an
external static RAM if you don't like SDRAM.

-- 

John Devereux

larwe wrote:
> Paul Marciano wrote:
> > FPGAs and CPLDs are a lot of fun.  I find verilog incredibly easy and
> > interesting (coming from a 'C' and assembly background with a
>
> I started experimenting with VHDL a while ago - I have about eight
> inches of books on the topic <g> - but haven't progressed very far.

I toyed with an FPGA development system for about a year - reading
Verilog books but never actually getting around to DOING anything.

Then I joined a small company and spec'd an FPGA as part of an
out-sourced board.  The story ends with us deciding to bring the FPGA
code back in-house and with me volunteering to do it.  Which I did in
about two weeks.

What the FPGA did isn't important.  What is important is that having
spec'd the chip and having poured through Verilog and digital design
texts for a year, applying it was straightforward.

In the end you learn by doing.  Don't be afraid.  A CPLD may give you
better integration, real estate and performance than discretes or
trying to do it all in the microcontroller.

Paul.

On 21 Jan, in article
     <1137882618.340881.298250@o13g2000cwo.googlegroups.com>
     me@linnix.info-for.us "linnix" wrote:

>larwe wrote:
>> Paul Marciano wrote:
>>
>> > In terms of configuration, Digilent (who make development boards for
>> > Xilinx) sell a $12 cable:
>
>I would go directly with the Xilinx  HW-SPAR3-CPLD-DK.  They have
>FPGA+CPLD together for $99, including a XC3S200 FPGA,
>XC9500 CPLD, jtag downloader and CDs.  The 200K FPGA alone
>cost over $20 retail.  The package is cheaper than all the components.
>
>By the way, the FPGA kit has a hardware VGA port for three basic
>colors (RGB).  I am sure you can modified it for additional colors.
>If you need and want an micro within the FPGA, PPC cores are available
>for the Virtex-4 series.

All that seems overkill. Having used a 128kB SRAM and Altera Max7256 to

        dual port RAM with micro (address and data)
        frame grab from a PAL interlaced video source in monochrome
                route ADC data to SRAM
        Continuously play back data from RAM to a DAC whilst performing
          simple calculations on the data at pixel rate.
        Run all the necessary counters for video timing and addressing.
        CPLD registers for function control of CPLD from software.
        Other functions for the board.

All that in 128 TQFP and had enough extra lines and counter bits available
to cope with 512kB device when 128kB no longer available. The 512kB is only
in a 4 pin larger package (36 instead of 32).

That way the CPLD and SRAM appear on the address bus of the micro. The
10bit DAC and 8 bit ADC were connected and controlled directly by the CPLD.

For what you are doing a smaller pin count Altera or Xilinx will do the job
of handling syncs and providing blanking interupts for you.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

mhahn@hvc.rr.com wrote:
> Will an external scanline buffer leave you much time to do anything?
> 
> I seem to remember a thread in this group a while ago saying you'd be
> hard pressed to do much more than a 5 Mhz write speed with an lpc2xxx
> arm. Let's see a video scan line is about 87 uSec long and if you're
> writing 256 bytes per scan line ... If you're writing a 16 bit word at
> a time, it might take you 30 uSec to write out the scanline.

87us ??? Try 31.78us with about 26us active. Since the code needs to be 
linear for speed there is no need to read anything less than a word and 
use the ARM's efficient barrel shifts to position the appropriate pixel 
data. You really don't have an option for how long it might take, it has 
to fit in that window which on the LPC2138 means 192 pixels top-speed 
whereas the LPC2148 will manage 480 pixels. Vertical resolution depends 
upon the amount of RAM available and is the main limiting factor.

But if you use external hardware they would need strobing/clocking and 
that can take quite awhile using I/O pins unless you upgrade to the much 
larger package and use the external bus.

> 
> Well that doesn't seem too bad. You'll spend around 35% of your cpu
> bandwidth writing out the video doing it a word at a time and around
> 70% doing things a byte at a time (simpler scanline buffer hardware).
> Actually your overhead will be a bit less since there are vertical
> blank regions during which the cpu doesn't really have to do anything.
> 
> Now the trick will be to find an FPGA to do the scanline buffer that
> doesn't cost more than just doing a CRTC with a RAM and a handful of
> counters.
> 
> Maybe you could do a hybrid system using a large external ram to do the
> scanline buffer and use a cheap cpld to do the scanline counter. You
> could reload the address in the counters every scanline during the
> horizontal blank period. This would let you use the whole RAM as a
> screen buffer. You can probably buy a 128K byte SRAM chip and a cheap
> cpld for about what you'd spend for a fpga.
> 
> Mark

I have done various discrete counter/PLD/CPLD designs in the past and 
they all require some form of address/data/control lines which always 
means much higher pin-count and size.

Nothing I know of is simpler than the LPC21xx method I am using (albeit 
with limitations). One tiny 48 or 64 pin LQFP pack and that's it! How 
small? This is an earlier product but take a look at:-
http://www.pbjtech.com/products/index.html#THUMBNAIL_2106_VGA_PROCESSOR_MODULE

Yeah, that's right, you could almost fit it into the VGA head-shell.

*Peter*

Paul Carpenter wrote:
> On 21 Jan, in article
>      <1137882618.340881.298250@o13g2000cwo.googlegroups.com>
>      me@linnix.info-for.us "linnix" wrote:
>
> >larwe wrote:
> >> Paul Marciano wrote:
> >>
> >> > In terms of configuration, Digilent (who make development boards for
> >> > Xilinx) sell a $12 cable:
> >
> >I would go directly with the Xilinx  HW-SPAR3-CPLD-DK.  They have
> >FPGA+CPLD together for $99, including a XC3S200 FPGA,
> >XC9500 CPLD, jtag downloader and CDs.  The 200K FPGA alone
> >cost over $20 retail.  The package is cheaper than all the components.
> >
> >By the way, the FPGA kit has a hardware VGA port for three basic
> >colors (RGB).  I am sure you can modified it for additional colors.
> >If you need and want an micro within the FPGA, PPC cores are available
> >for the Virtex-4 series.
>
> All that seems overkill. Having used a 128kB SRAM and Altera Max7256 to

Overkill as in "being too cheap"?

>From digikey:
Altera EPM7256AETC100-10 is USD$40
Xilinx XC3S200-4FTG256C is USD$26

I would stick with the 256 balls BGA, in case of needs to upgrade to
XC3S1K.

> ...

> For what you are doing a smaller pin count Altera or Xilinx will do the job
> of handling syncs and providing blanking interupts for you.

Unfortunately, they don't make big chips with small pin/ball counts.
Bigger
chips are sometime cheaper as well.

>>
>> AT91FR40162 is at Digikey.
>> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate SRAM.
>> If you run the FIQ + some kind of external buffer, you might be able to 
>> do
>> it.
>> Also contains a 2 MB Flash.
>> If you don't like BGA, then the AT91R40008 is the same part without the
>> Flash in TQFP-100.
>
> Perhaps you can answer this question for me:   Why does the part with
> the internal flash   end up in the 121-pin BGA while the part with
> external flash ends up in the 100-pin qfp?  That seems backwards to
> me.   If you can put all the Flash and RAM in the same package, why
> do you need the extra 21 pins?
>
>


You still want to have the external bus, and the flash needs to have 
additional pins.
The chipselects to the flash needs to be connected outside the package.
it is (intentionally) not connected inside.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

In article <i7kFf.318$E_4.353@nntpserver.swip.net>, ulf@a-t-m-e-l.com 
says...
> >>
> >> AT91FR40162 is at Digikey.
> >> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate SRAM.
> >> If you run the FIQ + some kind of external buffer, you might be able to 
> >> do
> >> it.
> >> Also contains a 2 MB Flash.
> >> If you don't like BGA, then the AT91R40008 is the same part without the
> >> Flash in TQFP-100.
> >
> > Perhaps you can answer this question for me:   Why does the part with
> > the internal flash   end up in the 121-pin BGA while the part with
> > external flash ends up in the 100-pin qfp?  That seems backwards to
> > me.   If you can put all the Flash and RAM in the same package, why
> > do you need the extra 21 pins?
> >
> >
> 
> 
> You still want to have the external bus, and the flash needs to have 
> additional pins.
> The chipselects to the flash needs to be connected outside the package.
> it is (intentionally) not connected inside.
> 
> 
> 
OK, That's two to four pins, now what about the  other 17?


Mark Borgerson

>> >> AT91FR40162 is at Digikey.
>> >> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate 
>> >> SRAM.
>> >> If you run the FIQ + some kind of external buffer, you might be able 
>> >> to
>> >> do
>> >> it.
>> >> Also contains a 2 MB Flash.
>> >> If you don't like BGA, then the AT91R40008 is the same part without 
>> >> the
>> >> Flash in TQFP-100.
>> >
>> > Perhaps you can answer this question for me:   Why does the part with
>> > the internal flash   end up in the 121-pin BGA while the part with
>> > external flash ends up in the 100-pin qfp?  That seems backwards to
>> > me.   If you can put all the Flash and RAM in the same package, why
>> > do you need the extra 21 pins?
>> >
>> >
>>
>>
>> You still want to have the external bus, and the flash needs to have
>> additional pins.
>> The chipselects to the flash needs to be connected outside the package.
>> it is (intentionally) not connected inside.
>>
>>
>>
> OK, That's two to four pins, now what about the  other 17?
>
>
> Mark Borgerson


The next larger size from BGA100 (10 x 10)  is BGA121 (11 x 11)
and if you look at the datasheet, you see it has some no connects.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

In article <ds9du4$k73$2@gondor.sweden.atmel.com>, ulf@a-t-m-e-l.com 
says...
> >> >> AT91FR40162 is at Digikey.
> >> >> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate 
> >> >> SRAM.
> >> >> If you run the FIQ + some kind of external buffer, you might be able 
> >> >> to
> >> >> do
> >> >> it.
> >> >> Also contains a 2 MB Flash.
> >> >> If you don't like BGA, then the AT91R40008 is the same part without 
> >> >> the
> >> >> Flash in TQFP-100.
> >> >
> >> > Perhaps you can answer this question for me:   Why does the part with
> >> > the internal flash   end up in the 121-pin BGA while the part with
> >> > external flash ends up in the 100-pin qfp?  That seems backwards to
> >> > me.   If you can put all the Flash and RAM in the same package, why
> >> > do you need the extra 21 pins?
> >> >
> >> >
> >>
> >>
> >> You still want to have the external bus, and the flash needs to have
> >> additional pins.
> >> The chipselects to the flash needs to be connected outside the package.
> >> it is (intentionally) not connected inside.
> >>
> >>
> >>
> > OK, That's two to four pins, now what about the  other 17?
> >
> >
> > Mark Borgerson
> 
> 
> The next larger size from BGA100 (10 x 10)  is BGA121 (11 x 11)
> and if you look at the datasheet, you see it has some no connects.
> 
I guess that makes some sense.   The other thing I had considered
was more power and ground pins to handle the extra current demands
of the flash.


Mark Borgerson