CSEE4823 Handout #35c Prof. Steven Nowick 11/29/12 Project #2: FAQ (frequently-asked questions) The following summarizes some questions/answers and clarifications about the mini-project. Listed from most recent to oldest: ====================================================================== 12/7/12 ====================================================================== ------------------------------------------------------------------ Minimalist: option settings for minimalist-speed, minimalist-area ------------------------------------------------------------------ Q. What options should we use for minimalist-speed and minimalist-area in the mini-homework assignment? A. Check the commands (using 'help' mode) to see which parameters are automatically used by default, and which you have to explicitly set. In any case, for minimalist-speed, use no-feedback, and either single-output or output-disjoint (the latter allows sharing of products between different outputs, but does not allow output logic to share next-state products to avoid extra load) For minimalist-area, use feedback and multi-output. ====================================================================== 12/4/12 ====================================================================== -------------------------------------------- "Res" input: can it be stored in a register -------------------------------------------- Q. In the project, the "Res" input is a 4-bit field indicating the user-specified resolution of the MacLaurin computation. Its value can range from 5-15. However, the handout says that -- like "Start" -- it is only valid for 1 clock cycle (while the Input operand is valid for 2 clock cycles). It seems it is not valid long enough to store it. Can we? A. YES. You can assume that, like the Input FP operand, that "Res" is actually valid for *2 clock cycles* and can be correctly stored in a register. ====================================================================== 12/3/12 ====================================================================== -------------------------------------- barrel shifters: left vs. right shift -------------------------------------- Q. Can we use left/right barrel shifter in our design? In the Gajski book, only a barrel shifter that implements right-shift is given, but can we slightly modify this implementation to allow using single block to implement both left and right shift? Or should we use separate blocks, one for left shift, another for right? A. You can allocate a barrel shifter that does *either* right shift *or* left shift, but not both. If you need both, you will need two barrel shifters: one for right shift and one for left shift. ---------------------------------------------------------------- Minimalist: creating/displaying .bms specification (Postscript) ---------------------------------------------------------------- Q. How do I graphically display the .bms specification? A. As a part of the homework (Handout #35d) on asynchronous controller design using the Minimalist CAD tool, you are expected to use 'bms2ps' to display the specification in a graphical format. NOTE that, 'bms2ps' **only generates** the corresponding postscript (.ps) file. To view the file, you must use Ghostview (gv) or any other equivalent program for viewing postscript files. For example, If you have entered your specification in foo.bms, the first command will generate foo.ps. The second command will display the file. minimalist> bms2ps foo.bms minimalist> gv foo.ps ====================================================================== 11/29/12 ====================================================================== Q. multiple sources for the same variable: When doing the datapath for the ASM, if we find a particular variable has multiple loads from multiple sources, should we allocate a MUX with its own control signals to select the source(s)? A. Yes. I sketched a solution to this in class. For example, suppose you have a generalized-ASM, which includes the following statements: ... x := 0 if (y<0) then x := y ... x:= 15 In step #3 of Handout #31 ("Allocate Datapath Blocks", also known as 'resource allocation'), you would not only: (i) allocate a sequential component for variable x, which (in above example) could both perform a 'load' and a 'hold' operation (such as a basic register with parallel load, looking into Handout #34 for an appropriate component); but also (ii) allocate an input MUX which (in above example) takes 3 inputs and has 1 output (such as a 4-to-1 MUX), to attach to the data input port of storage unit x, to allow you to select one of the 3 possible operands (0, y, 15); this MUX would also have 'select' signals as its control signals. That is, in Datapath Allocation, for the above code fragment, you would allocate both an appropriate storage unit for x, and an attached input MUX. Each typically has attached control signals, which should be clearly indicated. ----------------------------------------------------------------- Q. How different can my pseudo-code (step #1) be from my generalized ASM (step #2)? A. The pseudo-code should be very close in level to the generalized-ASM. See handout #31 as an example. The idea is that the pseudo-code already is broken into simple RTL operations, that map *directly* to the generalized ASM. Of course, the pseudo-code is behavioral, therefore inherently higher-level, and doesn't have a notion of state or clock cycle (unlike the generalized ASM). Nonetheless, as indicated in class, the operations in pseudo-code and generalized ASM should be at a similar level, and the former ones correspond simply and directly to the latter ones. ----------------------------------------------------------------- Q. WHAT TO HAND IN: for steps #1 (pseudo-code) and #2 (generalized ASM), should we add comments, notations, clarifications, etc. to make our submitted projects more readable and understandable? A. YES! These are basic requirements, as we went over explicitly for Project #1. In particular, much like Handout #31 (but in more detail, because you are handling a more complex subsystem): (i) listing basic variables/storage units (before step #1): *Before* presenting your pseudo-code, you should neatly list each 'variable' you will use. (For ex., the variables in handout #31 included Input, Output, Data and Ocount.) For each variable, indicate total # of bits, any breakdown into individual fields, subfield names, etc. I strongly suggest you DRAW A SIMPLE FIGURE for each storage variable, indicating the above. You can show any breakdown into fields in the figure. These drawings are *before* doing the datapath allocation step, they are abstract figures of the storage units (before you have determined which precise unit in the library the variable maps to). The above is part of general documentation, whether for TA's, management or design review. This documentation makes it easier for others to follow your pseudo-code and generalized ASM. (ii) commenting and annotating your pseudo-code (step #1) It is very useful to include comments within your pseudo-code to document the major steps, what each part does, etc. In addition to inserted text comments, you can also include brackets around groups of instructions, as in handout #31, to highlight the larger parts of your code. (iii) commenting and annotating your generalized ASM (step #2) As in Project #1, draw dotted lines around groups of ASM blocks that form steps, and annotate them. For example, you can group ASM blocks that handle special symbols, indicate where initialization occurs, where output occurs, what operations occur in which region (e.g. sine vs. cosine), where an inner loop body occurs and what it does. All such neat *hierarchical* documentation adds to the readability of your solution, helps to present your solution more clearly, and is part of professional practice. ----------------------------------------------------------------- ================================================ RTL operations: pseudo-code and generalized ASM ================================================ Your RTL operations should be simple. The idea is that you are breaking down a relatively complicated specification into a series of *very simple step*s. In the pseudo-code, these steps are 'behavioral' (i.e. no clock cycles indicated). In the generalized ASM, these steps include clock cycles, and hence are "scheduled": each state box in your generalized ASM corresponds to an FSM state, and all operations in the state occur in the same clock cycle. As a result, in the 'resource allocation step', each micro-operation will be mapped to a very simple unit in the Gajski-based library (i.e. Handouts #33 and #34). DO NOT LOOK FOR COMPLEX OPERATIONS AND UNITS! As I have indicated, unless you get special permission from me, you must only use components in the given library. Also, if you start working on the problem by trying to design the hardware and architecture, you are off track! Follow handout #31: your focus should be entirely on the top-level pseudo-code and generalized ASM first. --------------------- basic RTL operations: --------------------- Typical RTL operations are very simple, such as are included in Handout #31 (1's counter). Each can be performed within 1 clock cycle, and have a direct match to associated hardware units: x := y + z x := y - z x := y >> 3 h := j j := j + 1 z := (x > y) [sequential] or simply (x > y) [combinational] ... etc. Most of your RTL operations will look like the above. ------------------------------------------- allowed multi-step operations ('chaining'): ------------------------------------------- See details in requirements of Handout #35, and as covered in class lecture. I indicate that in a few simple cases, you can have 2 combinational operations, one after the other, in the same clock cycle. You should *not* assume a single 'merged' datapath block. Instead this involves 2 separate blocks, and you must identify *both* operations explicitly in your pseudo-code and generalized ASM. For example, I have allowed a combinational shift before (or after) an addition. To specify this in pseudo-code and the generalized ASM, you simply list a composite operation: e.g. x := (a << 1) + b -- shifts a before adding to b y := (a - b) >> 3 -- shifts result after subtracting a - b In this case, since you are doing combinational shifting instead of sequential shifting, you would allocate a barrel shifter in the resource allocation for the shift part of the operation. Both combinational components would be explicitly allocated in the 'resource allocation step', and they would be tied together appropriately for the given composite (i.e. chained) operation. However, very few operations can be chained under my guidelines. See explicit discussion on pp. 3-4 of Handout #35. Normally, an RTL operation is simple a single step! ----------------------------------------------------------------- ================================ SPECIAL FP OPERATIONS: SIGNED 0 ================================ Q. How do I do operations with the special reserved FP symbol, +/-0? A. First, for your integer operand, if it is 0, assume it can be treated in FP as +0. So you will never be adding two -0 operands. Of course, the integer operand is never infinity. Given these constraints, the relevant operations with signed 0 and infinity are: For any N: +0 + N = N -0 + N = N +0 * N = +0 -0 * N = -0 -----------------------------------------------------------------