Frustration with Vendors!
in [FPGA]
|
From: rickman on 27 Feb 2010 21:31 On Feb 26, 11:25 pm, -jg <jim.granvi...(a)gmail.com> wrote: > 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 Lattice XP3C in the TQ100 package. I much prefer leaded packages for several reasons and the TQ100 was the largest that would fit on the board. It also was the smallest I could get. My only other choice was various BGA type packaging or the really fine pitch QFN devices. Another reason that most of the non-leaded devices were less than optimal is that they mostly have more I/Os and so cost more. I could have used a 256 pin part, but the price is nearly double! Right now I would love to have the higher gate count I can get in that package, but I will make do with 3k LUTs. Rick
From: rickman on 27 Feb 2010 21:43 On Feb 27, 6:53 am, Kolja Sulimma <ksuli...(a)googlemail.com> wrote: > 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 Yes, SI is a complex issue and often simple solutions fail. But in this case, I am confident we can make it work by controlling the edge rate. Let's face it. If the device only fails because the edge is stretched out to 40 ns, I expect we can find a happy medium that works well even with variation between parts. So far, every edge rate we have tested, other than the worst case slow, seems to make the board work. I am going to shoot for one of the faster options which should give us lots of margin on the current problem as long as we don't get serious overshoot. The board does have provision for a series termination. But that is no magic bullet either. There is a connector about an inch from the output pin which will produce a reflection that can cause some issues for faster edge rates regardless of the termination. I am sure this will work just fine. My only issue is that I had to do a lot more work investigating this issue than I would have if I simply had the information I had requested, not to mention the time I spent fruitlessly trying to get the information. Rick
From: rickman on 27 Feb 2010 21:59 On Feb 27, 9:20 am, Symon <symon_bre...(a)hotmail.com> wrote: > On 2/27/2010 2:30 AM, rickman wrote: > > > > > 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. > > I expect the actual failure was the newer FPGA occasionally saw the slow > falling edge of the clock as a rising edge. It sounds like your clock > frequency is low, why don't you just build a falling edge glitch filter > in the new FPGA? > > Syms. That is not my FPGA, it is my customer's. But he did just that to investigate the issue before he had scope'd the line and found the slow edge. He had explored other possibilities first, likely because this module works in the original system so it wan't the first suspect. This is not an extremely fast clock. It is a programmable rate up to 6.144 MHz (half the ref clock of 12.288 MHz). As an input to my FPGA, I would not be using it as a clock, but rather I would sample it with a system clock at a higher rate and detect the edge to use it as an enable for the data and cross it into the system clock domain. This all by itself would eliminate the noise issue. In fact, in an unrelated design, my customer told me he has an FPGA design with 90 clocks and was having trouble with the tools making it all work!!! I explained to him how to sample the slower clocks with a single system clock to transport signals across clock domains and I think he is going to do that. Rick
From: rickman on 27 Feb 2010 22:08 On Feb 27, 2:27 pm, austin <aus...(a)xilinx.com> wrote: > Re: Spice > > If everything used, free? I can not imagine that everyone out there > is using free schematic, free pcb layout, etc. tools! > > Someone might be, but that must be the hobby type, or student > (although students usually have free access to dozens of very powerful > tools, if they would only ask their professor!). Yes, there are no useful free tools in the world. That is why no FPGA companies provide tools that run under a free, open source OS like Linux. ;^) > Anyone with a business can certainly justify paying for something > useful, that would save them time (or money). IF it saved them time and money. Why would you expect that to be true of all paid tools? Even if there is a time savings, isn't there a tradeoff? Is the tool worth the price? The price is not just the money. I have to use a licensed tool for FPGA development and it has been more than once I spent a lot of time just working around license issues, which always seem to occur on Friday afternoon when I plan to work over the weekend! If I had a choice, I would never use another commercial tool again. But some tools are just not available... yet. Maybe the world is not the way you seem to see it??? Rick
From: rickman on 27 Feb 2010 22:11
On Feb 27, 3:56 pm, -jg <jim.granvi...(a)gmail.com> wrote: > On Feb 28, 8:27 am, austin <aus...(a)xilinx.com> wrote: > > > > > Re: Spice > > > I know that hspice has an interface to allow IBIS models to be > > declared, and used, with the spice netlist. > > > I suspect, "real" spice tool vendors expect one to pay for this sort > > of feature, which is not part of the free UC Berkeley spice source > > code (on which all the free spice versions are 'based.') So, someone > > has to code the .model additions to the spice program to deal with the > > IBIS data files. Unless they are doing it for fun, they probably wish > > to get paid for their work: I would need some monetary motivaion now, > > as coding might have been 'fun' when I was 14 years old, but that was > > a long time ago. > > > So, yes Hyperlynx ia not free, and neither is hspice. > > > If everything used, free? I can not imagine that everyone out there > > is using free schematic, free pcb layout, etc. tools! > > > Someone might be, but that must be the hobby type, or student > > (although students usually have free access to dozens of very powerful > > tools, if they would only ask their professor!). > > > Anyone with a business can certainly justify paying for something > > useful, that would save them time (or money). > > > I am a ham radio operator (AB6VU), and I do have my own collection of > > useful free stuff, but even I have purchased some of my hobby software > > when necessary (but, I will admit, I don't own any hobby software with > > more than a $100 price tag). > > > Austin > > You've somewhat missed the point. > > Xilinx tools are likely to be free to the vast majority of users. > > Xilinx PAY their employees to create models, and the tools. > > It's simple common sense for Xilinx to do this once, vs hundreds of > users, having to either call xilinx (and so consume man-hours), or > find a solution themselves. > > The spice models do NOT have to be full fab-mosfets ones - as you have > mentioned, the device/temperature/voltage variations already swamp > small tool variations. > > If someone wanted to get creative, they could do a competition for the > best IBIS to Spice, with two categories ? : > a) The Simplest, and most portable. > b) A higher level of accuracy > > Sounds like a good final year project to me... > > -jg Ahhhh... someone who understands me! Thanks. Rick |