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
Structural simulation of FFT core reveal the frequency to bin (XK_IDX) mapping are bit reversed when the FFT core is configured to output in streaming, natural order. Real time swapping of the frequency needs FIFO of 2^N deep. Can anyone help me to implement a more optimized freq swap method.Article: 135076
edwin.gobain@gmail.com writes: > I am new to ASIC prototyping approaches. I know it concept wise but > want to know more about how popular is it among designers. In other I would say that it's quite popular. However, you want it to be as transparent as possible. You would like it to behave like a fast simulator (which is a *lot* cheaper, but your observability is somewhat limited compared to simulation). But you will typically find yourself spending considerable amount of time optimizing your design to make the timing requirements. If you interface to some standard bus like PCIe or similar you have to make the speed requirements. But if you interface only to yourself you might be able to scale the "simulation" down without having to meet the requirements of other interfaces. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 135077
Jon Elson wrote: (snip) > Well, it is all designed and the board is layed out. I used the AD > CMP603 single fast comparator. A bear to mount, but a very fine chip > for the purpose. It DOES use 2 range switching caps, plus stray > capacitance as the lowest cap value, plus 2 selections of > current-programming resistor. One that I worked on some time ago, using a custom ASIC, did something like that for the low order bits and digital counter logic for the high bits. The goal was to measure the arrival time of pulses fairly accurately. As for fully digital, it might be that you could use four 125MHz clocks 90 degrees apart in phase, and for input timing latch the input with all four clocks. For output, OR the output of four registers, each clocked by one of the clocks, with the appropriate input depending on which edge it should switch. There are many other design methods which trade more slow logic for a small amount of fast logic. Otherwise, a small amount of ECL on the output of the FPGA and before the real output could do it. For example, put a small loadable ECL shift register on the output of the FPGA, clocked at the full 500MHz, but the FPGA clocks much slower. (How fast is ECL these days?) -- glenArticle: 135078
On Sep 13, 8:39 am, rickman <gnu...@gmail.com> wrote: > There are any number of reports that Vista will make your software run > significantly slower than XP... or better yet, Win2k. If you could > manage it, I would love to see this measured for FPGA work. Clippy: "You appear to be trying to build a circumvention device..."Article: 135079
I guess that people in this group might be interested in
hearing about this years FPL conference.
* All of the keynotes were interesting, especially the
SETI and CERN keynotes.
* The CERN keynotes contained lots of details about the LHC which I hadn't
heard before. One interesting detail: The FPGAs close to one of the
detectors could not be cooled using fans because of the insane magnetic
field.
* The SETI talk partly described the FPGA based infrastructure used by
the "Center for Astronomy Signal Processing and Electronics Research".
casper.berkeley.edu has more information, including source code and board
schematics/layouts.
* Some other interesting presentations I attended:
* Martin Langhammer from Altera presented a very interesting paper about a
floating point datapath compiler. By removing parts of the normalization
and denormalization it is possible to reduce the area and latency of the
datapath. Unfortunately the tool is not available yet...
* Simulating neural networks (the application was the processing of
sensor data from whiskers)
* It was very interesting to listen to all papers in the financial
section as I know very little about this kind of area but would
like to know more.
* Also, for similar reasons, the paper on molecule docking code was
interesting as I know very little about this area.
* Tom van Court of Altera gave a nice overview of the various tools
that try to convert some form of C to hardware.
* I also got to meet a few people from comp.arch.fpga :)
* Finally, I got a nice book from the Synopsys representative.
"Advanced FPGA Design" by Steve Kilts. It contains a nice writeup
of some important details which are typically ignored or glossed over
in many textbooks. (Such as clock domain crossings.)
/Andreas
Article: 135080> I'd be interested in the details. What does it do when you power up? It has a little CPLD. > From where does it read its initial bitstream? If there's no flash or ROM, > there's an active agent, either external or onboard, stuffing a bitstream to > the device. Is there an MCU onboard? Does it require an external JTAG > connection for bootup? Of course, this board is configured with JTAG connection and XMD works OK, but my intention is automating this process.Article: 135081
On Fri, 12 Sep 2008 18:19:03 +0200, Frank Buss <fb@frank-buss.de> wrote: >Michael Dreschmann wrote: > >> The active current is important, if we don't need the FPGA it will be >> completely disconnected from power. There is no limit in "how low >> power", the more low power the besser because the energy source will >> last longer ;) > >Why not just using a big FET switch for disconnecting it from power? Then >it will need (nearly) no power, when disconnected. This I wanted to say with "completely disconnected from power" ;) MichaelArticle: 135082
On Sat, 13 Sep 2008 06:29:09 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: > >If it is a research project, why does power matter so much ? >What is powering this, for how long ? It's powered optically, so power is the central point. >> but if possible >> also some further analysing of the videoframes and so on. > >but that is suddenly very open-ended :) Exactly, we want to test what we can implement with out limited power budget, perhaps 300mW all together. >> The active current is important, if we don't need the FPGA it will be >> completely disconnected from power. > >What makes that decison > >If you have an external uC, then adjust that for lowest Static/idle >power. Yes, we'll have a MSP from TI to control the whole system and power the FPGA if needed. >Then the uA/MHz numbers will matter most, and if you can push down the >MHz, you can start to lower Vcc. >Some vendors have more info than others here. You mean I can go down with the Corevoltage? This would be interesting. Thanks, MichaelArticle: 135083
On Fri, 12 Sep 2008 11:12:17 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >On Sep 12, 9:58=A0am, michael...@gmx.de (Michael Dreschmann) wrote: >> Hi! >> >> Thanks for your suggestions. >> >> >It would help if you gave more details with your question. =A0From what >> >you said, it seems like a CPLD would do the job. >> >> It's a research project at a university and at the moment we don't >> know exactly what we want to include in the CPLD/FPGA. A manchester >> encoder (100-200 MBit), a manchester decoder (some MBit) and some >> datasignal conversation from a video camera for shure, but if possible >> also some further analysing of the videoframes and so on. Hard to say. >> I would prefer a FPGA because then we porbably won't come to the limit >> of a familiy so fast. >> >> >How low power do you need and what is most important, active current >> >or quiescent? >> >> The active current is important, if we don't need the FPGA it will be >> completely disconnected from power. There is no limit in "how low >> power", the more low power the besser because the energy source will >> last longer ;) >> >> >What clock rates are you using? =A0Will the part be >> >mostly idle or very active? =A0What size will your design be? >> >> The clockrates I would guess arround 40 MHz, apppart from the >> manchester encoder/decoder and as said before everytime it's powered >> it'll be probably full active. > >Of course lower power is better. That is a given. But you need to >quantify a value. Otherwise you have no idea when when you have found >a part that is "good enough". You need to set some design goals for >battery life and with the size of the battery you can use, spec a max >active current. No point in even looking at PLDs until you know what >you are looking for. As said in the other post, we probably have something around 300mW for the whole system and we want to see whats possible with this amount. But this also includes Videosensors, some actors (buffered by capacitors) and so on. >BTW, a manchester encoder/decoder is typically a *very* small design, >so even at 200 MHz, it won't use much power. Also this is not fixed, in the last design we used manchester in a CPLD but if we have an FPGA we can use more complicated codes. It's all about "what we can archive at maximum with the given power and there I thing a low power FPGA can do more than any processor oder CPLD. Sandby is not important, an MSP controller will disconnect the PLD vom power if not used. >The CPLDs can run in the low mA range depending on your design size. >They are very linear with speed and the amount of logic used, going to >nearly zero when the clock is stopped or the design size approaches >zero. > >In a nutshell this is what you are likely to find. So can you live >with around 100 mA active current or do you need to keep looking and/ >or consider a CPLD? 100mA would be to much, Siliconblue stated for one of their smaler parts around 8mA for a completely with counters filled FPGA at 32 MHz. This would be an acceptable value. Unfortunately it seems that's impossible to test their designsoftware without a licence to see what fits exactly in such a part. >If you really need to know how low the power is, >you need to figure out just how large your design is. I don't know >your constraints working at the University, but in a commercial >application, if we don't have good info on the FPGA design we want, it >would be prototyped in an eval board before we would attempt to spec >any hardware. Is there a reason that you need to spec your hardware >before you know what it will be hosting? Yes, the plattform with the FPGA is powered optically and we have a given amount of power and want to figure out what we can do with that power. So the goal is not to solve a given problem with minimum power but to see what problems can be solved with a given power. In the last time I heard many times about the Actel Igloo, maybe they will find their way into our design. Has anyone experience with the siliconblue parts? Thanks, MichaelArticle: 135084
On 15 sept, 12:24, michael...@gmx.de (Michael Dreschmann) wrote: > On Fri, 12 Sep 2008 11:12:17 -0700 (PDT), rickman <gnu...@gmail.com> > wrote: > > > > >On Sep 12, 9:58=3DA0am, michael...@gmx.de (Michael Dreschmann) wrote: > >> Hi! > > >> Thanks for your suggestions. > > >> >It would help if you gave more details with your question. =3DA0From = what > >> >you said, it seems like a CPLD would do the job. > > >> It's a research project at a university and at the moment we don't > >> know exactly what we want to include in the CPLD/FPGA. A manchester > >> encoder (100-200 MBit), a manchester decoder (some MBit) and some > >> datasignal conversation from a video camera for shure, but if possible > >> also some further analysing of the videoframes and so on. Hard to say. > >> I would prefer a FPGA because then we porbably won't come to the limit > >> of a familiy so fast. > > >> >How low power do you need and what is most important, active current > >> >or quiescent? > > >> The active current is important, if we don't need the FPGA it will be > >> completely disconnected from power. There is no limit in "how low > >> power", the more low power the besser because the energy source will > >> last longer ;) > > >> >What clock rates are you using? =3DA0Will the part be > >> >mostly idle or very active? =3DA0What size will your design be? > > >> The clockrates I would guess arround 40 MHz, apppart from the > >> manchester encoder/decoder and as said before everytime it's powered > >> it'll be probably full active. > > >Of course lower power is better. =A0That is a given. =A0But you need to > >quantify a value. =A0Otherwise you have no idea when when you have found > >a part that is "good enough". =A0You need to set some design goals for > >battery life and with the size of the battery you can use, spec a max > >active current. =A0No point in even looking at PLDs until you know what > >you are looking for. > > As said in the other post, we probably have something around 300mW for > the whole system and we want to see whats possible with this amount. > But this also includes Videosensors, some actors (buffered by > capacitors) and so on. > > >BTW, a manchester encoder/decoder is typically a *very* small design, > >so even at 200 MHz, it won't use much power. > > Also this is not fixed, in the last design we used manchester in a > CPLD but if we have an FPGA we can use more complicated codes. It's > all about "what we can archive at maximum with the given power and > there I thing a low power FPGA can do more than any processor oder > CPLD. Sandby is not important, an MSP controller will disconnect the > PLD vom power if not used. > > >The CPLDs can run in the low mA range depending on your design size. > >They are very linear with speed and the amount of logic used, going to > >nearly zero when the clock is stopped or the design size approaches > >zero. > > >In a nutshell this is what you are likely to find. =A0So can you live > >with around 100 mA active current or do you need to keep looking and/ > >or consider a CPLD? > > 100mA would be to much, Siliconblue stated for one of their smaler > parts around 8mA for a completely with counters filled FPGA at 32 MHz. > This would be an acceptable value. Unfortunately it seems that's > impossible to test their designsoftware without a licence to see what > fits exactly in such a part. > > >If you really need to know how low the power is, > >you need to figure out just how large your design is. =A0I don't know > >your constraints working at the University, but in a commercial > >application, if we don't have good info on the FPGA design we want, it > >would be prototyped in an eval board before we would attempt to spec > >any hardware. =A0Is there a reason that you need to spec your hardware > >before you know what it will be hosting? > > Yes, the plattform with the FPGA is powered optically and we have a > given amount of power and want to figure out what we can do with that > power. So the goal is not to solve a given problem with minimum power > but to see what problems can be solved with a given power. > In the last time I heard many times about the Actel Igloo, maybe they > will find their way into our design. Has anyone experience with the > siliconblue parts? > > Thanks, > =A0Michael Hi Michael, if you need some estimate maybe I can try run some design for you with the SBT tools? I have them installed and working :) Antti and my Brain, Issue-1 http://groups.google.ee/group/antti-brain/filesArticle: 135085
Michael Dreschmann wrote: > On Sat, 13 Sep 2008 06:29:09 +1200, Jim Granville > <no.spam@designtools.maps.co.nz> wrote: > > >>If it is a research project, why does power matter so much ? >>What is powering this, for how long ? > > > It's powered optically, so power is the central point. > > >>>but if possible >>>also some further analysing of the videoframes and so on. >> >>but that is suddenly very open-ended :) > > > Exactly, we want to test what we can implement with out limited power > budget, perhaps 300mW all together. > > >>>The active current is important, if we don't need the FPGA it will be >>>completely disconnected from power. >> >>What makes that decison > >>If you have an external uC, then adjust that for lowest Static/idle >>power. > > > Yes, we'll have a MSP from TI to control the whole system and power > the FPGA if needed. > > >>Then the uA/MHz numbers will matter most, and if you can push down the >>MHz, you can start to lower Vcc. >>Some vendors have more info than others here. > > > You mean I can go down with the Corevoltage? This would be > interesting. Given the tight power budget, I would look at MSP + CPLD + FPGA and use the CPLD for running a 'non processing' system. Timebases etc, Starting a FPGA takes a while, and some energy. Besides the config time, some older ones had an inrush current at power on. Oscillator power will also be an issue. Xtal Osc > 40Mhz tend to be fairly power hungry. If you can tolerate less pecision, we have found LC Osc work well with CPLD Schmitt - fast start, and low power. You may be able to calibrate from a MSP430 32KHz Clk ? Small 'Zero power' CPLDs come from Atmel, Lattice and Xilinx. -jgArticle: 135086
I am interested to hear about experiences anyone may have had in switching to Altera hardware and tools. To be clear, the intent here isn't to start a "who's better" debate but rather to understand what to expect from those who did switch, regardless of the underlying issues. In our particular case we'd be switching from V2 and V5 devices to Arria and Stratix. In general terms the applications involve image processing. I've seen Altera's approach to image processing IP and tools and I have to say that I am impressed. In contrast Xilinx's image processing tools are more like a collection of app notes without a real underlying structure. The tools seem more user friendly...but I don't have real experience with them yet. I was surprised that Altera discourages low-level design. We've used low level instantiation and explicit control of interconnect paths quite effectively with Xilinx in order to squeeze performance out of modules that needed it. I suppose that there might be a point in trying to stay high level in that designs have improved reusability and, if chips are fast enough it really is better to avoid low-level work. Thanks, -MartinArticle: 135087
On 15 Sep, 16:51, m <martin.use...@gmail.com> wrote: > I am interested to hear about experiences anyone may have had in > switching to Altera hardware and tools. > > To be clear, the intent here isn't to start a "who's better" debate > but rather to understand what to expect from those who did switch, > regardless of the underlying issues. > > In our particular case we'd be switching from V2 and V5 devices to > Arria and Stratix. =A0In general terms the applications involve image > processing. =A0I've seen Altera's approach to image processing IP and > tools and I have to say that I am impressed. =A0In contrast Xilinx's > image processing tools are more like a collection of app notes without > a real underlying structure. =A0The tools seem more user friendly...but > I don't have real experience with them yet. =A0I was surprised that > Altera discourages low-level design. =A0We've used low level > instantiation and explicit control of interconnect paths quite > effectively with Xilinx in order to squeeze performance out of modules > that needed it. =A0I suppose that there might be a point in trying to > stay high level in that designs have improved reusability and, if > chips are fast enough it really is better to avoid low-level work. Certainly will help transitioning from X to A. JonArticle: 135088
On Sep 12, 11:18=A0am, dudesinmexico <dudesinmex...@gmail.com> wrote: > I am setting up a signal integrity simulation of a Virtex-4 DDR2 > memory interface with Agilent's ADS. > According to the readme file in the Virtex-4 IBIS distribution, on has > to add a "a 50-65 ohm transmission line with 10-200ps of delay" to > properly model package parasitics, so I have added a transmission line > between the driver output and the PCB load. The IBIS model, however, > already has a model for package parasitics (R_pkg, L_pkg, C_pkg) so I > am wondering how these will interact. From what I understand, this > transmission line models a trace in the "redistribution layer" inside > the BGA package, so ideally it should be embedded in the IBIS model > before R_pkg, L_pkg, C_pkg, not after, right? > > Austin, do you have any recommendations? > > Thanks I had similar questions for V5 and HyperLynx, so I opened a webcase. Here is the reply I received: -------------------------------- "However, I am not clear on what to do about the package parasitics, R_pkg, L_pkg, and C_pkg. AR#11754 says "there is a single set of RLC numbers in the Virtex IBIS file that applies to all package types. But virtex5.ibs actually contains a different set of numbers for each package, all commented out. The numbers that are uncommented are labeled "Null Package", and they are all essentially zero. The download also included a file ff676_5vlx50_ibis.pkg, with a whole bunch of RLC values in it." -Correct, there is a set of RLC values in the ibis file labeled as Null package. This is just a generic set of RLC values. If you are not using the pkg file, you will need to uncomment the lines of the RLC values for the package that you are using. If you have an IBIS simulator that uses the pkg file (such as IBIS writer), the pkg files contain RLC information for every specific pin and overrides that RLC information in the IBIS file. "Question is, should I un-comment the values in virtex5.ibs for my package (FF676)? If yes, then do I still need to include the short transmission line in LineSim, for the package signal trace? Do I need the other ".pkg" file for anything?" -It depends on if you are using the pkg files. If you are using the pkg, don't worry about uncommenting the lines. If you aren't using the pkg file, uncomment the lines under your specific package. The pkg and IBIS file should include everything you need to properly simulate your IOs. It depends on what simulator you are using, but the pkg file is a universal standard which most IBIS simulators will use. ------------------------------------------------------- So my understanding of this is that you either have the choice of using the IBIS file (as is) along with the pkg file, or if you forget about the pkg file, then modify the IBIS to use the R,L,C for your specific package and include the trans lines in your circuit. I chose the latter, as I had no luck getting HyperLynx to use the pkg file. BarryArticle: 135089
On Sep 15, 11:08=A0am, Jon Beniston <j...@beniston.com> wrote: > On 15 Sep, 16:51, m <martin.use...@gmail.com> wrote: > > > > > I am interested to hear about experiences anyone may have had in > > switching to Altera hardware and tools. > > > To be clear, the intent here isn't to start a "who's better" debate > > but rather to understand what to expect from those who did switch, > > regardless of the underlying issues. > > > In our particular case we'd be switching from V2 and V5 devices to > > Arria and Stratix. =A0In general terms the applications involve image > > processing. =A0I've seen Altera's approach to image processing IP and > > tools and I have to say that I am impressed. =A0In contrast Xilinx's > > image processing tools are more like a collection of app notes without > > a real underlying structure. =A0The tools seem more user friendly...but > > I don't have real experience with them yet. =A0I was surprised that > > Altera discourages low-level design. =A0We've used low level > > instantiation and explicit control of interconnect paths quite > > effectively with Xilinx in order to squeeze performance out of modules > > that needed it. =A0I suppose that there might be a point in trying to > > stay high level in that designs have improved reusability and, if > > chips are fast enough it really is better to avoid low-level work. > > Certainly will help transitioning from X to A. > > Jon Our development group did a wholesale platform change from V2 Pro X to Stratix II GX around 2-3 years ago, and it went very well. The change was mainly due to the fundamental issues that we were having with basic Xilinx IP blocks not working, as well as issues w/ the Rocket IO in the Virtex 2 Pro X devices. What also helped is amount of local support that we got from Altera (coupled w/ the lack of support from Xilinx). In fairness to our local FAE, he was very good, but the way priorities shake out amongst companies being supported locally, we weren't the highest on the totem pole. Anyways, we have not had a single errata or IP-based issue since the switch. Everything has pretty much worked as advertised, and we have been including plenty of the advanced DSP blockset modules in DSP Builder / Simulink. It has taken some time to "cut our teeth" on the DSP tools, but we haven't come across anything that we couldn't figure out ourselves. We mainly use FIR filters and NCOs, so not much of the image processing that you were asking about. With respect to your comment about low-level design, the DSP builder tool really encourages coming up with a high-level DSP design, which is then instantiated in your project w/ a single component (typically using a .tcl script). What I have found is that, in DSP Builder versions < 8.0, I needed to do some manual massaging of the models in order to hit timing (the Matlab simulations would work great, but then fail timing miserably in place/route). From what I understand, the 8.0 version of DSP Builder is a lot better than the previous releases (takes care of timing, optimizing using multi-cycle, etc), but we haven't upgraded, since we're in the middle of a project right now. I definitely am looking forward to checking out the new features, though. One issue that I've been curious about is why these forums seem to be dominated by issues people are having with Xilinx parts. From what I understand, the market share is something like 60/30 between (Xilinx and Altera, respectively), with the other guys cleaning up the rest. I'm wondering why I don't see that sort of general trend in the posts on here. Is it because people are going down other channels for Altera support? Are there just more issues w/ Xilinx? Who knows. Anyways, I just thought I would toss my $.02 worth. JeffArticle: 135090
On Sep 12, 7:32=A0pm, Brian Davis <brimda...@aol.com> wrote: > dudesinmexico wrote: > > > According to the readme file in the Virtex-4 IBIS distribution, on has > > to add a "a 50-65 ohm transmission line with 10-200ps of delay" to > > properly model package parasitics, so I have added a transmission line > > between the driver output and the PCB load. > > =A0What version/date are the IBIS files you're looking at? > The Virtex4 IBIS file is marked as IBIS version 3.2. This is the most recent IBIS file for V4 available for download from wwww.xilinx.com.Article: 135091
On Sep 15, 9:44=A0am, Barry <barry...@gmail.com> wrote: > On Sep 12, 11:18=A0am, dudesinmexico <dudesinmex...@gmail.com> wrote: > > > I am setting up a signal integrity simulation of a Virtex-4 DDR2 > > memory interface with Agilent's ADS. > > According to the readme file in the Virtex-4 IBIS distribution, on has > > to add a "a 50-65 ohm transmission line with 10-200ps of delay" to > > properly model package parasitics, so I have added a transmission line > > between the driver output and the PCB load. The IBIS model, however, > > already has a model for package parasitics (R_pkg, L_pkg, C_pkg) so I > > am wondering how these will interact. From what I understand, this > > transmission line models a trace in the "redistribution layer" inside > > the BGA package, so ideally it should be embedded in the IBIS model > > before R_pkg, L_pkg, C_pkg, not after, right? > > > Austin, do you have any recommendations? > > > Thanks > > I had similar questions for V5 and HyperLynx, so I opened a webcase. > Here is the reply I received: > > -------------------------------- > "However, I am not clear on what to do about the package parasitics, > R_pkg, L_pkg, and C_pkg. =A0AR#11754 says "there is a single set of RLC > numbers in the Virtex IBIS file that applies to all package types. > But virtex5.ibs actually contains a different set of numbers for each > package, all commented out. =A0The numbers that are uncommented are > labeled "Null Package", and they are all essentially zero. =A0The > download also included a file ff676_5vlx50_ibis.pkg, with a whole > bunch of RLC values in it." > > -Correct, there is a set of RLC values in the ibis file labeled as > Null package. =A0This is just a generic set of RLC values. =A0If you are > not using the pkg file, you will need to uncomment the lines of the > RLC values for the package that you are using. =A0If you have an IBIS > simulator that uses the pkg file (such as IBIS writer), the pkg files > contain RLC information for every specific pin and overrides that RLC > information in the IBIS file. > > "Question is, should I un-comment the values in virtex5.ibs for my > package (FF676)? =A0If yes, then do I still need to include the short > transmission line in LineSim, for the package signal trace? =A0Do I need > the other ".pkg" file for anything?" > > -It depends on if you are using the pkg files. =A0If you are using the > pkg, don't worry about uncommenting the lines. =A0If you aren't using > the pkg file, uncomment the lines under your specific package. =A0The > pkg and IBIS file should include everything you need to properly > simulate your IOs. =A0It depends on what simulator you are using, but > the pkg file is a universal standard which most IBIS simulators will > use. > ------------------------------------------------------- > > So my understanding of this is that you either have the choice of > using the IBIS file (as is) along with the pkg file, or if you forget > about the pkg file, then modify the IBIS to use the R,L,C for your > specific package and include the trans lines in your circuit. =A0I chose > the latter, as I had no luck getting HyperLynx to use the pkg file. > > Barry Brian and Barry, thanks for sharing your experience. It is still not clear whether one has to add the transmission line model. The readme.txt file in the V4 IBIS distribution says to do so, while at page 73 of UG112, Note 1. of Tb. 4-3 reads: "The I/O data reflects the full FC interconnect chain-bump, the vias, and external balls as depicted in Fig. 4-3." This is all very confusing...Article: 135092
On Sep 15, 1:47 pm, jeffjcan...@gmail.com wrote: > One issue that I've been curious about is why these forums seem to be > dominated by issues people are having with Xilinx parts. From what I > understand, the market share is something like 60/30 between (Xilinx > and Altera, respectively), with the other guys cleaning up the rest. > I'm wondering why I don't see that sort of general trend in the posts > on here. Is it because people are going down other channels for > Altera support? Are there just more issues w/ Xilinx? Who knows. I think this might be as simple as Xilinx having more low-cost eval boards on the market, so that hobbyist, student, and professional development type projects are more likely to end up in their silicon, and more likely to end up asking basic questions about it here. Wheras in more professional usage problems that can't be solved in house might be more likely to end up with the FAE's than on the newsgroups.Article: 135093
Rob Gaddi wrote: >> > > EP51 D-flop claims 320ps typ clock to out, 3GHz maximum toggle frequency. Which I suppose is fast enough for some people. You know, the ones doing pedestrian stuff. > Assuming 0 pS of routing for the Q to CLK pin that would give you a 320pS High and Low times for a total period of 640pS or 1.5625 GHz. EdArticle: 135094
On Sep 15, 12:44 pm, Barry <barry...@gmail.com> wrote:
>
> So my understanding of this is that you either have the choice of
> using the IBIS file (as is) along with the pkg file, or if you forget
> about the pkg file, then modify the IBIS to use the R,L,C for your
> specific package and include the trans lines in your circuit.
>
But Xilinx's response to your question makes no mention of including
those Tlines in the simulation model:
> -It depends on if you are using the pkg files. If you are using the
> pkg, don't worry about uncommenting the lines. If you aren't using
> the pkg file, uncomment the lines under your specific package. The
> pkg and IBIS file should include everything you need to properly
> simulate your IOs. It depends on what simulator you are using, but
> the pkg file is a universal standard which most IBIS simulators will
> use.
My understanding of this is as follows:
- if you use the IBIS header values by uncommenting the header
for a specific package, you get a generic uncoupled lumped model
with min/typ/max values representative of that package type
- if you use the .pkg file, you get a coupled lumped model that
models each pin of the package distinctly
In neither case should you use the Tlines with these newer IBIS
files,
as that delay is now included in the lumped package model.
( I haven't any first hand experience with Hyperlynx in over five
years,
so take the above advice with an appropriately sized lump of salt. )
I'm working on a more detailed reply to "dudesinmexico" with some
notes about the IBIS modeling changes, but I don't know if I'll have
time to post it tonight.
Brian
Article: 135095dudesinmex...@yahoo.com wrote: > > It is still not clear whether one has to add the > transmission line model. > > The readme.txt file in the V4 IBIS distribution says to do so, > while at page 73 of UG112, Note 1. of Tb. 4-3 reads: "The I/O > data reflects the full FC interconnect chain-bump, the vias, > and external balls as depicted in Fig. 4-3." > I'd go with UG112 on this one. I believe the statement in the V4 readme file is just a case of "copy the old readme" from the earlier releases of the V4 IBIS models, as the V5 models, using the exact same type of lumped model, do NOT have that note about needing to add the Tlines. Nor would it be unusual for an Answer Record (11754) to be out of date. ---------------------- I'd also take a look at this video ( which I haven't actually watched yet ): http://signal-integrity-tips.com/2008/workflow-with-ibis-models/ Squinting at the initial screen dumps, it doesn't look like they added the extra Tline ( the next blob over from the Xilinx IBIS buffer looks like a via model ). I'd ask your ADS FAE if there's a copy of the associated ADS files for that ADS Xilinx/Micron IBIS simulation, and see which version of the Xilinx IBIS files the ADS modeling used, and whether the ADS gurus used the extra Tline. > > The Virtex4 IBIS file is marked as IBIS version 3.2. > Note, the revision of importance here is not the IBIS file format version, but the one labeled [File Rev], which AFAIK is currently 2.5.1 for Virtex4. Comparing the older IBIS files to this newer version: - In the earlier (2.2) IBIS files, using the Tline, there is one and only one set of package parasitics, with teeny values for L_pkg and C_pkg. ( less than one nH and one pF each ). - In the newer (2.5.1) IBIS files, no Tline required, there is a heftier value, for each type of package, of a few or more nHs and pFs each. Which I believe supports my interpretation that the delay formerly modeled by the Tline now shows up in the lumped LCR package model, as also explained in UG112. BrianArticle: 135096
Hello,
Could any body tell me if i can use a OPB ethernet device in polled
mode for sending and in interrupt mode for receiving packets from the
network. I am unable to do that.
Why i am asking this? :
When i use the ethernet ports in interrupt mode ( i have two of
them), due to the priority i set in the interrupt controller, one of
the ports always has a higher priority. Because of this the FPGA if it
wants to send data using the busy port, it is not able to do so, since
the port is held by the interrupt controller.
An early reply would be really appreciated.
Best regards,
G Aswin
Article: 135097On 12 Wrz, 14:37, michael...@gmx.de (Michael Dreschmann) wrote: > Hi all! > > For an actual project I'm looking for an ultra low power FPGA. The > size is not so important, we probably don't need much more resources > that an CPLD would provide but power is absolutely critical. > I heard already about Siliconblue but does someone of you know of any > other devices playing in the same league to get some overview? > Siliconblue seams to be very new on the market and this means a > certain risk. Some nonvolatile config memory also would be preferable. > > Thanks, > =A0Michael maybe QuickLogic?Article: 135098
>Structural simulation of FFT core reveal the frequency to bin (XK_IDX) >mapping are bit reversed when the FFT core is configured to output in >streaming, natural order. Real time swapping of the frequency needs >FIFO of 2^N deep. Can anyone help me to implement a more optimized >freq swap method. > FFTs are - as a result of the nature of the Cooley-Tukey algorithm - either natural-in+reversed-out or reversed-in+natural-out. To design an architecture that does natural-in+natural-out without a buffer memory is distinctly non-trivial. Try asking on a DSP newsgroup...Article: 135099
Hi fellow forumers, We currently have lots of designs implemented with different versions of ISE. Often when a bug needs to be fixed on an old design the engineer will check out the code and find that it was last compiled with an older version of ISE. The user will therefore usually migrate to the latest version they have installed on their computer. In the past some designs have simply not built because of things like syntax changes with UCF files, but I am also worried about more subtle problems that might arise from using the newer ISE version. Also, when compiling large designs, a user's computer is utilised quite heavily (especially memory) limiting what can be done on that PC until the build finishes. For these reasons I was thinking of having an "ISE build PC" which has all of the versions of ISE we use installed on it. Then, using build scripts (tcl??), the build process can be automated and the process will be 100% repeatable and can be performed on an expensive behemoth PC rather than the user's work station. The thing is, I'm not sure how to implement such a thing, or indeed whether it is a sensible plan. I've had a look through the Xilinx Tcl stuff and there doesn't seem to be a way of getting a version for the tools that are being invoked. Has anyone implemented anything like this? Is it sensible?? Cheers Rob
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