AppologyThis document still has no real content. Tenos finally does really exist and, very soon now, we will add the real content below. Document ScopeThe embedding of hardware designs in software languages requires a mapping from software concepts to hardware concepts. The design requirements for such a mapping are that it is easy to use and supports flexible repartioning of the system between hardware and software and between simulation and implementation. TENOS is the name of our solution. TENOS is a set of library files and a set of rules built into the associated compilers. BackgroundHardware synthesis rules used with Verilog and VHDL require that a variable is only updated by one thread. The method for block instantiation in these languages reinforces this paradigm. On the other hand, software systems which deal with asynchronous events from various sources are implemented with threads which flow from one module to another using up and down calls. This appears to be the major difference between current hardware design approaches and software. Most people will agree that the software approach is easier to use, since far less parallelism needs be considered by the designer.IntroductionThe Verilog language has a number of features which make it good for modelling hardware. Indeed, a large number of Verilog features are used only for run-time modelling at the wire and transistor level and are not relevant for cycle-level simulation and not supported for synthesis. On the other hand, for complex system specification, Verilog has a number of shortcomings: one is its lack of mutexes and abstract data types and another is the unusual semantics of its more idiosyncratic features, such as delta delays and the two assignment operators. Nonetheless, the Verilog language has important features that we need to provide in a C, C++ or Java environment if these programming languages are to replace Verilog. The major features are
TENOS Structural Instantiationto be written... TENOS Target Thread Libraryto be written... TENOS Simulation Thread LibraryUsing Mode 2, for each process loop, a thread is required during simulation and a nominal thread is needed for compilation. to be written... TENOS Master-Slave FunctionThe following two process loops share one variable. Each process loop is shown in C (mode 2) and Verilog. The Verilog example has used blocking assignment. The intention is that the variable a is updated with the old value of b before b is updated with c.
while(1) while(1)
{ {
a = b; b = c;
cx_barrier(clk); cx_barrier(clk);
} }
always @(posedge clk) always @(posedge clk)
begin begin
a = b; b = c;
end end
The semantics of Verilog are slightly strange, in that owing to the blocking assignment, the desired behaviour is only guaranteed if the two loops are placed in different modules. This is beacuse of the implied hash-zero delay on every signal as it enters and leaves a module. To explain this further is beyond the scope of this document, but suffice to say two things: 1. If the Verilog blocking assignment operator were used instead, the problem would not arise, and 2. using the blocking assignment operator results in code which is RTL rather than behavioural and so fundamentally moves us away from our main goal of designing hardware with constructs familiar to programmers. At first sight, it may appear that the two while loops need to be run with separate threads and for the threads to simply rendevouz inside the barrier calls. However, depending on which assignment happens first, inderterminate results are possible, exactly as in the Verilog, same module situation. If these sections of code are inputs to a compiler, one possible solution is to compile both process loops together and ask the compiler to generate the correct ordering for a single thread of execution to model both of the source threads. This is what our VTOC compiler does in modes 0 and 1. However, these two pieces of code could have been generated by separate runs of a compiler (separate runs are needed in large systems owing to compile time limitations.) or could have been written by hand with a desire that they are run with real threads. In either case, two actual threads are needed. Our solution is to make multiple copies of variables using the "ttmodelling" package. A writer module updates one copy. This acts like the master of a master slave flip-flop. Once all the threads are trapped inside the barrier rendevouz, the master is copied to all of the other copes, which act like slaves. The package complains if more than one module has written a variable between barrier statements. A method for supporting combinatorial toing and froing between modulesA normal software design approach does not use combinatorial logic concepts: variables simply stay at the last value assigned to them and assigning to one variable does not affect the values of others (unless aiased in a union). In ... TENOS Meta CommandsThe following meta commands can be included in the source language to provide compilation directives and simulation control. rest to be written... TENOS Graphical Outputto be written... TENOS Source Mapping ModesTENOS uses three sets of mapping semantics, known as mode 0, mode 1 and mode 2. These have much in common, in that a C subroutine maps to a Verilog module with the same number of parametes. Outputs use call by reference and the value returned by the top level C routine is ignored. The respective CTOV and VTOC manuals give detailed information about how these modes are used with each tool. Here we summarise the modes. Note that mode 2 is the only mode which enables a design to be transformed repeatedly back and forwards beteen C and Verilog without change of function. |
|
A mode 0 representation of hardware is a subroutine which does not contain any infinite loops. The subroutine must be called by a thread sufficiently frequently that any changes to the inputs and free variables are not aliased. Any of the inputs may be regarded as clocks. A mode 1 representation of hardware is also a subroutine which does not contain any infinite loops, but each call to the subroutine is associated with the active edge of a nominated clock. The clock net need not appear as a parameter to the routine, since it is defined elsewhere or defaults to `clk'. Other clock inputs to the subsystem must be less than half the frequency of the nominated clock otherwise they will be aliased. A mode 2 representation of hardware is a subroutine which contains one or more barrier statements, using the `cx_barrier(clk, id)' call. The subroutine may contain an infinite loop. Larger systems can be modelled with multiple such subroutines. These systems then require our pthreads-based threads library to be run as a software system but the threads library is not required if they are compiled to Verilog by CTOV. The first parameter to a barrier is a clock net whose edge enables the barrier to be crossed. The second parameter is an optional text string which provides a name for the barrier to help with cross-referencing the object code. Barriers may be hard, elidable, soft or automatic. A hard barrier definately relates to a clock cycle. Elidable and soft barriers can be deleted by the CTOV tool if they are not required and would only serve to make the resulting hardware run more slowly. An automatic barrier is inserted by the tools inside an infinite loop or other loop not unwound at compile time which would otherwise generate combinatorial loops in the resulting hardware. Time SpecificationsConventional time specifications set the clock period and the setup and hold time of the IO signals. In TENOS, however, the time specifications alter the number of clock cycles between IO events. The period of the clock and absolute time are not considered in this version of TENOS. The conventional time specifications must be fed to the RTL compiler that is used to process the output from CTOV. If the backend compilation cannot produce a sufficiently fast clock, then CTOV needs to be manually reinvoked to yield a design which perhaps uses more clock cycles or less, but which will meet the overall aim. In the future, we would hope to add to CTOV some absolute time time control, to make this process more automatic. The TENOS time specifications are given in terms of clock cycle counts between calls to subroutines. These subroutines may be dummies which have been added specifically and only for the purpose of annotating with timespecs, or they may serve a normal purpose. Typically, they will be subroutines which perform an IO operation. See the CTOV manual for the commands needed to add a time spec to a subroutine. Flowgraph DirectivesIt is impossible for a compiler to know that restricted patterns of calling will occur between subroutines in the general case (halting problem), and in practice input pattern constraints not known at compile time will have a large effect on control graph shape. Therefore the CTOV compiler takes a conservative approach to call graph shape, which may result in a longer path being considered than will ever be executed in practice. This will result in additional parallelism (more hardware) being needed in the synthesised result to achieve a given clock count limit. Therefore, flow graph directives must be added to eliminate these unused paths from consideration. This section will explain how to use these in a future draft. TENOS CodesignWith this release there is no support for automatic partitioning between hardware and software: for instance, with CTOV, all of the C code in and called from a top level C routine is converted to hardware. We would hope to support more options in the future. TENOS FILESC Language VersionThe files that make up the TENOS library C language version are
|