How to evaluate as a Beginner how much will fit in a certain amount of LUTs? - Page 1
Forum section: electronics / general

author: soFPG
author_rank: Frequent Contributor
timestamp: May 19, 2020, 11:21:33 pm
content: I am thinking about some projects which use FPGAs. One of them would be interfacing with an image sensor (~75MHz 12-bit parallel) and sending the pixel color data via SPI (maybe 50MHz) to a display (320 x 240 Pixel).I am assuming this 12-bit parallel read from GPIOs at 75MHz wouldn't be a problem (?), same goes for the SPI. But then there is the initialization of the display (via SPI) and the image sensor (via I2C) where I don't know how many instructions this will take at the moment. I assume it would make sense to use a small uC for the initialization process?Anyway, how do I know if this will fit in 1.5k LUTs? Or 2.5k LUTs? You are probably saying that I should buy a bigger FPGA to have enough room for testing, especially as a beginner. But as far as I know at about 2.5k LUTs or 4k LUTs products start to only come in BGA packages and I was thinking about realising this on a 2 layer PCB...But then I also thought about adding a external SDRAM module to buffer images (at least one).

author: asmi
author_rank: Super Contributor
timestamp: May 19, 2020, 11:46:04 pm
content: The short answer is - you won't know until you actually design, simulate and implement it.I'd strongly recommend to NOT use 2 layer boards for anything high-speed. Especially considering how cheap 4 layer boards are nowadays. And as a small plug to myself, check out the project in my signature, maybe it will give you some ideas and/or will be a good starting point for your own design.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: May 20, 2020, 12:18:11 am
content: Also, unlike programming micros, you'll certainly notice when your device approaches getting full (P&R run times go crazy). With a micro, it's either out of memory or not.

author: soFPG
author_rank: Frequent Contributor
timestamp: May 20, 2020, 07:24:08 am
content: QuoteIs 75MHz considered high-speed?QuoteSure, they became much cheaper. But 2 layer boards are still cheaper.QuoteI checked out your project, thank you. Maybe I am just wrong but I neither plan to use an FPGA which has so many pins nor DDR2-RAM, nor HDMI so I would consider my project far less complex?

