What: Talk by Robert W. JKembel on Unified Data Center Network
When: Wednesday, 21st March, 2012, 5 pm to 8 pm.
Where: Yashada, Rajbhavan Complex, Baner Road, Pune

Registration and fees: This event is *FREE* for all to attend. Please RSVP to amarjeet.sharma@qlogic.com.

I was invited to visit the Nvidia Tech Week this past weekend (February 25-26, 2012) at their facilities in Pune. This is a great concept – getting employees to invite friends and relatives to actually see what their company is all about is very good social outreach and a fantastic marketing initiative. If more tech companies in the area do similar events once or twice a year, it will help lift the shroud of technical opaqueness around them. I think hosting similar events in area colleges will also help students realize that even VLSI/Embedded Systems Design is cool.

I was given a personal tour by Sandeep Sathe, a Sr. Development manager at Nvidia and also met with Jaya Panvalkar, Sr. Director and head of Pune facilities. There was enough to see and do at this event and unfortunately I was a bit short on time. It would have taken a good two hours for a complete walk-through, so I decided to spend more time on the GPU/HPC section though the Tegra based mobile device section was also quite impressive. It’s been a while since I actually installed a new graphics card in a desktop (actually, it’s been a while since I used a desktop), but graphics cards have come a long way! Nvidia is using standard PCI Express form factor cards for the GPU modules with on-board fans and DVI connectors.

The following are key takeaways from the demo stations I visited

GeForce Surround 2-D
Here, Nvidia basically stretches the game graphics from a single monitor to three monitors. Great for gamers as it gives a fantastic feel for peripheral vision. The game actually doesn’t have to support this. The graphics card takes care of it. The setup here is that while the gamer sits in front of the main monitor, he also sees parts of the game in his peripheral vision in two other monitors that are placed at an angle to the main monitor. I played a car rally game and the way roadside trees, objects moved from the main monitor to the peripheral vision monitors was quite fascinating.

GeForce 3-D Vision Surround
This is similar to the above, but with 3D. You can completely immerse yourself in the game. This sort of gaming setup is now forcing monitor manufacturers to develop monitors with ultra small bezel widths. I suppose at some point in the next few years, we will be able to seamlessly merge graphics from different monitors into one continuous collage without gaps.

Powerwall Premium Mosaic
Powerwall is a eight monitor setup driven by the Quadro professional graphics engine. Two Quadro modules fit into one Quadroplex industrial PC to drive four monitors. Projectors can also be used in place of monitors to create a seamless view. The display was absolutely clear and highly detailed. The Powerwall is application transparent. Additional coolness factor – persistence data is saved so you don’t lose the image during video refresh and buffer swaps. This is most certainly a tool intended for professionals who need high quality visuals and computing in their regular work. Examples are automotive, oil and gas, stock trading.

PhysX Engine
PhysX is a graphics engine that infuses real time physics into games or applications. It is intended to make objects in games or simulations move as they would in real life. To me this was very disruptive, and highlight of the show. You can read more about PhysX here. It is very clear how PhysX would change gaming. The game demo I watched had several outstanding effects: dried leaves moving away from the character as he walks through a corridor, glass breaking into millions of shards as it would in real life. Also running was a PhysX simulation demo that would allow researchers to actually calculate how objects would move in case of a flood. What was stunning was that the objects moved differently every time as they would in real life. PhysX runs on Quadro and Tesla GPUs. It is interesting to note that Ra.One special effects were done using PhysX.

3D photos and movies
Next couple of demos demonstrated 3D TV and photo technology using Sony TVs and a set of desktops/laptops. Notably, the Sony 3D glasses were much more comfortable compared to others. Nvidia is working with manufacturers to create more comfortable glasses. There was also a Toshiba laptop that uses a tracking eye camera to display a 3D image to the viewer regardless of seating position without glasses. It was interesting. However, the whole 3D landscape need a lot of work from the industry before it can become mainstream.

