-
Notifications
You must be signed in to change notification settings - Fork 149
/
all.bib
6471 lines (5900 loc) · 223 KB
/
all.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
@string{ASPLOS={Proceedings of the Architectural Support for Programming Languages and Operating Systems (ASPLOS)}}
@string{ECOOP={Proceedings of the European Conference on Object-oriented Programming (ECOOP)}}
@string{POPL={Proceedings of the Symposium on Principles of Programming languages (POPL)}}
@string{OOPSLA={Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA)}}
@string{PLDI={Proceedings of the Conference on Programming Language Design and Implementation (PLDI)}}
@string{DAC={Proceedings of the Design Automation Conference (DAC)}}
@string{DATE={Proceedings of the Design Automation and Test in Europe (DATE)}}
@string{CODES={Proceedings of the International Symposium on Hardware/Software Codesign (CODES)}}
@string{ICASSP={Proceedings of the International Conference on Acoustics, Speech and Signal Processing (ICASSP)}}
@string{ICVS={Proceedings of the International Conference on Vision Systems (ICVS)}}
@string{ASILOMAR={Proceedings of the Asilomar Conference on Circuits, Signals and Systems}}
@string{CDC={Proceedings of the Conference on Decision and Control (CDC)}}
@string{ICCAD={Proceedings of the International Conference on Computer Aided Design (ICCAD)}}
@string{EMSOFTW={Proceedings of the International Workshop on Embedded Software (EMSOFT)}}
@string{IFIPCONGRESS={Proceedings of the IFIP Congress}}
@string{MEMOCODE={Proceedings of the Conference on Methods and Models for Codesign (MEMOCODE)}}
@string{RSP={Proceedings of the International Workshop on Rapid System Prototyping (RSP)}}
@string{SAS={Proceedings of the Static Analysis Symposium (SAS)}}
@string{HSCC={Proceedings of the International Workshop on Hybrid Systems: Computation and Control (HSCC)}}
@string{FPL={Proceedings of the International Field Programmable Logic and Applications Conference (FPL)}}
@string{FPGA={Proceedings of the International Symposium on Field Programmable Gate Arrays (FPGA)}}
@string{FPT={Proceedings of the International Conference on Field-Programmable Technology (FPT)}}
@string{FCCM={Proceedinds of the International Symposium on Field-Programmable Custom Computing Machines (FCCM)}}
@string{ASAP={Proceedings of the International Conference on Application-specific Systems, Architectures and Processors (ASAP)}}
@string{CASES={Proceedings of International Conference on Compilers, Architecture, and Synthesis for Embedded Systems(CASES)}}
@string{IEEETASSP={IEEE Transactions on Acoustics, Speech, and Signal Processing (TASSP)}}
@string{IEEETC={IEEE Transactions on Computers}}
@string{IEEEDTC={IEEE Design and Test of Computers}}
@string{IEEETCAD={IEEE Transactions on Computer-aided Design of Integrated Circuits and Systems (TCAD)}}
@string{IEEETVLSI={IEEE Transactions on Very Large Scale Integration (VLSI)}}
@string{CACM={Communications of the ACM}}
@string{COMPUTER={IEEE Computer}}
@string{SCP={Science of Computer Programming}}
@string{ACMTODAES={ACM Transactions on Design Automation of Electronic Systems (TODAES)}}
@string{ACMTRETS={ACM Transactions on Reconfigurable Technology and Systems (TRETS)}}
@string{SPRINGER={Springer-Verlag}}
@string{KLUWER={Kluwer}}
@string{IFIP={International Federation for Information Processing}}
@string{AW={Addison-Wesley}}
@string{PH={Prentice-Hall}}
@string{NH={North-Holland}}
@string{MIT={MIT Press}}
@string{MK={Morgan Kaufmann}}
@string{LNCS={Lecture Notes in Computer Science}}
@string{OREILLY={O'Reilly}}
@string{ELSEVIER={Elsevier}}
@string{IEEE={IEEE}}
@string{ACM={ACM}}
% For EECS thesis
@string{EECS={EECS Department, University of California at Berkeley, CA}}
% For ERL memos
@string{ERL={Electronics Research Lab, Department of Electrical
Engineering and Computer Sciences}}
@string{MEMO={Technical Memorandum}}
@string{TR={Technical Report}}
@string{UCB={University of California Berkeley, CA 94720, USA}}
@manual{Almagest94,
title = {The {A}lmagest: {P}tolemy User's Manual Version 0.5},
year = {1994},
key = {University of California},
organization = ERL
}
@article{Andrews93,
author = {Warren Andrews},
title = {Search Continues for a Single, Best Approach to
{DSP} Interfacing},
journal = {Computer Design},
year = {1993},
pages = {55--64},
month = jul
}
@TechReport{Antares,
author = {The ANTARES Collaboration},
title = {A Deep Sea Telescope for High Energy Neutrinos},
institution = {DAPNIA},
number = {99-01},
year = 1999,
type = {Technical Proposal},
month = mar,
day = 31
}
@inproceedings{BarreraLee91,
author = {Brian Barrera and Edward A. Lee},
title = {Multirate Signal Processing in {C}omdisco's {SPW}},
booktitle = ICASSP,
pages = {1113--1116},
year = 1991,
month = may
}
@inproceedings{ChoLiu91,
author = {King-Wai Chow and Bede Liu},
title = {On Mapping Signal Processing Algorithms to a
Heterogenous Multiprocessor System},
booktitle = ICASSP,
year = {1991},
organization = IEEE,
pages = {1585--1588},
keywords = {parallel-dsp scheduling}
}
@phdthesis{Ha92,
author = {Soonhoi Ha},
title = {Compile-Time Scheduling of Dataflow Program Graphs
with Dynamic Constructs},
school = EECS,
month = apr,
year = {1992}
}
@article{Marrin93,
author = {Ken Marrin},
title = {{DSP} Development Tools Engage Mainstream Designers},
journal = {Computer Design},
year = {1993},
pages = {65--74},
month = jan
}
@article{Messerschmitt84,
author = {David G. Messerschmitt},
title = {A Tool for Structured Functional Simulation},
journal = {IEEE Trans. on Special Topics in Communications},
month = jan,
year = {1984}
}
@inproceedings{Messerschmitt84a,
author = {David G. Messerschmitt},
title = {Structured Interconnection of Simulation Programs},
booktitle = {GlobeComm 84},
year = {1984},
pages = {808--811}
}
@techreport{Meyer94,
author = {Matthias Meyer},
title = {A Pilot Implementation of the Host-Engine Software
Architecture for Parallel Digital Signal Processing},
year = {1994},
month = nov,
institution = {School of Electrical Engineering, University of
Technology Sydney, and Technical University
Hamburg-Harburg},
note = {FTP from {\tt ftp.ee.uts.edu.au} as {\tt
/pub/DSP/papers/spook.ps.gz}}
}
@InProceedings{Nestor,
author = {B. Monteleoni},
title = {{NESTOR} a deep sea physics laboratory for the
{Mediterranean}},
booktitle = {Proceeding of the International conference on
Neutrino Physics and Astrophysics (NEUTRINO)},
year = 1996,
address = {Helsinki, Finland},
month = jun,
day = {16-19}
}
@article{OwickiGries,
author = {Susan Owicki and David Gries},
title = {An Axiomatic Proof Technique for Parallel Programs
{I}},
journal = {Acta Informatica},
year = "1976",
volume = "6",
pages = "319-340",
publisher = SPRINGER
}
@inproceedings{Pino++94,
author = {Jose Luis Pino and Thomas M. Parks and Edward
A. Lee},
title = {Mapping Multiple Independent Synchronous Dataflow
Graphs Onto Heterogeneous Multiprocessors},
booktitle = ASILOMAR,
month = nov,
year = {1994}
}
@inproceedings{Powell++92,
author = {Douglas B. Powell and Edward A. Lee and William
C. Newman},
title = {Direct Synthesis of Optimized {DSP} Assembly code
from Signal Flow Block Diagrams},
booktitle = ICASSP,
year = 1992,
pages = {V-553--V-556}
}
@inproceedings{Ptolemy91,
author = {Joseph Buck and Soonhoi Ha and Edward A. Lee and
David G. Messerschmitt},
title = {Multirate Signal Processing in {P}tolemy},
booktitle = ICASSP,
year = {1991},
keywords = {lgdf sdf gabriel ptolemy}
}
@techreport{Reekie87,
author = {Hideki John Reekie},
title = {A Real-time Performance-Oriented Music Synthesiser},
year = {1987},
month = nov,
institution = {School of Electrical Engineering, University of
Technology, Sydney},
note = {Undergraduate thesis report}
}
@techreport{Reekie92,
title = {Towards Effective Programming for Parallel Digital
Signal Processing},
author = {H. John Reekie},
institution = {Key Centre for Advanced Computing Sciences,
University of Technology, Sydney},
year = {1992},
type = {Technical Report},
number = {92.1},
month = may
}
@inproceedings{Reekie92a,
author = {John Reekie},
title = {Integrating Block-Diagram and Textual Programming
for Parallel {DSP}},
booktitle = {Proc. 3rd Intl. Symp. on Signal Processing and its
Applications (ISSPA 92)},
year = {1992},
month = aug,
pages = {622--625}
}
@unpublished{Reekie93,
author = {H. John Reekie},
title = {Real-time {DSP} in {C} and Assembler},
year = {1993},
note = {FTP from {\tt ftp.ee.uts.edu.au} as {\tt
/pub/prose/c30course.ps.gz}}
}
@techreport{Reekie94,
title = {Modelling Asynchronous Streams in {H}askell},
author = {H. John Reekie},
institution = {Key Centre for Advanced Computing Sciences,
University of Technology, Sydney},
year = {1994},
type = {Technical Report},
number = {94.3},
month = jun,
note = {FTP from {\tt ftp.ee.uts.edu.au} as {\tt
/pub/prose/async-streams.ps.gz}}
}
@techreport{Reekie94a,
title = {Visual {H}askell: A First Attempt},
author = {H. John Reekie},
institution = {Key Centre for Advanced Computing Sciences,
University of Technology, Sydney},
year = {1994},
type = {Technical Report},
number = {94.5},
month = aug,
note = {FTP from {\tt ftp.ee.uts.edu.au} as {\tt
/pub/prose/visual-haskell.ps.gz}}
}
@phdthesis{Reekie95,
author = {H. John Reekie},
title = {Realtime Signal Processing: Dataflow, Visual, and
Functional Programming},
year = 1995,
school = {School of Electrical Engineering, University of
Technology, Sydney}
}
@unpublished{Reekie9501,
author = {H. John Reekie},
title = {Some thoughts on ``higher-order dataflow''},
month = aug,
year = {1995},
note = {Unpublished memo}
}
@unpublished{Reekie9502,
author = {H. John Reekie},
title = {Cyclic Graphs and Dataflow Models},
month = sep,
year = {1995},
note = {Unpublished memo}
}
@inproceedings{ReekieMeyer94,
author = {H. John Reekie and Matthias Meyer},
title = {The Host-Engine Software Architecture for Parallel
Digital Signal Processing},
booktitle = {Proc. PART'94, Workshop on Parallel and Real-time
Systems, Melbourne, Australia},
year = {1994},
month = jul,
note = {FTP from {\tt ftp.ee.uts.edu.au} as {\tt
/pub/prose/host-engine.ps.gz}}
}
@inproceedings{ReekiePotter92,
author = {John Reekie and John Potter},
title = {Transforming Process Networks},
booktitle = {Proc. MFPW'92, the Massey Functional Programming
Workshop},
year = {1992},
organization = {Massey University},
address = {Palmerston North, New Zealand},
month = aug
}
@inproceedings{ReekiePotter93,
author = {John Reekie and John Potter},
title = {Process Network Transformation},
booktitle = {Parallel Computing and Transputers (PCAT-93)},
year = {1993},
publisher = {IOS Press},
pages = {376-383},
editor = {David Arnold},
month = nov
}
@inproceedings{ReekiePotter94,
author = {H. John Reekie and John M. Potter},
title = {Generating Efficient Loop Code for Programmable
DSPs},
booktitle = ICASSP,
year = 1994,
pages = {II-469--II-472},
organization = IEEE
}
@article{Rodet84,
author = {Xavier Rodet},
title = {Time-Domain Formant-Wave-Function Synthesis},
journal = {Computer Music Journal},
year = 1984,
volume = 8,
number = 3,
pages = {9--14}
}
@INCOLLECTION{SifakisCompositionHybrid:98,
author = {Sebastien Bornot and Joseph Sifakis},
title = {On the composition of hybrid systems},
booktitle = HSCC,
publisher = SPRINGER,
series = LNCS,
number = 1386,
month = apr,
year = 1998,
pages = {49-63}
}
@book{Stanley++84,
author = {W. D. Stanley and G. R. Dougherty and R. Dougherty},
title = {Digital Signal Processing},
publisher = {Reston Publishing},
year = {1984}
}
@manual{TMS320C30,
title = {TMS320C3x User's Guide},
organization = {Texas Instruments Inc.},
year = {1992},
note = {Literature number SPRU031C}
}
@manual{TMS320C40,
title = {TMS320C4x User's Guide},
organization = {Texas Instruments Inc.},
year = {1991},
note = {Literature number SPRU063}
}
@inproceedings{Verbauwhede++94,
author = {Ingrid M. Verbauwhede and Chris J. Scheers and Jan
M. Rabaey},
title = {Specification and Support for Multi-dimensional
{DSP} in the {S}ilage Language},
booktitle = ICASSP,
address = {Adelaide, Australia},
year = {1994},
pages = {II-473--II-476},
month = apr
}
@article{Verhulst94virtuoso,
author = {Eric Verhulst},
title = {Meeting the Parallel {DSP} Challenge with the
Real-Time {V}irtuoso Programming System},
journal = {DSP Applications},
year = {1994},
pages = {41--56},
month = jan
}
@article{Willekens94dataflow,
author = {Patrick Willekens and Dirk Devisch and Marc Van
Canneyt and Paul Conflitti and Dominique Genin},
title = {Algorithm Specification in {DSP} Station using
{D}ata {F}low {L}anguage},
journal = {DSP Applications},
year = {1994},
pages = {8--16},
month = jan
}
@Book{Wilson:Languages,
author = {Leslie B. Wilson and Robert G. Clark},
title = {Comparative Programming Languages},
publisher = AW,
year = 1993,
edition = {Second Edition}
}
@InProceedings{achermann01piccola,
author = {Franz Achermann and Oscar Nierstrasz},
title = {Applications = Components + Scripts : A Tour of
{Piccola}},
booktitle = {Software Architectures and Component Technology},
pages = {261--292},
year = 2001,
editor = {Mehmet Aksit},
publisher = KLUWER
}
@Book{agha86actors,
author = {Gul A. Agha},
title = {{ACTORS}: A Model of Concurrent Computation in
Distributed Systems},
publisher = MIT,
year = 1986,
series = {The MIT Press Series in Artificial Intelligence},
address = {Cambridge},
annote = {It is clear by the tone of this book that Agha seeks
to show that the actors model is a better model than
others that are available including synchronous
processes models (e.g., CSP and CCS) and functional
models (e.g., PN) among others. Agha speaks about
the advantages of expressiveness of a language but
he does not discuss the problems of
over-expressiveness. Agha places computational
elements of concurrent systems into three
categories: 1) sequential processes, 2) functions
transforming data values and 3) actors. Sequential
processes include CSP, CCS, Concurrent Pascal and
the Shared Variables model. Sequential processes are
defined by the fact that they consists of a sequence
of transformations on states. In addition, the
transformations may depend on inputs or produce
outputs. This dependency on inputs causes problems
for the denotational semantics of sequential
processes because of the possibility of
deadlock. Functions that transform data values
operate directly on data without the benefit of
state. Functional models are derived from
$\lambda$-calculus based languages such as Pure
Lisp. Concurrent systems based on functional models
include Kahn and MacQueen's network of parallel
processes and Agerwala and Arvind's dataflow
model. The concurrency in such systems is the
ability to evaluate arguments of a function in
parallel. Note that some would argue that functional
methods can indeed have state. In particular, Kahn's
PN, (as opposed to Kahn/MacQueen) which maps streams
to streams, maintains state while the stream is
being processed. Kahn does not make this clear but
this seems to be the argument that Edward
makes. Actors obey the following rules. Every
incoming communication is mapped to a 3-tuple
consisting: 1) a finite set of communications sent
to other actors. 2) a new behavior for the next
communication 3) a finite set of new actors
created. Agha makes two points. First he states that
actors maintain state. This is clear to me. Next he
states that there is no presumed sequentiality:
``mathematically each of its actions is a function
of the actor's behavior and the incoming
communication.'' The second point is not clear. At
the very least there must be sequentiality with
respect to the order of incoming
communications. Agha emphasizes that mutability that
is inherent in the actors model as it facilitates
dynamic topologies.}
}
@article{agha90concurrent,
author = {Gul Agha},
title = {Concurrent Object-Oriented Programming},
journal = CACM,
volume = 33,
number = 9,
month = sep,
year = 1990,
pages = {125--140}
}
@Article{agha93abstraction,
author = {Agha, G. and Frolund, S. and Kim, W.Y. and Panwar,
R. and Patterson, A. and Sturman, D.},
title = {Abstraction and modularity mechanisms for concurrent
computing },
journal = {IEEE Parallel and Distributed Technology: Systems
and Applications},
month = may,
year = 1993,
volume = 1,
number = 2,
pages = {3--14},
annote = {The syntactic description of actor-oriented design
is inspired by the work of Agha, although the
description of semantics is somewhat
different. Primarily, in Agha's model actors send
named messages to one another, whereas in our usage
actors do not know about other actors. Although this
might seem contradictory, the two views are
complementary. Agha concentrates on describing the
behavior or execution of a model, while we
concentrate on the specification of actors and
models. During execution of an actor-oriented model
the destination of every message is fixed when the
message is sent, even if the actor itself is not
aware of the destination. Another difference is that
Agha concentrates on }
}
@Article{agha97foundation,
author = {Agha, Gul and Ian A. Mason and Scott F.Smith and
Carolyn L. Talcott},
title = {A Foundation for Actor Computation},
journal = {Journal of Functional Programming},
volume = "7",
number = "1",
pages = "1-72",
year = "1997",
}
@book{aho85compiler,
author = {Alfred V. Aho and Ravi Sethi and Jeffrey D. Ullman},
title = {Compilers: Principles, Techniques, and Tools},
Publisher = AW,
year = {1985}
}
@Article{alberto02platforms,
author = {Alberto Sangiovanni-Vincentelli},
title = {Defining platform-based design},
journal = {EEDesign},
year = 2002,
month = feb
}
@incollection{alfaro01interfaces,
author = "Luca de Alfaro and Tom Henzinger",
title = "Interface theories for component-based design",
booktitle = EMSOFTW,
series = LNCS,
number = 2211,
publisher = SPRINGER,
year = 2001,
pages = "148--165"
}
@Article{allen97wright,
author = {Robert Allen and David Garlan},
title = {A Formal Basis for Architectural Connection},
journal = {ACM Transactions on Software Engineering and
Methodology},
year = 1997,
month = jul,
annote = {This paper is essentially about using a variant of
Tony Hoare's CSP to describe communication between
components. I was basically disappointed with this
paper because in using CSP in its foundation it
makes some serious assumptions. How do we use this
approach to describe asynchronous communication in a
succinct format? The paper begins with a
justification for the need to have an architectural
specification approach for describing connections
between components in a system. The paper began with
a discussion of the existence of several
specification languages for describing
implementation relationships but a lack of languages
for describing interaction relationships. The crux
of the architectural description approach (which
apparently is the basis for the {\em Wright system})
is the notion of a connector type. A connector type
is defined as a set of {\em roles} and a {\em glue}
specification. Each role describes the local
behavior of each interacting party that is connected
through the connector. The glue describes the
coordination of the activities of the roles. The
roles and glue are described using CSP semantics
with a few variations. The variations are largely
inconsequential from the perspective of
specification style. One key difference is the
notion of deterministic choice in addition to the
standard non-deterministic choice already found in
CSP. My problem is that this system relies too
heavily on CSP semantics. What about asychronous
systems? Is this really an efficient specification
approach?}
}
@InProceedings{alur94realtime,
author = {Rajeev Alur and Thomas A. Henzinger},
title = {Real-time System = Discrete System + Clock
Variables},
booktitle = {Theories and Experiences for Real-time System
Development},
year = 1994,
editor = {T. Rus and C. Rattray},
series = {AMAST Series in Computing 2},
publisher = {World Scientific},
pages = {1-29},
annote = { The paper provides a framework for formalizing real
time systems. The framework is referred to as the
``clock approach'' in which a system's variables are
partitioned into discrete variables and clock
variables. The paper introduced many terms that were
new to me. At the same time, I felt there were
subtle ambiguities (in some cases blatant errors) in
the examples that were used throughout the
paper. The combination of learning several new terms
in conjunction with errors made the paper
unnecessarily challenging in my opinion. The paper
begins with a good example of the need for
verification in the railroad-gate controller
example. They then describe the synchrony assumption
as a timing abstraction (where the environment speed
is much slower than the system
speed). Unfortunately, in their attempt to describe
Zeno behavior as a result of the synchrony
assumption, they appear to produce a critical error
in the water-level controller example (i.e., the
drain rate should be 3 liters/sec and the fill rate
should be 2 liters/sec). It builds up by describing
four types of systems: untimed, ... Untimed systems
consist of variables. States are simply functions
that map variables to values of a given type. A
transition is a pair of states (source and target
state). A {\em stutter transition} is one in which
the source state is identical to the target
state. Stutter transitions represent internal
behavior of a system that is not visible
externally. A behavior is a countable sequence of
states. Several assumptions are made about a system
and its environment. 1) In a finite interval of time
there are a finite number of transitions. (Note at
this point time had not been defined.) 2) A system
can not prevent an environment activity. 3) The
environment never terminates A behavior is
considered {\em environment fair} if it contains
infinitely many stutter transitions. Basically this
means that the environment can not prevent the {\em
eventual} internal execution of a system. A closed
discrete system, $S$, is a pair consisting of a
state predicate (initial condition) and a transition
predicate. A behavior, $\sigma$ satisfies $S$ if the
state predicate holds for $\sigma$ and the
transition predicate is invariant for $\sigma$. The
set of behaviors of a system satisfy 1) {\em stutter
closure} - removing or adding a stutter transition
to a possible behavior results in a possible
behavior 2) {\em fusion closure} - concatenation of
possible behavior at common states results in a
possible behavior 3) {\em limit closure} - if all
finite prefixes of the environment fair behavior,
$\bar{\sigma}$, are valid behaviors, then
$\bar{\sigma}$ is also a valid behavior. The
ramifications of the above closure properties are
that possible behaviors are determined one
transition at a time. Thus, a valid finite prefix
can be followed by an infinite sequence of stutter
transitions; i.e., a system need not progress. }
}
@InProceedings{alur96reactive,
author = {Rajeev Alur and Thomas A. Henzinger},
title = {Reactive Modules},
booktitle = {Proceedings of the 11th IEEE Symposium on Logic in
Computer Science},
year = 1996,
pages = {207-218},
annote = { This paper presents a formal modeling language for
reactive concurrent systems. Alur and Henzinger
define "Reactive Modules" which serve as a model of
components in a concurrent system. The framework can
model both synchronous and asynchronous behavior and
incorporates abstration and hiding operators to
facilitate the representation of a continuum between
these two notions. I am interested in this paper
because it applies the Assume-Guarantee and
Compositional assumptions. It also discusses
hierarchical proof techniques (stepwise
refinement). Consider hardware-software codesign and
verification of reactive systems. The design
requirements include: * The ability to model
different synchrony assumptions (systems are
typically heterogeneous and include synchronous and
asynchronous components). * The ability to model
systems at different levels of abstraction. * The
ability to decompose verification tasks into
subtasks of lower complexity. The salient features
of reactive modules are scalability along the space
and time axes and interdefinability of synchronous
and asynchronous behavior. Scalability along the
space axis means that spatial implementation details
(e.g., internal variables and wires) can be
hidden. Scalability along the time axis means that
temporal details (e.g., internal computation steps
and delays) can be hidden. Interdefinability means
that after hiding spatial or temporal details, a
module that was previously synchronous
(asynchronous) can be redefined to be asynchronous
(synchronous). Definition of a Reactive Module
Variables, States & Events A module has a _finite_
set of typed variables. States are particular
valuations of these variables. Events are modelled
by toggling boolean variables. System
vs. Environment Variables are partitioned into two
groups: Controlled Variables - Updated internally by
the system External Variables - Updated externally
by the environment States vs. Observations
Controlled variables are partitioned into two
groups: Private and Interface Variables Interface
and External variables are observable externally
while private variables are only observable by the
internal system. Asynchrony vs Synchrony Variables
change their values in a sequence of rounds during
execution: Pure Asynchrony - Private variables can
be updated independent of observable
variables. Examples include asychronous systems
communicating via shared variables. Observable
Asynchrony - Private variables are updated in
response to observable changes. Examples include
asynchronous systems communicating via events such
as I/O automata. Atomic Synchrony - The system and
environment simultaneously update
variables. Examples include Mealy machines and
Hoare's CSP. Nonatomic Synchrony - The system and
environment take turns updating variables during
microsteps. The synchronous programming languages
such as Estereluse this model. Modeling
vs. Programming Language It should be noted that
reactive modules serve as a modelling language; not
a programming language. As such it has an explicit
notion of variables and states and allows
nondeterminism. Nondeterminism is a convenient
mechanism for describing incomplete or high level
designs. The intent is that various programming
languages will be translated to reactive modules and
analysis will be performed. I am not exactly clear
on the difference between a modelling language and a
programming language. I think that a modelling
language is close to a model of computation in that
it has semantics without syntax. Implementation
Module P "implements" module Q if the following
conditions are met: 1) Every interface variable of Q
is an interface variable of P. 2) Every external
variable of Q is an observable variable of P. 3) For
all observable variables x in Q and interface
variables y in Q, if y awaits x in Q, then y awaits
x in P. 4) If s is a trace of P, then the projection
of this trace onto the observable variables in Q is
a trace of Q. Operations on Reactive Modules Here we
focus on how reactive modules can be combined and
operated on. Five operations were covered: 1)
Variable Renaming 2) Parallel Composition 3)
Variable Hiding 4) Round Abstraction 5) Triggering
Of special interest to me is parallel composition
and this is what I will cover below. Reactive
modules P and Q are considered "compatible" if 1)
The interface variables of P and Q are disjoint 2)
The await dependencies among observable variables of
P and Q are acyclic. Note that I did not summarize
the component of this paper that deals with acyclic
dependencies. Note that if P implements Q and P and
R are compatible, then Q and R are compatible as
well. Parallel Composition If P and Q are two
compatible modules, then the composition is the
module P||Q with * The private (interface) variables
of P||Q are the union of the private (interface)
variables of P and Q. * The external variables of
P||Q are the union of the external variables of P
and Q minus the interface variables of P||Q. This
accomodates the fact that an interface variable of P
might connect with an external variable of Q. The
paper then proceeds to invoke the compositional and
assume-guarantee assumptions. Accordingly I list
several propositions which have proofs that use
these assumptions: * P||Q implements P * P
implements Q implies P||R implements Q||R * P1 and
P2 are compatible as are Q1 and Q2. Then P1||Q2
implements Q1, Q1||P2 implements Q2, every external
variable of Q1||Q2 is an observable variable of
P1||P2 implies that P1||P2 implements
Q1||Q2. Initially I read this paper to consider
extensions to other general models of computation
with particular emphasis of applications to the
dataflow model. I am reading it a second time with
consideration for how it can impact composition of
operational semantics. I am trying to determine how
composition should come about for the Ptolemy II
process domains. I think that the notion of
``implements'' as explained in this paper could be
useful for my composition needs. For example, in DDE
each actor has a local notion of time. The questions
to be answered include: How does time fit in Alur
and Henzinger's classification of variables. Where
do DDE actor's fit on the (a)synchrony scale?}
}
@Book{andrews91concurrent,
author = {Gregory R. Andrews},
title = {Concurrent Programming: Principles and Practice},
publisher = {Benjamin/Cummings},
year = 1991,
address = {Redwood City, California},
annote = {This is a comprehensive textbook on concurrent
programming. The book starts off with a review of
formal logic and its use in sequential
programming. The logical constructs introduced here
are repeatedly referred to throughout the
book. Chapter 2 introduces concurrency and
synchronization. The idea is simply that processes
alternately process information and communicate the
information to other processes. Internal processing
happens concurrently with that of neighboring
processses. Communication between processes makes it
necessary to synchronize so that interference can be
avoided. Interference occurs when a process makes an
action that invalidates assumptions made by another
process. To avoid interference, processes
synchronize. We can view the execution of a
concurrent program as an interleaving of the atomic
actions executed by the individual processes. The
set of possible interleavings consists of many
realizations. In general, some interleavings are
undesirable and result in interference. The are two
ways to avoid undesirable interleaving. One
possibility is to combine several atomic actions in
to coarse grain actions. The second option is to
delay certain atomic actions of a given process
until the program state is safe. The first option is
referred to as {\em mutual exclusion}. The second
option is referred to as {\em condition
synchronization}. Mutual exclusion and condition
synchronization serve as core solutions throughout
the text. The book builds a solid foundation based
on the notion of mutual exclusion and }
}
@Book{armstrong00VHDL,
author = {James R. Armstrong and F. Gail Gray},
title = {VHDL Design Representation and Synthesis},
publisher = PH,
year = 2000
}
@InProceedings{armstrong02embedded,
author = {Brijesh Sirpatil and James Baker and James
Armstrong},
title = {Using {SystemC} to Implement Embedded Software},
booktitle = {Proceedings of International Conference on Hardware
Description Languages},
year = 2002
}
@Article{astrom00swingup,
author = "{\AA}str{\"o}m, Karl Johan and Furuta, Katsuhisa",
year = 2000,
volume = 36,
title = "Swinging up a Pendulum by Energy Control",
pages = "278--285",
journal = "Automatica"
}
@inproceedings{balarin02metropolis,
author = {F. Balarin and L. Lavagno and C. Passerone and
Y. Watanabe},
title = {Processes, Interfaces, and Platforms: Embedded
Software Modeling in {Metropolis}},
booktitle = EMSOFTW,
series = LNCS,
number = 2491,
publisher = SPRINGER,
year = 2002,
pages = "407--421"
}
@Article{basten97vectorTime,
author = {Twan Basten and Thomas Kunz and James P. Black and
Michael H. Coffin and David J. Taylor},
title = {Vector Time and Causality Among Abstract Events in
Distributed Computations},
journal = {Distributed Computing},
year = 1997,
volume = 11,
number = 1,
pages = {21-39}
}
@article{benveniste98hybrid,
author = {Albert Benveniste},
title = {Compositional and Uniform Modeling of Hybrid
Systems},
journal = {IEEE Transactions on Automatic Control},
year = 1998,
volume = 43,
number = 4,
pages = "579-584"
}
@InProceedings{bhattacharya00psdfScheduling,
author = {Bishnupriya Bhattacharya and Shuvra
S. Bhattacharyya},
title = {Quasi-static Scheduling of Reconfigurable Dataflow
Graphs for {DSP} Systems},
booktitle = RSP,
year = 2000,
month = jun,
publisher = IEEE
}
@Article{bhattacharya01psdf,
author = {Bishnupriya Bhattacharya and Shuvra
S. Bhattacharyya},
title = {Parameterized dataflow modeling for {DSP} systems},
journal = {IEEE Transactions on Signal Processing},
year = 2001,
volume = 49,
number = 10,
pages = {2408--2421},
month = oct
}
@InProceedings{bhattacharya02localSynchrony,
author = {Bishnupriya Bhattacharya and Shuvra
S. Bhattacharyya},
title = {Consistency Analysis of Reconfigurable Dataflow
Specifications},
booktitle = {Embedded Processor Design Challenges},
pages = {1--17},
year = 2002,
number = 2268,
series = LNCS,
month = oct,
publisher = SPRINGER
}
@article{bhattacharyya93sdf,
author = {Shuvra S. Bhattacharyya and Edward A. Lee},
title = {Scheduling Synchronous Dataflow Graphs for Efficient
Looping},
journal = {Journal of VLSI Signal Processing},
volume = 6,
year = 1993,
page = {271--288}
}
@article{bhattacharyya94memory,
author = {Shuvra S. Bhattacharyya and Edward A. Lee},
title = {Memory Management for Dataflow Programming of
Multirate Signal Processing Algorithms},
journal = {IEEE Transactions on Signal Processing},
year = 1994
}
@Book{bhattacharyya96sdf,
author = {Shuvra S. Bhattacharyya and Pravin K. Murthy and
Edward A. Lee},
title = {Software Synthesis from Dataflow Graphs},
publisher = KLUWER,
year = 1996
}
@Inproceedings{biberstein02sealing,
author = {Marina Biberstein and Vugranam Sreedhar and Ayal
Zaks},
title = {A Case for Sealing Classes in {Java}},
booktitle = {Proc. The Israeli Workshop on Programming Languages
and Development Environments},
month = jul,
year = 2002
}