Using SDRAM as VRAM and Bitmapped Video - Page 1
Forum section: electronics / projects

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 01:12:49 am
content: Hey guys,I know that VRAM and GDDR are specialized for use with graphical systems and adapters, but is it feasible to use standard SDRAM as a graphics buffer, or is it just not suited for that application?

author: Len
author_rank: Frequent Contributor
timestamp: March 24, 2015, 01:36:44 am
content: It depends on the requirements of your graphics system. For example the Apple II used 16 kbit RAM chips running at 1 MHz for its memory (main + video). You could take that as a practical lower limit.

author: helius
author_rank: Super Contributor
timestamp: March 24, 2015, 02:02:43 am
content: The most basic requirement for a framebuffer (as opposed to an offscreen bitmap) is for it to be dual-ported. The video generator needs to read it strictly according to the pixel clock, which is asynchronous to data processing. If you only have a single-ported memory, you will need to make the video generator be the master clock source, and use priority decoder so that the low-priority task (processor wants to write into the buffer) is only allowed when the video is blank (horizontal or vertical blanking periods). This can slow down the processor.

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 02:29:43 am
content: Thanks for the replies, guys. At least I know that it can be done depending on the requirements.I'd like to do into more detail on my design; it's in an alpha stage, and I'm open for new ideas.I'm coming from the old-school of NTSC composite, NES-style tile-mapped graphics. When I saw my graphics on the more modern TVs, they lookedbadto say the least. So now, I want to focus on a component video signal to eliminate the required processing; this improves video quality. I know that I want to have a refresh rate of 60Hz for smoothness, but I'm not sure what resolution I want to go for. I feel like 800x600 would look blocky and chunky on, say, a 32" TV. Right now my CPU is running at about 6MHz which would be unacceptable if I want a relatively high resolution.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 24, 2015, 03:21:37 am
content: Back in the IBM PC days, and yes machines like the Apple II, they did everything together. On common-bus systems, the CPU was held in WAIT state until the memory was accessible -- the few microseconds (all of a bus cycle or two worth) during horizontal retrace, or a few ms of useful action during vertical retrace. Atari 2600 also comes to mind. IBM PCjr. Painfully slow or underpowered machines, they were!General IBM PC machines (XT-AT era?) have an 8 or 16 bit "local" CPU bus with system memory and BIOS ROM(s), adapted to an 8 bit (AT or PS/2+? introduced 16 bit) ISA bus, and peripherals that mostly stood alone without the CPU's constant attention (or causing WAIT states to it constantly). Things get just as bad as the old machines if you tried doing a lot of graphics -- typical CGA/MDA/EGA/VGA adapters had DRAM wired to the graphics chipset, which was accessible on the bus at a fixed address range so you could directly access it, but the chipset took priority of course, so if you access during a scan line, you aren't going to get an opening until the end of that scanline, up to 60us of wasted time. That's not exactly true, actually; CGA had "snow" if you tried accessing it during a scan line, because they forgot to make it wait, and sometimes the data gets... confused.Somewhere in the 90s, dual ported RAM, ASICs, buffered/cached IO, and VESA and finally PCI percolated down to consumer hands, boosting speeds and data transfer methods into the modern era (more or less). Nowadays I think everything is more or less memory mapped, but the mapping is a virtual construct (I mean, besides the processor's own memory mapping shenanigans), carried through serial data packets on PCIe, and stored in buffers/cache at each end until the processors / arbitrators can do something with it. (Curiously, or perhaps not, the overall latency hasn't improved much at all; whereas the ISA bus could complete a single transaction (one byte) in a fraction of a microsecond, PCIe latency can be microseconds. Of course, you can burst 10s of kB in that microsecond, and completely load a 10MB+ frame or texture buffer in a millisecond.)Anyways, as far as using SDRAM, as far as I know, you could use it sequentially into a DAC to generate VGA waveforms (or a serdes/PHY for DVI/HDMI?). You'd need a controller (FPGA most likely?) to generate sequential addresses (including whatever prefetching / queuing the SDRAM supports that's handy for the purpose), and allow CPU bus access during retrace periods. Or whatever kind of buffering/cache you want to write for it, limited by the logic on the FPGA.But a better question, these days, might be... why? Modern graphics isn't strictly sequential by pixel like it used to be... I mean, the hard part of it, anyway. The hard part is 3D rendering, and shaders, and CUDA/etc. cores. Frame buffers and RAMDACs are the relatively trivial part; indeed, with digital standards being typical these days, the RAMDAC isn't even a DAC anymore, it's just... RAM.If it's for an embedded project, yes you can still get the kinds of LCD displays that require a sequential raster input (i.e., having no onboard RAM themselves), but you're almost certainly better off buying a controller chip, or an MCU with the controller integrated. If you get the integrated controller type LCD, then you can perform random writes to its framebuffer without worry. Or, if this is for idle curiosity, then I hope this was helpful?Tim

author: babysitter
author_rank: Frequent Contributor
timestamp: March 24, 2015, 05:54:12 am
content: Matjaz Vidmar used 4116 RAM to generate a FBAS composite video signal out of a slow-scanning Weather satellite APT signal.In addition to the main memory there is a line buffer, 2112 :http://lea.hamradio.si/~s53mv/archive/a031.pdf(Italian text but schematics are clear)As RAM is cheaper today, you might improve resolution a lot I think

author: helius
author_rank: Super Contributor
timestamp: March 24, 2015, 07:03:17 am
content: The PC-AT was the one with the 16-bit ISA bus. The PS/2 had Micro Channel, which was initially 16-bit but had a 32-bit flavor soon after.dual-port is just the basic part of VRAM; they also had things like mask and fill registers to make drawing/clearing operations faster. if you wanted to do those things externally to a regular DRAM, you would use an FPGA to open+read a whole line into a big shift register. Then clock out each pixel as needed until the register is empty or blanking occurs. The FPGA also has to arbitrate this DRAM access for the processor.

author: hamster_nz
author_rank: Super Contributor
timestamp: March 24, 2015, 09:23:39 am
content: Quote from: sentry7 on March 24, 2015, 01:12:49 amYes, depending on resolution and the total SDRAM bus width.A 100MHz SDRAM with a 16 bit interface (e.g. MT48LC4M16) can supply about 180MB/s even with the most basic of controllers. That isn't enough for high colour depth 1080p graphics, but enough for 1080p at 8 bits per pixel, or 720p @ 16bpp. With 124MB/s used for the display it doesn't leave much to bandwidth for the writes to update the image... :-(If you run it at a slower clock rate you loose bandwidth as more and more cycles are lost to overhead (e.g. refresh cycles, activations and so on). From memory think that the slowest you can run the memory at is a few MHz before all the cycles are eaten up in refresh.But for low resolutions like 640x480@60Hz, SDRAM has plenty of bandwidth.

author: Gribo
author_rank: Frequent Contributor
timestamp: March 24, 2015, 09:35:54 am
content: Modern GDDR is not dual ported. The video chip (Nvidia and AMD) uses cross bar architecture and features of SGRAM itself to arbitrate the bus between the GPU and TMDS/LVDS driver or DAC.http://en.wikipedia.org/wiki/Dynamic_random-access_memory#Synchronous_graphics_RAM_.28SGRAM.29

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 07:34:17 pm
content: Sorry for the long delay, but please keep the insights coming! I'm just getting into bitmapped graphics and would like the wisdom/experience of those who have done this.Maybe I should go more into detail about my project. I designing a video game console, and I have already decided that I do not want 3D graphics. I want multiple hi-res bitmaps with masking, and at least a 256 color mode. What kind of hardware am I looking at? I'm guessing several MB of memory with a circuit/controller that generates the addresses and a DAC for signal generation?

author: Alex Eisenhut
author_rank: Super Contributor
timestamp: March 24, 2015, 08:06:07 pm
content: Quote from: sentry7 on March 24, 2015, 07:34:17 pmYou might find it entertaining to look at how the VIC-20 and C64 were set up. The video chip and CPU shared the same physical memory, but the CPU had access on the high part of the system clock, the video chip on the low. (or the opposite, who knows?)The VIC used SRAM and a low-res video chip, so it's not a big deal to see how it works, but the C64 used DRAM with the video chip doing the refreshing as well as putting the CPU into a wait state if it needed more data.

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 08:16:46 pm
content: Quote from: Alex Eisenhut on March 24, 2015, 08:06:07 pmAh, the VIC-20. My current configuration was inspired by systems that had that architecture. My current GPU is a Parallax Propeller microcontroller; I've essentially programmed it to be a graphics processor. The big problem with what I have now, is that the chip doesn't have enough memory for the features that I want like horizontal and vertical scrolling or parallax scrolling. Tilemap graphics just isn't cutting it for my system either and the composite video quality is killing the graphics.

author: macboy
author_rank: Super Contributor
timestamp: March 24, 2015, 08:36:00 pm
content: Quote from: sentry7 on March 24, 2015, 02:29:43 amIf you are actually talking NTSC then you have no choice of resolution. You have 525 lines of vertical resolution, and horizontal resolution is determined by the pixel rate you choose and the bandswidth of the entire analog chain between you and the CRT. Of those 525 lines, you have about 480 lines visible within the screen. A resolution of 640x480 is commonly used since that gives you square pixels, allthough the practical horizontal resolution will usually be significantly less than 640 unless using component video.If you are thinking of using analog HDTV resolutions, then you still don't have the option of 800x600. You have either 720 or 1080 (visible) vertical lines, and again the horizontal is limited in practice by your pixel clock. Again if assuming square pixels then 1280x720 and 1920x1080 with 16:9 ascpect ratios. Most TVs will not sync to 800x600 on the component inputs, but often will do so on a VGA input if it has one.

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 09:10:52 pm
content: Quote from: macboy on March 24, 2015, 08:36:00 pmThank you for bringing that up; it is a good point. I plan to change from NTSC to VGA, for the sake of quality. I have a question though about video systems, specifically game systems. Consoles are obviously used with different sized TVs, but how does the system adjust the resolution to fit the TV? Does it simply adjust the dot clock based on horizontal dimension?

author: Len
author_rank: Frequent Contributor
timestamp: March 24, 2015, 09:19:16 pm
content: Quote from: sentry7 on March 24, 2015, 09:10:52 pmThe resolution does not change. A big TV has the same picture as a small TV, just bigger! The number of horizontal lines is always the same (defined by the NTSC or PAL standard). The horizontal resolution along each line depends on the TV's analog hardware - it just does its best to represent the analog input signal. The game console outputs some fixed number of pixels per line (say 256) and the TV will display them in a more or less blurry fashion.

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 09:28:47 pm
content: Quote from: Len on March 24, 2015, 09:19:16 pmThat makes sense in the NTSC case, but what if I did VGA? How does this change? Does the TV just adjust the image based on the synchronization signals?

author: Len
author_rank: Frequent Contributor
timestamp: March 24, 2015, 09:46:00 pm
content: Quote from: sentry7 on March 24, 2015, 09:28:47 pmSorry, I was talking about TV's and game consoles specifically.Yes, VGA "multisync" computer monitors can detect the various VGA graphics modes based on the input signal and adjust their scan rate accordingly. (Supposedly you could damage a monitor by feeding it a non-standard video signal.) But again this has nothing to do with the size of the screen.

author: sentry7
author_rank: Regular Contributor
timestamp: March 24, 2015, 10:59:56 pm
content: Quote from: Len on March 24, 2015, 09:46:00 pmI mean my design is a game console that outputs VGA to TVs that have a VGA input, so does this work for TVs too?

author: grumpydoc
author_rank: Super Contributor
timestamp: March 24, 2015, 11:26:18 pm
content: QuoteSome 8 bit designs in the late 1970's/early 1908's (I'm thinking mainly of the Nascom but there were others as well) did it the other way around - allowing the CPU access priority over access by the video hardware. This tended to affect the display a bit :-/Way back I acquired an old CPM system - this (amongst other interesting bits and pieces) had a Z80 based bitmapped graphics card which I pretty fully reverse engineered at the time. I recall that it seamlessly interleaved access by the CPU and by the video hardware.Sadly the last time I went hunting for the card and my notes I could no longer find it. I was annoyed, partly because I had plans to restore the system (it was last seen in bits to draw out the schematics) and partly because I'm convinced it did it without Z80 wait states and in the odd moments that my mind flits back to that system I still can't quite figure out how one could achieve that.

author: Len
author_rank: Frequent Contributor
timestamp: March 24, 2015, 11:51:13 pm
content: Quote from: sentry7 on March 24, 2015, 10:59:56 pmI've never had a TV with a VGA input, but I suppose that if it supports VGA, it supports the common VGA modes. Check the TV's specs to be sure.

author: hamster_nz
author_rank: Super Contributor
timestamp: March 25, 2015, 12:29:32 am
content: Quote from: sentry7 on March 24, 2015, 10:59:56 pmYes, if a TV has a VGA input it will work with some of the standard VGA video rates - the TV itself will upsample it to fill the screen, or put it in a boarder depending on settings. For any flat panel TV at least the common modes will be supported - 640x480, 800x600 & 1024x768 should be fine. I've got a Sony FullHD TV which only supports resolutions under 1280x720 via VGA, but is fine with 1920x1080 over HDMI. I guess they used a cheap Video ADC. :/The resolutions to be supported is a key decision - double-scanned 320x200 gives a 12.5MHz pixel clock, 640x480 is a 25MHz pixel clock, full HD is 145MHz pixel clock, multiply that by your bits per pixel and divide by 8, and you get the memory bandwidth (in MB/s) you need just to support generating video.I don't have any practical experience with discrete video implementations, but anything above 640x480 would be pretty tricky to get working on a breadboard.If you go down the FPGA route, getting something to work at bitmapped 720p is pretty achievable, but on low-end boards bitmapped 1080p starts to get ugly due to memory bandwidth and access scheduling issues.If you wanted something retro-but-modern, consider using 720p but with 2x2 pixels. That takes the memory bandwidth down to 18.75 M pixels per second, and only needs 230,400 bytes of storage for 8-bit pixels.

author: sentry7
author_rank: Regular Contributor
timestamp: March 25, 2015, 01:06:22 am
content: Quote from: hamster_nz on March 25, 2015, 12:29:32 amThanks! This gives me a ballpark estimate of the amount of memory I need. Now, when you say 2x2 pixels, you mean 1 of my output pixels map to a 4-pixel square on the screen, right? That's an excellent resolution! From far away, that would actually look like full res.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 25, 2015, 01:10:44 am
content: Also, worth mentioning maybe... Multiscan monitors can run at higher vertical refresh rates than 60Hz. LCD panels rarely do. If you ever intend on doing a stupid fast game (like, say, an F-Zero style racing game), fast refresh might be a neat option. My Trinitron goes up to 144Hz at 800x600, and I think more at other settings. Or you can get special LCDs that do support faster refresh rates.Tim

author: sentry7
author_rank: Regular Contributor
timestamp: March 25, 2015, 01:20:20 am
content: Man, this is good stuff!Now suppose I wanted to support horizontal, vertical, and parallax scrolling. I'm guessing I need more memory for more bitmaps, or maybe there are programming tricks I could use to do all that with one bitmap...maybe clipping and blitting?

author: marshallh
author_rank: Unknown
timestamp: March 25, 2015, 01:23:00 am
content: SDRAM would be great your application.If you are going to be using it as sprite data and dynamically generating the video output from a tile/sprite structuer (SNES) you will want lots of bandwidth and as many ports as possible.Physically, all SDRAM is single ported. To simulate having more ports you just do time interleaving in your memory controller.If you are doing graphics, get the widest bus width SDRAM you can. I think you can get x32, and x16 is very common. Also, DDR memories effectively double the bus width.Another trick you can use to get more bandwidth is to have 2 or 4 separate ram controllers for storing your sprites, and pipe all writes to all at once, but when you read, you can read from each independently!I'm in the middle of doing a 1080p60 upscaler based around LPDDR. At 166mhz with x32 bus width it is sufficient. Basically you have scanline buffers you read and write in blocks.At lower resolutions you can fit these scanline accesses in HBLANK. But at 1080p hblank barely exists, so you need to double buffer the scanline reads. It gets worse when you are doing interpolation, I have dual 2-ported brams each with 3 buffer slots so that I can be reading from 2 locations while writing 1 location to both.The suggestion of shooting for 720p is a good one. You can output 720p with cheap Spartan-6 fpgas and no other hardware. It won't be compliant, but it does work. Meeting timing for stuff at 1080p is much more difficult.Pixel clock for 720p is 74.25mhz, 1080p is 148.5mhz.Also consider using SSRAM (synchronous) for things that you will want deterministic access for. Stuff that you need low latency reads on, but takes too much fpga BRAM, like attribute/nametables.If you're going to do all this with the framebuffer approach, where you draw stuff via painters algorithm, you will need a huge amount more ram bandwidth than the PPU-type approach. Look to the Neo Geo graphics pipeline for inspiration on how to do 60fps with 100's megabytes of sprites using 1988 technology.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: March 25, 2015, 02:02:53 am
content: heh Im tinkering with some similar ideas. I'm knocking up a little z80 homebrew and need to do some vga output. I have some nice fast RAMDAC chips, but need to pump from memory at a certain speed, fast enough to hit the VGA spec for 640x480x256 or 800x600x256. Got some nice and fast 64kb srams 15ns... but the z80 cant pump data IN while the support processor is trying to feed the ramdacI was thinking of just having enough srams to screenflip, fill one while the other is used for drawing, then swap. problem there becomes, you have to fill the second screen with the same data as the first.the z80 cant really feed enough data into the srams during the vblank signal (how we used to do it back in the DOS demo coding days).a conundrum..

author: hamster_nz
author_rank: Super Contributor
timestamp: March 25, 2015, 03:25:28 am
content: Quote from: sentry7 on March 25, 2015, 01:06:22 amI sort of mean, where each digits and letters are different pixels in memory.Code:each line is 1280 characters long.line 0: 00112233445566...line 1: 00112233445566...line 2: aabbccddeeffgghh....line 4: aabbccddeeffgghh.......line 719: ......So if you display this on a 1920x1080 TV, each pixel will actually map to a 3x3 area on the screen (as 1280/2*3 = 1920, and 720/2 *3 = 1080) and it most likely will be filtered by the display too, so won't be super blockky.Maybe you should make a 640x360 bitmap, and display it full screen on a 1080p monitor to see what it will look like?

author: DanielS
author_rank: Frequent Contributor
timestamp: March 25, 2015, 03:56:35 pm
content: Quote from: BloodyCactus on March 25, 2015, 02:02:53 amOnly if you need to do a partial screen update though. If you are re-drawing the whole screen, you can simply delay the flip until you are done doing whatever you are doing.

author: sentry7
author_rank: Regular Contributor
timestamp: March 25, 2015, 04:39:30 pm
content: Hey guys,So I did a test to see what certain resolutions would look like on an LCD TV. I connected a laptop to one of the LG TVs we have at the university and set up multiple resolutions. I was thoroughly impressed.I think I want to settle on 1280x768; this looked really good on the big screen. As far as implementing this is concerned, I am willing to step outside of my DIP chip/breadboard playground and go into a FPGA design.If I do 8 bits per pixel, then that's 8(bits/pixel) * (1280 * 768)(pixels) = 7864320 bits = 960KB?

author: Scrts
author_rank: Frequent Contributor
timestamp: March 25, 2015, 09:53:02 pm
content: Quote from: sentry7 on March 25, 2015, 04:39:30 pmAnd that will be monochrome? Otherwise it's 24bits/pixel. Why don't you want to go with HD resolution? It's 1280x720.Also you'll need triple buffering, so check how much bandwidth you need.

author: sentry7
author_rank: Regular Contributor
timestamp: March 25, 2015, 10:13:49 pm
content: Quote from: Scrts on March 25, 2015, 09:53:02 pmMaybe I'm missing something, but why must it be 24bpp if not monochrome? Is that just HD color depth?I'm looking at the timing table for 720p (http://www.3dexpress.de/displayconfigx/timings.html). The bandwidth is specified as 74.2MHz. What does the bandwidth specify?

author: hamster_nz
author_rank: Super Contributor
timestamp: March 25, 2015, 10:28:19 pm
content: Quote from: Scrts on March 25, 2015, 09:53:02 pmWhy, why and why?He might need only RGB 3:3:2? Which is pretty common for home brew analogue VGA outputs. I've even implemented a three bit 720p HDMI (not DVI-D) output just for fun.And triple buffering may not be needed, depending on what he is trying to do. You can do scrolling shooters with a frame buffer that is slightly larger than visible resolution - just update the background out of the frame and move the sprites and/or display window during the blanking interval.Triple buffering is only needed really needed if you intend to redraw any non-static areas for every frame and don't want to stall the drawing engine and you also want to lock the frame switch to the display refresh. Double buffering is enough if you just don't want to see something on the screen as it is being drawn...PS. The 74.2MHz specifies the pixel clock - you need to multiply that by bytes per pixel to get the peak memory bandwidth required for display. The average memory bandwidth is hres*vres*fps*bpp/8, or 55,296,000 for 1280x720@60, 8bpp. The difference is due to the blanking intervals.

author: sentry7
author_rank: Regular Contributor
timestamp: March 25, 2015, 10:46:55 pm
content: Quote from: hamster_nz on March 25, 2015, 10:28:19 pmUnderstood. So just locking in on what I want, RGB [3:3:2], 60Hz, 1280x720, double buffered. In order to achieve these, I need (2 * 900KB) of RAM clocked @ 55,296,000Hz?

author: hamster_nz
author_rank: Super Contributor
timestamp: March 26, 2015, 12:34:05 am
content: Close.Capacity -yes, you will need about 2MB of storage at a minimum - a 32Mb (4MB) memory chip would be ideal.if you have less memory bandwidth than 75MB/s you will need some buffers to even out the bandwidth requirements, but if you have less than 55MB/s you will not have enough bandwidth to send pixels to the display, no matter how much buffering you use.If you have 75MB/s of memory b/w you have enough bandwidth to update the display, and about 20MB/s during the blanking intervals where you could update the contents of the frame buffers.So the lowest spec you should consider is a 8-bit wide (x8) static RAM running at 100MHz, where a little over half the bandwidth has to be used for updating the display.A better bet would be a 32Mb x16 wide static RAM, and you could clock it at the speed of the display's pixel clock 75MHz, allowing everything to be run off of the same clock signal (a good thing for a first design!).

author: sentry7
author_rank: Regular Contributor
timestamp: March 26, 2015, 03:26:01 pm
content: I'm certainly getting a definite idea of what I want to do with this design.I found this memory on Mouserhttp://www.mouser.com/ds/2/198/42S16100E-258389.pdf. It's only 16Mb, but I could chain two together; maybe set up some latching in the memory control block. I really don't want to deal with BGA packages; they don't seem like a lot of fun.By the way, I drew up this very rough block diagram of the design. Just wondering if this is a good general structure for a console. This was based off my previous GPU-style system.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 26, 2015, 04:03:56 pm
content: You're targeting SDRAM, so you must think of SDRAM controller efficiency too. You also must understand how this type of memory works. If you'll do random reads and writes, then the performance will be extremely poor, so you must think how to do aligned writes to the memory, so at the end of the write there could be a refresh issued. You must also take write and read times into consideration. You need to have enough time budget to do a read or write burst, so you won't catch up yourself don't having time to write to the memory, because you must read it constantly at a pixel clock without possibility to interrupt that. This ends up in having a higher clock rate than your pixel data. If you want to use 16 bits memory interface, you should also think that writing only 8 bits at once would be a waste of bandwidth.I've written my own DMAs in the FPGA, I've also used lots of buffering for various applications, so usually you still have FIFO before the memory for the writes and FIFO after the memory for the reads, so you read from the FIFO at a pixel clock rate, but burst data into FIFO from the SDRAM at a higher frequency. Same on the write side.

author: marshallh
author_rank: Unknown
timestamp: March 26, 2015, 07:18:01 pm
content: It's not that hard. Just make a simple FSM to do activate-read/write cycles and precharge yourself at the end. If you're doing fixed video data like a framebuffer you dont' even need to refresh! (Well, you should anyway)

author: sentry7
author_rank: Regular Contributor
timestamp: March 26, 2015, 10:38:27 pm
content: My final questions (maybe) for this are where can I learn to get started with FPGAs and where can I get the best, cheapest chips. I've been looking into the Xilinx Spartans. Looks like they range anywhere from about $28 to $52. Is this the typical price range?

author: helius
author_rank: Super Contributor
timestamp: March 26, 2015, 10:55:24 pm
content: low-cost FPGAs from Lattice are available as low as $2 in single quantities. (ICE40LP384-SG32)