cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Historian
Historian
9,145 Views
Registered: ‎02-25-2008

Virtex-4 INIT_B and Slave Serial configuration oddness

I have a system design in which a Virtex-4 LX is configured in slave serial mode from a microcontroller. The previous batch of systems built up a couple of years ago work flawlessly. A new run has a few boards which fell out due to some odd behavior.

 

At system boot time or as a result of a software command, the micro will configure the FPGA. The micro pulls down on PROGRAM_B, then clears DIN and CCLK, and finally pulls down on INIT_B. The INIT_B pin on the micro is configured as open-drain and a 4k75 pull-up resistor is installed on the line. After a setting up a few things, the micro releases first PROGRAM_B and then INIT_B.

 

But ... INIT_B doesn't go high when I release it. It goes high much later (order of several milliseconds). This is quite bizarre.

 

The data sheets give no mention of the timing of INIT_B with respect to PROGRAM_B, nor is there a minimum pulse width given for it. (The width of PROGRAM_B far exceeds the datasheet minimum of 300 ns.)

 

I suppose that a workaround would be for the micro to release INIT_B and then turn around and wait for it to actually go high before continuing the configuration. But it's odd that this same code which worked on a couple dozen boards now fails on a couple of the new builds.

 

I've verified that the power supplies are good, and this process happens well after the supplies are stable.

 

Any ideas about this behavior?

----------------------------Yes, I do this for a living.
0 Kudos
2 Replies
Highlighted
Moderator
Moderator
9,129 Views
Registered: ‎01-15-2008

Hi Bassman,

 

If you see the Virtex-4 configuraiton guide the Init_b signal will be low approx prog_b pulse width + Tpl(program latency).

Kindly check the figure 1-3 in the UG071

http://www.xilinx.com/support/documentation/user_guides/ug071.pdf

Tpl should be calculated based on the bitstream size of the device you have. 

In the datasheet the Tpl is available and it is 0.5 Us/frame.

http://www.xilinx.com/support/documentation/data_sheets/ds302.pdf

 

If you consider XC4VLX200 as an example, the Tpl should be around (37,500*0.5 ) 18.75ms 

Hope this info helps.

How much time is the init_b is low after the prog_b is high in your case?

 

--Krishna

 

0 Kudos
Highlighted
Historian
Historian
9,116 Views
Registered: ‎02-25-2008


@kkn wrote:

Hi Bassman,

 

If you see the Virtex-4 configuraiton guide the Init_b signal will be low approx prog_b pulse width + Tpl(program latency).

Kindly check the figure 1-3 in the UG071

http://www.xilinx.com/support/documentation/user_guides/ug071.pdf

Tpl should be calculated based on the bitstream size of the device you have. 

In the datasheet the Tpl is available and it is 0.5 Us/frame.

http://www.xilinx.com/support/documentation/data_sheets/ds302.pdf

 

How much time is the init_b is low after the prog_b is high in your case?


OK, for my PROGRAM_B pulse width of 500 ns, I measure INIT_B low for ~229 us. INIT_B is asserted barely 167 ns after the assertion of PROGRAM_B.


The obvious question, then, is: once my master asserts INIT_B, does the FPGA ensure that it remains low for Tprog_b + Tpl, or must I ensure that I keep it asserted for that time?

 

Remember that I am not relying on the FPGA's power-on logic to start configuration, I am doing it whenever the application requires the FPGA to reconfigure.


If you consider XC4VLX200 as an example, the Tpl should be around (37,500*0.5 ) 18.75ms 


I'm using XC4VLX15,  with 3,740 device frames, so Tpl is 1.875 ms.

 

The data sheet gives Tpl as 0.5 us/frame max, which implies  that it could be much faster, which must be the case if I see it go away after 229 us.

 

The solution is what I proposed earlier: assert INIT_B and then stop driving it shortly thereafter, and then spin on INIT_B, waiting for it to go high before continuing with configuration. I've been testing this and it seems reliable.

----------------------------Yes, I do this for a living.
0 Kudos