author: tggzzz
author_rank: Super Contributor
timestamp: May 20, 2020, 08:14:37 am
content: Quote from: soFPG on May 20, 2020, 07:24:08 amIn that context 1Hz can be high speed. The clock rate iscompletely irrelevant.The only two things that matter arethe edge rate, because that's what defines the high frequency energy in the signals. For quick hand-waving theory and a few simple practical measurements, seehere, especially the last two images.the number of outputs switching simultaneously and the current drawn through the outputs, because that is what causes power supply "bounce". In modern designs getting the "power distribution network" right is a key design problem

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 20, 2020, 09:52:52 am
content: Of course you can only guess, until it's actually done. And even then, that's just one instance, probably not an optimized one; and after much optimization, soul-searching, and ponderings over coffees, still not perfectly optimized (as there most likely cannot be such a thing), but perhaps getting closer.So, what then? Well, of course if you have much experience, you can guess that such-and-such operations will take up this-and-that LUTs/gates/whatever, and probably be well enough in the ballpark. Say +/-20%, more than good enough to budget for the right chip (say, choosing between the 10k or 16k LUT model).If you don't have that much experience, you'll have to break it down further. What, on a high level, do you need to implement your system? Probably some block RAM, or a bus interface to external RAM of some type. Counters, latches and decoders, to drive state machines and interfaces. Miscellaneous gates for tying everything together. How wide are each of these interfaces? How much arithmetic needs to be performed on each of them? (Counters might only need an increment block, but an advanced state machine might need, say, several full adders? If you're doing DSP, you'll need lots of adders, and multipliers too. Etc.) Then, what does your target platform support -- do they have just LUTs and that's it, do they have hardware adders (or carry chains, or carry lookahead for that matter)? Hardware multipliers? Block RAM? Other special parts? With some hand-waving, you can roughly guess (maybe hopefully a say +100/-50% ballpark?) how much resources your problem is likely to take, given a typical synthesis.And if that's still too advanced -- break it down again! Learn introductory VHDL or Verilog; get a dev kit, make some very basic things: counters, blinkers, interfaces, decoders, whatever. Read and understand the output (synthesis and compilation), usually given in terms of RTL (register transfer logic -- buses, latches, adders, etc., the kinds of components I mentioned above) and gates (layout and allocation).You could break it down one more level still, and synthesize gates yourself -- but this would actually not be such a great idea, unless you really want to solve it by hand, pad and pen, discrete gate ICs, that sort of thing. Writing out combinatorial logic as basic process statements is actually a bad idea: sure, you can create any kind of gate imaginable, but the synthesizer doesn't know how to map those into the gates it has. It's not designed to solve backwards like that. (Or at least, this was the case as of, whatever it was, Quartus Web 10.0 I might've been using back then.) It will end up taking hugely more LUTs and propagation delay than a slightly higher level solution will.So implement it primarily in behavioral statements: understand that aCASEstatement instantiates a mux, say; aif (clk'event and clk='1')statement instantiates a(n edge-triggered) register; arithmetic statements instantiate adders or such; etc.Partial aside: you can generally ignore connections, I think, but highly interconnected systems may become routing constrained, and then you won't be able to use as many LUTs. I've not thought about this much before (let alone done much of anything in an FPGA, for quite some time!), but it is just another resource, and subject to availability all the same. Most problems at least can be solved with an average number of connections, and this is likely the ratio of gates to interconnects the manufacturer chose for their design. Related reading:https://en.wikipedia.org/wiki/Rent%27s_ruleSo, as for your particular case -- I would guess there's buffering in there somewhere? You're smashing down a lot of bandwidth. Namely, 12 * 75 = 900 Mbps, versus a 320x240 x 24bpp x 60Hz ~= 110.6 Mbps display (or less depending, but probably not much more?). Where does the excess bandwidth go? Will you be discarding it wholesale (decimation)? If so, can you just skip over the useless data at the source itself? (Maybe not, that would need an addressable image sensor which I would guess isn't common.) Averaging or other filtering? Per line, or between lines (requires some line buffer RAM and arithmetic blocks)? Maybe the scan rate or resolution is wholly different, so you need a good 2Mb of frame buffer RAM? Presumably there'll be a state machine to handle startup and operation, pixel or scan counters, etc.Would guess startup can just be ROM blocks (really just emulated by muxes I think, unless block RAM can be instantiated and initialized? Don't know offhand), you're just reading off values and streaming them into the port (and maybe streaming out state info as well, like delay cycles in case some options require initialization time).That's still pretty far from even a tentative RTL schematic, but gives some ideas where to go in that direction. And yeah, I would guess it'll fit in less than 10k LUTs/gates, but I'd be very nervous about just 1 or 2k, especially if any kind of buffering or filtering is added.As for high speed, what they said -- edge rate is what's critical, but on top of that, you don't have any room to slow down the edges because you have merely 13ns per cycle to work with, and spending even 2ns per edge will give you some pretty iffy timing windows.At lower rates, you can (and should!!) slow down the edge rates, usually with series resistors or ferrite beads. Keep this in mind for low bandwidth signals, status, I/O, whatever.For point of reference, that's faster than 74HC logic can move. It's fast enough that, in a foot of ribbon cable say, and at a given instant in time, you can have ~VCC at one end of a wire, and ~GND at the other, as the edge propagates along it near the speed of light. You will need good grounding (solid ground plane PCB; alternating GND and signal for cables, preferably shielded as well), and not really controlled impedances but just mindful impedances, in that you can't have traces being every which way, but they should be consistent, and terminated accordingly, at the source, load or both (as applicable). Lengths matched as closely as needed.If you can use differential signaling, do take advantage of it; especially for long runs, anything in cables, etc. LVDS and others have definitely been applied, in commercial applications, at lower clock rates than these! Differential alleviates not only cable EMI issues, but supply bypassing demands as well -- you don't have a half dozen signals drawing tiny gulps of charge at the same time, instead it's a constant-current load, and can be less average current anyway (in much the same way that TTL vs. CMOS trades off idle vs. dynamic current draw with speed).Expect to employ timing constraints on your platform; this will be specified somehow, maybe directly in code, maybe in supplementary project files (I think Quartus does, or did, it this way?). An output of which, will be a listing of the timing constraints on each signal, which informs your physical layout -- how closely the lengths need to be matched. Be careful that some blocks can be instantiated in very different ways, so as to meet some constraints (like propagation delay from a clock) but missing others (maybe it has a latency of one or more cycles); pipelining is a powerful example of this, and every paralleled instance of the pipelined block takes up its own resources; use carefully! (You probably won't need anything pipelined for this, I would guess, but keep this in mind if you find you're doing more advanced arithmetic -- division and floating point being common examples.)Tim

