The Digital Electronics Blog at Design Automation Conference (DAC)



The Design Automation Conference (DAC) website has listed this Blog in the Industry Blogs Section on the home page. This is the first time since this blogs inception in 2004 that a major event had noticed us and has recommended us in the elite list. We at The Digital Electronics Blog thank all the readers and subscribers for making us so popular on the web for digital electronics and semiconductor resources.

Others who are part of this elite list!
  • Adventures in ASIC
  • ASIC-SoC-VLSI Design
  • Between the Lines
  • Cool Verification
  • Deep Chip
  • Digital Electronics Blog
  • EDA Blog
  • EDA DesignLine
  • EDA Confidential
  • Eric's Blog for Work
  • Gabe on EDA
  • John's Semi-Blog
  • On The Verge
  • PLD DesignLine
  • Practical Chip Design
  • Sandbox

Good Technology Business Blogs


Sramana Mitra's Take on Technology Business Blogs...
  • TechCrunch: TechCrunch reports on new technology companies in the web space.
  • Ars Technica: Ars Technica is focused on the "art of technology".
  • Lifehacker: Life Hacker provides tech tricks, tips and downloads, and a lot about making computers and the internet useful in everyday life.
  • Oreilly Radar: Tim O'Reilly and other leading technocrats follow developments in the various technological arenas and provide analysis, trends and predictions for the future.
  • GigaOM: GigaOM covers a wide range of topics from broadband and online games to Web 2.0. The authors provide in-depth reports, editorial articles, opinion polls, and market metrics about interesting startups, trends, products, and people in technology.
  • VentureBeat: VentureBeat provides you with news and information about private companies and the venture capital that fuels them. Writers mainly focus on the Silicon Valley and provide you with insider news and data about the entrepreneurial and venture community that is useful to decision makers.
  • Scobleizer: Robert Scoble best known for his popular blog, writes about the technology industry and especially Silicon Valley's Web, consumer electronics, computer, and other high tech companies.
  • PaidContent.org: PaidContent is focused on the future of the digital content business.
  • NewTeeVee: The GigaOM network has introduced NewTeeVee which focuses on the online video industry's latest topics.
  • Silicon Valley Watcher: Tom Foremski writes about business and culture of Silicon Valley. Tom keeps a close eye on telephony products, Internet based products and other related technologies and presents his views, opinions, and analysis on the latest development in the technology world.
  • Good Morning Silicon Valley: John Murrell writes about technology. He provides you with news of the day, reports, in-depth analysis and excellent commentary about the tech world.

The Future of High Performance Memory!


Rambus logo

Rambus India Design Seminars

The Future of High Performance Memory Designs

21 February 2008 | The Leela Palace Kempinski Bangalore | Bangalore, India

In this seminar, we will explore the types of memory systems required for next generation consumer applications and discuss how these advanced memory systems will solve tomorrow's system challenges. We will discuss innovative techniques developed by Rambus to improve memory performance and reduce overall system costs, as well as analyze solutions to multi-GHz memory designs. Finally, we will unveil the newest development from Rambus, the Terabyte Bandwidth Initiative, which enables 1 TB/s of memory bandwidth performance into a single SoC.

There is no cost for this seminar, but you must register to attend. Sign up early, as space is limited.

Who should attend?
Anyone who designs or manufactures digital consumer electronic systems or memory subsystems, including:
System Designers
System Manufacturing Engineers
Chip Architects
Technical Managers
Product Marketing

Agenda
9:30 – 10:00
Registration
10:00 – 10:05
Introduction
10:05 – 11:00
Evolution of Memory
11:00 – 12:15
XDR™/XDR2 and Memory Requirements for Next Generation Consumer Products
12:15 – 13:30
Lunch and Product Demonstrations
12:30 – 14:15
Solving System Engineering Challenges in High Speed Memory Designs
14:15 – 15:00
DDR2/DDR3 Bimodal Controller Design
15:00 – 15:15
Break
15:15 – 16:00
Terabyte Bandwidth Initiative
Demonstrations and Q&A
Technical experts from Rambus will conduct demonstrations and answer questions at the end of the main session. Lunch will be provided to all attendees, and Rambus experts will be available during the lunch hour to answer questions.



This message was sent by Electronic Engineering Times eeMail broadcast service on behalf of Rambus.

For further assistance or more information about our full range of sourcing products and services, please contact us at Customer Services, 1 Sims Lane #08-01, Singapore 387355; phone: (65) 6547-2800; fax: (65) 6547-2888; e-mail: service@globalsources.com

DesignCon 2008



Your Design Connection Awaits!

DesignCon attracts engineering professionals from various levels and disciplines and represents many aspects of electronic design: applications engineering, architecture and systems design, ASIC design, circuit-board design, embedded-systems design, hardware/software integration, high-performance systems, IC design, packaging, semiconductor product management, service and support, SoC design, software development, testing and debugging, and more.

Professionals who need to stay on top of current information and developments regarding design-engineering theories, techniques, and applications strategies will benefit from attending DesignCon's conference and exhibition.

Individuals presenting papers at DesignCon will join an elite group offering leading-edge case studies, technology innovations, practical techniques, design tips, and application overviews.

DesignCon 2008 Topic Categories

  • Chip-Level Architectural and Functional Design
  • Functional and Performance Verification
  • Chip-Level Physical Design and DFM
  • Chip-Level Electrical and Package Design
  • PCB and Passive Component Technology
  • High-Speed Parallel Interface Design
  • Multi-Gigabit Serial Interconnects
  • High-Speed Timing, Jitter, and Noise
  • High-Speed Signal Processing, Equalization, and Coding
  • Power Integrity and Power-Aware Design
  • Electromagnetic Compatibility and Interference
  • Test Fixturing and Measurement Methodology
  • RF and Signal Integrity
  • Chip/Package/Board/System Co-Design
  • Business and Engineering Impacts

TAU 2008


ACM/IEEE International Workshop on Timing Issues in the Specification and Synthesis of Digital Systems (TAU Workshop) will be held at The Portola Plaza Hotel at Monterey Bay in Monterey, California on February 25-26, 2008. The workshop is co-sponsored by IEEE/CAS and ACM/SIGDA.

The TAU series of workshops provide an informal forum for practitioners and researchers working on temporal aspects of digital systems to disseminate early work and engage in a free discussion of ideas.