Optimus
What was explained to me was that Optimus allows laptops to shut off GPUs when they are not needed. They can be woken up when high performance work is required. This would be automatic and seamless, similar to how power delivery is in on a Toyota Prius. This sort of a technology is not new to computing – a laptop typically puts a lot of components to sleep/hibernate when not being used, but the GPU is not included.

Quadro Visualizations
This allows 2D/3D visualizations for automotive, architectural and similarly complex systems for up to one thousand users at a time. You can easily change colors, textures, views so everyone can comment and give constructive feedback. I was not sure if the design can be changed on the fly as well. Nvidia is working with ISVs like Maya and Autodesk on this.

Tesla
Tesla GPUs use chips that are used for high performance computing and not rendering, which is different from what Nvidia typically does. The Tesla modules do not have any video ports! It has a heterogeneous GPU/CPU architecture that saves power. In fact, the SAGA-220 supercomputer, dubbed India’s fastest, at ISRO’s Vikram Sarabhai Space Center facility uses 2070 Tesla GPUs along with 400 Intel Xeon processors. In addition to supercomputing, Tesla is very useful in 3D robotic surgery, 3D ultrasound, molecular dynamics, oil and gas, weather forecasting and many more applications.

Tegra Mobile Processor
Next few demos showcased the Tegra mobile applications processor based on ARM Cortex A9 cores. The HD quality graphics and imaging were impressive. It is clear that smartphones and tablets of the day are clearly far more powerful compared to desktops of yesteryear and can support highly impressive video and audio in a very handy form factor.

In all, I had a great time. As I mentioned earlier, Nvidia along with other tech companies in Pune should hold more of these kinds of events to give technology exposure to the larger population in general. I think it is important for people to know that the stuff that makes Facebook run is the real key and that is where the coolness is.

SystemVerilog Guru Cliff Cummings is back in town and he will be holding another seminar on April 19th at the MCCIA auditorium on Senapati Bapat Road from 4:00pm to 7:30pm. Most recently, Cliff was here in November 2009 and this seminar gives a great opportunity for engineers to  re-engage with him. This event is completely free, but registration is required. Please visit this link to register and view the agenda.

 This event is co-sponsored by Qlogic and Cadence who I must thank profusely on behalf of the PuneChips community. It is not very often that internationally renowned experts visit our city and hold free seminars, but QLogic and Cadence have made it possible. So, I encourage everyone who has any interest in SystemVerilog to attend and participate.

photo credit: kalleboo

This is a PuneChips event, a forum for Pune people interested in semiconductors design/apps/EDA

What: Talk by Gandhar Gokhale on Moving from 3G to 4G
When: Saturday, 26th March 2011, 10:30 am to 12:00 noon.
Where: Venture Center, Classroom E, NCL Innovation Park, Pashan Road

Registration and fees: This event is *FREE* for all to attend. No registration required.

Mobile Networks - Moving from 3G to 4G
This presentation will be an introduction to the mobile network evolution. It’ll run through the evolution of generations of mobile networks to the upcoming 4G.  The radio interface and terrestrial network evolution in each generation will be briefly touched upon. The LTE (Long Term Evolution) as the candidate technology for 4G shall be explored. We’ll conclude by discussing how these generations have impacted or shall impact our lives.

About the Speaker – Gandhar Gokhale
Gandhar Gokhale is a software architech with LSI Corporation. He has more than 12 years of Network Software development and Network Security experience. He completed his  M.E. (Telecom) from IISc Bangalore and B.E. (Electronics) from WCE Sangli.

photo credit: oskay

On November 11, 2010, Pune Mirror did a story on investments related to Storage, Networking and Computing chips in Pune. The story is not available online unfortunately, but can be read in the e-Paper version, under ‘City’ section, Page 07. For those who are interested in reading this article, we are uploading a scanned copy of this story. Read it here: Pune Area Hi-Tech Investments Total $1B

Image Sourve: allSAN.com

