Debug Tip from "Magic's Biggest Secrets Finally Revealed on AXN" show

While ago AXN ran this series "Magic's Biggest Secrets Finally Revealed". It was kind of interesting series. Lets take example where the magician is able to move a egg or himself through a solid wall. watch this : http://www.youtube.com/watch?v=pEIFYFqEyaw

What I learnt from this is, we see what magician wants us to see. We shut our attention to see what is really happening to make that illusion possible. Now in this case if the wall is solid the only way he could move in and move out is from sides. Now what one has to look for is what can help magician move from the side.

How does this translate to debugging ?
Look Programmer and Debugger are really two different personalities although it may be done by single person, Programmer is magician and Debugger is audience. Programmer has algorithmic intent that he has captured in his program and it has failed. While debugger starts looking at it, Programmer shows only his intent but does not allow the Debugger to look at it from perspective of yes this is intent but what can break the intent. This is magic trick of the programmer on debugger where he creates the illusion of this failure is not possible.

As a smart audience, Debugger needs to think like this. Lets accept failure has happened. Lets stop denying that this failure is not possible. What one needs to think is with this given code snippet that had specific intent what can lead to the failure. It may be the fact that program was not designed for a specific input and it was given or in the course of solving main problem certain subtle language specific intent was missed.

Let me elaborate with simple System verilog constraint failure example. I had this simple constraint that sum of two integer numbers[A, B] less than third integer[C]. Third integer[C] was input and other two integers[A, B] were output of this constraint. I checked the input number it was correct but the generated integers[A, B] when I was printing as HEX was showing huge values. I thought how could this simple constraint fail. Well what was happening was int was taking negative values. I really wanted only positive numbers and declaring as int had caused it. While I stared at the simple constraint for long time assuming bug was there while it was just hiding the data type. Programmer would just show me the constraint and hide his trick with integers data type.

Object oriented programming

Often there are times when I find the problem falls in to one of those buckets that have clear mapping to concepts of OOPs. Without much of thought I jump in code and move on.

There are times when its not. Thats when I dive to fundamenatals again. I was asking myself did the object orineted programming exist even before the foraml object oriented language introduction ? Did go back in the time of software days and discussed with few of my friends and answer is YES. Look the various components of the Linux kernel for instance. By using the Structs and function pointers people did do OOP with C. So it is these concepts which had inherent advnatges were made explicit with the help of the explicit constructs in the object oriented programming.

Well thought of diving in and capturing the most essential concepts used in the OOP's and the value that they bring in.

Two key things OOPs is attempting to solve is bring programming closer to problem domain and ease the reuse of the code. When done properly, the approach leads to simpler, concrete, robust, flexible and modular programs.

Also note that basic OOP concepts such as Abstraction, Encapsulation, Inheritance and Polymorphism should not be viewed as all independent things. Instead they are all related. Both the inheritance and polymorphism build on the top of Abstraction and Encapsulation.

A. Abstraction : "Abstraction is the elimination of the irrelevant and the amplification of the essential," according to Robert C. Martin in "Designing Object-Oriented C++ Applications Using the Booch Method," ISBN 0-13-203837-4

Abstraction is something we see in our everyday life. Be it any device like Car, Alarm clock or mobile. There are only few essential things that one needs to know in order to use them. Other details are not relevant and hence abstracted away.

In programming abstraction could be data abstraction or control abstraction.

Miller’s law: humans can only keep 7 ± 2 things in their head at a time.

Key to managing complexity: abstraction.
An abstraction is a view or representation of an entity that includes only the attributes of significance in a particular context. Abstraction is about emphasis on what an object is or does rather than how it is represented or how it works.

While abstraction reduces complexity by hiding irrelevant detail, generalization reduces complexity by replacing multiple entities which perform similar functions with a single construct. Generalization is the broadening of application to encompass a larger domain of objects of the same or different type.

Value abstraction brings in:
1. Hides all irrelevant details and thus making the main program simpler to design, write and maintain when the system is quite complex.
2. Reuse the proven components across applications
3. Abstraction allows the method of the internal implementation to continuously improve without affecting the rest of the system.

B. Encapsulation : Generally viewed as brother of the abstraction. Abstraction is noble but to get its benefits it has to be enforced. Abstraction is way to achieve intended(positive) and encapsulation is prevent any things that could break the abstraction(negative). Encapsulation is mechanism of implementing the abstraction so that its benefits can be realized.