The fifteenth in the TAU series, the TAU 2008 workshop invites submissions from all areas related to the timing properties of digital electronic systems, including but not limited to:

Formal theories and methods
System-level timing
Transistor-level timing
Circuit-level timing
Sensitivity analysis
Full custom design analysis
Integrated functional-temporal analysis
Incremental analysis
Timing issues in low power design
Power-delay trade-offs
Adjacent line switching and coupling
Delay models and metrics
Layout impact on timing
Timing-driven layout optimization
Timing-driven synthesis and re-synthesis
Circuit optimization
Uncertainty-based analysis
Incorporation of RETs in timing
Reliability impact on performance
Process & environmental variation models
Statistical analysis technique
Clocking, synchronization, and skew
Clock domains, static/dynamic logic
Novel clocking schemes
Special circuit families
Asynchronous systems

ACM/EDAC/IEEE Design Automation Conference 2008


The Design Automation Conference (DAC) is the premier event for the design of electronic circuits and systems, and for EDA and silicon solutions. DAC features a wide array of technical presentations plus over 250 of the leading electronics design suppliers.

OVM Available Now!!


The OVM is now available for download from the new OVM website.

The OVM is based on the IEEE 1800 SystemVerilog standard and supports design and verification engineers developing advanced verification environments that offer higher levels of integration and portability of Verification IP. The methodology is non-vendor specific and is interoperable with multiple languages and simulators. The OVM is fully open, and includes a robust class library and source code that is available for download.

HDL Coding Guidelines - Part 7


Hints
  1. Avoid more package references than needed
  2. Keep all objects and subprograms in the nearest possible scope
  3. Keep local objects invisible outside a package
  4. Transfer stable component declarations into components packages
  5. Re-use functionality of standard packages as much as possible
  6. Size of VHDL Units should be reasonable for synthesis
  7. A VHDL unit should not exceed 500 lines of code
  8. A process or subprogram should not exceed 100 lines of code
  9. Component instantiations should not exceed 4 levels of hierarchy
  10. An architecture should not contain more than 10 processes
  11. Structural and behavioral code should not be mixed
  12. Define project packages early in the project
  13. Hide old VHDL files
  14. Follow Naming conventions for VHDL units
  15. Follow Naming conventions for VHDL files
  16. Follow Naming conventions for VHDL objects
  17. Choose short instance names
  18. Keyword casing should be uniform in all VHDL code
  19. Use an intermediate signal for reading from an output port
  20. Self-defined conversion functions must assert un-mappable input values
  21. Use complex data types inside architectures
  22. Use a small number of self-defined global data types
  23. Insert test-enable for scan-test
  24. Use vector operations instead of loops
  25. Avoid unnecessary repetition of function calls
  26. Use efficient description for the wrap around of counters
  27. Build interface consistency checks into the model
  28. For soft-core development use generics, do not use constants
  29. A testbench has neither ports nor generics
  30. Variables of access types should be modified only in procedures defined in packages
  31. Use abstract, compact coding style in testbench and simulation models
  32. In case of accelerated simulation or emulation, the testbench must be synthesizable
  33. Stop the simulation from within the testbench
  34. Use assertion messages extensively
  35. Check the success of a read operation
  36. Use std.textio only, where really necessary
  37. Store file data to a VHDL variable, if read multiple times
  38. In association lists of subprogram calls use named association
  39. Indentation should be consistent in all VHDL code
  40. Align comments vertically
  41. Align declaration lists vertically
  42. Align association lists vertically
  43. Use closing labels for entity, architecture, process, loop, generate, etc.
  44. Indicate condition at remote ends of control structures (if ... then, case)
  45. Use one statement per line
  46. Group related constructs
  47. Group related port or signal declarations
  48. Switch constructs should not be nested to more than 4 levels
  49. Remove unnecessary code fragments
  50. Order of items should be the same in package header and body
  51. Use predefined attributes to make code generic and more re-usable
  52. Do not have code that have been commented out in checked-in versions
  53. Carefully use real values with PN-generators
  54. Be aware of operating-system-specific features
  55. Take care of array widths for std_logic_arith operators
  56. Use conversion functions around arithmetic operators
  57. Requirements for resource sharing
  58. EMC and transmission line effects need not be modeled
  59. Minimize the number of processes, signals, and signal assignments
  60. Replace signals by variables whenever possible
  61. Inhibit execution of statements where not necessary
  62. Divide large memories into blocks
  63. Avoid declaring constants within subprograms
  64. Always use deallocate(access_obj) to dereference allocated memory
  65. Use only well tested functions for object-initialization purposes
  66. Be aware of the use of the attributes DELAYED, STABLE, QUIET, and TRANSACTION

HDL Coding Guidelines - Part 6


To Avoid common Warnings
  1. Store each VHDL unit into a separate file except package header and body
  2. Signal assignments for renaming purposes should be avoided
  3. The names of clocks and resets should be unique in the whole design
  4. Soft macros: Data types at ports: std_(u)logic(_vector)
  5. Avoid custom data types (e.g., multidimensional arrays, records, enumeration types)
  6. Avoid gated clocks unless absolutely necessary
  7. Avoid latches unless absolutely necessary
  8. All outputs of synchronous modules should be registered
  9. Process only one clock in RTL-units
  10. Do not use the value of type’left for initializing of a signal or variable during reset
  11. Avoid unused ports, busses must be split accordingly
  12. Avoid homographs
  13. Do not define a subprogram for a subtype only
  14. Comment each process, each subprogram and global aspects
  15. Processes should be labeled
  16. Aliases are not recommended
  17. Bussed ports of width one are forbidden
  18. Use case-statements instead of if-statements when the conditions are mutually exclusive
  19. All signals and variables should be read at least once
  20. Static ports should not exist
  21. Use a separate library clause for each declared resource library
  22. Use a separate use clause for each declared package
  23. Maximum line-length is 100 characters
  24. Order of ports in entity, component and instance should be the same
  25. Do not have unused signals
  26. Minimize the number of signals of your sensitivity list
  27. Avoid unnecessary computations within loops
  28. Use sensitivity lists instead of wait statements
  29. Subprograms may not have any side effects

HDL Coding Guidelines - Part 5