Howard Goldstein spoke to the PuneChips community on Storage and Networking Protocols earlier this month. His presentation is now available here as a PDF file. Please download as required.

Goldstein Storage Networking – The Path to Performance

photo credit: oskay

This is the second in the blog series titled Field Manual for Verification Planning written for PuneChips by Suhas Belgal . The blogs deal with functional verification of digital ICs and cover mostly the pre-silicon verification phase.  

Welcome to the second article in the Chip Design Verification blog series. In this article, we will look at the Test-plan development part of the verification program. We are going to explore the method to the madness of developing effective test-plans.  

Some of the questions that come to the mind are: how do we know if the test-plan is complete? How do we map the test-plan to the ‘tests’? How do we ensure coherency between the test-plan and the test data base throughout the project (and beyond)? What’s a good test-plan template? How should the cases be organized? What additional data or information needs to be in the test-plan? Throughout this article, we will address these questions. What one should expect here is not a ready-made solution, but the underlying philosophy, various options available for implementation and key considerations. As mentioned in the introductory article, there is an ‘intellectual part’ which requires the best and the brightest engineering mind and cannot be substituted by any tool or practice. This will be clearly identified wherever applicable.  

Example

Let’s revisit our example. The DUT is a simple SOC with some standard SOC components – a host processor, a co-processor (such as a DSP or some such computational element), internal buses for both control and high speed data transfers, memory sub-system (DDRs, SRAMs), peripheral IO interfaces such as USB, UART, and internal SOC control elements such as IO muxes, clock/power management unit, interrupt management unit.  

The following block diagram illustrates our example. 

Example DUT

What Rather Than how

The first step in any verification program is to review the Design/Architecture Specification documents along with any other relevant supporting documents such as ‘Standards Specifications’. This becomes the basis of what needs to be tested. At this stage, don’t worry about the how this block or chip needs to be tested or any other logistical issues such as schedule, simulation speed, resources etc., as it would cause unnecessary distraction, and might cause you to overlook some of the test-cases. Any cracks at this stage are the most expensive. Achieving a high quality list of ‘what’ needs testing is indeed an intellectual process – this list forms the ‘denominator’ in the coverage ratio – regardless of tool or method used for measuring coverage.  

Given the importance, this step needs undivided attention. Block off time on your calendar, hide in conference rooms, work from home, or do whatever it takes to focus. In addition, indulge in lots of formal and informal brainstorming sessions with various members of the team such as the architects, principle designers, other senior verification engineers, software/firmware engineers, and even marketing personnel. During these discussions, don’t let the other person drag you into the ‘how’ or any other logistical issue like schedules or resources. Also note that everyone will be providing you their perspective based on their roles/background. I call these Swiss cheese slices; all will have holes, but stacked on top of each other will give you a solid list of cases.  

Lastly, start organizing this list hierarchically and in sections. Typically, there will be following sections:  

• Architectural or black box cases
  • eg, Read a sector from SATA interface with the interrupt enabled. In the Interrupt Service Routine (ISR), examine the contents of the sector read and clear the interrupt.
• Software or use cases
  • eg, The boot sequence; Bus enumeration sequence for the USB port
• Micro-architectural or Design cases (aka white box)
  • eg, state machine interactions; buffer full/empty conditions
• Block/sub-block level
  • eg, USB Link block level: Rest of the chip can be substituted by a Bus Functional Model (BFM)
• Cluster or System level interactions
  • eg, System Memory coherency and interactions with multiple requestors
• Compliance
  • eg, SATA, USB standards Compliance for interoperability;
• Error cases
  • eg, SATA Device sends erroneous packets
• Performance
  • eg, Memory Bandwidth  

Example of a hierarchy:  

• Major Feature: eg. USB packet Transfer types
  • Minor Feature: eg. Bulk Transfer
    • Test Scenario or a Test Matrix: eg. Minimum and Maximum size Bulk OUT transfers