author: tggzzz
author_rank: Super Contributor
timestamp: May 20, 2020, 10:12:24 am
content: The other thing that you should get sorted out sooner rather than later is the clock strategy, especially in terms of i/o structures and clock domains.That's particularly true if you have a large design where some of the signals will have to cross large parts of the die, or if you have inputs and/or outputs that don't have a well-defined frequency and/or phase relationship with each other.

author: asmi
author_rank: Super Contributor
timestamp: May 20, 2020, 01:34:25 pm
content: Quote from: soFPG on May 20, 2020, 07:24:08 amConsidering massive advantages 4 layer boards have over 2 layer ones, the small difference in price is totally worth it.Quote from: soFPG on May 20, 2020, 07:24:08 amlol. "Who needs so many pins?" - that what I thought when I was just beginning to work with FPGAs.But here is the thing - FPGA I use in that project has 100 user IO pins. Which might seem a lot, but in reality it's not. Didn't you said you want to connect SDRAM to FPGA? Well guess what - that will "consume" 40-50 FPGA pins, or almost a half of those 100 available in my package of choice. Next, 75 MHz 12 bit bus? That's another 13 pins. SPI? That's another 4 pins, or 6 if you will want QSPI for speed. You will also likely want some GPIO pins for LEDs, buttons and stuff to help with debugging, say that's another 5 pins. Also clock input + system reset pin. As you can see, it starts to add up really quickly even in relatively simple cases - and THAT is why FPGA tend to have a lot of pins.As for my project - it's meant to be a starting point more so that a ready-made design, basically to make sure all configuration-related and other service pins are connected properly, if you remove parts you don't need and replace them with ones you do. The way I see it is you will probably want to keep DDR2 SDRAM as it's useful for so many applications (and you can fit a smaller capacity memory chip to save some cost, down to 64 MBytes), which leaves you a full IO bank (50 user IO pins) for your custom peripherals and other external connections.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 20, 2020, 01:56:41 pm
content: Since most FPGA vendors have product lines with a range of similar models, people usually select a series that fits their other requirements, design their RTL, synthesize it with the FPGA vendor tools, then figure out how many LUTs they'll need, and which model they'll choose according to this. Many vendors have series with a rather large range, so this is usually no problem.And, since models in a given series often have their number of LUTs and number of IOs linked somewhat, if you need a large number of IOs, you'll often end up with a large number of LUTs, whether you need them or not.One exception could be if you think of using some specific, "low-end" FPGA series, like what you can find with Lattice (MachXO2/3, ice40...), you'll need to give it a bit more thought.In any case, using the vendor tools to get a realistic figure is a safe approach, and can be done first thing before deciding. And of course, once you get a figure, give it some leeway for future updates.One thing to consider is also the max frequency you need your design to run at. If you select a model in which your design will barely fit, chances are place and route will struggle and you'll get poor timing results - so in general, the highest the frequency, and the most leeway you'll need. Unless you're maybe ready to do some PAR manually, which can be pretty involved.

author: rstofer
author_rank: Super Contributor
timestamp: May 20, 2020, 07:10:58 pm
content: Pick the largest chip in the family you intend to use and then design and synthesize the project. This doesn't have to be optimized to any extent, it's probably better if it isn't. All you're trying to do is find out how many resources are required. It's all in the Reports including power.Then back off on the chip and keep doing that until it doesn't fit. P&R gives up in disgust...At this point, you know the minimum chip. Personally, I would double the resources but that's just me.You can always get a development board to actually implement your synthesized project and test things out before you start downsizing the chip.I tend to buy development boards with as many resources as possible and, if given a choice, I buy the board with the largest chip. Yes, I know an Artix 7 100-T is overkill for almost anything I want to do.