Critical Policies to Keep note!
  1. Balance clock to delta accuracy
  2. Pull-ups and pull-downs have to be modeled on chip level
  3. Communication between modules using text-IO is forbidden
  4. No characters with a lower rank than space may occur in text-IO
  5. Testbench and DUT should be compiled into the same library
  6. Asynchronous parts should be placed into separate entities
  7. VHDL units should take into account later floorplanning
  8. A FSM must be described in a separate entity/architecture pair
  9. Only verified VHDL code allowed for check-in
  10. Identifier naming must be based on English language
  11. Use meaningful identifier names
  12. Separate identifier components using underscores
  13. Instantiate the power pads for each power domain
  14. Gate instantiation must be encapsulated by separate unit
  15. Spend extensive efforts for documentation of interfaces
  16. Request external VHDL code suppliers to deliver used arithmetic packages
  17. Spacer cells needed between pads
  18. Signals that cross clock domains must be synchronized by synchronization cells
  19. Language for comments and code documentation is English
  20. Comments should be related to the lines of code below

HDL Coding Guidelines - Part 4


To Avoid common Errors
  1. A configuration declaration is needed for each architecture in the design
  2. Design-internal references must use library work
  3. Use selected names in binding indications and ’use’ clauses only
  4. Configuration must be in a separated file except the latest level of hierarchy
  5. All primary unit names must be unique in the project library
  6. Identifier casing should be uniform in all VHDL code
  7. Length of entity names should not exceed 32 characters
  8. An instance name must not contain the substring ’pfiller’
  9. Use unresolved data types if possible
  10. Hard/firm macros: Data types at ports: std_(u)logic(_vector)
  11. Generics must have type integer for synthesis
  12. Avoid feedthroughs
  13. Strength stripping should be performed on chip level
  14. Do not assign the value 'X'
  15. Asynchronous reset is mandatory for sequential processes
  16. Do not use internal three-state busses
  17. Use the predefined templates for component instantiation
  18. Refer to one edge of clock, only
  19. Do not use combinational feedback loops
  20. Global signals may be used for testing purposes only
  21. Use relative path names for files accessed through text-IO
  22. Binary file-IO may not be used
  23. In association lists of generic maps and port maps use named association
  24. VHDL-93 keywords should not be used
  25. Verilog keywords should not be used
  26. SDF keywords should not be used
  27. IKOS keywords should not be used
  28. Allowable replacement characters are forbidden
  29. Tool specific types may not be used
  30. Configuration declarations must have the configuration name and the entity name in one line for vimport
  31. Never redefine standard operators, subprograms, attributes, and packages
  32. Language for modeling is VHDL-87
  33. Comparison of arrays must be based on arrays of the same width
  34. Bussed arithmetic objects use "downto" as their index orientation
  35. Store package header and body into same file
  36. Default values for ports, signals, and variables may not be used
  37. Data types must be synthesizable
  38. Array ranges must be of type integer
  39. Integer type objects must be constrained with respect to to their range
  40. Use standard templates for clocked processes
  41. Generics must have type integer
  42. Order of generics in entity, component and instance must be the same
  43. Place port and generic maps at the component instantiation
  44. Instantiated component and entity name must be equal, incl. casing
  45. The sensitivity list for combinational processes must be complete
  46. Write variables before read in combinational logic
  47. Bit-wise association of arrays in port maps is not possible in presence of generics
  48. Embedding scripts as meta comments is not acceptable
  49. Use only standard meta comments
  50. Code for synthesis must match the synthesis subset
  51. Do not use disconnect, register, and bus
  52. Do not use port modes buffer and linkage
  53. Do not use configuration specification (“hard binding”)
  54. Do not use blocks
  55. Avoid identifier hiding caused by loop index
  56. Recursive use of subprograms is forbidden
  57. Do not use guarded signals, guarded assignments, and guarded expressions
  58. Trailing comments are only allowed for declarative lists

HDL Coding Guidelines - Part 3


Portability
  1. Language for modeling should be VHDL-87
  2. VHDL-93 keywords should not be used
  3. Verilog keywords should not be used
  4. SDF keywords should not be used
  5. IKOS keywords should not be used
  6. Allowable replacement characters are forbidden
  7. Tool specific types may not be used
  8. Configuration declarations must have the configuration name and the entity name in one line
  9. Never redefine standard operators, subprograms, attributes, and packages
  10. Design-internal references must use library work
  11. Bussed ports of width one are forbidden
  12. Carefully use real values with PN-generators
  13. Be aware of operating-system-specific features
Arithmetic
  1. Bussed arithmetic objects use "downto" as their index orientation
  2. Comparison of arrays must be based on arrays of the same width
  3. Request external VHDL code suppliers to deliver used arithmetic packages
  4. Avoid homographs
  5. Where to use ieee.std_logic_arith and std_developerskit.synth_regpak
  6. Where to use std_logic_signed and std_logic_unsigned
  7. Take care of array widths for std_logic_arith operators
  8. Use conversion functions around arithmetic operators
Synthesizability
Note that the restrictions listed below do not apply to pure simulation models and not to testbench models.
  1. Code for synthesis must match the synthesis subset
  2. Store package header and body into same file
  3. Default values for ports, signals, and variables may not be used
  4. Data types must be synthesizable
  5. Array ranges must be of type integer
  6. Integer type objects must be constrained with respect to to their range
  7. Use standard templates for clocked processes
  8. Generics must have type integer
  9. Order of generics in entity, component and instance must be the same
  10. Place port and generic maps at the component instantiation
  11. Instantiated component and entity name must be equal, incl. casing
  12. The sensitivity list for combinational processes must be complete
  13. Write variables before read in combinational logic
  14. Bit-wise association of arrays in port maps is not possible in presence of generics
  15. Embedding scripts as meta comments is not acceptable
  16. Use only standard meta comments
  17. Gate instantiation must be encapsulated by separate unit
  18. Requirements for resource sharing
Simulation Performance
  1. Use sensitivity lists instead of wait statements
  2. Minimize the number of signals of your sensitivity list
  3. Avoid unnecessary computations within loops
  4. Remove unnecessary code fragments
  5. EMC and transmission line effects need not be modeled
  6. Use abstract, compact coding style in testbench and simulation models
  7. Minimize the number of processes, signals, and signal assignments
  8. Replace signals by variables whenever possible
  9. Inhibit execution of statements where not necessary
  10. Divide large memories into blocks
  11. Avoid unnecessary repetition of function calls
  12. Avoid declaring constants within subprograms
  13. Always use deallocate(access_obj) to dereference allocated memory