In addition to writing down the test scenario, it is extremely important to note down any assumptions or questions one might have.  

A Generic Block

Let’s create a generic block to illustrate the process of identifying thorough top-down test scenarios:  

Generic Test Block

This block has several input and output data ports. There is a separate interface to access control/status registers. There are two clock domains and internal memory for local storage. In addition, there are some side band signals, along with several asynchronous events coming into the block such as reset, clock disable, mode control signal and so on. As an exercise, try mapping any blocks or designs you have worked in the past into this – you will be amazed! Make it even more interesting – map a microprocessor into this block!  

First order Test Scenarios for this generic block:  

• Access to all control/status register
• Access to all memory elements (both via standard datapath, and any special backdoor access)
• Complete protocol testing of all input and output interfaces (control and datapath)
• Exhaustive/interesting testing of all control logic (first order and ‘interesting’ register coverage)
• Exhaustive/interesting testing of any data computation performed in the block
• All possible/useful combinations of the two clocks
• Side band signal functionality
• All asynchronous events crossed with each other and skewed against each other
• All asynchronous events during ‘important or interesting’ states  of the block
• Memory element access during operations – corner cases (buffer full, empty)
• Stalling
• Hard and soft reset behavior
• Power management cases
• Performance

We just saw the ‘science’ portion of test-planning! Generating a robust first order list of scenarios for any block should be possible by going through the above exercise. This starts becoming an ‘art’ (or the intellectual process), once we start creating second order or combination tests; in short, the optimization process.  

Priorities

Now that we have a list of ‘all’ cases that need to be tested or covered, next thing to do is to prioritize them according to the importance. This can be used throughout the project to make tough schedule related calls. The priority should also be used to generate weighted coverage numbers.  

What is the basis of the priorities or the importance? The following set will serve as a useful guideline:  

• Atomic hardware functions that cannot be worked around using software. For Instance, basic addition instruction in a microprocessor
• Advertised features or normal operation of the machine are more important than others
• Any bug that can cause a catastrophic failure in the normal operation of the machine.

Another pragmatic view point is ‘assuming worst case scenarios’ – let’s say a bug that slips affects the reset or the boot sequence – this chip will be DOA (Dead on Arrival) – no bring-up or characterization can be done on this chip. Instead, say, the access to certain memory locations don’t work – this is definitely not something to be proud of, but, on the positive side, at least the operations of the chip using the lower memory locations can be tested out (including the development of the software). Thus, one would put the boot sequence test at a higher priority compared to the access to the entire memory range. Again, note, this example was just to illustrate relative priorities. Any verification plan that does not cover access to the entire memory map is indeed a very poor one!  

Note that this was just to illustrate how one can go about the prioritizing. There are a lot more factors that need to be considered for prioritizing that depends on your project goals.  

Reviews

We have identified, documented and prioritized all the test-cases (the ‘what’ portion). It’s time for a formal review. Very important to note – DO NOT WAIT to complete identifying and documenting all the cases before calling a review. As we all know, verification is an NP complete problem, and thus, one can never say that their plan is theoretically complete! Use judgment, and call the review once the plan is at, say, 90% mark. Some useful guidelines for the review:  

• Circulate the review material well in advance so that the audience has a chance to study it.
• No lengthy text or narration.
• Walk through the cases hierarchically (breadth first)
• Use appropriate visual forms such as tables, lists, pictures (remember, a picture is worth a 1000 words)
• Start with a block diagram and a description of the DUT ‘in your own words’
• Required Audience: Design counterparts, architects, and senior design/verification members, owners of adjacent blocks, owners of central blocks, software/firmware engineers, System/board designers and Managers.
• Have your manager or colleague collect action items.
• Don’t let anyone hijack the meeting. Keep it under your control – it’s your meeting.
• Call extension meetings if all the material cannot be covered in one session.
• Solicit feedback on the ‘priority settings’.
• Follow up on all action items and send the updated plan once all the action items are completed.
• Don’t get into the ‘how portion’ (or don’t let any drag you into the implementation) – Cover that topic in a separate review.  

