Presentation is loading. Please wait.

Presentation is loading. Please wait.

Verilog Code Generation for an ASIP Design Environment Nathan Kitchen Vinay Krishnan Mentor: Scott Weber (MESCAL) EE 244/249 Joint Project Fall 2002.

Similar presentations


Presentation on theme: "Verilog Code Generation for an ASIP Design Environment Nathan Kitchen Vinay Krishnan Mentor: Scott Weber (MESCAL) EE 244/249 Joint Project Fall 2002."— Presentation transcript:

1 Verilog Code Generation for an ASIP Design Environment Nathan Kitchen Vinay Krishnan Mentor: Scott Weber (MESCAL) EE 244/249 Joint Project Fall 2002

2 Outline Motivation Design Environment Approach Example

3 Motivation Three ways to design a programmable system (ASIP): Specify its micro-architecture and the operations it performs (the instruction set) and verify that they are consistent intractable in general Synthesize a micro-architecture from the ISAneed architectural hints and behavioral synthesis Specify the micro-architecture and extract the operations it supports We are here

4 Bottom-up Instruction Set Design Traditional Top-down Design ISA is fixed micro-architecture space instruction set space micro-architecture space Any of these instruction sets can implement the application. Bottom-up Design architecture exploration

5 Teepee Design environment for MESCAL Multi-view methodology –Common data model for generating simulator, assembler, compiler, and netlist –Views are abstractions of the model Can only use information present in the model Not allowed to introduce new semantics –Architecture view: designer lays out datapath –Operation view: extracts operations from architecture –Simulator view: generates simulator program –Hardware view: generates synthesizable Verilog (our project)

6 Advantage of Multi-View Design synthesis simulation RTL gates silicon C ≡? simulation synthesis data model RTL gates silicon C  Traditional: hard to verify equivalence of simulator and RTL written separately easier to verify correctness of transformations from common data model

7 Architecture View Actors connected by signals between ports Semantics of atomic actors defined by firing rules Composite actors allow hierarchy or(fire(in[0].p.1.int32, in[1].p.0, sel.p.1.e, out.p.1.int32) {out = in[0];} fire(in[1].p.1.int32, in[0].p.0, sel.p.1.e, out.p.1.int32) {out = in[1];} no_fire(in[0].p.0, in[1].p.0, sel.p.0.e, out.p.0) {} ) out in sel Port ColorMeaning.p.0Signal is not present (its data is invalid)..p.1Signal is present..p.1.eSignal is present and is an enumeration..p.1.intSignal is present and is a bit vector.

8 Composing Actors Control ports (select lines) are left unconnected. Their values will be determined in the operation view. out in sel inc in out dec in out in sel

9 Operation View Solve constraints on firing rules Iterative SAT procedure Only minimal solutions Operation 1 Operation 2 Operation 3

10 Instruction Models Composite1 has separate instruction models for NOP, i_1, and i_2 Composite2 has one instruction model for both i_1 and i_2 Composite1 Composite2 i_2 i_1

11 Approach (cut to Vinay)

12 A Sample Architecture View >>

13 Fetch Unit >>

14 Program Counter >>

15 Verilog Structure Preserve the hierarchical structure of the Architecture View Atomic actors => Atomic modules Composite actors => Composite modules

16 Atomic Modules Actor semantics implemented with behavioral Verilog Two parts: combinational logic and sequential state write Procedural ‘always’ blocks implemented for both Combinational logic in ‘always’ blocks instead of ‘assigns’ to avoid potential mux chains

17 Composite Modules Act as containers for the modules inside them Instantiate the inner modules Route the wires appropriately Merge control signals based on instruction models Ground unconnected ports, if any

18 Top-Level Module Decodes instruction word Converts opcodes to control signals which activate concerned atomic actors (one hot encoding of opcodes->control signals) Multiple issue width achieved by multiple-hot encoding! opcode parameter1 parameter2

19 Results!

20 Tools ModelSimPE 5.5ed Synplicity Pro 7.1

21 Circuit Schematic architecture view

22 Fetch Unit architecture view

23 Program Counter architecture view

24 Questions?

25 The Answer: 42

26 Prior Work Architecture description languages –Behavioral ADLs Describe instruction semantics Lack information for synthesizing micro-architecture –Mixed ADLs Describe semantics and micro-architecture Tightly coupled with specific tools Hardware description languages (e.g., Verilog) –Can describe any micro-architecture –No concept of operations

27 Future Work Combine operations into more conventional instructions in assembler or compiler view Multiple PEs


Download ppt "Verilog Code Generation for an ASIP Design Environment Nathan Kitchen Vinay Krishnan Mentor: Scott Weber (MESCAL) EE 244/249 Joint Project Fall 2002."

Similar presentations


Ads by Google