Programmable Logic

Reconstruction, Maintenance, and Archival of FPGAs

The trials and tribulations of modifying FPGAs when no documentation is available.

by Shay Wasser and Moshik Antebi

In the summer of 1995, our R&D group at ECI Telecom (Petach Tikva, Israel) had to modify a Xilinx 3042 FPGA that was controlling the system. At that time, we discovered our two-year-old system needed some modifications. It was felt that the modification was "only a matter of downloading a new netlist." It turned out, however, to be a bit more complicated than expected.

The FPGA is a part of a trunk interface card that performs the E1/T1 interface of our product. We wanted to modify the FPGA so that it would split the "common channel signaling," supporting four independent channels, rather than four with the same signaling source.

Unfortunately, there were two major problems with the modification:

1. The engineer that designed the chip resigned and left no documentation or source files other than the logic cell array (LCA) file. In addition, the designer created the original design on a demo workstation that our company later returned to the vendor. Unfortunately, our company did not retrieve the design from the demo workstation's hard drive.
2. Because of the many systems that are being used in the field, we could not replace the Xilinx 3042s with 3042As, which have more routing resources, or replace them with the Xilinx 3142-2 for more speed. It would be far too expensive for people to send us the boards or to send a technician to rework parts in the field. Our only feasible choice was to stay with the same part, the XC3042-70 in a 100 pin QFP.

We had to decide whether we were going to start from scratch or keep the current design and add to it. If we started from scratch, it meant that the part would require six months of system integration because the functions of the chip would change. We chose to add to the current design because it would only require a minimal amount of integration time.

Several of the system's features were not readily apparent when we began the design. Because the assignment of pins on the device could not change, we were constrained by the chip's timing and routing resources. In our case, the device only had 30 free configurable logic blocks (CLBs) to accommodate the change.

The way to solve the problems We used a variety of tools to perform the modification: Schematic Maker from Intergraph Corp. (Huntsville, AB), NeoCAD from NeoCAD Inc. (Boulder, CO), XACT 5.1 and XACT Foundry 7.0 from Xilinx Corp. (San Jose, CA), and Synario from Synario Design Automation (Redmond, WA). We performed the modification in four steps:

1. We created a schematic from the LCA file.
2. From the schematic, we created an LCA that matched the current chip.
3. We wrote a VHDL description of the new section.
4. We combined the two sections with minimum timing changes.

Intergraph's Schematic Maker helped us integrate the modified part into our system. The tool converted an LCA file into a schematic file in the normal Intergraph environment, 210.sbk. However, the tool's conversion created a rat's nest of AND/OR gates and flip-flops. It also changed all the node names such that using a "guide file" was useless--guide file is an LCA file that holds the previous design before an incremental change; it permits fast changes to the existing layout by only routing the changes to the original design.

Figure 1. The signaling detector changed from a single output across two time slots, (TS-16-1) and (TS-16-2), to separate outputs for each.

When Schematic-Maker changed the net names, the guide file reacted by changing all of the nets; thus, the timing was effected. Luckily, we found that the XACT underscore was changed to ~ by Schematic-Maker. Once we changed ~ back to _ in the schematic, the original and regenerated LCA files matched.

Now we were ready to add our engineering change request (ECR) to the schematic. We didn't just add a schematic page to the design of the chip. We first wrote the addition in VHDL, simulated it, then added a block of schematic representing the change as a hierarchy page in the schematic. Finally, we ran it through XACT 5.1 for routing and XACT Foundry 7.0 for refining the results.

Details of circuit operation The two bit streams contain four different trunks. When the Man Machine Interface (MMI) defines a certain signaling source, all 4 trunks use the same source because there isn't an option in the MMI to define the signaling source of each channel.

Two 4 Mbyte/s bit streams enter the FPGA. The two bit streams are interleaved like a comb. Time slot 16 (TS-16) is intended to transfer the Signaling signals in frames 1-15 and to synchronize the multiframe pattern in frame 0.

The functions of the FPGA in TS-16 include identification of this location in the bit stream and in the multiframe, and insertion of the required Signaling signal. The insertion of the correct TS-16 in the appropriate channel is performed in a number of stages:

• At system boot time, the CPU writes the signaling type mode of every channel to the FPGA. This data is saved in eight registers.
• A logic system gets the output detectors X1, X2, X11, X22 and the registers' outputs produce control signals for the multiplexer (MUX) module.
• A System of two MUXs for every composite bit stream provides speed of 4 Mbyte/s.

