Frustration with Vendors!
in [FPGA]
|
From: austin on 26 Feb 2010 16:31 Rick, Must not be a Xilinx part, as our hotline engineers have copies of all popular signal integrity tools, and any webcase (from a paying customer: students and hobbyists might have to email me, or post their queury on our forums) that provides the needed information (part number, package, io type, drive strength, slew setting, pcb trace length, load) can request a "what if" sanity check answer (slew rate, overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ temperature corners).... You know my email, too, so if you had emailed me, you would have your answer by now. I really have to say that paying for Hyperlynx once is a lot cheaper than fixing board, after board, with bad SI. In fact one re-spin of the pcb is about what the tool costs. Now, you know I don't gain anything from the endorsement of this tool, unless it is one of our parts that is being used (as the board gets done sooner, and we see revenue earlier). Seems some companies really have forgotten that they need customers. Been a long time since I posted something like this... with Peter Alfke retired from Xilinx, I wear a "white hat" all the time now, and I am nothing but nice, and helpful (no negativity!). I think my fearsome reputation in the halls of the 'other' FPGA company has quietly faded from memory. Austin
From: -jg on 26 Feb 2010 17:46 On Feb 27, 10:31 am, austin <aus...(a)xilinx.com> wrote: > Rick, > > Must not be a Xilinx part, as our hotline engineers have copies of all > popular signal integrity tools, and any webcase (from a paying > customer: students and hobbyists might have to email me, or post > their queury on our forums) that provides the needed information (part > number, package, io type, drive strength, slew setting, pcb trace > length, load) can request a "what if" sanity check answer (slew rate, > overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ > temperature corners).... Decoding all that tho, confirms Rick's issue that there is no easy way for a customer to simply do this themselves ? Why is there no simple Spice pathway to allow users do the 'sanity check' stuff themselves ? It seems IBIS to spice is doable, but with some caveats, so is the sort of thing a vendor should do once, as opposed to hundreds of customers ? Many Spice offerings have node-limited freebies, and there are widely used free items like LTSpice and SpiceOpus. -jg
From: rickman on 26 Feb 2010 21:30 On Feb 26, 4:31 pm, austin <aus...(a)xilinx.com> wrote: > Rick, > > Must not be a Xilinx part, as our hotline engineers have copies of all > popular signal integrity tools, and any webcase (from a paying > customer: students and hobbyists might have to email me, or post > their queury on our forums) that provides the needed information (part > number, package, io type, drive strength, slew setting, pcb trace > length, load) can request a "what if" sanity check answer (slew rate, > overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ > temperature corners).... > > You know my email, too, so if you had emailed me, you would have your > answer by now. > > I really have to say that paying for Hyperlynx once is a lot cheaper > than fixing board, after board, with bad SI. In fact one re-spin of > the pcb is about what the tool costs. Now, you know I don't gain > anything from the endorsement of this tool, unless it is one of our > parts that is being used (as the board gets done sooner, and we see > revenue earlier). > > Seems some companies really have forgotten that they need customers. > > Been a long time since I posted something like this... with Peter > Alfke retired from Xilinx, I wear a "white hat" all the time now, and > I am nothing but nice, and helpful (no negativity!). I think my > fearsome reputation in the halls of the 'other' FPGA company has > quietly faded from memory. > > Austin Thanks for the reply. No, it isn't a Xilinx part and no one is respinning any boards over this. In fact, the point is that I have the ability to deal with the SI issue by adjusting the IO parameters. But it would be so much easier to get a handle on what settings to try for testing if I had the simple, basic data of what the part does when the settings are adjusted. I'm not planning to spend five large to make up for a vendor's shortcomings. If Xilinx had an appropriate part, I likely would have used it. But it is hard to find any FPGAs in 100 TQFP packages, much less Flash based ones. The problem started when we found the original setting produced a rising edge so slow that it created multiple pulses on a clock line. The board worked ok in the original chassis, but the new customer design uses a faster FPGA to receive the clock and had failures. In the end, I had to meet with my customer today with a bucket of boards with different settings. I think we can use one of the mid range values that gives a good trade off of edge rate and overshoot. I couldn't test one value because I made a mistake and programmed two boards with the same bit file. Unfortunately the missing one is likely the one we will want to use. So I'll be back with my customer Monday with another board. Rick
From: -jg on 26 Feb 2010 23:25 On Feb 27, 3:30 pm, rickman <gnu...(a)gmail.com> wrote: > If Xilinx had an appropriate > part, I likely would have used it. But it is hard to find any FPGAs > in 100 TQFP packages, much less Flash based ones. Which Flash FPGA in 100 pins did you select? Actel seem to have good coverage there, and we are about to trial a ProASIC nano. Actel also look to be releasing an ARM variant next week. -jg
From: Kolja Sulimma on 27 Feb 2010 06:53
On 27 Feb., 03:30, rickman <gnu...(a)gmail.com> wrote: I think we can use one of the mid range > values that gives a good trade off of edge rate and overshoot. I > couldn't test one value because I made a mistake and programmed two > boards with the same bit file. Unfortunately the missing one is > likely the one we will want to use. So I'll be back with my customer > Monday with another board. If there are no transmission line effects involved there will be no overshoot. If there are transmission line effect involved I believe that you need something more reliable than a output drive setting which might show any sort of variation from part to part, over temperature, supply voltage and aging. DCI would be a good solution, but I guess the part you are using is not supporting it so you are trying to mimik it with output drive settings. >but the new customer design uses a faster FPGA to receive the clock Clock lines should always be terminated. I prefer series terminations, but those are hard to implement on an existing board. But on a tqfp package it should be possible to patch a parallel 0201 resistor on the receiving pin to completly get rid of the overshoot even with the fastest slew rate setting. Kolja Sulimma |