jhenderson
Site Admin
Joined: 07 Mar 2006
Posts: 2267
Location: So. Cal. USA
|
 Posted: Tue Feb 02, 2010 8:20 am Post subject: X5 flash programming interface |
 |
|
| Quote: | Our application is running great and is about to go through lab validation before we field it for some experiments in the Fall. We have been using JTAG to load the FPGA during the development process, and will be ready to update the FLASH soon. One requirement we have is to be able to update the FLASH image while in the field.
Normally we would use your VsProm utility to do this, but we ended up replacing the PCIe core you supply with our own. Upon looking for your FLASH interface code, it looks like it is in the PCIe core module, which we don’t have the source for. Can you provide us with the VHDL for the FPA interface on the x5-400M board?
|
The FPA interface in the FPGA is a simple register interface, that the software bit-bangs to talk to the CPLD serially.
Software writes to the FPA registers, which are directly connected to the CPLD. The mode bits are set by the software to indicate which mode
the CPLD should interpret the serial data. Please refer to the software libraries documentation for details.
The fpa_wr is a write strobe to the appropriate address; data_in is the data bus carrying the data.
The code snippet follows:
| Code: | -- register for controlling the fpa interface
-- (Flash Programming and Authentication)
process (pcie_clk)
begin
if (rising_edge(pcie_clk)) then
if (fpa_wr = '1') then
fpa_reg <= data_in(6 downto 0);
end if;
end if;
end process;
loader_mode(0) <= fpa_reg(0);
loader_mode(1) <= fpa_reg(1);
loader_mode(2) <= fpa_reg(2);
loader_clk <= fpa_reg(3);
loader_do <= fpa_reg(4);
loader_spare0 <= fpa_reg(5); -- not used
loader_spare1 <= fpa_reg(6); -- not used
Pin locations:
NET "loader_*" IOSTANDARD = LVCMOS18;
NET "loader_mode<0>" LOC = "AE18" ; #Bank 4
NET "loader_mode<1>" LOC = "AF18" ; #Bank 4
NET "loader_mode<2>" LOC = "AG18" ; #Bank 4
NET "loader_clk" LOC = "AF19" ; #Bank 4
NET "loader_di" LOC = "AG20" ; #Bank 4
NET "loader_do" LOC = "AG21" ; #Bank 4
|
I would also like to see the C source code that interacts with this module. I have the VsProm source, but the actual interface code seems to be in library functions that get called. We aren’t using the Malibu framework for our software. We have a simple register interface, and didn’t require anything fancy, so we wrote our own WinDriver interface. My goal is to be able to add FLASH programming to our existing software framework. Can you provide the necessary source code?
Source code for the VsProm application is attached. As you indicated, the VsProm utility is a front-end on the Malibu library functions contained in FpaLoadThread_Mb.cpp. These functions are exposed through the VsProm() method of the 400M board object within Malibu. The FPA interface within the standard logic provides bit-banged access to registers within the CPLD which is actually connected to the flash ROM. You will need to implement identical behavior in your firmware to gain access to the CPLD, and then you can leverage the code in the FpaLoadThread file. Unfortunately, we do not have a C-source equivalent to this C++ code.
| Quote: | I think I'll be able to write a flash programmer using this information. I've been reviewing the C++ code that does the work, and I have a question. In the FpaLoadThread code you have defined several events and event handlers to handle various tasks like parsing and loading. Is there a special reason why events were used? Is there any reason why I can't write this without using events? I'll be using C instead of C++, so I'll be using your code as a guide, but the less complexity there is, the better.
|
Malibu uses events in order to simplify access to the real-time actions of the Malibu libraries within application code. But, it is certainly possible to create a custom Flash programming facility without using events.
| Quote: | | I have another flash question. I have been trying to put our bitstream into the Flash on the x5-400M board without success. Is there any monitoring of the bit image “integrity” by the on-board configuration manager (Virtex-4??) that would cause it to load the golden image in lieu of our image at power-up? Our design consists of a PCIe core that we built ourselves, so your register set is not present. I made sure to load your reference bitstream before attempting to flash. What’s strange is the fact that the VsProm application seems to be happy when it programs my bitstream. When I start the board up, it doesn’t seem to be there, though. |
The bitstream data within the .bit image generated by ISE contains embedded checksum information. If the FPGA configures properly from Flash, then an LED on the board will illuminate. If the PCI Express links establish properly, the second LED will illuminate.
So, if neither LED illuminates, the image is invalid. However, if one LED illuminates, it implies that the configuration was successful but the PCI Express interface is not viable in your implementation (many possible causes).
| Quote: | | I managed to write a standalone command line based Flash programmer for the X5-400M board. Thanks for your help. I inserted my own IP into the FPGA and dropped the VHDL code snippet you provided for the FPA interface. My plan now is to increase the speed of the Flashing operation by transferring a word at a time over the PCIe bus instead of a bit at a time (with its accompanying clock toggling). I was wondering if you had a simulation model available for the FPA interface? It would make my job easier, and give me more confidence it its correctness, if I can simulate the CPLD interface. |
Unfortunately, we don't have a simulation model for the FPA-CPLD interface. |
|