Critical Constructs
  1. Do not use guarded signals, guarded assignments, and guarded expressions
  2. Do not use disconnect, register, and bus
  3. Do not use configuration specification (“hard binding”)
  4. Do not use port modes buffer and linkage
  5. Do not use blocks
  6. Avoid identifier hiding caused by loop index
  7. Global signals may be used for testing purposes only
  8. Recursive use of subprograms is forbidden
  9. Subprograms may not have any side effects
  10. Use only well tested functions for object-initialization purposes
  11. Be aware of the use of the attributes DELAYED, STABLE, QUIET, and TRANSACTION

IFIP/IEEE VLSI-SoC 2008 International Conference, 16th International Conference on Very Large Scale Integration


IFIP/IEEE VLSI-SoC 2008 International Conference
16th International Conference on Very Large Scale Integration

October 13-15, 2008
Rhodes Island, Greece

http://vlsi.ee.duth.gr/vlsisoc-2008

 

CALL FOR PAPERS

 

ABOUT VLSI-SoC 2008:
VLSI-SoC 2008 is the 16th in a series of international conferences sponsored by IFIP TC 10 Working Group 10.5 and IEEE CEDA that explores the state-of-the-art and the new developments in the field of Very Large Scale Integration Systems and their designs. Previous Conferences have taken place in Edinburgh, Trondheim, Tokyo, Vancouver, Munich, Grenoble, Gramado, Lisbon, Montpellier, Darmstadt, Perth, Nice and Atlanta. The purpose of the Conference is to provide a forum to exchange ideas and to show industrial and research results in the fields of VLSI/ULSI Systems, VLSI CAD and Microelectronic Design and Test.

Topics of interest include but are not limited to:

  1. Analog, Digital, and Mixed-Signal IC Design
  2. 3-D Integration and Physical Design
  3. Deep Submicron Design and Modeling Issues
  4. New Devices and MEMS
  5. Testability and Design for Test
  6. CAD and Tools
  7. Digital Signal Processing and Image Processing IC Design
  8. Prototyping, Validation, and Verification
  9. Modeling and Simulation
  10. System-On-Chip Design
  11. Embedded Systems Design
  12. New Architectures and Compilers
  13. Reconfigurable Systems
  14. Low-Power Design
  15. Logic and High-Level Synthesis
  16. New Applications (communications, biosystems, video, automobile, security, sensor networks, etc.)
  17. Real-Time Systems

 

IMPORTANT DATES

Paper submission:                     March 28, 2008
Special Session proposal:          March 28, 2008
Notification of acceptance:        June 16, 2008
Camera ready submission:         July 11, 2008

 

SUBMISSION INSTRUCTIONS

Papers should present original research results not published or submitted for publication in other forums. Papers should not exceed 6 pages (single-spaced, 2 columns, 10pt font; see the VLSI-SoC website for detailed guidelines soon) and must be submitted electronically using the VLSI-SoC 2008 website. The proceedings will be published by IFIP (with ISBN) and available through IEEE Xplore. They will be distributed during the conference to all participants. A selection of the conference best papers will be invited to submit an extended version to be included as chapters of a book to be published by Springer.

GENERAL CHAIR
Prof. Dimitrios Soudris, Democritus Univ. of Thrace, Greece

PROGRAM CO-CHAIRS

  • Prof. Christian Piguet, CSEM, Switzerland
  • Prof. Thanos Stouraitis, Univ. of Patras, Greece

PUBLICITY CO-CHAIRS

  • Prof. David Atienza, Complutense U. of Madrid, Spain
  • Prof. Bernard Courtois,TIMA Labs, France

KEYNOTE SPEAKERS

Prof. Eby Friedman, Univ. of Rochester, USA
Keynote Talk Title: "Interconnect-Based Design Challenges in High Performance Two- and Three-Dimensional Integrated Circuits and Systems"

Prof. Ahmed Jerraya, CEA/LETI, France
Keynote Talk Title: "Design and Programming strategies for MPSoC"

Dr. Roberto Zafalon, STMicrolectronics, Italy
Keynote Talk Title: "CLEAN: Leakage Aware Design for Next Generation's SOCs"

STEERING COMMITTEE

  • Manfred Glesner, TU Darmstadt, DE
  • Ricardo Reis, UFRGS, BR
  • Michel Robert, U. Montpellier, FR
  • Luis Miguel Silveira, INESC ID, PT

CONFERENCE SECRETARIAT/WEB DESIGN
Christos Baloukas
Democritus Univ. of Thrace
email: VLSI SOC 2008

SPONSORS

VLSI-SoC 2008 is kindly supported and sponsored by the following companies and
institutions:

HDL Coding Guidelines - Part 2


When Compiling (VHDL):
  1. A configuration declaration is needed for each architecture in the design
  2. Design-internal references must use library work
  3. Use selected names in binding indications and ’use’ clauses only
  4. Testbench and DUT should be compiled into the same library
  5. Avoid more package references than needed
Partitioning VHDL Code
  1. VHDL units should take into account later floorplanning
  2. Asynchronous parts should be placed into separate entities
  3. Keep all objects and subprograms in the nearest possible scope
  4. Keep local objects invisible outside a package
  5. Transfer stable component declarations into components packages
  6. Re-use functionality of standard packages as much as possible
  7. Size of VHDL Units should be reasonable for synthesis
  8. A VHDL unit should not exceed 500 lines of code
  9. A process or subprogram should not exceed 100 lines of code
  10. Component instantiations should not exceed 4 levels of hierarchy
  11. An architecture should not contain more than 10 processes
  12. Structural and behavioral code should not be mixed
  13. Define project packages early in the project
Storing VHDL Code
  1. Configuration must be in a separated file except the latest level of hierarchy
  2. Only verified VHDL code allowed for check-in
  3. Store each VHDL unit into a separate file except package header and body
  4. Hide old VHDL files
