UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer nknuth
Observer
14,942 Views
Registered: ‎01-19-2015

VC709 BPI unreadable after boot

Jump to solution

I am wondering if the community of VC709 users can help me out?  If you have VC709 evaluation board, does your BPI flash work after you have booted from flash?  

 

After booting from flash into a simple C program or into u-boot/Linux then I believe that you should be able to access the flash and read its contents.  (maybe I am asking too much?)  Unfortunately with the three VC709 boards that I have, the flash is completely locked up after I boot from it and there is nothing that I have figured out to get it back into read array mode.  

 

I have read a number of the technical briefs about the BPI and verified and re-verified that my board is in good working order and that all the pins/jumpers are configured appropriately.  Also, I have explored a number of drivers and tested their flash access routines and debugged how they execute the flash commands to restore the flash to read array mode, but nothing seems to clear the issue after I boot from the BPI flash.  It seems to be completely locked up. 

 

This issue is a show stopper for me, because I would like to store my bitstream combined with the first boot program in the flash, then boot up and have it load and jump to u-boot.  This is all well-documented in the Xilinx reference designs, but it doesn't work on any of my three VC709 boads.  

 

Strangely enough, if I place the u-boot into flash and then load the bitstream program over JTAG (instead of storing it in flash), then everything works fine.  This is not a production solution, but it does confirm that all the software is intact and capable of booting the system.  It is just that when you store the bitstream to flash, then power-on and boot from the BPI flash that it becomes locked up.  

 

You can demonstrate the same problem with the VC709 BIST code provided by Xilinx.  Here are the steps to re-create:

 

  1. Use the procedure outlined in "xtp238-vc709-restoring-flash-c-2014-4.pdf" to restore the flash contents on any VC709 board.  
  2. Run the BIST test:
    ********************************************************
    ********************************************************
    ** Xilinx Virtex-7 FPGA VC709 Evaluation Kit **
    ********************************************************
    ********************************************************
    Choose Feature to Test:
    1: UART Test
    2: LED Test
    3: IIC Test
    4: FLASH Test
    5: TIMER Test
    6: SWITCH Test
    7: DDR3 C0 External Memory Test
    8: DDR3 C1 External Memory Test
    9: BRAM Internal Memory Test
    A: BUTTON Test
    0: Exit
  3. Select "4", the BPI flash test
    ********************************************************
    ********************************************************
    ** VC709 - FLASH Test **
    ********************************************************
    ********************************************************
    -- Fail at Initialize --
    Flash test failed (1)
  4. The flash can be programmed with the BIST test, but when running the BIST test via power-on reset, the flash cannot be accessed.  We have confirmed the same failure with a simple C program attempting to read the flash as well.  

 My management is ready to send all three VC709 evaluation boards back.  I am trying to figure out how to work-around this issue or trying to learn something that maybe I have done wrong.  If there is somebody from Xilinx on this thread, can you confirm if I am doing something wrong?  Do you see this issue with BIST and a VC709 board that you have in your lab? Any help is appreciated...

 

Thanks,

Nathan

 

0 Kudos
1 Solution

Accepted Solutions
Observer nknuth
Observer
22,402 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

I recently sat down with another engineer in my office and figured this one out.  

 

This issue is caused by the FLASH being used in synchronous mode versus asynchronous mode.  If you change the following settings in your bitstream generation, then you will be able to access the flash after loading the bitstream from it. 

 

set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [get_designs impl_1]

set_property BITSTREAM.CONFIG.BPI_SYNC_MODE DISABLE [get_designs impl_1]

 

The reason that the BIST test for FLASH fails is because it is trying to acces the flash without a clock and yet the flash is in synchronous mode and requires a clock.  There doesn't appear to be a way to switch these eval boards back to asynchronous mode after booting in synchronous mode.  Thus, the two settings above setup the bitstream to be booted in asynchronous mode -- effectively punting on synchronous mode.

 

Once I did this, then I can access the flash after I have booted from it.  Now I can boot the bitstream, run fs-boot, load u-boot and run the linux kernel all from the same flash.  

 

Strange that when I originally presented this issue to Xilinx in a Webcase that they decided to RMA my board?

 

