Revision as of 15:22, 23 January 2014

The HES-SO VME IP Core was designed within the project BasMI. Is is used in the VME Backplanes for interconnecting different Rack Boards together. This IP can be found on the EDA Repository: svn: https://repos.hevs.ch/svn/eda/

Introduction

At the moment of the creation of this document, some new FPGA development cards have been realized at the HES-SO Valais/Wallis Sion. There are the FPGA Rack V1 board (successor of the old FPGA-EBS, for general purpose) and the * FPGARack AD/DA V1 board (initially done for the OLGM project).

These new PCBs have Eurocard (100x160mm) size and a DIN41612 3x32pin connector soldered. So, this document describes the work realized around this new communication bus (physical and VHDL). The goal was to define and create the communication in the aforementioned DIN41612 conncetor. It was choosen to create a modified VME Bus called HVME (HES-SO VME).

Compatible Rack Boards

• HES-SO FPGA Rack Board
• HES-SO FPGA Rack AD-DA Board
• HES-SO FPGA Rack Debug Board

Available Rack Backplanes

• HES-SO FPGA Rack Backplane

Bus Specification

• Bus Specifications
• Signal Mapping
• Timing Diagrams

VHDL Implementation

Two controllers (master and slave) have been realized and are available in the EDA repository inside the VME library - with dependency to EDAC and Memory libraries.

Master Controller

The master controller is available under the name “VmeMasterController_Core”.

The first side, clocked at the core clock iCLOCK_CORE, offers to the user an input FIFO for all read/write requests (i/oCMD*) and a direct output for incoming slave read data (oRET*). Debugs signals are available for identify potential problems on the bus, like freezing (oDEBUGFLAG*). Let’s just take an example: you want to read data on the bus. The procedure is the following :

- Place the command request on all iCMD_* signals, where :

• • iCMD_ADDR is the address (right justified for 16bit device).
  • iCMD_DATAIN is the data to write (right justified for 16bit device).
  • iCMD_ECCEN enable the ECC management for this bus access (0: enabled, 1: disabled).
  • iCMD_SLVMODE set the access mode (0: 16bit, 1: 32bit).
  • iCMD_WR_RDn define if it’s a read (0) or write (1) operation.

The validation of the command has to be done by setting high iCMDVALID (only if oCMDREADY is high!). These requests can be bursted, because they are accumulated into a FIFO. If the FIFO is full (-1), it causes oCMDREADY signal to rise. - The controller processes the request during an undetermined time (depending on the FIFO occupation and ECC transmission error)... - When the oRETVALID is high, consume the slave data on oRET_DATAOUT.

Writing operation is similar, excepting no data are returned.

On the other side (the VME bus control) is clocked to iCLOCK_BUS – generally generated by a PLL consuming the core clock. All signals should be routed to the corresponding physical lines (VME_D, VME_ECC and VME_sReady must be “tristated” on top).

Three integer generics can be configured:

• gTXFifo_AddrWidth : Set the FIFO width for storing the incoming command requests. Resulting available cases are 2gTXFifo_AddrWidth-1.

• gWatchdog_CounterWidth : Number of iCLOCK_BUS cycles (during MFreeze or SReady are high, respectively, low) before give a bus frozen warning via oDEBUGFLAG_ECCREADERROR_WATCHDOG_OVERFLOW / SLAVEWAITREQ_WATCHDOG_OVERFLOW.

• gSyncStageCount : Number of stages for cross-domain data synchronization.

The master core uses two different clock inputs. On is the user accessible clock iCLOCK_CORE for the CMD and the RET signal interface. The other Clock input is used for the VME bus. The iCLOCK_CORE clock input is used to the logic and is also directly assigned to the oVME_CLOCK, it sets the overall VME clock speed.