Topic: PC720: FPGA Configuration Questions; board diagnostic information  (Read 16915 times)

ldaddario October 01, 2013, 12:57 PM

  • Member
  • *
  • Posts: 30
I have two questions regarding FPGA configuration on the PC720 under Linux.

1.  Using the supplied utility program '4fm_upload_firmware', I get:
       # 4fm_upload_firmware PC720 0 -b,direct mycode.hex
       FPGA B direct firmware upload not existing for device 'PC720'
and
       # 4fm_upload_firmware PC720 0 -b mycode.hex
       WARNING:
            This operation will write to FLASH.
       Continue?  (yes/no):

This behavior is not documented in the 4FM Programmers Guide.  Is it not possible to configure the FPGA without writing to flash?  If we proceed with writing to flash, is the FPGA also programmed or does that require a power cycle?

2.   The '_4FM_UploadFirmware()' API library function takes two arguments:  a pointer to the image filename and something called 'target' of type 'enum ufTarget', where 'target' specifies "the target on the board that will receive the image."  But the allowed values of 'target' and their meanings are not given in the 4FM Programmers Guide.  What exactly are they?  Does this allow configuring the FPGA directly without writing to flash?  Does it allow writing to flash without configuring the FPGA?  Does it allow doing both simultaneously? 

I also find that the '4fm_get_diagnostics' utility returns nothing interesting:
Using username "ldaddari".
# 4fm_get_diagnostics PC720 0
Successfully read diagnostic information from device 0
Diagnostics (FM480, FM482, FM577):
        3V3     : 0.00V
        1V8     : 0.00V
        1V2     : 0.00V
        Vref    : 0.00V
        FP      : 0.00V
        FPGA_A  : 0.0 C
        FPGA_B  : 0.0 C
Extended Diagnostics (FM485, FM486, FM489):
        1V0     : 0.00V
        1V0 MGT : 0.00V
        1V2 MGT : 0.00V
Extended Diagnostics (FM485, FM486, FM489 and FM577):
        2V5    : 0.00V
        5V     : 0.00V
        12V    : 0.00V
        -12V   : 0.00V
        IOPN4  : 0.00V
        REF_A  : 0.0 C
        REF_B  : 0.0 C

All of the results are labeled as applying to devices other than the PC720, and all values are zero.  Does the PC720 support reading its voltages and temperatures?  If so, perhaps the problem is that the utility does not support the PC720.  Is a newer version available?

I am using 4fm_tools version 1.7.0 and lib4fm version 1.42.1, both of which are part of the Linux release of 23 August 2013 (4fm.bsp.23.08.2013).  However, I notice that the release also includes 4fm_tools version 1.6.9.

Thanks,
Larry

