An Analysis of Hardware Generation Techniques for ... Stateflow and VCC ... better suited for designing these complex systems on ... The behavior of the state machine is modeled using

An Analysis of Hardware Generation Techniques for Stateflow and VCC

Kevin Camera University of California, Berkeley

Department of Electrical Engineering and Computer Science EE249 Fall 2000

Abstract This project investigates the area and delay efficiency of hardware generators for Stateflow and VCC. The first goal of this work is to determine how the use of hierarchy in Stateflow affects the resulting hardware. While the use of hierarchy is extremely convenient for the system designer and reduces the size of the description, it must be flattened before hardware generation, and the flattening process may introduce undesired overhead. The second goal is to determine how the hardware implementation of the CFSM model used in VCC differs from the primarily synchronous StateCharts model used in Stateflow.

The hardware generation tools for each platform are discussed, along with their mapping methodology. The case studies used as examples for the analysis are also presented in detail, as they have a profound impact on the results and consumed a large portion of the time allocated to this work. Lastly, the resulting hardware characteristics are presented, along with an interpretation of their meaning and the conclusions drawn from the preceding analyses.

1. Introduction Anyone in our field surely is aware of the trend toward larger scales of integration on silicon devices. The number of transistors available on a single chip has reached the point where entire computation and communication systems can reside on the same die. This new class of devices is referred to as “system on a chip”, or SoC. Along with the amazing capabilities of these devices comes an significantly more difficult design problem. The design tools which were already stretched to their limit in the previous generation are now incapable of producing SoC devices in a reasonable amount of time.

Naturally, new tools are being developed which are better suited for designing these complex systems on a chip. One such tool is VCC by Cadence Design

Systems. VCC specializes in the modeling and interfacing of heterogeneous components. Custom-written source code and state machines are integrated into the same behavioral model as external components and “hard macros”, such as IP (“intellectual property”) blocks. IP blocks pose a unique challenge since their implementation details are hidden from the system designer, and they are typically unchangeable. All this software and behavioral models are then mapped onto an implementation, allowing architectural exploration and performance measurement without prototyping.

Other more novel approaches are being considered for specialized applications. Our research group at the Berkeley Wireless Research Center is working on a design flow for direct-mapped hardware systems, such as communication devices. In a nutshell, the flow works by providing hardware libraries linked to Simulink processing elements, and a predictable backend flow for generating layout corresponding to the design. The power of this design flow is its ability to inherently perform architectural exploration and performance estimation in the same environment as high-level algorithmic simulation. The benefit of directly mapping hardware to the algorithm is exploited once again to provide rapid, automatic generation of silicon from little more than the original description.

Neither modeling virtual components nor directly mapping hardware datapaths results in a complete working system. Both of these approaches share one common feature: they must provide a means for defining and synthesizing control flow. A heterogeneous VCC system will need controllers to manage the operation of its components and maintain the state of the system. Likewise, a communication device must have some form of control to facilitate adaptive behavior, resource access, or user interaction. While these examples are not exhaustive, they do indicate that control blocks are essential to the usefulness of the system.

This project seeks to compare the hardware generation techniques available for finite state controllers in VCC and Stateflow. The paper will be organized as follows. Section 2 will provide a detailed description of the FSM models used in VCC and Stateflow, as well as the tools used to generate hardware from these descriptions. Section 3 will provide a thorough explanation of the benchmarks used in this analysis, including their benefits and limitations. Section 4 presents the area and delay characteristics of the hardware implementations of each example, as well as explanations for the data. Finally, Section 5 presents the conclusions that were drawn from this project, things that should have been done differently, and important areas of further work.

2. Background Before the case studies and results can have any meaning, it is necessary to review the FSM models used by VCC and Stateflow and discuss the hardware mapping methodologies used by the generation tools. The first section will review VCC and its generator buildVlog, and the second section will review Stateflow and present its translator, SF2VHD.

VCC Clearbox STD

VCC defines three types of descriptions (called views) based on how you wish to model them: Blackbox C++, Whitebox C, and Clearbox STD. Blackbox C++ is used to model the timing and functional behavior of a component without providing any internal definition. Whitebox C allows the designer to write C source code which will be compiled and run directly on the platform under design. This targetable code can also be analyzed to derive performance estimates for a given processor architecture. Clearbox STD allows the designer to define behavior with a FSM description which can be translated into either software or hardware. Since this project focuses only on hardware efficiency, the only view type considered in this project is Clearbox STD (hereby referred to only as a STD).

VCC STDs follow a model of computation based on CFSMs, co-design finite state machines. A CFSM is characterized by asynchronous communication to the outside world, but with synchronous timing inside the state machine. This is where the “co-design” part of the name comes from: a system with heterogeneous components, each of which may be implemented in either software or hardware, will have a wide range of communication latencies. The asynchronous global events simplify the communication aspect of the design, and the local synchrony greatly simplifies

the internal implementation and the ability to verify it.

Figure 1: Example of a Clearbox STD model

(SyncFilter STD from TCI)

The hardware implementation of synchronous FSMs has been well known for some time, and CFSMs do not differ much from the classic model, thanks to local synchrony. Therefore, a tool is provided (or rather, will be provided) by Cadence to perform the mapping automatically.

buildVlog The tool used to translate a STD into its hardware equivalent is called buildVlog. At the time of writing, this tool was in the middle of its development phase, and was not yet released. Fortunately, the current version of the tool and some instructions for its usage were provided by Roberto Passerone with Cadence Berkeley Labs.

As the name implies, buildVlog produces a Verilog hardware description for any cell with a STD view. The mapping methodology used by the tool is very straightforward. The Verilog module is given the same name and port interface as the VCC cell. There is one exception: every VCC port is converted into two Verilog signals, one for the port’s value and one which indicates the presence of an event for that signal. The actual edge detectors or other logic which determines the presence of an event is not included. This logic would be implementation-specific, and may be unnecessary if the presence signal is used throughout the rest of the design.

The Verilog code produced by the tool was very clean, and well mapped from the STD to hardware. However, there were some lingering bugs with operator support and missing declarations for constants. This had an impact on the time requirements of the project, since every change to the

STD in VCC required hand-patching of the Verilog before synthesis.

The behavior of the state machine is modeled using a separate Verilog task for the next-state function (the δ relation) and each output function (the λ relations). The tasks themselves are constructed from a binary decision tree representation of the transition function. An optional feature specified on the command line forces the outputs to be held at their previous value when they are not explicitly set. This feature adds some additional lines to the body of the main Verilog task, and in fact must be enabled to match the behavior of Stateflow, as we will see in the following section.

Matlab Stateflow Stateflow is a state machine entry tool provided with Simulink, a graphical front end to the Matlab simulation engine provided by The MathWorks. Although there are some additional syntax features to improve the interface with Matlab, the Stateflow description language is based almost entirely on StateCharts, a graphical language for complex systems designed by Harel in 1987 [1]. It is not the purpose of this paper to describe the rich semantics of Stateflow, but the unique features which do not map trivially into hardware must be addressed to justify the focus this work.

Figure 2: Example of a Stateflow chart

(custom-made arbiter)

The timing model in Stateflow, as it is used in this project1, is purely synchronous. Although there is support for asynchronous triggering off of external events, this feature is not considered here so that the 1 In fact, the timing model can be quite difficult to understand depending on the Simulink simulation mode. In this project, only discrete, fixed time simulations are used, causing the Stateflow timing model to be purely synchronous and well understood.

contrast with VCC STDs is kept clear. The most unique feature of Stateflow, and the most interesting in this project, is the ability to define hierarchical states. The use of hierarchy greatly simplifies the task of the system designer and makes complex systems fit into smaller and more convenient descriptions. However, since our target is a flat hardware description, this hierarchy must be translated into a flat representation during hardware generation. The flattening methodology investigated here is performed by a custom hardware generation tool written by the author, interestingly enough called SF2VHD.

SF2VHD This tool is a masters project which is part of the design flow group at the Berkeley Wireless Research Center. As mentioned earlier in this paper, the design flow is a rapid, high-efficiency methodology for generating direct-mapped hardware from an algorithmic description of a device. The role of SF2VHD is to provide an automated path for control flow synthesis. The approach for the tool has always been “best effort”, under the assumption that control on such devices is small and simple compared to the datapath, and therefore does not need to be aggressively optimized.