The ‘how’ Portion

Now that all the cases that need to be covered are completely documented and reviewed, let’s look at the ‘how’ part. This part will determine or form the specification for the test-bench.  

The first order of classification will be based on whether something is tested using simulation, formal method or emulation.  Simulation provides more controllability and observability. This makes it easier and more practical to hit white-box cases. Also, debugging is much harder on the emulator. You don’t want to be exposed to first order bugs in the basic operation during the emulation. In fact, simulation based testing needs to be used as a screen before starting the emulation.  

Within simulation the scope of the DUT is the other decision point. Most of the cases intrinsic to a block should be tested at a block level. This makes simulations faster, debugging quicker and test setups easier. Also, during earlier phases of the project, all the adjacent blocks may not be developed or stable for cluster or system level testing.  

Formal method or tools are still limited in terms of ability. These are best suited for smaller blocks that are well specified.  

Cases that need a large number of cycles are best suited for emulation. Other types of cases suited for emulation or prototyping are the ones that test interoperability with real-life interfaces or devices such as SATA or USB, in our example.  

To summarize, here are some of the key factors influencing the testing method:  

• Debug-ability: Areas most likely to have lots of bugs. This is true for normal machine operation during initial phases of verification (fresh RTL code).
• Cases hard to control: error cases, multiple events happening at precise points
• Cycles needed to setup and exercise the case
• Requirement of real life devices to provide the stimulus/response(interoperability)
• Testing speed (some cases need at-speed testing)
• Number of theoretical cases. Some scenarios can explode – and there may be an opportunity to use formal methods to cover such scenarios  

Another practical tip here is to put greater emphasis on debugging ease and simulation times/turn times during the high bug phase, for instance, when there is fresh RTL code.  There is no need to worry about phases or cases where the probability or likelihood of hitting a bug is very low.  

Notes:  

• The test-bench and the test cases should be design in such a way that most or majority of the tests at a lower scope can be reused at a higher level.  Block level cases should be reusable at cluster level, and system level simulation cases should be reusable on emulators. This provides two benefits: the lower level or scope tests can be used as a screen to start testing at the higher level, thereby eliminating any build or database coherency issues. Secondly, the test setup knowledge at lower levels can be used at higher levels. For instance, for system level test cases, one should not be required to understand detailed setup up procedures of a SATA transfer in the context of the SATA Link when it has already been put in place at a lower level test-bench.
• Lastly, apply the 80-20 rule for test-bench designs. That is 80% (read as majority) of cases should be supported by the mainstream test-bench. For the remaining 20% (read as minority), a special ability or a hook needs to be added to the test-bench. Again, apply the 80-20 rule for this remaining 20% and keep going till all cases are covered. This will be reviewed again, and in greater detail, with examples in a future article covering test-bench designs.  

Coverage Measurement/Key Indicators/Metrics

Once the test-plan has been filled with all the test cases (or coverage scenarios) along with the priorities and testing methods, one can start creating various indicators and metrics.  

A single number providing the state of the verification program is always desirable. However, it is important to build this in a hierarchical fashion. This way, one gets to look at the coverage at various granularities such as block based, feature based, scope based and so on. This helps to make tactical project decisions.  In the final section we will look at how all of this data can be organized and consumed.  

The most popular methods of measuring coverage are:  

• Code coverage – toggle, block, condition, state machine, expression.
  This is the easiest way to generate coverage information. It is built into most simulators these days and can be turned ON or OFF with the flick of a switch.
  The advantages of code coverage are the ease of use, and detection of any first order hole. On the down side, it doesn’t quite tell us if we are done. Any ‘missing’ RTL code cannot be detected. Also, the coverage information is mostly combinatorial in nature. Sequential cases don’t get measured. Lastly, dead logic or architecturally irrelevant cases provide false negatives. 
  It is a necessary but not a sufficient condition. Lastly, code coverage monitoring in the mid-phase of the project is a good way to track project progress.
