CPLD or FPGA, please help

[lawrence11]

Hello, please help.

 

For my electronic design, I am experimenting what device will be better, FPGA or CPLD, I wish to compile and determine the amount of space this takes on a device then judge my needs. I am trying to do as per this image, I have simple task of finding right 3 byte condition in parallel data stream, coming at about 12-22 Mhz, lets say I will have about 50-100 of these 3 byte conditions. These 50-100 or so conditons will in turn, signal 20 or so different  type events ( pins). So some  event pins will work for a multitude of 3 byte conditions.

 

Can anybody code for me a simple example?  I am mostly self taught C programmer, please understand my difficulty.

 

For example: combination 144,136,88  ( 0x009000800058) activates a pin, combination 0,196,0 (0x000000C40000) activates another pin.

 

As per the Drawing, thank you.

[Buriedcode]

The lines between CPLD and FPGA have been somewhat blurred over the past decade.  For the most part it sounds like what you wish to do a "CPLD" will do just fine - just requires lots of IO and some glue logic.  With that said just to store or compare 3 bytes is 24 macrocells, so something like a 64 macrocell CPLD might not cut it.   It seems its the speed of 12-22Mhz that makes using programmable logic over a microcontroller preferable.

However, some devices are closer to FPGA's (like the lattice MachXO2/XO3 or the more CPLD-like Altera MAX V) but they still have on-board config memory like older CPLD's. These have plenty of resources, are pretty cheap, easy to work with, and lots of IO options.  What can make a big difference is the voltage level you're working with. Old 5V-TTL would require either 5v device or, more likely a 5v-tolerant device - both of which are no longer supported so you'll be looking at legacy devices, or a very fast microcontroller.  For 3.3v or below, almost all modern CPLD/FPGA's will be fine.

The only real downside with using programmable logic, be it FPGA or CPLD is the steep learning curve, and the large design software (expect 4gig+ for a free suite from any vendor).

[lawrence11]

Hello, thank you for your response.

O my, I guess a CPLD is out of the question. I will be needing an FPGA then, an FPGA that is "CPLD-like".

For me, a TQFP 64 pins is sufficient, the least pins the better.

I know they are difficult to learn, that is why I need a concrete example for exactly my needs, and nothng else. Monkey see, monkey do.

Verilog or VHDL, whatever is fine.

thank you.

[james_s]

If I understand your question, a CPLD should do just fine. Generally you move up to an FPGA if you need things like an internal soft processor core, RAM, ROM, PLL's, multipliers, DSP, that sort of thing. As has been mentioned, the line between CPLD and FPGA is not as cut & dry as it used to be.

[maginnovision]

I feel like an Atmel CPLD would work just fine. Why is it 24 macrocells to store and compare 3 bytes?, why would you need to store them anyway?

[james_s]

Altera and Xilinx both offer inexpensive CPLDs with tens to hundreds of macrocells. Lattice is the other major player, I use Atmel microcontrollers but never looked at their programmable logic offerings.

[Buriedcode]

Well perhaps you wouldn't need to store them - comparison is basic AND logic, as you've shown in your first post.

But you also mentioned parallel - I assumed, perhaps wrongly that you were getting 8-bit wide parallel data, one byte at a time.  And a macrocell, in older CPLD terms, is generally a flipflop, with some combinatorial logic on the input, so should you wish to store say, two bytes, that 16 MC's used. 

You mentioned you require "50-100 conditions" to me, that means you are comparing your 24-bit input, to 50 to 100 possible patterns, with 20 outputs.  That is a fair bit of logic.  As you appear to have Xilinx's ISE, you could knock up a quick verilog (or VHDL, I'm a verilog guy though) file that compares your inputs to your required constants.  I'm pretty sure you will find it uses far more resources than even a 72 macrocell device - but certainly not requiring a huge device.  Then there is meta-stability - your 24 inputs may not instantly change at exactly the same time, so simple combinatorial logic may change its outputs several times as the inputs stabilize.  This is why often (but not always) inputs are clocked in to registers, so that all get updated at the same time and your output doesn't radically change between input transitions.  This clock can of course be tens of MHz.  Or at least faster than rate of change at the input.

maginnovision mentioned an Atmel CPLD.  I could be wrong here, but those devices are over a decade old, and as such, probably expensive, and might be difficult to get the design software to work on modern OS's.  As I said, I could be wrong, never used Atmel programmable logic.  Whilst you don't have to use modern devices, it will make your life easier, and also be cheaper.  The only reason one would opt for legacy (as in no longer supported) devices would be if one requires 5V interfacing.

This project sounds almost ideal for getting started with programmable logic.  The task isn't particularly difficult, but it does require some knowledge of how the logic is implemented.  If you can't find any resources, I will try to knock up an example that checks for a few constants, and you should be able to modify it to your needs.

[james_s]

What I would suggest doing is design the thing first and test it in simulation, or if you prefer to play with real hardware (as I do) implement it in an FPGA since you know that will be much more than adequate. Then look at the resources consumed and select the cheapest part that it will fit. The toolsets I've used let you select a family and have it auto-pick the smallest device in that family.

[rstofer]

Deleted!

See BrianHG's code below.

[BrianHG]

To make this as simple as possible, I would write it in verilog.  For a beginner, I would make it look something like:

Code: [Select]

module decode_3x8bits_2_pins (clk, byte_in, pin_out_1, pin_out_2, pin_out_3, pin_out_4, ect...);

input         clk;
input [7:0] byte_in;
        output pin_out_1;
        output pin_out_2;
        output pin_out_3;
        output pin_out_4;

reg [23:0] big24bitregister;
reg pin_out_1;
reg pin_out_2;
reg pin_out_3;
reg pin_out_4;


always@(posedge clk) begin

big24bitregister[7:0]   <= byte_in[7:0];
big24bitregister[15:8] <= big24bitregister[7:0];
big24bitregister[23:16] <= big24bitregister[15:8];


output_pin_1 <= big24bitregister[23:0] == 'hFF3318;  // One time on event
output_pin_2 <= big24bitregister[23:0] == 'h0123CD;
output_pin_3 <= big24bitregister[23:0] == 'hAB2756;

example of separate on and off events for 1 pin....
       if  (big24bitregister[23:0] == 'h001265 || big24bitregister[23:0] == 'h552555)  output_pin_4 <= 1;  // turn on pin 4 under these 2 circumstances...
else if (big24bitregister[23:0] == 'h666333 || big24bitregister[23:0] == 'h000000) output_pin_4 <= 0;  // turn off pin 4 under these 2 circumstances...
...... ect.......

end
endmoduleNote, this verilog code is for ultra beginners...
Also, output pins are delayed by 1 additional clock...

You can expect over 100MHz performance on the cheapest slowest PLD or FPGA today, even filling in all 20 outputs compares.

[lawrence11]

Ok, thank you all for your response.

The CPLD is there to flag a specific color condition from a pixel stream, decoded DVI or HDMI signal. 24 bit wide  data stream, aka I need 24 inputs + maybe a clock, so maximum 25 inpuits, is this clear enough?

I dont understand how nobody cant help me out because my project is not "well defined". I could use Logic gate from 74HC series and it would suffice, but it would be way too cumbersome and big.

My need is very very simple, and I provide all the information.

I cant decide on CPLD vs FPGA nor advance in my project without this code snippet for these. Simply copy paste my Hex numbers into your code, and it should be done, for an expert this should take 1 minute.

I cant compile anything and see the space used without this tiny bit of help. I cant estimate my needs without the software telling me.

See the image, all is explained there clear as day.

Edit: Brian, I just saw your post, thanks, will check. Anybody else?

[BrianHG]

Ummm, are you trying to trap single pixels?  Or groups of pixels with a set of colors.  My example only covers a single 8 bit wide data path, or 8 bit color by 3 pixels wide.  You would need to change my [7:0] to [23:0] for 24 bit parallel input and change the big24 register's [23:0]  to [71:0] and the appropriate shifts to scan a block of 3 serial 24 bit pixels.  Trapping single pixels removes the big24register stuff completely and you only need the 'if' and to look at the data input.

Note, you can only expect such precise values to come from a PC video card in RGB mode and a true dumb DVI receiver IC and ALL PC COLOR correction disabled, or gamut color correcting tables off.  The smart DVI receivers sometimes shift, or miss some colors.  I've been through this.  Never expect such accuracy from HDMI's component mode, or 4:2:2, or any compressed color modes, or, newer Analog devices DVI/HDMI receivers which have any type or color controls, even if they are disabled.  This is the way it is and it sucks, but, that's life.

[lawrence11]

You are right Brian, I should watch out for the proper terms, there is in fact "3 pixels per pixel"...Lol

I am trying to trap, the right color, all 3 bytes must be correct, that is why they are AND the 3 of them.

I throwing out there another color condition, 0,196,0 , just so I can see the different syntax when the output pin differs.

I now notice that I wrote hex wrong,

0x009000880058 should be 0x908858, or simply, 144,136,88. I apologize for this as it seems some people got confused.

Edit: Thanks Brian for that information, its ok Brian if it misses a bit, but on average I think I will detect the required condition. The error rate should not be so bad in lower resolutions since the serial data from the PC card will not be so fast. I understand that there is no error correction, but on average I think I will be ok and its not super important to get 100% right.

