Electronics > Microcontrollers

Best FPGA for glue logic

(1/3) > >>

thetooth:
I bought a stellaris launch pad MCU last month and have been working on a in card computer/data logger, so far the software and hardware side of designing have been really easy, but as im getting closer to PCB design im thinking i should consolidate my design.

The main display(CFAG320240CX-TFH-T) is a 8-bit parallel controlled graphics LCD with 5 control lines and a busy state pin based on the Epson S1D13700, now my first issue is transfer speed, hooking the 8-bit bus directly to the MCU would be silly since i'd have no pins in no time, so currently i use a MCP23S17 bi-directional shift register. This is great when sending characters to the display, the 10Mhz clock rate of the SPI line is very fast... but... for graphics the display requires you to send a 8bit value(the screens VRAM is arranged as 40 columns by 240 lines of 8-bit(1-byte for bitmap, 2-byte for 4 shaded grayscale and/or blending effects) scan lines, you update a single pixel by reading in the current VRAM, changing the pixel value, and the writing the block back). So, you see drawing the entire display in monochrome would be very slow over SPI, so my idea would be to synthesize the SPI->parallel conversion in the FPGA for characters, but also store graphics and GUI routines within the FGPA's high speed memory and assign macros that allow me to draw large graphics at line speed(40Mbps compared to 625kbps). Additionally, those control pins are also set byte sending an entire byte to the I/O expander, theoretically i could also automate this on the FPGA side :D

Finally, i could drop the other chips for user I/O and just use opto-couplers for isolation rather than a pair of voltage converters.

So my question is, what would be my best bet for this application? i was thinking spartan 3E, but its not recommended for new designs(end of life?), and, well i don't really understand a lot of the terminology relating to `cell size` and logic gates.

Smokey:
Unless you have big plans for implementing other functions in the FPGA, you should check out CPLDs for glue logic type applications.

Something like the Xilinx Coolrunner-II series maybe.  Price is under 2USD for the smaller ones.
http://www.xilinx.com/support/documentation/data_sheets/ds090.pdf

Harvs:
Which MCU is it you plan on using?  I believe the launchpad comes in many variants doesn't it? (I see there's a Cortex M4F launchpad?)

I'm not overly familiar with the TI line of ARMs, however, most larger 32bit MCUs have a dedicated parallel interface for driving external memory and this sort of thing.  Maybe it would be easier (and cheaper) to choose a MCU that has the dedicated hardware to do this?

As this is only a monochome LCD, 320x240 is only 76.8kb or 9.6kB.  So a decent MCU could hold the complete frame in RAM and do all the graphics processing in RAM, then use a DMA to regularly update the display in the background when triggered by the processor.  This is how I've done it before with a similar SPI driven display.

thetooth:

--- Quote from: Smokey on December 13, 2012, 11:14:48 pm ---Unless you have big plans for implementing other functions in the FPGA, you should check out CPLDs for glue logic type applications.

Something like the Xilinx Coolrunner-II series maybe.  Price is under 2USD for the smaller ones.
http://www.xilinx.com/support/documentation/data_sheets/ds090.pdf

--- End quote ---
Looks promising, im not familiar with CPLDs though, would it be possible to say, implement a program for drawing a circle or reading a bitmap from memory?


--- Quote from: Harvs on December 14, 2012, 01:06:28 am ---Which MCU is it you plan on using?  I believe the launchpad comes in many variants doesn't it? (I see there's a Cortex M4F launchpad?)

I'm not overly familiar with the TI line of ARMs, however, most larger 32bit MCUs have a dedicated parallel interface for driving external memory and this sort of thing.  Maybe it would be easier (and cheaper) to choose a MCU that has the dedicated hardware to do this?

As this is only a monochome LCD, 320x240 is only 76.8kb or 9.6kB.  So a decent MCU could hold the complete frame in RAM and do all the graphics processing in RAM, then use a DMA to regularly update the display in the background when triggered by the processor.  This is how I've done it before with a similar SPI driven display.

--- End quote ---
I'm currently using the LM4F120H5QR, it has 32 channels of usable GPIO, for the LCD to run in parallel thats almost half my channels gone already(8-bit data bus plus 6-bit control, not including reset or power control), i mean i could JUST cram everything in like this, but i feel it would be much more flexible if i had 24 channels for GPIO and everything else run off the FPGA.

One issue i also forgot to bring up(which you can in fact see in the picture i attached), is this I/O expander requires you to send a 1-byte address and mode every time you send it data, so thats 3-bytes to clock in, and another 2-bytes to clock out, so for 9.6kB the actual transmission over head is 48kB, to achieve 60fps, a throughput speed of 2.8MB/s, also again this display can do grayscale too, so a further byte is required.

Anyway thanks for the advice, im going to read up on CPLDs now.

tnt:
I wouldn't qualify what you describe as "glue logic" ....  glue logic is really small stuff that you could implement with a few discrete 74xx or 4xxx chips ...

What you describe is essentially a GPU and you're not going to do that in a CPLD.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version