MIT - 6.823 Computer System Architecture - Fall 2007 (Lecture Notes)

  • L-01: Computer System Architecture, pdf, ppt [09/05/07]
  • 1-Intro: Introduction to Pin, pdf [09/05/07]
  • L-02: Influence of Technology and Software on Instruction Sets: Up to the dawn of IBM 360, pdf, ppt [09/10/07]
  • L-03: Instruction Set Evolution in the Sixties: GPR, Stack, and Load-Store Architectures, pdf, ppt [09/12/07]
  • L-04: Hardwired, Non-pipelined ISA Implementation, pdf, ppt [09/17/07]
  • L-05: Instruction Pipelining and Hazards, pdf, ppt [09/19/07]
  • L-06: Microprogramming, pdf, ppt [09/26/07]
  • L-07: Cache Organization, pdf, ppt [10/01/07]
  • L-08: Memory Management: From Absolute Addresses to Demand Paging, pdf, ppt [10/03/07]
  • L-09: Modern Virtual Memory Systems, pdf, ppt [10/10/07]
  • L-10: Complex Pipelining, pdf, ppt [10/15/07]
  • L-11: Complex Pipelining: Out of Order Execution and Register Renaming, pdf, ppt [10/17/07]
  • L-12: Branch Prediction, pdf, ppt [10/22/07]
  • L-13: Speculative Execution, pdf, ppt [10/24/07]
  • L-14: Advanced Memory, pdf, ppt [10/29/07]
  • L-15: Multithreading, pdf, ppt [10/31/07]
  • L-16: VLIW/EPIC: Statically Scheduling ILP, pdf, ppt [11/05/07]
  • L-17: Vector Computers, pdf, ppt [11/07/07]
  • L-18: Virtual Machines and Dynamic Translation: Implementating ISA's in Software, pdf, ppt [11/14/07]
  • L-19: Reliable Architecture, pdf, ppt [11/19/07]
  • L-20: Symmetric Multiprocessors: Synchronization and Sequential Consistency, pdf, ppt [11/26/07]
Courtesy: MIT

