MIPI CSI-2 Implementation In FPGAs

[Adam Taylor] always has interesting FPGA posts and his latest is no exception. He wanted to use a Zynq for image processing. Makes sense. You can do the high-speed parallel parts in the FPGA fabric and do higher-level processing on the built-in CPU. The problem is, of course, you need to get the video data into the system. [Adam] elected to use the Mobile Industry Processor Interface (MIPI) Camera Serial Interface Issue 2 (CSI-2).

This high-speed serial interface is optimized for data flowing in one direction. The camera, or the master, sends a number of bits (at least one) serially with one clock. To increase speed, data transfers on both rising and falling clock edges. The slave also has a pretty standard I2C master to send commands to the camera which, for the purposes of I2C, is the slave.

In theory, with one lane of data on the D-PHY, you can get up to 4.5 Gbps on four wires, although you might get less with an FPGA. [Adam’s] post quotes different numbers, but also mentions the FPGA won’t get there anyway. One of the chips used supports the D-PHY directly on the chip, but the standard Zynq does not. Even when using IP, you have to understand this and make the appropriate choices and that’s the main point of the post.

It does illustrate how even using IP isn’t as plug-and-play as, say, hooking up home stereo equipment. You still have to understand what’s going on and how to best work with the IP — in this case both on the outside interface and the inside one.

If you want to look at a simpler serial interface on an FPGA, try our POV project. We also used a similar serial port to fake an internal logic analyzer.

