PCMCIA Network InterfaceMain issue of the work presented in this section is to implement an FPGA-based PCMCIA card prototype capable of emulating Symmetricom’s bc635/637PCI card behaviour. This card acts like a receiver module that provides precision time and frequency reference to the host computer system via PCI bus and furnishes it to the TDP network processor for packets processing and queuing. Time is acquired from either the GPS satellites using a supplied antenna/receiver or from time code signals.
The card chosen for this purpose is the COM-1300 ComBlock module. It is a PC card which supports communication with a host computer either through a standard1 6-bit PCMCIA or 32-bit CardBus Type II bus interface. It is essentially composed by a Xilinx Spartan-3XC3S400-4 FPGA, internally connected to a 32 MB volatile SDRAM, a flash memory and a microprocessor and interfaced to extern world with the bus interface itself and a 40 pin connector. The whole system is provided with a 40 MHz clock internally generated by a quartz oscillator, but that may be replaced any time with an external source trough the assigned connector’s pin.
Software running within the FPGA basically follows the 4 points previously mentioned. By giving it a stable 10 Mhz squared wave input signal and a 1PPS one, it has to generate an interrupt signal that gives network server a precise time reference for processing packets that must be sent over the net. Interrupt signal has to be handled with the higher system priority in order to have faster response and reduce latency and for this reason, a dedicated driver has to be written. FPGA communication is memory mapped so, driver simply reads from and writes to registers, i.e acknowledging an interrupt, asking for current GPS time stamp or setting a new output frequency values. "Plug and Play" PCMCIA bus solution ensures to this new prototype card to be compact, light and used with either laptop Pc or desktop. Higher portability and flexibility of the whole system that can be changed, carried and moved in a simpler way is one of the main task. 1 - FPGA InplementationSoftware running within the FPGA basically must satisfy 4 requirements:
By givingit a stable 10 Mhz squared wave input signal and a 1PPS one, it has to generate an interrupt signalthat gives network server a precise time reference for processing packets that must be sent over thenet. This has been practically done by creating two separated VHDL processes within the FPGA:
Interrupt signal is generated by a particular VHDL block that basically acts like a frequency divider. It takes the very stable 10 MHz input signals and lowers the frequency value according to the timing that is needed by network server to operate packet processing. Division is performed using a programmable counter driven by this 10 Mhz signal that changes output status signal any time count reaches the programmed value. This slowed-down version of the input squared wave signal is than processed to produce another signal that physically drives the interrupt line with the same frequency characteristic but a shorter pulse duration (i.e. max 100 us). This is needed in order to avoid interrupt line to be asserted for a longer time in case interrupt is not recognized by the system and so, not acknowledged.
Data exchange process between PC and card has been implemented as a FSM (Finite State Machine) that performs operations on data and commands sent by PC through the CardBus bus as shown in figure . FSM is basically composed by 2 logical states:
Communication is achieved by passing 32 bit command words to the FPGA input port that are than interpreted according to what previously presented in section \ref{Implement}. Since it is necessary to synchronize data exchange between PC and card and to buffer incoming or out coming data, an internal register structure is required. Registers are all 16 bit wide and used for:
According to the register structure presented, an allowed command can be any of the followings:
2 - Driver implementationInterrupt signal has to be handled with the higher system priority in order to have faster response and reduce latency and for this reason, a dedicated driver has to be written. Purpose of the driver is to provide a complete software support to com1300 PCMCIA card in order to let it act as close as possible to Symmetricom's PCI board. Basically it represents an interface to this card that provides control over the com1300 features that has been implemented on it. It can seen as a modify of the existing PCI driver version, a porting from Symmetricom's card to a newer but different card type. As for Symmetricom's driver, since not all this card features are required to network TDP server to work, com1300 driver does not furnish support to all its features but only to those routines needed by TDP and which are called by the TDP itself to manage packets. The driver is developed as a kernel module for FreeBSD, a unix-like OS. Driver's main task is to take care of handling PCI interrupts generated by the com1300 Programmable Periodic Output. In fact they represents the TF beginning in our system and is necessary to manage them through an interrupt service routine that must be allocated in the system using the dedicated bus method. This procedure is called at very high priority whenever a generic interrupt occurs and checks whether if Comblock card is the source of that interrupt or not. In case it is, it proceeds acknowledging it and than driving TDP scheduling (i.e. packets queuing, transmissions) in each node of the switch prototype. Time position within TC and TF must be traced in order to know the overall progress of packet flowing. Time reference is carried out by increasing three global counters: q_counter, tf_counter, and tc_counter; they respectively represent the current buffer from which TDP packets has being dequeued, the current TF, and the current TC. Moreover, it is necessary to acquire the current UTC time at the system start-up, in order to compute the initial value of TF and TC to assign to tf_counter and tc_counter. Driver must implement at least three necessary functions; one for probing and recognizing the card at the time it's plugged in the system, an attach routine that allocates resources for such card (i.e. memory, I/0 ports, interrupts...) ones it has been probed and a function to deallocate every allocated resourse.
Allocation of Cardbus memory and interrupt resources as data passing to and from Cardbus card are
achieved directly using a set of kernel functions FreeBSD offers to developers.
|
|||||||||
|