This document discusses the benefits of using a Chip Specification Language (CSL) to automatically generate shared infrastructure elements across hardware, software, simulation, and verification domains for chip design. Key points include: - CSL allows for a single specification of infrastructure that can be compiled to generate equivalent code for all domains, avoiding errors from manual generation and maintenance. - Automatically generating infrastructure can reduce engineering time spent on repetitive tasks by 10-100x, allowing teams to focus on design. - Shared infrastructure specified in CSL maintains consistency when changes are made, rather than requiring updates across different files and teams manually. - CSL can generate test benches, vectors, and other elements to dramatically increase verification points

1. Methodologies and flows for chip design
Chip Specification Language (CSL)
Derek Pappas

2. Overview

3. Shared infrastructure
• Infrastructure elements are shared between teams
• Infrastructure elements include hierarchies,
connections, vectors, vector readers/writers, state
elements (e.g. registers, register files, …), ISA’s,
pipelines, address maps, …
• Infrastructure elements do not include
• Control and data path elements which are typically
implemented differently in RTL and simulation

4. The cost of not automating vs automating
• Failing to automate the generation of infrastructure
code costs companies $$$’s and increases time to
market
• Conversely a significant reduction in engineering and
verification time can be achieved by automating the
infrastructure generation process

5. Infrastructure changes
• Changes in the architecture and RTL cause changes in
simulation, verification, documentation, and software
• Manually generated infrastructure is time consuming to
maintain
• Manually generated infrastructure limits the number of
verification points/test benches on projects
• Teams should not spend time creating and maintaining
infrastructure when the infrastructure can be generated

6. Infrastructure changes (continued)
• Changes in infrastructure are communicated through
emails, meetings, build breaks, and tickets
• Often documentation is not updated to reflect the
infrastructure changes

7. Throwing problems over the wall
• Throwing problems over the wall gives the illusion that
the generation of infrastructure in one domain can be
done quickly
• The next domain has to reimplement the same
infrastructure elements
• The changes have to be made in all domains

8. Problem: Parallel bookkeeping
• Eliminate the parallel bookkeeping required to
synchronize shared infrastructure elements between
teams

9. Automatically generate shared infrastructure
• 100x reduction in code
• Rapidly bring up the project
• Rapidly make changes
• Propagate changes to all affected parties

10. HW/SW/Simulation/Verification interface
methodology
HW SW
Verif Sim
Equivalent infrastructure across all file views/teams
with documentation
DOCS

11. Shared infrastructure
• Examples:
• Interfaces
• Registers
• Vectors

12. CSL infrastructure generation flow
CSL specification
HW SWVerif Sim DOCS
CSL compiler

13. Reduce integration time
• Tighter software/hardware integration
• Tighter simulation/hardware integration
• Tighter test/simulation/hardware integration

14. Benefits
• Rapidly bring up test benches, simulation and design
• Test RTL from day 1
• Spend time on the architecture and design
• No time wasted bringing up and maintaining
infrastructure
• 10-100x reduction in work required to create the project
infrastructure

15. Benefits (continued)
• Generate infrastructure code and documentation which
is in sync
• Create a specification for infrastructure which can be
compiled
• Cloud based team solution (to be built) for instant
collaboration using a GUI and table driven entry
• To be constructed using the existing C++ class
hierarchy and compiler, with web based tools and an
underlying database

16. Benefits (continued)
• Extensive CSL documentation (manuals)
• Need to be converted from Framemaker which is no
longer supported by Adobe
• CSL is throughly tested
• Automatic and manual test suites
• Regression/reports
• Needs to be turned into a web based report and run on
a continuous integration server like Jenkins

17. Dramatically increase the number of verification
points
• A verification point in an RTL design is either set of
interfaces or state that is driven by stimulus vectors and
compared expected vectors and/or state from an
alternate implementation’s
• Teams are bandwidth limited when creating verification
points in designs
• Creation and maintenance of test infrastructure is time
consuming

18. Typical objections to infrastructure meta
languages and compilers

19. Typical objections by HW engineers to using
meta specification languages
• “I can write the infrastructure code as fast as writing
meta language spec”
• No one can write code as accurately as a working
compiler can.
• “I only write the infrastructure code once”
• Infrastructure code changes and needs to be synced
across domains

