In this post, we'll start by looking at the schematics, and define what is connected to what, and what internal controller is responsible for operating the DMA chip we have on board. We'll then fetch the required information from the documentation, and define the required setup. The SROM controller of the S5PV is described in the user manual, it goes into timing diagrams and properties essential for controlling SRAM modules, so one has to match these values to whatever module is used. The timing data is described in the DMAEP datasheet, fortunately, I did not have to go through it, as the timing configuration was available in the Linux kernel port of this chip's driver, I simply copied it, and trusted it. From DMAEP datasheet, we know that we have two distinct operating modes, our chip corresponds to the bit operating mode, so we expect our data bus to be bits wide, looking at S5PV's user manual, section 2.
|Published (Last):||10 September 2013|
|PDF File Size:||10.80 Mb|
|ePub File Size:||17.12 Mb|
|Price:||Free* [*Free Regsitration Required]|
Currently, there are several projects that make use of the DE2 Ethernet port. However, none of these projects focused on creating a modular platform to allow for easy integrate with higher layer protocols. A major deficiency is the lack of a full hardware implementation that can allow for the easy implementation of higher layer protocols.
We hope that our project will be beneficial for future groups looking to make use of Ethernet without the requirement of adding a NIOS to their hardware. If the trend continues, connectivity will have an increasingly important role in product design. After looking at prior years projects it became apparent that there was not a good hardware implementation of Ethernet that also allowed for the addition of higher level protocols.
We desired to pursue this project as it explored new hardware not addressed during any other labs and we believe that a good implementation could provide to be very useful for student projects in the future. Our project will initialize the Ethernet chip and then provides routines for sending and receiving packets from the link.
The code was designed to be modular to simplify the addition of higher layer protocols. See the diagram in the hardware section for a visual depiction of the project module interconnections. We created a general module that contained all the hardware needed to send and receive basic packets. Adding the Ethernet Top module expands our implementation to send Ethernet frames. For our project we decided to use a fully hardware approach.
Our goal of the project was to construct a hardware module capable of Ethernet frame transmission. Overall a hardware only approach will increase the processing speed of the Ethernet unit. However, the most significant improvement is the ability to have a link layer protocol enabled in hardware without necessarily introducing a NIOS to the system. This will save in both gates and system complexity.
Additionally the modular approach allows for the addition of higher layer protocols if need be. As we aimed to make our project as universal as possible we adhere to the RFC standards. As we implemented Ethernet frames we adhered to the standard as depicted below. The system is designed comprising of several smaller modules. A block diagram of the physical connections between the modules is shown below.
All communication between external hardware and the Davidcom Ethernet chip is initiated by the Ethernet Top interface. We provide an example program for interfacing with the chip as well as outline the communication process below.
Our internal modules will control data flow and port access of the Davidcom chip via grants from an arbiter. Once access is granted to an originating module the data passes to the Ethernet controller module which contains the state machine for communicating with the Ethernet chip.
Ethernet Top is a module that instantiates and connects the blocks necessary to implement the link layer protocol. This includes instantiating the Receive Ethernet and Send Ethernet modules. This includes the interface that is to be accessed by the users wishing to use our module. As this module also encompass the DMa controller there are also all the ports that interface with the Ethernet chip. These will be discussed later. The interface ports provide the user with an easy way to 'black box' interface with the on board Ethernet controller.
Our interface uses a handshaking technique for packet reception and transmission. For both the receive and send interfaces there are 4 ports used. Additionally, an interrupt signal is output for received packets.
The interfacing module will wait until the data ready line is driven high. Our module will then transmit notify the interfacing module when the transmit or read is complete. An example interface is provided in TXDemo. This module provides the functionality to send Ethernet frames using MAC addressing. The input and output ports for interfacing are as described in the top level Ethernet Top Module.
The purpose of this module is to construct the Ethernet frame as depicted in the Standards section. In the general state the state machine begins in a waiting state. Once an external module requests to sent a packet the module will begin to wait for a grant from the internal arbiter.
Once the grant is given the machine will begin to read the source MAC address from the chip's registers. This data is then stored into internal registers to be used when constructing the frame.
The MAC addresses are the first bytes sent to the tx buffer. This can easily be changed in code. Once the MAC is sent the module sets the protocol type. Next the data is read from the inputs and is forwarded to the tx buffer.
The module knows that the sender is done transmitting data when the request line is cleared. Once the transmission completes successfully, the module will indicate the successful transmission to the interfacing module.
The second link layer module is Receive Ethernet Packet module which serves to construct a Ethernet frame and provide an interface with external hardware.
Much simpler than the send module, the receive module contains 4 states. It begins by entering the waiting state. When an Ethernet receive request arrives the module begins to wait until it has access to the data, once the data is ready it will begin the read the header data.
This data is then dumped and un-used as we do no implement a CRC check. After the header is read the data portion of the packet is clocked out on its data out port. When all data is read it will set the transmission complete line for one cycle before returning to the waiting state. The module instantiates several modules including a TX and RX controller, a register access, initialization and interrupt detection module these modules will all communicate with the the Ethernet controller as dictated by the arbitrator.
The Ethernet Controller module controls the bit timing and communication to the Ethernet chip. The Ethernet chip provides several interface ports for communication these include a a chip select port, a command port to indicate address or data, a write enable port, a read enable port, 16 bits of data.
As one data port is used for both the reads and the writes we determine in the Ethernet controller whether the data is being read or written. To write to one of the controller's registers we must stick to a strict timing and data sequence. To begin writing to the Ethernet controller one must pull low the chip select pin and write the appropriate command. To begin a write to the chip we would issue an address type write.
Therefore, our data line would indicate the address of the register where we want to write. The write data is held for at least one cycle before being driven low. A minimum of 2 cycle wait is required before we can begin to write data to certain registers. After the the data may begin to be written.
This follows the same sequence as the address write however the command will be set to data. For specific timing values we consulted section To read from the controller a similar process is followed.
To read from a register in the controller we must first write the address of the register we want to read from to the controller. For this process we follow the write command sequence as outlined above.
However, instead of writing again after the address write, we will draw the read line low and begin reading the data form the controller. The controller has a built in auto incrementing address for the read register, therefore it allows for sequential reads from registers without the need of writing an address every time. The specific timing for the reads was pulled from the datasheet section The controller arbiter directs communication between the modules. In order to communicate with the Davidcom chip all data must pass though the arbiter.
A module wishing to communicate with the Ethernet chip will first need to issue a communication request to the arbiter. The arbiter will then grant the request to the modules in the following priority order: interrupt, register access, packet receive, packet send modules assuming all packets arrive at the same time. The arbiter will determine which module to grant access to based on priority and will notify the module that it now has access to the Ethernet controller.
Combinationally, the proper outputs are assigned in the arbiter. The Ethernet controller is the module that controls communication and data timing with the Davidcom Ethernet chip. Its purpose is to provide a simple modular interface to talk with the Ethernet chip hardware.
All of the inputs to the Ethernet controller come from either the arbiter or DMa Ethernet chip. After reset, the Ethernet controller enters the wait state.
In this state the controller is waiting for a start command from the arbiter. Once that command is received the controller will latch the data on its inputs. It then begins the sequence to communicate with the Ethernet chip. We designed the controller to be somewhat conservative with the timing as we found this gave us reliable performance. Once the write of the address takes place the controller will then either enter the write or read sequence depending on the command input form the arbiter.
The read and write sequence will all be handled as described in the DMa section. Depending on whether a read or a write is being performed we will drive the output data line with data from the read or write registers respectively. The Initialization module is one of the 5 modules that provides data to the Ethernet controller.
Its sole purpose is to properly initialize the DMa Ethernet chip. We perform this function by storing all the initialization sequence in ROM and read it back during init.
The init sequence is started by pressing button 2 on the DE2 board. The initialization module will then issue a request to the arbiter.
DM9000 - ISA TO ETHERNET MAC CONTROLLER WITH INTEGRATED 10/100 PHY
Datasheet - Cyclone II
DM9000, DM9000A, DM9000AE