Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Understanding ASM Modeling Assumptions in Digital VLSI Design using flowHDL, Study notes of Computer Science

An overview of algorithmic state machine (asm) modeling assumptions in digital vlsi design using flowhdl. It covers the concepts of modeling the control path as a finite state machine (fsm) and the data path operations using register transfer notation (rtn). The document also explains the underlying assumptions about timing behavior based on registered or non-registered elements in the data path. The result is the ability to construct architectures easily from abstract system models.

Typology: Study notes

Pre 2010

Uploaded on 09/02/2009

koofers-user-j4g
koofers-user-j4g 🇺🇸

10 documents

1 / 16

Toggle sidebar

Related documents


Partial preview of the text

Download Understanding ASM Modeling Assumptions in Digital VLSI Design using flowHDL and more Study notes Computer Science in PDF only on Docsity! 2002/9/30 Fall 2002 - Lecture 16 Digital VLSI Design Methods-3 ASM Modeling Assumptions © 2002 Dr. James P. Davis CSCE 491 Computer Engr. Design Project Page 2© 2002 Dr. James P. Davis Lecture 16 - Outline Objective: To gain comprehensive enough understanding of Algorithmic State Machine notation in order to use it to create VLSI systems architecture. Means: Modeling the control path as a Finite State Machine (FSM). Modeling the data path operations using the Register Transfer Notation (RTN). Applying the underlying assumptions about timing behavior based on whether we use registered or non-registered elements in the data path. Registered elements have a one-cycle delay from when they are scheduled in the FSM and when the result appears on the output of data path registers. Assuming “unit delay” in the scheduling of data path operations from the control path of the state machine. Result: Construct architectures easily from abstract system models from UML, where these models are “cycle accurate”, not necessarily accurate in terms of a set of specific VLSI circuit delays. Page 5© 2002 Dr. James P. Davis Composition of ASM Concepts-1 Flowdiagram_Model Thread 1..* Contains State_Block 1..* Contains State 1 Contains Binary_Condition 0..* Contains Case_Condition 0..* Contains Conditional_Output 0..* Contains A given register-transfer expression must appear on a State, Condit ion, Case, or Conditional_Output. However, it can appear on States and Conditional Outputs but , because of the syntax, cannot appear on states and conditional outputs AND on Conditions and Cases (because condition expressions are of a different syntax than Moore and Mealy assignments and assert ions). RTN_Expression 0..* 0..* Schedules 1 0..* Evaluates 1 0..* Evaluates 1..* 0..* Schedules Event_Spec 1..* Contains Bus Bus_Name : type = Text Contains 1..*1..* References 1..* Contains 1..* Clock_Spec 1 Contains 1..* Contains Contains Page 6© 2002 Dr. James P. Davis Composition of ASM Concepts-2 Bus_Width Width : type = Integer Bus_Element_Type Type : type = Enum Bus_Mode Mode : type = Enum Bus Bus_Name : type = Text 1 Has_Property 1 Has_Property 1 Has_Property Input Output Internal Bi-directional Register Latch Wire State 0..* 0..* State_Sequence +previous_state +next_state Page 7© 2002 Dr. James P. Davis Modeling Complex Macro-functions Using flowHDL's macro-function operators, it is possible to create complex datapath descriptions that are efficient, in terms of gate count and delay. A designer can "nest" macro primitives to create complex macro descriptions, which can then be sequenced by the state machine. The designer should take care to remember that (1) macro arguments should match, in terms of bus width, signal type and signal mode, (2) macros should not have an output argument fed back as an input without proper buffering, and (3) take care not to drive a bus as both registered and unregistered (as this causes a multi-drive error, unless using MVL data types with resolution tables). s1 bBus <- nmux(add(a,b), add(a,c), or(band(xnor('b00,cmp(b, 'd1'))),d) Page 10© 2002 Dr. James P. Davis Carry/Borrow Bit with Arithmetic Macro-functions Page 11© 2002 Dr. James P. Davis Eliminating Latches in Asynchronous Datapath Page 12© 2002 Dr. James P. Davis Using the Asynchronous Reset flowHDL provides a pre-defined "Reset" signal. Reset generally defines the power-up or re-start event, on which most of the synchronous register elements are tied. It is defined asynchronous to the clock, in that it can occur at any time, and does not require synchronization before the system is to respond to the event. Reset has some specific "pulse and hold" behavior, in that the signal is asserted or de-asserted for a certain amount of time (i.e., pulsed) before being held. During the time that the signal is in its "hold" state, the execution of the circuit is enabled. When the signal is next pulsed, the system immediately aborts its current machine cycle and transfers control to the associated Reset state. The designer would typically use Reset to initialize each flowdiagram "thread" in a concurrent system description. Note that only one Reset can be used in a given flowdiagram thread, through each concurrent thread may have a Reset event defined. Page 15© 2002 Dr. James P. Davis Enable Events for Synchronization ^RES CLK (rising) C1 <- '1' AS1 <- '1' AS1 <- '0' C1 <- ^C1 Thread 1 AS1 C1 (rising) C2 <- '1' AS2 <- '0' AS2 <- '1' C2 <- ^C2 Thread 2 ^AS2 C2 (falling) ASSERT_1 Thread 3 !ASSERT_2 s0 s1 s6 s2 s3 s8 s4 s5 s7 Modeling Concurrency: - Multiple model FSM "threads" having shared buses. - Independent clocking schemes and enabling events (e.g., ^RES). - Types of concurrent interaction: I. Synchronization - coordinated activities (e.g., handshaking, pipelining). - implicit references to shared buses. II. Competition - shared resources (for example, bus arbitration). - explicit use of other concurrent processes, components, or entities to model the arbitration protocol. Page 16© 2002 Dr. James P. Davis ASM Design Method Using flowHDL
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved