Please download to get full document.

View again

of 38
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Document Share
Document Tags
Document Transcript
  THE   ILSP   BEHAVIORAL   DESCRIPTION   LANGUAGE AND   ITS   GRAPH   REPRESENTATION FOR   BEHAVIORAL   SYNTHESIS Masayasu   Odani Sun   Young   HwangTom   BlankTom   Rokicki Technical   Report:   CSL TR 88 350 March   1988 This work was supported by Defense Advanced Research Projects Agencyunder Contract No. MDA 903-83-C-0335, and partly by Toshiba Corporation.  THE   ILSP   BEH VIOR L   DESCRIPTION   L NGU GE AND   ITS   GRAPH   REPRESENT TION FOR   BEH VIOR L   SYNTHESIS Masayasu Odani, Sun Young Hwang, Tom Blank, and Tom Rokicki Technical Report: CSL-TR-88-350 March 1988Computer Systems LaboratoryDepartments of Electrical Engineering and Computer ScienceStanford UniversityStanford, CA 943054055 Abstract This report describes the ILSP behavioral description language and its internalrepresentation employed in the zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA emod   behavioral synthesis system. Using combinedcontrol/data flow graph (C/DFG)  as an intermediate representation, Hermod  generateshardware modules and their interconnection from behavioral descriptions. Hex-mod isincluded in an integrated environment for hardware simulation and synthesis systemunder development at Stanford University. The functional models written in ILSP canbe simulated on the THOR logic/functional/behavioral simulator without translation.After proper verification of its behavior, an ILSP model can be input to the synthesizerfor compilation into an RT-level description.This report consists of two parts: the specification of the ILSP language and its graphrepresentation. Key  Words and Phrases: behavioral description language, behavioral synthesis,structural synthesis, control and data flow graph, register-transfer level description,functional simulation.  Copyright 1988 bY Masayasu OdaniSun Young HwangTom Blank Tom Rokicki  The   ILSP   Behavioral   Description   Language 1.   Overview This document provides the features and syntax of the ILSP(Input  Language forSynthesis Program), which is used to describe the behavior of functional modules.Compared to the ISPS (Instruction Set Processor Specifications) which describeshardware at register-transfer level, the ILSP description is purely procedural orbehavioral. Her-mod is included in an integrated environment for hardware simulationand synthesis system under development at Stanford University. The functional modelswritten in ILSP can be simulated on the THOR logic/functional/behavioral simulatorwithout translation.After proper verification of its behavior, an ILSP model can bepipelined to the synthesizer for compilation into an RTL-level description.Based on the C-language, ILSP has conditional (if-then-else and switch), and loop (while- and do-loop) control constructs.It also allows explicit specification of theactual hardware interface to the outside world. Many features of the C languageconsidered redundant or unnecessary for behavioral representation of a hardwaremodule are omitted in ILSP. For instance, only integer type variables are supported,and parameter passing is handled through interface declarations in the ILSP proceduredeclaration section.. .The overall features of ILSP are presented in the first three*sections,  followed by theILSP syntax. The differences from the C language are presented in each section.  2 Lexical Conventions There are five classes of tokens: identifiers, keywords, constants, operations, anddelimiters (like ‘ ’  or ’   (‘).  Blanks, tabs, newlines, and comments are used to separate tokens. 2.1 Comments The characters ‘/*’  introduce a comment, which ends with the characters ‘*/‘. 2.2 Identifiers An identifier consists of a sequence of letters and digits. The identifier must startwith a letter. The underscore ‘-’ counts as a letter. Upper and lower case letters areconsidered different. There are no restrictions on the length of the identifier. 2.3 Keywords Reserved Words The following identifiers are reserved for use as keywords. The keyword zyxwvutsrqponmlkjihgfedcbaZ xtern   isnot supported for global variables in IMP;  instead, they should be explicitly declared inthe interface declaration sections. int  GRP r?gIsT OUTJ4L 5T if else defaultbreak ONE ZERO  MODELreturn 2.4 Constants . .SIG  BUS STLIST m h do  FLOAT  L.S O ENDLJSTcase while UNDEF   MSBO There are two types of constants: integer constants and reserved constants. Aninteger constant consists of a sequence of digits.Only decimal expressions are allowed. The reserved constants are ONE, ZERO, FLOAT, and UNDEF. They are irszd   torepresent the value of a signal line in the THOR simulation system.The objectsdeclared as SIG or GRP in the interface declaration sections are allowed to have one of these values.
Similar documents
View more...
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks