Products > PC720

PC720: FPGA Configuration Questions; board diagnostic information

(1/2) > >>

ldaddario:
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:

--- Quote from: ldaddario on October 01, 2013, 12:57 PM ---...   The '_4FM_UploadFirmware()' API library function takes two arguments...

--- End quote ---

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:
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:

--- Quote from: ebarhorst on October 02, 2013, 06:10 AM ---the PC720 has only 1 FPGA to configure the flash of this FPGA  you need to target FPGA A by selecting "-a".

--- End quote ---

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.

--- End quote ---

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?


--- Quote from: ldaddario on October 01, 2013, 12:57 PM ---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?

--- End quote ---


--- Quote from: ldaddario on October 01, 2013, 06:22 PM ---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?

--- End quote ---

Thanks,
Larry

arnaudNL:
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

Navigation

[0] Message Index

[#] Next page