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.