Naming Conventions
  1. All primary unit names must be unique in the project library
  2. Identifier casing should be uniform in all VHDL code
  3. Length of entity names should not exceed 32 characters
  4. An instance name must not contain the substring ’pfiller’
  5. An instance name must not start with bondpad
  6. Identifier naming must be based on English language
  7. Use meaningful identifier names
  8. Separate identifier components using underscores
  9. Signal assignments for renaming purposes should be avoided
  10. The names of clocks and resets should be unique in the whole design
  11. Naming conventions for VHDL units
  12. Naming conventions for VHDL files
  13. Naming conventions for VHDL objects
  14. Choose short instance names
  15. Keyword casing should be uniform in all VHDL code
  16. Use standard top-levels xmpl, xmpl_top, and xmpl_chip
  17. Use an intermediate signal for reading from an output port
  18. Example for unit and file naming conventions
  19. Abbreviations for naming conventions
Data-Types
  1. Use unresolved data types if possible
  2. Hard/firm macros: Data types at ports: std_(u)logic(_vector)
  3. Generics must have type integer for synthesis
  4. Soft macros: Data types at ports: std_(u)logic(_vector)
  5. Avoid custom data types (e.g., multidimensional arrays, records, enumeration types)
  6. Self-defined conversion functions must assert un-mappable input values
  7. Use complex data types inside architectures
  8. Use a small number of self-defined global data types
Design Rules
  1. Asynchronous reset is mandatory for sequential processes
  2. Do not use internal three-state busses
  3. Use the predefined templates for component instantiation
  4. Refer to one edge of clock, only
  5. Do not use combinational feedback loops
  6. Avoid feedthroughs
  7. Strength stripping should be performed on chip level
  8. Do not assign the value 'X'
  9. Balance clock to delta accuracy
  10. Pull-ups and pull-downs have to be modeled on chip level
  11. Gate instantiation must be encapsulated by separate unit
  12. A FSM must be described in a separate entity/architecture pair
  13. Instantiate the power pads for each power domain
  14. Spend extensive efforts for documentation of interfaces
  15. Spacer cells needed between pads
  16. Signals that cross clock domains must be synchronized by synchronization cells
  17. Avoid gated clocks unless absolutely necessary
  18. Avoid latches unless absolutely necessary
  19. All outputs of synchronous modules should be registered
  20. Process only one clock in RTL-units
  21. Do not use the value of type’left for initializing of a signal or variable during reset
  22. Avoid unused ports, busses must be split accordingly
  23. Use case-statements instead of if-statements when the conditions are mutually exclusive
  24. All signals and variables should be read at least once
  25. Static ports should not exist
  26. Avoid unnecessary computations within loops
  27. Insert test-enable for scan-test
  28. Use vector operations instead of loops
  29. Avoid unnecessary repetition of function calls
  30. Use efficient description for the wrap around of counters
  31. Build interface consistency checks into the model
  32. For soft-core development use generics, do not use constants
Testbenches
  1. Global signals may be used for testing purposes only
  2. Variables of access types should be modified only in procedures defined in packages
  3. A testbench has neither ports nor generics
  4. Use abstract, compact coding style in testbench and simulation models
  5. In case of accelerated simulation or emulation, the testbench must be synthesizable
  6. Stop the simulation from within the testbench
  7. Use assertion messages extensively
Text-IO
  1. Binary file-IO may not be used
  2. Use relative path names for files accessed through text-IO
  3. Communication between modules using text-IO is forbidden
  4. No characters with a lower rank than space may occur in text-IO
  5. Check the success of a read operation
  6. Use std.textio only, where really necessary
  7. Store file data to a VHDL variable, if read multiple times
Readability
  1. In association lists of generic maps and port maps use named association
  2. Language for comments and code documentation is English
  3. Comments should be related to the lines of code below
  4. Trailing comments are only allowed for declarative lists
  5. Comment each process, each subprogram and global aspects
  6. Processes should be labeled
  7. Aliases are not recommended
  8. Do not define a subprogram for a subtype only
  9. The names of clocks and resets should be unique in the whole design
  10. Use a separate library clause for each declared resource library
  11. Use a separate use clause for each declared package
  12. Maximum line-length is 100 characters
  13. Order of ports in entity, component and instance should be the same
  14. Do not have unused signals
  15. In association lists of subprogram calls use named association
  16. Indentation should be consistent in all VHDL code
  17. Align comments vertically
  18. Align declaration lists vertically
  19. Align association lists vertically
  20. Use closing labels for entity, architecture, process, loop, generate, etc.
  21. Indicate condition at remote ends of control structures (if ... then, case)
  22. Use one statement per line
  23. Group related constructs
  24. Group related port or signal declarations
  25. Switch constructs should not be nested to more than 4 levels
  26. Remove unnecessary code fragments
  27. Order of items should be the same in package header and body
  28. Use predefined attributes to make code generic and more re-usable
  29. Do not have code that have been commented out in checked-in versions

HDL Coding Guidelines - Part 1


Coding of circuit behavior and architecture is one of the most critical steps in the whole chip development project. It has a major impact on logic synthesis, routing results, timing robustness, verifiability and testability.

The HDL Coding Guidelines help chip and macro developers/teams to rapidly understand each other's code. Macro based designs integrate easier if these common coding styles are followed. This also applies to externally developed softcores. Codes will not need modification if simulator, synthesis tool, or technology is exchanged. Code invariants with respect to Synthesis tool is given in case of a similar HDL synthesis subset. Code invariants with respect to technology is given in case of similar performance and cell set. In addition, the given guidelines enable high synthesis quality and simulation performance.

The HDL Coding Guidelines need continuous adaptation according to new tool properties and new upcoming methodologies. Please participate in this process with your design know-how. Contribute rules for HDL coding that turned out to prevent errors in the downstream flow, or recommendations that alleviate further design, re-use or maintenance.

The HDL Coding Guidelines may be passed to sub-contractors or cooperation partners. Ideally their coding works should comply to these guidelines, enabling rapid and safe integration with internally developed modules.

Reading of the HDL Coding Guidelines is most efficient at the beginning of a chip-design-project. Furthermore a code review should be considered in a very early phase of HDL coding.

What is case analysis?


Case analysis lets you perform timing analysis using logic constants or logic transitions on ports or pins to limit the signals propagated through the design. Setting a case analysis with a logic constant propagates the constant forward through the design, then disables paths where the constant is propagated.

Setting a case analysis with a logic transition (rising or falling) eliminates certain paths by limiting the transitions considered during analysis. Case analysis propagates the constant values specified on nets forward (but not backward) through the design.