• Functional coverage:
  One of the things that code coverage doesn’t provide is a coverage view abstracted at a higher level. For instance, one will get information about whether all the bits toggled on the address bus, but it will not tell us if all ‘regions’ of the memory were accessed by a particular memory master. This kind of abstracted coverage information starts tying closely with the desired functionality of a particular block. In most of the modern HVLs (Hardware Verification Languages), one can easily instrument these ‘coverage points’ or ‘coverage buckets’ to provide an abstracted view of the coverage. This is the most effective way to track coverage, provided test-benches are developed using HVLs.
• Assertion Based Coverage:
  This is a form of functional coverage.  There are several assertion languages and libraries that one can choose from. Interesting cases can be coded as assertions and the simulator can then ‘watch’ for these assertions during simulations. Note, one can construct very ‘smart’ sequential or ‘temporal’ assertion, and tie these closely to the coverage-plan/test-plan.
• Register Coverage:
  This is a special type of functional coverage. Covering all the bits or knobs that control a particular block’s behavior can provide very useful first order coverage. One can then create combinations of various fields to cover interesting cases.  

Knowing or deciding ‘what’ needs to be measured and setting goals is more of an art than science. This is the intellectual exercise. Let’s take a block with 20 control bits or knobs. If you let a coverage tool measure the coverage on this without any constraints, it will look for all permutations and combinations of these bits or fields – that’s more than a million cases and most of the cases may be useless or irrelevant. Identifying or selecting ‘interesting’ cases is indeed an intellectual exercise. How good someone is in doing this will determine the efficiency and robustness of the verification project.  

Another way to reduce the coverage set or optimize it without risk is to look at orthogonal cases, based on the design and usage. For instance, one may never use two features or blocks of the design simultaneously – say, SATA and the Memory Card interface will never be in a product together. This can be used to drastically reduce the number of test cases. Note, that this can be dangerous if used without proper care. First of all, this has to be documented very clearly. Even better, make it a requirement that such cases need to be officially accepted by the program management.  

Test-Plan Management System

Last but not the least is how do we manage all this data? There is a lot of important data that needs to be created, stored and accessed with different views. Traditional ‘Word’ or even Excel based test-plans are not enough. These are not ‘executable’, hard to keep coherent with the test-base. Oftentimes, the testplan document never gets updated once it is reviewed, and by the end of the project it is almost obsolete!  

The real solution is to create a database for all the information, similar to bug databases. There are several solutions available in the market. Cadence’s VManager™ or Mentor’s ReqTracer™ are some of the examples. Jasper DA offers a freeware named Gameplan ™. Or, one can develop an in-house tool to manage the test-plans. Let’s look at how we might want to organize and access this data.  

Key factors to keep in mind:  

• Ease of use.  Anything complex becomes a deterrent.
•  Test-plan is a live document – keeps getting updated whenever new ideas prop up, and everyone ought to be viewing the most recent version
• Ability for different views
• Marrying the scenarios with simulation or implementation data
• Ability to tightly couple with the testbench collateral
• Track specification/design changes seamlessly
• Removing any room for ‘oops’ through automation
• Query based access
• Using test-plan to manage status information including coverage data.

Records

The atomic record in this database is a test case (or a test scenario). Some of the important fields are:  

• Summary and description field,
•  Module, feature, sub-feature
• Owner
• Test-case submitter (there may be a situation that someone other than the block owner thinks of a case)
• Testing Method(s) used: simulation/emulation/formal
• Scope(s): Block/Cluster/System
• Priority/Weight
• Test(s) that will cover this scenario
• Assumptions/Questions associated
• Coverage measurement method
• Status (based on back-annotated simulation data)
• Tags:  This can be used for queries to build different types of ‘test-lists’ or ‘regression lists’ based on the need.
• Simulation directives

