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
Been wondering the same thing. There has been an unusually light amount of
traffic over the past few months on comp.dsp. Used to be if I didn't check it
for a day or two, there would be several humdred unread posts. Maybe it is the
economy or something. At the same time the FPGA traffic has gone way up, some
of it is attributable to the beginning of the school year, but not enough to
make a big difference. I think FPGAs have certainly become more commonly used,
and DSP using FPGAs is finally becoming accepted. There are considerably more
DSP type posts to .fpga which reflects people trying it out and finding that it
isn't always that easy to do.
Steve Casselman wrote:
> I've been keeping track of just the raw number of posts to both
> comp.arch.fpga and comp.dsp and in the last 2 months arch.comp.fpga has had
> more posts per day. I'm wondering if fpgas are going more mainstream or dsps
> are just so well known that people don't ask as many questions...
>
> Any thoughts???
>
> Steve
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48526Kevin, thanks for your comments. I would be interested in your reaction to my responses below. > > While I have never designed a printed circuit board, PCI specification > seems to imply that you need to use at least a 4 layer PCB. Agreed, there were a lot of variables and I wanted to keep costs down. I was prepared to scale the PC system speed down to a frequency that could be used to debug and figure all the other requirements before spinning another board. Currently I am running at 25MHz. > Also, looking at the picture of the PCI card you designed, your PCI > card doesn't seem to have any high-speed ceramic capacitors near the > edge connector in which the specification says you need to have. High-speed .1uF caps are on the bottom of the card, under the FPGA. (My hand soldering skills are not that great, so I do not advertise that more than I have to) As you say, PCI spec requires a certain number of caps near the edge connector. (I once looked for cards that followed that spec and quickly found 3 that did not have small caps near the card edge, so it seems a lightly followed spec) > Another thing I will say from my experience of developing a > PCI IP core is that perhaps the use of an Altera device is not > terribly a good idea for PCI. I seem to hear that a lot, :-) I started this well before Insight released their Xilinx PCI product. One thought was that there may be demand albeit small for a non-Xilinx card. > Looking at your PCI card, you are using a FLEX10K30E-3 which is the > slowest FLEX10KE available. > Not only that particular part of FLEX10KE is not guaranteed to meet > PCI's V/I curve (You need a speed grade -1 FLEX10KE part to meet 5V > PCI's V/I curve according to FLEX10KE datasheet.), but also I will bet > you that with FLEX10K30E-3, your PCI interface probably won't meet the > setup time requirement of Tsu < 7ns that easily unless you heavily > floorplan it because FLEX10K30E-3's 4-input LUT's delay (tLUT) is > already at 1.1ns, and some unregistered signals usually have to pass > through 3 to 4 levels of 4-input LUT before reaching a FF. (Also, you > have to add the interconnect delay between LUTs which is very > unpredictable in Altera FLEX because the fitter is so flaky, input pin > delay, and FF setup time.) Agreed, I am certainly not rigorously following PCI spec. Although I am certainly hoping to evolve into some sort of small business, if there is no market for this, it will be an interesting hobby. > The problem I had with Altera floorplanner is that even if I place a > certain LUT to a certain LAB, often the fitter will duplicate the LUT > for some reason, and when the LUT is duplicated, the placement > information gets ignored. (i.e., ix7342 gets duplicated as ix7342~1 by > the fitter. The fitter will ignore ix7342's placement information when > placing ix7342~1.) > That problem pretty much makes the Altera floorplanner useless. > Besides the Altera floorplanner problem, Altera's fitter does a pretty > poor job of meeting setup time timings, and usually meeting the setup > time is the hardest part of developing a PCI IP core. (To Altera's > credit, Altera fitter does a good job of maximizing fmax, but since > meeting fmax of 33.3MHz isn't too hard with most recent FPGAs, that's > not a big deal.) I'm currently taking defaults in Quartus II V2.1 allowing for the config cycle access and would like to get memory accesses working before opening the fitter can of worms. (Maybe by then Altera will have better parts as you point out) > Personally, I have used Xilinx Spartan-II to test my PCI IP > core, and unlike when I ported my PCI IP core to Altera > FLEX10K100EFC484-1 (tLUT = 0.7ns), Xilinx's software (ISE WebPACK) met > Tsu < 7ns without having to use the floorplanner. > Meeting Tval < 11ns and Thold <= 0ns requirement of PCI was also much > easier with Spartan-II than FLEX10KE because unlike FLEX10KE IOE which > has only one FF, Spartan-II IOB has three FFs for input, output, and > tri-state control. > If you still want to stick with Altera which I don't recommend, you > may want to consider using ACEX 1K instead which is much cheaper than > FLEX10KE, but essentially has the same features FLEX10KE has. I started this just when ACEX was coming on market (I think they were expensive), so will probably spin the board for that (or maybe Cyclone) (If I go to Xilinx, I think I would be competing too much with Insight...?) > I hate to be a nay-sayer, but since Insight Electronics sells > a well constructed Spartan-II XC2S200-based PCI prototype card with > 8MB of SDRAM for $250, I am not sure how many people will buying your > 2 layer PCB-based PCI card with FLEX10K30E-3 without external SDRAM > even if you give out the a PCI IP core for free. With Insight Electronics, don't you have to buy or license the PCI core? Some people may not want to do this and just have a manner to get high bandwith IO to/from the CPU with GPIOs that can be easily configured. (at least that is an idea...) > My suggestion will be that you may want to use 4 layer PCB, use a > larger ACEX1K (Consider using ACEX1K EP1K100-1 if you want to stick > with Altera.), have an SDRAM SO-DIMM slot, and have an expansion > connector just like what Insight Electronics Spartan-II PCI card has. Good points, but before I invest a lot of time and money, I am really curious if there is a viable marketplace out there for this sort of thing. Thanks again Kevin, -SteenArticle: 48527
Ken,
We do appreciate your presence here even though at times we might not show it. I
think most of us who hang here and use the tools have felt the difference. You
provide a response that is much better than that provided by tech support.
Perhaps you should have your hotline people lurk once in a while too ;-)
Ken McElvain wrote:
> Actually, one of there reasons I follow this new group is to
> find out about those annoying problems that people suffer with
> but are too small to bother logging through formal channels.
> The VDD/GND issue was a perfect example, I'm pretty sure you
> or someone else posted it here and that's why it got fixed.
>
> - Ken
>
> Jan Gray wrote:
>
> > "Ken McElvain" <ken@synplicity.com> wrote
> >
> >>I belive that the feature you want has just gone out in the 7.2 Beta.
> >>Why don't you download it and look up what we call a "locked"
> >>compile point.
> >>
> >
> > Thank you, I will, as time permits. And thanks for addressing the VCC/GND
> > problem.
> >
> > I would like to clarify that I have no complaints with respect to Synplicity
> > support -- the two issues/suggestions in my earlier post in this thread were
> > both communicated to Synplicity through unconventional channels (such as
> > their newsgroup) and so were not formally tracked as support issues.
> >
> > I appreciate your contributions to this group. Thanks. Thanks also to
> > Peter and Austin and the other vendor 'ambassadors' who make this newsgroup
> > so useful.
> >
> > -----
> > Product development is sometimes a thankless job. When it works as
> > designed, everyone takes it for granted. When it's broken, even "a little",
> > (or even when it's "user error"), everybody is unhappy. When you change
> > something for a good reason, those that benefit don't realize their good
> > fortune, and those that don't benefit, complain.
> >
> > Either you get support calls, or more happily, the phone doesn't ring at
> > all. But rare indeed is the spontaneous customer compliment "Wow, your
> > product worked great for my application, and I have no complaints. Great
> > work."
> >
> > (Of course I don't consider turning a 2 hr run into a 25 hour run a good
> > thing. Clearly some device-sized RPMs (quite easy to create) belong in the
> > PAR test suite, and the PAR test suite apparently needs some performance
> > regression tests.)
> >
> > (Which reminds me: "There is nothing more difficult to take in hand, more
> > perilous to conduct, or more uncertain in its success, than to take the lead
> > in the introduction of a new order of things. Because the innovator has for
> > enemies all those who have done well under the old conditions, and lukewarm
> > defenders in those who may do well under the new." -- Machiavelli)
> >
> > -----
> > OK, everybody, Monday is Appreciation Day. Post a success story. Take your
> > FAE to lunch, etc. Go forth and share some good will.
> >
> > Jan Gray, Gray Research LLC
> >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 48528"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:aohlte$mjpf3$2@ID-84877.news.dfncis.de... > "Austin Franklin" <austin@da98rkroom.com> schrieb im Newsbeitrag > news:uqojb9qj4l5j21@corp.supernews.com... > > > > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > > news:ao9q80$rqb$1@agate.berkeley.edu... > > > In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> > > wrote: > > > >CPLDs are typically not SRAM based and maintain their programming on > > > >startup. > > I think this is not quite correct. If you take a closer look to the Xilinx > CPLDs datasheets, it says something about . . .configuration is finished > within 200us . . . > So it looks like that CPLD (from Xilinx) are SRAM based CPLDs + Flash on one > chip. Falk, The CPLDs don't require external memory... No CPLDs that I know of do. AustinArticle: 48529
Austin Franklin wrote: > > "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message > news:aohlte$mjpf3$2@ID-84877.news.dfncis.de... > > "Austin Franklin" <austin@da98rkroom.com> schrieb im Newsbeitrag > > news:uqojb9qj4l5j21@corp.supernews.com... > > > > > > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > > > news:ao9q80$rqb$1@agate.berkeley.edu... > > > > In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> > > > wrote: > > > > >CPLDs are typically not SRAM based and maintain their programming on > > > > >startup. > > > > I think this is not quite correct. If you take a closer look to the Xilinx > > CPLDs datasheets, it says something about . . .configuration is finished > > within 200us . . . > > So it looks like that CPLD (from Xilinx) are SRAM based CPLDs + Flash on > one > > chip. > > Falk, > > The CPLDs don't require external memory... No CPLDs that I know of do. I don't think he meant off-chip loader silicon. The Coolrunners, and newest Lattice devices with similar mA/Mhz curves, all specify a config time of 'some us' (i.e. short, but not zero ) - suggesting a ReadNV - >store.ConfigLatches scheme. I have not dug deep enough into the ProASIC (Flash FPGA) data, but it's likely the same. -jgArticle: 48530
FPGA and DSP complement each other nicely. The fact that processor cores may be available for FPGAs die not mean a DSP can be replaced by an FPGA. There are a lot users that use simpler controllers together with FPGAs, hence more messages in th FPGA group Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net Steve Casselman wrote: > I've been keeping track of just the raw number of posts to both > comp.arch.fpga and comp.dsp and in the last 2 months arch.comp.fpga has had > more posts per day. I'm wondering if fpgas are going more mainstream or dsps > are just so well known that people don't ask as many questions... > > Any thoughts???Article: 48531
Helmut Sennewald <HelmutSennewald@t-online.de> wrote: : "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> schrieb im : Newsbeitrag news:aopg16$mo5$2@news.tu-darmstadt.de... :> Thomas Buerner <buerner@lrs.e-technik.uni-erlangen.de> wrote: :> :> : Does anybode know, where I can download the 4.2 version of Webpack ? :> :> Why do you want 4.2 when there is 5.1? : Hello Uwe, : the version 5.1 runs only on WIN-2000/XP but 4.x runs on WIN98 too. We had no luck running 4.2 running on Win98. Running webpack.exe and impact.exe soon resulted in a Exception error popping up an error box. Now I run 5.1 webpack/ise.exe with quite good success on Linux with wine( cvs needed, as same recent patches are needed). Wine has to run with ~/.wine/config [Version]"Windows" = "nt40". ECS is painfully slow, but otherwise usable. StateCad has display problems. Only impact has no chance of running, as the windrvr.sys file is needed. However as there is also Windriver for Linux, a translation layer may be thinkable. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 48532
Nicholas C. Weaver <nweaver@ribbit.cs.berkeley.edu> wrote: > Personally, I think RMS could use a good twisting. I much prefer BSD > style liscences, as they have more real freedom. But thats a > religious issues, and I will say no more. The BSD license gives you the freedom to take the freedom away from others. The GPL denies you this freedom to keep the software free for everyone. Decide for yourself which is better .. for selfish reasons the BSD license seems better but may not be overall. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 48533
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> schrieb im Newsbeitrag news:aorifc$5ah$1@news.tu-darmstadt.de... > Helmut Sennewald <HelmutSennewald@t-online.de> wrote: > > : "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> schrieb im > : Newsbeitrag news:aopg16$mo5$2@news.tu-darmstadt.de... > :> Thomas Buerner <buerner@lrs.e-technik.uni-erlangen.de> wrote: > :> > :> : Does anybode know, where I can download the 4.2 version of Webpack ? > :> > :> Why do you want 4.2 when there is 5.1? > > : Hello Uwe, > : the version 5.1 runs only on WIN-2000/XP but 4.x runs on WIN98 too. > > We had no luck running 4.2 running on Win98. Running webpack.exe and > impact.exe soon resulted in a Exception error popping up an error box. > Hello Uwe, I have Webpack 4.2WP2.x running on Win98SE and use it for VHDL education myself. Maybe it is important to have WIN98SE and not WIN98. Best Regards HelmutArticle: 48534
"Jim Granville" <jim.granville@designtools.co.nz> wrote in message news:3DB0DC4C.4131@designtools.co.nz... > Austin Franklin wrote: > > > > "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message > > news:aohlte$mjpf3$2@ID-84877.news.dfncis.de... > > > "Austin Franklin" <austin@da98rkroom.com> schrieb im Newsbeitrag > > > news:uqojb9qj4l5j21@corp.supernews.com... > > > > > > > > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > > > > news:ao9q80$rqb$1@agate.berkeley.edu... > > > > > In article <3DA867BB.40301@mail.com>, John_H <johnhandwork@mail.com> > > > > wrote: > > > > > >CPLDs are typically not SRAM based and maintain their programming on > > > > > >startup. > > > > > > I think this is not quite correct. If you take a closer look to the Xilinx > > > CPLDs datasheets, it says something about . . .configuration is finished > > > within 200us . . . > > > So it looks like that CPLD (from Xilinx) are SRAM based CPLDs + Flash on > > one > > > chip. > > > > Falk, > > > > The CPLDs don't require external memory... No CPLDs that I know of do. > > I don't think he meant off-chip loader silicon. > The Coolrunners, and newest Lattice devices with similar mA/Mhz curves, > all specify a config time of 'some us' (i.e. short, but not zero ) > - suggesting a ReadNV - >store.ConfigLatches scheme. > > I have not dug deep enough into the ProASIC (Flash FPGA) data, > but it's likely the same. > Hi Jim, I believe Falk believes that the Xilinx CPLDs require an external configuration memory, because it has a "configuration time"...and read the previous posts... AustinArticle: 48535
"Steve Casselman" <sc@vcc.com> writes: > > Unused bits are set to zero, which compress really well. ;-) > > This is not ture. If you go into the fpga editor and create a blank part you > will see lots of ones and zeros. neil@chonsp 16:09:11 ~> vd -er 0/0 null300.bit Col: 0, Row: 0 CLB: 0 1 2 3 4 frame 012345678901234567890123456789012345678901234567 addr .------------------------------------------------ 0|110111110001100011111011110111110001100011111011 1|100001000101011010000001100000010110111000100001 2|111111111111111110000000000000011111111111111111 3|111111111111111100100000000001001111111111111111 4|000000000100001000000000000000000010100000000000 5|000000000000000000000000000000000000000000000000 6|000000000000000000000000000000000000000000000000 7|000000000000000000000000000000000000000000000000 8|000000000000000000000000000000000000000000000000 9|000000000000000000000000000000000000000000000000 10|000000000000000000000000000000000000000000000000 11|000000000000000000000000000000000000000000000000 12|000000000000000000000000000000000000000000000000 13|000000000000000000000000000000000000000000000000 14|111111111111111111111111111111111111111111111111 15|100011100011100011100011100011100011100011100011 16|111111111111111111111111111111111111111111111111 17|111111111111111111111111111111111111111111111111 bit addr > What is ture is that the if a lot of the > chip is not used there is a repeating pattern that is the same for each > unused tile and so a low utillization design gives better compression > results. For example if you just have one input and one output and one wire > inbetween in a V1000 it compress about 100x.. Empty XCV300: -r--r--r-- 1 neil franklin 219047 Sep 27 2001 null300.bit -r--r--r-- 1 neil franklin 3794 Sep 27 2001 null300.bit.gz About 1/4 full XCV300: -rw-r--r-- 1 neil franklin 219047 Oct 16 00:34 pdp10.bit -rw-r--r-- 1 neil franklin 21241 Oct 16 00:34 pdp10.bit.gz -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48536
Hello,
currently I'm doing a signal processing project with altera devices.
I have to do a mean-value calculation on a set of samples.
To do the mean calculation, I need an 24bit divider, so I used the
lpm_divide megafunction in an unsigned and non-pipelined mode.
My problem is: How can I find out, when the divider has ended its
division ?
My current solution is to wait a fixed time of 500ns.
Thanks
Alex
Article: 48537Thanks! Actually there are several of the hotline folks that read the newsgroup, but we limit the number of posters. We have to because we get lots of advanced information and we have to be very sure that we don't announce someone else's new feature for them ;-) BTW, your most recent annoying problem, the unisim library support issue has also been fixed in the 7.2 Beta. The fix is for Virtex and later families. The essence of this problem was that you could either have your VHDL compatible with simulation and have instantiated components treated as black boxes with no timing model, or you could be compatible with Synplify, get timing models for the instantiated components and hence better results. With this fix, you can do both. Ken CTO, Synplicity Inc. Ray Andraka wrote: > Ken, > > We do appreciate your presence here even though at times we might not show it. I > think most of us who hang here and use the tools have felt the difference. You > provide a response that is much better than that provided by tech support. > Perhaps you should have your hotline people lurk once in a while too ;-) > > Ken McElvain wrote: > > >>Actually, one of there reasons I follow this new group is to >>find out about those annoying problems that people suffer with >>but are too small to bother logging through formal channels. >>The VDD/GND issue was a perfect example, I'm pretty sure you >>or someone else posted it here and that's why it got fixed. >> >>- Ken >> >>Jan Gray wrote: >> >> >>>"Ken McElvain" <ken@synplicity.com> wrote >>> >>> >>>>I belive that the feature you want has just gone out in the 7.2 Beta. >>>>Why don't you download it and look up what we call a "locked" >>>>compile point. >>>> >>>> >>>Thank you, I will, as time permits. And thanks for addressing the VCC/GND >>>problem. >>> >>>I would like to clarify that I have no complaints with respect to Synplicity >>>support -- the two issues/suggestions in my earlier post in this thread were >>>both communicated to Synplicity through unconventional channels (such as >>>their newsgroup) and so were not formally tracked as support issues. >>> >>>I appreciate your contributions to this group. Thanks. Thanks also to >>>Peter and Austin and the other vendor 'ambassadors' who make this newsgroup >>>so useful. >>> >>>----- >>>Product development is sometimes a thankless job. When it works as >>>designed, everyone takes it for granted. When it's broken, even "a little", >>>(or even when it's "user error"), everybody is unhappy. When you change >>>something for a good reason, those that benefit don't realize their good >>>fortune, and those that don't benefit, complain. >>> >>>Either you get support calls, or more happily, the phone doesn't ring at >>>all. But rare indeed is the spontaneous customer compliment "Wow, your >>>product worked great for my application, and I have no complaints. Great >>>work." >>> >>>(Of course I don't consider turning a 2 hr run into a 25 hour run a good >>>thing. Clearly some device-sized RPMs (quite easy to create) belong in the >>>PAR test suite, and the PAR test suite apparently needs some performance >>>regression tests.) >>> >>>(Which reminds me: "There is nothing more difficult to take in hand, more >>>perilous to conduct, or more uncertain in its success, than to take the lead >>>in the introduction of a new order of things. Because the innovator has for >>>enemies all those who have done well under the old conditions, and lukewarm >>>defenders in those who may do well under the new." -- Machiavelli) >>> >>>----- >>>OK, everybody, Monday is Appreciation Day. Post a success story. Take your >>>FAE to lunch, etc. Go forth and share some good will. >>> >>>Jan Gray, Gray Research LLC >>> >>> >>> >>> > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > > >Article: 48538
> Hi Jim, > > I believe Falk believes that the Xilinx CPLDs require an external I believe in love . . . ;-) Serious, I wanted to say that the Xilinx CPLDs are SRAM based (I assume) and have an INTERNAL FLASH/EEPROM which automatically configures the CPLD upon power-up. See also ds017.pdf, page 3, Tconfig 60us max., Coolrunner ds090.pdf, page 11, power-up characteristics, power-up <25ms, Coolrunner-II I dont know if both families (Coolrunner and -II) are SRAM based, but for -II the datasheet definitely says that. -- MfG FalkArticle: 48539
"Alex Kühn" <akuehn@monet.fh-friedberg.de> schrieb im Newsbeitrag news:f84ba0f3.0210190736.1ede04a5@posting.google.com... > Hello, > > currently I'm doing a signal processing project with altera devices. > I have to do a mean-value calculation on a set of samples. > To do the mean calculation, I need an 24bit divider, so I used the > lpm_divide megafunction in an unsigned and non-pipelined mode. > My problem is: How can I find out, when the divider has ended its > division ? Hmm, dont know. But you should think about the mean value. Do you need and arbitrary number of samples for which you calculate the mean value? If it is a power of two, the division would be much easier and faster. . . -- MfG FalkArticle: 48540
On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain <ken@synplicity.com> wrote: >Thanks! Actually there are several of the hotline folks that read the >newsgroup, but we limit the number of posters. Ah, good. I'd like to know what you are doing about the SRL16 inference rule change between 7.0 and 7.1. We have a number of designs here that break in 7.1 and 7.2 because Synplify Pro is inappropriately changing FF into SRL16E. Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted to SRL16E. SRL16E don't work at 350MHz (in Virtex2). Problem 2 (still outstanding) Some FF with async reset get converted to SRL16E. SRL16E don't have an async reset input, so this is a functional change. (It's that old problem of Synplify trying to be too clever about the meaning of GSR when the startup block is present. If an FPGA has an external reset input (connected to the startup block) then it is *not* correct to assume that GSR is only active during configuration.) Problem 3 (still outstanding) Some FF that were in IOBs get converted to SRL16E. This breaks the I/O timing on the part. Problem 3 is actually the worst one for us, since most of the designs infer I/O FF. I rather liked the 6.x rule that only allowed an RTL FF to be converted to SRL16E when the FF was coded without an async reset or set. Regards, Allan.Article: 48541
"Will" <wv9557@yahoo.com> schrieb im Newsbeitrag news:4a885870.0210190910.e66333c@posting.google.com... > My experience with large XILINX distributors is not very good. It seems > like they are not really interested in selling inexpensive evaluation kits. Hmm, I guess the large Xilinx distibutors are focused on the big business. But there are enough 3rd partys, wich also welcome small hobbyists. I ordered some stuff from nuhorizons, no probs. Burched I dont know, but I guess his main focus is very much the hobbyists, isnt it? ;-) -- MfG FalkArticle: 48542
I have made a program on Delphi, but there is a problem: the logic 1 signal at TDO is too weak about1.6 volts and LPT can't read it! I use third-party JPOD. Meanwhile, iMPACT can force the POD to set proper 5V level at TDO and I program Xilinx CPLDs using the same cable.Article: 48543
> Any suggestions how to make this crappy PS/2 decoder state machine better > appreciated. > It looks like synchronizers might be required for the keyboard clock and data to avoid meta-stability issues. It's difficult to simplify the interface due to the idiosyncrasies of the PS2 interface; but if only a read interface is required it can be made fairly simple. Some of the work could be moved over to software. Is there really a need to manage the keyboard buffer in hardware ? Also serialization could be done with software due to the slow interface speed. All that would be needed is a two bit registered port in that case, although it's not my favorite approach. There is a PS2 compatible keyboard / mouse interface available at www.birdcomputer.ca Provided it's for personal use or evaluation, there is no fee. Send me an email if you're interested. Rob rob@birdcomputer.caArticle: 48544
Hello, my task is to decode elements in a circuit. I know how to build flat decoder from and2 elements but find it difficult to draw parts of the decoder into sub-circuits to minimize number of wires entering the sub-module. For example: there is 10000 elemnts to decode 500 of which are in sub-module, so I could provide the module only with 9 lower address lines that could be decoded there. The second approach that I see is to use selector (address window) for sub-circuit and decode lower adderss lines of the window in the module. The first one seems more effective but complex to implement. Which one to choose? I wonder if nobody dealt with the problem.Article: 48545
Recently i got the insight spartan II demo board and xilinx webpack, but i can't get the board to work. Xilinx iMPACT doesn't recognize it. The board is connected with the computer through jtag cable. I tried all sorts of combinations with the jumpers on the board, but no matter what i do it just doesn't work. I'm a beginner with fpga and i'm getting very frustrated with not finding the mistake, please help. regards KlemenArticle: 48546
Jan Gray wrote: > Nicholas wrote: > > MIPS: Machine without Interlocking Pipeline Stages. > > MIPS: "Microprocessor without Interlocked Pipeline Stages" > > Even the R4000 (which had a 2 cycle load-to-use delay, IIRC) made sure to > have a 0 cycle ALU-to-use delay, whereas a superpipelined 250 MHz V-II RISC > would necessarily a 1 cycle ALU-to-use delay. That is rather more > challenging for the code scheduler to address. > In fact it was the R2000/3000 [and its IDT 30xx derivatives] that relied strictly on compiler scheduling to handle the, then, 1 clock load-to-use delay. When the R4000 with its 8 stage pipeline came out the MIPS architects had decided that 2 clocks was too much (and I suppose they wanted to be able to run legacy MIPS-I code) and so they put in a load interlock. In fact they added something called a pipeline `slip' to handle this where part of the pipe stops & the rest keeps going, instead of a crude stall. This interlock was kept even when the non-multiprocessor R4000 variant was re-engineered as the 5-stage R4600 and then on to the R5000, RM52xx, RM70xx etc. I'll check up with our compiler person just how hard a 1 clock ALU-to-use delay would be for gcc's scheduler to handle.Article: 48547
Austin Lesea wrote: > Or, > > You can use a series 100 ohm resistor if you can tolerate the series > resistance. > > http://www.xilinx.com/products/virtex/techtopic/vtt002.pdf > > Austin > Is the max acceptable current limit through the clamp diode the same for V-II as for V-E ?Article: 48548
Paul wrote: > In article <aoheo3$2q0$1@news.storm.ca>, "jakab tanko" > <jtanko@ics-ltd.com> wrote: > > > Hello, > > > > Does anybody know how to (safely) drive Virtex2 > > inputs with 5V TTL levels? > > > > Thanks, > > > > jakab > > A solution I know that works, is to use QuickSwitches. > <snip> A couple of words of warning on this solution, which is the one we use as well: o You can power the original 5V `QuickSwitch' and its clones comfortably down to 3.3V but we generally use a 3.9V Zener. o Strictly speaking a QS part does not clamp the voltage but its impedance rises steeply once the driving side gets to about VCC-0.7V. If you look at the output side whose input is being driven by a static 5V signal (e.g. a pull-up) you'll see that it does in fact get to VCC but, of course, has no drive current available. o If you want to use 3V `QuickSwitches' be aware that they come in 2 flavours - "clamping" and non-"clamping".Article: 48549
Allan Herriman wrote: > On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain <ken@synplicity.com> > wrote: > > >Thanks! Actually there are several of the hotline folks that read the > >newsgroup, but we limit the number of posters. > > Ah, good. I'd like to know what you are doing about the SRL16 > inference rule change between 7.0 and 7.1. We have a number of > designs here that break in 7.1 and 7.2 because Synplify Pro is > inappropriately changing FF into SRL16E. > > Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted > to SRL16E. SRL16E don't work at 350MHz (in Virtex2). > > Problem 2 (still outstanding) Some FF with async reset get converted > to SRL16E. SRL16E don't have an async reset input, so this is a > functional change. > (It's that old problem of Synplify trying to be too clever about the > meaning of GSR when the startup block is present. If an FPGA has an > external reset input (connected to the startup block) then it is *not* > correct to assume that GSR is only active during configuration.) > > Problem 3 (still outstanding) Some FF that were in IOBs get converted > to SRL16E. This breaks the I/O timing on the part. > > Problem 3 is actually the worst one for us, since most of the designs > infer I/O FF. > Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer bug and mucho thanks for the warning as I was just about to make the move from 7.0.2 -> 7.2. > > I rather liked the 6.x rule that only allowed an RTL FF to be > converted to SRL16E when the FF was coded without an async reset or > set. > In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF with any sort of set/reset sync or async since the Xilinx primitive doesn't have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I think.
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