For every channel there are two 4-bit registers that save the signaling mode. The upper nibble contains the idle signal (relevant only for local-generator mode). And the lower nibble contains the information about the signaling operation mode (see Table 1). For every write of the CPU to the Xilinx FPGA, the upper nibble contains the same idle signal, and the lower nibble increments the register number in M2 and M3, while M0 and M1 contain the particular signaling operation mode of every channel.

Table 1. The coding M0 and M1 define the type of signaling, and M2 and M3 determine the channel.

The insertion of the correct TS-16 occurs only on frame 1 to frame 15. In frame 0, we just zero the upper nibble for multi-frame alignment. The upper part of the schematic in Figure 2 shows the detector, which detects frame 0 and the upper nibble on TS-16 in this frame. At the lower part of Figure 2 there is an identifier of the signaling operation mode. The output will go to zero during the time of the upper nibble just in frame number 0 of TS-16.

In normal operation (except in TS-16) Z0 is low, such that the bit stream is transferred without change. If the signaling type, for instance, is Local Gen or Signaling for channel 1, then at the time of TS-16-1, Z0 will go high (Z1 is "don't care"), and the desired signaling will pass. After the TS-16-2 period, Z0 will return to low, the other time slots pass transparently.

In the existing version, the TS-16 detector rises to "1" for the duration of time slot 16 of bit-stream number 1 (TS-16-1) and time slot 16 of bit-stream number 2 (TS-16-2). This means the duration of time-slot 16 is twice as long as a time slot for a single bit stream (see Figure 1 ).

The ECR allows us to define the source of the information in TS-16 for each channel individually. However, the idle signal patterns stay identical for all the channels that use the local-generator signaling source inside the chip.

Figure 2. The schematic shows the design of the new detector and MUX module.

In the new version, we separated the two TS-16s with a separate detector for TS-16-1 and TS-16-2. Thus, detection of TS-16 is performed by decoding the outputs of a modulo 512 counter. The TS-16-1 is high between the counts of 256 and 263. TS-16-2 is high between 264 and 271. The same separation occurs for TS-16-3 and TS-16-4 channels (see Figure 1 ).

Using the CAE tools As mentioned before, the new design is based on the old design, plus the changes inserted in a separate schematic page. When we started the modification, we only had an LCA file left over from the previous design. From this file, we created a schematic file that contained the chip's information in a gate-level form.

We performed the following functions to generate a schematic file in Intergraph's SBK format from the LCA file:

1. The 210.lca file was converted to a 210.xnf file with the assistance of the XDM utility lca2xnf in the XACT 5.1 package.
2. Under the new Xilinx environment of the Intergraph software, we performed xnf2edif in order to receive a file in EDIF format.
3. With the help of Schematic Maker, we performed a translation from EDIF format to schematic (SBK).

After we created the schematic of the old LCA, we created a top-level design that includes two hierarchical blocks. The first block represents the old LCA and the other represents the new addition (see Figure 3 ).

Top-level design At this point in the modification process, the new design consists of three draft files (SBK): connect.sbk , a top-level hierarchy page that contains the original module design and its association to the correction that was inserted; 210.sbk , the original (old) design with the addition of hierarchy pins in the spots where the change should take place; and qdli-1.sbk , the schematic page that describes the change.

The schematic file is examined by the Intergraph utilities "danceplus" and "drink": danceplus -n -t connect.sbk ; drink

The connect.sbk file automatically calls the other files in the lowest hierarchy. The switches -T and -N represent the hierarchy schematic (tree) and nested pages, respectively.

From the schematic file, we perform a conversion to a udb file. This is performed with the following command: sbktoudb connect.sbk

After running this command, we receive a connect.udb file; then we convert the udb file to an xnf file: udb2xnf -p=3042pq100-70 connect.udb

After running this set of commands, we receive three xnf files.

In the XACT XDM, we use the xnfmerge function to merge the three xnf files, created earlier, into one xnf file.

Placement, mapping, and routing Before mapping the chip, we created a NeoCAD preference file. In the conversion process of the original 210.lca file to an xnf file, an additional file, which has an extension of SCP, is created. This additional file, is a constraint file of the original design that defines the external pins and logic placement.

We changed the extension of the file from SCP to CST so that it will be recognized by XACT 5.1 and NeoCAD's translate function.

Under NeoCAD, we run the mapsh function and choose the Translate option, instead of Map. Then we convert the connect-mrg.xnf file to an NCD file with a constraint file (CST) that we created previously. In this process, we choose to lock the placement and the routing. We then created a file with the extension PRF, which is virtually a translation of the CST file to the format that the NeoCAD place and route tool understands.