20. Typical objections by HW engineers to using
meta specification languages (continued)
• “Integration does not take long so I do not need a meta specification
language/GUI/compiler”
• Integration lasts for an entire project cycle and if the entire design has
complete coverage with respect to test points it will take an army of
verification engineers to generate the test benches.
• “Integration does not take long so I do not need a meta specification
language/GUI/compiler”
• Integration accounts for a huge amount of delays on projects. We
Brought up 64 processor application specific chips at Sun in 2 weeks,
including a basic compiler and RTL model in under 3 weeks using a
meta language to generate the complex interconnect for the entire
chip in 2 days.

21. Typical objections by HW engineers to using
meta specification languages (continued)
• “Generated code is not flexible and I can’t add custom
code to it”
• Wrong. Generated code has points where custom
code can be inserted to modify the behavior of the
design
• “No one uses tools to do that…”
• Hardware engineers who do not not embrace well
understood software engineering principles reject
meta language compilers

22. Typical objections by HW engineers to using
meta specification languages (continued)
• “We already have point tools for memory map
generation, interconnect generation”
• The individual tools typically do not communicate with
one another and parts of the infrastructure
specification needs to be replicated in each of the
overlapping tool’s input format.
• “We have SystemC/System Verilog“
• These are not meta description languages

23. The Objections are not factual…
• In reality no programmer can create or maintain large
pieces of infrastructure code on a project
• Infrastructure code needs to be consistent across
different views which is not possible with “parallel book
keeping”
• It takes a lot longer to manually create and maintain
infrastructure code than it does to write a compressed
representation in a meta language and/or to use a GUI
to describe the specification and to compile the
specification

24. Meta specification language

25. Guaranteeing consistency between different
views
• A single source is used to describe the shared
infrastructure
• A single source eliminates parallel bookkeeping
problems

26. Automating the chip specification process
• A meta level specification is constructed using a GUI
and the Chip Specification Language (CSL)
• The CSL specification is checked for correctness by
software
• Generation of shared infrastructure code for RTL,
simulation, software, and verification

27. CSL Grammar/ENF
• CSL is well defined
• The language is parsed using ANTLR

28. Meta specification language benefits
• Single source
• Rapid changes
• Synchronization of changes across all domains
• Minimal time to infrastructure
• Minimal code set

29. Requirements for a meta specification language
• Different domains share infrastructure
• Need an unambiguous shared specification
• The specification should compile

30. CSL Language

31. CSL Attributes
• CSL is object oriented
• CSL is similar to C++/Java
• No pointers/memory management
• Scopes
• CSL is easy to learn

32. CSL Documentation
• CSL grammar is specified for each major component
(e.g. interconnect, test benches, …)
• Examples for each language construct are shown
• CSL code + diagrams + generated Verilog/C++

33. Interconnect, hierarchy and test
benches

34. Connections

35. Connection types
• Scalar
• Vector
• Concatenations
• Structures
• Hierarchies

36. Signal types
• [SLIDES UNDER CONSTRUCTION]

37. Aggregated structures
• [SLIDES UNDER CONSTRUCTION]

38. Connections and functional units

39. Connections and functional units
Hierarchies and pipelines
a0_0[9:0]
b0_0[9:0]
c0_0[9:0]
d0_0[9:0]
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a0_1[9:0]
b0_1[9:0]
c0_1[9:0]
d0_1[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]
x{x0}
x{x1}
y
x{x0}
x{x1}
y
x{x0}
x{x1}
y
z{z2}z{z0} z{z1}
top

40. Auto routing connections between end points
• End points, name(s), and the type to route are specified
• Intermediate connections do not need to be specified
• Benefits
• Consistency between different file views
• Rapid floor planning changes to meet full chip timing

41. Connections and functional units
a[9:0]
b[9:0]
c9:0]
d[9:0]
Signal Group
abcd
Connections
z{z0}.y.x{x0} ->
abcd
-> z{z1}.y.x{x0}
Hierarchy
x{x0} x{x1} x{x1} x{x1} x{x1} x{x1}
y y
top
y
z{z0} z{z1} z{z2}
Connections are autoroutes across hierarchies

42. Tech bench generation

43. C/C++/SystemC Simulator
infrastructure generation

44. Generation of simulator infrastructure code
• Simulator code is generated from the meta specification
• Equivalent verification points are chosen between the
RTL design and simulator
• Vector writers/readers are generated automatically
• Vector readers/writers are generated in the
corresponding test benches

45. Automatic simulator infrastructure generation
benefits
• The simulator infrastructure code is updated
automatically
• The generated infrastructure infrastructure in the
simulator is in sync with the corresponding
infrastructure elements in different domains (i.e. RTL,
software, verification)