Of course, once you start thinking down this route, there may be other attributes that you can use to make the system even more efficient for your environment.  

Access

Various access points are desired for proper use of this data. Some of these are:  

• Easy to use GUI based system to enter test cases, one at a time
• Importing (from, say, an excel spreadsheet)
• Backdoor access for simulation scripts (query based)
• Exporting into standard formats such as excel (query based)
• Back annotation of results and other status information
• Reporting – html or other forms based on queries (for reviews)
• Metric reporting in a tabular or graphical form (query based) 

So, we have seen the art and science behind creation of test-plans/coverage plans. Test/coverage plan development is a very creative process. To begin with, one needs to have an in-depth knowledge of the DUT being implemented. The ‘hunch’ is a cumulative knowledge of the protocols involved, usage perspective including the use-cases, intent of  the features, design methods used, historical perspective (knowing USB1.0,2.0 while testing 3.0), knowing where the bugs lie. The ‘hunch’ then allows one to prioritize, shortlist ‘interesting cases’. This allows crafting of the next ‘killer’ test case. However, this alone is not enough. Verification is as much about discipline. One might catch all the killer corner cases in a DUT, but completely overlook an entire section! Cases like these are not uncommon. Having a disciplined systematic approach in combing through all the possible test scenarios is a must. This is the ‘science’ behind verification test planning.  

In the next article, we will focus on test-bench design – on how to build robust and reusable test-benches. You might have the best or most exhaustive test-plan, but a poor test-bench can be a project killer.

About the Author:  Suhas Belgal has 17 plus years of experience in Chip Design, Emulation, Modeling and Verification, including 9 years as a Verification Manager. During these years, Suhas has worked for several multi-billion dollar companies such as Intel , LSI, Mentor Graphics, and various start ups, and co-founded a Verification Services company. Over the years, Suhas has played key roles several high profile design teams such as Pentium II, and successfully led several SoC chips to production.  He has experience in a wide range of Verification Methods and tools, and has been a presenter and panel member at various conferences, including the DAC. He has a master’s degree in EE from University of Texas at Austin and a bachelor’s from VJTI, Mumbai.

What: Panel discussion on Future Devices and Convergence as a part of InCSIghts 2010 organized by Computer Society of India, Pune Chapter
When: Saturday, 27th March 2010, 2:00 pm to 3:30 pm.
Where: Suman Mulgaonkar Auditorium, ICC Towers, Senapati Bapat Road, Pune 411016
Registration and fees: This is a paid event. Registration is required.

About InCSIghts:

InCSIghts is the annual CSI IT roundup and will be held this year on March 27, 2010. The event will showcase a broad range of topics that IT professionals and academicians shouldn’t miss.

This event will try to give audiences a sneak peek into technologies that will dominate the future and analyze their impact on IT professionals. It will also focus on issues relevant to industry needs today, both business and technical. InCSIghts is Pune’s premier annual event that delivers an informative and actionable perspective of the issues shaping our industry with a peek at the future of technology. This year, InCSIghts brings you some of the most respected names on Pune’s IT scene with a cuisine of thought-provoking items on the agenda.

We have planned four sessions this year – Technology, e-Governance, Computer Science Research and Future of Mobile Devices and Convergence. Here are details:

Future of Devices and Convergence:

A new breed of mobile devices that offer tremendous productivity boost to the average user is just around the corner. As we are just starting to get used to the ubiquity of constantly connected mobile smart phones, future mobile devices promise a significantly enhanced feature set over the existing ones. Devices such as the iPad from Apple, Kindle from Amazon or the Adam from Notion Ink are some examples that highlight this new trend.

These advances bring new challenges to the software development community which has hitherto been focused on programming for personal computers. It is quite obvious that the software developers must embrace new trends in order to survive and prosper. This panel discussion is the ideal setting to start the conversation between the hardware makers and the software developers, as the focus of the discussion will be on various technologies/platforms/form-factors that will be prevalent in newer devices. The attendees can expect a spirited discussion on the following topics:

