th(BOOT) timing for maximum

Hi Michi,

Judging from the two tables, along with figures 7-4 and 7-5, I would say that ASIC should hold its hi-z state until "td(RSTH-IOFUNC)" maximum time has expired, i. e. 14ns. I don't have any values, except  those figuring in the datasheet.

Best Regards
Biser

Dear Biser-san,

Thank you for your reply.

Could you give me more detailed data for th(BOOT)?  Customer would like to know more accuracy data, the maximum value of  th(BOOT), or the minimum value of td(RSTH-IOFUNC).

I appreciate your support.

Best regards,

Michi

I'm sorry, I have only the values that are given in the datasheet, just like you. That is why I suggested that you use the td(RSTH-IOFUNC) maximum time of 14ns. This should be safe enough for preventing I/O conflicts.

Dear Biser-san,

Thank you for your support.

I talked wih my customer regarding this. And I found my fault. The customer would like to know different thing.

According to the customer explanation, customer's ASIC output the config data to AM3874 when reset. And its cofiguration data is latched by POR rising edge. After reset, BTMODE pins are used as address/data signal. So the ASIC must stop to output  the cofig data to AM3874 for avoiding the bus conflict to BTMODE signal(address/data).      So customer would like to know the allowance delay time for config data. The current spec is specified only minimum hold time. But customer need the information of maximum hold time by the above reason. So the time 14ns is not suitable for this spec.

Please let me know the th(BOOT) max value.

Best regards,

Michi

Dear Biser-san,

Thank you for your quick reply.

I understand you have only the datasheet values. But customer said me they can't stop to output config data soon as "0ns".  Customer doesn't know the maximum value of hold time. If customer takes 10ns to stop the cofig data, does TI guarantee it? I think it is impossible. Of course customer never accept it.

So could you recommend some solutions to customer as TI? Now we can't give the value of the specifiation. But probably you can advise the solution to the customer how to do it. Customer needs any guidance for design.

I appreciate your quick reply.

Best regards,

Michi 

Hi Michi,

Can the external ASIC tri-state it's line while the Davinci processor comes out of reset?  This will be the lowest risk approach, and the intended way to use our BTMODE pins.  For instance, if the ASIC can tri-state the data lines connected to BTMODE pins until you see RSTOUT go high, then we can simply use external pull-ups/pull-downs on these lines, hence eliminating contention possibilities.

As per Figure 7-4, BTMODE pins will go from Hi-Z to active state in at most 14ns from when POR goes high.  I feel it's going to be tough to time the ASIC at this level of resolution.

Dear Ivan-san,

Thank you for your reply.

Regarding your question " Can the external ASIC tri-state it's line while the Davinci processor comes out of reset?", the answer is No.

 Because ASIC outputs the config data to AM3874 when reset.  And its configuration data is latched by POR rising edge. According to the

AM3874 datasheet,  hold time BTMODE[15:0]  pin  is minimum 0ns. But ASIC can't stop to output the config data soon after POR rising, as you know.

So customer would like to know the maximum time for config data output. If TI can't give its maximum value to the customer, please let them know some solutions to customer how to handle it.

Please let me know.

I appreciate your quick reply.

Hi Michi,

We're working with the architecture team on this.  In the mean time, can you confirm the bootmode you're using?  Is it a GPMC bootmode?  If there's flexibility here, we may choose a bootmode that allows us to stay in hi-z for these pins even after reset.  Looking at table 3-1, the pins show up as "I" (input) pins by default.  Unless we're booting from GPMC (NOR or NAND) I don't expect these pins to want to drive right after reset.

Dear Ivan-san,

Thank you for your support.

Regarding your question, Answer is Yes. Customer is usingGPMC(NOR) bootmode on their system.

Is this customer's using no problem?

Best regards,

Michi 

Dear Ivan-san,

Thank you for your support.

Please reply me. The situation is urgent. Customer's development is pending for this matter.

Best regards,

Michi

Michi, I'm checking with the design team.  In case we don't converge on a good solution for this timing, would the customer consider using a small SPI flash to boot from (UBL-like), and then proceed to communicate with the FPGA via GMPC?  We could then do the following:

1. Boot from SPI (GPMC pins should be tri-stated)

2. Complete SPI boot, signal FPGA that we're ready (GPMC pins should be tri-stated)

3. TI processor would then start accessing FPGA via GPMC

SPI flash should not be expensive to add and is very small form factor-wise.

I've received some information from the design team.  We're in the process of confirming that we could get about 100ns of time before the pins start driving.  Will let you know, but maybe in the mean time you can let me know if this timeframe would even be helpful.

The silicon itself doesn't try to drive the pins.  It is the software that does this.  By default, the pins stay tri-stated during and after reset.  However, we need to be careful of when the boot ROM configures NAND/NOR to start fetching data (at this point the lines start to drive).  In other words, if you didn't use GPMC to boot, those pins would remain in tri-state.

Before the software gets a chance to execute, the hardware will have a delay of ~100ns (we're confirming this still).  Something to consider if this amount of time is something you can work with.

Dear Ivan-san,

Thank you for your reply.

I think it is very helpful information we have 100ns before the pins start driving. I will let our customer know this information.

Please continue to confirm this information.

I appreciate your support.

Best regards,

Michi