CPLD or FPGA, please help

[lawrence11]

Ok, Next question for Brian.

Lets say I have dvi/hdmi resolution 1920x1200. The highest single link scenario. The one that reaches 165mhz clock speed.

On the decoded side, I have 165 mhz/8=20.62 mhz in 24 bit parallel form.

Is 55 ns SRAM fast enough to buffer a screen?

Or do I need 10ns SRAM?

Dam, I think this is starting to smell like I need DRAM. My FPGA will be 20% full and I am overspending on SRAM because I am too lazy for DRAM. Dram looks like a pain in the ass.

I need a good DRAM page that explains everything in perfect detail, maybe I can cook up something in CMOS and make a FPGA version.

[asmi]

Ok, Next question for Brian.

Lets say I have dvi/hdmi resolution 1920x1200. The highest single link scenario. The one that reaches 165mhz clock speed.

On the decoded side, I have 165 mhz/8=20.62 mhz in 24 bit parallel form.

Is 55 ns SRAM fast enough to buffer a screen?

Or do I need 10ns SRAM?

This is not the way it works. Pixel clock "clocks" pixel starts, data lanes send 10 bits each (8 bits of payload in 8b/10b encoding) during single pixel clock period. So you would get 24bit stream of pixels at 165 MHz (assuming incoming stream is 8:8:8 RGB). But HDMI transmits "data" during blanking too, so if you only interested in pixels, you can "stretch" the stream a bit (make it slower) using FIFOs at expense of eliminating these blanks.

[lawrence11]

Ok, Next question for Brian.

Lets say I have dvi/hdmi resolution 1920x1200. The highest single link scenario. The one that reaches 165mhz clock speed.

On the decoded side, I have 165 mhz/8=20.62 mhz in 24 bit parallel form.

Is 55 ns SRAM fast enough to buffer a screen?

Or do I need 10ns SRAM?

This is not the way it works. Pixel clock "clocks" pixel starts, data lanes send 10 bits each (8 bits of payload in 8b/10b encoding) during single pixel clock period. So you would get 24bit stream of pixels at 165 MHz (assuming incoming stream is 8:8:8 RGB). But HDMI transmits "data" during blanking too, so if you only interested in pixels, you can "stretch" the stream a bit using FIFOs at expense of eliminating these blanks.

I think you are confused, the internals of the lcd does not work at those speeds.

On the decoded side the speed is slower.

[asmi]

Well personally I'm rarely doing anything particularly high speed. My own FPGA projects are mostly replicating 40 year old tech, 12 MHz is "fast".

That's what I was doing about 2 years ago as well. But I wanted to do progressively more ambitious things, and now I work on 6 layer boards with 5Gbit transmission lines and DDR3L-800 interfaces Who knows what will it be another 2 years from now

[asmi]

I think you are confused, the internals of the lcd does not work at those speeds.

On the decoded side the speed is slower.

I'm talking about DVI/HDMI interface. It works as I described above. Just multiply resolution by framerate, and you will see that it needs to run at least at 1920x1200x60=138.24 MHz to physically refresh each pixel. HDMI interface will run at higher clock rate to allow for blanking. At 165 MHz pixel clock each of three HDMI data lanes will transmit data at 165x10=1650 Mbit/s ("on-the-wire" speed), or 165x8=1320 Mbit/s of "payload" data rate. This is why HDMI cables are so darn expensive.

[nctnico]

Ok, Next question for Brian.

Lets say I have dvi/hdmi resolution 1920x1200. The highest single link scenario. The one that reaches 165mhz clock speed.

On the decoded side, I have 165 mhz/8=20.62 mhz in 24 bit parallel form.

Is 55 ns SRAM fast enough to buffer a screen?

Or do I need 10ns SRAM?

This is not the way it works. Pixel clock "clocks" pixel starts, data lanes send 10 bits each (8 bits of payload in 8b/10b encoding) during single pixel clock period. So you would get 24bit stream of pixels at 165 MHz (assuming incoming stream is 8:8:8 RGB). But HDMI transmits "data" during blanking too, so if you only interested in pixels, you can "stretch" the stream a bit using FIFOs at expense of eliminating these blanks.

I think you are confused, the internals of the lcd does not work at those speeds.

It does. Do the math. 1920x1200 -> add some sync time -> 2100x1300x60Hz=163.8Mhz. That is the pixel clock and for each cycle you transfer 3 bytes in parallel so the total data transfer rate is 491.4MByte/s. For these kind of speeds a Spartan6 + DDR memory would be a good choice. At 400MHz a 16 bit DDR memory can transfer 1.6GB/s (in bursts).

