1 / 20

System-On-a-Chip: A case study based on the ELIET Chip

System-On-a-Chip: A case study based on the ELIET Chip. Contents. ELIET Architecture SoC trade-offs Design methodology Specification Problem General information about ELIET Designed to last System Integration Verification Conclusion References. ELIET Architecture.

Download Presentation

System-On-a-Chip: A case study based on the ELIET Chip

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. System-On-a-Chip: A case study based on the ELIET Chip

  2. Contents • ELIET Architecture • SoC trade-offs • Design methodology • Specification Problem • General information about ELIET • Designed to last • System Integration • Verification • Conclusion • References

  3. ELIET Architecture • ELIET stands for Electronic ISDN Echo Canceller Transceiver • Mixed analog/digital chip integrating all the functions required to implement an LT (line termination) system • ELIET building blocks are: • custom DSP • 8 bit harvard micro-controller • embedded memories (ROMs and SRAMs) • different internal and external bus protocols • A/D and D/A converters • PLL • ...

  4. ELIET Architecture

  5. SoC trade-offs ADVANTAGES: • Cost reduction • Shortening time to market • attack productivity bottlenecks (verification) • good design methodology • Increase of complexity • Design methodology and the right verification strategy become critical DISADVANTAGES:

  6. Design Methodology • State of the art tools • robust and proven design flow • rigorous project management • definition phase • guidelines • checklists • design specification • design phase • VHDL coding, DFT, synthesis, floorplan, wireload model generation, P&R • verification phase • behavioural models, RTL simulation, code coverage, GL simulation, formal verification • documentation phase • functional doc. • implementaion doc. • verification doc.

  7. The Specification Problem • specification detailed enough to allow RTL coding • save time and unpleasant surprises on silicon • serve as feasability study • functionality, timing, performance, interfaces, physical issues (area, power, …) • continuously updated • paper specification • formal specification • executable specification (C, C++, matlab, Cossap, …)

  8. The Specification Problem • Overview • Functional requirements • Physical requirements • Verification requirements • Design guidelines • Block diagram • Interfaces • signal names and meanings • transaction protocols (timing diagram) • timing specifications • set-up and hold time on inputs • clock to Q time for outputs • special signals (test, analog, …) • asynchronous signals • clocks, resets, interrupts and their timing • legal values for input and output datas • checklists (paper, scripts, …)

  9. General information about ELIET

  10. Some number about ELIET

  11. Designed to last • Chip design constrained by what can be verified, rather than by the functions • design style driven by verification (clock synchronous synthesizable RTL) • As the complexity of the chip increases “Pray to God approach” is not an option • No magic rule to getting first-time-right silicon • maximum level of quality in each step of the development process • no separation between front end and back end • too many macros with the wrong aspect ratio can make the chip unroutable or too big or can create unacceptable delays on critical nets • accurate wire load models for DSM • bottom up synthesis approach recommended

  12. Designed to last • clock distribution accurately studied • balanced clock tree with low skews • test strategy decided at an early stage of the design • BIST for memories • full scan flops • max 1000 flops per scan chain • boundary scan • insulation and ad hoc testing for analog macros • Guidelines and Checklists • RTL coding guidelines • coding for portability (ieee standard types, too many subtypes, …) • guidelines for clock and reset • coding for synthesis • check code quality (profiling tools, synthesis results, ...) • no unexplained warning

  13. System Integration • Reduce the number of new gates introduced • Massive reuse of existing proven designs • reused parts need to be pre-verified with high degree of quality to allow SOC verification to complete within a reasonable time frame • not all core configurations have been tested together • Focus of system level simulation is on errors at macro interconnections level • misunderstanding of the bus protocols • different bridges to communicate between the different busses • standardize on a single common bus architecture

  14. Verification • Main bottleneck of the development process • Right verification strategy at each step of the design • It is verification that drives the selection of tools and design style • Define the verification plan as soon as possible • a list of all test bench components • a list of required verification tools • a list of specific tests • what functionality will be verified • target code coverage • description of the regression test environment and regression procedures • Test bench design takes more time than the circuit design • The entire set of test benches and test suites must be reusable (different design teams) and portable (different simulators)

  15. Verification • Test bench must be one of the deliverables • Bus functional models & bus monitors • single test bench command file • VHDL test bench guidelines • use a clock to synchronize stimuli generation • use built in textio packages • partition the test bench code in synthesizable and behavioural • do not generate data , clocks and resets from the same process • common strategy for the test bench for both sub-modules and top level • the test bench has to be self-checking (no waveform inspection required) and issue a clear error message in case of failure (what occured, at what time, what was the expectation, what is the result, …)

  16. Verification • Toggle coverage greater than 98% • Timing analysis • static timing analysis and formal verification • gate level simulation in case of asynchronous parts

  17. Conclusion • Mixed analog/digital 4 channel ASIC for ISDN • 0.35 mm, 3.3 V technology • 4 analog macros (about 2 mm2 each) • 2 PLLs (about 1.10 mm2 ) • microprogrammed 8 bit Harvard processor for the ISDN data processing control (about 6.09 mm2 ) • custom DSP implementing the echo cancellation algorithm (about 3.07 mm2 ) • line controller (about 1.60 mm2 ) • universal external interface and iom/PCM interface (about 1.60 mm2 ) • 6 ROMs for the microprogrammed processor (about 1.76 mm2 ) • 1 ROM and 4 SRAMs for the DSP (about 1.75 mm2 ) • Total Area of the chip ~ 51 mm2

  18. Conclusion

  19. Conclusion

  20. References M.Keating, P. BricaudReuse methodology manual for system-on-a-chip DesignsKluwer Academic Publishers, 1998 A.M. Rincon, W.R. Lee, M. SlatteryThe Changing Landscape of System-on-a-Chip DesignCustom Integrated Circuits Conference, 1999 R.D. AdamsSystem on a chip TestingCustom Integrated Circuits Conference Educational Sessions, 1999 D.D. WarmkeFour white papers on VHDL designIntegrated System Design, 1993

More Related