I have one question from our customer.
Accroding to the Table 7-9 in 7.3.18 Reset Electrical Data/Timing of datasheet(sprs695a), it is specified that " th(BOOT)" (= Hold time, BTMODE[15:0] pins valid after xPOR high or xRESET high) is 0 ns (min ). But maximum value is not written in Table 7-9.
I know the value of maximum for the hold time is not needed usually. But our customer will connect one ASIC device to GPMC port. So ASIC device must output hi-z level signal until BTMODE port output. How is maximum value for "th(BOOT)"?
Or, according to the table 7-10 in 7.3.18 section of datasheet, it is specified that "td(RSTH-IOFUNC)" (= Delay time, xRESET high or xPOR high to all I/Os exiting their reset state). this timing is only specified the maximum value. How is minimum value for "td(RSTH-IOFUNC)"? If this minimum value is specified, the collision of ARM output and ASIC output can be avoided.
Please let me know which one value "the(BOOT)" maximum or "td(RSTH-IOFUNC)" minimum.
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.
Note: If this answer solves your question please mark post as "Answered"
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.
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.
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.
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.
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.
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.
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.
Regarding your question, Answer is Yes. Customer is usingGPMC(NOR) bootmode on their system.
Is this customer's using no problem?
Please reply me. The situation is urgent. Customer's development is pending for this matter.
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.