In my opinion you can take several approaches:
If both devices (MCU and FPGA) store their code/configuration in the same flash, you can simply download the contents via a dedicated reader (You can buy one, serial or parallel) and write the contents to the new chip on the new board.
You can just unsolder the flash and resolder it to the new board.
You can unsolder and resolder the FPGA and MCU (If they store their config internally and readout is locked)
You can connect to the MCU/FPGA via e.g. a JTAG-Probe and download the internal code/config if readout is not locked.
You can scan the internet/ask the manufacturer for the .bin files. With some luck they will provide them as they no longer manufactur the device in question.
As, in my opinion, the flash only holds the config for the FPGA you can download/reuse the contents from these chips. The MCU will, most likely, store its code internally. Therefore you will have to download (JTAG, if not locked) the code and flah it to a new device - or simply reuse the current device.
My advice:
Simply reuse the components in question (MCU, FPGA, Flash, EEPROM) by unsoldering and resoldering them.
This depends on the "solderability" of these devices and your skillset/tools available - but in my opinion this is the easiest route.
Also, if you lack the tools/skills/time, you can involve an "repair-shop" for these kind of tasks. They will charge a few hundred bucks, but this can be worth it (Mandatory machine controllers, defence equipment, what not).
A few problems:
The components (FPGA/MCU) may have code in them to check for device IDs on boot. This is a common feature to make "ripping it off" harder. If so, you will have to reuse the current devices. If not, you will have to dig through the code and find the "comparison" routine.
If the FPGA/MCU/Flash are in some "high density .35mm pitch 1000Pins package" you can run into trouble unsoldering/resoldering them quickly.
Why use a FPGA/MCU tandem:
There are many, many, and even more reasons to do that.
MCUs in general are targeted for special jobs - as FPGAs are.
BUT: a FPGA can be a simple MCU/dedicated FPGA. It can be what you want it to be.
So judging from the information available to me: I would say, that the FPGA does implement some custom Card<->Card interface reused by the design team. They opted with a FPGA as they maybe wanted special features or internal frame buffering or what not.
The MCU treats the FPGA as some sort of "external communication device" - quite like a UART/USB converter you can buy - and does the "heavy application lifting".
But maybe the FPGA does also implement the actual motor-drive logic and the MCU works as sort of "Sensor-Hub" reading currents and voltages or switches and whatnot.
We would need to trace out the PCB to form a clearer picture of the "assumed" block diagramm of the pcb - but you will never know for sure "what does what" as long as you dont dig thorugh the code/configuration, spend countless hours reading and thinking, measuring and testing.
EDIT 1:
To get more detailed (based on the comments) i append this edit.
- As it seems, the used FPGA does not have any internal configuration. So all configuration will be stored on an external Device. Either, on boot, the fpga is configured directly from a Flash/EEPROM Memory (easy case) or via the MCU loading the firwame (maybe encrypted, but unlikely) from the flash and sending it to the FPGA (Not so easy case).
To get the contents of the FLASH/EEProm you will have to read it. You should obtain a datasheet for the specific memory used. Based on the exact information you can order/build a probe to read the memory contents. You will have to unsolder the IC to read from it.
When assembling your new PCB, you simply use the same probe to write the exact contents to the new FLASH IC !before! soldering.
- To connect to the MCU you will have to get information on what interface is used. To do this, you have to find a datasheet. This will have information on what debug/programming interface is used. If i had to guess, i would go with JTAG.
You then have to order/build a probe for this pecific interface to connect to the controller - it is !very! unlikely that this can be bypased and instead be done via the UART port.
The downloading is usually as follows: You obtain the memory addreses from the datasheet (Flash x->y, eeprom a->b - the addresses) and use you probe via command line/GUI. You then tell it to download the content from addres (x or a) with a size of (y-x, b-a) and save it to your local machine.
On your new PCB you connect to the MCU via the probe again and tell it to upload the contents to the same addresses as they were downloaded from.
In anycase:
If you want to build your own PCB (why not reuse the old one and repair it?) you will have to download the FPGA configuration and the MCU software -both are important.
EDIT 2:
As you downloaded the FPGA configuration succesfully, you now have to continue with MCU firmware.
You can connect to the AVR MCU via the ISP header present on the board. Make sure to get the pinout correct: ISP Datasheet.
To verify, that the ISP is enabled/functional you can try the following:
Download the EEPROM content and check for a 0xFF byte. Then try to write that 0xFF byte to a known value ( e.g 0x12). Download the EEPROM content again. If the byte was changed, you can trust both FLASH and EEPROM downloads.
Make sure to also download the fuses - these are important too.
You can store these three files on your local machine to later on programm them onto your new device.
EDIT 3:
As you now have all four files required (FPGA config, MCU flash, MCU EEprom, MCU Fuses) you can rebuild your board.
But be aware: The MCU code may hide some ID-Checks, internal PCB speciic calibration, what not - so dont be happy to early!