If you download and install the various releases of the Xilinx BIST code, you can see that they changed the BIST over from asynchronous mode access of the flash to synchronous mode.  Synchronous mode has the promise to be faster, but after booting from flash with these eval boards you are stuck. 

 

2014-1 bist app from Xilinx - Boots in asynchronous mode, BIST flash test passes

2014-2 bist app from Xilinx - Boots in asynchronous mode, BIST flash test passes

2014-3 bist app from Xilinx - Boots in synchronous mode, BIST flash test fails

2014-4 bist app from Xilinx - Boots in synchronous mode, BIST flash test fails

 

Thanks,

Nathan

 

 

0 Kudos
26 Replies
Moderator
Moderator
14,925 Views
Registered: ‎01-15-2008

Re: VC709 BPI unreadable after boot

Jump to solution

what is the mode pins set in SW11 when you do the power cycle to run the BIST from bpi flash.

it must "010"

check the user guide table A-2

http://www.xilinx.com/support/documentation/boards_and_kits/vc709/ug887-vc709-eval-board-v7-fpga.pdf

 

--Krishna

Xilinx Employee
Xilinx Employee
14,921 Views
Registered: ‎07-31-2012

Re: VC709 BPI unreadable after boot

Jump to solution

Hi,

 

Please check the AR - http://www.xilinx.com/support/answers/54355.html and try to make sure all the board led and jumper settings are as per this and then run the BIST. Also check the section 6 for BPI device debugging.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
Xilinx Employee
Xilinx Employee
14,911 Views
Registered: ‎01-03-2008

Re: VC709 BPI unreadable after boot

Jump to solution

> My management is ready to send all three VC709 evaluation boards back. 

 

This isn't a problem with the VCU709 board, it is a problem with your design.  The likely problem is that the configuration from the BPI flash has left in a mode that was not expected by the processor code and the flash device needs to be reset.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
Observer nknuth
Observer
14,905 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Yes, the mode pins are set to 010.  I have gone through all the docs trying to figure out if I have the wrong settings.  It is pretty straight forward, just doesn't work. 

 

Thanks,

Nathan

 

0 Kudos
Observer nknuth
Observer
14,901 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

I agree that the flash device just needs to be reset and put into readarray mode, but when would boot up any bitstream from the flash, the flash is not resettable as far as I can tell.  (It is locked up) I have downloaded and installed the specific driver for this flash from Micron.  Wrapping that driver with a simple C program yields the same results:  If you program the bitstream (MSC) file to the flash and then reset the board micron driver is useless in resetting the flash, reading the device ID, or placing the device in read array mode.  

 

I would like to figure a way around this.  It is a pain to not be able to read the flash after booting from it. 

 

Thanks,

Nathan

 

0 Kudos
Observer nknuth
Observer
14,898 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

I thought at first that it was my design that was the problem, but then the Xilinx provided BIST design shows the same issue.  This leads me to believe that it is more of a board problem then a code or design problem.  When I load the Xilinx provided BIST code, I don't compile it even but rather just use the MCS file provided in the zip file. 

 

Do you see this on your VC709 boards?

 

Thanks,

Nathan

 

0 Kudos
Observer nknuth
Observer
14,879 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Can you point me towards a Xilinx reference design that demonstrates that the flash is readable after you boot from it?  I am happy to concede that my design must be wrong somehow, but it is difficult to believe that my design is wrong when I am just using a Xilinx reference design to demonstrate the problem? 

 

Thanks,

Nathan

 

0 Kudos
Xilinx Employee
Xilinx Employee
14,777 Views
Registered: ‎07-31-2012

Re: VC709 BPI unreadable after boot

Jump to solution

Hi,

 

You can check and try using the mcs file from the multiboot design from this link - link. Check for XTP236.

 

Check if the mcs in this should help program the FPGA from the BPI after programming.

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
Participant pillinj1
Participant
14,066 Views
Registered: ‎02-11-2014

Re: VC709 BPI unreadable after boot

Jump to solution

I too am experiencing this exact issue on the VC707. If I program the FPGA via JTAG, I can read from the Flash fine. If the FPGA is programmed from the Flash, Xflash_Initialize() fails and I can't interact with the flash.

 