MIT student projects - 6.884 Complex Digital Systems

  • Out-of-Order SMIPS Processor Using Tomasulo's Algorithm
    Cliff Frey and Vicky Liu
  • Memory Access Scheduler
    Matt Cohen and Alvin Lin
    • Cache-Coherent Memory System Using a Ring Network
      Albert Chiou and Mat Laibowitz
      • High-Performance SMIPS Processor
        Jonathan Eastep
        • Hardware Implementation of an 802.11a Transmitter
          Elizabeth Basha, Steve Gerding, and Rose Liu
          • The Pipe Dream: Out-of-Order SMIPS Processor using a Reorder Buffer
            Karthik Balakrishnan and Michal Karczmarek
            Courtesy: MIT
              • 2007 chip rankings, the Sliders and the Climbers

                Source EE Times

                Intel, Sony, Toshiba and Qualcomm are the stars -- or winners -- in iSuppli Corp.'s projected IC rankings for 2007. The losers: AMD, Freescale, among others. Advanced Micro Devices Inc. and Freescale Semiconductor Inc. are both projected to fall out of the top-10 rankings in terms of sales in 2007. (See charts below.)

                Intel Corp., whose chip revenue is expected to rise 7.7 percent to reach $33.97 billion in 2007, will remain the world's largest IC maker in 2007, according to the projected rankings. Samsung Electronics Co. Ltd. is projected to remain in second place in the rankings in terms of projectd IC sales for 2007, according to the research firm. Toshiba Corp. is expected to take third place, jumping over Texas Instruments Inc., who will be in fourth in the projected rankings for 2007, according to the firm. Rounding out the top-10, STMicroelectronics will be in fifth, followed by Hynix, Renesas, Sony, NXP and Infineon, according to the firm.

                Sony Corp. and Infineon Technologies AG made their way to the top-10. Sony was in 14th place in 2006, while Infineon was in 15th.

                Sony is still in limbo, however. Sony's revenue increase is nearly all due to its sales of chips for the company's PlayStation 3 video-game console, according to iSuppli. Company semiconductor revenue increased to $8 billion in 2007, up from $5.1 billion in 2006, they said. Sony has announced a deal to transfer production of its Cell microprocessor for the PlayStation 3 to Toshiba. If this deal closes before the end of the year, Sony's chip revenue in 2007 in this area will be transferred to Toshiba, based on iSuppli's methodology. Under these circumstances, Toshiba would increase its distance from TI's as the world's No. 3 semiconductor supplier, while Sony would drop out the Top-10 rankings, according to iSuppli.

                Meanwhile, Infineon is set to achieve a 14.6 percent increase in semiconductor revenue CY 2007, much of this increase is due to a rise in wireless communications semiconductor sales, they said.

                Another star, Qualcomm Inc., is expected to post the third largest increase in revenue among the top-20 semiconductor suppliers in 2007, rising by 23.7 percent to reach $5.6 billion, up from $4.5 billion in CY 2006. This will put Qualcomm into the market's 12th ranking in 2007, up from 16th in 2006. Qualcomm's increase is entirely due to a surge in sales of semiconductors for mobile handsets and infrastructure, the firm said.

                Going in the opposite direction, Freescale Semiconductor is set for a 10.7 percent decline in chip sales for 2007. This is primarily due to weakness at Freescale's largest customer, Motorola Inc., which has been losing market share to Nokia and Samsung in mobile handset sales in 2007, according to iSuppli.

                And at the same time, Intel outperformed its PC microprocessor rival, AMD, whose sales are expected to decline by 22.7 percent for the year. "Throughout most of the year, Intel successfully defended much of the market share that it won from AMD in the first quarter in the PC microprocessor segment due to the success of its lines of dual- and quad-core chips," said Dale Ford, vice president, market intelligence for iSuppli, in a statement.

                "This represents a major reversal of fortune compared to 2006, when AMD had the advantage with its popular dual-core microprocessors, allowing it to gain share from Intel," he said.

                Wireless HMD

                YelloMosquito delivers Qingbar Gp300: the wireless HMD
                Courtest - Engadget
                Although you may not be familiar with YelloMosquito, chances are you're totally aware of the business that 22Moo is in. Turns out, the former is simply a division of the latter, which is busy boasting about the Qingbar Gp300. 'Course, we've known that completely wireless head-mounted displays were in the works, but YM is claiming that these unsightly things are the world's first cordless LCOS video glasses to feature a built-in media player complete with DivX support. Reportedly, users can enjoy getting mocked while watching a 50-inch virtual screen, and they can load up their files via the built-in miniSD slot. If you just can't resist the urge to relive your Virtual Boy glory days, you can pre-order the December-bound unit now for $299 -- otherwise, you'll be laying down a Benjamin more (or smartly saving a mint) wh! en it ships en masse.

                [Image courtesy of YelloMosquito]

                Mentor Graphics, TSMC release 65-nm RF design kit

                Mentor Graphics Corp. (Wilsonville, Ore.) and Taiwan Semiconductor Manufacturing Co. Ltd. (Hsinchu, Taiwan) have announced the release of a 65-nm RF process design kit.

                ST opens office in Vietnam, say reports

                Identifying strong market potential in Vietnam, European chipmaker STMicroelectronics NV has opened a representative office in Hanoi, according to local newspapers <i>Viet Nam News</i> and <i>Thanh Nien Daily</i>.

                Stocks crumble on recession fears

                U.S. stocks retreated sharply on news corporate earnings sagged during the third quarter, dropping to its lowest level in years and sparking fears the economy could slide into a recession as corporations cut back on capital expenditure.

                Interview: Intel research trio discuss 45-nm high-k

                Three Intel researchers Robert Chau, Kaizad Mistry and Tahir Ghani, who were part of the team behind the 45nm high-k metal gate success, talk about the highs and lows of the project and what motivated them to press on and move on to more challenging endeavors.

                Interview Question - Intel, Folsom

                Your next co-op job is with the Independent Eagle-Eyed Elective, a consulting firm that performs code reviews for other companies. Your first task is to review the VHDL code for a new traffic-light controller that has been written by Valerie Hazelton and David Langsdorf.

                1. The traffic-light controller is designed for conventional intersections of two roads, with green, yellow, and red lights facing each of the four directions. There are no turn signals or blinking green lights.
                2. Valerie and David have checked that their code is legal and synthesizable.
                3. Val and Dave have not yet simulated or verified their code.
                4. Each of the four directions (North, South, East, and West) has a traffic light.
                5. The North and South facing lights are both controlled by the NS light output of the controller.
                6. The East and West facing lights are both controlled by the EW light output of the controller.
                7. Each of the four direction has a car sensor (e.g. N car) to detect when a car is waiting for the light to turn green.

                Identify three changes that VH and DL should make to their code that will have the largest impact in improving the controller (e.g. optimizations or bug fixes). For each change:

                1. Identify the lines of code or signals affected by the change
                2. Describe the change
                3. Justify the importance of the change in terms of its impact on the controller

                Disclaimer & Agreement

                BY READING "The Digital Electronics Blog", YOU AGREE TO BE BOUND BY ALL THE TERMS AND CONDITIONS.

                If you do not agree with the terms and conditions of this Agreement, you should leave the site immdiately. This Agreement may be modified from time to time. This Agreement supersedes any prior agreements. The current version applies to your use of the Services and the Site both now and in the past. If you continue to browse this blog it is understood that you have read this "Disclaimer & Agreement" in full and that have agreed to abide by it.

                1. Registration
                We don't require a registration process, but you are obligated to subscribe to the newsletter and updates from this blog through the subscription box on the main page. This implies your agreement to this "Disclaimer & Agreement". Your e-mail will be used to identify you on "The Digital Electronics Blog". By registering, you certify that the email address you provided in the registration is accurate and belongs to you.

                You are responsible for maintaining the confidentiality of your password and for any and all activities that occur under your Member Name and password. You agree to notify "The Digital Electronics Blog" immediately at admin@"The Digital Electronics Blog".com of any unauthorized use of your account or any other breach of security you learn about.

                To protect your privacy and the privacy of others, "The Digital Electronics Blog" uses Member Names to identify participants. We keep your email address and other information strictly confidential. You should refrain from using identifiers in choosing your Member Name and in your postings that would compromise your privacy, such as your email address, URLs, full name, street address, telephone or fax numbers, place of employment, etc.

                2. Privacy
                You are providing your electronic mail ("email") address for the purposes of registering to access this service. Correctly entering your email address is important so that you are able to participate in the collaboration process (e.g. you will receive email notifications when a problem/question you posted receives a comment or a proposed solution.)

                3. Guidelines for Use
                "The Digital Electronics Blog" Services and Site are only available for use by individuals who are age 13 or over. The Services and Site may not be used by scripts, machines or automated services.

                "The Digital Electronics Blog" Services and Site may be used only for lawful purposes. You must comply with all applicable local, state, national and international laws, regulations or conventions, including without limitation those related to data privacy, international communications, and exportation of technical or personal data. You may not use the "The Digital Electronics Blog" Services or Site for any criminal or illegal activities or any activities that might be legally actionable.

                "The Digital Electronics Blog" reserves the right to determine what constitutes Internet abuse and objectionable conduct. If "The Digital Electronics Blog" believes, at its sole discretion, that a violation of these Guidelines has occurred, it may take responsive action. Such action may include, but not be limited to, permanent removal of illegal or inappropriate information or content, or suspension or termination of your membership and access to "The Digital Electronics Blog" Services. Examples of objectionable conduct and content that violate these Guidelines include, but are not limited to, the following:

                1. Using a Member Name or posting, transmitting or linking to any text or images that are sexually explicit, pornographic, violent, racially or ethnically objectionable or grossly offensive to the online community posting, transmitting or linking to defamatory and libelous statements or other statements that would violate any third party's privacy or publicity rights.
                2. Posting, transmitting or linking to profane language, descriptions of situations or scenarios considered, in the opinion of "The Digital Electronics Blog", inappropriate for the "The Digital Electronics Blog" membership.
                3. Impersonating any person or using a name that you are not authorized to use.
                4. Planning illegal activities, such as creating computer viruses, building a bomb or counterfeiting money.
                5. Advertising, promoting in any way or offering to sell any goods or services for any commercial purpose.
                6. Soliciting individuals to join other services comparable to or competitive with "The Digital Electronics Blog".
                7. Promoting any products or services that are unlawful at the location at which the content is posted or received.
                8. Posting any content that infringes any third party's intellectual property rights or violates any confidentiality agreements or contracts of employment.
                9. Posting, transmitting or linking to statements that are intentionally false or misleading.
                10. Introducing viruses, worms, harmful codes or Trojan horses.
                11. Spamming, flaming or other similar activities.
                12. Violating the guidelines for academic honesty or other unethical behavior.
                13. Violations of system and network security are prohibited.

                4. Content License
                "The Digital Electronics Blog" enables Members to post problems or questions, proposed solutions or answers, information, comments and other content ("Your Content") to its Site. When you post Your Content to the Site, you understand and agree that Your Content can be viewed and used by other Members who visit the Site.

                You represent and warrant that you own or otherwise control all of the rights to Your Content and that use of Your Content by "The Digital Electronics Blog" and its affiliates will not infringe upon or violate the rights of any third party. Before you use "The Digital Electronics Blog" Services to post any information or content that is protected by intellectual property laws, you shall have acquired the legal right to do so from the owner or authorized licensee of such information or content.

                By registering with "The Digital Electronics Blog" and posting Your Content on the Site, you hereby grant "The Digital Electronics Blog" a non-exclusive, perpetual, irrevocable, unrestricted, transferable, fully sublicensable, worldwide, royalty-free license to use, distribute, display, reproduce, perform, modify, adapt, publish, translate and create derivative works from Your Content in any form, media or technology, whether now-known or hereafter developed. You also grant "The Digital Electronics Blog" and its affiliates and sublicensees the right to use the Member Name that you submit with Your Content for purposes of attribution. If you do not wish to have Your Content attributed to you, then you must notify "The Digital Electronics Blog" at admin@"The Digital Electronics Blog".com.

                Interview Question

                Some software programming languages allow compilers to perform "short cut" or "short circuit" optimizations on AND and OR operations. In a short-cut AND or OR, the second argument is not evaluated if the first argument evaluates to a controlling value. For example, in evaluating f(x) AND g(y), if f(x) is false, then g(y) will not be evaluted.

                Answer whether this optimization is feasible and beneficial in hardware.

                This optimization is neither feasible nor beneficial for hardware.
                Hardware executes in parallel (concurrently) and software executes sequentially (serially). In hardware, we already have the circuitry to evaluate both sides of an operand. It would require more circuitry and incur greater delay to control the evaluation of the second operand than to just use the result of the second operand.

                Extra notes:
                • f(x) and g(y) take multiple cycles to execute and each is executed on separate hardware, then we can execute both f(x) and g(y) at the same time and perform the short-cut optimization if the first operation to complete execution results in a controlling value.
                • If f(x) and g(y) take multiple clock cycles to execute and are executed on the same hardware, then the short-cut optimization is feasible and beneficial.
                Poor justification: Confusing “short-circuiting” as software jargon with short circuiting in the
                hardware world.

                Difficulty: Easy

                BSNL IPTV, Triple Play, Multi Play, India

                Message from BSNL Customer care..

                Hello Sir/Madam,
                I would like to add something more to about IPTV Service Blog. We are the Customer Care Center personnel of BSNL IPTV Services.
                I am Ravi, CSE.

                IPTV Triple Play is now "IPTV Multiplay".
                we are showing 60 TV channels for now & later expansion to 150+ channels, 14 Radio Stations and Video On Demand.

                More info -
       (Bangalore Telecom)

                Purchase Plan

                STB Cost = Rs. 3950/-
                Installation Charges = Rs. 600/-

                Rental Plan
                Refundable Security Deposit = Rs. 1500/-
                Installation Charges = Rs. 889/-
                Monthly Rent of STB = Rs. 100/-

                The monthly subscription charges of the service are Rs. 150/- + E.Tax Rs.45/- + S.T. 12.5%
                the total is Rs.213/- including all taxes.

                Discount scheme is running in this month of November (20% discount on the Telephone usage + 20% discount on Broadband usage on all plans, all applicable for life), 15 day free trail with absolutely no fee.

                For details feel free to contact us @ the below number.

                Contact # - 1 800 345 0111

                Thanks & Regards
                Ravi (CSE)

                Inverter madness - Interview Question

                • The following graph plots the voltage transfer characteristic for a device with one input and one output. Can this device be used as a combinational device in a logic family with 0.75V noise margins?

                • You are designing a new logic family and trying to decide on values of the four parameters VIL, VOL, VIH, VOH that lead to non-zero noise margins for various possible inverter designs. Four proposed inverter designs exhibit the voltage transfer characteristics shown in the diagrams below. For each design, either (1) specify suitable values of VIL, VOL, VIH, VOH. or (2) explain why no values for these parameters satisfy the static discipline.

                Difficulty: Medium

                Digital Abstraction - Interview Question

                1. The behavior of a 1-input, 1-output device is measured by hooking a voltage source to its input and measuring the voltage at the output for several different input voltages:
                  We're interested in whether this device can serve as a legal combinational device that obeys the static discipline. For this device, obeying the static discipline means that
                  if VIN <= VIL then VOUT >= VOH, and
                  if VIN >= VIH then VOUT <=
                  • Can one chose a VOL of 0V for this device? Explain.
                  • What's the smallest VOL one can choose and still have the device obey the static discipline? Explain.
                  • Assuming that we want to have 0.5V noise margins for both "0" and "1" values, what are appropriate voltage levels for VOL, VIL, VIH, and VOH so that the device obeys the static discipline. Hint: there are many possible choices, just choose one that obeys the constraints listed above.
                  • Assuming that we want to have 0.5V noise margins for both "0" and "1" values, what is the largest possible voltage level for VOL that still results in a device that obeys the static discipline?
                  • Assuming that we want to have equal noise margins for both "0" and "1" values, what is the largest noise margin we can achieve with this device and still obey the static discipline?
                Difficulty: Medium

                VHDL Interview Question(s)

                1. What are the two key concepts in the simulation semantics of VHDL and how does each concept help VHDL simulation produce waveforms that match the behaviour that we expect?
                2. What is the advantage of RTL simulation in comparison to simulation as defined by the VHDL standard?
                3. What is the disadvantage of RTL simulation in comparison to simulation as defined by the VHDL standard?
                4. For each of the architectures muruku 1. . . muruku 4, answer the following questions.
                  • INSTRUCTIONS:
                    1. Is the code legal VHDL?
                    2. If the code is legal VHDL:
                      • Answer whether the behaviour of the signal z has the same behaviour as in the main architecture of sumit.
                      • Answer whether the code is synthesizable.
                      • If the code is synthesizable, answer whether it adheres to good coding practices.
                If the the code is not legal, not synthesizable, or does not follow good coding practices, explain why.

                entity sumit is
                port (
                a, b, clk : in std_logic;
                z : out std_logic
                end sumit;

                architecture main of sumit is
                signal m : std_logic;
                process ( clk )
                if rising_edge( clk ) then
                m <= a or b; end if; end process; process ( clk ) begin if rising_edge( clk ) then z <= not m; end if; end process; end main;
                1. Muruku 1
                  • architecture muruku_1 of sumit is
                    signal m : std_logic;
                    process ( clk )
                    if rising_edge( clk ) then
                    m <= a or b; z <= not m; end if; end process; end muruku_1;
                2. Muruku_X
                  • architecture muruku_X of sumit is
                    signal m, p : std_logic;
                    process ( clk )
                    if rising_edge( clk ) then
                    m <= a or b; end if; end process; process ( clk ) begin if rising_edge( clk ) then z <= p; end if; end process; p <= not m; end muruku_X;
                3. Muruku_2
                  • architecture muruku_2 of sumit is
                    signal m, p : std_logic;
                    if (a or b) = ’1’ generate
                    m <= ’1’; end generate; if (a or b) = ’0’ generate m <= ’0’; end generate; process ( clk ) begin if rising_edge( clk ) then p <= m; end if; end process; process ( clk ) begin if rising_edge( clk ) then z <= not p; end if; end process; end muruku_2;
                4. Muruku_3
                  • architecture muruku_3 of sumit is
                    wait until rising_edge(clk);
                    wait until rising_edge(clk);
                    z <= not (a or b); end process; end muruku_3;
                5. Muruku_4
                  • architecture muruku_4 of sumit is
                    signal m, p : std_logic;
                    process ( clk )
                    if rising_edge( clk ) then
                    m <= a or b; end if; end process; process ( clk ) begin if rising_edge( clk ) then p <= m; end if; end process; z <= not p; end muruku_4;
                Difficulty: Medium

                Functional verification and 'e'

                The e language enjoys popular use in the ASIC/VLSI industry for creating spec's, modeling, testing and verification of hardware systems.

                Features of e include a combination of object oriented and constraint oriented mechanisms for the specification of data formats and interdependencies, interesting mechanisms of inheritance, and an efficient combination of interpreted and compiled code. Since the language is also extensible it serves as a living, industrial scale, implementation and application of the aspect oriented programming paradigm.

                During the course of the following tryst with the e language we will cover the language highlights, its novel features and their particular suitability to the task of hardware verification, and reports on our experience of aspect oriented programming in this intense commercial setting. Objects have been a great success at facilitating the separation of concerns, but objects are limited in their ability to modularize systemic concerns that are not localized to a single module's boundaries. Rather than staying well, localized within a class, these concerns tend to crosscut the system's class and module structure. Much of the complexity and brittleness in existing systems appears to stem from the way in which the implementation of these kinds of concerns comes to be intertwined throughout the code.

                We observed that while object oriented techniques have given the programmer excellent data abstraction mechanisms, objects themselves are cumbersome when it comes to expressing aspects of behavior that affect several data types. Conversely, OOP fails in naturally facilitating non-invasive extension mechanisms for layering new functionality over existing code.
                • A typical verification problem: A functional verification program consists of a more or less detailed description of the functionality of a device, its operating environment, and the data transformations it performs. In general terms functional verification is predicated on the assumption that a detailed simulation model of a device has been implemented in a suitable hardware description language. Such descriptions are simulated in software or emulated in configurable hardware for the purpose of determining the precise timing properties of the design, as well as to judge its functional correctness. Given such an implementation of the device under test (DUT) a suitable testbench needs to be erected around the DUT in order to subject it to a large number of tests.
                  • Instructions: A key element in any verification environment is an adequate description of the data being manipulated—CPU instructions, in this case. Such descriptions typically do form natural classes of structured data—thus CPU instructions will be defined by some common elements such as opcode and addressing mode, but differences emerge (say) in the operands present causing a classification into immediate (e.g., the second operand, op2, is a two byte integer constant), memory (op2 is a two byte memory address), and register instructions (op2 is a four bit register index).
                  • Test Generator: This software ultimately creates a sequence of test vectors (of bits) to stimulate the DUT whether on-the-fly, or as a prelude to running a test. Setting aside the question of how to (randomly) generate instances of the data classes involved, the test generator needs to determine what are legal inputs, and what are not. To some extent a strong type system helps define legal ranges—it is easy then to generate a random four bit value for op2 in the register class. However via types it is difficult to stipulate, for example, that since register zero never holds a branch address an indexed branch instruction cannot have op2 equal to zero. Constraints, in the form of Boolean relationships over the fields of class definitions, contribute the necessary flexibility, relieving the programmer (or test writer) of much unnecessary programming.
                  • Reference model: Commonly, but not necessarily, a reference model will be used to predict correct responses from the DUT for each datum input during a test. Typically functional verification works at the level of whole transactions rather than clock cycles of the DUT—in this case a transaction is initiated by injecting an instruction into the running simulation, and terminated some time later by observing a result on one of the device’s output channels. Reference models thus do not need to be cycle accurate specifications of the hardware, just functionally accurate.
                  • Checker: The testbench must obviously check the expected results of the test against the actual computation. In CPU verifications there are typically two types of checker: a data checker that ensures that all instructions computed the correct results, and a temporal checker that monitors how each instruction is executed by the DUT. This latter activity calls for the definition of behavioral rules (e.g., via executable temporal logic, or finite automata) that are run concurrently with the DUT, monitoring its state and progress.
                  • Coverage: Metrics that help the verification engineer decide how well the verification is progressing have to be carefully designed with reference to a test plan. For instance it may be required to test that the CPU responded correctly to an interrupt when a branch instruction was being decoded. The ‘responds correctly’ may be a temporal rule invoked under such circumstances, but the fact that this scenario occurred during testing would be entered as a functional coverage point. In a simple case one might be content to count how many times this combination of circumstances occurred.
                    Given a functional verification environment such as that envisaged above, tests will be devised to exercise the design. Sometimes these need to be very deterministic (e.g., in the early phases of the verification effort when one is testing basic functionality), but better coverage of the state space is achieved through random testing, especially when the ‘randomness’ can be directed towards particular goals. Often such goals are expressed as corner cases, particularly where functions of the device interact with one another. Principally it is for this purpose that the e language has been developed: random, directed test generation.
                  • Factors influencing e's design: Since its initial conception in the early nineties the e language has evolved to meet the needs of functional verification engineers. e is used to describe the DUT, its operating environment, its legal inputs, and its behavior over time. Specman, Verisity’s flagship product implementing the language and runtime system, takes such a description and uses it to generate test inputs and drive them into the DUT, carry out temporal and data checking by monitoring the device, create coverage reports, and assist in debugging. Even though e is a general-purpose programming language (in fact most of Specman is written in e) its design has been geared towards the task of modeling and verifying hardware systems. This specific task imposed a number of important characteristics on the language.
                    • Specialized Lingual Constructs: These include constraints, for example, which provide an effective declarative mechanism for the specification of configurations and for guiding test generation, and temporal properties (also declarative) which are used to describe time based phenomena. Inevitably there are many hardware oriented primitive types and operators on them such as bit-access and bit-slicing (common HDL functions), as well as mechanisms for specifying parallel execution.
                    • Simplified textual syntax:The rich toolset that e provides to its user must be served in an easy to use, non-cryptic syntax. The design of the syntax and the semantics were also influenced by the reality that the principal users of the language are not software specialists but mainly hardware engineers who, in particular, may not be schooled in object oriented languages.
                    • Performance: The verification of hardware systems by means of simulation is, almost by definition, a slow process. Every hardware cycle in which many operations may take place in parallel is translated to a sequence of slow software steps. In addition, the quality of a verification process is highly dependent on its coverage level. Even a non-exhaustive verification process may execute for months on dedicated powerful servers. This is the reason why e has a very efficient implementation; typically, an instruction (such as field access or function call) in e is implemented in a similar manner to the equivalent instruction in C.
                    • Compiled and interpreted code: For reasons that are discussed in subsequent Sections below, there is a need when building testbenches to be able to load files which add new features, constructs, and especially constraints,
                      on top of an extant code base. There is also a need for mixing those independently constructed additions in an unrestricted way.
                      On the face of it e is a lexically scoped, statically type checked object-oriented language with single inheritance. A struct in e, just like a class in other programming languages, may declare fields and methods. Structs may also contain several unique declarative components, including constraints (affecting initial values assigned to fields), event definitions (for monitoring DUT behaviour), and temporal properties (checking protocols, etc.). The temporal and concurrent features of e are not discussed further here.
                      A simple example, drawn from a verification environment for a packet switching device, demonstrates how constraints are used in e.
                      type packet kind: [empty,short,long];
                      struct packet {
                      i: int;
                      j: int;
                      kind: packet kind;
                      keep i < j + 1;
                      keep j in [1..5];
                      The first of these two statements declares an enumerated type, the second declares a structured object with several scalar fields. The keeps are constraints that affect initial values assigned to the fields mentioned whenever an instance of this class is created—Specman resolves such constraints during a test run in order to generate a random, directed stream of data for the DUT. Constraints in e are linear functions over finite domains.
                      While the synthesis of constraint solving and object oriented programming in e is an interesting subject in itself, it is not explored further in this article which rather focuses on the language constructs that address separation of concerns. Thus, in addition to the simple inheritance mechanism (which is called like inheritance in e), the language provides a unique and powerful when inheritance mechanism. Moreover, any e struct can be extended in a later module: fields, methods, events, and constraints can be added to it, and method definitions can be modified or overridden. Interpreted files can be loaded on top of a compiled executable, possibly extending already-compiled structs. The extension capabilities are discussed in Sections below, the when inheritance mechanism is also deferred until subsequent Sections.
                  • The aspect-oriented features of e
                    • Motivation:
                    • Orthogonal extensions
                    • Other uses of extension
                      • Ease of debugging/analysis
                      • Design exploration
                      • Replacing callback registrations
                    • Extending in-place
                  • Extending extend
                    • No pre-processor
                    • The need for environmental acquisition
                    • Using when inheritance
                  • Conclusion
                Contributed by Deepak

                To be completed..

                Intel's Power-Efficient Penryn Processors

                Over the weekend Intel launched its long-awaited new 'Penryn' line of power-efficient microprocessors, designed to deliver better graphics and application performance as well as virtualization capabilities. The processors are the first to use high-k metal-gate transistors, which makes them faster and less leaky compared with earlier processors that have silicon gates. The processor is lead free and by next year Intel is planning to produce chips that are halogen free, making them more environmentally friendly. Penryn processors jump to higher clock rates and feature cache and design improvements that boost the processors' performance compared with earlier 65-nm processors, which should attract the interest of business workstation users and gamers looking for improved system and media performance.

                Funny twist with compression and performance - Interview Question

                The organization Scholastic Lecture Expert Productivity Testers (SLEPT), has defined a standardized algorithm to compress digital-video lectures by removing irrelevant material. The company you work for, Yawn Inc, is developing a circuit that implements this compression algorithm. A competing company, Snore Co, has just released their own circuit that also implements the standardized algorithm.

                SLEPT has established a benchmark of five lectures to use for comparing circuits that implement the compression algorithm.
                The CEO of your company, Dr. Owsy has asked you to calculate the price at which you should sell the Yawn circuit such that you can advertise to consumers that the price/performance ratio for the Yawn circuit is 10% better than the Snore circuit.

                You evaluate a Yawn circuit and a Snore circuit in your lab, and gather the following data. Unfortunately, you fall asleep on the backspace button, deleting the information for the length of lectures after compression for the Yawn circuit.

                Collect the below data...

                1. Define “performance” for circuits that run the SLEPT compression algorithm. Briefly justify your definition.
                2. Assuming that the selling price of Snore Co’s circuit is $150, compute the selling price for the Yawn circuit that would make its price/performance ratio 10% better than the Snore circuit. If you do not have enough information to calculate the selling price: explain how you could obtain the missing information and show your equation that uses the missing information to calculate the selling price.
                1. Performance is work/time. The work that the circuit does is to compress lecures. The SLEPT algorithm is standardized. All circuits that implement the algorithm will produce the same results (e.g. same amount of compression). Hence, all circuits do the same amount of work.The time taken to do the work is the “Execution time for circuit”. Because we have a benchmark, the execution time to compare is the time to run the benchmark, that is, compress the five lectures in the benchmark.

                A better price/performance ratio means that the price is lower or the performance is greater: the lower the ratio the better the ratio.

                Starting with the formula for “a is n% more than b”: we get the following


                The Good, the Bad, and the Unsynthesizable - Interview Questions

                1. For each of the code fragments, answer whether the code is legal VHDL.
                2. If the code is legal VHDL, answer whether it is synthesizable.
                3. If the code is synthesizable:
                  • answer whether it represents good coding practices.
                  • answer whether the signal w or y is combinational, a latch, or a flip-flop.
                  • If the the code is not legal, is not synthesizable, or does not follow good coding practices, explain why.
                4. The signals are declared as follows:
                  • a, b, c, d, w : std logic
                  • m, y : unsigned(15 downto 0)

                process (a, b) begin
                if a = '1' then
                w <= b;
                end if;
                end process;

                process (a, c) begin
                if a = '0' then
                w <= c;
                end if;
                end process;

                unsynth: single assignment rule — can't have multiple processes driving the same signal

                process begin
                wait until rising_edge(a);
                w <= not w;
                end process;

                good: w=flop // or bad coding style, because state machine without reset

                b <= a;
                if b = '1' generate
                w <= c;
                end generate;
                if b = '0' generate
                w <= d;
                end generate;


                illegal: dynamic test in generate

                process begin
                w <= '0';
                wait until (a = '0');
                p: loop
                wait until rising_edge(b);
                next p when (a = '1');
                w <= c xor d;
                end loop;
                end process;


                unsynth: different wait conditions

                process (m) begin
                for i in 15 downto 0 loop
                if 3 >= i then
                y(i) <= '0';
                y(i) <= m(i-3);
                end if;
                end loop;
                end process;


                good: y = comb

                process begin
                wait until rising_edge(a);
                if b = '1' then
                wait until rising_edge(a);
                w <= b;
                w <= c;
                end if;
                end process;


                good: w=flop


                Texas Instruments, Bangalore - Interview Questions - Freshers

                For the following question, you only need to give the relevant VHDL code fragment (i.e. process that drives the flop). You may assume that any signals you need or want to use are defined appropriately. Use obvious labels like d, q, cs select, reset, etc.
                1. Give a VHDL code fragment to implement a standard D flip-flop.
                2. Give a VHDL code fragment to implement a flip-flop with a multiplexer on its input (assume two inputs: a and b).
                3. Give a VHDL code fragment to implement a flip-flop with a chip select line and an asynchronous reset.
                Sol 1:
                if rising_edge(clk) then
                q <= d;
                end if;
                end process;

                Sol 2:
                if rising_edge(clk) then
                if (sel = '1')
                q <= a;
                q <= b;
                end if;
                end if;
                end process;

                Sol 3:
                process(clk, reset)
                if (reset = '1') then
                q <= '0';
                elsif rising_edge(clk) then
                if (cs_select = '1') then
                q <= d;
                end if;
                end if;
                end process;

                Difficulty: Easy

                Wishing you a happy Deepavali

                We @ The Digital Electronics Blog wish our readers
                "A Very Happy Deepavali"

                Interview Question - Bangalore

                Assume a clock-gating scheme for turning off the clock in certain situations:
                • 60% of the time, the main circuit has valid data
                • the clock gating circuitry is 80% effective
                • the clock gating circuitry has a capacitance equal to 15% of the main circuit
                • the clock gating circuitry has an activity factor equal to 1.1 times that of the main circuit.
                How much power will be saved (as a percentage of the original power) by this clock gating scheme?

                Solution: 15.5%
                Want a full solution?

                Difficulty: Medium

                Qualcomm Interview Questions - Bangalore

                1. The average performance of products in your market segment triples every 36 months. Your design engineers have proposed an optimization that will increase performance by 12%. The optimization will postpone the completion date of the project by 2 months. Should the engineers implement the optimization and postpone the completion date, or should they stick to the original schedule?
                2. Your group designs a microprocessor for use in cell phones and palmtop computers. You currently fabricate your chips on a 0.25micron process. A new fabrication facility with a 0.13micron process has asked you if you would like to switch to their facility. What do you believe will be the three most important tradeoffs between remaining with the 0.25 micron fabrication process and switching to the 0.13 micron process?
                3. Explain derating factor
                Possible solutions:

                1. The average performance in the market segment will increase by 6.3%. Design engineers will increase performance by 12%, which is more than the competition will increase in performance. So, the engineers should complete the optimization and postpone the completion date.
                2. The three points
                  • smaller feature size will likely increase leakage power
                  • smaller feature size will decrease area, thereby decreasing cost
                  • new facility may have manufacturing problems
                3. Derating factors give factors for predicting the maximum clock speed of a circuit as supply voltage, temperature, and other environmental factors change. In the formula below, F is the maximum clock speed and V is the supply voltage. As the supply voltage increases, the maximum clock speed also increases.
                F = ( V - Vt) ^2/V

                Difficulty: Medium

                Broadcom Bangalore - Interview Questions

                1. The new vice president of your company has set up a contest for ideas to reduce leakage power in the next generation of chips that the company fabricates. The prize for the person who submits the suggestion that makes the best tradeoff between leakage power and other design goals is to have a door installed on their cube. What is your door-winning idea, and what tradeoffs will your idea require in order to achieve the reduction in leakage power?
                2. You're on the functional validation team for a chip that will control a simple portable CD-player. Your task is to create a plan for the functional validation for the signals in the entity cd digital. You've been told that the player behaves "just like all of the other CD players out there". If your test plan requires knowledge about any potential non-standard features or behaviour, you'll need to document your assumptions.
                  • Display Show following: 2 digit Track #, 2 digit Minutes & 2 digit Seconds
                  • Buttons Available: Prev, Stop, Play&Pause, Next, Pwr

                  • entity cd_digital is
                    port (
                    -- buttons
                    pwr : in std_logic;
                    -- detect if player door is open
                    open : in std_logic;
                    -- output display information
                    track : out std_logic_vector(3 downto 0);
                    min : out unsigned(6 downto 0);
                    sec : out unsigned(5 downto 0)
                    end cd_digital;
                  1. Describe five tests that you would run as soon as the VHDL code is simulatable. For each test: describe what your specification, stimulus, and check. Summarize the why your collection of tests should be the first tests that are run.
                  2. Describe five corner-cases or boundary conditions, and explain the role of corner cases and boundary conditions in functional validation.

                Possible Solutions in order:
                1. Increase transistor size so as to increase threshold voltage. This will require an increase in supply voltage, which will likely increase total power.
                  • Alternative: When increasing transistor size, keep the supply voltage the same, but decrease performance.
                  • Alternative: Change fabrication process and materials to reduce leakage current. This will likely be expensive.
                  • Alternative: Use dual-Vt fabrication process.
                2. There can be many possible solutions but the best ones are what the interviewer is looking for.
                  • The possible Tests:
                    1. Test 1:
                      • Specification: when power is turned on, the display will show the number of tracks on the CD, and the minutes and seconds will show the total length of the CD
                      • Stimulus: power='0'; wait; power='1', all other signals are '0'.
                      • check: display outputs of circuit match specification
                    2. Test 2:
                      • Specification: when power is on, play starts CD playing, display for track=1, min and sec show remaining time for song and start decrementing.
                      • Stimulus: power='1'; play='0'; wait; play='1', all other signals are '0'.
                      • Check: display outputs of circuit match specification
                    3. Test 3:
                      • Specification: when power is on and CD is playing, next starts next song. Display for track increments, min and sec show remaining time for next song and start decrementing.
                      • Stimulus: power='1'; play='0'; next='0'; wait; play='1'; wait; next='1', all other signals are '0'.
                      • Check: display outputs of circuit match specification
                    4. Test 4:
                      • Specification: when power is on and CD is playing, prev starts previous song. Display for track decrements, min and sec show remaining time for previous song and start decrementing.
                      • Stimulus: power='1'; play='0'; prev='0'; wait; play='1'; wait; prev='1', all other signals are '0'.
                      • Check: display outputs of circuit match specification
                    5. Test 5:
                      • Specification: when power is on and CD is playing, stop causes CD to stop.
                      • Stimulus: power='1'; play='0'; stop='0'; wait; play='1'; wait; stop='1', all other signals are '0'.
                      • Check: display outputs of circuit match specification
                Now one last hurdle! Can you justify all the solutions above?

                Difficulty: Medium