This slide captures a lot-- almost like a roadmap for the next few steps in improving efficiency for contemporary applications. Moving from the left to the right requires significant investment in terms of development time, and for ASICs, money, because of the complexities of designing applications on each platform and the specialization required to obtain a high quality solution.

The programmable DSP is interesting because it requires the most software specialization but also appears to require a fair bit of hardware specialization since it implements IP blocks for a highly specialized domain. On top of that, the DSP has some degree of programmability as opposed to being an entirely fixed function ASIC.

This slide got me thinking about the programming expertise needed for each of these types. Earlier I thought that knowing C and C++ is sufficient to write very performant code. In this course I learnt that it is not merely enough.

One other interesting thing with ASIC that came up from this lecture. ASIC is very application specific and if an algorithm changes, then pretty much it is not applicable anymore. But it is not only about the algorithm but also about the future needs of the application that ASIC is used on. In my opinion, that would be a barrier for using it + the high cost mentioned on the slide.

I really loved this slide too! Some notes from lecture that add additional color:

• CPU: least energy efficient, like an ARM core (as opposed to x86, which has more baggage compared to ARM in terms of energy efficiency). Can get more efficiency using parallelism and other CS 149 techniques
• GPU: throughput oriented processor focused on data parallel applications, which make programming tasks more challenging (need to write in CUDA or OpenCL)
• Programmable DSP: high level languages don't cut it anymore, you basically need to write code at the ASM level (instructions are very idiosyncratic and powerful, no compiler can generate them)
• FPGAs / reconfigurable logic: now the programming model is even more challenging, you need to use a hardware description language and need to deal with the idiosyncrasies / limitations of the architecture of an FPGA. For example, implementing content-addressable memory (as in caches) is not trivial on FPGAs
• ASIC: first develop the ASIC, debug the hardware description, and then fabricate the chip ($10M+), the cost needs to be justified!

This part of the lecture was pretty interesting to me. Kunle mentioned that, in high-level, that we could see this as a tradeoff between flexibility and efficiency. It helped me understand that the more we understand about a certain task/the more specific a particular task is, we can have more efficient methods to tackle the task but we would lack the ability to distribute the tool to solve a wider range of problems.

@ghostcow Love the point about content-addressable memory in FPGAs! I assume this is the kind of thing the slides mean when they say its an active area of reasearcher to make programming them easier. I imagine someone is working on some compiler-like program that can take a high level description of what operations require what data and ouput FPGA HW descriptions that wire up the memory efficiently but for dynamic addresses that would be intractable.

This slide really summarizes all of the challenges when creating a new application/program. There are so many design choices that need to be made and it seems like it is very overwhelming. As someone who does not know much about FPGA's and ASIC, is there a place to learn about these more? If I wanted to use an FPGA, how would I get started with that?

My impression is that the devices further to the right on this axis are programmed in language much closer to the hardware that resembles, or is, assembly. Are there any (domain specific, maybe) languages for devices on the right that are designed to compile down to lower level instructions?