Final FPGA place and route We began the process of mapping the logic to the component using the NeoCAD place and route tool. We began by typing mapsh at the command line in the "FPGA evaluator shell dialog box" of the NeoCAD tool user-interface. Next, we chose the MAP function. We selected connect-mrg.xnf as the source file. The file after the mapping was maped.ncd .

The mapping function in the FPGA evaluator shell dialog box has a few switches.

Under Options, we performed the following:

• Mark the part number and its speed.
• Write the Preference file name.
• remove unused logic
• pack logic block = 80

Under Advanced Features, we performed the following:

• register ordering
• use di pin

We performed place & route implementation using NeoCAD's parsh. In this function there are also a few switches:

Under Placement Options, we performed the following:

• run until solved
• minimal skew on all clocks
• save best = 1 runs

Under Router Options, we performed the following:

• automatic
• number of cost based cleanup passes = 19
• do clean up if fully routed
• number of passes = 18

We then placed the results in a special directory called post.dir.

Making a bit stream file and loading file With the bitsh function of the NeoCAD place and route tool, we created a BIT file and MCS file.

To create a bit file, we chose the following switches when the bitsh function was running:

• Select the XC3000 family
• operation = bitgen

Under options, we performed the following:

• run drc
• tie down unused interconnect

Note that the Work file is the file we created from the parsh function under post.dir (5_xx.ncd) . The output is 5_xx.bit .

We generated an MCS loading file with the help of the bitsh function, with the following switches:

• operation = promgen

Under Options, we performed the following:

• bit file = 5_xx.bit
• prom size = 32k
• prom format = prom mcs-86
• load position = up
• load address = 0

Archival of FPGA Because of our problems with poor or missing documentation, we defined methods for version and revision control, archive management, backup methods, software release, and executable file creation for all programmable chips. Details of what we did are listed below.

The hardware group used many CAD tools to develop programmable parts. These parts are divided into two main categories: (1) files that are loaded in the boot process and (2) files that are used by the hardware chip programming device. The chip programmer can be a dedicated bit stream, JTAG, or a dedicated or multi-purpose programmer.

The hardware development staff responsibilities, with regard to Software Configuration Management, are defined as follows:

The developer The developer implements the software-hardware changes as required by the project management and then he or she tests the changes. He or she also coordinates the release of the version with his or her project manager and saves the files in the software archive.

Figure 3. This schematic shows the connection of the new section to the existing design.

The project manager The project manager (PM) tracks and checks the release of a new version. The PM checks that all the hardware designs, documents, and bug lists are in their appropriate directories. Then, the PM signs the proper document for manual routing of Xilinx parts and makes sure the work is not done on demo units. Finally, the PM releases software versions to other groups.

The archiver The archiver saves all PALs, PROMs, CPLDs, and FPGAs data forms in the PVCS environment. He or she ensures that all the files that are needed to recreate the current revision are present. He or she then saves in physical form the CAD development software (CD-ROM or tape), its revision, hardware key, license file. Finally, he or she saves the computer type, identification, and environment, such as autoexec.bat, config.sys, or hostid (for Unix stations).

The software configuration manager The software configuration manager (SCM) creates the software archive and maintains it. The SCM generates the supporting Make and Batch procedures, makes backup files, and grants the correct access rights to each user. He or she also supports users who require help using the software archive.

The software configuration management supports the following hardware development issues:

• Archive structure.
• Version and revision control.
• Security and maintenance.
• Executable buildup.
• Bug documentation.
• Backup methods.
• Attributes.
• Tools documentation.

In conclusion, we learned a few valuable lessons from this ordeal. First, never develop a programmable part on a demo station. Second, make sure that once the chip is ready there is enough documentation to maintain the chip in an easy manner. Third, interrogate your designer to find out if manual routing/partitioning was needed for the completion of the device. If so, make sure that the manual routes/partitioning and the reasons for the manual intervention are well documented. And finally, educate your designers about the R&D flow, including archiving.

Note to the reader NeoCAD Inc. was purchased by Xilinx Inc. and the NeoCAD tool has now been integrated into Xilinx's XACT Foundry software. Also, Intergraph created a new company called VeriBest (Boulder, CO). Schematic Maker is now called the VeriBest Schematic Generator--it is offered as part of the VeriBest High-Level Design suite of tools.

Shay Wasser is a hardware group manager at ECI Telecom (Petach Tikva, Israel). Moshik Antebi is a hardware designer at ECI Telecom (Petach Tikva, Israel).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  October 1996