46. Automatic test bench generation
• Maintain consistency between the RTL design unit
under test (DUT), the algorithmic or cycle based
simulator, tests, and test benches
• Generate test benches at every level
• The generation of infrastructure for test bench
generation/design coverage is not limited by the
bandwidth of the design, simulation, and verification
teams

47. Level of verification detail
• Creating test benches
• Integration of multiple units
• Leaf level testing
• Lots to maintain

48. Connections (signals) become vectors
• Consistency between the design, the simulator and the
test bench is maintained

49. Different levels of abstraction in models
C++ simulator
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
RTL test bench

50. Infrastructure equivalency requirement
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
Input vector Expected vector
Module under test instantiation
Vector checkerVector reader
Inter unit
Connections
Outputs
Design hierarchy
Inputs
OutputsInputs
Inter unit Connections
C++ simulator
RTL test bench

51. Infrastructure maintenance/parallel book keeping
• Single test bench
• At least 7 infrastructure elements to maintain
• Different teams needs to keep in sync
• Changes break regressions/tests

52. Deign hierarchy equivalency-verification point
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
C++ simulator
RTL test bench
Design hierarchy

53. Unit interface equivalency
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
OutputsInputs
OutputsInputs
C++ simulator
RTL test bench

54. Vector equivalency
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
Input vector Expected vector
C++ simulator
RTL test bench

55. Test bench generation
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
Module under test instantiation
Vector checkerVector reader
Inter unit Connections
C++ simulator
RTL test bench

56. State infrastructure/registers
C++ simulator
uint abcd1
uint abcd0
uint abcd1
uint abcd0
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
RTL test bench
RF
RF
==
Input vector
Expected vector
Comparator

57. Standalone algorithmic simulators can be built to
generate vectors
uint abcd1uint abcd1
a1_0[9:0]
b1_0[9:0]
c1_0[9:0]
d1_0[9:0]
a1_1[9:0]
b1_1[9:0]
c1_1[9:0]
d1_1[9:0]v
==
Input vector Expected vector
Stand
alone
software
simulator
RTL test bench
test(s)

58. Signal Inheritance

59. Objects share features
• The same bits are reused in different types of objects
• Connections
• Inputs/outputs
• Registers
• Pipelines
• Vectors

60. Reuse of features
• Objects inherit features from a meta description
• All derived objects share the same features

61. Reuse benefits
• Reuse reduces time to code
• Reuse reduces errors
• Reuse eliminates parallel book keeping
• Reuse reduces time to make changes

62. Example: pipeline connected to a signal
opcode_0[3:0]
srca_0[5:0]
srcb_0[5:0]
dest_0[5:0]
opcode_0[3:0]
srca_0[5:0]
srcb_0[5:0]
dest_0[5:0]
opcode_0[3:0]
srca_0[5:0]
srcb_0[5:0]
dest_0[5:0]
v
valid
stall
reset
enable
instruction_0[21:0] instruction[21:0]
v
valid
stall
reset
enable
instruction_0[21:0]
opcode[3:0]
srca[5:0]
srcb[5:0]
dest[5:0]
instruction[21:0]

63. Access elements in aggregated structures
instruction[21:0]
instruction.srca
instruction.srcb
instruction.dest

64. Memory maps

65. Memory maps (CSL under construction)
• The CSL memory map specification integrates tightly
with the other CSL components

66. Pipeline Generation

67. Generating pipelines (under construction)
• Generation of pipeline code can eliminate register over
and under run errors
• Valid, stall, and enable logic is generated
• Cookie cutter/cut and paste pipeline logic is generated
• Pipeline naming conventions are followed and names
are updated automatically

68. Control, Status, Query,
configure, Measure

69. Control, Status, Query, Configure, Measure
• Control
• Status

70. Out of band communication
• [UNDER CONSTRUCTION]

71. Non-shared infrastructure elements
• Non-shared infrastructure elements which need to integrate with RTL
for tape out models which can be generated from a specification
• Clock trees
• Testability logic
• IO pads
• Note: it can be argued that most of this logic should be int he RTL
design
• Some design teams “hack” the clock trees and testability logic into
the netlist which further delays takeout instead of putting the clock
trees and testability logic under test/regression control

72. More CSL components
• The CSL language is very comprehensive
• Many more CSL components are supported by the CSL
compiler and documented.
• Some components need to be built out