[rstofer]

Skip what I wrote, it doesn't apply.

BrianHG has a nice approach.  He recognized the problem as strictly combinatorial whereas I took the ',' to mean there was a stream of data that had to be accumulated.

[Bruce Abbott]

I am trying to trap, the right color,

Why?

[lawrence11]

Why not?

[BrianHG]

Ok, trapping single colors, or even ranges is easier than the program I gave you, here is the simplified version:

Code: [Select]

module decode_24bits_2_pins (clk, pixel_in, pin_out_1, pin_out_2, pin_out_3, pin_out_4, ect...);

input         clk;
input [23:0] pixel_in;
        output pin_out_1;
        output pin_out_2;
        output pin_out_3;
        output pin_out_4;

reg pin_out_1;
reg pin_out_2;
reg pin_out_3;
reg pin_out_4;


always@(posedge clk) begin

        if  (pixel_in[23:0] == 'h000000)  output_pin_1 <= 1;  // turn on output pin 1 if black...
else if  (pixel_in[23:0] == 'hFFFFFF)  output_pin_1 <= 1;  // or turn on output pin 1 if white...
else if  (pixel_in[23:0] == 'h00FF00)  output_pin_1 <= 1;  // or turn on output pin 1 if green...
else if  (pixel_in[23:0] == 'h00FE00)  output_pin_1 <= 1;  // or turn on output pin 1 if slightly darker green...
else  output_pin_1 <= 0;  // turn off output pin 1 under any other circumstance

        if  (pixel_in[23:0] == 'h808080)  output_pin_2 <= 1;  // turn on output pin 2 if gray...
else  output_pin_2 <= 0;  // turn off output pin 2 under any other circumstance

        if  (pixel_in[23:0] == 'h0000FF)  output_pin_3 <= 0;  // turn off output pin 3 if red...
else  if  (pixel_in[23:0] == 'h00FFFF)  output_pin_3 <= 0;  // or turn off output pin 3 if yellow...
else  output_pin_3 <= 1;  // turn on output pin 3 under any other circumstance

        if  (pixel_in[23:0] == 'h0000FF)  output_pin_4 <= 1;  // turn on output pin 4 if red...
else  if  (pixel_in[23:0] == 'hFF0000)  output_pin_4 <= 1;  // or turn on output pin 4 if blue...
else  if  (pixel_in[23:0] == 'h00FFFF)  output_pin_4 <= 0;  // or turn off output pin 4 if yellow...
else  if  (pixel_in[23:0] == 'h00FF00)  output_pin_4 <= 0;  // or turn off output pin 4 if green...


...... ect.......

end
endmoduleThese 4 examples should tell you all you need to know about what a verilog program to cycle some IO pins would look like based on scanning a 24 bit color input stream.

[BrianHG]

I am trying to trap, the right color,

Why?

Optical screen codes to trigger hardware, like 3D LCD shutter glasses, or, begin and end capture of a segment of display, or, mute out a portion of a screen, or only send sections of a display area to one of 2 screens, or one side of a 3D glasses display buffer.  Note, I have 2 patents on these process way back in 1999 and 2003...  made me some $ at the time.

I also encoded firmware & software controls into the video coming out of the PC itself.  Something you can do with scanning for specific colors.

First 3D LCD glasses interface with external video page flipped cache from way back in 2000.

[lawrence11]

Awesome Brian, I love it that old guys that built stuff and saw things read these forums and answer me.

I have a few ideas myself, I am just a maintenance tech, I grease transmissions, etc. Simple work really, but there was a time where I love to solve CMOS puzzles.

Mosly for backup systems and recording how many tires were assembled, etc, and show it on a cheap 7 segment for the operators.

This is just an idea I got for something, currently experimenting.

[lawrence11]

Awesome code Brian. Just a few questions,  Does the reg give it a memory and you can only shut off the pin afterwards when its declared as reg? I thought this was pure combination with a CPLD, and by nature the output doesnt need to be told otherwise if its set high. Or are you coding this in a FPGA oriented style?

I am just trying to understand the reasoning, I have not decided yet on wether I will go CPLD or FPGA.

Also, I have a few bold questions.

module decode_24bits_2_pins (clk, pixel_in, pin_out_1, pin_out_2, pin_out_3, pin_out_4, ect...); module decode_24bits_2_pins  ?? Is this a pre-defined function, what are you telling here exactly? You seem to define the necessary I/O's for the logic, why is this necessary??

 input            clk;
 input   [23:0]  pixel_in;
 ?       output    pin_out_1;   why is there such a big gap here, is this just your coding style and tabulation?
        output    pin_out_2;
        output    pin_out_3;
        output    pin_out_4;

 reg     pin_out_1; So a pin is defined as an output but as a reg also??
 reg     pin_out_2;
 reg     pin_out_3;
 reg     pin_out_4;


always@(posedge clk) begin This functiions interacts with the input variable "clk" defined above and makes this pos edge? Simple as that? Awesome...

        if  (pixel_in[23:0] == 'h000000)  output_pin_1 <= 1;  // turn on output pin 1 if black...
else if  (pixel_in[23:0] == 'hFFFFFF)  output_pin_1 <= 1;  // or turn on output pin 1 if white...
else if  (pixel_in[23:0] == 'h00FF00)  output_pin_1 <= 1;  // or turn on output pin 1 if green...
else if  (pixel_in[23:0] == 'h00FE00)  output_pin_1 <= 1;  // or turn on output pin 1 if slightly darker green...
else  output_pin_1 <= 0;  // turn off output pin 1 under any other circumstance

        if  (pixel_in[23:0] == 'h808080)  output_pin_2 <= 1;  // turn on output pin 2 if gray...
else  output_pin_2 <= 0;  // turn off output pin 2 under any other circumstance

        if  (pixel_in[23:0] == 'h0000FF)  output_pin_3 <= 0;  // turn off output pin 3 if red...
else  if  (pixel_in[23:0] == 'h00FFFF)  output_pin_3 <= 0;  // or turn off output pin 3 if yellow...
else  output_pin_3 <= 1;  // turn on output pin 3 under any other circumstance

        if  (pixel_in[23:0] == 'h0000FF)  output_pin_4 <= 1;  // turn on output pin 4 if red...
else  if  (pixel_in[23:0] == 'hFF0000)  output_pin_4 <= 1;  // or turn on output pin 4 if blue...
else  if  (pixel_in[23:0] == 'h00FFFF)  output_pin_4 <= 0;  // or turn off output pin 4 if yellow...
else  if  (pixel_in[23:0] == 'h00FF00)  output_pin_4 <= 0;  // or turn off output pin 4 if green...


...... ect.......

end
endmodule

[james_s]

I don't understand what you're going on about with "FPGA or CPLD style", there's no difference in the style, an FPGA is just a really big CPLD which includes additional specialized blocks. Typically the CPLD is inherently nonvolatile while an FPGA requires a separate configuration ROM but that only matters in terms of building the hardware. If you could do it with a handful of TTL logic gate ICs then a CPLD will cover it easily. Assuming you don't instantiate RAM, ROM, clock PLLs or hardware multipliers you can compile the exact same code for a CPLD or FPGA provided the chip is large enough to hold it. Stop thinking about them as two different types of devices, they're the same thing, one is just stripped down optimized for simpler purposes.

[lawrence11]

I don't understand what you're going on about with "FPGA or CPLD style", there's no difference in the style, an FPGA is just a really big CPLD which includes additional specialized blocks.

Hey Thank you for your response. Good to know

I am a bit new with both of these to be honest, I was just watching some yt videos right now.

I am trying to figure out most optimal code, for the device, wich is still to be decided.

Decisions decisions.... Cost/speed/density vs timing speed and time delay issue.

[james_s]

You're spending way too much thought on a trivial aspect of the project. Cost doesn't matter at this point, you can get an FPGA or CPLD on a basic dev board for under $15 and when you're doing prototyping you can reuse it for other projects. The determining factor is going to be how large the synthesized logic resulting from the code is, which from what I can gather from your description it's not going to be very big. Once you have something that works, you can always optimize to a smaller cheaper part.

Download Altera Quartus II or Xilinx ISE and find some tutorials for VHDL or Verilog and learn some of the basics. I prefer VHDL personally but Verilog can describe anything VHDL can describe and vice versa, try not to get caught up in the strange religious debates people get in over language of choice. Get the software going, write some code and compile it, that will give you a good idea how big of a part you need to hold it.

[BrianHG]

module decode_24bits_2_pins (clk, pixel_in, pin_out_1, pin_out_2, pin_out_3, pin_out_4, ect...);

'decode_24bits_2_pins' is just the name I gave it, you can call it what you want....
'(clk, pixel_in, pin_out_1, pin_out_2, pin_out_3, pin_out_4, ect...)' is just a list of all the names of the inputs and outputs of the module.  When putting this into verilog code into Altera's Quartus, or it must be similar in Xilinx's compiler, you may ask the IDE to generate a block symbol for the 'decode_24bits_2_pins' & these are the names which will appear on your graphic editor symbol.

why is there such a big gap here, is this just your coding style and tabulation?
Just my style.  You only need 1 space.  I have large code modules where some lines, instead of just being an 'input', I have 'input unsigned'. or 'integer', or a whole other bunch of possible assignments or parameters, so when I code much more complex larger modules using all these types & definitions, everything looks neat on my screen.  You do not need to do this, especially for such a small simple program.  Also, it's just the way this forum seems to space the [TAB]s which I copied and pasted from some older work...

So a pin is defined as an output but as a reg also??
Yes.  Each output pins id a D-Flipflop clocked registered to that posedge clk input.  This is the only way you can make a number of circumstances where you set the output high, another set to clear the output + retain the previous state if no other state is met.  You can turn off the reg, but now, the output will be strict combinational un-clocked logic sensitive to input delays and setup timing of the routing on the PLD chip, making the output spike randomly as you inputs change.  Also, if you have only 1 valid set-point for an output and that appears for a single pixel, you may just end up with that output pulsing high for only a few nanoseconds instead of 1 full pixel clock time.  Having registered outputs to 1 clock will make all your outputs clean and synchronous to the posedge of the source clk.

If you want to output your 20 data pins in parallel with your 24 bit color data, I would add an output reg port 'pixel_out' and add the line in the code 'pixel_out <= pixel_in;'.  Now your 20 output pins will be decoded and timed with the same clock as your pass through pixel_out.  You will also need to buffer the DVI active_video data signal otherwise the screen image will be shifted to the right by 1 pixel.  You may also use the active_video data signal to disable your 20 decoded outputs since during the inactive video periods, the DVI RGB 24 bits retain their previous values or have random values or have digital audio values which you may not want your decoded 20 outputs to respond to.

[lawrence11]

but now, the output will be strict combinational un-clocked logic sensitive to input delays and setup timing of the routing on the PLD chip, making the output spike randomly as you inputs change.  Also, if you have only 1 valid set-point for an output and that appears for a single pixel, you may just end up with that output pulsing high for only a few nanoseconds instead of 1 full pixel clock time.

If you want to output your 20 data pins in parallel with your 24 bit color data, I would add an output reg port 'pixel_out' and add the line in the code 'pixel_out <= pixel_in;'.  Now your 20 output pins will be decoded and timed with the same clock as your pass through pixel_out.  You will also need to buffer the DVI active_video data signal otherwise the screen image will be shifted to the right by 1 pixel.  You may also use the active_video data signal to disable your 20 decoded outputs since during the inactive video periods, the DVI RGB 24 bits retain their previous values or have random values or have digital audio values which you may not want your decoded 20 outputs to respond to.

So for the first part,  I guess this is where the "always@(posedge clk) begin" comes in to to NOT make this strict combinational un-clocked (less reliable) design.

Last paragraph: You lost me there Brian... you mean Pixel in? Hmm... I dont think I need that, alot of this quacky idea will be problem solved in C, with my microcontroller. But its good to know.

[james_s]

"always@(posedge clk) begin" is the start of a process statement. This creates a D-type flip-flop triggered on the rising edge of the clock pulse, which in this case is a signal called "clk".

Teaching you Verilog or VHDL is beyond the scope of a forum post. If you read some tutorials that should answer most of these questions. I liked the free e-book "Free Range VHDL", perhaps someone can point to a similar lesson for Verilog.

[BrianHG]

Last paragraph, remember, all you 20 outputs will be computed in 1 clk.  All in parallel.  All the 'if' and 'else' all happen simultaneously.  But, there is still that 1 clk delay.  The PLD isn't instant.

What I am saying if a you are searching for a white pixel.  Once the pixel comes into the PLD and the clock cycles, your output will be set.  This may be fine for you.  Then everything is ok.

Say if you want to change that white pixel to another color, however, once you decoded your output pin, the next newer pixel is already coming into your PLD, the white pixel has already left.  I was only suggesting a way to output your white decoding output pin simultaneously with the white pixel data which came into the PLD at the previous clock by piping the 24 bit color data through the PLD as well, delaying it by 1 clock, so you can modify or mask out that white pixel data based on one of your 20 pin decoded outputs.  You do not need to do this unless you wish to manipulate the video picture data based on your 20 decoded outputs in perfect synchronicity.


Piping the entire 24 bit pixel through the FPGA means if there are enough gates, you can manipulate the video picture data, not just decode your 20 outputs.  Like, change contrast or color, even sharpen/blur/saturation and tint the image if your FPGA has enough gates in it.

[BrianHG]

Verilog basics and tutorial: http://www.asic-world.com/verilog/index.html
Basic guide to Verilog syntax and language structure, variable types, commands + examples.

On how to type you verilog programs into Xilinx or Quartus, just Google how to program verilog in Xilinx/Altera Quartus, or even search on youtube for a visual on how to enter code in Xilinx/Quartus.

[agehall]

Just build the code for the things you need, simulate and test it. If the compiled code fits in a CPLD - go for that. If not, you need an FPGA.

But I find it very hard to believe that you need anything other than a CPLD for this. As others have said, you are spending way too much time on a trivial aspect of your project - just get on with it and it will become very clear what you actually need.

[iMo]

I am a bit new with both of these to be honest, I was just watching some yt videos right now.

You have to start with something much simpler..
Buy a cheap CPLD board, learn the basics, try with verilog and get familiar with the tools/develepment chains..
A long way to go..

[agehall]

I am a bit new with both of these to be honest, I was just watching some yt videos right now.

You have to start with something much simpler..
Buy a cheap CPLD board, learn the basics, try with verilog and get familiar with the tools/develepment chains..
A long way to go..

My first CPLD project was a protocol converter for the CD exchanger in my car. Maybe not the prettiest VHDL, but it worked just fine. It doesn't have to be that hard, just break things down and work thru the problems...

[lawrence11]

I thank everybody for their participation.

For curriosity: This is a comment from the xilinx forums.

I think this design will call for an FPGA. I doubt that a CPLD (at least from Xilinx's range) will be big enough to handle 100 3-byte combinations, whereas their smallest "new" FPGA (Spartan 7 XC7S6) would do it easily.

 

Have you got a preferred implementation language (VHDL or Verilog)? You could probably do it in C via HLS if you had to, but HLS isn't really designed for toggling pins.

[james_s]

VHDL and Verilog are the two big HDLs (Hardware Description Language) used to develop for CPLDs and FPGAs. Verilog is more widely used in professional circles in the US while VHDL is more popular in Europe and academics. VHDL also seems to have a lot more hobbyist support and is my personal preference. Despite the passionate debates some will have, there is really no clearly superior language, it's like debating English vs German, they can both describe the same thing. Have a look around, try some basic tutorials in both and pick the one that makes the most sense to you.

Forget about programming languages like C, you're not writing a program, you're describing digital hardware. You have to get into the right mindset, a hardware designer, visualize logic gates, flip flops, latches, counters and such. You're using a special language to describe a schematic, you're not writing a sequential program. Tell yourself that as many times as you have to in order for it to sink in.

[NorthGuy]

I think this design will call for an FPGA. I doubt that a CPLD (at least from Xilinx's range) will be big enough to handle 100 3-byte combinations, whereas their smallest "new" FPGA (Spartan 7 XC7S6) would do it easily.

Spartan-7 has 6-input LUTs, so 24-bit input can be fed to 4 LUTs (24/6) plus one LUT to get the combined inputs from the first 6. It is 5 LUTs per color to find a match. 5 LUTs x 50 colors = 250 LUTs. Plus 20 to 100 LUTs for output. Thus you'd need about 350 LUTs. A good portion of these can be eliminated by the tools if there are colors with common bytes.

XC7S6 has about 3700 LUTs. Looks like huge overkill to me.

[james_s]

Just to put things in perspective, a tiny by modern standards Altera EP2C5T144C8 FPGA can contain a complete 8 bit computer system with a Z80 soft core, ROM, VGA controller, serial ports, SD card interface and boot the full fledged operating system CP/M with the only external semiconductor being a RAM chip and that consumes only about 70% of the FPGA fabric. When comparing to 74xx series TTL logic a small modern FPGA is a bit like a breadboard the size of a tennis court.

[lawrence11]

I understand Brian

[james_s]

You have the same learning ability as many of us, it's just a matter of taking the time. I spent probably 2 years tinkering with VHDL before something clicked and I finally got to where I could write the code for a project, fix a handful of typos and other dumb errors and it would compile and more or less work. FPGA development is difficult and has a steep learning curve, that's why so few people do it.

Xilinx and Altera are the two I'm familiar with, I've gone back and forth and have not found a real clear winner, both have quirks and advantages. Overall I think I like Altera's Quartus II a bit better than Xilinx ISE, and the (clone) programming dongles for the Altera hardware are much smaller and cheaper so that is another perk. Again don't spend too much time worrying about which vendor to use, the products are roughly similar, they all use pretty much the same code, it's easy to port from one to the other. The choice largely comes down to which software package you like better since you are locked into using the software supplied by the hardware vendor. Quartus and ISE both have free versions for personal use, keep in mind that at least with Altera you have to use an older version for some of the older parts that are still popular amongst hobbyists. 13.0 SP1 is the last version to support the popular Cyclone II series of FPGAs.

[james_s]

Go to digikey.com and use the parametric search, there are loads of CPLDs and FPGAs that meet your criteria. At this stage I would suggest using a basic development board rather than bothering with a bare chip, it will save a lot of time and the cost is similar. I've used the Xilinx XC9500 and Altera Max series CPLDs with good results. The Altera Cyclone II and Cyclone IV FPGAs are inexpensive and readily available if you need to step up to something larger. For now just buy something cheap and play with it.

[james_s]

What do you mean? The XC9500 CPLDs have IO pins that are 5V tolerant and 3.3V native, most of their FPGAs have IO that is selectable between several formats. Parts made by all the main vendors have similar specs in that regard.

[BrianHG]

Your going for the Altera Max 10 10M02SCE144C8G.
Nice choice, no boot-prom needed.  Only a single 3.3v supply.  144pin QFP.  101 IOs,
Don't need your static ram controller, just wire the PLD directly to the ram and program direct access.  Unless it is DRAM, then you need a DRAM controller firmware if you are trying to do a bunch of things on-chip.
You also get 10Kx9 onchip dual-port cache memory.

Figure 27 bits in for the video, 27 bits out.  24 Color, HS, VS, VENA. (Active video)
56 IOs.
20 outputs for your custom output pins.
+Use a dedicated clock pin for clk input. (Compiles better when using dedicated clocks for clocks and you get the use the PLL if you want.  You might consider using the dedicated PLL clk out pin also if you are passing video through the PLD) 
Total.
77 IOs going the route of additionally piping the video through the PLD, otherwise, you only need 48 IOs.

You can select different output voltage standards for different banks of IOs, like 3.3v, 2.5v, 1.8v, 1.2v.

IE, 1/4 of the PLD can be powered to 1.8v IOs while the rest is 3.3v IOs.
5v for these larger PLD and FPGAs is rare today.

[BrianHG]

Also note that the 10M04SCE144C8G is double the logic and double the cache ram size of the 10M02SCE144C8G for only a few dollars more while 10M08SAE144C8G is 4x the logic and 4x the cache ram, but around triple the price at around 21$.  144 pin drop in replacements exist up to 20x the size of the smallest one.

But still, they are all 144 pin drop in replacements.

[james_s]

Don't you think you should write the code and get it working before you settle firmly on the device to use?

[BrianHG]

Don't you think you should write the code and get it working before you settle firmly on the device to use?

Excellent point.................................

[xaxaxa]

Also note that the 10M04SCE144C8G is double the logic and double the cache ram size of the 10M02SCE144C8G for only a few dollars more while 10M08SAE144C8G is 4x the logic and 4x the cache ram, but around triple the price at around 21$.  144 pin drop in replacements exist up to 20x the size of the smallest one.

But still, they are all 144 pin drop in replacements.

If an additional 1.2V buck converter isn't a problem I'd recommend xc6slx9, also in a tqfp144 package but bigger (9K logic elements) and cheaper ($5 on aliexpress). An spi flash chip costs pennies and you only need to wire it up to the fpga (no additional circuitry needed).

[asmi]

If an additional 1.2V buck converter isn't a problem I'd recommend xc6slx9, also in a tqfp144 package but bigger (9K logic elements) and cheaper ($5 on aliexpress). An spi flash chip costs pennies and you only need to wire it up to the fpga (no additional circuitry needed).

I would NOT recommend it because it's already the largest part in that package, while MAX10 has full density range in that package.
I don't understand why everyone is so afraid of BGAs? In many ways they are easier to work with than, for example, QFNs. As a matter of fact, if the device is available in BGA and some other package, I prefer BGA (as long as it's pitch is not too small).

[james_s]

I'm not afraid of BGAs, but I tend to avoid them for my projects because it drives up the cost of the boards, you pretty much need 4 layers minimum.

It's all academic here anyway though, for a project like this using a large FPGA is like using a sledge hammer to drive a finishing nail.

[asmi]

I'm not afraid of BGAs, but I tend to avoid them for my projects because it drives up the cost of the boards, you pretty much need 4 layers minimum.

For most hi-speed interfaces you will need 4 layers minimum because of controlled impedance requirements. But I've noticed people are avoiding BGAs even on those boards, which is what puzzles me. I've learn to like BGA because they allow for very space-efficient routing, and they tend to me physically smaller than equivalent non-BGA packages (for example FBGA-256 has 256 pins and is 17x17 mm while TQFP-144 has only 144 pins, but is physically larger - 22x22 mm).

[asmi]

Dont disturb my comfort zone.

If you never leave your comfort zone, you will never grow as engineer.

[james_s]

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".

[nctnico]

Hello, please help.
 

For my electronic design, I am experimenting what device will be better, FPGA or CPLD, I wish to compile and determine the amount of space this takes on a device then judge my needs. I am trying to do as per this image, I have simple task of finding right 3 byte condition in parallel data stream, coming at about 12-22 Mhz, lets say I will have about 50-100 of these 3 byte conditions. These 50-100 or so conditons will in turn, signal 20 or so different  type events ( pins). So some  event pins will work for a multitude of 3 byte conditions.

So you have 20 outputs and 24 inputs. The limit is the number of logic it needs in between to detect the input values you are looking for. I think the best approach is to write a piece of code in Verilog or VHDL (*) and then compile it for various CPLDs and if it doesn't fit an FPGA. It all depends on the number of equations needed which in turns depends on how well the values you are looking for can be combined into the least number of logic equations. It is hard to tell how much logic will be needed in advance.

The biggest difference between a CPLD and an FPGA is that a CPLD can typically run from a single 3.3V and has an internal flash. An FPGA OTOH typically needs multiple voltages and an external storage. The start-up time for an FPGA is usually longer. Also an FPGA uses more or less small chunks of logic in series depending on the complexity of the combinatorial equations so the timing is less predictable compared to a CPLD which uses large AND/OR terms.

(*) In VHDL I'd define an array with the values (per output) you are looking for and then iterate through these with a for-loop to compare with the inputs to set the output. The synthesizer will create combinatorial logic from this and it will have a clean interface for entering the combinations to detect.

[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.

[BrianHG]

You are at a point where you should just purchase a SBC with linux installed which has a HDMI/DVI video input capture capability and write your own software for it.  It will take a fraction your time and you will get the added video out, networking, a full os, keyboard/mouse/usb and everything else which comes with a full at least dual core 1-2GHz computer with graphics accelerator for under 100$.  All components assembled on a module, including flash and ram and a flash port as well.

[lawrence11]

Too slow.... I need to modify that board.

[lawrence11]

Ok Brian,

Tell me exactly why again you say I cant use an TQFP 144?

I have some tqfp-144 with like 400000 ram bits.

We come to a wall here.

It cant be BGA.

That a no go zone.

[nctnico]

Ok Brian,

Tell me exactly why again you say I cant use an TQFP 144?

I have some tqfp-144 with like 400000 ram bits.

We come to a wall here.

It cant be BGA.

That a no go zone.

Get an FPGA + DDR memory on a module but make sure the FPGA is supported by the free version of the vendor tools.

[asmi]

The reason I prefer Xilinx chips for my projects is that it provides a good amount of IPs for free, which includes DDR1/2/3 memory controller. Altera only provides a time-limited evaluation version for free, if you want a permanent one - you will have to pay $$$. Developing DDR controller is a complex task way beyond beginners' abilities (and many non-beginners too - I personally wouldn't even think of it at this point).
But choosing Xilinx means you have to get comfortable using BGA chips because memory controller is not supported in TQFP version of Spartan-6, while all 7 series chips are BGA-only. DDR2/3 only exists in BGA packages as well. I was kind of afraid of BGAs before I actually started using them, but once I did they turned out to be much easier than I expected. Like I said above, I had more problems with QFNs than I did with BGAs so far.

[NorthGuy]

I was kind of afraid of BGAs before I actually started using them, but once I did they turned out to be much easier than I expected.

I agree. BGAs are the easiest thing to solder during prototyping. Just apply flux, place BGA and heat. Much less effort compare to TQFP.

[lawrence11]

Xilinx sounds good then, and this has seperate voltage I/O right?

I'll think about it. If this requires an oven I'm screwed,

My other solution, the easiest.

Is jsut to stay under 100million pixels per second.

And use some good old expensive 10ns sram. 3.3 volts everywhere.

Where is this "DDR+FPGA" on a module?

[james_s]

There are a number of DDR controllers out there, at least some of which should be fairly platform agnostic.

http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

https://github.com/stffrdhrn/sdram-controller

Keep in mind that even if you have an IP core there is still usually a considerable amount of work required to integrate it. You have a very long road ahead to get this working. This is sounding orders of magnitude more complex than the goal originally described.

[mrflibble]

The reason I prefer Xilinx chips for my projects is that it provides a good
amount of IPs for free, which includes DDR1/2/3 memory controller.

Yup, same here.

Where is this "DDR+FPGA" on a module?

See this one for example: Xilinx Artix-7 35T FPGA, dual 100 MBit Ethernet transceivers, 512 MByte DDR3 SDRAM
https://shop.trenz-electronic.de/en/TE0710-02-35-2IF-Dual-fast-Ethernet-Artix-Module-with-Xilinx-Artix-7-35T-ind.-temp.-range?c=148
https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/TE07XX-Artix-7/

Trenz has a fairly wide range of fpga modules you can choose from.
And if you don't want to mouseclick waaaay over in the land of Bratwurst
and my grandfather's bicycle, you can always mouseclick closer to home:
https://www.digikey.com/en/supplier-centers/t/trenz-electronic

[amspire]

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.

I haven't been following this thread, so I may be missing the obvious. Is there any reason you cannot use 3 static ram chips for a 24 byte read and write? Probably only use 16 extra I/Os compared to a single static RAM.

[asmi]

I haven't been following this thread, so I may be missing the obvious. Is there any reason you cannot use 3 static ram chips for a 24 byte read and write? Probably only use 16 extra I/Os compared to a single static RAM.

At that kind of speed you will likely need to length-match all lines to avoid timing issues. And doing that for 3 chips is not easy and I doubt you can get away with 2 layers (or even four). Typical dual x16 module DDR3 routing requires at least 6 layers.

[asmi]

Anyways, BGA looks cool, with an oven, wich I dont have, yet.

But once u got an oven...looks so nice for lazy people.

I use cheap-ass T-962 oven which I got for like $200. To give a perspective, my recent 6 layer boards order was ~$240 (that is extremely cheap, same specs order in Europe/US would be well over $1000), and a set of parts for assembling a single board is about $200. Even though some people here say this oven is crap, I use it for oven 2 years now with great success after some initial modifications to flash community firmware and some small HW changes (there are many guides out there on what to do and how to do it, it's a one-time deal which took about 3 hours for me to perform).
Another thing you will need to get comfortable with is placing very small parts. While some FPGA can be decoupled with 0402 parts, using 0201 caps makes it much easier from the layout standpoint as these parts fit perfectly between breakout vias of 1.0 mm pitch BGAs. But these are 0.6x0.3 mm parts, and you will need some kind of microscope to place them.

[NorthGuy]

Anyways, BGA looks cool, with an oven, wich I dont have, yet.

You can get by with hot air.

If money is a problem, you can buy a toaster oven in Wal-Mart for $20.

[asmi]

You can get by with hot air.

Not with double-sided parts placement which is all but required. Theoretically decoupling caps can be soldered manually, but soldering 0402 parts will drive you nuts in no time flat even with good stereo microscope and fine iron tip, while hand-soldering 0201 caps will most likely crack them by thermal shock - and MLCC caps tend to become conductors when cracked, so it will be extremely hard to find the one that failed without removing them all as DMM will just show you that there is a short circuit, but won't tell you which of 50+ caps failed
Also uneven heating might crack parts - especially physically large ones like FPGAs. I personally use hot air gun only when oven can't be used.

If money is a problem, you can buy a toaster oven in Wal-Mart for $20.

Like I said above, $200 is not that much money considering we're talking about parts with price in the same ballpark. I somehow doubt that a person who can afford spending that kind of money on parts (let's face it - there WILL be multiple respins due to layout/schematic bugs, and desoldering and reballing BGA is not always an option) is going to have issues making a one-time investment in equipment.

[lawrence11]

Ok,


I have nailed down the 2 only solutions possible for me.

My original idea, with 10ns sram and low resolution. All TQFP, all 3.3 volts. About 10$ more in components, cheaper PCB.

Or some DDR2,400mhz clock, 16 bits, WBGA package

https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=ddr2&k=&pkeyword=ddr2&pv1291=4952&FV=8e80071%2Cmu400MHz%7C800%2Cffe00306%2C238067c&mnonly=0&ColumnSort=1000011&page=1&quantity=0&ptm=0&fid=0&pageSize=25

And this XC6SLX9-2FTG256C, Startan 6 FPGA, with the MCB hardware package

https://www.digikey.com/products/en/integrated-circuits-ics/embedded-fpgas-field-programmable-gate-array/696?k=fpga&k=&pkeyword=fpga&pv1291=5227&FV=ffe002b8%2Cffece02b&mnonly=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25

[asmi]

Or some DDR2,400mhz clock, 16 bits, WBGA package

https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=ddr2&k=&pkeyword=ddr2&pv1291=4952&FV=8e80071%2Cmu400MHz%7C800%2Cffe00306%2C238067c&mnonly=0&ColumnSort=1000011&page=1&quantity=0&ptm=0&fid=0&pageSize=25

And this XC6SLX9-2FTG256C, Startan 6 FPGA, with the MCB hardware package

https://www.digikey.com/products/en/integrated-circuits-ics/embedded-fpgas-field-programmable-gate-array/696?k=fpga&k=&pkeyword=fpga&pv1291=5227&FV=ffe002b8%2Cffece02b&mnonly=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25

Forget DDR2 - DDR3 is better in any way possible - it's faster, has higher capacity, tighter tolerances on drivers' strength, and is even easier to route due to ability to use fly-by routing for address/control lines.
XC6SLX9 part doesn't have any GTPs so you will have to use external HDMI RX chip. If so, I'd prefer using faster Artix-7 (or Spartan-7 if your application is not going to be DSP-heavy) as Vivado IDE is much much better in my opinion than old rusty ISE.
Next, you will need to implement a wide memory bus to get the kind of bandwidth you need. I'd use dual x16 DDR3 chips, which at 400 MHz gives you 25 Gbps of peak bandwidth, which would give you plenty of headroom. And even using lowest speed grade (-1) will allow you to run memory at 333 MHz which will yield 20.8 Gbps of peak BW, so you can save some money on not investing into -2 speed grade, even though there are some design-related implications for doing that, which I won't go into here as not to overload you with all technical details.
Now, such memory controller with x32 DQ bus will consume 2 out of 4 IO banks (because it will need to be powered by 1.5V for DDR3 or 1.35V for DDR3L), and will force you to use voltage translation as the only fully routed banks on that package are ones used for configuration as well (banks 14 and 15). Depending on what else you will want to connect, you might want to opt for larger package. Especially since HDMI RX's RGB interface requires quite a number of pins as well.
Lastly, do you have any estimates on how much FPGA resources your application will consume? The flip side of 7 series memory controller's flexibility is that it will consume 10-15k LUTs all by itself, which pretty much demands 35T (talking about Artix-7 here as I'm most familiar with them) part as a minimum. If you're not sure, it's usually recommended to place the largest density part available in your package of choice on the prototype and then downsize it once you know exactly how much resources will you need, but for the love of God don't place big (and expensive) part on the very first revision of your board as chances are you're going to find some issues with schematic or layout (or both), and smoking $25 part will look much better than smoking $130 one.

[nctnico]

Vivado IDE is much much better in my opinion than old rusty ISE.

Just wondering: in what way do you think Vivado is better? Do the tools also build a design faster or is it just the user interface?

[asmi]

Just wondering: in what way do you think Vivado is better? Do the tools also build a design faster or is it just the user interface?

1. It works in Win10 Pro without nasty hacks or virtual machine.
2. Xilinx provide Microblaze softcore for free for all 7 series devices, which is not the case for S6.
3. I really like visual designer because it helps to visualize the system and how each parts of it are interconnected. Staring at HDL is nowhere near as "visual".
4. SystemVerilog support with some advanced IPs like AXI Verification (which is written entirely in SV) which makes developing testbenches for AXI-capable components MUCH easier (issuing a transaction in a testbench now takes only few lines of code).
5. "Cleaner" and IMHO more logically-organised GUI where controls are mostly where you expect to find them.
7. Most importantly it's not "abandon-ware" like ISE is.

I also like 7 series fabric because it's faster than S6. My initial detractor was BGA only package options (S7 was initially announced in TQFP-144 package, but it got cancelled somewhere along the way), but once I realized that DDR2/3 only exist in BGA packages as well, and got over my fear of them, I can now select a device based on what kind of capabilities I need for a specific project, not on what's available in packages I can work with.

[nctnico]

But it doesn't route faster? I'm using ISE primarily to drive the tools (but some are makefile projects so ISE sees even less use). I've moved editing HDL to Eclipse several years ago.

[asmi]

But it doesn't route faster? I'm using ISE primarily to drive the tools (but some are makefile projects so ISE sees even less use). I've moved editing HDL to Eclipse several years ago.

I don't know if it's faster or not because I didn't run side-by-side benchmarks. But in case of block diagram-driven designs, it can use OOC synthesis to make main process faster, so theoretically there might be some time savings.
Personally I'm not very concerned by synthesis or P&R times as my projects aren't very large as I simply can't afford big enough FPGAs for "compilation" time to become a problem

[nctnico]

Synthesis and P&R times are an issue for me. Some designs I work on take several hours on a fast machine.

[asmi]

Synthesis and P&R times are an issue for me. Some designs I work on take several hours on a fast machine.

Well technically you should be able to run the same HDL through both ISE and Vivado to see which one is faster on your setup.

[BrianHG]

Good luck on trying to get this 1 IC, then you don't need a FPGA or DDR3 ram:
http://docs-europe.electrocomponents.com/webdocs/1383/0900766b81383bf9.pdf

[james_s]

I'd be curious to see what sort of stuff takes several hours to synthesize, must be impressive. Most of my projects synthesize in under a minute.

[rstofer]

An unscientific comparison (a WAG) shows Vivado to be about half the speed of ISE.  It is absolutely grim on anything but the highest performance PCs available.  That it won't use more than 4 cores (8 threads) means there is no point in buying one of the truly outrageous Xeon systems.  I don't know if the commercial incantation runs any faster.  I only use the 'freebie'.

In the end, it doesn't matter.  ISE doesn't support the new chips and Vivado doesn't support the old ones (of which I have several boards).  It is imperative to have both versions running.

I put together a machine just for Vivado - I7-7700 and very fast Samsung 960 EVO SSD (1 TB) and I can go from text edit to device programmed in about 2 minutes for the LC3 16 bit RISC project (about 2000 lines of code).  That's a long time given my short attention span. 

The project uses very little of the Digilent Nexys 4 DDR board capability so routing isn't all that time consuming.  I suspect if I had a project that used most of the resources, it might take a very long time to route (hours and hours).  Good thing my projects are small!

Google for 'Vivado seems slow'...

[asmi]

In the end, it doesn't matter.  ISE doesn't support the new chips and Vivado doesn't support the old ones (of which I have several boards).  It is imperative to have both versions running.

ISE supports 7 series chips.

[NorthGuy]

Vivado looks very slow to me, slower than ISE without any doubts. My natural tendency is to recompile often, so Vivado drives me nuts.

[asmi]

Vivado looks very slow to me, slower than ISE without any doubts. My natural tendency is to recompile often, so Vivado drives me nuts.

Like I said, you can use ISE for 7 series if you want.
I only ever do a full P&R after all testbenches are successfully completed, so I spend most of the time in simulator, and it "recompiles" code quite quickly. "Recompile often" is a bad approach, because as your project grows so will the P&R time, and at some point you will spend most of the time waiting. This doesn't strike me as most efficient approach. I do know where this approach comes from as I'm professional software developer, and there compilation tend to be rather quick, but I made a point to change my habits when it comes to HW development.

[lawrence11]

ISE re-dowload.

So who here has used this magical MCB?

I will see what kind of pinout this represents and how bad it is to design a pcb for it.

Right here might be the deciding factor, PCB price.

One thing leads to another, into the No Go zone once again.

[asmi]

Right here might be the deciding factor, PCB price.

10 4 layer boards 10x10 cm with 0.1/0.1 mm and 0.2 mm drills, ENIG finish, controlled impedance (requirement for high-speed traces) is about $140. Same specs but 6 layers is about $200. Delivery charge is extra (in my case it was $30 to ON, Canada). I doubt you can make x32 DDR3 layout on a 4 layer board (I couldn't do it even for x16 bus), so count on 6 layer board as it will give you a lot of freedom and will make layout much easier.

High-speed layout is not particularly difficult but requires you to read, understand and follow layout requirements like length match groups, fly-by routing and spacing between traces to keep crosstalk in check. All of that is described in HW guides and appnotes, so information is out there, but - just like with BGA packages - it has a reputation of being "very hard" in the community (and I was guilty of thinking the same until I actually did this). It's not hard if you understand what you're doing and why - and aforementioned docs do a great job of explaining that. DDR3 on my board worked perfectly at full speed (400 MHz) on a first try, and it had even less design margin because I use low-power DDR3L module (voltage swing is smaller than in "normal" DDR3 mode).

[lawrence11]

This FPGA thing is a bit complicated.

Why is this IP core taking so much pins?

What is an acceptable pin count for what I wanna accomplish? I need to fill up a single DDR3 chip that is X16. I dont read while I write, I guess this is not bidirectionnal in my case.


IO Utilization:
  Number of bonded IOBs:                       239 out of     186  128% (OVERMAPPED)
    Number of LOCed IOBs:                       52 out of     239   21%

Specific Feature Utilization:
  Number of RAMB16BWERs:                         0 out of      32    0%
  Number of RAMB8BWERs:                          0 out of      64    0%
  Number of BUFIO2/BUFIO2_2CLKs:                 1 out of      32    3%
    Number used as BUFIO2s:                      1
    Number used as BUFIO2_2CLKs:                 0
  Number of BUFIO2FB/BUFIO2FB_2CLKs:             0 out of      32    0%
  Number of BUFG/BUFGMUXs:                       3 out of      16   18%
    Number used as BUFGs:                        2
    Number used as BUFGMUX:                      1
  Number of DCM/DCM_CLKGENs:                     0 out of       4    0%
  Number of ILOGIC2/ISERDES2s:                   0 out of     200    0%
  Number of IODELAY2/IODRP2/IODRP2_MCBs:        24 out of     200   12%
    Number used as IODELAY2s:                    0
    Number used as IODRP2s:                      2
    Number used as IODRP2_MCBs:                 22
  Number of OLOGIC2/OSERDES2s:                  47 out of     200   23%
    Number used as OLOGIC2s:                     0
    Number used as OSERDES2s:                   47
  Number of BSCANs:                              0 out of       4    0%
  Number of BUFHs:                               0 out of     128    0%
  Number of BUFPLLs:                             0 out of       8    0%
  Number of BUFPLL_MCBs:                         1 out of       4   25%
  Number of DSP48A1s:                            0 out of      16    0%
  Number of ICAPs:                               0 out of       1    0%
  Number of MCBs:                                1 out of       2   50%
  Number of PCILOGICSEs:                         0 out of       2    0%
  Number of PLL_ADVs:                            1 out of       2   50%
  Number of PMVs:                                0 out of       1    0%
  Number of STARTUPs:                            0 out of       1    0%
  Number of SUSPEND_SYNCs:                       0 out of       1    0%


Mapping completed.
See MAP report file "mig_39_2_map.mrp" for details.
Problem encountered during the packing phase.

Design Summary
--------------
Number of errors   :   2
Number of warnings :   0

Section 1 - Errors
------------------
ERROR:Pack:2309 - Too many bonded comps of type "IOB" found to fit this device.
ERROR:Map:237 - The design is too large to fit the device.  Please check the Design Summary section to see which resource requirement for
   your design exceeds the resources available in the device. Note that the number of slices reported may not be reflected accurately as
   their packing might not have been completed.

[asmi]

This FPGA thing is a bit complicated.

Why is this IP core taking so much pins?

It looks like you're trying to externally expose AXI Slave bus AXI is designed to be used only inside the FPGA for interconnects between internal subcomponents, but never exposed to outside world.

[NorthGuy]

"Recompile often" is a bad approach, because as your project grows so will the P&R time, and at some point you will spend most of the time waiting. This doesn't strike me as most efficient approach.

"Recompile often" is a very good approach. Of course, it doesn't live well with overbloated tools. ISE is quite overbloated too, just not as much as Vivado.

The idea that P&R is inherently slow doesn't hold water. Even if you place everything manually, it'll still be slow.

[asmi]

"Recompile often" is a very good approach.

Of course you're going to defend your approach

What's the point of it anyway? One doesn't need P&R to run sims (except in very rare cases where bad placement caused timing issues), and normally if I do P&R that means it's already passed functional verification and so I'm reasonably certain it will work in hardware on the first try. I only make exception from TDD approach when working with some external chip with not very good datasheet, and so I need to use ILA to see what it actually does.

[NorthGuy]

"Recompile often" is a very good approach.

Of course you're going to defend your approach

You bet.

What's the point of it anyway? One doesn't need P&R to run sims (except in very rare cases where bad placement caused timing issues), and normally if I do P&R that means it's already passed functional verification and so I'm reasonably certain it will work in hardware on the first try.

I don't know. You brought the P&R up, not me. You said:

"Recompile often" is a bad approach, because as your project grows so will the P&R time, and at some point you will spend most of the time waiting.

Now you say that you only need P&R very rarely. Ok. Let it be. Are you implying that synthesis in Vivado is quick?

[lawrence11]

I just created a new file.

Common procedure----->new_new project, chose my target, Tools---->Core Generator

Then once in the new Core menu, new Project, make sub-folder, and configure my chip with the MCB GUI.

I am using 16x default, with a 256 pin BGA.

I never saw the term "AXI" from beginning to end.

How do I turn this off.

Ok I see now,

https://www.xilinx.com/support/documentation/ip_documentation/mig/v3_9/ug416.pdf

in Click the Enable AXI check box to add an AXI4 user interface to all MCBs (this option
is only available for Verilog designs). Otherwise, the MIG design is generated with the
standard (or Native) user interface by default. Select a memory standard from the
Memory Type drop-down menu for each MCB that implements a memory interface
(only DDR2 and DDR3 are available when using an AXI4 interface). Click Next.

Now, can somebody tell me where is this "native" user interface? How come I dont get this inferface yet this causes my compile to fail WTF?


In this cluttered bunch of files.

[nctnico]

Vivado looks very slow to me, slower than ISE without any doubts. My natural tendency is to recompile often, so Vivado drives me nuts.

Like I said, you can use ISE for 7 series if you want.
I only ever do a full P&R after all testbenches are successfully completed, so I spend most of the time in simulator, and it "recompiles" code quite quickly. "Recompile often" is a bad approach, because as your project grows so will the P&R time, and at some point you will spend most of the time waiting. This doesn't strike me as most efficient approach. I do know where this approach comes from as I'm professional software developer, and there compilation tend to be rather quick, but I made a point to change my habits when it comes to HW development.

I agree when it comes to developing HDL code. When I make a new module I simulate it before integrating it into the design. That usually saves quite a few P&R cycles but you can't avoid them all. Sometimes I need to tweak the map parameters to make a design P&R quicker and/or meet timing but it takes a lot of P&R cycles to find a good value. The right map parameters can mean the difference between P&R in 10 minutes + meeting the timing requirements and running for 8+ hours and not meeting the timing requirements.

[mrflibble]

quick post. during installation you can select the components you want. For example webpack vs system edition (or something lkike it). Anyways, the XPS system thingy is not part of all install types. But core generator should be part of it.

Short version: from IE you should be able to start core generator, from which you can build your MIG.

[lawrence11]

I'll check later for XPS...Maybe...Maybe never

Where do I find the AXI4 config file, the config thingy that will change things and let me compile.

You know what I mean...The config file for AXI4 that doesnt let me compile a bitfile.

Nevermind the other stuff, XPS is gone, was removed by xilinx. Its just a bullshit 3 letter word that you need to pay for.

I have the CoreGenerator, I have this, I can create a DDR project but I cant compile a bitfile because of this dam by default AXI settings, it seems like I dont get
my advertised GUI settings (wich allows trial and error testing out stuff) for the AXI. So I am now in search of some sort of file where I comment out things to make it equivalent to the AXI GUI experience?

This FPGA thing is a bit complicated.

Why is this IP core taking so much pins?

It looks like you're trying to externally expose AXI Slave bus AXI is designed to be used only inside the FPGA for interconnects between internal subcomponents, but never exposed to outside world.

I am trying the exact opposite of that, I DONT want to expose the AXI slave Bus to the outside world, I would like it to be NOT exposed to the outside world.

[asmi]

No offence, but you seem to have no idea what are you talking about.
AXI is a bus that is used to issue commands to the memory controller. So whatever component(s) you design will connect to this bus and issue commands - hence your component will have AXI Master bus connector. On your screenshot I see wires like "s_axi_*" - these are wires that belong to AXI bus.
Go the the ARM website and download AXI4 specification - it explains how this bus works, and how to use it.
Alternatively you can use "native" interface - for 7 series devices it's described in document UG586, page 92 and below. But I never actually used it as I prefer using AXI because it's more universal, so I can't help you here. At least in Vivado MIG generates an example design along with the actual core when you invoke it, so you might want to check if it's the same for MIG in ISE - and if it is, study it's code (along with reading documentation) to get an idea how to use the thing.

[lawrence11]

I dont need to read about AXI just to generate a bitfile example from a GUI.

I need to know where I make my pin count lower so I can compile.

[lawrence11]

Sorry, sometime you guys just get on my nerves, sometimes these comments are not helping, but I know its just because you never went through these unlucky same and bullshit problems a noobie faces.

I have to read about AXI but its just bullshit this FPGA software is like Catia on steroids x10. All those dam icons and 100 page pdf's everywhere I'm pissed off its not easier.

In a rage, I said, one last time before I try Lattice software and there it was, it was like in the image.

I managed to get the AXI thing to look like it should.

You have to create your project inside core generator, from scratch,  thenopen it with ise or just click the icon inside that project.

Not by creating an ISE project ( choose device), then add an IP core( with same device). This makes AXI dissapear, not there nor selectable.

Not like this video, and not like in one of the documents ( there's 2 different ones), one basicly shows the wrong way, then they show you the AXI Figure and you think you missed something.

Really a big mess.



I now see AXI, still I cant compile, I have same errors. but I am seeing it.

[james_s]

We're not trying to get on your nerves, we're trying to help, but you're not listening. You keep trying to skip ahead to the end and want a simple answer to a very complex question. You need to take a few steps back and take the time to learn the HDL you wish to use, and then learn how to use IP cores. It looks like you're trying to build a standalone IP core, that's not how these are designed to work. What you should do is have a top level file which has all the IO that interfaces to the physical world through pins on the device, then within that top level file you have modules such as the IP core(s) you wish to use and other functionality that is "wired" together via the top level file. Attempting to rush to the end is only going to lead to frustration, it's like trying to jump right into calculus without bothering to learn basic arithmetic and algebra.

[lawrence11]

No offence, but you seem to have no idea what are you talking about.
AXI is a bus that is used to issue commands to the memory controller. So whatever component(s) you design will connect to this bus and issue commands - hence your component will have AXI Master bus connector. On your screenshot I see wires like "s_axi_*" - these are wires that belong to AXI bus.
Go the the ARM website and download AXI4 specification - it explains how this bus works, and how to use it.
Alternatively you can use "native" interface - for 7 series devices it's described in document UG586, page 92 and below. But I never actually used it as I prefer using AXI because it's more universal, so I can't help you here. At least in Vivado MIG generates an example design along with the actual core when you invoke it, so you might want to check if it's the same for MIG in ISE - and if it is, study it's code (along with reading documentation) to get an idea how to use the thing.

I tried this before but it seems like I have to buy the board to get the examples for the DDR2.

https://www.xilinx.com/products/boards-and-kits/ek-s6-sp601-g.html#documentation

There is missing files from the DDR2 example design.

[mrflibble]

Not a 100% match of what you want, but the required steps are similar.
You can take a look at the board files + MIG related stuff. Maybe it has enough
info in it for you such that you don't have to RTFM. At least you don't have to
buy anything to get board files.

https://reference.digilentinc.com/nexys4-ddr/advmb
https://reference.digilentinc.com/_media/reference/programmable-logic/nexys-4-ddr/nexys4ddr_mig_prj.zip
https://reference.digilentinc.com/reference/programmable-logic/nexys-4-ddr/

[mrflibble]

I can confirm, from personal experience, that AXI is a particularly confusing specification for those new to FPGAs.

If the AXI avoidance score is really high ... you don't have to use AXI.

In ISE in core generator select the "Show older versions" (or something to that effect, it's been a while). Then you will also see the older non-AXI MIGs. In the past I've done exactly that because at the time I didn't need AXI for any other component, and the old school MIG flavor was less work to use in that project.

For Vivado I think you can do something similar. See for example:
https://forums.xilinx.com/t5/Memory-Interfaces/Looking-for-native-user-interface-option-in-MIG-7-Vivado-v2-3/td-p/550963

[lawrence11]

I can confirm, from personal experience, that AXI is a particularly confusing specification for those new to FPGAs.

Annoying is it? All this messing around just to use some DDR3... Really a pain in the a**.

I follow a procedure from a pdf.

So Asmi was right, the AXI4 bus is acting stupid and not giving me a default randomized pinout according to my GUI requirements that can be compiled and played with.  

 Please help. I wanna "connect my axi bus to something". Or just not use AXI. The goal of me needing to use an FPGA is to buffer an image frame, and analyze with a microcontroller. Get this done  and over with.

 Thank you.

[Someone]

All this messing around just to use some DDR3... Really a pain in the a**

If the vendor IP is so hard to use then will it be much easier to simply write your own DDR controller?

[asmi]

So Asmi was right, the AXI4 bus is acting stupid and not giving me a default randomized pinout according to my GUI requirements that can be compiled and played with.  

 Please help. I wanna "connect my axi bus to something". Or just not use AXI. The goal of me needing to use an FPGA is to buffer an image frame, and analyze with a microcontroller. Get this done  and over with.

You keep trying to brute-force this without much thinking. Take a step back and try to understand what are you going, and you will see a problem. AXI bus is can't possibly "act" - it's all of your doing.

[asmi]

If the AXI avoidance score is really high ... you don't have to use AXI.

You will have to learn AXI sooner or later as just about anything in Xilinx IP world uses this bus. Want video streaming? Here's AXI Stream. Need to connect some (relatively) slow peripheral to Microblaze/Zynq CPU? That's what AXI Lite is for. Need to do high-bandwidth data exchange with some other component inside your system? AXI Full exists just for that.
The bus might seem intimidating at first glance due to sheer amount of signals, but once you understand the reasoning behind them all, it becomes quite clear. The only real source of confusion I can see is relative timing of WA/WD and RA/RD channels.
Also Vivado provides a tool that can generate very well commented boilerplate stubs for any of aforementioned variations of AXI bus, as well as excellent AXI Verification IP which makes developing testbenches orders of magnitude easier than it used to be in the past.

[lawrence11]

No problem learning it. No choice there. .

The software should invite me into a graphical pinning out of the bus after I set up the DDR. Thats is the problem.

I just need to know where I reroute and connect the axi4 BUS to external things.

Theres like 32 wide address bus and 32 wide data bus and a few other pins. In fact, I like this Bus, it is reminiscent of SRAM.

[NorthGuy]

All this messing around just to use some DDR3... Really a pain in the a**

If the vendor IP is so hard to use then will it be much easier to simply write your own DDR controller?

Reading JEDEC DDR3 specs is substantially bigger effort than reading AXI4 specs.

The OP seems to have an inclination to avoid reading, which certainly makes even simpler things much harder.

[lawrence11]

I have no problem reading.

https://www.xilinx.com/support/documentation/ip_documentation/mig/v3_9/ug416.pdf

All files I read never tell me where I should connect the interface. In fact, they show me a graphical configuration that I never see when I am in native mode.

Where are those 64+ bus connections that are assumed lost and not connected internally, in what file? I will go there and connect those connections to pins( user logic)

It will be more clear to me once I know the exact file I should study. I  will track down their names and what they do and what pins I want them to relate to.

[lawrence11]

Ok never mind this DDR for now.

I will pay attention on the upgrades, one day I will learn it once they make a more user friendly software  that has actual GUI, and a real BUS to PIN interface.

This will get done with SRAM.

[mrflibble]

... one day I will learn it once they make a more user friendly software  that has actual GUI, and a real BUS to PIN interface.

So, roundabout the introduction of DDR8 then.

[james_s]

Don't hold your breath. FPGA development is an esoteric field, it is inherently complex enough that the software to do it is not going to be super easy to use. It's aimed at professional engineers who have the training and experience to use it effectively, the hobby community is very small.

[lawrence11]

Not holding my breath. I`d say by the time they make DDR5 or 6. DDR2 is almost 20 years old and its used today.

Maybe a DDR manufacturer will pay them to make a really easy GUI that allows for plug and play.

Maybe when I need the upgrade I will pay Lattice for a really newbie friendly libary that is plug and play. Apparently its ''low cost''.

[asmi]

Maybe a DDR manufacturer will pay them to make a really easy GUI that allows for plug and play.

You're using the software that has been officially abandoned by the vendor at least 4 years ago (when they transitioned to Vivado, which is the tool they are actively working on right now). There will NEVER be a single "Do it good!" button you seem to be looking for because flexibility that FPGAs provide always comes at expense of complexity.

Maybe when I need the upgrade I will pay Lattice for a really newbie friendly libary that is plug and play. Apparently its ''low cost''.

They are even worse than Xilinx. And their DDR controller costs $$$.

Last point - FPGA are beginner-friendly, but only for those beginners who are willing to learn a lot of new things and concepts which are unique to FPGA world.

[james_s]

Who is the market target for a really easy to use DDR IP core? How does that translate into profit for the company producing it? Keep in mind the development effort could easily exceed many tens of thousands of dollars.

Lots of people already using DDR RAM with FPGAs, I posted links to at least two controllers earlier.

[nctnico]

Who is the market target for a really easy to use DDR IP core? How does that translate into profit for the company producing it? Keep in mind the development effort could easily exceed many tens of thousands of dollars.

Lots of people already using DDR RAM with FPGAs, I posted links to at least two controllers earlier.

IMHO the built-in DDR memory controller in the Spartan6 is pretty easy to work with and you can choose what kind of memory widths it has. Over a decade ago I wrote my own DDR controller from scratch and that was quite a bit of work to say the least.

[maginnovision]

Why not just learn first and then do it properly? I'm sure by learning what you should know first will actually save you time including the learning time.

[BrianHG]

Who is the market target for a really easy to use DDR IP core? How does that translate into profit for the company producing it? Keep in mind the development effort could easily exceed many tens of thousands of dollars.

Lots of people already using DDR RAM with FPGAs, I posted links to at least two controllers earlier.

IMHO the built-in DDR memory controller in the Spartan6 is pretty easy to work with and you can choose what kind of memory widths it has. Over a decade ago I wrote my own DDR controller from scratch and that was quite a bit of work to say the least.

It took me 3 solid months to get my SODIMM 8-port (4 read ports, 4 write ports), with adaptive variable same page burst length DDR2 controller working in Quartus 9.2.  It was a fluke that the PCB cad-ing went perfectly, but then again, I also wrote a tool which took both my netlist from Protel99se and Quartus's pinmap in the assignments file and filled it in guaranteeing no pinout mistake other than the possibility of using a wrong color coded bank in the FPGA as I was using variable voltages.  The biggest annoyance was the read latch clock since I wanted multiple different frequency module support and I ignored the DQS on reads opting for the loss of the possible extra 1/2 clock shorter read latency.

[NorthGuy]

I think my idea would be cooler and higher quality if I used DDR, but that was when I thought this was GUI 100%

I would rather think about the future. Imagine you succeed. Then few months and $2,000 later you get a working board which can accept an HDMI stream, write a frame to DDR memory, then gives you an AXI stream to let you read back the picture you have just saved few milliseconds ago. Is that what you want/need? What are you going to do with it? How is it better than the picture you had before saving? Is that short delay between saving and reading back was worth the effort?

[james_s]

For the most part you should just forget about the GUI. It's ok for instantiating IP components but once you've created that, you will virtually always want to connect them together using your HDL of choice. The FPGA software has a schematic capture feature but it's really just a gimmick, beyond extremely simple projects it only makes it far more tedious and time consuming to develop and debug. If you don't take the time to learn VHDL or Verilog you will never get very far with this.

[BrianHG]

I've only used the GUI for the Top hierarchy in Quartus.  It basically automatically made 1 or 2 of my main verilog modules into block with inputs on the left and IOs on the right and I just placed the IO pins at each port.  Everything else inside those 1-2 modules was all in HDL except for the occasionally added PLL instance which I might opt to place on the top or everything instead of inside the HDL.  This became useless once I had to begin to use software reconfigurable PLLs.  All in HDL was the only way after all those control signals had to be wired up.

Note this was back in the mid 2000s and it was how I was taught at the time.  Quartus still seems big on providing fancy illustrated GUI modules for their IP.  It may only be useful for illustration purposes or if you are making a project just to simulate that 1 module with Quartus' internal simulator which was abandoned back in version 10.0.  Today, it just gets the in the way of full HDL coding and may only have a slight purpose in school work as a small stepping stone between seeing wired HDL modules in the GUI, then, learning how to 'wire' and 'assign' connections between such modules in your own HDL code without the GUI.

[james_s]

Things have not changed much in that regard so far as I've seen. When I was just getting my feet wet with CPLDs the schematic capture tool was a cool way to play with some basic logic and blink some LEDs very early on. I even went so far as to recreate most of the original Atari Pong arcade game on a CPLD using the schematic. It was partially working but had some issues, I soon realized how tedious the schematic was and gave up on that particular project. Outside of the wizards for setting up IP blocks like clock PLLs and RAM/ROM instances the GUI is pretty useless.

[asmi]

For the most part you should just forget about the GUI. It's ok for instantiating IP components but once you've created that, you will virtually always want to connect them together using your HDL of choice. The FPGA software has a schematic capture feature but it's really just a gimmick, beyond extremely simple projects it only makes it far more tedious and time consuming to develop and debug. If you don't take the time to learn VHDL or Verilog you will never get very far with this.

I disagree. While I do spend most of time in the code editor and simulation window, I do like diagrams in Vivado as a great way to visualize all interconnect so you can quickly see the entire system "at a glance". This is especially useful when I open some kind of sample project, or even my own project that I didn't touch for a while. In recent versions Xilinx finally added ability to directly instantiate your code modules in the diagram without creating IP package.

Connecting multiple AXI buses in HDL is quite a miserable and error-prone experience due to sheer amount of signals. Also Vivado automatically generates AXI interconnects when needed (for example when you want to connect multiple masters to the same bus, or when different parts of AXI bus need to have different clocks). So it's definitely useful, especially so if your design is only going to use pre-existing IPs (which are plentiful - even webpack edition contains almost 200 free IPs!) as it allows you to create entire system without writing a single line of HDL code. And even commercial IPs provide evaluation versions for free, so you can use them as "known good" code to test your newly built hardware, so that when time will come to develop your own IPs you will be certain that hardware works. For example, when I assembled my first Artix board with DDR3, it took me literally few clicks of a mouse to create a test system that allowed me to confirm that DDR3 indeed works.

[KE5FX]

A few random thoughts in no particular order:

1) Vivado is faster and better in pretty much every way than ISE, in my experience.  That was not true a couple of years ago, but at this point I don't miss ISE at all.  If your project takes longer to build in Vivado than in ISE, make sure you're using comparable settings and taking advantage of out-of-context IP synthesis.

2) Consider Hyperram if DRAM routing or controller complexity is a problem for any given reason.  Sounds like you may have to do some interleaving, either way.

3) Start with an eval/demo board or trainer.  Do not attempt to bring up hardware at the same time you're getting your first FPGA project going, especially not one as complex as this one sounds like.

4) No matter what you need to do, there is almost certainly either an existing tutorial somewhere for it, or a ready-made project somewhere on Github.  Do not attempt to build complicated stuff from scratch when you're not entirely sure of what you're doing.

5) There will probably never be a time when FPGAs and their toolchains aren't stupefyingly complex, slow, and annoying.  It is what it is.  Again, your best defense is to start with an existing hardware platform, even if only for tutorial purposes.

[lawrence11]

The problem with Vivaldo is that it needs 50$ IC's.

So now we got a PCB price problem and a component price problems.

Its funny how when I  am electronics amateur entrepreneur I transform myself into a penny pincher, I'm not like this in real life.

But when it has to do with my design, I like it to be cheap.

I dont know about you LOL...

[Someone]

The problem with Vivaldo is that it needs 50$ IC's.

Digikey have single quantity Artix devices starting from $26, once spartan 7 series are in volume production they should appear well under that. The market is fairly competitive so you get what you pay for, there aren't large cheap FPGAs from any vendor.

[NorthGuy]

The problem with Vivaldo is that it needs 50$ IC's.

Digikey have single quantity Artix devices starting from $26, once spartan 7 series are in volume production they should appear well under that.

Judging by what prices they have now, spartans won't be much cheaper than artixes.

[asmi]

Judging by what prices they have now, spartans won't be much cheaper than artixes.

Right now on DK Canada XC7S50-1FGGA484C is 72.34 CAD, while equivalent Artix (XC7A50T-1FGG484C) is 109.59 CAD. So S7 is about 34% cheaper. I expect the smallest S7 (6K logic cells in 4-layer-friendly FTGB196 package) will be about 15-20 CAD for singular quantity.