The tool supports arbitrary levels of OR-decomposition (sequential processes) in the hierarchy, but cannot handle AND-decomposition (concurrent processes). Certain redundant syntax constructs are also unsupported by design, just to keep the initial program complexity lower. The flattening methodology used by SF2VHD strictly follows the complicated Stateflow execution semantics, which in general gives priority to transitions and actions in top-down order. All state allocation and transition functions are directly translated from Stateflow to VHDL (in the spirit of the rest of the flow), but with no optimization or relative performance estimation. Since Stateflow executes all actions sequentially and preserves output values at all times, the VHDL code also is structured so that all outputs values are latched on each clock cycle.

Despite the fact that the program was deemed finished a couple months prior to the time of writing, the examples described in the following section proved that SF2VHD’s mundane syntax conversions were inadequate. Since we were not given any information on the file format used by Stateflow, SF2VHD was written by reverse engineering the format, which of course resulted in an “ignorant” parser. Previous internal benchmarks did not excite all possible failure modes, and were developed in

tandem with the tool by hardware designers within our group. A significant amount of time was spent trying to fix these errors in an effort to reduce the total time cost of hand-patching the VHDL code for synthesis.

3. Test Cases Creating, or obtaining and translating, the benchmarks for this analysis was a major obstacle to the progress of the project. One reason is that the selection of examples has a profound impact on the clarity and validity of the results. Another reason is that there were very few relevant examples already available, and the time to manufacture a realistic example is significant. Yet another reason is that it requires a lot of effort to understand someone else’s example well enough to perform a useful translation into a different model of computation. In fact, the selection of the case studies alone led to some interesting conclusions, which are discussed at the end of this paper.

The following three subsections present the examples considered in this project, along with their strengths and weaknesses. This information will be important to achieve a fair analysis of the results.

Proprietary Automatic Gain Controller The first attempt at a benchmark was a Stateflow model of an automatic gain controller. The state machine was fairly large (76 states), was hierarchical, had a complex transition function (30 transitions with multi-level branched decisions), and used a wide range of Stateflow action syntax. Besides the ulterior motive that the example was recommended by my research advisor, it seemed to be a good choice, since it demonstrated a sophisticated commercial design (with a patent pending) with all the glory of Stateflow features. A high-level picture of the design’s complexity is given in Figure 3.

As you may have guessed, the wide range of syntax used in the design uncovered many limitations in the parsing capability of SF2VHD. Many days were spent trying to bring the tool up to date with the design, and a number of modifications were performed by hand when the code requirements were too large. Once the design passed the synthesis stage, the netlist contained incorrect logic and combinational loops, rendering it an invalid example.

Figure 3: AGC Stateflow chart (text is intentionally illegible)

Upon further investigation, it was also found that the design, despite the appearance of extensive hierarchy, only utilized two levels of hierarchy. The appearance of most parent states was purely cosmetic, as the parent itself contained no unique state or activity. Thus, this example would not have been a useful demonstration of deep hierarchy had it worked, and was an unfortunate side track as far as this project is concerned.

Custom-made Transceiver Arbiter Based on the disappointment caused by complexity in the last example, a very simple benchmark was created to get a guaranteed look at concrete results. SF2VHD had extended its supported feature list, and the Stateflow version of the design could be produced with almost no synthesis problems. As I was also the designer of the block, it was fairly quick to translate into a VCC model. Of course, a few changes needed to be made by hand to patch errors in both tools, but the design quickly passed synthesis and was ready for analysis.

The design is based on a simple arbiter that would apply in a system with a half-duplex transceiver that must be shared between transmission and reception. The Stateflow description consists of 8 states and two levels of hierarchy, and includes a transition at the top level of the design which preempts the execution of the child states for transmission (in this sense, it gives higher priority to an incoming reception). This type of condition, a high-level transition superceding the child states, is one of the critical cases for flattening a design. The high-level transition must be duplicated for all child states in the flat description. Please refer back to Figure 2 for a diagram of the Stateflow chart.

The VCC description required 6 states (the same states as before, minus the parent containers), and

looked remarkably similar, except that the parent transitions had to be explicitly drawn in the STD, since the CFSM model does not support hierarchy. Again, this tedious replication of behavior common to more than one state is where the benefit of hierarchy lies. The number of explicit ports was also reduced compared to Stateflow, as the occurrence of an event has explicit meaning to a CFSM. Thus, the interface of the STD was a better indicator of the data handled by the block, and was not burdened by additional ports to control the protocol. The figure below shows the STD. The lines that run off the right side of the image would not fit even across the page, but they implement a parity check on the input value using shifts and bitwise AND operations.

Figure 4: VCC STD of custom-made arbiter

(missing lines implement parity check)

However, the simplicity of the design, although convenient, prevented the differences between the models from being obvious. Also, the fact that I was the designer of both descriptions meant that both looked very similar. This “human factor” may contribute to the blurry distinction between the two models.

TCI Transmit/Receive Controllers The final case study of this project was also the most useful. The two-chip intercom (TCI) group, also part of the Berkeley Wireless Research Center, had already designed a system in VCC from the media access layer all the way to the user interface. Many of the blocks at the MAC and physical control layers were designed as STDs, and offered a unique opportunity to convert several existing system components based on the CFSM model into a single Stateflow chart which was hierarchical and synchronous.

Figure 5: Top level of the TCI protocol stack in VCC (transmit and receive controllers are the

blocks farthest to left and right)

Within the time constraints of the project, it was clear that the merging of the entire medium access layer was not possible. Therefore, a selection of four blocks at the physical control layer were selected for the example. Two STD blocks, SyncFilter and PhySend, are part of the transmit controller, and the other two, InvSyncFilter and PhyReceive, are part of the receiver controller. Unfortunately, a few connecting blocks had to be left out of the example, as they were described in C and could not be easily converted into hardware-friendly syntax in Stateflow. As a consequence, the behavior of the Stateflow version is not exactly matched to the VCC version, but a very close approximation was achieved which will not induce bias into the results. In fact, the Stateflow implementation includes the parallel-to-serial converter (modeled in Whitebox C in VCC), which is not included in the VCC totals. This was done as a challenge to make sure the comparison was not biased towards Stateflow. The following table lists the state count for each CFSM included in the example, and for the merged Stateflow equivalent.

Table 1: State and instance counts for TCI example

Block States Instances SyncFilter 4 2 PhySend 7 1 InvSyncFilter 1 2 PhyReceive 3 1 Total 15 6 Stateflow 24 1

One notable observation made during the conversion process was how much state was consumed in the CFSMs to manage the ordering of inputs. Since the CFSM model is comfortable with inputs arriving in an unordered fashion, the state machine itself needs to work for all possible orderings. The result is more states and more transitions to provide a consistent path independent of input order. Adding fuel to the fire is the fact that input buffers have a length of one. In addition to managing the input order, the CFSM must also buffer its own inputs, further increasing the state requirements of the description.

4. Results Now that the examples have been introduced, we can look at the synthesized hardware characteristics and analyze the effects of hierarchy and model of computation.

Custom-made Transceiver Arbiter The following table lists characteristics of the hardware after synthesis with Synopsys Design Compiler in a 0.25µm technology:

Table 2: Hardware efficiencies for simple arbiter

Platform Area (µm2) Cells Delay (ns)Stateflow 7236 133 3.28 VCC 5634 81 2.87

You can see that the CFSM-based VCC implementation is the clear winner in terms of area and speed. This is not too surprising, considering the way in which the descriptions matched up. The CFSM model looked almost exactly the same as the Stateflow model, but did not require additional parent states for hierarchy. Since SF2VHD directly converts each state in the description into a state code and case statement in the VHDL, the parent states are assigned logic and register resources even though they are never explicitly the current state. This is a consequence of OR-decomposition and the way in which SF2VHD flattens the design. By modifying the program to only define hardware state for child (leaf) states, some if not all of this type of overhead can be eliminated.

By browsing the HDL code2, you can see that the Verilog generated from VCC is written in a very direct form and only uses the basic reg and wire

2 Please refer to the Appendix for the very lengthy code samples.

data types. However, the VHDL produced by SF2VHD uses a combination of standard and custom type conversion mechanisms. These mechanisms may not be efficiently interpreted by the synthesis tool, and result in bloated logic. For example, in Figure 6, notice that the parity check resulted in an optimal XOR tree at the top left of the schematic. The VHDL-based result in Figure 7, however, was not so lucky, and the parity checks was lost in a larger chunk of logic. Proof of what VHDL syntax usage is causing this inefficiency will require iterative experimentation, and cannot be included in this work.

