DECISIONS TAKEN IN GENERATING THE VHDL CODE

The GCI Automation tool generates VHDL code for the data read in through the word document. Hence knowledge of VHDL is a pre-requisite in the formation of the tool. This forces the designer to consider what decisions are to be taken in the formation of the VHDL code right from the leaf level to the uppermost node. This step is meticulously followed since it facilitates efficient coding and further enhancements. This step enlists detailed information of the signals to be included in the entity, syntax and semantics of the language, generics involved, structure of the top-level multiplexers and also about the style of modeling to be used in particular design criteria. It also gives the coder an idea as to what statements are repetitive, where to assign specific access types and also as to what signals to concatenate in the generation of an output signal. The genesis of this VHDL entity is from the base level flip-flops being the utmost base level entities.

Signals that are to be serviced at this level are as follows:

1. reg_data_in: We need to determine the width of this signal. The width of this signal is available from the bit-width (BSW) summation, which is available from the second structure. Pointer to this particular data is bnkptr->no_of_bits.
2. reg_reset_input & gci_clk: These two signals are necessary signals since they determine the reset signals and the gci clock signals respectively that are inputted from the interface between the microprocessor, the gci and the core.
3. write_request: this is one more input signal, which is essential to be specified. This request can be made by the core to the GCI or by the microprocessor to the GCI. Accordingly the code has to be written for the write request signal.
4. reg_data_out: reg_data_out obviously is an output signal, which is the outlet to the entity at base level. Its width depends upon the BSW and the reset signal.
5. regsel: Enable signal for the flip-flop which is used at base level. regsel signal is clubbed with the enable signals in each component instantiations.

Check –1:

If the reg_reset_input signal is high then the reg_data_out signal will naturally be the concatenation of all the default values, present in the table. Secondly we have to check whether individual resets in each base level flip flop is high. If this regsel signal is high then data_out of that flip flop is the default value. All other flip-flop’s data_out is the value stored in it.

Check-2:

It may so happen that a particular number of flip flop may be of UNUSED status. If this is the case then the data_out of that flip-flop will contain the default value already specified in the table for that register. Check-2 also becomes very important in the context that we don’t have to instantiate components for the unused bits, as it would lead to unnecessary wastage of memory space and resources. Hence it becomes very necessary to know the unused or rather the used bits only. The starting bits and ending bits SBN and EBN respectively will be given by the structure so the bus width of each row in the table will be known. By scrutinizing the ACCESS type given by the structure we can conclude whether the bits are unused or not. If the ACCESS type doesn’t match to pre-defined formats then (EBN –SBN) number of bits will have default values at their respective data_out signals.

Components for (total _no_of_bits – unsued_bits – resetted_bits) will have to be instantiated and the concatenation of the data_out for these bits is done to form the reg_data_out signal. To provide functionality to each bit in the table we are instantiating a component for each bit. This component is nothing but a simple flip-flop.

MULTIPLEXER DESIGN FOR THE SAME REGISTER TYPE

This multiplexer is the next level of hierarchy after the basic register entity. The register multiplexers and the registers are then declared as components in the structural modeling for the bank entity

Here is an algorithm to generate VHDL code for this multiplexer:

• The register enable input is declared in this entity. This signal will be given to the address decoder. This requires just writing to file instructions
• The packet counter signals are again input signals, the output is in the format

Registername_data_tx.

• The above signals have to be read from the word file and hence it requires file handling operations
• We have to multiplex the appropriate signals to the register data output depending upon the register enable input. For this purpose we first of all have to count the no of register banks given by TOP.size()
• String comparison has to be done in Java so that we generate the appropriate enable code. Method followed is one hot method of decoding
• The file reading has to be done carefully to note down the exact signals that are interfaced in the different banks.

• This is the next level after we create a mux for each bank in the TOP linked list.
• For particular bank entity type we have to declare the individual registers in the bank, the bank multiplexers etc as components in the register bank entity.

Eg:

Here tx_intr is the interrupt bank, which contains individual registers and the multiplexer:

interfaces of this entity);

thus the bank will be created .The output of this bank structure will be muxed to the Tx-Multiplexer depending upon register enables of the address decoder.