Register re-timing


Register retiming is a sequential optimization technique that moves registers through the combinational logic gates of a design to optimize timing and area.

When you describe circuits at the RT-level prior to logic synthesis, it is usually very difficult and time-consuming, if not impossible, to find the optimal register locations and code them into the HDL description. With register retiming, the locations of the flip-flops in a sequential design can be automatically adjusted to equalize as nearly as possible the delays of the stages. This capability is particularly useful when some stages of a design exceed the timing goal while other stages fall short. If no path exceeds the timing goal, register retiming can be used to reduce the number of flip-flops, where possible.

Purely combinational designs can also be retimed by introducing pipelining into the design. In this case, you first specify the desired number of pipeline stages and the preferred flip-flop from the target library. The appropriate number of registers are added at the outputs of the design. Then the registers are moved through the combinational logic to retime the design for optimal clock period and area.

Register retiming leaves the behavior of the circuit at the primary inputs and primary outputs unchanged (unless you choose special options that do not preserve the reset state of the design or add pipeline stages). Therefore you do not need to change any simulation test benches developed for the original RTL design.

Retiming does, however, change the location, contents, and names of registers in the design. A verification strategy that uses internal register inputs and outputs as reference points will no longer work. Retiming can also change the function of hierarchical cells inside a design and add clock, clear, set, and enable pins to the interfaces of the hierarchical cells.

Soft Macro Vs Hard macro?


Soft macro Vs Hard macro?
Soft macro and Hard macro are categorized as IP's while being optimized for power, area and performance. When buying IP and evaluation study is usually made to weigh advantages and disadvantages of one type of macro over the other like hardware compatibility issues like the different I/O standards within the design, and compatibility to reuse methodology followed by design houses.

Soft macros?
Soft macros are used in SOC implementations. Soft macros are in synthesizable RTL form, are more flexible than Hard macros in terms of reconfigurability. Soft macros are not specific to any manufacturing process and have the disadvantage of being unpredictable in terms of timing, area, performance, or power. Soft macros carry greater IP protection risks because RTL source code is more portable and therefore, less easily protected than either a netlist or physical layout data. Soft macros are editable and can contain standard cells, hard macros, or other soft macros.

Hard macro?
Hard macos are targeted for specific IC manufacturing technology. They are block level designs which are optimized for power or area or timing and silicon tested. While accomplishing physical design it is possible to only access pins of hard macros unlike soft macros which allows us to manipulate the RTL. Hard macro is a block that is generated in a methodology other than place and route ( i.e. using full custom design methodology) and is imported into the physical design database (eg. Volcano in Magma) as a GDS2 file.

Note:
Firm macros are in netlist format and are optimized for performance,area and power using a specific technology node. Firm macros are more flexible and portable than hard macros. Firm macros are mode predictable in terms of performance and area when comparing with soft macros.

Delays in ASIC/VLSI design


Source Delay/Latency, Network Delay/Latency, Insertion Delay, Transition Delay/Slew, Path Delay, Net delay, Wire delay, Interconnect delay, Propagation Delay, Phase Delay, Cell Delay, Intrinsic Delay, Extrinsic Delay, Input Delay, Output Delay, Exit Delay, Latency (Pre/post CTS), Uncertainty (Pre/Post CTS), Unateness: Positive unateness, negative unateness, Jitter: PLL jitter, clock jitter.

These terms are explained in good detail @ http://vlsifaq.blogspot.com/

Latch based Interview Question


Latch-based designs are sometimes used for high-speed digital circuits. One possible configuration places combinational logic between a pair of latches with opposite polarities (one latch is active high and the other is active low) that use the same clock signal. The two latches given below are intended to be used in such configuration. One of the two designs is an active high latch while the other is an active low latch. Additionally, you know that one of the two designs is a “bad” latch.










  1. Which of the two latches is active high and which is active low?
  2. Which of the two latches is the “bad” latch? Clearly justify your answer.

NVIDIA Interview Question


Two stages are added to the pipeline discussed in the earlier post to form the circuit shown below.













1.





2. Stage A decides to send the input either to stages B-C or to stage D.
3. 35% of data from stage A is sent to stages B-C while 65% of data from stage A is sent to stage D.
4. All information given in the earlier post is applicable to this pipeline as well.

Extend the power reduction scheme that your developed in the earlier post and apply it to the new pipeline. Calculate how much power will be saved when applying this scheme to the new circuit.

NVIDIA Interview Question


Your task is to develop a method to reduce the power consumption of the 2-stage image processing pipeline shown below (clock inputs are not shown for simplicity).











NOTES:
1.





2. The capacitance of an individual gate (e.g. AND, OR) is 1.
3. The capacitance of a flip flop is 2.
4. The circuit uses a valid-bit protocol to distinguish between valid and invalid data. The valid bit arrives in the same clock cycle as the valid data.
5. The environment sends valid data once every 5 clock cycles (e.g. one clock cycle with valid data, followed by 4 clock cycles of invalid data).
6. Your power reduction scheme shall not:
change the clock speed or any characteristics of the implementation technology (e.g. supply orthreshold voltage).
add or delete any signals between the circuit and the environment.
change the functional behaviour of the circuit for valid data.
7. Your power reduction scheme may increase the latency of the pipeline

Describe/illustrate your power reduction scheme. Calculate how much less power (as a percentage) the new circuit (i.e. with your scheme) consumes compared to the original circuit (i.e. without the power reduction scheme).

NVIDIA Interview Question


Circuit below, which implements operation C, has been designed such that it has two modules i and j, with the delays shown in the given figure below. The latency for circuit b is 2 and the delay through a register is 5ns. Assume that circuits a and b are stages of a pipeline as shown in the figure below.
















NOTES:
1. The pipeline has 2 stages where the first stage of the pipeline contains circuit a (executing operation A or B) and the second stage of the pipeline contains circuit b (executing operation C).
2. Stage 2 reads the output of stage 1 as soon as it is available even if the two operations of stage 1 (i.e. A and B) have imbalanced latencies.
3. The pipeline has registers only on the inputs of the stages
4. The performance and cost overhead due to control circuitry (e.g. Mux) is not considered in this preliminary analysis.