[asmi]

For these kind of speeds a Spartan6 + DDR memory would be a good choice. At 400MHz a 16 bit DDR memory can transfer 1.6GB/s (in bursts).

I don't think Spartan-6 SERDES can run that fast. Because even faster Artix-7 has a maximum "on the wire" data rate of 1250 Mbps in 10:1 DDR mode (for speed grades -2 and -3). At least I couldn't get it to "place&route" without timing errors when I attempted to run it at FullHD (145 MHz or so) - I had speed grade 2 device on my board.
Just checked - S6 can only go up to 500 Mbps for -1 speed, 950 Mbps for -2, 1050 for -3N and 1080 for -3.
But in any case memory controller is only present in S6 devices in BGA package. And if you want to run DDR3 at 400 MHz, you will need fastest -3 speed grade, which is expensive.

[nctnico]

For these kind of speeds a Spartan6 + DDR memory would be a good choice. At 400MHz a 16 bit DDR memory can transfer 1.6GB/s (in bursts).

I don't think Spartan-6 SERDES can run that fast. Because even faster Artix-7 has a maximum "on the wire" data rate of 1250 Mbps in 10:1 DDR mode (for speed grades -2 and -3). At least I couldn't get it to "place&route" without timing errors when I attempted to run it at FullHD (145 MHz or so) - I had speed grade 2 device on my board.

You don't need SERDES. Just the built-in DDR memory controller. Note I wrote 1.6GB as in GBytes/s and not Gb/s as in Gbit/s.

[asmi]

You don't need SERDES. Just the built-in DDR memory controller. Note I wrote 1.6GB as in GBytes/s and not Gb/s as in Gbit/s.

How are you going to deserialize HDMI stream without SERDES? Some kind of external receiver IC?
Attached is screenshot from S6 datasheet.

[nctnico]

Get the Spartan 6 with GTP transceivers. Those should do the trick. http://www.xilinx.com/support/documentation/application_notes/xapp1077-phy-hdmi-rx-gtp.pdf

[asmi]

Get the Spartan 6 with GTP transceivers. Those should do the trick. http://www.xilinx.com/support/documentation/application_notes/xapp1077-phy-hdmi-rx-gtp.pdf

That rules out TQPF packages, as well as two-layer boards. The minimum is XC6SLX25T in CSG324 or FGG484 package.

[lawrence11]

Dam, you are right, total miscalculation by me.

165mhz clock but 1.65 Ghz data rate on those 3 wires RBG.

This idea has just hit the can, how can I even buffer anything at this speed.

I need 3ns RAM with super low resolution.

[asmi]

This idea has just hit the can, how can I even buffer anything at this speed.

I need 3ns RAM with super low resolution.

