Appendix A. Frequently Asked Questions

  1. What is SCE ?

    SCE is an acronym for System-on-Chip Environement. It is a design environement based on a model refinement methodology. The environment consists of several tools and user interfaces to help the designer take a functional system specification to its cycle accurate implementation with minimal effort.

  2. What are the supported platforms for SCE ?

    SCE 2.2.0 beta is currently supported on Linux RedHat 7.3. The public distribution of the operating system is included on the CD-ROM. SCE has also been tested for RedHat 8.0 and SuSE 8.2 distributions of Linux. Other platforms will be supported in the future as the need arises.

  3. What is the level of expertise needed to design with SCE ?

    SCE is designed with the goal of allowing even non-experts to perform system design. A very basic knowledge of SW and HW design, equivalent to an undergraduate degree in computer engineering, is required to work with SCE.

  4. What is the difference between behavior and model ?

    A model is a description of the design in a machine readable form (like SpecC). There may be several models used in a system design effort. These models capture the design with varying levels of abstraction. A behavior, in context of SCE, is a unit of computation. A model is made up by a hierarchy of behaviors that communicate with each other using variables or channels.

  5. What are the models that I need ?

    In SCE, the designer may start with only a specification model. This model captures the functionality of the design without any implementation details. As we go through the design process, various models with greater implementation details are generated automatically using the built in tools in SCE. The designer only needs to guide the model generation with decisions. The four primary models in the SCE methodology are Specification model, Architecture model, Communication model and Cycle-accurate model. The designer may choose to start with any model as per his or her choice.

  6. What do I need to do with all these models ?

    Each of the models need to be compiled to generate an executable. Once they are compiled, they need to be simulated to make sure that they work correctly. The designer may choose to view the models in graphical form to understand and verify the implementation details added as a result of refinement. The specification model also needs to be profiled to get useful data for making architectural decisions.

  7. How do I get a cycle accurate model of my design ?

    The designer may start with any of the system level models, namely the specification model, the architecture model or the communication model. With the help of design decisions, SCE will generate subsequently refined models of the design. The final model generated after RTL refinement and SW compilation will be a cycle accurate model of the design.

  8. Why is profiling relevant ?

    Profiling is performed to gather useful data about the specification. It gives both a quantitative and a qualitative measure of the computation inside each behavior or a set of behaviors. This information is used to choose the right type and number of components for the system architecture.

  9. How do I discover the "computationally intensive" behaviors in my model ?

    A straightforward approach is to produce bar charts for each leaf behavior in the model. For a reasonably complex design, the designer can use the hierarchical nature of the behaviors to display comparision between composite behaviors. Behaviors with low computation may be eliminated. For a behavior with high computation, the designer can display its child behaviors and so on. The author of the specification model can also supply this information upfront, since he or she would be well conversant with the model.

  10. Why should I evaluate an architecture before refinement ?

    Most designs have constraints on execution time. The architecture exploration phase requires the designer to come up with the best set of components (and the distribution of computation over them) to meet this constraint. One way would be to generate the architecture model and then simulate it. This is time consuming if the designer has to go over several architectural choices. Evaluation of a model is a static analysis feature that allows the designer to check if an architectural choice meets the design constraints.

  11. If my architecture model simulation shows an encoding delay of "0.0ms", what did I do wrong ?

    This may be because the specification was not profiled before an architecture model was generated. Profiling generates information that allows architecture refinement to insert the appropiate delays for the target component.

  12. Can I refine any behavior in a model ?

    The behavior which is set as the "top level" of the design is considered for architecture and communication refinement by the tools. Typically, the behavior representing the design under test (without the testbench) is set as the "top level" behavior. However, for RTL refinement, the designer may choose a particular behavior mapped to HW. This will allow the designer to examine only an interesting part of the design without having to simulate the entire model at cycle accurate level.

  13. Why do I need to rename all the generated models ?

    Renaming is done to avoid overwriting of models during exploration. Automatically generated models are read-only for the same reason. Renaming also gives a suitable name to the model so that it can be easily recognized in the project window.

  14. I want multiple busses in my design. How do I map channels to busses ?

    The design example in the tutorial has only one bus. The shortcut for mapping all channels to one bus is to map the top level behavior to that bus. In case of multiple busses, select Synthesis->Show Channels after allocating the busses. This would expose all the channels between the components. Individual channels can then be mapped to respective busses.

  15. Can I use point to point wire connections instead of busses in my design ?

    Busses in SCE represent generic connection elements. It is possible to have point to point connections between components. This can be done simply by including such a point to point protocol in the protocol library and selecting it during communication synthesis. During channel mapping the designer must take care to map channels between only the relevant components to the point to point "connection element."

  16. Why do I need to do RTL preprocessing ?

    Preprocessing is needed to generate a super finite state machine model of the design, which serves as an input to RTL refinement. The preprocessing step splits the behaviors into super states, with each super state comprising of a basic block.

  17. Why does RTL scheduling and binding display work only for leaf behaviors ?

    During preprocessing each leaf behavior under the selected behavior for HW implemetation is converted to a super FSM. Displaying only one super FSM at a time avoids overcrowding in the display and state name conflicts.

  18. How do I know which RTL units to choose ?

    The designer chooses the RTL units that can perform the operations required in the model. RTL analysis gives statistical information on the number and type of operations in each super state. Structural constraints can put lower bound on the number of units. For example, if a unit with 3 inputs and 1 output is allocated, then atleast 4 busses must be allocated for feasible binding.

  19. How do I view source code generated by SCE ?

    The SpecC source code for the behavior definition can be seen by clicking on the behavior in the hierarchy tree and selecting View->Source. The code for the behavior instance can be seen by right clicking on the instance in hierarchy and clicking Source. However, SCE also produces C, Verilog and Handel-C files. Since these files do not show up in the hierarchy, they have to be opened externally from a shell using standard editors.

  20. What is the current status of SCE ?

    SCE is currently a demo version that works for select examples. In the future, it will be enhanced to a prototype tool.

  21. What other features are planned in the immediate future for SCE ?

    In the immediate future, we plan to expand the libraries with more components, IPs and bus protocols. Improvements are planned for communication synthesis framework to handle complex communication architectures. There is also work planned for OS targetting and generation of RTOS models.