This person also seems to be having the same problem: http://forums.xilinx.com/t5/7-Series-FPGAs/FSBL-can-t-read-from-BPI-x16-flash-for-vc709/td-p/559297

 

Can a Xilinx engineer please look at this and at least get the BIST demonstration working?

 

If I get a chance, I'm going to Chipscope (or whatever it's not called in Vivado) the flash lines and see if there's any difference in JTAG vs Flash programming.

0 Kudos
Observer nknuth
Observer
12,325 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Glad to hear that somebody else is seeing this problem.  I see the same problem on all the VC709 boards that I have in house.  And, as mentioned it is easily recreatable with the Xilinx provided BIST code.  Not sure why the Xilinx posts on this thread have said that it is a problem with the design?  

 

The reference by Xilinx support to the multiboot XTP236 example is not a good test because the example code does not make use of Xflash_Initialize().   The bottomline quesion, after booting an MCS file from flash, how can you get the flash back into read-array mode to read from it?   

 

Thanks,

Nathan

 

0 Kudos
Observer nknuth
Observer
12,277 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Any word from Xilinx on this?  I brought this issue up with a webcase and it was Xilinx decided to RMA my VC709 board?  I see this on all of the VC709 boards that I own.  Should I RMA all them?

 

Nathan

 

0 Kudos
Observer densipe
Observer
12,089 Views
Registered: ‎01-27-2010

Re: VC709 BPI unreadable after boot

Jump to solution

I have the same issue on a newly designed board that implemented the same bpi connections as the VC707 reference design.  After configuration and grounding INIT_B - FLASH RST- with a test lead, i can successfully read from the device. It might be more of a Micron problem instead of Xilinx??

 

Please keep this thread up to date is a solution arrives.

 

right now i am instrumenting my board to see the signals at the flash instead of using fpga debug.

i really want to know what WAIT is doing.

0 Kudos
Observer nknuth
Observer
22,403 Views
Registered: ‎01-19-2015

Re: VC709 BPI unreadable after boot

Jump to solution

I recently sat down with another engineer in my office and figured this one out.  

 

This issue is caused by the FLASH being used in synchronous mode versus asynchronous mode.  If you change the following settings in your bitstream generation, then you will be able to access the flash after loading the bitstream from it. 

 

set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [get_designs impl_1]

set_property BITSTREAM.CONFIG.BPI_SYNC_MODE DISABLE [get_designs impl_1]

 

The reason that the BIST test for FLASH fails is because it is trying to acces the flash without a clock and yet the flash is in synchronous mode and requires a clock.  There doesn't appear to be a way to switch these eval boards back to asynchronous mode after booting in synchronous mode.  Thus, the two settings above setup the bitstream to be booted in asynchronous mode -- effectively punting on synchronous mode.

 

Once I did this, then I can access the flash after I have booted from it.  Now I can boot the bitstream, run fs-boot, load u-boot and run the linux kernel all from the same flash.  

 

Strange that when I originally presented this issue to Xilinx in a Webcase that they decided to RMA my board?

 

If you download and install the various releases of the Xilinx BIST code, you can see that they changed the BIST over from asynchronous mode access of the flash to synchronous mode.  Synchronous mode has the promise to be faster, but after booting from flash with these eval boards you are stuck. 

 

2014-1 bist app from Xilinx - Boots in asynchronous mode, BIST flash test passes

2014-2 bist app from Xilinx - Boots in asynchronous mode, BIST flash test passes

2014-3 bist app from Xilinx - Boots in synchronous mode, BIST flash test fails

2014-4 bist app from Xilinx - Boots in synchronous mode, BIST flash test fails

 

Thanks,

Nathan

 

 

0 Kudos
Observer densipe
Observer
12,068 Views
Registered: ‎01-27-2010

Re: VC709 BPI unreadable after boot

Jump to solution

I agree with Nathan.

 

The EVAL board BIST application uses Async Config and it works fine.

I have also been able to verify that using ASYNC configuration allows full access to the FLASH on my one-off design.

And no access after a Synchronous Configuration.

I think i have tracked it down to this statement in the Micron Spec.

 

--

Bus WRITE cycles are asynchronous only.