1) Awareness of current and future technologies/platforms/form-factors

2) Consideration on power, usability, ubiquity which are not that important in PC programming

3) Programming platforms and programming tools

4) Marketing your software product

5) Considerations for building the hardware

Contact:

Please write to:  info.csipune@gmail.com

photo credit: stars6 / Leonardo Rizzi

On January 15, 2010, LSI hosted its Datacenter Evolution 3.0 forum in Pune. The Pune center is certainly getting a lot of prominence within LSI as the top two LSI execs, Abhi Talwalkar, CEO and Jeff Richardson, EVP Semiconductor Solutions Group, were hobnobbing with the attendees. VP and LSI India MD, Pravin Desale was the EmCee. Talwalkar has a strong personal connection to Pune – he was born here! He has presided over a complete makeover of the company where all internal manufacturing has been completely eliminated. LSI now is a silicon, systems and software Technology Company playing in the Storage and Networking verticals. Obviously, datacenters are a very important market.

Robinson, in his keynote, talked about how datacenters need to evolve to support the upcoming surge in data and traffic (Figure 1).

Figure 1: Surging Internet Traffic and Data; Source: LSI

His take is that new datacenters need to satisfy three key requirements – manageability, scalability and green-ness. A couple of technological innovations are powering the drive to the management and scaling of datacenters; an application aware infrastructure and storage device performance. There are also a number of innovations that reduce datacenter power consumption at all levels from device to software.

Application Aware Infrastructure

Initially, all network traffic was treated the same way, essentially as an Ethernet packet. That, however created a problem where higher priority traffic was often bottlenecked. In addition, there is no way to confirm a packet’s bona fides. The solution to this problem lies in inspecting the packet before it is forwarded to its destination. DPI or deep packet inspection technique allows looking inside a packet to identify what application it belongs to such as e-mail, VoIP, Video, HTTP, etc. and whether the packet is a virus or malware. Application awareness (Figure 2) allows infrastructure devices to meet the quality of service (QoS) requirements of the application along the entire path. With the pending move to cloud computing, application awareness is required to provide consistent performance at all points.

Figure 2: Application Aware Infrastructure; Source: LSI

An application aware infrastructure has better performance, much better levels of security and control and better management of resources. Networking giants such as Cisco Systems and Juniper Networks already use DPI in their latest generation network processors and a number of supporting devices are also hitting the market.

LSI demonstrated their Application Recognition Products at the event. It turns out that the entire development has been done by the LSI networking team in Pune.

As with any technological advance, there is a dark side; a rogue installation could use DPI to exploit an application vulnerability and to mount attacks. DPI can become a tool for govt. bodies to spy on its citizens or for organizations such as RIAA or MPAA in their overzealous attempts to fight piracy. Rumor has it that the Chinese govt. is very interested in DPI. As such, DPI vendors will need to work together with application developers to provide fool proof security to users.

Device Performance

As Ethernet speeds move from 10G to 40G/100G, an inflection point in storage device performance has been reached. SSDs or Solid State Drives offer 1000x input/output operations per second or IOPs when compared to hard disk drives or HDDs. While performance is high, SSD overhead cannot be hidden in RAID stack as you can with HDD. SSD cost is also an issue, and as such HDDs currently rule when high-capacity storage is required, but that advantage should go away once SSD volumes improve. In the current scenario, a hybrid storage that uses SSD for cache and HDD for main storage is certainly something worth looking at. The area where HDDs are expected to have a major advantage is where a large number of small files need to be stored, but that is something that could be worked around by application providers.

Here’s a recent performance comparison of SSD vs HDD performed by Tom’s Hardware.

As internet traffic and data are expected to grow by leaps and bounds in the coming years, it could be just that the next rounds of datacenter evolution (4.0, 5.0, …) may just be round the corner.