Micro with DMA output engine?

I didn't think of Altera, but I started with Xilinx and Lattice, and remember it's not quite as simple as just free software tools - I need a reasonably priced JTAG pod (or whatever) also.

There are many solutions to any problem. Particularly when considering my form factor, the "right" way to do it is to put everything in an FPGA, but I don't have the skills and experience to do it this way. I'm only considering a CPLD as a replacement for the discrete logic I'm going to need (counters and misc. gates), which is how I've used them in the past. Yes, it could all be done elegantly in VHDL but I'm only at a rudimentary level of familiarity with the language; I think I can get the project done faster using other methods.

I think Xilinx and Altera are the #1 and #2 respectively for FPGAs and CPLDs. The Xilinx tools are very good, I think. They just released version 8.1i of their Webpack free development suite.

In terms of configuration, Digilent (who make development boards for Xilinx) sell a $12 cable:

Or Xilinx provide instructions and 'C' code to enable devices to be programmed directly from a microprocessor (i.e. you could wire the ARM to the CPLD's JTAG pins and program the CPLD from the ARM... if you can fit the bitfile in the ARM flash).

See:

FPGAs and CPLDs are a lot of fun. I find verilog incredibly easy and interesting (coming from a 'C' and assembly background with a university digital systems education).

I develop my verilog with the Icarus verilog simulator and gtkwave vcd viewer on Linux. Then I migrate onto the Xilinx tools when I'm ready to do more hardcore simulation and synthesis.

Good luck!

Paul.

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?

Mark Borgerson

A later check says that while they have it in the catalogue, there i no stock at the moment.

The Flash needs some specific signals. VPP If below 0.4V , then this is a write protect NCSF Flash Chip Select. Ths chip select between CPU and Flash is not internally connected This allows you to put the flash on any chip select. NBUSY Flash RDY/Busy NRSTF Flash Reset

So you need more than 100 pins. Maybe the next larger size is 121 BGA.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Thanks, that's exactly the kind of tip I needed.

I have plenty of room at the moment - but I'm not sure I want to waste all that space since I might want to add more functionality to the main uP.

I started experimenting with VHDL a while ago - I have about eight inches of books on the topic - but haven't progressed very far.

Hey Lewin,

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.

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

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.

Actually I'd be sure there was some sort of blanking when you are updating the video RAM. It's nice to do it during vblank, but if the screen goes black for an instant when you do a major screen update it's not that noticeable. Do they make DACs that have an output enable?

Hmmm ... you could use 8 bits of micro IO to do the row addressing, and do the lower 9 bits of collumn addressing just using a simple counter. You'd have to provide a clock for the counter. You could probably use the hsync the micro generates to clear the counter. This would probably require you to waste a few bits on either side of hsync to provide a proper front and back porch.

Too bad they don't make the 74hc590 in a 9 bit counter (only 8 bits, so you'll need 2). It has tri-state outputs. You could have the counter and the micro share the 9 lines of collumn addresses. The micro would set the counter into Hi-Z state when it needed to write to RAM. When the counter was running, the micro would set its lines Hi-Z.

There's probably more to it than that. I'm having a hard time believing you could do a video interface with a micro, clock source, 1 RAM chip,

2 counter chips and some sort of dac. But it'd be cool if you could.

I've had this weird notion for some time to try to do a video display with a PIC, this might be a cheap way to do it.

Mark

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.

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

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.

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
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

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.

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:-

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

*Peter*

Overkill as in "being too cheap"?

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.

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

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

OK, That's two to four pins, now what about the other 17?

Mark Borgerson

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