author: soFPG
author_rank: Frequent Contributor
timestamp: May 21, 2020, 02:12:09 pm
content: So I guess something like a EP4CE6E22C8N should be fine?Max. frequency: 200MHzLogic-Elements: 6272I/Os: 91RAM: 270 kbit

author: Someone
author_rank: Super Contributor
timestamp: May 21, 2020, 11:53:33 pm
content: Quote from: soFPG on May 21, 2020, 02:12:09 pmIts not possible to make a realistic estimate from so little information. Download their tools and try building a sketch of the system to see if it will fit.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: May 22, 2020, 06:03:31 am
content: My (beginner) strategy: Buy the biggest board you can and use that for creating the design / experimentation.When the design is working and done - buy the smaller chip that will fit that design.

author: Ice-Tea
author_rank: Super Contributor
timestamp: May 22, 2020, 09:08:45 am
content: Quote from: soFPG on May 21, 2020, 02:12:09 pmNobody said that.. If you want to know: make code for it, doesn't even have to be functional, but at least a facsimile on some level and see if it compiles.And perhaps you need to pay some attention how you plan to buffer this. Buffering inside the FPGA is a *lot* easier in every single way, but in that case 270kb is probably insufficient by *far*.

author: soFPG
author_rank: Frequent Contributor
timestamp: May 30, 2020, 08:15:35 am
content: QuoteSo what does that mean? As far as I understand from your answer it doesn't make sense to interface an image sensor at 75MHz at all?I don't understand how slow or fast rise times affect the FPGA and why I've never read about it in context with microcontrollers? Wouldn't a series resistor produce a voltage drop in the line and therefore reduce signal integrity? I've never seen a PCB with an FPGA on it which had dozens of ferrite beads around it (considering how much I/O capabilities an FPGA has there should be hundreds of ferrite beads?).

author: Ice-Tea
author_rank: Super Contributor
timestamp: May 30, 2020, 10:28:51 am
content: Quote from: soFPG on May 30, 2020, 08:15:35 amI think this is mainly in response to your assumption that 75MHz would not be a problem at all. You need to be aware that the ICs ability to run at that speed is only part of the equation. There are board and system design considerations as well. Which is mainly where edge rates come into play.QuotePerhaps the documentation for uCs that you've read were SW centric? In addition, contradictory enough, it's the ability of FPGA to handle very high speed IO that causes the problem. If your IO pin is capable of driving 350MHz signals, this means that it produces very fast edges. Even if you use that pin to drive a 115kbps serial interface it does so with the same HW and thus the same edge rate. Which causes all sorts of nastiness. Run-off-the mill uC may have slower IO with slower edge rates and thus less problematic behaviour as well.QuoteYou need to look into wave theory a bit. In "steady state", there is no voltage drop as a CMOS input has very high impedance, so it does not draw current and so there's no voltage drop over the resistor. The resistor is there for the moment where the driver launches the wave in the conductor: the resistor will limit the current at that time and will so reduce ringing, EMI and all other good stuff.QuoteThen you have not been paying attention. They are there for sure. The reason you don't find them on all interface is manifold:- Some (especially high speed) interfaces have their own termination scheme.- Over short runs (which requires carefull consideration and good layout) restrictions lessen considerably- In some cases the FPGA's ability to 'choose' edge rates can help out.- Some designers will just go with the "meh, if it works it works approach".

author: tggzzz
author_rank: Super Contributor
timestamp: May 30, 2020, 10:34:10 am
content: Quote from: soFPG on May 30, 2020, 08:15:35 amAt these frequencies components (such as wires) cannot be understood in terms of lumped approximations.You need to understand transmission line theory, particularly the various termination strategies and when to use them.You need to understand that the concept of "ground" or "0V" is a convenient fiction, which does not exist in practice.

author: soFPG
author_rank: Frequent Contributor
timestamp: May 30, 2020, 10:50:23 am
content: QuoteThank you, I got that part the other way around. I thought short edge rates would be a problem for the FPGA.QuoteDo you mind going into a bit more detail why there are such problems? As far as I understand a display with an SPI, for example, has this I/O built in as a hardware module. Furthermore, FPGAs are a combination of lookup tables and, depending on how they are interconnected, can produce relatively high latencies in comparison to pure hardware implementations. So in that perspective, the FPGA is slower than the real hardware (I hope this makes sense).QuoteI don't really have any in depth education in electronics