Figure 6: Design Analyzer view of the synthesized

netlist generated from VCC/buildVlog

Figure 7: Design Analyzer view of the synthesized

netlist generated from Stateflow/SF2VHD

A final observation is that the VHDL suffers from one more feature: a synchronous reset. This built-in reset is a requirement of the design flow infrastructure to which SF2VHD belongs. The reset is ultimately implemented with combinational logic

directly after the output latches (recall that output persistency is required for Stateflow) and before the output pins. Since the Verilog code does not use an intrinsic reset, it saves the area and delay needed to implement it. This is an orthogonal issue, but does explain part of the significant gap in efficiency. Refer once again to Figure 6 and Figure 7, and pay attention to the two-level logic gates present at every output in the top-right corner of the VHDL schematic. These gates implement the synchronous reset condition, and are not present in the Verilog result.

TCI Transmit/Receive Controllers The following table lists characteristics of the hardware after synthesis with Synopsys Design Compiler in a 0.25µm technology:

Table 3: Hardware efficiencies for TCI controllers

Platform Area (µm2) Delay (ns)SyncFilter 16,569 5.25 PhySend 33,876 6.82 InvSyncFilter 6,174 2.47 PhyReceive 42,903 17.58 VCC Total 99,522 N/A Stateflow 64,728 9.3

You can see from the table that Stateflow is the winner here. One of the most likely explanations for this result was touched on above. The asynchronous communication model of CFSMs require additional state to keep track of the order of inputs and to explicitly buffer input values. The synchronous timing model of Stateflow does not suffer from this limitation. In a sense, the single hierarchical description is statically scheduled; at any time instant, the state machine knows which path it followed and what data is present and valid. The synchronous model also did not require constant acknowledgements between blocks. It was obvious in the CFSMs that many states existed only to send and receive an acknowledgement, which is unnecessary in a single state machine where the protocol state is known.

Another explanation for this result is that the multiple, independent CFSMs suffer from additional overhead caused by maintaining their own separate state. Each CFSM must have its own state registers and logic, whereas the Stateflow model shares a common system state, and likewise the same state registers and logic. We know that log(N) state signals and flip-flops are needed for an N-state machine, and the “inefficiency ratio” of N/log(N)

becomes smaller for increasing values of N.3 Likewise, when the next-state logic is separately partitioned, the synthesis tool is unable to share and optimize logic as much as when all state logic is combined.

5. Conclusion Although not as much time was available for quantitative analysis as I would have liked, several useful conclusions can be drawn from the work done on this project.

First and foremost, it is not the best idea to use development tools on a class project. The time limitation is stringent enough that the percentage of time spent on dealing with imperfect tools is too large. This problem is compounded when you are the person responsible for repairing one of the tools. Instead of reporting the problem and moving, valuable time needs to be spent recoding and verifying. Luckily, the tools were adequate enough to produce one wave of useful results, which can be expanded on in the future.

Second, it became clear that the selection and creation of benchmarks has a severe impact on the progress and validity of the experiment. It was a double-edged sword, since any example that could be easily generated in a reasonable amount of time was too simple, and a very large, more appropriate example required far too much time to understand and convert than the time constraint allowed. Even when acceptable examples were found, second-order effects such as designer bias propagated through to the results.

Third, during the course of building case studies, it became apparent that very deep hierarchies are not useful for designing real systems. It was not possible to even conjure up an example with a hierarchy depth of more than two or three levels. The amount of nested state simply does not propagate that deep. This observation, if generally correct, implies that negative effects of deep state hierarchy on hardware should not be considered detrimental to their use. In these examples with only a couple layers, the overhead due to hierarchy was not extreme, and possibly was avoidable altogether by stripping all but leaf states from the hardware description.

Fourth, it was apparent from the last example that the maintenance of event ordering and the need for

3 In other words, more states can be packed into each bit of hardware as the number of states increases.

acknowledgements between blocks came with a heavy cost for the CFSM implementation. The monolithic Stateflow description, being statically scheduled, in a sense, did not require so much communication overhead, since the path taken and system state was always known.

Finally, it was clear that poor coding style in the VHDL generated by SF2VHD resulted in bloated hardware. This is a known possibility with HDL and synthesis, and appeared in this work with the arbiter example. With such a small state machine, the “lean and mean” CFSM implementation was much more efficient in hardware form than its Stateflow counterpart, and benefited from not having hierarchy getting in the way of that streamlined efficiency.

Future work on this project is needed to better understand what VHDL usage is causing the bloated hardware results with SF2VHD. It would also be nice to stitch together the Stateflow-based TCI design, and see how it performs in the rest of the system. Clearly the synchronous, hierarchical state machine results in less hardware (and therefore less cost in area and power). Once the timing of the Stateflow version is matched to the system (either by allowing synchronous communication or by adding asynchronous event triggers to the Stateflow interface), it can be modeled in VCC as a virtual component and perhaps used in the final system.

6. References 1. D. Harel; Statecharts: A Visual Formalism

for Complex Systems; Sci. Comput. Programs; 8:231-274; 1987.

Appendix The following pages contain sample code for the VHDL and Verilog implementations of the arbiter example. This code is extremely long, and is only included as part of an electronic submission so you can see the basic structure of the two approaches.

VHDL by SF2VHD -- VHDL generated by sf2vhd (Berkeley Wireless Research Center, 2000)-- from Simulink/Stateflow file protocol.mdl

library IEEE;use IEEE.std_logic_1164.all;use IEEE.std_logic_arith.all;

entity protocol isport(signal HostSend : in std_logic;

signal HostRecv : out std_logic;signal HostRecvData : out unsigned(7 downto 0);signal HostSendAck : out std_logic;signal Tx : out std_logic;signal TxData : out unsigned(7 downto 0);signal HostSendData : in unsigned(7 downto 0);signal HostRecvAck : in std_logic;signal Rx : in std_logic;signal RxData : in unsigned(7 downto 0);signal RxPar : in std_logic;signal RxAck : out std_logic;signal TxAck : in std_logic;signal RxNack : out std_logic;signal SFRESET : in bit;signal BCLK : in bit);

function CONV_STD_LOGIC(ARG: UNSIGNED) return STD_LOGIC isbegin

return ARG(0);end;

