Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 27 Feb., 03:30, rickman <gnu...@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. =A0I > couldn't test one value because I made a mistake and programmed two > boards with the same bit file. =A0Unfortunately the missing one is > likely the one we will want to use. =A0So 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 SulimmaArticle: 145901
> 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. Austin, You've posted this a few times. I've had a look at the Mentor web site for costs before but as usual they aren't mentioned. I don't want to contact them for pricing as it'll probably lead to being pestered by a rep. Does anyone know how much you'd pay for a one off license (US $ will do, although we probably pay the same in GBP as with most EDA tools)? Nial ---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 516 8883 32/12 Hardengreen Business Park Fax: +44 131 663 8771 Dalkeith, Midlothian EH22 3NX www.nialstewartdevelopments.co.ukArticle: 145902
On Feb 26, 4:52=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > Hello, > > I am using Xilinx ISE 11.1, and I need to place some components in > certain areas of the FPGA. I have never done manual PaR, so here are a > few questions: > 1) Do I need to manually place each and every net? > 2) Is it possible to just place 'blocks' of each component in a general > area of CLB on the device, and let the PaR algorithms auto route any > connecting nets? > > Thanks in advance, > Jason You can also use the User Constraints File to explicitly place individual elemens using a LOC constraint or associate many components into an AREA_GROUP constraint. Check out the Constraints Guide at http://bit.ly/8YkuR9 for the details.Article: 145903
On 2/26/2010 10:46 PM, -jg wrote: > > Why is there no simple Spice pathway to allow users do the 'sanity > check' stuff themselves ? > Because Spice models reveal more about the actual structure of the device than the vendors are prepared to give. The IBIS table based method keeps this proprietary information hidden. Syms.Article: 145904
>Hi, >I need to implement CRC detection in a Spartan3 Xilinx FPGA. My data stream >is coming in one byte at a time, but I do have about 8-10 clock cycles >between each byte (still tbd!). > >If I want to save area, is it better to use a CRC that works byte per byte >or bit per bit? > >Also, any idea where I could find code for the standard polynomials? > >Thanks! >Diego > >--------------------------------------- >Posted through http://www.FPGARelated.com > If you have 8-10 clock cycles, a serial implementation will most likely be the the easiest and the least resource intensive. The architecture is essentially a shift register with XOR gates inserted between some of the flops. Like others have mentioned, web based CRC calculation tools can be very useful when debugging the design. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145905
On 2/27/2010 11:53 AM, Kolja Sulimma wrote: > > > If there are no transmission line effects involved there will be no > overshoot. Below, please find a LTSpice model with only lumped components that produces overshoots. > Clock lines should always be terminated. Not always. For example, if the rise time of the clock is longer than a sixth of the trace delay, you almost certainly don't need to worry about termination. If the trace delay is longer than the rise time, you almost certainly do need to worry about it. http://www.sigcon.com/Pubs/straight/termcraz.htm HTH., Syms. Model:- Version 4 SHEET 1 880 680 WIRE 176 48 96 48 WIRE 336 48 256 48 WIRE 96 96 96 48 WIRE 336 96 336 48 WIRE 96 208 96 176 WIRE 336 208 336 160 FLAG 96 208 0 FLAG 336 208 0 SYMBOL voltage 96 80 R0 WINDOW 3 -16 165 Left 0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value PULSE(0 1 0 1n 1n 9n 20n) SYMBOL ind 272 32 R90 WINDOW 0 5 56 VBottom 0 WINDOW 3 32 56 VTop 0 SYMATTR InstName L1 SYMATTR Value 1n SYMBOL cap 320 96 R0 SYMATTR InstName C1 SYMATTR Value 10p TEXT 62 266 Left 0 !.tran 100nsArticle: 145906
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.Article: 145907
On 26/02/2010 14:57, Symon wrote: > On 2/26/2010 12:58 PM, David Brown wrote: >> >> I've figured it out - you are using "continuous" mode, so that the pdf >> reader is looking at the document as though it were one very tall page, >> and thus fit-width applies to the this whole continuous page. I prefer >> "single page" mode, in which fit-width (and fit-page) apply to a single >> page at a time. >> >> Hope that helps, >> >> David. > > David, you've solved it! I tried going into single page mode before, but > I didn't re-click the fit-width thing. > Cheers! > Glad to be of help. Much of what I know about high speed PCB design I've learned from listening in to you and other experts in c.a.f., so it's nice to give a little back. > p.s. I still maintain Altera are wrong to have landscape pages mixed in! > I like continuous mode. It's never easy finding a layout that suits everyone. If they kept the tables in portrait mode, they would have less information, or be crushed up. If they used landscape tables but kept portrait mode in the pdf file, you'd have to rotate the page to view it. Personally, I think it works well - but then, I like single-page mode. I think single-page mode is more like reading a book, while continuous mode is like reading fan-fold paper printouts from ages past.Article: 145908
On 02/27/2010 08:52 AM, John_H wrote: > On Feb 26, 4:52 pm, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> Hello, >> >> I am using Xilinx ISE 11.1, and I need to place some components in >> certain areas of the FPGA. I have never done manual PaR, so here are a >> few questions: >> 1) Do I need to manually place each and every net? >> 2) Is it possible to just place 'blocks' of each component in a general >> area of CLB on the device, and let the PaR algorithms auto route any >> connecting nets? >> >> Thanks in advance, >> Jason > > You can also use the User Constraints File to explicitly place > individual elemens using a LOC constraint or associate many components > into an AREA_GROUP constraint. > > Check out the Constraints Guide at http://bit.ly/8YkuR9 for the > details. Thanks for all the help, everyone. I have a lot to read up on. I'll be working on this in the next few days, you'll probably hear from me if I can't seen to get it working. Sincerely, JasonArticle: 145909
On Jan 28, 1:55=A0pm, "Charles" <charlesdlam...@gmail.com> wrote: > Hi All, > =A0 =A0 =A0 =A0I am new to the FPGA design flow. Now I am working on FPGA= editor to > make changes in the design. Once I make changes in the ncd file i can hav= e > either a modified ncd file or a bit file from it (using Bitgen). > > My question is that is it possible to do post route simulation from any o= f > these two files or is there any other way to do it?? > > Thanks in Advance, > > Charles. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You can run "netgen" command with the modified NCD to generate a Verilog or VHDL simulation model. Cheers, Jim http://myfpgablog.blogspot.com/Article: 145910
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). AustinArticle: 145911
On 2/26/2010 9:31 PM, austin wrote: > > 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!). Who are you, and what have you done with Austin? Syms. ;-)Article: 145912
On Feb 28, 8:27=A0am, austin <aus...@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.') =A0So, someone > has to code the .model additions to the spice program to deal with the > IBIS data files. =A0Unless they are doing it for fun, they probably wish > to get paid for their work: =A0I 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? =A0I 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... -jgArticle: 145913
On Feb 28, 2:59=A0am, Symon <symon_bre...@hotmail.com> wrote: > On 2/26/2010 10:46 PM, -jg wrote: > > > =A0 Why is there no simple Spice pathway to allow users do the 'sanity > > check' stuff themselves ? > > Because Spice models reveal more about the actual structure of the > device than the vendors are prepared to give. The IBIS table based > method keeps this proprietary information hidden. hmm.. sounds more like spin/deflection than a real reason, to me. I did find a useful IBIS resource web page here http://www.mentor.com/products/pcb-system-design/modeling-resources includes links to many free resources... (something FPGA vendors could learn from.. ?) -jgArticle: 145914
On Feb 27, 3:56=A0pm, -jg <jim.granvi...@gmail.com> wrote: <snip> > 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 Or the simplest IBIS simulator with single source, single destination, simple transmission line. Kind of like what Hyperlinx was back when you could get a free version.Article: 145915
On Feb 17, 9:09=A0pm, Verictor <stehu...@gmail.com> wrote: > Hi, > > I have a V4 with input clock frequency running at 130MHz. This clock > goes into a DCM then CLK0 goes out to other logic. The CLK0 net is > named as "derived_clock" by Synplify. Now the timing report on the > input 130MHz is fine (positive slack) but the derived_clock doesn't > meet timing. How to contrain that? > > Thanks. The fact you stated that "the derived_clock doesn't meet timing" means the clock is already constrained. You need to look at the timing report to figure out why it doesn't meet timing (.e.g. too many logic levels, too big clock skews, bad placements, etc). Cheers, Jim http://myfpgablog.blogspot.com/Article: 145916
On Feb 27, 8:59=A0am, Symon <symon_bre...@hotmail.com> wrote: > On 2/26/2010 10:46 PM, -jg wrote: > > > =A0 Why is there no simple Spice pathway to allow users do the 'sanity > > check' stuff themselves ? > > Because Spice models reveal more about the actual structure of the > device than the vendors are prepared to give. The IBIS table based > method keeps this proprietary information hidden. > > Syms. That is not fully accurate, even if it is many vendors' party line. Yes, if they create the spice model by describing their actual circuit in the spice model, it can be reverse engineered. But just like they generated an IBIS file which only describes the behavior of the IO port, they can describe the same behavior in a spice model. In fact, I found one program from Intusoft that will convert an IBIS file into a spice model. But it has two problems. One is that it generates only one version of spice code that is not compatible with the spice program that I use. The other is that it does not work with all versions of IBIS (including the newest one) so that it won't convert all IBIS files. Those are both pretty big limitations, but it shows that a spice model can be created that does not give away proprietary information. The vendors simply feel that their customers don't "need" spice models. That goes back to exactly "who" their customers (or main customers) really are. The FPGA vendors cater to the comms markets who buy a lot of FPGAs and also buy the really high end, super expensive FPGAs. Those guys pretty much don't mind spending $5k on a tool that gets used a handful of times per year. We smaller customers, who don't have the cash to spend on a tool that merely reduces the vendor's inconvenience, prefer using open source tools that are very well supported, like LTspice, over commercial tools that are expensive and often poorly supported. RickArticle: 145917
On Feb 26, 11:25=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Feb 27, 3:30=A0pm, rickman <gnu...@gmail.com> wrote: > > > =A0If Xilinx had an appropriate > > part, I likely would have used it. =A0But 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? > =A0Actel seem to have good coverage there, and we are about > to trial a ProASIC nano. > =A0Actel 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. RickArticle: 145918
On Feb 27, 6:53=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 27 Feb., 03:30, rickman <gnu...@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. =A0I > > couldn't test one value because I made a mistake and programmed two > > boards with the same bit file. =A0Unfortunately the missing one is > > likely the one we will want to use. =A0So 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. RickArticle: 145919
On Feb 27, 9:20=A0am, Symon <symon_bre...@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. RickArticle: 145920
On Feb 27, 2:27=A0pm, austin <aus...@xilinx.com> wrote: > Re: Spice > > If everything used, free? =A0I 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??? RickArticle: 145921
On Feb 27, 3:56=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Feb 28, 8:27=A0am, austin <aus...@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.') =A0So, someone > > has to code the .model additions to the spice program to deal with the > > IBIS data files. =A0Unless they are doing it for fun, they probably wis= h > > to get paid for their work: =A0I 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? =A0I 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. RickArticle: 145922
On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg <jim.granville@gmail.com> wrote: >On Feb 28, 2:59 am, Symon <symon_bre...@hotmail.com> wrote: >> On 2/26/2010 10:46 PM, -jg wrote: >> >> > Why is there no simple Spice pathway to allow users do the 'sanity >> > check' stuff themselves ? >> >> Because Spice models reveal more about the actual structure of the >> device than the vendors are prepared to give. The IBIS table based >> method keeps this proprietary information hidden. > >hmm.. sounds more like spin/deflection than a real reason, to me. > >I did find a useful IBIS resource web page here > >http://www.mentor.com/products/pcb-system-design/modeling-resources > >includes links to many free resources... > >(something FPGA vendors could learn from.. ?) > >-jg Actually FPGA vendors do the same thing. From A to X, all FPGA vendors supply a free version of their tool. So I think you're being a little bit hard on them. With respect to IBIS, I think it is not reasonable to expect any vendor to give their actual circuit so that clients would be able to simulate with it. Even if they did, you'd still need a tool to extract your PCB to generate the netlist for the rest of the system (which interestingly is available for free too). If you say that they can simpify the netlist not to expose their circuits, then IBIS is the modelling language to generate that simplified circuit. Finally what you want (a basic tool which shows you rise/fall times for simple loads) is already available. You can get the Visual IBIS editor and use its waveform viewer to get what you want. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 145923
On Feb 27, 11:13=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg > > > > <jim.granvi...@gmail.com> wrote: > >On Feb 28, 2:59 am, Symon <symon_bre...@hotmail.com> wrote: > >> On 2/26/2010 10:46 PM, -jg wrote: > > >> > Why is there no simple Spice pathway to allow users do the 'sanity > >> > check' stuff themselves ? > > >> Because Spice models reveal more about the actual structure of the > >> device than the vendors are prepared to give. The IBIS table based > >> method keeps this proprietary information hidden. > > >hmm.. sounds more like spin/deflection than a real reason, to me. > > >I did find a useful IBIS resource web page here > > >http://www.mentor.com/products/pcb-system-design/modeling-resources > > >includes links to many free resources... > > >(something FPGA vendors could learn from.. ?) > > >-jg > > Actually FPGA vendors do the same thing. From A to X, all FPGA vendors > supply a free version of their tool. So I think you're being a little > bit hard on them. With respect to IBIS, I think it is not reasonable > to expect any vendor to give their actual circuit so =A0that clients > would be able to =A0simulate with it. You are missing the point. No one has to give their "actual circuit" in order to provide a spice model. If they have characterized the circuit to build the IBIS model, they can use that same data to produce a spice model that does not reveal the circuit. The more I discuss this, the more I am ticked off about it. The vendors all understand what I am saying. So why are they being so stubborn about not providing characterized spice models? Is there anyone who can explain why spice models that don't reveal circuit details are not provided by the vendors? Is it a mindset that they are providing IBIS models and that should be good enough? I get the impression that when spice models are provided, little or no effort is made to make them compatible with the free versions like LTspice (which btw is an excellent tool!) > Even if they did, you'd still need > a tool to extract your PCB to generate the netlist for the rest of the > system (which interestingly is available for free too). I don't agree that without PCB data an IO model is not useful. All I was looking for was info on the IO without the PCB details. I had no idea what to expect by changing the current setting vs. changing the speed setting. In fact, the more I think about this, the more I realize that even with simulation data, there is no way to guesstimate what to expect and you are left to perform trial and error tests! The only info they give as a function of the settings are the voltages and delays as a function of current. There is no info regarding the speed setting at all! I guess we are all used to designing FPGAs in the dark. > If you say > that they can simpify the netlist not to expose their circuits, then > IBIS is the modelling language to generate that simplified circuit. Yeah, so what's your point? Why can't they then provide that model in a spice description? > Finally what you want (a basic tool which shows you rise/fall times > for simple loads) is already available. You can get the Visual IBIS > editor and use its waveform viewer to get what you want. Now this is some useful info. I downloaded this program and took a look at the waveforms. What could be displayed was very limited and I'm not even sure what the data represents! I looked at a couple of drive strengths that I think are the most interesting and with the 8 mA drive I found the signal never goes above 2.25 volts. It has an intial hump to about 2.25 volts until about 4 ns and then comes back down to about 1.5 volts where it remains for the rest of the data (up to 20 ns). I believe this circuit is driving a 100 ohm pull down resistor which would imply the IO has a 100 ohm effective series resistance. I believe the waveforms are an accurate representation of the part even if I have no idea what it means. On the 12 mA drive level the same thing is seen, although not as pronounced and I see that on the board. Of course the voltage levels are different because I don't have a 100 ohm pulldown in the real circuit. My point is that even after running the simulation, I'm not sure what I am looking at. Is this hump because of something internal to the FPGA, such as extra drive that is turned on during the transition time, or is this a reflection that was captured when collecting the data to enter into the model file? From what I see here, I would say that the best simulation is the one I run on my board. I am starting to think I have been wasting my time pursuing any of this. What good is a model that is totally incapable of modeling my circuit even if I have the full blown multi-kilobuck version of the software? RickArticle: 145924
Assuming you are talking about MAX-II: According to MAX-II device handbook (p.2.29) for any given I/O standard there are only two levels of of programmable drive strength control. So, 8mA and 12mA being the same is not surprising. W.r.t. slew rate control the handbook doesn't say how exactly it is implemented but gives you a hint on p.2.30 - "The lower the voltage standard (for example, 1.8-V LVTTL) the larger the output delay when slow slew is enabled." Being EE from that phrase you could probably figure out the topology of their slew control. Since I am not EE, nor a specialist in CMOS circuit design I wouldn't say what my guess is. My personal advice, not from EE but from experienced Altera designer nevertheless - unless you line has low-impedance parallel termination resistor use minimal drive strength and fast slew rate.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z