31 thoughts on “MIPI CSI-2 Implementation In FPGAs

  1. I read this earlier when Google auto-suggested it for me… Even though I work with these terms often, I found the article lacking in clarity and detail. For example what are the acronyms PL and PS? I was really disappointed the author didn’t go into the circuit schematic at all, aside from saying it was ‘resistor based’. When I finished reading, it sort of just felt like clickbait.

    1. One quick web search on “Zynq PL PS” gives “Programmable Logic (PL)” and “SoC Processing System (PS)”. I generally find that if I don’t know what something is and it is clearly mentioned in context, it is easy enough to educate yourself. People working closely in some field of knowledge, eventually get sucked into to shorthand notation for maximum communication speed with others in that area.

      1. Explaining terms is good technical writing. Acronyms and initialisms are the bane of technical writing because we often carry in our own interpretations and they can be ambiguous.

        1. As an ideal sure but, the issue of comparative efficiency arises as to how far to go assuming one knows the audience bell curve. In other words if taken to extreme then the article can be way too long, boring and time-consuming even for speed readers. A good start as accepted protocol is as per my earlier comment on this thread (first use has ancronym spelled out) and where more specialised even for those in a narrow abstract field already considered advanced then a considerate glossary of terms helpful and at end so as not to clutter.

      2. A good writer will always define a technical abbreviation (or TA, in industry parlance) the first or second time it appears in context.

        Anything else is lazy writing, or assuming a deep contextual frame of relevance.

    2. The normal and well accepted procedure as standard in technical writing for a broad audience is to put the term in capitals fully spelled out first followed by the abbreviation in brackets then any later use the acronym is fine but not before explicitly expanded Eg

      “Evidence shows Global Positioning Satellites (GPS) incontrovertibly prove special and general relativity valid, nowadays we would be lost without GPS and corrections in everyday use”

      Its of course arguable the audience is not broad in this case or knows the pre-requisites, in this situation however since the posting goes to readers who have not been qualified or are able to be by the writer then the above example should be implemented as mandatory as it causes less confusion and is more efficient.

      This might well change with some pre-requisites lookup script which could scan for conjunction of readers verified knowledge in the field with the writers draft and subsequently substitute the necessary elaboration, though we aren’t at that stage yet. Therefore best to adopt the standard protocol where practicable and where cool humour injection is entertaining ;-)

    3. HI Nathan, I wrote, the blog I am sorry I did not explain it all in depth, after writing 250 plus blogs on how to use the Zynq I do at times take it for granted people know the acronyms.

      It is a little light on detail for two reasons one it was an introduction and two the CSI-2 spec is pretty locked down. I work with the spec a lot and do not want to get in legal trouble.

      That said I just created a MIPI FPGA camera project which is on hackster and will come with all the source code for the FPGA and importantly the SW. I am jut uploading the project now. If you want you can take a look on hackster and see the finished project which includes everything you need

  2. That author does generate a lot of clickbait…
    That said, he has made numerous earlier posts about the Zynq architecture, and probably assumes that the readers understand the Zynq architecture well enough not to have to explain PL and PS.

    BTW, For the Xilinx heterogeneous FPGAs:
    PS = the ARM cores + hard peripherals
    PL = the fully programmable FPGA fabric

      1. PS = Processing System = the [Advanced [Reduced Instruction Set Computer] Machines] cores + hard peripherals
        PL = Programmable Logic = the Field Programmable Gate Array fabric

    1. But if the article is on MIPI CSI, it should go into detail. All I got was “it’s like what you already know about DDR, and controlled basically over i2c” and then a bunch of screenshots of whatever vendor tool. That really doesn’t get us too far.

      1. No, it doesn’t, but the problem is that MIPI keeps the CSI and D-PHY specs on lockdown ($$$) for member companies, and these IP blocks are not trivial implementations. (I’ve read the specs and done some design work in this area). It’s just not an easy thing to dig into in a blog post. Most of the devices that work via DSI or CSI are only available in production-run quantities.

        That said, I agree it’s light on details.

          1. Not if you’re designing your own it’s not. You’re comparing a finished product, where the developer paid big bucks to access the MIPI CS specification, to a thing complete noobs just plug in. Go find a newer camera chip and interface it to the Pi. Good luck finding what you need to make it all work.

        1. Hi Evan,

          Your right the spec is pretty locked down, and the article was meant as an intro for how we can use MIPI in our Xilinx FPGA. It is a fine line between introducing something and getting in legal trouble for giving away elements of the spec so I based it mostly on freely available info.

          I have just created a project on my hackster account which shows all the detail and the code as I said in the blog it is just uploading to my github account. Hopefully it should help illuminate the issue a little more



    2. Alan, thanks for explaining the terms, I must admit I had kind of taken it for granted the readers would know what I was talking about is the 265 installment of the blog. I will make sure to take more care in future.

      I might generate a lot of articles but I hope they are of use to community, I just love working with FPGA and writing about them.

  3. Since the specialists are reading this and I’m in no way up to speed of recent fpga product ranges for cost effective tech of last 10 years, in that I would first focus on other methods can someone comment on the viability of this requirement for implementation in FPGA for first 100 units.

    1. Array of say 64 off 24 – 32 bit counters addressable same as ram parallel access such that high access speed the target from a 32 bit suitable CPU bus/instruction such as Single Instruction Multiple Data (SIMD) for typical range of Digital Signal Processor (DSP) either multiply accumulate or data times indexed coefficient to array sort type. Not for control systems operation, primarily graphic display generation so all safe for time being, interface to novel controllers far later…
    2. Individual count inputs of course, count up only is fine (up/down later on larger array on 2nd rev)
    3. Timebase selectable such as from a table of values for range representing 0.01s to 1 sec in classic 1,2,5 dividers each decade, maybe binary steps later.
    4. Same timebase all counters (separate from common table in 3 for later on 2nd rev)
    5. Input Freq range for all counters 100KHz to 100MHz potentially to 1GHz for 64 bit DSP (2nd rev)
    6. Package, size, power consumption not relevant for 100 or so proof of concept units.
    7. I2C type other other serial interfaces desirable for setting config or for getting data at slower rate or push button input to switch tables of coefficients and timebase selections.

    That’s a start, reply here to firm up details or send msg via my name link through quora.com
    Comments and queries welcomegenetal or specific is fine might take while get back if I need to verify with others but, for most part have checked the data flow model…

      1. @WinkelVisser
        Sorry you miss the point, the intent is primarily to bring up the matter for discussion as a form of challenge if you like and in front of an appropriate audience to see what eventuates. It should be obvious its early stages of a potential project before any sort of substantive budget has been set.

        You also haven’t considered the benefit of the likes of quora.com as an efficient first step establishing some tenure of the buyer as indicative and a filter from random anonymous nicknames who show themselves up spouting insulting prejudice such as by stating “..your bloody”

        You might also want to appreciate and consider risk assessment issues that relying on an email as first line of contact is incredibly naive, learn how quora and Facebook handle messages vs easily deleted/edited emails that might give you a clue. Isn’t it obvious claims and insults dirt cheap, it so easy and overall stupid for random annonymous nicks to spout prejudice only making noise offering nothing useful well, other than declaring their ignorance and cowardice as a nickname. Your site wonderbread.co
        “This site can’t be reached
        wonderbread.co’s server IP address could not be found.

        Try something better for a change, add something useful, try the topic :-)

        1. “random annonymous nicks to spout prejudice only making noise offering nothing useful” – you perfectly describe facebook. I do not really know this quora system, but perhaps it’s similar. If I want to discuss something in public, then a forum is a good way. E.g. this forum, you do not have to redirect to another one. Especially as it seems you can not do anything without prior registration.
          If I shall take something serious, I will not primarily discuss it in public. Email is a very good media in this case.

    1. Absolutely viable. Be a pretty big FPGA – you’re looking at >2k registers just for your counters, and at your count speeds you can’t really multiplex them, so for a first attempt you’d want to start somewhere over 10k LUT (so your chip will come in around $30-40 or so), but you might be able to pack that down later. What is the timebase supposed to do, reset the counter?

      100MHz for a counter is easy, 1GHz is extremely difficult. You can get 200-300MHz from a number of FPGAs, although you’re pushing the IO buffers at that point. There’s no real lower limit – you can count to DC just fine.

      Controlling it via I2C isn’t too bad. Your main parallel bus for data will depend somewhat on the DSP architecture to get optimal timings.

      1. Cool, thanks for the observations HaxGrrl good points.
        Cost fine, yes timebase to reset counters of course naturally buffer/latch.

        On reflection approach more idealistic to higher end along lines of one off development platform which I guess easier with hcmos logic/dual port ram etc & smaller (set) FPGA for which tool sets off shelf. Final product likely not need anywhere as much infrastructure or high speeds though I won’t be able to confirm until I have some means to evaluate wide range and that means National Instruments/LabVIEW thpe daq system. In new year can update on application. Though I already see value in that development setup for a few other areas.

        I also love these sorts of diverse challenges, relish getting back into deep end as it’s been 20 years since I did much with pld/gals, will be reviewing suppliers and their support forums, thanks again

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.