function "and" (L: UNSIGNED; R: INTEGER) return UNSIGNED is-- NOTE: This function probably should check if the integer is largerconstant Rv : UNSIGNED(L'length-1 downto 0) := CONV_UNSIGNED(R,L'length);variable res : UNSIGNED(L'length-1 downto 0);

beginfor i in L'range loop

res(i) := L(i) and Rv(i);end loop;return res;

end;

function "srl" (L: UNSIGNED; R: UNSIGNED) return UNSIGNED isbegin

return SHR(L,R);end;

function "srl" (L: SIGNED; R: UNSIGNED) return SIGNED isbegin

return SHR(L,R);end;

function "sll" (L: UNSIGNED; R: UNSIGNED) return UNSIGNED isbegin

return SHL(L,R);end;

function "sll" (L: SIGNED; R: UNSIGNED) return SIGNED isbegin

return SHL(L,R);end;

end protocol;

architecture behavior of protocol is

-- Constant data

-- Signals for all inputs, outputs, and local datasignal HostSend_SIG : std_logic;signal HostRecv_SIG : std_logic;signal HostRecv_NEXT : std_logic;signal HostRecvData_SIG : unsigned(7 downto 0);signal HostRecvData_NEXT : unsigned(7 downto 0);signal HostSendAck_SIG : std_logic;signal HostSendAck_NEXT : std_logic;signal Tx_SIG : std_logic;signal Tx_NEXT : std_logic;signal TxData_SIG : unsigned(7 downto 0);signal TxData_NEXT : unsigned(7 downto 0);signal HostSendData_SIG : unsigned(7 downto 0);signal HostRecvAck_SIG : std_logic;signal Rx_SIG : std_logic;signal RxData_SIG : unsigned(7 downto 0);signal RxPar_SIG : std_logic;signal RxAck_SIG : std_logic;signal RxAck_NEXT : std_logic;signal TxAck_SIG : std_logic;signal RxNack_SIG : std_logic;signal RxNack_NEXT : std_logic;signal bit0_SIG : std_logic;signal bit0_NEXT : std_logic;signal bit1_SIG : std_logic;signal bit1_NEXT : std_logic;signal bit2_SIG : std_logic;signal bit2_NEXT : std_logic;signal bit3_SIG : std_logic;signal bit3_NEXT : std_logic;signal bit4_SIG : std_logic;signal bit4_NEXT : std_logic;signal bit5_SIG : std_logic;signal bit5_NEXT : std_logic;signal bit6_SIG : std_logic;signal bit6_NEXT : std_logic;signal bit7_SIG : std_logic;signal bit7_NEXT : std_logic;signal parity_SIG : std_logic;signal parity_NEXT : std_logic;signal sending_SIG : std_logic;signal sending_NEXT : std_logic;signal state_SIG : integer range 0 to 8;signal state_NEXT : integer range 0 to 8;

begin

-- Map all input ports to signalsHostSend_SIG <= HostSend;HostSendData_SIG <= HostSendData;HostRecvAck_SIG <= HostRecvAck;Rx_SIG <= Rx;RxData_SIG <= RxData;RxPar_SIG <= RxPar;TxAck_SIG <= TxAck;

-- Map all output ports to logic output signalsHostRecv <= HostRecv_NEXT;HostRecvData <= HostRecvData_NEXT;HostSendAck <= HostSendAck_NEXT;Tx <= Tx_NEXT;TxData <= TxData_NEXT;RxAck <= RxAck_NEXT;RxNack <= RxNack_NEXT;

logical : process(HostSend_SIG,HostRecv_SIG,HostRecvData_SIG,HostSendAck_SIG,Tx_SIG,TxData_SIG,HostSendData_SIG,HostRecvAck_SIG,Rx_SIG,RxData_SIG,RxPar_SIG,RxAck_SIG,TxAck_SIG,RxNack_SIG,bit0_SIG,bit1_SIG,bit2_SIG,bit3_SIG,bit4_SIG,bit5_SIG,bit6_SIG,bit7_SIG,parity_SIG,sending_SIG,state_SIG,SFRESET)

variable HostSend_VAR : std_logic;variable HostRecv_VAR : std_logic;variable HostRecvData_VAR : unsigned(7 downto 0);variable HostSendAck_VAR : std_logic;variable Tx_VAR : std_logic;variable TxData_VAR : unsigned(7 downto 0);variable HostSendData_VAR : unsigned(7 downto 0);variable HostRecvAck_VAR : std_logic;variable Rx_VAR : std_logic;variable RxData_VAR : unsigned(7 downto 0);variable RxPar_VAR : std_logic;variable RxAck_VAR : std_logic;variable TxAck_VAR : std_logic;variable RxNack_VAR : std_logic;variable bit0_VAR : std_logic;variable bit1_VAR : std_logic;variable bit2_VAR : std_logic;variable bit3_VAR : std_logic;variable bit4_VAR : std_logic;variable bit5_VAR : std_logic;variable bit6_VAR : std_logic;variable bit7_VAR : std_logic;variable parity_VAR : std_logic;variable sending_VAR : std_logic;variable state_VAR : integer range 0 to 8;

begin

-- Begin with all variables assigned to the latched signalHostSend_VAR := HostSend_SIG;HostRecv_VAR := HostRecv_SIG;HostRecvData_VAR := HostRecvData_SIG;HostSendAck_VAR := HostSendAck_SIG;Tx_VAR := Tx_SIG;TxData_VAR := TxData_SIG;HostSendData_VAR := HostSendData_SIG;HostRecvAck_VAR := HostRecvAck_SIG;Rx_VAR := Rx_SIG;RxData_VAR := RxData_SIG;RxPar_VAR := RxPar_SIG;RxAck_VAR := RxAck_SIG;TxAck_VAR := TxAck_SIG;RxNack_VAR := RxNack_SIG;bit0_VAR := bit0_SIG;

bit1_VAR := bit1_SIG;bit2_VAR := bit2_SIG;bit3_VAR := bit3_SIG;bit4_VAR := bit4_SIG;bit5_VAR := bit5_SIG;bit6_VAR := bit6_SIG;bit7_VAR := bit7_SIG;parity_VAR := parity_SIG;sending_VAR := sending_SIG;state_VAR := state_SIG;

case state_SIG iswhen 1 => -- State: Idle

if ( HostSend_VAR = '1' and Rx_VAR = '0' ) then-- Traversing from junction 11if ( sending_VAR = '0' ) then

Tx_VAR := '1';TxData_VAR := CONV_UNSIGNED(HostSendData_VAR , 8);state_VAR := 4;sending_VAR := '1';

elsif ( TRUE ) thenstate_VAR := 4;sending_VAR := '1';

end if;elsif ( Rx_VAR = '1' ) then

state_VAR := 5;bit0_VAR := CONV_STD_LOGIC(RxData_VAR and 1);bit1_VAR := CONV_STD_LOGIC((RxData_VAR srl "001") and 1);bit2_VAR := CONV_STD_LOGIC((RxData_VAR srl "010") and 1);bit3_VAR := CONV_STD_LOGIC((RxData_VAR srl "011") and 1);bit4_VAR := CONV_STD_LOGIC((RxData_VAR srl "100") and 1);bit5_VAR := CONV_STD_LOGIC((RxData_VAR srl "101") and 1);bit6_VAR := CONV_STD_LOGIC((RxData_VAR srl "110") and 1);bit7_VAR := CONV_STD_LOGIC((RxData_VAR srl "111") and 1);parity_VAR := bit0_VAR xor bit1_VAR xor bit2_VAR xor

bit3_VAR xor bit4_VAR xor bit5_VAR xor bit6_VAR xor bit7_VAR;else

state_VAR := 1;end if;

when 2 => -- State: Transmitif ( Rx_VAR = '1' ) then

HostSendAck_VAR := '0';state_VAR := 5;bit0_VAR := CONV_STD_LOGIC(RxData_VAR and 1);bit1_VAR := CONV_STD_LOGIC((RxData_VAR srl "001") and 1);bit2_VAR := CONV_STD_LOGIC((RxData_VAR srl "010") and 1);bit3_VAR := CONV_STD_LOGIC((RxData_VAR srl "011") and 1);bit4_VAR := CONV_STD_LOGIC((RxData_VAR srl "100") and 1);bit5_VAR := CONV_STD_LOGIC((RxData_VAR srl "101") and 1);bit6_VAR := CONV_STD_LOGIC((RxData_VAR srl "110") and 1);bit7_VAR := CONV_STD_LOGIC((RxData_VAR srl "111") and 1);parity_VAR := bit0_VAR xor bit1_VAR xor bit2_VAR xor

bit3_VAR xor bit4_VAR xor bit5_VAR xor bit6_VAR xor bit7_VAR;else


-- Begin substates of Transmitwhen 4 => -- State: PassTxData

if ( Rx_VAR = '1' ) thenHostSendAck_VAR := '0';state_VAR := 5;bit0_VAR := CONV_STD_LOGIC(RxData_VAR and 1);bit1_VAR := CONV_STD_LOGIC((RxData_VAR srl "001") and 1);bit2_VAR := CONV_STD_LOGIC((RxData_VAR srl "010") and 1);bit3_VAR := CONV_STD_LOGIC((RxData_VAR srl "011") and 1);bit4_VAR := CONV_STD_LOGIC((RxData_VAR srl "100") and 1);bit5_VAR := CONV_STD_LOGIC((RxData_VAR srl "101") and 1);bit6_VAR := CONV_STD_LOGIC((RxData_VAR srl "110") and 1);bit7_VAR := CONV_STD_LOGIC((RxData_VAR srl "111") and 1);parity_VAR := bit0_VAR xor bit1_VAR xor bit2_VAR xor

bit3_VAR xor bit4_VAR xor bit5_VAR xor bit6_VAR xor bit7_VAR;

elsif ( TxAck_VAR = '1' ) thenTx_VAR := '0';state_VAR := 7;HostSendAck_VAR := '1';sending_VAR := '0';

elsestate_VAR := 4;

end if;when 7 => -- State: GotTxAck

if ( Rx_VAR = '1' ) thenHostSendAck_VAR := '0';state_VAR := 5;bit0_VAR := CONV_STD_LOGIC(RxData_VAR and 1);bit1_VAR := CONV_STD_LOGIC((RxData_VAR srl "001") and 1);bit2_VAR := CONV_STD_LOGIC((RxData_VAR srl "010") and 1);bit3_VAR := CONV_STD_LOGIC((RxData_VAR srl "011") and 1);bit4_VAR := CONV_STD_LOGIC((RxData_VAR srl "100") and 1);bit5_VAR := CONV_STD_LOGIC((RxData_VAR srl "101") and 1);bit6_VAR := CONV_STD_LOGIC((RxData_VAR srl "110") and 1);bit7_VAR := CONV_STD_LOGIC((RxData_VAR srl "111") and 1);parity_VAR := bit0_VAR xor bit1_VAR xor bit2_VAR xor

bit3_VAR xor bit4_VAR xor bit5_VAR xor bit6_VAR xor bit7_VAR;elsif ( TRUE ) then

HostSendAck_VAR := '0';state_VAR := 1;

elsestate_VAR := 7;

end if;-- End substates of Transmitwhen 3 => -- State: Receive

state_VAR := 3;-- Begin substates of Receivewhen 5 => -- State: CheckParity

if ( TRUE ) then-- Traversing from junction 13if ( parity_VAR /= RxPar_VAR ) then

RxNack_VAR := '1';state_VAR := 1;

elsif ( TRUE ) thenRxNack_VAR := '0';state_VAR := 8;HostRecv_VAR := '1';HostRecvData_VAR := CONV_UNSIGNED(RxData_VAR , 8);

end if;else


when 6 => -- State: GotHostAckif ( TRUE ) then

RxAck_VAR := '0';-- Traversing from junction 12if ( TRUE ) then

state_VAR := 1;elsif ( Rx_VAR = '1' ) then


elsestate_VAR := 6;

end if;when 8 => -- State: PassHRData

if ( HostRecvAck_VAR = '1' ) thenHostRecv_VAR := '0';state_VAR := 6;RxAck_VAR := '1';

elsestate_VAR := 8;

end if;-- End substates of Receivewhen others =>

NULL;end case;

if ( SFRESET = '0' ) then-- Set outputs and local data to their initial valueHostRecv_NEXT <= '0';HostRecvData_NEXT <= CONV_UNSIGNED(0,8);HostSendAck_NEXT <= '0';Tx_NEXT <= '0';TxData_NEXT <= CONV_UNSIGNED(0,8);RxAck_NEXT <= '0';RxNack_NEXT <= '0';bit0_NEXT <= '0';bit1_NEXT <= '0';bit2_NEXT <= '0';bit3_NEXT <= '0';bit4_NEXT <= '0';bit5_NEXT <= '0';bit6_NEXT <= '0';bit7_NEXT <= '0';parity_NEXT <= '0';sending_NEXT <= '0';-- Initial transition and state entry actionsstate_NEXT <= 1;

else-- Assign logic output signals to variable resultsHostRecv_NEXT <= HostRecv_VAR;HostRecvData_NEXT <= HostRecvData_VAR;HostSendAck_NEXT <= HostSendAck_VAR;Tx_NEXT <= Tx_VAR;TxData_NEXT <= TxData_VAR;RxAck_NEXT <= RxAck_VAR;RxNack_NEXT <= RxNack_VAR;bit0_NEXT <= bit0_VAR;bit1_NEXT <= bit1_VAR;bit2_NEXT <= bit2_VAR;bit3_NEXT <= bit3_VAR;bit4_NEXT <= bit4_VAR;bit5_NEXT <= bit5_VAR;bit6_NEXT <= bit6_VAR;bit7_NEXT <= bit7_VAR;parity_NEXT <= parity_VAR;sending_NEXT <= sending_VAR;state_NEXT <= state_VAR;

end if;

end process;

synch : process(BCLK)

begin

if (BCLK'EVENT and BCLK = '1') then

HostRecv_SIG <= HostRecv_NEXT;HostRecvData_SIG <= HostRecvData_NEXT;HostSendAck_SIG <= HostSendAck_NEXT;Tx_SIG <= Tx_NEXT;TxData_SIG <= TxData_NEXT;RxAck_SIG <= RxAck_NEXT;RxNack_SIG <= RxNack_NEXT;bit0_SIG <= bit0_NEXT;bit1_SIG <= bit1_NEXT;bit2_SIG <= bit2_NEXT;bit3_SIG <= bit3_NEXT;bit4_SIG <= bit4_NEXT;bit5_SIG <= bit5_NEXT;bit6_SIG <= bit6_NEXT;bit7_SIG <= bit7_NEXT;parity_SIG <= parity_NEXT;sending_SIG <= sending_NEXT;

state_SIG <= state_NEXT;

end if;

end process;

end behavior;

Verilog by buildVlog module prot_fsm( v_presence_RxPar, RxPar, v_presence_RxData, RxData, v_presence_clk, clk,v_presence_HostRecvAck, HostRecvAck, v_presence_RxAck, RxAck, v_presence_TxAck, TxAck,v_presence_HostSendAck, HostSendAck, v_presence_HostRecvData, HostRecvData,v_presence_HostSendData, HostSendData, v_presence_TxData, TxData, CLK );// Input/Output declarationsinput v_presence_RxPar;input RxPar;input v_presence_RxData;input [7:0] RxData;input v_presence_clk;input clk;input v_presence_HostRecvAck;input HostRecvAck;output v_presence_RxAck;output RxAck;input v_presence_TxAck;input TxAck;output v_presence_HostSendAck;output HostSendAck;output v_presence_HostRecvData;output [7:0] HostRecvData;input v_presence_HostSendData;input [7:0] HostSendData;output v_presence_TxData;output [7:0] TxData;input CLK;// Registers required for assignments to outputsreg v_presence_RxAck;reg RxAck;reg v_presence_HostSendAck;reg HostSendAck;reg v_presence_HostRecvData;reg [7:0] HostRecvData;reg v_presence_TxData;reg [7:0] TxData;// Internal variablesreg [2:0] state_new;reg sending_new;reg bit0_new;reg bit1_new;reg bit2_new;reg bit3_new;reg bit4_new;reg bit5_new;reg bit6_new;reg parity_new;reg bit7_new;reg PREVIOUS_RxAck;reg NEW_RxAck;reg PREVIOUS_HostSendAck;reg NEW_HostSendAck;reg [7:0] PREVIOUS_HostRecvData;reg [7:0] NEW_HostRecvData;reg [7:0] PREVIOUS_TxData;reg [7:0] NEW_TxData;reg [2:0] state;reg sending;reg bit0;reg bit1;reg bit2;reg bit3;reg bit4;

reg bit5;reg bit6;reg parity;reg bit7;// Constants

// Parameters

// Latch the states of the CFSMalways @( posedge CLK )beginPREVIOUS_RxAck = RxAck;PREVIOUS_HostSendAck = HostSendAck;PREVIOUS_HostRecvData = HostRecvData;PREVIOUS_TxData = TxData;state = state_new;sending = sending_new;bit0 = bit0_new;bit1 = bit1_new;bit2 = bit2_new;bit3 = bit3_new;bit4 = bit4_new;bit5 = bit5_new;bit6 = bit6_new;parity = parity_new;bit7 = bit7_new;

end

// Other combinational logicalways @( PREVIOUS_RxAck or NEW_RxAck or v_presence_RxAck )beginif ( v_presence_RxAck ) RxAck = NEW_RxAck;else RxAck = PREVIOUS_RxAck;

endalways @( PREVIOUS_HostSendAck or NEW_HostSendAck or v_presence_HostSendAck )beginif ( v_presence_HostSendAck ) HostSendAck = NEW_HostSendAck;else HostSendAck = PREVIOUS_HostSendAck;

endalways @( PREVIOUS_HostRecvData or NEW_HostRecvData or v_presence_HostRecvData )beginif ( v_presence_HostRecvData ) HostRecvData = NEW_HostRecvData;else HostRecvData = PREVIOUS_HostRecvData;

endalways @( PREVIOUS_TxData or NEW_TxData or v_presence_TxData )beginif ( v_presence_TxData ) TxData = NEW_TxData;else TxData = PREVIOUS_TxData;

end

always @( parity or v_presence_RxPar or RxPar or v_presence_RxData or RxData or bit0 or bit1 orbit2 or bit3 or bit4 or bit5 or bit6 or bit7 or state or v_presence_clk or clk orv_presence_HostRecvAck or HostRecvAck or v_presence_TxAck or TxAck or v_presence_HostSendData orHostSendData or sending )beginprot_fsm_tr( parity, v_presence_RxPar, RxPar, v_presence_RxData, RxData, bit0, bit1, bit2,

bit3, bit4, bit5, bit6, bit7, state, v_presence_clk, clk, v_presence_HostRecvAck, HostRecvAck,v_presence_RxAck, NEW_RxAck, v_presence_TxAck, TxAck, v_presence_HostSendAck, NEW_HostSendAck,v_presence_HostRecvData, NEW_HostRecvData, v_presence_HostSendData, HostSendData, sending,v_presence_TxData, NEW_TxData, state_new, sending_new, bit0_new, bit1_new, bit2_new, bit3_new,bit4_new, bit5_new, bit6_new, parity_new, bit7_new );end

task prot_fsm_tr;// Input/Output declarationsinput parity;input v_presence_RxPar;input RxPar;input v_presence_RxData;input [7:0] RxData;input bit0;

input bit1;input bit2;input bit3;input bit4;input bit5;input bit6;input bit7;input [2:0] state;input v_presence_clk;input clk;input v_presence_HostRecvAck;input HostRecvAck;output v_presence_RxAck;output RxAck;input v_presence_TxAck;input TxAck;output v_presence_HostSendAck;output HostSendAck;output v_presence_HostRecvData;output [7:0] HostRecvData;input v_presence_HostSendData;input [7:0] HostSendData;input sending;output v_presence_TxData;output [7:0] TxData;output [2:0] state_new;output sending_new;output bit0_new;output bit1_new;output bit2_new;output bit3_new;output bit4_new;output bit5_new;output bit6_new;output parity_new;output bit7_new;// Internal variablesreg [7:0] v_MOD2099;reg [7:0] v_EXP2101;reg [7:0] v_MOD2102;reg [7:0] v_EXP2104;reg [7:0] v_MOD2105;reg [7:0] v_EXP2107;reg [7:0] v_MOD2108;reg [7:0] v_EXP2110;reg [7:0] v_MOD2111;reg [7:0] v_EXP2113;reg [7:0] v_MOD2114;reg [7:0] v_EXP2116;reg [7:0] v_MOD2117;reg [7:0] v_EXP2119;reg [7:0] v_MOD2120;reg [7:0] v_EXP2122;reg [7:0] v_MOD2123;reg [7:0] v_EXP2125;reg [7:0] v_MOD2126;reg [7:0] v_EXP2128;reg [7:0] v_MOD2129;reg [7:0] v_EXP2131;reg [7:0] v_MOD2132;reg [7:0] v_EXP2134;reg [7:0] v_MOD2135;reg [7:0] v_EXP2137;reg [7:0] v_MOD2138;reg [7:0] v_EXP2140;reg [7:0] v_MOD2141;reg [7:0] v_EXP2143;reg [7:0] v_MOD2144;reg [7:0] v_EXP2146;reg [7:0] v_MOD2147;reg [7:0] v_EXP2149;

reg [7:0] v_MOD2150;reg [7:0] v_EXP2152;reg [7:0] v_MOD2153;reg [7:0] v_EXP2155;reg [7:0] v_MOD2156;reg [7:0] v_EXP2158;reg [7:0] v_MOD2159;reg [7:0] v_EXP2161;reg [7:0] v_MOD2162;reg [7:0] v_EXP2164;reg [7:0] v_MOD2165;reg [7:0] v_EXP2167;reg [7:0] v_MOD2168;reg [7:0] v_EXP2170;reg [7:0] v_MOD2171;reg v_XOR2173;reg v_XOR2174;reg v_XOR2175;reg v_XOR2176;reg v_XOR2177;reg v_XOR2178;reg [7:0] v_EXP2180;reg [7:0] v_MOD2181;reg [7:0] v_EXP2183;reg [7:0] v_MOD2184;reg [7:0] v_EXP2186;reg [7:0] v_MOD2187;reg [7:0] v_EXP2189;reg [7:0] v_MOD2190;reg v_presence___done_something;reg v_NE2097;reg v_EQ2098;reg v_EQ2100;reg v_EQ2103;reg v_EQ2106;reg v_EQ2109;reg v_EQ2112;reg v_EQ2115;reg v_EQ2118;reg v_EQ2121;reg v_EQ2124;reg v_EQ2127;reg v_EQ2130;reg v_EQ2133;reg v_EQ2136;reg v_EQ2139;reg v_EQ2142;reg v_EQ2145;reg v_EQ2148;reg v_EQ2151;reg v_EQ2154;reg v_EQ2157;reg v_EQ2160;reg v_EQ2163;reg v_EQ2166;reg v_EQ2169;reg v_EQ2172;reg v_XOR2179;reg v_EQ2182;reg v_EQ2185;reg v_EQ2188;reg v_EQ2191;// Constantsreg [7:0] const645;reg [7:0] const644;reg [7:0] const648;reg [7:0] const647;reg [7:0] const646;reg [7:0] const671;reg [7:0] const670;reg [7:0] const669;

reg [7:0] const694;reg [7:0] const693;reg [7:0] const692;reg [7:0] const717;reg [7:0] const716;reg [7:0] const715;reg [7:0] const651;reg [7:0] const650;reg [7:0] const649;reg [7:0] const674;reg [7:0] const673;reg [7:0] const672;reg [7:0] const697;reg [7:0] const696;reg [7:0] const695;reg [7:0] const720;reg [7:0] const719;reg [7:0] const718;reg [7:0] const654;reg [7:0] const653;reg [7:0] const652;reg [7:0] const677;reg [7:0] const676;reg [7:0] const675;reg [7:0] const700;reg [7:0] const699;reg [7:0] const698;reg [7:0] const723;reg [7:0] const722;reg [7:0] const721;reg [7:0] const657;reg [7:0] const656;reg [7:0] const655;reg [7:0] const680;reg [7:0] const679;reg [7:0] const678;reg [7:0] const703;reg [7:0] const702;reg [7:0] const701;reg [7:0] const726;reg [7:0] const725;reg [7:0] const724;reg [7:0] const660;reg [7:0] const659;reg [7:0] const658;reg [7:0] const683;reg [7:0] const682;reg [7:0] const681;reg [7:0] const706;reg [7:0] const705;reg [7:0] const704;reg [7:0] const729;reg [7:0] const728;reg [7:0] const727;reg [7:0] const663;reg [7:0] const662;reg [7:0] const661;reg [7:0] const686;reg [7:0] const685;reg [7:0] const684;reg [7:0] const709;reg [7:0] const708;reg [7:0] const707;reg [7:0] const732;reg [7:0] const731;reg [7:0] const730;reg [7:0] const666;reg [7:0] const665;reg [7:0] const664;reg [7:0] const689;reg [7:0] const688;

reg [7:0] const687;reg [7:0] const712;reg [7:0] const711;reg [7:0] const710;reg [7:0] const735;reg [7:0] const734;reg [7:0] const733;

beginconst645 = 8'b00000010;const644 = 8'b00000001;const648 = 8'b00000001;const647 = 8'b00000010;const646 = 8'b00000001;const671 = 8'b00000001;const670 = 8'b00000010;const669 = 8'b00000001;const694 = 8'b00000001;const693 = 8'b00000010;const692 = 8'b00000001;const717 = 8'b00000001;const716 = 8'b00000010;const715 = 8'b00000001;const651 = 8'b00000010;const650 = 8'b00000010;const649 = 8'b00000001;const674 = 8'b00000010;const673 = 8'b00000010;const672 = 8'b00000001;const697 = 8'b00000010;const696 = 8'b00000010;const695 = 8'b00000001;const720 = 8'b00000010;const719 = 8'b00000010;const718 = 8'b00000001;const654 = 8'b00000011;const653 = 8'b00000010;const652 = 8'b00000001;const677 = 8'b00000011;const676 = 8'b00000010;const675 = 8'b00000001;const700 = 8'b00000011;const699 = 8'b00000010;const698 = 8'b00000001;const723 = 8'b00000011;const722 = 8'b00000010;const721 = 8'b00000001;const657 = 8'b00000100;const656 = 8'b00000010;const655 = 8'b00000001;const680 = 8'b00000100;const679 = 8'b00000010;const678 = 8'b00000001;const703 = 8'b00000100;const702 = 8'b00000010;const701 = 8'b00000001;const726 = 8'b00000100;const725 = 8'b00000010;const724 = 8'b00000001;const660 = 8'b00000101;const659 = 8'b00000010;const658 = 8'b00000001;const683 = 8'b00000101;const682 = 8'b00000010;const681 = 8'b00000001;const706 = 8'b00000101;const705 = 8'b00000010;const704 = 8'b00000001;const729 = 8'b00000101;const728 = 8'b00000010;const727 = 8'b00000001;

const663 = 8'b00000110;const662 = 8'b00000010;const661 = 8'b00000001;const686 = 8'b00000110;const685 = 8'b00000010;const684 = 8'b00000001;const709 = 8'b00000110;const708 = 8'b00000010;const707 = 8'b00000001;const732 = 8'b00000110;const731 = 8'b00000010;const730 = 8'b00000001;const666 = 8'b00000111;const665 = 8'b00000010;const664 = 8'b00000001;const689 = 8'b00000111;const688 = 8'b00000010;const687 = 8'b00000001;const712 = 8'b00000111;const711 = 8'b00000010;const710 = 8'b00000001;const735 = 8'b00000111;const734 = 8'b00000010;const733 = 8'b00000001;v_NE2097 = ( parity != RxPar );v_EQ2098 = ( parity == RxPar );v_MOD2099 = ( RxData & 8'b00000001 );v_EQ2100 = ( v_MOD2099 == 1 );v_EXP2101 = ( RxData >> 1 );v_MOD2102 = ( v_EXP2101 & 8'b00000001 );v_EQ2103 = ( v_MOD2102 == 1 );v_EXP2104 = ( RxData >> 1 );v_MOD2105 = ( v_EXP2104 & 8'b00000001 );v_EQ2106 = ( v_MOD2105 == 1 );v_EXP2107 = ( RxData >> 1 );v_MOD2108 = ( v_EXP2107 & 8'b00000001 );v_EQ2109 = ( v_MOD2108 == 1 );v_EXP2110 = ( RxData >> 1 );v_MOD2111 = ( v_EXP2110 & 8'b00000001 );v_EQ2112 = ( v_MOD2111 == 1 );v_EXP2113 = ( RxData >> 2 );v_MOD2114 = ( v_EXP2113 & 8'b00000001 );v_EQ2115 = ( v_MOD2114 == 1 );v_EXP2116 = ( RxData >> 2 );v_MOD2117 = ( v_EXP2116 & 8'b00000001 );v_EQ2118 = ( v_MOD2117 == 1 );v_EXP2119 = ( RxData >> 2 );v_MOD2120 = ( v_EXP2119 & 8'b00000001 );v_EQ2121 = ( v_MOD2120 == 1 );v_EXP2122 = ( RxData >> 2 );v_MOD2123 = ( v_EXP2122 & 8'b00000001 );v_EQ2124 = ( v_MOD2123 == 1 );v_EXP2125 = ( RxData >> 3 );v_MOD2126 = ( v_EXP2125 & 8'b00000001 );v_EQ2127 = ( v_MOD2126 == 1 );v_EXP2128 = ( RxData >> 3 );v_MOD2129 = ( v_EXP2128 & 8'b00000001 );v_EQ2130 = ( v_MOD2129 == 1 );v_EXP2131 = ( RxData >> 3 );v_MOD2132 = ( v_EXP2131 & 8'b00000001 );v_EQ2133 = ( v_MOD2132 == 1 );v_EXP2134 = ( RxData >> 3 );v_MOD2135 = ( v_EXP2134 & 8'b00000001 );v_EQ2136 = ( v_MOD2135 == 1 );v_EXP2137 = ( RxData >> 4 );v_MOD2138 = ( v_EXP2137 & 8'b00000001 );v_EQ2139 = ( v_MOD2138 == 1 );v_EXP2140 = ( RxData >> 4 );v_MOD2141 = ( v_EXP2140 & 8'b00000001 );v_EQ2142 = ( v_MOD2141 == 1 );v_EXP2143 = ( RxData >> 4 );

v_MOD2144 = ( v_EXP2143 & 8'b00000001 );v_EQ2145 = ( v_MOD2144 == 1 );v_EXP2146 = ( RxData >> 4 );v_MOD2147 = ( v_EXP2146 & 8'b00000001 );v_EQ2148 = ( v_MOD2147 == 1 );v_EXP2149 = ( RxData >> 5 );v_MOD2150 = ( v_EXP2149 & 8'b00000001 );v_EQ2151 = ( v_MOD2150 == 1 );v_EXP2152 = ( RxData >> 5 );v_MOD2153 = ( v_EXP2152 & 8'b00000001 );v_EQ2154 = ( v_MOD2153 == 1 );v_EXP2155 = ( RxData >> 5 );v_MOD2156 = ( v_EXP2155 & 8'b00000001 );v_EQ2157 = ( v_MOD2156 == 1 );v_EXP2158 = ( RxData >> 5 );v_MOD2159 = ( v_EXP2158 & 8'b00000001 );v_EQ2160 = ( v_MOD2159 == 1 );v_EXP2161 = ( RxData >> 6 );v_MOD2162 = ( v_EXP2161 & 8'b00000001 );v_EQ2163 = ( v_MOD2162 == 1 );v_EXP2164 = ( RxData >> 6 );v_MOD2165 = ( v_EXP2164 & 8'b00000001 );v_EQ2166 = ( v_MOD2165 == 1 );v_EXP2167 = ( RxData >> 6 );v_MOD2168 = ( v_EXP2167 & 8'b00000001 );v_EQ2169 = ( v_MOD2168 == 1 );v_EXP2170 = ( RxData >> 6 );v_MOD2171 = ( v_EXP2170 & 8'b00000001 );v_EQ2172 = ( v_MOD2171 == 1 );v_XOR2173 = ( bit0 ^ bit1 );v_XOR2174 = ( v_XOR2173 ^ bit2 );v_XOR2175 = ( v_XOR2174 ^ bit3 );v_XOR2176 = ( v_XOR2175 ^ bit4 );v_XOR2177 = ( v_XOR2176 ^ bit5 );v_XOR2178 = ( v_XOR2177 ^ bit6 );v_XOR2179 = ( v_XOR2178 ^ bit7 );v_EXP2180 = ( RxData >> 7 );v_MOD2181 = ( v_EXP2180 & 8'b00000001 );v_EQ2182 = ( v_MOD2181 == 1 );v_EXP2183 = ( RxData >> 7 );v_MOD2184 = ( v_EXP2183 & 8'b00000001 );v_EQ2185 = ( v_MOD2184 == 1 );v_EXP2186 = ( RxData >> 7 );v_MOD2187 = ( v_EXP2186 & 8'b00000001 );v_EQ2188 = ( v_MOD2187 == 1 );v_EXP2189 = ( RxData >> 7 );v_MOD2190 = ( v_EXP2189 & 8'b00000001 );v_EQ2191 = ( v_MOD2190 == 1 );RxAck( state, v_presence_clk, v_NE2097, v_presence_HostRecvAck, v_presence_RxAck, RxAck,

v_presence___done_something );HostSendAck( state, v_presence_TxAck, v_presence_HostSendAck, HostSendAck,

v_presence___done_something );HostRecvData( v_presence_RxData, state, v_presence_clk, v_EQ2098, v_presence_HostRecvData,

HostRecvData, v_presence___done_something );TxData( v_presence_HostSendData, state, v_presence_HostSendData, v_presence_RxData,

sending, v_presence_TxData, TxData, v_presence___done_something );state_new( state, v_presence_RxData, v_presence_clk, v_presence_TxAck, v_EQ2098, v_NE2097,

v_presence_HostSendData, sending, v_presence_HostRecvAck, state_new, v_presence___done_something);

sending_new( state, v_presence_HostSendData, v_presence_RxData, sending, sending_new,v_presence___done_something );

bit0_new( v_EQ2100, state, v_presence_RxData, bit0_new, v_presence___done_something );bit1_new( v_EQ2103, state, v_presence_RxData, v_EQ2106, v_EQ2109, v_EQ2112, bit1_new,

v_presence___done_something );bit2_new( v_EQ2115, state, v_presence_RxData, v_EQ2118, v_EQ2121, v_EQ2124, bit2_new,



v_presence___done_something );

bit5_new( v_EQ2151, state, v_presence_RxData, v_EQ2154, v_EQ2157, v_EQ2160, bit5_new,v_presence___done_something );

bit6_new( v_EQ2163, state, v_presence_RxData, v_EQ2166, v_EQ2169, v_EQ2172, bit6_new,v_presence___done_something );

parity_new( v_XOR2179, state, v_presence_RxData, parity_new, v_presence___done_something );bit7_new( v_EQ2182, state, v_presence_RxData, v_EQ2185, v_EQ2188, v_EQ2191, bit7_new,

v_presence___done_something );

endendtask

task RxAck;// Input/Output declarationsinput [2:0] state;input v_presence_clk_e;input v_NE2097;input v_presence_HostRecvAck_e;output v_presence_RxAck;output RxAck;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition FunctionRxAck = 1'bx;v_presence_RxAck = 1'b0;v_presence___done_something = 1'b0;case ( state )3'b000: beginend

3'b001: beginend

3'b010: beginend

3'b011: begincase ( v_presence_clk_e )1'b0: beginend

1'b1: begincase ( v_NE2097 )1'b0: beginend

1'b1: beginRxAck = 1'b0;v_presence_RxAck = 1'b1;v_presence___done_something = 1'b1;

endendcase

endendcase

end3'b100: begin

case ( v_presence_HostRecvAck_e )1'b0: beginend

1'b1: beginRxAck = 1'b1;v_presence_RxAck = 1'b1;v_presence___done_something = 1'b1;

endendcase

end3'b101: beginend

3'b110: beginend

3'b111: beginend

endcase

endendtask

task HostSendAck;// Input/Output declarationsinput [2:0] state;input v_presence_TxAck_e;output v_presence_HostSendAck;output HostSendAck;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition FunctionHostSendAck = 1'bx;v_presence_HostSendAck = 1'b0;v_presence___done_something = 1'b0;case ( v_presence_TxAck_e )1'b0: beginend

1'b1: begincase ( state )3'b000: beginend

3'b001: beginv_presence_HostSendAck = 1'b1;v_presence___done_something = 1'b1;HostSendAck = 1'b1;

end3'b010: beginend

3'b011: beginend

3'b100: beginend

3'b101: beginend

3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

task HostRecvData;// Input/Output declarationsinput [7:0] RxData;input [2:0] state;input v_presence_clk_e;input v_EQ2098;output v_presence_HostRecvData;output [7:0] HostRecvData;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition FunctionHostRecvData = 8'bxxxxxxxx;v_presence_HostRecvData = 1'b0;v_presence___done_something = 1'b0;case ( v_EQ2098 )1'b0: beginend

1'b1: begin

case ( v_presence_clk_e )1'b0: beginend

1'b1: begincase ( state )3'b000: beginend

3'b001: beginend

3'b010: beginend

3'b011: beginv_presence_HostRecvData = 1'b1;v_presence___done_something = 1'b1;HostRecvData = RxData;

end3'b100: beginend

3'b101: beginend

3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endcaseend

endtask

task TxData;// Input/Output declarationsinput [7:0] HostSendData;input [2:0] state;input v_presence_HostSendData_e;input v_presence_RxData_e;input sending;output v_presence_TxData;output [7:0] TxData;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition FunctionTxData = 8'bxxxxxxxx;v_presence_TxData = 1'b0;v_presence___done_something = 1'b0;case ( sending )1'b0: begin

case ( v_presence_RxData_e )1'b0: begin

case ( v_presence_HostSendData_e )1'b0: beginend

1'b1: begincase ( state )3'b000: begin

v_presence_TxData = 1'b1;v_presence___done_something = 1'b1;TxData = HostSendData;

end3'b001: beginend

3'b010: beginend

3'b011: beginend

3'b100: beginend

3'b101: beginend

3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

1'b1: beginend

endcaseend

1'b1: beginend

endcaseend

endtask

task state_new;// Input/Output declarationsinput [2:0] state;input v_presence_RxData_e;input v_presence_clk_e;input v_presence_TxAck_e;input v_EQ2098;input v_NE2097;input v_presence_HostSendData_e;input sending;input v_presence_HostRecvAck_e;output [2:0] state_new;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition Functionstate_new = 3'bxxx;v_presence___done_something = 1'b0;case ( state )3'b000: begin

case ( v_presence_HostSendData_e )1'b0: begin

case ( v_presence_RxData_e )1'b0: beginend

1'b1: beginv_presence___done_something = 1'b1;state_new = 3'b011;

endendcase

end1'b1: begin


v_presence___done_something = 1'b1;state_new = 3'b001;

end1'b1: begin


endendcase

endendcase

end3'b001: begin

case ( v_presence_TxAck_e )1'b0: begin



endendcase

end1'b1: begin



end1'b1: begin


endendcase

endendcase

end3'b010: begin

case ( v_presence_clk_e )1'b0: begin



endendcase

end1'b1: begin



end1'b1: begin


endendcase

endendcase

end3'b011: begin

case ( v_presence_clk_e )1'b0: beginend

1'b1: begincase ( v_NE2097 )1'b0: begin

case ( v_EQ2098 )1'b0: beginend


endendcase

end1'b1: begin

case ( v_EQ2098 )1'b0: begin

v_presence___done_something = 1'b1;

state_new = 3'b000;end


endendcase

endendcase

endendcase

end3'b100: begin

case ( v_presence_HostRecvAck_e )1'b0: beginend


endendcase

end3'b101: begin

case ( v_presence_clk_e )1'b0: begin



endendcase

end1'b1: begin



end1'b1: begin


endendcase

endendcase

end3'b110: beginend

3'b111: beginend

endcaseend

endtask

task sending_new;// Input/Output declarationsinput [2:0] state;input v_presence_HostSendData_e;input v_presence_RxData_e;input sending;output sending_new;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition Functionsending_new = 1'bx;

v_presence___done_something = 1'b0;case ( v_presence_RxData_e )1'b0: begin

case ( v_presence_HostSendData_e )1'b0: beginend


v_presence___done_something = 1'b1;sending_new = 1'b1;

end3'b001: beginend

3'b010: beginend

3'b011: beginend

3'b100: beginend

3'b101: beginend

3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

1'b1: beginend

endcaseend

endtask

task bit0_new;// Input/Output declarationsinput v_EQ2100;input [2:0] state;input v_presence_RxData_e;output bit0_new;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition Functionbit0_new = 1'bx;v_presence___done_something = 1'b0;case ( v_presence_RxData_e )1'b0: beginend


v_presence___done_something = 1'b1;bit0_new = v_EQ2100;

end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: begin

end3'b101: begin


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

task bit1_new;// Input/Output declarationsinput v_EQ2103;input [2:0] state;input v_presence_RxData_e;input v_EQ2106;input v_EQ2109;input v_EQ2112;output bit1_new;output v_presence___done_something;// Internal variables// Constants

begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend

3'b101: beginv_presence___done_something = 1'b1;bit1_new = v_EQ2103;

end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

task bit2_new;// Input/Output declarationsinput v_EQ2115;

input [2:0] state;input v_presence_RxData_e;input v_EQ2118;input v_EQ2121;input v_EQ2124;output bit2_new;output v_presence___done_something;// Internal variables// Constants

begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask


begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask


begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask


begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

task bit6_new;// Input/Output declarationsinput v_EQ2163;input [2:0] state;

input v_presence_RxData_e;input v_EQ2166;input v_EQ2169;input v_EQ2172;output bit6_new;output v_presence___done_something;// Internal variables// Constants

begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

task parity_new;// Input/Output declarationsinput v_XOR2179;input [2:0] state;input v_presence_RxData_e;output parity_new;output v_presence___done_something;// Internal variables// Constants

begin

// S-Graph-derived Transition Functionparity_new = 1'bx;v_presence___done_something = 1'b0;case ( v_presence_RxData_e )1'b0: beginend


v_presence___done_something = 1'b1;

parity_new = v_XOR2179;end

3'b001: beginv_presence___done_something = 1'b1;parity_new = v_XOR2179;

end3'b010: begin

v_presence___done_something = 1'b1;parity_new = v_XOR2179;

end3'b011: beginend

3'b100: beginend

3'b101: beginv_presence___done_something = 1'b1;parity_new = v_XOR2179;

end3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask


begin




end3'b001: begin


end3'b010: begin


end3'b011: beginend

3'b100: beginend


end

3'b110: beginend

3'b111: beginend

endcaseend

endcaseend

endtask

endmodule

Documents

An Analysis of Hardware Generation Techniques for ... Stateflow and VCC ... better suited for designing these complex systems on ... The behavior of the state machine is modeled using