Abstract. In this paper, we show how to combine a component system and a macro system. A component system separates the definition of a program fragment from the statements that link it, enabling independent compilation of the fragment. A macro system, in contrast, relies on explicit links among fragments that import macros, since macro expansion must happen at compile time. Our combination places macro definitions inside component signatures, thereby permitting macro expansion at compile time, while still allowing independent compilation and linking for the run-time part of components. 1 Introduction Good programmers factor large software projects into smaller components ormodules. Each module addresses a specific concern, and a program consists of a network of cooperating modules. First-order module systems provide namemanagement, encapsulation, and control over separate compilation [1]. However, first-order module systems use internal linkage, in which modules refer directlyto other modules.

Abstract. Hygienic macro systems, such as Scheme’s, automatically rename variables to prevent unintentional variable capture—in short, they “just work. ” Yet hygiene has never been formally presented as a specification rather than an algorithm. According to folklore, the definition of hygienic macro expansion hinges on the preservation of alphaequivalence. But the only known notion of alpha-equivalence for programs with macros depends on the results of macro expansion! We break this circularity by introducing explicit binding specifications into the syntax of macro definitions, permitting a definition of alpha-equivalence independent of expansion. We define a semantics for a first-order subset of Scheme-like macros and prove hygiene as a consequence of confluence. The subject of macro hygiene is not at all decided, and more research is needed to precisely state what hygiene formally means and [precisely which] assurances it provides. —Oleg Kiselyov [1]

Modern hardware description languages support code-generation constructs like generate/endgenerate in Verilog. These constructs are intended to describe regular or parameterized hardware designs and, when used effectively, can make hardware descriptions shorter, more understandable, and more reusable. In practice, however, designers avoid these constructs because it is difficult to understand and predict the properties of the generated code. Is the generated code even type safe? Is it synthesizable? What physical resources (e.g. combinatorial gates and flip-flops) does it require? It is often impossible to answer these questions without first generating the fully-expanded code. In the Verilog and VHDL communities, this generation process is referred to as elaboration. This paper proposes a disciplined approach to elaboration in Verilog. By viewing Verilog as a statically typed two-level language, we are able to reflect the distinction between values that

Working with Mitch Wand has been a rare privilege. I am grateful for all he has taught me and for the opportunity to work for a man I admire. A great deal of my education took place in the extraordinary Programming Research Laboratory on the third floor of West Village H. In particular, I find it hard to imagine ever finishing this work without the perspective, insight,

To ensure that hardware descriptions are synthesizable, designers today bear the responsibility of understanding and conforming to coding guidelines. This makes it harder to write reusable designs, and makes the transition from a behavioral design to a structural design more labor intensive. This paper proposes the use of a static analysis to check the synthesizability of a design. This static analysis uses ideas from statically-typed two-level languages to reflect the distinction between values that are known at design time and values that are carried on wires in synthesized circuits. This distinction is crucial for determining whether abstractions such as iteration and module parameters are used in a synthesizable manner. To formalize these ideas, we develop a core calculus for Verilog, along with a static type system. We define a preprocessing step that defines how such abstractions can be eliminated in an early phase of synthesis, and the kinds of errors that can occur during preprocessing. Our key technical result is showing that a well-typed design cannot lead to preprocessing errors, and can only expand to a synthesizable circuit. 1

Abstract — Hardware description languages (HDL) suffer from inconsistencies between their simulation and synthesis semantics: A program successfully compiled and simulated might fail to synthesize. In this work, we propose the usage of statically typed two-level languages (STTL) to eliminate such inconsistencies. Languages like VHDL and Verilog have constructs (loops, parameters, and other abstractions) that helps the digital circuit designer in writing more generic code. These constructs are eliminated during elaboration and replaced by appropriate expansions. In many cases synthesis failure is effectively due to failure to achieve this step. Capturing the mechanics of that preprocessing stage can be formalized using STTLs that allow us to define corresponding expansion semantics. We can therefore statically verify the synthesis feasibility of a certain program by type checking against rules specifically designed for that purpose. In this paper, we show how this STTL approach can be applied to Verilog. To do so, we define the syntax, first-stage expansion semantics, and type system for a representative subset of the Verilog language that we call (Featherweigth SV). We also prove that according to our model, expansion preserves well-typedness of a program, that it results in an obviously synthesizable program (free from first stage constructs) and finally that it does not depend on wire values. I.