Based on your analysis in the earlier post, what is the total time required to execute 100 input parcels sent through the pipeline?

NVIDIA Interview Questions


You are designing a circuit that implements two operations A and B as shown below.














NOTES:

1. At any point in time the circuit is doing either A or B.
2. Delays through modules of each operation are given in the figure below.
3. The circuit must have registers on all inputs. No registers are needed on the outputs.
4. The delay through a register is 5ns.
5. Operation A occurs 70% of the time while operation B occurs 30% of the time.

What is the clock period that will result in highest overall performance?

And questions increasing in difficulty.

NVIDIA Interview Questions


State whether each of the following statements is True or False .
Justify your answers.

  1. RTL simulation is faster than delta-cycle simulation but can not be used in all situations.
  2. When doing RTL design, all flip-flops need to have a reset input that is synchronized with the clock.
  3. If P is a 16-bit unsigned signal, testing if P = 656 requires a minimum of 16 FPGA cells each having an LUT with 4 inputs, 1 output, a carry-in, and a carry-out.
  4. Because there are two types of memory operations (Read and Write), there are four different types of data dependencies that can exist between memory operations.
  5. When doing RTL design, a HLM can be written only after input/output allocation is done.
  6. If the hold time of a flip-flop is violated, a possible solution would be to add buffers at the input of that flop.
  7. Voltage scaling is a power reduction technique that relies on reducing the supply voltage of a circuit without affecting any of the other circuit parameters.
  8. Because of the small number of transitions between codes, a 32-state finite state machine that uses Gray coding will consume less power than one that uses binary coding.
  9. If a circuit contains some redundant components, all faults in the redundant circuitry are
    undetectable.

Useful Skew - Using Clock Skew as a Tool to Achieve Optimal Timing


What is Useful Skew anyway?
Some nonzero skews can become useful by creating safety margins to guard against delay variations (Moving the skews toward the center of the permissible ranges, creating safety margins against potential timing violations).

When we look for optimal design solutions, we need to look at the bigger picture:
What is the problem we're trying to solve in the first place? Is minimizing clock skew the primary goal of our design?
No, the primary goal of any design is to meet the chip's timing requirements. Since logic path delays also determine the timing of a chip, minimizing skew is just one approach to meeting the timing specifications. If we consider skew in the context of chip timing, we would find a larger, multidimensional space in which to search for solutions. Designers can consider skew--much like logic functions, gate sizes, and supply voltages--as a design variable. In that sense, what we're really trying to achieve is not just a good clock design, but rather a closure of timing or a more robust timing of the chip.

More detailed explanation @ (EE Times)

Pipelining Interview Question


Pipe-lining is particular form of re timing where the goal is to increase the throughput (number of results per second) of a circuit. Consider the circuit diagram below; the solid rectangles represent registers, the square are blocks of combinatorial logic:










Each combinatorial block in the diagram is annotated with it's propagation delay in ns. For this problem assume that the registers are "ideal", i.e., they have zero propagation delay, and zero setup and hold times.
  1. What are the latency and throughput of the circuit above? Latency is how long it takes for a value in the input register to be processed and the result appear at the output register. Throughput is the number of results per second.
  2. Pipeline the circuit above for maximum throughput. Pipelining adds additional registers to a circuit; we'll do this by adding additional registers at the output and then use the retiming transformation to move them between the combinational blocks. What are the latency and throughput of your resulting circuit?
Solution:

  1. The register-to-register TPD is the TPD of the longest path (timewise) through the combinational logic = 53ns. A value in the input register is processed in one clock cycle (latency = 53ns), and the circuit can produce an output every cycle (throughput = 1 answer/53ns).
  2. To maximize the throughput, we need to get the "30" block into it's own pipeline stage. So we'll draw the retiming contours like so:













Note there is an alternative way we could have drawn the contours to reach the goal of isolating the "30" block; it might be that other implementation considerations would help pick which alternative was more attracive. Similarly, we could have instead added registers at the input and used retiming to move them into the circuit.
The contours above lead to the following piplelined circuit diagram:










A good check to see if the retiming is correct is to verify that there are the same number of registers on every path from the input(s) to the output(s).
The register-to-register TPD is now 30ns, so the throughput of the piplined circuit is 1/30ns. The latency has increased to 3 clock cycles, or 90ns. In general increasing the throughput through pipelining always leads to an increase in latency. Fortunately latency is not an issue for many digital processing circuits -- eg, microprocessors -- where we care more about how many results we get per second much more than how long it takes to process an individual result.

Logic Design Interview Question


In thinking about the propagation delay of a ripple-carry adder, we see that the higher-order bits are "waiting" for their carry-ins to propagate up from the lower-order bits. Suppose we split off the high-order bits and create two separate adders: one assuming that the carry-in was 0 and the other assuming the carry-in was 1. Then when the correct carry-in was available from the low-order bits, it could be used to select which high-order sum to use. The diagram below shows this strategy applied to an 8-bit adder:















  1. Compare the latency of the 8-bit carry-select adder show above to a regular 8-bit ripple-carry adder.
  2. The logic shown for C8 seems a bit odd. One might have expected C8 = C8,0 + (C4*C8,1). Explain why both implementations are equivalent and suggest why the logic shown above might be prefered. Hint: What can we say about C8,1 when C8,0=1?
Solution:



  1. For the low-order 4 bits, the latency is the same for both implementations: TPD,4-BIT ADDER. But with the carry-select adder, the remaining latency is the propagation delay of the 4-bit 2:1 multiplexer (TPD,2:1 MUX) instead of the longer time it takes for the carry to ripple through another 4 bits of adder (TPD,4-BIT ADDER). If we consider an N-bit adder, the latencies are:
    TPD,N-BIT RIPPLE = 2 * TPD,(N/2)-BIT RIPPLE
    TPD,N-BIT CARRY-SELECT = TPD,(N/2)-BIT RIPPLE + TPD,2:1 MUX
    As N gets large the carry-select adder is almost twice as fast as a ripple-carry adder since the delay through the 2:1 mux is independent of N. The carry-select strategy can be applied recursively to the (N/2)-bit ripple-carry adder, and so on, ultimately producing an adder with O(log2N) latency.



  2. If we think about carry generation, it's easy to see that if C8,0=1 then C8,1=1, i.e., if we get a carry with CIN=0, we'll also get a carry when CIN=1. Using this fact we can do a little Boolean algebra:
    C8 = C8,0 + (C4 * C8,1)
    ____
    = C8,0*(C8,1 + C8,1) + (C4 * C8,1)
    ____
    = (C8,0 * C8,1) + (C8,0 * C8,1) + (C4 * C8,1)
    = (C8,0 * C8,1) + 0 + (C4 * C8,1)
    = (C8,0 + C4)*C8,1
    
    In the worst case (the carry-in rippling all the way up), C8,1 will take a little longer to compute than C8,0, so the logic for C8 shown in the diagram will be a little faster since it provides the shorter path to C8.