The purpose is to achieve potential for change: the internal mechanisms of the component can be improved without impact on other components, or the component can be replaced with a different one that supports the same public interface. Encapsulation also protects the integrity of the component, by preventing users from setting the internal data of the component into an invalid or inconsistent state. Another benefit of encapsulation is that it reduces system complexity and thus increases robustness, by limiting the interdependencies between software components.[

C. Inheritance : Just like abstraction is closely related with generalization, the inheritance is closely related with specialization. the specialization relationship is implemented using the principle called inheritance.

A new class can be defined in terms of “diffs” from another class. New class is called subclass or derived class; old class is called superclass or parent class.

A derived class inherits all the entities of its parent class, but this can be restricted by access controls. Details are language-specific. Subclasses can override methods and provide its own implementation that may differ from the superclass.

D. Polymorphism : Polymorphisms is a generic term that means 'many shapes'. More precisely Polymorphisms means the ability to request that the same operations be performed by a wide range of different types of things.

The primary usage of polymorphism is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, and so the exact behavior is determined at run time (this is called late binding or dynamic binding).

The different objects involved only need to present a compatible interface to the clients. In principle, the object types may be unrelated, but since they share a common interface, they are often implemented as subclasses of the same superclass.

Polymorphism is only concerned with the application of specific implementations to an interface or a more generic base class. Polymorphism is not the same as method overloading or method overriding.

SystemVerilog Assertions

Although been using the system verilog for a while but have not used the SystemVerilog Assertions(SVA). We could use the Formal verification to verify one of our Arbitration logic. Thats when I realized the assertions are quite overloaded entries. Formal verifciation seems to be good idea for the logic structures of the type "more of less". Meaning small processing but doing lot concurrent processing. Writing simulation environment for such thing is a pain. I found formal verification to be complementry to the the simulation than a replacement. Its certainly interesting and should be carefully made use to cover certain part of verification.

SVA is an integral part of IEEE-1800 System Verilog languages focusing on the
- temporal aspects of the spcification
- modeling
- verification
SVA allows sophisticated multi-cycle assertions and functional checks to be embedded in to the HDL code.

Good thing is it is multi-faceted. The same can be used as assertions, functional coverage, debug and formal verification.

It kind of makes verificatione engineers to invest in SVA assertions.

Communication Protocols -1

I was just looking back at the communication protocol's that have dealt with.

1. Started with simple UART
2. Moved to simple TDM switch
3. Telecom carrier line protocol E1 still kind of TDM
4. From TDM's to packet switched ISDN BRI and PRI from Exchange side
5. TCP/IP
6. H.323 and RTP for the VoIP

Aha...TCP/IP linux software stack interested me after having looked at the Streams based ISDN stacks. But what really fascinated me how would it look if the TCP/IP could be completely implemented in hardware. Not using some dedicated processor but a real custom FSM's. Processing the data at huge rate. May be people might have done it and using it in Server space.

Although I never got to implementing the TCP/IP on the hardware but have seen several mini versions in the bursting serial communication interfaces.

1. RapidIO - Parallel version. We implemented the first version of the spec. 8-bit Physical and link layer with buffer management logic for the protocol layer. It was fun.
2. HyperTransport - which was also called as LDT
3. PCIe - serial versions of it
3. USB3 - Now.

Its been a while dealing with these protocols. Many times during these spec implementation one thing that's not given enough attention by many as to why the things way they are. Although agree not every one may need it but it's certainly very important that at least few of the top level folks know about it. Its DNA.

In case of any ambiguities in the specs it helps to decide which route to take if you knew what intent it is supporting.

I am going to be doing the post mortem of these protocols and try to get what is the basic core problem is it trying to solve. Will be taking USB3 since I am fresh with it. Others have lost touch for a while.

Apple

Past few weeks I have had Steve Job's fever. I read and watched quite a bit about him. His principles of design are Simplicity, Ease of use, allowing creative extensions and reducing the pain.

I generally have these fever of something for a while. Different fever's last different duration. Some longer and some shorter. Some of them I really enjoy. Few of them have left mark on my life. Significant few have been Ayn Rand & Jiddu Krishnamurthy's literature for a while. There on the Madhwa philosophy which I am holding on to it.

Coming back to Steve & Apple. It triggered a thought process of asking myself question of how should things be done whenever I looked at any thing. What's the Apple way to do it ? What's the right way to do it ?

LPG Gas Stoove in the House caught up my attention. I certainly felt it lacked basic feature of Gas leakage detection. With so many fire accidents, I wonder why is this feature missing. Many Indian households could appreciate if Gas Stove could also double up as partial microwave oven. If not full featured at least it should have basic electronics to turn the burner off based on the timer. So next time you could keep milk for heating and not spill it out while you enjoyed your favourite TV show.