ldaddario October 01, 2013, 06:22 PM (#1)

  • Member
  • *
  • Posts: 30
...   The '_4FM_UploadFirmware()' API library function takes two arguments...

Correction:  Actually, the Programmers Guide specifies three arguments for this function:  a pointer to the device context structure, followed by the file name and 'target'.  But the function prototype in '4FM.h' has an additional argument (the 2nd one) called 'mode' of type 'enum frmupMode', not documented in the Programmers Guide.  What are the allowed values of 'mode' and 'target' and what effect do they have?

--Larry

ebarhorst October 02, 2013, 06:10 AM (#2)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi Larry,


the PC720 does not provide any status information about temperature and voltages. Therfore the returned data is all 0. I agree it is a bit confusing,


the PC720 has only 1 FPGA to configure the flash of this FPGA  you need to target FPGA A by selecting "-a".


Yes you can only update the FPGA configuration by updating the flash. The FPGA connects to the PCIexpress bus and if you would start updating the FPGA you would lose the PCIe link. The direct upload is only aplicable to boards that have two FPGAs.


best regards,
Erik

ldaddario October 02, 2013, 10:30 AM (#3)

  • Member
  • *
  • Posts: 30
the PC720 has only 1 FPGA to configure the flash of this FPGA  you need to target FPGA A by selecting "-a".

Erik,

OK, but I'm pretty sure that the one FPGA is called '-b'.

Quote
Yes you can only update the FPGA configuration by updating the flash. The FPGA connects to the PCIexpress bus and if you would start updating the FPGA you would lose the PCIe link. The direct upload is only aplicable to boards that have two FPGAs.

Yes, that makes sense. 

After loading the new configuration to flash, how does it get into the FPGA?  The Getting Started manual suggests cycling the power.  If that's the only way to configure the FPGA then it's a serious problem for us (and, I'd guess, for most users).  Our embedded system will be 5000 km away from my lab, in a location rarely attended by humans, so we need to be able to update the FPGA by logging in remotely.  How can we do that?

Also, what about my software question?

2.   The '_4FM_UploadFirmware()' API library function takes two arguments:  a pointer to the image filename and something called 'target' of type 'enum ufTarget', where 'target' specifies "the target on the board that will receive the image."  But the allowed values of 'target' and their meanings are not given in the 4FM Programmers Guide.  What exactly are they?

Correction:  Actually, the Programmers Guide specifies three arguments for this function:  a pointer to the device context structure, followed by the file name and 'target'.  But the function prototype in '4FM.h' has an additional argument (the 2nd one) called 'mode' of type 'enum frmupMode', not documented in the Programmers Guide.  What are the allowed values of 'mode' and 'target' and what effect do they have?

Thanks,
Larry

arnaudNL October 02, 2013, 02:32 PM (#4)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Hello Larry,


That's correct, "-a" is the actual PC720 FPGA. This is because our devices with two FPGAs (FM680, FM780) have the PCIe/Flash interface on FPGA A, FPGA B being the processing FPGA.


As far as the flash upload is concerned, the CPLD on PC720 does program FPGA from flash during a cold boot. The main limitation is the operating system/bios. There is no way you can reprogram FPGA without at least a reboot where the BIOS re-enumerate the PCI tree.


There are many options still, typically a command could be added in the CPLD to kick reloading FPGA, or maybe reload FPGA each time a system reset is asserted and then the system could be restarted instead a power cycle.


This is an integration issue and solutions can be discussed with one of our sales engineer. The same behavior is true for most of the card with only one FPGA providing PCI engine.


About the software question, You do have the source code of the firmware upload which actually works fine. But to answer your question directly:


For the upload mode, you can use either CREG_BASED or BURST_BASED, this parameters is only useful on FM577 and discarded for other hardware.


For the destination:


- FPGA_B do a direct FPGA B upload (not available on PC720).
- FLASH_A do a flash programming of the USER configuration.
- FLASH_B do a flash programming of the USER configuration for FPGA B (not available on PC720).
- SAFE_A do a flash programming of the SAFETY configuration (the configuration kicking in in case USER section is invalid. Not available on PC720 as the flash device can be directly programmed using impact).


We will modify the documentation and the flash upload software to be more intuitive, or at least to provide guidance about what can be used on PC720.


Best Regards,
Arnaud



ldaddario October 02, 2013, 03:16 PM (#5)

  • Member
  • *
  • Posts: 30
As far as the flash upload is concerned, the CPLD on PC720 does program FPGA from flash during a cold boot. The main limitation is the operating system/bios. There is no way you can reprogram FPGA without at least a reboot where the BIOS re-enumerate the PCI tree.

Hello Arnaud,

Can you give a precise explanation of what the present CPLD code does?

- Does the CPLD drive the FPGA's PROGRAM_B pin?

- Under exactly what circumstances does re-configuration occur?  What does the OS need to do to the SPIe bus to cause this?  (I doubt that a full re-boot is needed, but maybe a re-initialization of the SPIe.)  What signal(s) from the SPIe connector go to the CPLD? 

Quote
There are many options still, typically a command could be added in the CPLD to kick reloading FPGA, or maybe reload FPGA each time a system reset is asserted and then the system could be restarted instead a power cycle.

I think that would be good. 

Exactly what happens when the '4fm_reset' utility is executed or the '_4FM_ResetDevice()' function is called?  Is this dependent on having appropriate firmware running in the FPGA or is it handled entirely by the CPLD?  I guess it does not include re-configuring the FPGA from flash, but adding that functionality might be considered.

Would it be possible for us to get either or both of the following?
- Complete schematic of PC720 board;
- CPLD source code.

Thanks,
Larry

arnaudNL October 08, 2013, 11:19 AM (#6)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Larry,


The PCIe enumeration is done by BIOS and not by Windows/Linux. Reloading FPGA from flash during runtime will cause BIOS to loose the way to the peripheral and this is why a reboot is required.


On the PC720, the FPGA load itself from FLASH, I would assume a POR (Power on Reset) preventing the FPGA to load before power rail are stable.


I hope that helps,
Arnaud

ldaddario October 08, 2013, 12:03 PM (#7)

  • Member
  • *
  • Posts: 30
The PCIe enumeration is done by BIOS and not by Windows/Linux. Reloading FPGA from flash during runtime will cause BIOS to loose the way to the peripheral and this is why a reboot is required.

Arnaud,

I understand that re-loading the FPGA during runtime will cause the OS to loose communication with the FPGA via the PCIe bus.  I believe that we could re-establish communication by forcing a re-enumeratoin of the bus.  If re-enumeration requires a complete re-boot, that would be acceptable because re-boot can be commanded remotely.

What is NOT ACCEPTABLE for our application is requiring a POWER CYCLE in order to  re-load the FPGA.  We must be able to force a re-load of the FPGA by remote control.

Quote
On the PC720, the FPGA load itself from FLASH, I would assume a POR (Power on Reset) preventing the FPGA to load before power rail are stable.

In our system now, I find experimentally that a re-boot (with power remaining on) does NOT cause the FPGA to be loaded from FLASH.  A commanded "shutdown" followed by a pressing the power button to restart also does NOT cause the FPGA to be reloaded; this is because standby power continues to be applied, even though the CPU is shut down.  Only complete removal of power from the chassis and then re-applying power causes the FPGA to be loaded.  After that, the OS still is not able to communicate with the FPGA until a second re-boot is done.  The latter is probably because the FPGA has not finished loading when the BIOS attempts to enumerate the PCIe bus.

We need to find a way to fix this in order for the PC720 to be usable in our application.  I believe that a satisfactory fix is possible, but it probably requires modification of the CPLD code.  We would appreciate any help you can provide with this.

I have asked several questions in this thread which have still not been answered:

- Can you give a precise explanation of what the present CPLD code does?
- Does the CPLD drive the FPGA's PROGRAM_B pin?
- Exactly what happens when the '4fm_reset' utility is executed or the '_4FM_ResetDevice()' function is called?  Is this dependent on having appropriate firmware running in the FPGA or is it handled entirely by the CPLD?
- Can we get a copy of the complete schematic of the PC720 board?
- Can we get a copy of the CPLD source code?

Regards,
Larry

arnaudNL October 09, 2013, 03:22 AM (#8)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Larry,

The CPLD code mostly maps the flash device on to the FPGA and other glue logic functions. The code source is not disclosed and the CPLD code itself not documented as this is a proprietary element in our hardware. Indeed PROGRAM_B pin is driven by the CPLD; As per Xilinx requirement this is the way to hold the FPGA not loading from flash up to the point the flash device is actually ready to process commands, the CPLD knows this time. That could be a way to force FPGA reload before to restart the system. I believe this should be discussed further with sales. Typically for understanding the feasibility (There might be a requirement of dropping SD card to have free pins for this handshaking), shchematic and the availability of the CPLD source code.

_4FM_Reset gets FPGA fabric to be reset, this is to be seen as an "Event" caught by the FPGA  firmware. Calling this function translate to write register 0 in the PCI BAR 0 mapped to the PC720.


Best Regards,
Arnaud
  • « Last Edit: October 09, 2013, 06:00 AM by arnaudNL »