sharadsinha

Posts Tagged ‘EDA’

What is the purpose of a lab?

In Education, Embedded Systems on July 22, 2014 at 9:22 PM

Laboratory sessions at universities form an integral part of curriculum. This is specially the case with science and engineering disciplines. While different disciplines have different requirements regarding what will actually be done in these sessions, a basic question to ask is – what is their purpose? I will discuss with respect to labs for computer engineering curriculum. These lab sessions are meant to give hands on experience to students in working with devices like micro-controllers, microprocessors, field programmable gate arrays (FPGA) etc. Often times, students are given codes (programs in a programming language) written by a teaching assistant (TA) which they are expected to use to program the device. They are expected to program the device using some Integrated Development Environment (IDE). The students may be required to modify these programs based on the lab exercises.

Among other things to learn, I have realized that there is too much emphasis on learning how to use the IDEs. This is not peculiar to one country or university. It seems to be the norm at many places if you look at the lab descriptions available online. It is true that different IDEs look dissimilar (obviously!) and the options that they provide to a user can be in different parts of the graphical user interface (GUI) and under different menus. However, they all follow a basic flow which is essential and relevant to the system or device that they target. Good IDEs are similar in layout and are easy to navigate. Therefore, it should be easier for students to move from one IDE to another after they have learned at least one properly. Besides, it is not so much the IDEs themselves but the different steps in the flow which are more essential to learn. After all, IDEs package different steps, necessary to program such systems and devices, into one nice coherent click-and-run flow.

I believe that lab sessions are meant to complement lecture based learning. How the different steps , algorithms, methods etc. taught in a class come together in a coherent manner in order to enable the programming of such systems, is an important learning outcome. Besides, when working with development boards and evaluation kits, students can learn to navigate through user guides, reference designs, schematics, bill of materials (BOM) files etc. These will seldom be taught in class room, but they form a very important part of an engineer’s life in industry. Lab sessions provide an opportunity for students to relate and expand their class room based learning to what actually goes into designing, building and testing real world systems. I think that should be one of the most important guiding factor for faculty members when designing lab sessions.

Advertisements

Error Documentation: Why not?

In Design Methodologies, Embedded Systems on August 27, 2012 at 12:48 PM

I am sure that many of you who have used any software tool that throws up errors have spent time (at one point or another) figuring out what those errors mean. Every software tool that is used in any electronics or software design project throws up errors. Be it is GCC, EDA tools etc. One might have used the support channel of the vendor, user forums, websites like stackoverflow etc. to understand the meaning of those errors. A number of times, these errors do not make any immediate sense to the user. There are also many errors which can be because of multiple reasons. Once one gets a list of these reasons, one has to choose the one that is most likely to be applicable to the case at hand. All this reduces productivity. The time spent searching, gathering and analyzing information could have been better utilized focusing on design. Would it not be better if tool vendors also released documentation on the different kinds of errors that their tools might throw up and the associated reasons? I believe that this “ready-reference” would be very beneficial. After all during the development of those tools, the vendors are indeed aware of why a particular error has been thrown up. Why not just compile all that information in one place and help the user? Also, the errors are not always due to problems in the design source files. Sometimes they are there because the tool expects the user to structure the project, tool inputs etc. in a certain way. Given the complexity of modern EDA and other development tools and the time spent in learning them for effective use, it would only be welcomed if vendors offered this extra level of documentation.