author: tggzzz
author_rank: Super Contributor
timestamp: May 30, 2020, 11:03:25 am
content: Quote from: soFPG on May 30, 2020, 10:50:23 amIt is unrealistic to expect people to spend their time creating (poor) material for you to read, when there are many excellent resources available. They will probably provide you with pointers to "where the dragons lie" and search terms, but you will have to do the research and learn the material yourself.QuoteIn that case you have two strategies:learn the relevant sunset of electronics relevant to your task, ordo something and - if it doesn't work reliably - decide to understand the relevant part of electronicsAt this stage you should not consider making your own FPGA module. You should buy an FPGA module and embed it in your circuit. Best to ensure that every i/o line has a ground line next to it (to form moderate quality transmission lines). So not even think of using solderless breadboards.

author: asmi
author_rank: Super Contributor
timestamp: May 30, 2020, 02:50:35 pm
content: Quote from: tggzzz on May 30, 2020, 11:03:25 amThis is why 4 layer boards are so great! It's because you can have a solid ground plane underneath all your IO lines, and if the plane is close enough to the signal lines (like 0.08-0.1 mm which is typical for impedance-controlled boards), it greatly reduces crosstalk so you can pack your traces tighter - for example a rule of thumb for DDR3 signals is "1T-3T", which means you need to separate your signals by 3 times the distance between trace and a reference plane, but in case of lower frequencies you can use 1T-2.5T or even 1T-2T.Another thing was kind of hinted at above - reference plane doesn't actually have to be ground, there is nothing special about it, it can just as well be a power plane that is powering IO buffers for these signals. In fact for 4 layer boards you often have no choice but to use power plane as reference plane just because of routing constraints.

author: Bassman59
author_rank: Super Contributor
timestamp: May 30, 2020, 05:40:34 pm
content: Quote from: soFPG on May 30, 2020, 10:50:23 amHere's the problem. SPI, like all synchronous interfaces, has a clock signal. A receiver cannot distinguish between a proper clock edge and a glitch. Poor signal integrity causes glitches. You can look up the reasons for this, but the short answer is that an edge rate that is "too fast" without proper termination and line impedance causes reflections and those reflections end up looking like glitches. (For the full treatise on this, read Johnson and Graham's "Black Magic" book.)The receiver sees the glitch as multiple transitions on the clock when only one should occur. For SPI this means you clock in more bits than you expect. So reducing the clock rate from, say, 10 MHz to 1 MHz doesn't solve the problem because the edge rate remains the same.The good news is that most FPGA families have built-in signal integrity structures. These are input terminations, output (source) terminations, the output slew rate controls and the output drive controls. Some advanced microprocessors have similar options. Combine those with what are likely "typical" board layouts where parts are quite close together so trace lengths are rarely longer than a couple of inches, and most of the concerns about signal integrity are addressed. You need to be more concerned about impedance mismatches when going through connectors and onto cables than signals between two parts on the same board.As for how the actual logic is implemented -- say an SPI port in an FPGA vs one in a microcontroller -- you're overthinking it. The "latency," as such, is more defined by how you load outgoing data into your SPI port. And in the case of FPGAs, you can implement as many SPI ports as you want, and further you can customize them to meet the specific needs of the external slave. (Anyone who's dealt with data converters or image or other sensors is probably nodding their head in agreement now.) Instead of asking, "how do I make this micro's SPI port deal with 24-bit data when it handles only 8 bits at a time?" you just design a 24-bit port and be done with it.As for your original post -- interfacing to an image sensor and estimating the logic needed in the FPGA to do the job -- without knowing the specifics of the design other than "interface to an image sensor," it's impossible to say. What do you do with your data once you read the sensor? What else do you need to do apart from just implementing the sensor interface? Do you need to write the sensor control sequencer or do you just give it a "Frame request" signal? Do you need to upload different configurations to the sensor depending on readout mode? If so, where are those configurations stored? Do you need to store any image data prior to offloading it to "something else?" Do you need to deinterlace or otherwise descramble the image data prior to that transfer?Good luck.