The following conditions apply when a bus WRITE cycle occurs immediately before, or immediately after, a bus READ cycle:

• When transitioning from a bus READ cycle to a bus WRITE cycle, CE# or ADV# must toggle after OE# goes HIGH.

• When in synchronous read mode (RCR15 = 0; burst clock running), bus WRITE cycle timings tVHWL (ADV# HIGH to WE# LOW), tCHWL (CLK HIGH to WE# LOW), and tWHCH (WE# HIGH to CLK HIGH) must be met.

• When transitioning from a bus WRITE cycle to a bus READ cycle, CE# or ADV# must toggle after WE# goes HIGH.

--

 

I havent found a way to make CE# transition after WE#.  They are always coincident.  the notes seem to indicate that Write Cycle Period controls CEN width and Write Enable min Pulse Width controls WEN width, but i can't find a setting that widens CEN without changing WEN also.

Dennis

0 Kudos
Observer densipe
Observer
12,060 Views
Registered: ‎01-27-2010

Re: VC709 BPI unreadable after boot

Jump to solution

of course, i have typos. confusing OE#, WE# and CE#

0 Kudos
Observer densipe
Observer
12,045 Views
Registered: ‎01-27-2010

Re: VC709 BPI unreadable after boot

Jump to solution

I opened a webcase SR#10310608.

After providing pointers to app notes that explain how to setup Sync Config, they finally summed up the problem.

 

Hi Dennis,

 

Also AXI_EMC IP until 2015.1 tool version does not work for Synchronous mode. Change request CR#808007 is in place to add Synchronous operation support for AXI EMC IP.

 

Regards,

Kiran

 

It just doesn't work.  No solution until they rewrite some vhdl.  Not sure if this means 2015.1 works.

We need another workaround.  We have to Sync Config to meet powerup timing and we need to be able to access the flash for In System Upgrades.

 

 

0 Kudos
Visitor wojo
Visitor
12,040 Views
Registered: ‎05-20-2015

Re: VC709 BPI unreadable after boot

Jump to solution

I worked on this issue with Nathan and agree with Dennis on his earlier conclusion about INIT_B signal being directly connected to the Flash reset input being a problem.

 

The essence of the problem is that the Flash must be reset after its clock source stops to put it back into asynchronous mode. Flash gets its clock from the FPGA CCLK configuration pin (not EMC module).

After BIST app 2014.2 (2014.3 and 2014.4) the bitstream is loaded from the Flash in synchronous mode and Flash is left in that mode, although its clock source (CCLK) to the Flash stops. It surely speeds up the bitstream loading process, but Flash is left in unusable state. As Dennis noticed by toggling the Flash reset signal (FPGA_INIT_B) the Flash becomes usable again. By doing so Dennis reset the Flash and put it back in asynchrnous mode that the MicroBlaze/EMC logic expects. I do not believe that there is a mechanism in the FPGA that would allow INIT_B signal to be toggled after bitstream upload.

 

What we did with Nathan is we reverted the bistream upload mode back to asynchronous mode. He lists couple commmands that do that. Now the bitsream loads slower, about 2 seconds, but the Flash is also left in usable for the MicroBlaze/EMC mode.

 

Fix that would allow synchronous bistream uplaod and be compatible with present MicroBlaze/EMC logic unfortunately would require board spin. There would have to be means added to the board to reset the Flash after bitstream is loaded. Perhaps FPGA I/O pin could drive that signal (INIT_B signal is open drain so it can be driven low by multiple sources).

Better solution would be to have EMC module use the Flash in synchronous mode (both bitstream upload and MCU boot times would improve) but this would require a continous clock source; probably external. Again, this would require board redesign.

 

BTW, to speed up the Flash access slightly we also bumped the speed from 3MHz to 6MHz. Here are the constraints that we added to our .xdc file:

 

set_property BITSTREAM.STARTUP.STARTUPCLK CCLK [current_design]
set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [current_design]
set_property BITSTREAM.CONFIG.UNUSEDPIN Pulldown [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 6 [current_design]
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.BPI_SYNC_MODE DISABLE [current_design]
set_property CONFIG_MODE BPI16 [current_design]
set_property CONFIG_VOLTAGE 1.8 [current_design]
set_property CFGBVS GND [current_design]

 

Not as fast as in synchronous mode (less than 1 second), but still some improvement plus MCU can use the Flash now...

 

NOTE: unleass EMC module can drive the Flash clock input (which is connected on the VC709 board to the configuration clock pin CCLK) there will be no way for MCU to interface with the Flash in synchronous mode. Something to consider with new designs...

 

Jerry

 

0 Kudos
Observer densipe
Observer
12,024 Views
Registered: ‎01-27-2010

Re: VC709 BPI unreadable after boot

Jump to solution

 

Jerry,

using Async config is a show stopper for us.  we have a very tight powerup timeline and only Sync config will work.  100mhz EMMCLK, compressed and encrypted bit stream. 

 

The comment from Xilinx -- "Change request CR#808007 is in place to add Synchronous operation support for AXI EMC IP" -- would indicate that it is possible to do this with the current V7 devices.  This implies that it is just a change to the bitstream.  Either to reprogram the RCR in the flash post config or maybe an secret undocumented feature. 

 

The micron spec gives ambiguous details for this particular situation. At one place, it implies that a clock is necessary for a write during Sync mode; but there is a statement that all writes are Async. In another case - as i quoted - it may be possible to do a write without a clock, if WE# and CE# can be timed appropriately. That would be a change to the vhdl for the AXI-EMC IP. 

 

My current experiments will be to hand edit the bitstream to add another reprogram RCR command near the end - somewhere around the CRC and DESYNC commands.  Hopefully, the write to the flash will happen before the CCLK goes away - V7 generates about 24 clocks after DONE - if i read that right. 

 

maybe for future designs, adding a gate to AND in a user pin with the INIT_B will be a possible solution. 

 

There may be the option to keep CCLK active.  I haven't figured out if CCLK wil still be sourced by EMCCLK or if it transitions to the fabric clock.  and if user access to the flash is possible in that mode.   oooof.

 

Dennis

0 Kudos
Visitor wojo
Visitor
12,016 Views
Registered: ‎05-20-2015

Re: VC709 BPI unreadable after boot

Jump to solution
Dennis,
I would not read the "Change request CR#808007 is in place to add Synchronous operation support for AXI EMC IP" as this is going to fix the eval boards/designs based on them. It probably means that the IP core will be fixed/improved.
One of the Micron specs I read states definitely that if the clock stops the memory state machine will not move; reset is needed to bring back to starting step.
CCLK if generated by the FPGA has large tolerance and I do not see how this can be synchronized with EMC module. EMC module must run at the frequency of the clock connected to the Flash. Please see User Guide for EMC; there are 2 scenarios shown for synchronous operation; unfortunately both not possible on my VC709 boards or designs based on it.

Can you add a wire to connect any I.8V FPGA IO to the INIT_B signal? You could add little logic to pulse it low after configuration completes.
And of course Xilinx support could chime in and let us know if there are any undocumented features and stop us from reverse engineering their design.
0 Kudos
Visitor andrei_hres
Visitor
8,637 Views
Registered: ‎06-18-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Hi.

I have same problem on a board from HiTech Global HTG-V7-G3-PCIE (at boot time flash works in SYNC mode). I have tried to use xilflash lib and Micron driver. I stopped on using Micron driver. My solution of the problem is updating Micron driver with a function FlashSetAsync().

ReturnType FlashSetAsync()
{
	ReturnType  rRetVal = Flash_Success;
	uCPUBusType ReadConfigReg;

	/* #define SWD_INITIALIZED (ublNumBlocks != 0) */
	if(!ublNumBlocks) ublNumBlocks = 1;

	rRetVal = FlashReadBurstConfigRegister(&ReadConfigReg);
	if(rRetVal == Flash_Success)
	{
		if((ReadConfigReg & FLASH_CR_ASYNCHRONOUS) != FLASH_CR_ASYNCHRONOUS)
		{
			ReadConfigReg |= FLASH_CR_ASYNCHRONOUS;
			rRetVal = FlashSetBurstConfigRegister(ReadConfigReg);
		}
	}

	return Flash_Success;
}



Host runs this function (returns flash back to ASYNC mode) before FlashInit() function. In this case everything works fine.

 

Best Regards,

Andrei.

0 Kudos
Visitor keeganrm
Visitor
5,739 Views
Registered: ‎01-17-2017

Re: VC709 BPI unreadable after boot

Jump to solution

@wojo + @nknuth

 

Hi Jerry and Nathan, 

 

Thanks for giving so much information on the EMC / BPI async configuration for the VC707. I have some more questions about the configuration, and as you all seemed to figure this out, I was hoping one of you could help.

 

I'm trying to configure my VC707's flash using the AXI EMC core, and I'm still a bit confused about the clock sourcing. 

 

I looked at the 2014.2 BIST, and it looks like the EMC modules' ports S_AXI_ACLK / RDCLK are hooked up to the MIG's port MIG_UI_ADDN_CLK_0, which looks to be set to 100 MHz. (Please correct me if I'm wrong here, as my confusion stems from this.)

 

My impression was that we would need to use a generated 3 - 6 MHz clock for the S_AXI_ACLK / RDCLK inputs to the EMC module, but this implementation means that the clock source for these ports can be much faster? And if it can be faster, how fast can we clock this interface? Have either of you found that it works faster than 100 MHz?

 

If the RDCLK doesn't need to run at the same speed as the async configuration (3-6 MHz), how does the EMC module use the RDCLK for it memory reads/writes? I don't see any configuration in the EMC IP Core generator to specify this speed, so how would it know the switching frequency of the input clock?

 

As a follow up question, with the constraints set to what Jerry had specified in one of his posts (copied below), is the EMC clock still able to be used in the post-configuration design?

 

set_property BITSTREAM.STARTUP.STARTUPCLK CCLK [current_design]
set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [current_design]
set_property BITSTREAM.CONFIG.UNUSEDPIN Pulldown [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 6 [current_design]
set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.BPI_SYNC_MODE DISABLE [current_design]
set_property CONFIG_MODE BPI16 [current_design]
set_property CONFIG_VOLTAGE 1.8 [current_design]
set_property CFGBVS GND [current_design]

 

I was wondering if I could use this 80 MHz EMCCLK for other purposes in my design (though I know that it isn't on a CCIO pin, so there might be some timing issues to take into account).

 

If the constraints above are set, would this still allow for the EMCCLK to be brought into the design with the following constraints?

create_clock -period 12.5 [get_ports fpga_emc_clk]
set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets fpga_emc_clk]

 

Thanks for your time,

 

Keegan

 

 

0 Kudos
Visitor wojo
Visitor
5,722 Views
Registered: ‎05-20-2015

Re: VC709 BPI unreadable after boot

Jump to solution

Let me comment on couple of your points (its been a while since we debugged this):

 

Q) My impression was that we would need to use a generated 3 - 6 MHz clock for the S_AXI_ACLK / RDCLK inputs to the EMC module, but this implementation means that the clock source for these ports can be much faster? And if it can be faster, how fast can we clock this interface? Have either of you found that it works faster than 100 MHz?

 

 

A) In Asynchronous mode 6 MHz was the fastest rate that we could run at (166ns clock period +/-30%; min 116ns). At this rate all the Flash timing requirements can be fulfilled (refer to Flash's timing specs; min Read is 96ns). At the next step (I believe was 9MHz) things do not work any longer (111ns +/-30%; 78ns min).

At 100MHz clock period is 10ns but many commands still need multiple clocks to access the Flash in Synchronous mode. Real benefit of Synchronous mode is that Read and Write cycles can be optimized in 10ns increments and most importantly synchronous burst Read feature can be taken advantage off (16bits word Read per 10ns clock after initial Read delay; 1600Mbps). This is what allows shorter boot time in synchronous mode rather than with flat 166ns +30% cycles (67Mbps min) in asynchronous mode.

 

Q) As a follow up question, with the constraints set to what Jerry had specified in one of his posts (copied below), is the EMC clock still able to be used in the post-configuration design?

 

A) If the FPGA boots from the Flash in Synchronous mode and Flash clock stops, there needs to be a reset mechanism for the Flash to exit this mode (VC709 boards do not have such mechanism). Our present workaround is to boot in Asynchronous mode and stay in that mode (no need to reset the Flash). Its much slower but at least it works (allows us to access the Flash after booting). Note that all this is based on finding that we made 2 years ago and things might have changed since. We did not investigate this issues further since then.

0 Kudos
Scholar pratham
Scholar
5,715 Views
Registered: ‎06-05-2013

Re: VC709 BPI unreadable after boot

Jump to solution

@wojo Yes, From 2016.1 we have added the feature so you can reset the flash through software no hard reset is needed to use the flash in sync mode.

 

@keeganrm Please check the XAPP1282, this is for Ultrascale but same can be applied to the 7 Series FPGA. Please always start a new thread to get the quicker response.

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
Visitor keeganrm
Visitor
5,694 Views
Registered: ‎01-17-2017

Re: VC709 BPI unreadable after boot

Jump to solution

@pratham Thanks for your quick response. Sorry to post multiple questions in the same thread. I'll start a new thread next time. For now, a couple of notes about your response:

 

The XAPP1282 details using the STARTUPE3 primitive in the design. For clarification, I'm targeting the VC707 (Virtex-7 XC7VX485T-2FFG1761C). I'm still learning about these FPGAs (so correct me if I'm wrong), but I believe that the XC7VX485T-2FFG1761C doesn't come with the  STARTUPE3 primitive. Instead we have to use the STARTUPE2 primitive. I don't want to assume anything, so is there still some way that XAPP1282 can be applied to my hardware?

 

@wojo Thanks for getting back to me. I appreciate you dusting off this old knowledge. I'm not sure if I communicated as well as I should have when I was asking my question, so please allow me to clarify.

 

I'm attempting to use the flash in asynchronous mode. Looking back at the previous posts in this thread, Nathan noted that the 2014.1 and 2014.2 BIST designs interface with the flash in asynchronous mode, and the BIST flash test passes. In these designs, even though the flash is configured for asynchronous operations, it looks like the EMC module ports, S_AXI_ACLK / RDCLK are wired to a 100 MHz clock source (from the MIG's additional clock outputs). 

 

My question is, if the flash is configured for asynchronous read/writes, how is it that the BIST design can use a 100 MHz clock for the EMC module's RDCLK? I know that this RDCLK is not connected to the CCLK (the flash config clock), but so if these clocks don't have to be the same frequency, at what frequencies can the S_AXI_ACLK / RDCLK inputs be driven and still have the EMC module communicate with the flash?

 

To further clarify, I really would just like to ask whether:

a) The EMC ports S_AXI_ACLK / RDCLK do, or do not, have to run at, or near, the same frequency as the ConfigRate (3 - 6 MHz) 

