6
\$\begingroup\$

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!

\$\endgroup\$
2
  • \$\begingroup\$ How big are the MCS files? Can you post a little of them -- "very similar but not identical" doesn't give much to work with. \$\endgroup\$
    – jonathanjo
    Sep 26, 2022 at 15:08
  • \$\begingroup\$ Any way to post a bit of the two files? Or to explain what kinds of differences you're finding? I often find that files have timestamps in them, and are otherwise identical, and often it's possible to see that in the hex. \$\endgroup\$
    – jonathanjo
    Oct 22, 2022 at 23:30

2 Answers 2

0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

The most straightforward way to tell if the designs are functionally identical is to get an old version of the Xilinx ISE tools, load the real part, and then read back the checksum/CRC. If the CRC is identical then you have a pretty good (99.9999999%) indication that the designs are identical.

It appears that the Xilinx ISE toolset dropped support for the XC3000 series parts in 2003, so you would need a really old version of ISE. You can download old versions of ISE (all the way back to 3.1) from the Xilinx ISE Archive page.

And then hopefully you can get your hands on an old Windows XP or Windows 98 machine, or a copy of VM Ware and old Windows image. Plus, you would need a really old programming cable.

The newer ISE tools didn't appear to have a way to verify the CRC without actually loading the part, but it's possible the old ones did (which might make things simpler since you wouldn't need to actually load anything).

The other route you could take is to try and understand the contents of the bitstream itself. As a start I would try looking at the datasheet for the XC3090 part itself. I suspect that's going to be quite involved.

If we can confirm that Jekyll and Hyde are in fact different, is there any reasonable way to see whether the differences are trivial

Probably not. In my experience, Xilinx gives out a lot of information on the general bitstream formats (so that people can do things like program their devices from CPU or microcontroller IO), but not as much information on the details as it pertains to a specific device.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.