Hardwareand Petri nets

1 Hardware and Petri nets Alex Yakovlev Univ. Newcastle upon Tyne Advanced Course on Petri nets, Eichstätt, 24-26 Sept, 2003 Contents and schedule of lectures • Introduction (Wednesday,10:30-10:45) • Hardware modelling with Petri nets (Wednesday,10:45-12:00) • Circuit Synthesis (Thursday 10:30-12:00): – Direct synthesis of Petri nets (Thursday, 10:30-11:15) – Logic synthesis from STGs (Thursday, 11:15-12:00) • Analysis and verification (Friday, 10:30-11:15) • Performance analysis (Friday, 11:15-12:00) Main bib references • A.V. Yakovlev, A.M.Koelmans. Petri nets and digital hardware design, Lectures on Petri nets II: Applications, Advances in Petri Nets, LNCS vol. 1492, Springer 1998, pp. 154-236 • A. Kondratyev, M. Kishinevsky, A. Taubin, J. Cortadella, L. Lavagno. The use of Petri nets for the design and verification of asynchronous circuits and systems, Jour. Cir.,Syst. And Comp., vol.8, no.1, Feb 1998, pp. 67-118. • Hardware Design and Petri Nets (Editors: A. Yakovlev, L. Gomes, L. Lavagno), Kluwer Academic Publishers, March 2000, ISBN 0-7923- 7791-5, 344 pp • J. Cortadella, M. Kishinevsky, A. Kondratyev, L. Lavagno and A. Yakovlev, Logic Synthesis of Asynchronous Controllers and Interfaces, Springer, March 2002, ISBN3-540-43152-7 • Hardware Design and Concurrency, Advances in Petri nets, LNCS vol. 2549, Springer, ISBN 3-540-00199-9, 345pp. Hardware and Petri Nets: Introduction Alex Yakovlev Univ. Newcastle upon Tyne Advanced Course on Petri nets, Eichstätt, 24-26 Sept, 2003 Introduction. Outline • Role of Hardware in modern systems • Role of Hardware design tools • Role of a modeling language • Why Petri nets are good for Hardware Design • History of “relationship” between Hardware Design and Petri nets • Asynchronous Circuit Design Role of Hardware in modern systems • Technology allows putting 1 billion transistors on a chip • System on Chip is a reality – 1 billion operations per second • Hardware and software designs are no longer separate • Hardware becomes distributed, asynchronous and concurrent 2 Role of Hardware design tools • Design productivity is a problem due to chip complexity and time to market demands • Need for well-integrated CAD with simulation, synthesis, verification and testing tools • Modelling of system behaviour at all levels of abstraction with feedback to the designer • Design re-use is a must but with max technology independence Int. Technology Roadmap for Semiconductors says: • 2010 will bring a system-on-a-chip with: – 4 billion 50-nanometer transistors, run at 10GHz – Moore’s law: steady growth at 60% in the number of transistors per chip per year as the functionality of a chip doubles every 1.5-2 years. • Technology troubles: process parameter variation, power dissipation (IBM S/390 chip operation PICA video), clock distribution etc. present new challenges for Design and Test • But the biggest threat of all is design cost Design productivity gap A design team of 1000 working for 3 years on a MPU chip would cost some $1B (25% time spent on verification, 45% on redesign after first silicon) Role of Modelling Language • Design methods and tools require good modelling and specification techniques • Those must be formal and rigorous and easy to comprehend (cf. timing diagrams, waveforms, traditionally used by logic designers) • Today’s hardware description languages allow high level of abstraction • Models must allow for equivalence-preserving refinements • They must allow for non-functional qualities such as speed, size and power Why Petri nets are good for hardware design • Finite State Machine is still the main formal tool in hardware design but it may be inadequate for distributed, concurrent and asynchronous hardware • Petri nets: – simple and easy to understand graphical capture – modelling power adjustable to various types of behaviour at different abstraction levels – formal operational semantics and verification of correctness (safety and liveness) properties – possibility of mechanical synthesis of circuits from net models A bit of history of their “marriage” • 1950’s and 60’s: Foundations (Muller & Bartky, Petri, Karp & Miller, …) • 1970’s: Toward Parellel Computations (MIT, Toulouse, St. Petersburg, Manchester …) • 1980’s: First progress in VLSI and CAD, Concurrency theory, Signal Transition Graphs (STGs) • 1990’s: First asynchronous design (verification and synthesis) tools: SIS, Forcage, Petrify • 2000’s: Powerful asynchronous design flow (incl. hardware-software codesign and system-on-chip design) 3 Introduction to Asynchronous Circuits • What is an asynchronous circuit? – Physical (analogue) level – Logical level – Speed-independent and delay-insensitive circuits • Why go asynchronous? • Why control logic? • Role of Petri nets • Asynchronous circuit design based on Petri nets What is an asynchronous circuit • No global clock; circuits are self-timed or self-clocked • Can be viewed as hardwired versions of parallel and distributed programs – statements are activated when their guards are true • No special run-time mechanism – the “program statements” are physical components: logic gates, memory latches, or hierarchical modules • Interconnections are also physical components: wires, busses Synchronous Design Register Sender Logic Register Receiver Clock Data Data input Clock T setup T hold Timing constraint: input data must stay unchanged within a setup/hold window around clock event. Otherwise, the latch may fail (e.g. metastability) Asynchronous Design Register Sender Logic Register Receiver Data Data input Req Req/Ack (local) signal handshake protocol instead of global clock Causal relationship Handshake signals implemented with completion detection in data path Ack(nowledge) Req(est) Ack Physical (Analogue) level • Strict view: an asynchronous circuit is a (analogue) dynamical system – e.g. to be described by differential equations • In most cases can be safely approximated by logic level (0-to-1 and 1-to-0 transitions) abstraction; even hazards can be captured • For some anomalous effects, such as metastability and oscillations, absolute need for analogue models • Analogue aspects are not considered in this tutorial Logical Level • Circuit behaviour is described by sequences of up (0-to- 1) and down (1-to-0) transitions on inputs and outputs • The order of transitions is defined by causal relationship, not by clock (a causes b, directly or transitively) • The order is partial if concurrency is present • Two prominent classes of async circuits: speed- independent (work for any gate delay variations) and delay-insensitive (for both gate and wire delays) • A class of async timed (not clocked!) circuits allows special timing order relations (a occurs before b, due to delay assumptions) 4 Simple circuit example req1 x y + req2 a b + req3 * C ack1 ack2 ack3 out out=(x+y)*(a+b) + + * x y a b out Data flow graph Control flow graph – Petri net req1 req2 ack1 ack2 req3 ack3 Muller C-element Key component in asynchronous circuit design – like a Petri net transition C x1 y x2 y=x1*x2+(x1+x2)y Set-part Reset-part It acts symmetrically for pairs of 0-1 and 1-0 transitions – waits for both input events to occur Muller C-element C x1 y x2 y=x1*x2+(x1+x2)y Set-part Reset-part Power Ground x1 x2 x2 x1 y NMOS circuit implementation Muller C-element (in CMOS) Vdd Gnd x1 x1 x1 x1x2 x2 x2 x2 y y y C x1 y x2 y=x1*x2+(x1+x2)y Set-part Reset-part Why asynchronous is good • Performance (work on actual, not max delays) • Robustness (operationally scalable; no clock distribution; important when gate-to-wire delay ratio changes) • Low Power (‘change-based’ computing – fewer signal transitions) • Low Electromagnetic Emission (more even power/frequency spectrum) • Modularity and re-use (parts designed independently; well-defined interfaces) • Testability (inherent self-checking via ack signals) Obstacles to Async Design • Design tool support – commercial design tools are aimed at clocked systems • Difficulty of production testing – production testing is heavily committed to use of clock • Aversion of majority of designers, trained ‘with clock’ – biggest obstacle • Overbalancing effect of periodic (every 10 years) ‘asynchronous euphoria’ 5 Why control logic • Customary in hardware design to separate control logic from datapath logic due to different design techniques • Control logic implements the control flow of a (possibly concurrent) algorithm • Datapath logic deals with operational part of the algorithms • Datapath operations may have their (lower level) control flow elements, so the distinction is relative • Examples of control-dominated logic: a bus interface adapter, an arbiter, or a modulo-N counter • Their behaviour is a combination of partial orders of signal events • Examples of data-dominated logic are: a register bank or an arithmetic-logic unit (ALU) Role of Petri Nets • We concentrate here on control logic • Control logic is behaviourally more diverse than data path • Petri nets capture causality and concurrency between signalling events, deterministic and non-deterministic choice in the circuit and its environment • They allow: – composition of labelled PNs (transition or place sync/tion) – refinement of event annotation (from abstract operations down to signal transitions) – use of observational equivalence (lambda-events) – clear link with state-transition models in both directions Design flow with Petri nets High-level languages (VHDL, CSP, …) Transition systems Predicates on traces Abstract behavioural model Labelled Petri nets (LPNs) Signalling refinement Timing diagrams Logic behavioural model Signal Transition Graphs (STGs) Syntax-direct translation (deriving circuit structure) STG-based logic synthesis (deriving boolean functions) Library cells Circuit netlist Decomposition and gate mapping Verification and Performance analysis Abstract behaviour synthesis Hardware and Petri Nets: Modelling Alex Yakovlev Univ. Newcastle upon Tyne Advanced Course on Petri nets, Eichstätt, 24-26 Sept, 2003 Modelling.Outline • High level modelling and abstract refinement; processor example • Low level modelling and logic synthesis; interface controller example • Modelling of logic circuits: event-driven and level-driven parts • Properties analysed High-level modelling:Processor Example Instruction Fetch Instruction Execution Program Counter Update Memory Address Register Load Memory Read Instruction Register Load Two-word Instruction Decode Two-word Instruction Execute One-word Instruction Decode One-word Instruction Execute 6 High-level modelling:Processor Example • Details of further refinement, circuit implementation (by direct translation) and performance estimation (using UltraSan) are in: A. Semenov, A.M. Koelmans, L.Lloyd and A. Yakovlev. Designing an asynchronous processor using Petri Nets, IEEE Micro, 17(2):54- 64, March 1997 • For use of Coloured Petri net models and use of Design/CPN in processor modelling: F.Burns, A.M. Koelmans and A. Yakovlev. Analysing superscalar processor architectures with coloured Petri nets, Int. Journal on Software Tools for Technology Transfer, vol.2, no.2, Dec. 1998, pp. 182-191. Using Coloured Petri nets in IR PC Value Value 1'fetch [#no fetch = pc] 1'fetch 1'fetch Count 1'(no=1,instr=INT,d=0,d'=0,t=0)+ 1'pc 1'(pc+1) FETCH @+1 1'1 Color Set: color Instr = with INT | FPADD | MUL | DIV | BRA | NULL; color Line = int; color Dep = int;color Target = int; color Count = int timed; colour Value = record no:Line*instr:Instr*d:Dep*d':Dep*t:Target timed; Var Set: var fetch : Value; var pc : Count 1'(no=2,instr=MUL,d=1,d'=0,t=0)+ 1'(no=3,instr=DIV,d=0,d'=0,t=0)+ Using Coloured Petri nets FETC H [#no fetch = i] @+ 1 C if ti me()<2 then i d_:=0 el se (); if ti me()<2 then pred :=8 else (); if ad r<>0 the n pred := ! id_ el se(); if #i nstr fetc h=BRA o relse ad r<>0 then i nc(id_) el se (); ! id_ mod 5; IR Value in Value 1`{no=1,id_=0,instr=IN T,d=0,d'=0,t=0}+ 1`{no=2,id_=0,instr=IN T,d=0,d'=1,t=0}+ 1`{no=4,id_=0,instr=DI V,d=2,d'=0, t=2}+ 1`{no=5,id_=0,instr=IN T,d=1,d'=0,t=3}+ 1`{no=6,id_=0,instr=IN T,d=0,d'=0,t=0}+ PC C ou nt 1` 1 c o l o r B i t = b o o l w i t h ( n , y ) ; c o l o r C o u n t = i n t t i m e d ; c o l o r L i n e = i n t ; c o l o r I n s t r = w i t h I N T | F P A D D | M U L | D I V | B R A | N U L L ; c o l o r D e p = i n t ; c o l o r W A W = i n t ; c o l o r B r a = u n i o n n o _ : L i n e + t a : L i n e + b : B i t ; c o l o r B P U = u n i o n n o : L i n e + t : L i n e ; D E C O D E @ + 1 [ i f # i n s t r d e c o d e < > B R A t h e n # t d e c o d e = # n o w b e l s e t r u e ] w i n d V a l u e D I V @+ 2 4 e x o u t V a l u e D M E M @+ 1 w b V a l u e WB @+ 1 C i n p u t w b ; o u t p u t k ; a c t i o n i f # n o w b = 1 0 t h e n w r i t e _ r e p o r t ( " \ n i n s t r / c y c l e = " ^ m a k e s t r i n g ( r e a l ( # n o wb ) / r e a l ( t i m e ( ) - 4 ) ) ^ " \ n T i me = " ^ ma k e s t r i n g ( t i m e ( ) + 1 ) ) e l s e ( ) ; i f ! p r e d = # i d _ w b t h e n 1 e l s e 0 ; s t a l l V a l u e 4 ` { n o = 0 , i d _ = 0 , i n s t r = I NT , d = 0 , d ' = 0 , t = 0 } F P A D D H S N e w # 2 c o n t - Out o f Ord er/ Centr al Wind/ Branch Pred stall B r a 1` b (y) MU L H S N ew # 4 co n t - >r es IN T [( #i ns t r ex ec u te =IN T o re ls e #i n st r ex ec u te =B R A) an d al s o #d e x ec ut e = # n o w b a nd a ls o #d ' ex ec u te = #n o w b ] @ + 1 C in p u t ex ec u te ; o u tp u t (b r a, ad r, b ra n ch ) ; ac ti o n if t im e () < 3 t h en r := 0 e l se (); if # in s tr ex ecu t e = B R A th en in c (r ) el s e ( ); if # in s tr ex ecu t e = B R A an d al so co n t In s tr 4` NU L L 1 C o un t 1` 1 b p u B PU 1` n o (0)+ 1`t (0) B PU @ + 1 1` fe tc h [a d r =0] / u p d f(p , fe tc h ) 1` i 1` d eco d e d ec o d e ex ec u te 1` exe c ut e 1` d m em 1` d m em 1` wb if a d r <> 0 th en 1`a d r el se i f #i n st r fe tc h =B R A a n da ls o # n o fe tc h =b p u th e n 1` (#t f etc h ) els e 1` (i+ n o fe tch ) [k =0 ]/ 4`w b w b w b 1` in s t 1` IN T 1 [b r an c h =y ]/ (1 `n o _(b r a)+ 1`t a(a d r) +1 `b (y )) 1` n o (b p u) +1` t(a d r) 1` n o (b p u) +1` t(0 ) 1` fe tch 1` b (y ) 1` n o( b ra )+1 `t(a d r) i f br <> b ra t h en 1` n o (b r) +1` t(a d) el s e 1`n o (0 )+1 `t(a d ) 1` n o _(b r )+1 `ta (ad ) 1 `b (y ) Low-level modelling: “lazy token” ring adaptor Client 1 Adaptor 1 Client 2 Client 1 Adaptor 1 Adaptor 1 R G D G D G D R R Low-level modelling: “lazy token” ring adaptor Client 1 Adaptor 1 Client 2 Client 1 Adaptor 1 Adaptor 1 R G D G D G D R R Rr Lr La Ra Lazy ring adaptor Lr dum dum R Ra Rr La G D t=0 t=1 Ring adaptor R G D Ra Rr La Lr t=0 (token isn’t initially here) 7 Lazy ring adaptor Lr dum dum R Ra Rr La G D t=0 t=1 Ring adaptor R G D Ra Rr La Lr t=0->1->0 (token must be taken from the right and past to the left Lazy ring adaptor Lr dum dum R Ra Rr La G D t=0 t=1 Ring adaptor R G D Ra Rr La Lr t=1 (token is already here) Lazy ring adaptor Lr dum dum R Ra Rr La G D t=0 t=1 Ring adaptor R G D Ra Rr La Lr t=0->1 (token must be taken from the right) Lazy ring adaptor Lr dum dum R Ra Rr La G D t=0 t=1 Ring adaptor R G D Ra Rr La Lr t=1 (token is here) Logic Circuit Modelling Event-driven elements Petri net equivalents C Muller C- element Toggle Logic Circuit Modelling Level-driven elements Petri net equivalents NAND gate x(=1) y(=1) z(=0) NOT gate x(=1) y(=0) x=0 x=1 y=0 y=1 b x=0 x=1 z=0 z=1 y=0 y=1 8 Logic Circuit Modelling: examples Pipeline data Stage Data In Data Out Pipeline control Stage Rin Ain Rout Aout Data Enable Pipeline control must guarantee: •Handshake protocols between the stages •Safe propagation of the previous datum before the next one Event-driven circuit C C C1 XOR I1 I4 C2 Toggle I3 I2 Rin Aout Aout Rout Ain Rin Rout Ain fast-fwd option Level-driven circuit I2- C1+ I2+ C1- C1=1 C1=0 n_Ain/Rin y1 I2=1 C2- I1- n_y2 C2+ I2=0 Rout I1+ C2=1 I1=0 I1=1 C2=0 Rin En y1 Rout I2 C2 C1 I1 y2 n_Aout n_Ain C1: y1 = Rin {y2} + y1(Rin + n_Aout + y2) C2: n_y2 = y1 (n_Aout + n_y2) I1: n_Ain = y1' I1: Rout = y2' or Rout = delay (n_y2) Level-driven circuit I2- C1+ I2+ C1- C1=1 C1=0 n_Ain/Rin y1 I2=1 C2- I1- n_y2 C2+ I2=0 Rout I1+ C2=1 I1=0 I1=1 C2=0 Rin En y1 Rout I2 C2 C1 I1 y2 n_Aout n_Ain C1: y1 = Rin {y2} + y1(Rin + n_Aout + y2) C2: n_y2 = y1 (n_Aout + n_y2) I1: n_Ain = y1' I1: Rout = y2' or Rout = delay (n_y2) Set-part Level-driven circuit I2- C1+ I2+ C1- C1=1 C1=0 n_Ain/Rin y1 I2=1 C2- I1- n_y2 C2+ I2=0 Rout I1+ C2=1 I1=0 I1=1 C2=0 Rin En y1 Rout I2 C2 C1 I1 y2 n_Aout n_Ain C1: y1 = Rin {y2} + y1(Rin + n_Aout + y2) C2: n_y2 = y1 (n_Aout + n_y2) I1: n_Ain = y1' I1: Rout = y2' or Rout = delay (n_y2) Reset-part Level-driven circuit I2- C1+ I2+ C1- C1=1 C1=0 n_Ain/Rin y1 I2=1 C2 - I1- n_y2 C2 + I2=0 Rout I1+ C2 =1 I1=0 I1=1 C2 =0 Rin En y1 Rout I2 C2 C1 I1 y2 n_Aout n_Ain C1: y1 = Rin {y2} + y1(Rin + n_Aout + y2) C2: n_y2 = y1 (n_Aout + n_y2) I1: n_Ain = y1' I1: Rout = y2' or Rout = delay (n_y2) Without y2 in Set part of y1 this trace can happen: I2+ C1+ I2- C2+ I1+ C1- I2+ C2- C1+ 9 Level-driven circuit I2- C1+ I2+ C1- C1=1 C1=0 n_Ain/Rin y1 I2=1 C2- I1- n_y2 C2+ I2=0 Rout I1+ C2=1 I1=0 I1=1 C2=0 Rin En y1 Rout I2 C2 C1 I1 y2 n_Aout n_Ain C1: y1 = Rin {y2} + y1(Rin + n_Aout + y2) C2: n_y2 = y1 (n_Aout + n_y2) I1: n_Ain = y1' I1: Rout = y2' or Rout = delay (n_y2) Without y2 in Set part of y1 this trace can happen: I2+ C1+ I2- C2+ I1+ C1- I2+ C2- disabling C1+ Properties analysed • Functional correctness (need to model environment) • Deadlocks • Hazards: – non-1-safeness for event-based – non-persistency for level-based • Timing constraints – Absolute (need Time(d) Petri nets) – Relative (compose with a PN model of order conditions) More about this in the Verification Part How adequate is PN model? • Petri nets have events with atomic action semantics • Asynchronous circuits may exhibit behaviour that does not fit within this domain – due to inertia 0* 0* 0->1 0->1 a b a b a b 00 01 11 10 Petri Nets versus Circuits x- y+ AND x y 1->0 0* 1 p1 p2 p3 p1 p2 p3 x- y+ y+ y+ disabled (no memory of past) x y z z with large inertial (RC) delay Race between x- and y+ causes nondeterministic behaviour on y: (1) Either there is a 0-1-0 pulse (2) Or nothing switching threshold Request-Grant-Done (RGD) arbiter C C mutex r1 g2 g1 r2 R1 R2 G2 D2 G1 D1 Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 10 Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 mutex r1 g2 g1 r2 (locally optimised model) Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 C Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 Interface from event-based part to level-based part Request-Grant-Done (RGD) arbiter r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 Interface from level-based part to event-based part Request-Grant-Done (RGD) arbiter with environment r1- r1=0 r1=1 r1+ g1- g1=0 g1=1 g1+ r2- r2=0 r2=1 r2+ g2- g2=0 g2=1 g2+ me R1 R2 D2 G2 G1 D1 Private section 1 Private section 2 Critical section 1 Critical section 2 [...]... modelling is crucial • Refinement of Petri net models and interpretation can be used in hardware design • Petri nets are too abstract to capture analogue phenomena in circuits • However, non-persistence or non-safeness can (conservatively) approximate the possibility of hazards Hardware and Petri Nets: Synthesis Alex Yakovlev Univ Newcastle upon Tyne Advanced Course on Petri nets, Eichstätt, 24-26 Sept, 2003... with logic synthesis 26 Hardware and Petri Nets: Verification of Asynchronous Circuits using Partial Order Techniques Alex Yakovlev Univ Newcastle upon Tyne Outline • Representing Petri net semantics with occurrence nets (unfoldings) • Unfolding (finite) prefix construction • Analysis of asynchronous circuits • Problems with efficient unfolding Advanced Course on Petri nets, Eichstätt, 24-26 Sept, 2003... FIFO buffers) 1-safe net (using EVR’s cutoff) Unfolding k-safe Nets (3) Unfolding the original, unrefined net with FIFO semantics 34 Unfolding k-safe Nets Unfolding k-safe Nets Buffer Buffer size k-bounded net with Mcmillan's unfolding Original Unfolding time( (t/p) s) safe nets using ERV's algorithm FIFO-unfolding with McMillan's safe nets using ERV's algorithm size Original Unfolding (t/p) 8/14 time(s... construction Unfolding Petri net and its unfolding p1 Petri net t1 p2 p1 t2 p3 p4 t4 t5 p7 p6 p2 p7 p4 t7 p5 t6 t5 t4 p7 p6 t3 p4 t3 p1 t4 t5 t1 t2 p3 p4 p5 t4 t5 t6 p2 t3 p4 p5 t4 t5 t6 p6 p7 p5 t6 t7 t1 p2 p3 p3 t3 p2 p1 t3 t2 t2 t1 p2 t2 p3 p1 cut t1 t6 p6 marking p5 t3 p1 t1 p1 p1 p7 p6 t2 p3 p4 t4 t5 p7 p6 p5 t6 t7 t7 t7 p6 p7 … p7 … Petri net and its unfolding p1 marking Petri net and its unfolding... theory of binary covers on unfolding segments (Kondratyev et.al.) 0.07 0.11 0.12 0.17 0.51 0.12 0.37 2.87 0.07 Event-driven elements Petri net equivalents C Muller Celement … 6.13 Toggle 32 Experimental results (from Kondratyev) Analysis of Circuit Petri Nets example • Petri net models built for event-based and level-based elements, together with the models of the environment can be analysed using the... in ordinary P/T nets x=0 Prefix #places 100 2.20E+13 none 3091 10 200 2.90E+19 none 251839 455 250 too many none 1870847 >4hrs 300 too many none none none 60 6.00E+07 7897 4784 132 90 6.90E+11 23590 10634 740 120 8.40E+15 53446 18788 3210 80 2.20E+07 1688 1688 11 160 4.50E+13 6568 6568 101 240 7.00E+19 14648 14648 342 n_Aout Rin x(=1) BDD peak size final size time Circuit Petri nets Petri net equivalents... elements #states p4 Unfolding k-safe nets • How to cope with k-safe (k>1) nets and their redundancy • Such nets are extremely useful in modelling various hardware components with: – Buffers of finite capacity – Counters of finite modulo count • McMillan’s cutoff condition is too strong (already much redundancy) • EVR’s condition is too weak – cannot be applied to ksafe nets Proposed solution: introduce... semantics Unfolding k-safe Nets Unfolding k-safe Nets Approach (2) for refining FIFO places into 1-safe subnets (1) Direct unfolding prefix (using McMillan’s cutoff) k-size buffer xcp1 f1 f(k-1) f2 fk ••• xf xct1 ct1 ft(k-1) ft1 ••• cp1 n consumers xf2 xf1 pp xfk xf(k-1) pt xpt xcpn e2 e1 e(k-1) ek xpp ••• et1 xctn et(k-1) ctn cpn ••• xe1 xe2 xe(k-1) xek Unfolding k-safe Nets (2) Unfolding the explicitly... appropriate refinements have been made one can translate Labelled Petri nets (or Signal Transition Graphs) into circuits • Either by syntax-direct translation (discussed below) • Or by using Logic Synthesis (discussed later) b a and b are protected now (they are no longer disabled) 19 Why direct translation? Direct Translation of Petri Nets • Direct translation has linear complexity but can be area inefficient... tokens in ksafe nets or split self-loops) and thus spawn too many branches in history • Other forms of unfolding can be studied (e.g nonaggressive unfolding of places – building DAGs instead of branching processes) • Unfoldings have also been used to analyse nets with time annotation and for synthesis of circuits but these are hot research topics – Haway the lads! Hardware and Petri Nets: Performance