Electronic – How to meaningfully compare Xilinx MCS files

fpgaxilinx

Brief

I have two different boards with Xilinx designs that might be the same design. I am trying to compare the different MCS files to see if the designs in them are in fact the same design. Can this be done?

Details

I am looking at two old designs which both employ Xilinx XC3090 FPGAs. (Yeah, like I said… old.) Let's call these two designs "Jekyll" and "Hyde". I am trying to figure out how to replace these old FPGA designs with a newer FPGA design. Jekyll and Hyde look like they might contain identical FPGA designs. If they are in fact identical, then my task is twice as easy. I'm trying to figure out if they are truly identical FPGA designs.

  • Both Jekyll and Hyde contain three of the same devices (XC3090 FPGA) with different designs in each of the three devices.
  • The designs for Jekyll and Hyde look very similar. The pin names on FPGA1 on Jekyll are almost identical to the pin names on FPGA1 on Hyde, and so forth. The differences look like they could "probably" be just naming differences rather than differences in actual function.
  • One major difference between Jekyll and Hyde is that Jekyll uses one single Xilinx boot PROM to configure all three FPGAs, while Hyde is using an individual boot PROM for each of its three FPGAs.
  • I have a full set of design files for Jekyll, so it's pretty straightforward to figure out what's going on there.
  • For Hyde, I only have the .MCS files that are used to program the Xilinx boot PROM. Unfortunately it looks like the design files have been lost to the mists of time.

The Basic Question

So I have one design (Jekyll) which has a .MCS file that configures all three FPGAs in a daisy-chain, and another design (Hyde) where I have three individual .MCS files. Is there any reasonable way for me to confirm whether the three .MCS files from Hyde contain the same FPGA logic as the one .MCS file from Jekyll?

The Advanced "10,000 bonus points" Question

If we can confirm that Jekyll and Hyde are in fact different, is there any reasonable way to see whether the differences are trivial (e.g. just one more signal in the overall design) versus substantive (e.g. a whole collection of other flip-flops and gates)?

A Little More Background — Things I Know and Have Tried Thus Far

So, for the record, I already know that a .MCS file is just a flavor of Intel HEX file, and I've already taken a look at these .MCS files in that light. In these files, there are only really "Data" records (there is one "Extended Segment Address" record, which is 0 0 so I'm ignoring it).

When I compare the first .MCS file from Hyde with the first portion of the .MCS file from Jekyll, it looks very similar. But not quite identical.

Is there any way for me to make more sense of the address + data items I get out of those .MCS files? And for me to separate the meaningful parts of the configuration bitstream (the part specifying actual logic configuration) from the parts that are just ancillary stuff (like specifying the configuration clock rate or similar)?

For those of you that have actually read this far… thank you!

Best Answer

I would start by taking a look at the configuration documentation for those parts to get an idea about how the multiple bitstreams need to be stored in the flash to load all three FPGAs. It would also be a good idea to search for the bitstream header of the other two bitstreams in the combined file. That may actually be sufficient without requiring extra documentation. It might be easier to do this by converting the mcs files to bin files and then using a hex editor (unless you can find a hex editor that can edit the content of a hex file instead of the file itself). Once you know the offsets, then you can separate the bitstreams and then it's just a matter of doing a binary diff to see if they match.

As far as comparing functionality, there is really no way to do that unless you can convert the bitstream back into a netlist. I don't think the Xilinx tools support this, so unless the bitstream format has been reverse-engineered, you're probably out of luck.