It will need to be rather large too as a single frame is 1920x1200x3=6.6 MBytes, or 8.8 MBytes if you don't fancy packing 24bit data into 32bit interface words and would rather accept 25% overhead to gain pixel alignment to 32bit boundary (this is very common because it makes accessing individual pixel much more efficient). Also please remember that you will probably need to read from memory at the same time as writing to it, so 3ns may not be fast enough.
I would suggest to use DDR3 memory instead of SRAM (as it's much cheaper and has greater capacity) and send data in bursts to amortize access time overhead, but this approach has it's own pitfalls. You will need to use wide memory bus to get enough throughput.

[BrianHG]

As others have said:
The parallel data is coming in at the full 165MHz.  To process video at this rate, if you had ZERO wait state 24 bits of static ram, and only wanted to write exclusively, you need 6ns writes.  If you want to simultaneously read and write to your memory, you need a zero wait state of 3ns.  Figure under 2.5ns 24 bit DRAM running at least at 400MHz with at least 4 full page cache rams, 2 read, 2 write running at the full 400MHz on the DRAM memory side, 165MHz on each video in and out side.

Helpful hint (for regular 24bit DVI/HDMI):
1080p @ 60Hz delivers 148.5 million 24bit bit pixels a second.
720p @ 60Hz /1080i @ 60 Laced Hz delivers 74.25 million 24bit bit pixels a second.
480p @ 60Hz delivers 27 million 24 bit pixels a second.

You need a DVI decoder IC unless you go to a FPGA which can do 3 parallel 3GB/sec receivers, plus a fourth for the reference fame clock, and even then, you still need a receiver cable length equalizer amp circuit, preferably with a reclocker not to mention the HELL of getting the decoder parallel deserializer, with data skew allowance between the 3 channels, software working.  It's bad enough setting the I2C controls on some of the DVI/HDMI decoder ICs alone, even though they advertise that they do everything on their own.

If you are going with small PLDs, 1 you would be forced to use a DVI decoder IC most likely from TI or Analog Devices.  Unless you go for a huge IO count, complex ram controller and everything else, with only 101 IOs on a 144 pin QFP, I would say only wire 12 bit video and live with a crummy image, or, maybe even 16bit.  Otherwise, you need to find at least a 240 pin QFP and some fast DRAM running at least at 200MHz DDR, or 400MHz data with 48 bit with a partial line cache within the PLD, or, 24 bits ram, say 500MHz, with at least 4 full lines of video cache on the PLD if you plan on generating a picture out while receiving a picture in simultaneously.  You can relax these values quite a bit if you are only storing a picture, or, outputting a picture, but not both at the same time.

1920 x 24 bit x 4 lines = at least 196608 bits of ram just for line buffers.

This is not impossible, however, I would think you need to go to a large 480 pin BGA FPGA with 666MHz DDR2/3 ram at 64 bits support at a minimum to attempt simultaneous realtime video capture and playback.

My scalar uses 2 x 64 bit SODIMM modules and has a 780 pin BGA FPGA, but, it supports 2 simultaneous 30 bit video inputs with 30 scalable video out with picture-in-picture support.

[BrianHG]

I thought you just wanted to trap some screen colors in the DVI pictures.  Without picture storage, if you just want to respond to a bunch of data, at least a few pixels fat/wide, or single pixels spread out across the screen, a single PLD and my example code can handle that, even at 165Mhz, though you still need a 5$ DVI decoder (converts multi GHz DVI serial streams to parallel 24 bit color with 165 MHz clock, picture enable and H/V sync).  Even if your data codes are 1 pixel wide, the MAX10 PLD from Altera will decode and output your 20 decoded signals with ease.

Holding a 1080p picture and generating a 1080p picture will be outside the scope of the solutions so far.  Holding a line of video, or a 10kb-40kb of pixels inside the PLD is possible, but the 40kb version gets expensive as you are going up in PLD size.  FPGAs typically have 10x-50x the internal memory, but now you need a boot-prom and core voltage regulators and larger memory like that still costs more $.

[BrianHG]

To give you an idea, here is a photo of the CAD of the heart of my video scaler from 6 years ago, kind of overkill for your app, but it will help give you scale.  If you want to record and playback 2 different 165MHz DVI frames simultaneously, you will need at least 1/3rd of my attached image: The SODIMM modules were 500MHz DDR2 laptop ram modules.  It took almost 2 years to get the firmware working really good, though it did do image resizing, zooming, shrinking, cropping, scan-rate and video mode conversion, de-interlacing, color processing, image enhancement, picture-in-picture, ethernet linkable, external sync locking, test reference images, frame-store, stand-alone and PC controlled operation...

[NorthGuy]

The original post doesn't say anything about storing pictures. Doing what the OP has first asked and storing/altering pictures are two different tasks which require completely different hardware approaches.

[BrianHG]

The original post doesn't say anything about storing pictures. Doing what the OP has first asked and storing/altering pictures are two different tasks which require completely different hardware approaches.

Just read a few posts above from the 'OP' himself:
https://www.eevblog.com/forum/microcontrollers/cpld-or-fpga-please-help/msg1410584/#msg1410584
He added to the topic/asked about storing the image data...

If he just wants to store the decoded codes he is receiving on a PLD, not the full picture data, he has a chance.  If he wants the full 24 bit original photo, it's no longer so easy unless he want to scan in a few lines at a time into slower memory.  This means the screen image will need to be held still and it would take 8 frames in time to store the picture with 8x slower memory, though the stored data will be in vertical chunks and will need unchunking, but, 3x 8bit DDR2 dram chips with a larger PLD to accommodate a bottom end ram-controller would work if he just wanted to store a few frames coming in, then, play them back.  IE, store, or, play, not store whats coming in now and play what was recorded earlier simultaneously.  He wont have the spare 20 IOs for whatever the 20 decoders are being used for, so the 20 decodes will be needed to be used inside the PLD, with at least a few spare outputs, unless he foregoes having a video output, or reducing his frame-store to 5:6:5 16bit color.

[lawrence11]

I'd like to say my idea is flowing in a natural way.

Discovering things as I go along, with the help of the internet.


I need to "save a single frame", Then analyze that with an fpga process as a pre-filtering, then do stuff with my microcontroller. Then maybe like 4-5 frames later, Catch the beginning of a new complete frame and analyze. Repeat process. Whatever happens to those in-between frames is of no consequence or use.


What BrianHG provided will be of big help, I need to pickup these pixels at my own speed. I was gonna do this but it just got more complicated because I dont understand these damn SDRAM controllers.

Where in the world can I just order this up?

I need need a chip that is Soc and not for IP software bs I have to download. Or this could be good, if my max10 can be fast enough to be a sdram controller as well as my pre-filtering. In this case I will sign those papers.

I was thinking of using 2x of these, can 2 of these  DDR SDRAM (1st gen) be fast enough to buffer a frame of 165mhz dvi data, the max single link speed?

https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?FV=8e80070%2C142c137f%2Cffe00306%2C2380617&mnonly=0&ColumnSort=2042&page=1&stock=0&pbfree=0&rohs=0&cad=0&datasheet=0&nstock=0&photo=0&nonrohs=0&newproducts=0&quantity=&ptm=0&fid=0&pageSize=25

Is 200mhz enough? Access time is 700pS or is "Write Cycle Time - Word, Page" the limiting factor ? Because even DDR3 has "Write Cycle Time - Word, Page" of like 10nS

[BrianHG]

Normal DDR2 ram requires a complex power-up cycle.  Also remember, you need a row address, then you can burst a small packet on the column address.

You need to run these devices at 2.5v which means reading clearly in the MAX10 PLD how to separately power a bank of IOs at 2.5v for your memory section.  You will now also need to use 2 of the PLL dedicated outputs to differentialy drive the differential clock of the DDR2 ram and don't forget you need to worry about refresh cycles and you will need to use the PLD's internal memory for caching/smoothing out the chunky access characteristics of DRAM since video pretty much flows continuously without pause.  There is also a sophisticated power-up procedure and cycles you need to do before using the chips.  The kind of Verilog/VHDL programming involved is way beyond what you can achieve in any short order.  You will need to find out if Altera provides a DDR2/3 DRam controller IP core for the MAX10, or, if you can find one third party for free.  Otherwise, this costs $ for third party controllers...  You now begin to need to think of using a larger MAX10 instead of the smallest one, but you won't know until you program your core in Quartus.

Assuming you are using the MAX10 -8, slowest version, you can run the internal cache memory at 200MHz, run 2 in parallel giving you 400MHz throughput.  The IOs are rated at 300MHz.  24 bits or 32 bits of DRAM (2x 16bit chips) running at 150MHz DDR, ie 300MHz would be fast enough for single direction access + a second parallel CPU access at the same time.  If MAX10's 300MHz means it can do DDR as well, or 600MHz, or maybe somewhere in between like 400MHz throughput, you can get away with 1 x 16bit DRAM chip.

[BrianHG]

Writing a single page/word, better call it address row/column, you will need to write multiple columns is a chunk to get the throughput you need, hence the need for the PLD's onchip static ram.  If you are doing your own ram controller, I would recommend using enough PLD on-chip ram to store 2 lines of video.  That would be 2048x24 bits, by 2 lines.  Once one line buffer is filled, and the second one is currently being filled, the first one will be page bursted completely into 1 page or row of you DDR Ram giving you the RAS setup time, then, completely clock all the data out to the column, then precharge.  This will outpace your video coming into the second line buffer.  These 2 line buffers will eat up 55296 bits on the PLD, or, 6 M9K blocks.

Running DDR3 with a 300MHz controller on a -6 MAX10 mean 600MHz reads/writes per second.  You will need at least 16 bits at this speed which will give you 1.2GBytes/sec burst speed (assuming you will just pack your pixels as 32 bits into every 2x 16 bits of ram instead of the added difficulty of packing 24bits color into 16bits or ram, or, every 4 24bit pixels packed into every 6x16bit words...), but, you need to go to a 256 pin BGA package.  You cannot use MAX10 144 pin package with high speed DDR3/2 controller.  You will only need 1 16 bit ram chip and you can use Altera's ram controller IP which is available for the MAX10 series.

Altera's MAX10 complete handbook: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/max-10/m10_handbook.pdf

Goto section: MAX 10 External Memory Interface User Guide

This is now the cheapest device you can use:
-8 (I think around 200Mhz ram controller, or 400Mhz data throughput)
https://www.digikey.com/product-detail/en/altera/10M04DCF256C8G/544-3050-ND/5044224
-7 (Around 250Mhz ram controller, or, 500Mhz data throughput)
https://www.digikey.com/product-detail/en/altera/10M04DCF256I7G/544-3051-ND/5044225
-6 (No Stock at Digikey)

You also now need a separate core voltage unless you run everything at 1.2v.

[lawrence11]

IP is Available for free?

No way I am going to code this, never ever. I need this IP free, either it be Lattice, Xilinx or Altera. Or anything free source.

Maybe I wont be going Max10 now... It depends if it is free.

Also, since I was gonna have my own  memory controller anyways, I was gonna use 6x74hc161 Binary counters for SRAM, I can live with a dedicated SDRAM controller. and my own dedicated
color filtering, so 2x FPGA does not bother me.

I cant believe this, ST micro electronics just gave us a free pro compiler Atollic Truestudio and we cant get a frikkin DRAM controller for free?

Can I get a faster design by using 4x of these DDR chips? Would this help with refresh timings?

I can handle writing a vertical line on one, then on the other, in alternative fashion.

[NorthGuy]

I need to "save a single frame", Then analyze that with an fpga process as a pre-filtering, then do stuff with my microcontroller. Then maybe like 4-5 frames later, Catch the beginning of a new complete frame and analyze. Repeat process. Whatever happens to those in-between frames is of no consequence or use.

Any design starts from what you need to do. Once you have clear understanding of the whole process, you decide how do you want to do this.

When you formulate your goal as "analyze that with an fpga" or "do stuff with my microcontroller", you thereby make the design decisions even before you formulating what are your goals. May be it is a good idea to do everything in FPGA, or everything in microcontroller. What is best depends on what sort of processing you need.

Looking at the conversation, your design is nowhere near the point where you should discuss technical details. It is better to think in terms of data flows and processes until the whole picture is more clear. Then you may decide what components you need to process the data flow. It is way too early to choose between FPGA or CPLD, decide what type of memory you need etc.

It is very hard to discuss any design without knowing what exactly you try to accomplish. You discuss storing the picture, but this  calls for DDR memory thus involving either FPGA or a big CPU which can work with DDR2/3 memory. But may be your data flow is such that the storage may be avoided? For example, if the whole idea of storing  the picture is to pass it to MCU for processing, then you may be able to process everything in a single place and avoid any storage altogether.

[BrianHG]

Here:
https://www.eevblog.com/forum/microcontrollers/altera-max-10-external-memory/msg578607/#msg578607

I would ask Altera to be sure...

You just need 1 16 bit DDR3 ram chip.  That's fast enough even with the slowest -8 PLD, but, I would still go to the in between -7 speed for that little extra head-room.

This 1 chip is all you need:
https://www.digikey.com/product-detail/en/issi-integrated-silicon-solution-inc/IS43TR16640B-125JBL/706-1374-ND/5319933

If you must go DDR2, then this guy:
https://www.digikey.com/product-detail/en/alliance-memory-inc/AS4C16M16D2-25BCN/1450-1273-ND/5361420

[lawrence11]

I know how SRAM works, I used it before and tested it. Its beautiful, I give it an adress, sink some pins, bingo, next address, new data.

I wanna make SDRAM appear like SRAM, and forget about it.

Step 1, I get an SoC from TI, the TFP401, this chip is the starting point.

Then Step 2, I try to save this image inside some DDR SDRAM, either it be DDR,DRR2,DDR3 is fine with me.

My only design goal right now is to save a frame.

I was gonna buy 45$ worth of SRAM so I dont have to deal with this SRAM, but then I realised it could never work, since write time is 10ns and I may receive data that surpasses this.

Now I have cheaper memory options.

I need to either get free IP core or free source code will allow me to use this DRAM and forget about it.

By law of elimination, I need my DRAM controller to me an FPGA, since this chip cannot be bought.

Analyzing my options. Getting 2000$ per year software just to get some DRAM IP is out of the questions. I'd rather pay company 5$more per chip that has the software, than 2000$ right now for some software I barely know how to use.

I wanna take technology I cant use and dont understand, and use it. Thats about it. Any solution that requires deep knowledge is not a solution.