b) If they don't have to be the same, did someone in fact successfully drive the S_AXI_ACLK / RDCLK ports at 100 MHz (as 2014.2 BIST shows) while the EMC module was interfacing with the flash in asynchronous read mode? 

c) And as a bonus, is there any other frequencies that the S_AXI_ACLK / RDCLK ports have successfully been driven at while in async read mode?

 

 

Again, I really appreciate any time spent answering these questions. Thanks so much.

 

Keegan

 

 

 

0 Kudos
Scholar pratham
Scholar
5,666 Views
Registered: ‎06-05-2013

Re: VC709 BPI unreadable after boot

Jump to solution

@keeganrm Yes, You have to use the STARTUPE2 for 7 series.

-Pratham

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
2,968 Views
Registered: ‎11-28-2011

Re: VC709 BPI unreadable after boot

Jump to solution

I know the solution was posted a while ago on this. The post that was marked as being the solution recommended this:

set_property BITSTREAM.CONFIG.EXTMASTERCCLK_EN DISABLE [get_designs impl_1]

set_property BITSTREAM.CONFIG.BPI_SYNC_MODE DISABLE [get_designs impl_1]

 

Further posts mentioned modifying the swr driver, and also mentioned using the STARTUPE2 for 7-Series devices.

 

Therefore my question is, are all three (bitstream settings, swr mod, startupe2) required in order for swr running in the Zynq PS to be able to read/write to the flash post configuration?

Tags (3)
0 Kudos