CMOS Interview Question


Occasionally you will come across a CMOS circuit where the complementary nature of the n-channel pull-downs and p-channel pull-ups are not obvious, as in the circuit shown below:




  1. Construct a table that gives the on-off status of each transistor in the circuit above for all combinations of inputs A and B.
  2. Compute the output, Y, for each input combination and describe the function of the above circuit.
Solution:





2. The output Y is connected to four pairs of transistors in series, so each of these pairs can affect the output.
    when A=0 and B=0, transistors T4 and T5 are on, so Y=0 when A=0 and B=1, transistors T6 and T7 are on, so Y=1 when A=1 and B=0, transistors T2 and T3 are on, so Y=1 when A=1 and B=1, transistors T8 and T9 are on, so Y=0
Putting this together, we conclude that Y = XOR(A,B).

Logic Design Interview Question


A priority encoder has inputs that are assigned in some predetermined order. The output is the binary encoding of the first "1" valued input from the ordered list, and it is zero otherwise.
  1. Give the truth table for a 3-input priority encoder.
  2. Give a sum of products realization of this priority encoder.
Solution:


  1. Assume the inputs are A, B, C with A having priority 3, B priority 2 and C priority 1:
    A  B  C | P1 P0
    ========|=========
    0  0  0 |  0  0
    0  0  1 |  0  1
    0  1  0 |  1  0
    0  1  1 |  1  0
    1  0  0 |  1  1
    1  0  1 |  1  1
    1  1  0 |  1  1
    1  1  1 |  1  1
    

STA Interview Question


Suppose we are building circuits using only the following three components:
  • inverter: tcd = 0.5ns, tpd = 1.0ns, tr = tf = 0.7ns
  • 2-input NAND: tcd = 0.5ns, tpd = 2.0ns, tr = tf = 1.2ns
  • 2-input NOR: tcd = 0.5ns, tpd = 2.0ns, tr = tf = 1.2ns
Consider the following circuit constructed from an inverter and four 2-input NOR gates:






  1. What is tPD for this circuit?
  2. What is tCD for this circuit?
  3. What is tPD of the fastest equivalent circuit (i.e., one that implements the same function) built using only the three components listed above?
Solution:
  1. tPD for the circuit is the maximum cumulative propagation delay considering all paths from any input to any output. In this circuit, the longest path involves three 2-input NAND gates with a cummulative tPD = 6ns.
  2. tCD for the circuit is the minimum cumulative contamination delay considering all paths from any input to any output. In this circuit, the shortest path involves two 2-input NAND gates with a cumulative tCD = 1ns.

  3. The most straightforward way to determine the functionality of a circuit is to build a truth table:
    A  B  | OUT
    ======|=====
    0  0  |  1
    0  1  |  0
    1  0  |  1
    1  1  |  0
    
    from which we can see that OUT = not B. We can implement this with a single inverter that has a tPD = 1ns.

STA Interview Question


Suppose that each component in the circuit below has a propagation delay (tpd) of 10ns, a contamination delay (tcd) of 1ns, and negligable rise and fall times. Suppose initially that all four inputs are 1 for a long time and then the input D changes to 0.

Draw a waveform plot showing how X, Y, Z, W and Q change with time after the input transition on D.







Solution:

Discussion based Interview Question


 Your company, EarGuard Inc., is working on the q-pod, a new music player. The chief verification engineer has just reported that a bug has been discovered in the qDub module of the q-pod. The verification team has a hypothesis for what triggers the bug. Your task is to valuate whether the verification team's hypothesis is correct.

INSTRUCTIONS:
1. Facts about the qDub module:
Number of input bits: 56
Number of output bits: 32
Number of combinational gates: 500
Number of flip-flops: 100
Latency 5 clock cycles
Clock speed: 200 MHz

(a) All output signals are combinational
(b) The input is three unsigned numbers, each of which is between 0 and 65535 inclusive
(c) The output is two unsigned numbers, each of which is between 0 and 65535 inclusive
(d) If the bug occurs, both output signals are assigned 0. If the qDub was correct, it would never be the case that both output signals were 0 at the same time.
(e) The verification team hypothesizes that the bug occurs if-and-only-if in a single clock cycle, all three of the input numbers are greater than 19 and less than 25.

2. Test setup:
(a) EarGuard Inc. has begun to manufacture qDub chips for evaluation purposes. You are given 100 qDub chips, each of which has a computer and a test rig (printed circuit board and cables) to connect the qDub chip to the computer so that the computer can generate input test data and analyze the results.
(b) The test rigs can send and receive data with the qDub at the normal clock speed of the qDub (200MHz).
(c) All the qDub modules are the same design and therefore have exactly the same buggy behaviour.
(d) You must complete your evaluation within 2 months, so that the Earsplit managers can decide whether to ship the q-pod with the buggy qDub or delay production.

Briefly describe your procedure to evaluate whether the verification team's hypothesis is correct.

Difficulty: Medium
9-ms0

Interview Question



You are on the committee to define a uniquely Indian Hardware Description Language: IndieHDL — a cool language from a hot country. One proposal is to restrict the language so that IndieHDL supports only synthesizable programs.
From a user's perspective, what would be the two most significant consequences of switching from VHDL to a hardware description language that supports only synthesizable programs?
Dificulty: Easy
Solution:

  1. Most testbenches will have to be written in another language, because they rely on unsynthesizable code.

  2. Most high-level models will have to be written in another hardware description language. An HDL is often needed for high-level models, because we want to model clock cycles and concurrency easily. The first versions of high-level models often contain unsynthesizable code.

  3. IndieHDL will be easier to learn, because it is simpler. The issue of synthesizable vs unsynthesizable will completely disappear.