New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here


by: Ms. Jerad Bernhard


Ms. Jerad Bernhard
Texas A&M
GPA 3.75


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in ComputerScienence

This 26 page Class Notes was uploaded by Ms. Jerad Bernhard on Wednesday October 21, 2015. The Class Notes belongs to CPSC 689 at Texas A&M University taught by Staff in Fall. Since its upload, it has received 21 views. For similar materials see /class/226088/cpsc-689-texas-a-m-university in ComputerScienence at Texas A&M University.




Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/21/15
Design Interface and VerificationI Introduction to a model of interfacing components in a design and its verification MahapatraAXLMFEIIDO Interfacing components Process is an independent part of a computation done concurrently with other parts VHDL UNIX Thread is used in Java Component in Codesign COMPONENT name declaration local quantities of components used in computation computation MahapatraAXLMFEIIDO Telephone switch components 0 COMPONENT unit physical phone that detects the o ehook sends id and disconnects pmhoneicannector computation END unit COMPONENT connect check receiver not busy rree capacity arbiter COMPONENT transfer transmits digitized sound from common memory data transmission constantly in both directions Mahapah aAXLMFEIIDO Interfacing components Interface determines the coordination of the components including their data trans fer and synchronization Codesign demands heterogeneous interface modeling 7 Can not favor any one existing technology or signaling discipline alone A c ofnpbne39n t 39 component B Interface Mahapah aAXLMFEIIDO Interfacing components contd Interface model allows components to share one or more state variable ie simple Boolean integer buffer and other data type 7 Sharing value of state variable in interface may be changed by several different components 7 Undisciplined used of shared variable can lead to time dependent design errors which can be difficult to locate MahapatraAXLMFEIIDO 5 Telephone switch COMPONENT MnnhnnkBOOLEAN ltlt anyhooka 052p dialing sequ2n52gtgt Shared Van39 able onhook MahapatraAXLMFEIIDO 6 More Components of telephone switch After receiving dialing sequence the dialing component has the number until to be called this number is exchanged with the transfer component and therefore part of the interface COMPONENT dial0nh00k39BOOLEAN recinumber Together the arthook and recnumber makes up the interface between the dial and connect components of one unit they are grouped as record TYPE InterfaceDialCann Interface dialconnect campanentquot RECORD arthook BOOLEAN z39ndicale receiver on haakquot recinumber number Dialledphane END MahapatraAXLMFEIIDO 7 Physical Realization of State Variable Software as program variable in memory hardware wire connecting subcircuits 0 wires contain current value of state variable provision of refresh to remain current A state variable x is interpreted as a function from Time to its range of values eg x is boolean we have Mb x Time gt B Example Analog signal coming from microphone of a telephone Signal can be represented by state variable interface Mv v0ice39Time gt Freq The interface of an AD converter transforming analog input to discret 8 bit sample can be described as follows COMPONENT adcanvert n analog frequency out 0 255 MahapatraAXLMFEIIDO 8 Verification Veri cation is important for nontrivial design projects Ideally all exhaustive check is required but seldomely possible in practice Formal methods are more recent 7 Formality is a possibility but should not be mandatory Three kinds of formal methods are used at different stages of design process 7 Interface verification 7 design verification 7 Implementation verification MahapatraAXLMFEIIDO Interface verification What is interface verification Separate design to distinct components is common components interact through interface using coordination mechanism following the protocols 7 Designers might treat details on signaling differently across various components Leads to inconsistency gt Interface veri cation checks this inconsistencies MahapatraAXLMFall DO Design verification What is design verification Consists of verifying selected key requirements of incomplete models Example Arbiter 7 At most one device has access to common resources mutual exclusion Once the interface to bus has been designed it is possible to verify that it does not violate the mutual exclusion property even ifother components of the design are still missing MahapatraAXLMFEIIDO 11 Implementation verification To construct ef cient product it is necessary to re ne initial design into concrete realization typically includes a number of restrictions e g restrict integer values to a certain range so that you use xed number of bits Clearly it requires that the concrete realization has been done and hence implementation veri cation is relevant rather late in design process Now available in commercial design system MahapatraAXLMFEIIDO 12 Simplified Arbiter as an example COMPONENT arbiterreql grl reqr grr BOOLEAN INITIALLY grl FALSE grr FALSE ltlt reql A grr agrl TRUEgtgt H ltlt reql A grl agrl FALSEgtgt H ltlt reqr A grl agrr TRUEgtgt H ltlt reqr A grr agrr FALSEgtgt END arbiter Would check grr and grl are never both true This is mutual exclusion to beasserted grl A grr Reading assignment Section 651 of Text MahapatraAXLMFallDO 13 Interface Verification How is it possible to verify that different components have a consistent View of their interface 7 Allow them to have different views as long as these are not in con ict EX packet in communication protocol 7 An uninterrupted collection of bits to be transmitted vs structured packet with different fields indicating addresses control and checksum In codesign computational model interface of component consists of set of state variable and a protocol MahapatraAXLMFallDO 14 Interface verification contd Simple arbiter protocol fourphase 7 client requests the privilege by setting req to true 7 when gr becomes true the client enter its critical section 7 when leaving it req is set false 7 gr becomes false following req is set false This can be expressed formaly as follows reqposr reqpre grantpost reqpost grantpost grantpre grantpostreqpost Both the arbiter and the client may assume that the other components follow this protocol To verify that the changes made to gr by arbiter follow the protocol it must be shown that all its transitions obey grpost grpre reqpostgrpost39 Similarly for client reqpost reqpre reqpost grpost Mahapah aAXLMFEIIDO Design verification Requirements of a design are formalized as predicates constraining the computation Eg two grant signals never given simultaneous access Example Let us verify invariant in a design Invariant Sub Setofstate space containinginitjal state Further there must not be any transition from estate within the subset to a state T Tn 1 1 it ls on a state S is invariant lpre tprepost lpost To show that 7 grl A grr is an invariant for arbiter four implications must be shown le reql A grr A grl 7 grl A grr MahapatraAXLMFall DO Implementation verification Refine initial abstract design into concrete realization 7 This includes number of restrictions Both abstraction and realization are described form ally abstract design concrete design Abstract design consists of many possible scheduling algorithms vrs concrete des1gn is one of the possible realization 7 Thus concrete design wont exhibit all the behavior of abstract design Refer pp226227 for examples of concrete design of arbiter and the abstract arbiter 7 To show that the concrete design is a refinem ent one must show that any behavior exhibited by concrete design is also a possible behavior of abstract design MahapatraAXLMFEIIDO Cosimulation II Cosimulation Approaches Mahapatra Texas AampM Spring 03 How to cosimulate How to simulate hardware components of a mixed hardwaresoftware system within a unified environment This includes simulation of the hardware module the processor and the software that the processor executes How to simulate hardware and software at same time What are various challenges Software runs faster than hardware simulator How to run the system simulation fast keeping the above synchronized Slow models provide detailed and accurate results than fast models How to balance these effects Use of different platforms for simulations Mahapatra Texas AampM Spring 03 Some basic approaches 0 Detailed Processor Model processor components memory datapath bus instruction decoder etc are discrete event models as they execute the embedded software Interaction between processor and other components is captured using native eventdriven simulation capability of hardware simulator Gate level simulation is extremely slow tens of clock cyclessec behavioral model is hundred times faster Most accurate and simple model Backplane Mahapatra Texas AampM Spring 03 Bus Program running on Host Some basic approaches Model Cycle based simulator Discreteevent shells that only simulate activities of bus interface without executing the software associated with the processor Useful for low level interactions such as bus and memory interaction Software executed on ISA model and provide timing information in clock cycles for given sequence of instructions between pairs of IO operation Less accurate but faster simulation model Software executed by ISA Model B ackplane Mahapatra Texas AampM Spring 03 Some basic approaches 0 Instruction Set Architecture Model ISA can be simulated ef ciently by a C program C program is an interpreter for the embedded software No hardware mode Software executed on ISA model Execution on ISA model provides timing clock details of the cosimulation Can be more ef cient than detailed processor modeling because internals of the processor do not suffer the expense of discreteevent scheduling Program Running on Host B ackplane Mahapatra Texas AampM Spring 03 Some basic approaches 0 Compiled Model very fast processor models are achievable in principle by translating the executable embedded software speci cation into native code for processor doing simulation Ex Code for programmable DSP can be translated into Sparc assembly code for execution on a workstation No hardware software execution provides timing details on interface to cosimulation Fastest alternative accuracy depends on interface information Program running on host Backplane Mahapatra Texas AampM Spring 03 6 Some basic approaches 0 Hardware Model If processor exists in hardware form the physical hardware can often be used to model the processor in simulation Alternatively processor could be modeled using FPGA prototype say using Quickturn Advantage simulation speed Disadvantage Physical processor available Backplane Mahapatra Texas AampM Spring 03 A New Approach This is a combined HWSW approach The host is responsible of having OS some applications and might have superset simulating environment RSIM SIMICS SIMOID Use of fast backplane PCI for communication Real processor or processor core in FPGA as hardware model and ASICFPGA for interface and interconnection for hardware modeler Good for fast complex architecture simulations including multiprocessor Mahapatra Texas AampM Spring 03 Domain coupling In four out of siX approaches we have host that run software and required to interact with hardware model or simulator Dif culties providing timing information across the boundaries coupling two domains with proper synchronization Mahapatra Texas AampM Spring 03 Migration across cosimulation Consider the system simulation at different levels of abstraction throughout the design process In the beginning of design process hardware synthesis is not available Hence use functional model to study the interaction between HW and SW As design progress with more implementations replace functional model of hardware by netlist level Once detail operation of hardware is veri ed swap back the high level description of HW design to gain simulation speed The cosimulation environment should have this migration support across the levels of abstraction Offtheshelf Components design is not a part of the current design process Functional model is enough no need to know internal details Mahapatra Texas AampM Spring 03 l 0 Master slave cosimulation One master simulator and one or more slave simulators slave is invoked from master by procedure call The language must have provision for interface With different language Difficulties No concurrent simulation possible C procedures are reorganized as C functions to accommodate calls Master Slave Mahapatra Texas AampM Spring 03 l l Distributed cosimulation Software bus transfers data between simulators using a procedure calls based on some protocol Implementation of System Bus is based on system facilities Unix IPC or socket It is only a component of the simulation tool Allows concurrency between simulators V Cosimulation Software Bus Mahapatra Texas AampM Spring 03 l 2 Synchronization and Time in cosimulation In case of a single simulator say Verilog there is no problem for timing as single event queue is managed for simulation If there are several simulators and software programs in the domain hardware and software domain are using a handshaking protocol to keep their time clock synchronized Signals events transferred from one side to the other should have attached a time stamp It is possible to use a loosely coupled strategy which allows the two domain to proceed more independently If a signal is received with a time stamp lower than the current clock in the respective domain the respective simulator have to be back up Mahapatra Texas AampM Spring 03 l 3 Aspects of cosimulation A frame work of cosimulation consists of variety of components levels of abstractions and different models Mahapatra Texas AampM Spring 03 Heterogeneous Environment Ptolemy Ptolemy supports different design styles encapsulated in objects called Domain Domain realizes a computational model appropriate for a particular sub system Ex SDF Dynamic Data owDDF Discrete EventDE and Digital hardware modeling environment Thor Domain consists of a set of Blocks and Schedulers that con rm to a common computational model 96946 1mt1allze Block 39numlnit setup 39setSourcePortO setDestPort PortHole Partlcle Block objects send and receive 1mt1a112e readType data encapsulated in particles to 39recigeata0 print outside world through PortHoles sen a a0 39Operator 0 Bu ering by Geodesic clone Mahapatra Texas AampMSpr1ng 03 15 Garbage Collection Plasma Heterogeneous cosimulation Ptolemy Any model can be used at the top of hierarchy Within each level of hierarchy it is possible to have Blocks containing foreign domain Hierarchy heterogeneity is quite different from the concept of a simulation backplane that imposes a toplevel models of computation through Which all subsystem interact Active objects in a Domain are Stars They perform computation and communications With other objects through PortHoles Mahapatra Texas AampM Spring 03 l 6


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Jennifer McGill UCSF Med School

"Selling my MCAT study guides and notes has been a great source of side revenue while I'm in school. Some months I'm making over $500! Plus, it makes me happy knowing that I'm helping future med students with their MCAT."

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.