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
> Shameless plug ;-) Sounds like a good start though. Anyone in the UK give us a clue if this available here? RobinArticle: 32026
Tobias Stumber wrote:
> Use:
> attribute IOB: string;
> attribute IOB of ge_mem_oe_reg : signal is "true";
> This makes XST to replicate the FFs again after (!) having merged them into
> one in the final optimization phase.
> Works great !
>
> Tobias
Hi,
I tried to attach the IOb attribute but it did not work ! Even if I
instanciate FlipFlop components(FD) by hand, they are optimized away and
a single flop drives 16 tristate signals. I also tried the max_fanout
attribute:
attribute max_fanout : integer;
attribute max_fanout of ge_mem_tri_reg : signal is 1;
.. same result !
What is wrong ?
Matthias
--
-------------------------------------------------
\ Matthias Fuchs \
\ esd electronic system design Gmbh \
\ Vahrenwalder Straße 205 \
\ D-30165 Hannover \
\ email: matthias.fuchs@esd-electronics.com \
\ phone: +49-511-37298-0 \
\ fax: +49-511-37298-68 \
--------------------------------------------------
Article: 32027Hi all; I am working on the initial floor plan of a design using the Xilinx PCI core. Using their constraints generator, I have requested that the PCI pins be on the slot side of the device. This causes them to be spread evenly across the end of I/O bank 2 and beginning of bank 3. I would like to shift the core and its I/O such that it resides within a single quadrant of a device. I've been experimenting with their UCF generator, but am having a problem. In the device I'm using, the IRDY and TRDY pins are the first two pins in the 3rd bank. In the UCF generator, I have re-ordered the signals such that the RDY lines are first, with all others following them. This has nearly the desired effect. All of the pins are now in the third bank. However, the internal location constraints do not make sense to me. While most are shifted downwards in the Y plane, the address/data TBUFs are shifted up. In other words, while the pins and everything else move down into the South-East quadrant, the AD TBUFs have moved further into the North-East quadrant. Does anyone know why this is? Is it a bug in their UCF generator, or due to some peculiarity of what I'm trying to do? Thanks in advance, JamieArticle: 32028
(snip) > > Xilinx: are you listening? > > --andy > Welcome to the world of Xilinx :) In an unusual defensive stance for Xilinx, I should let you know I met with the team leader for the Webpack project a few weeks ago to discuss my _long_ list of gripes with the tool. They were sincerely interested in listening to customer comments, so we should see some improvements down the road... cheers, Jeff -- *********************************************** Jeffrey Vallier Sr. FW Engineer Gibson Guitar Corp. GMICS Division 1283 F Old Mtn View/Alviso Rd. Sunnyvale, CA 94089 408 734 4394 ***********************************************Article: 32029
At a recent seminar I attended on the Triscend chip, they said it could. SteveArticle: 32030
Peter Alfke schrieb: > > Of course, and you had to make sure that the red cut-out piece wordn't drop down > somewhere elso... > Later we checked larger circuits by crawling on the floor. ;-)) Ohh, I would give a kingdom to see a picture from this old days . . . -- MFG FalkArticle: 32031
Peter Alfke schrieb: > > Of course, and you had to make sure that the red cut-out piece wordn't drop down > somewhere elso... > Later we checked larger circuits by crawling on the floor. Floorplanner V0.01 ;-)))))) SCNR. -- MFG FalkArticle: 32032
Kolja Sulimma schrieb: > > Virtex is too expensive. > You should buy Virtex-E or Spartan-II. Do you know why Virtex is that expensive?? Virtex-E is better and cheaper. Is it a matter of production volume? -- MFG FalkArticle: 32033
Thomas Karlsson wrote:
> I have a state machine with 18 states. No matter what kind of state encoding
> I force the state vector flops into an illegal state for a moment (two flops
> set in a one-hot coded machine in this case)
> to simulate a disturbance, but then the next_state signal doesn't get the
> value for the state IDLE. (It gets a "five-hot" value!).
If you leave your encoding setting on AUTO,
Leo will choose a failsafe encoding for you.
Or you can design your own with explicit state values.
Some designers worry about illegal state recovery.
Some don't.
If you want it, it may cost you a gate or two.
-Mike Treseler
Article: 32034Falk Brunner wrote > > Do you know why Virtex is that expensive?? Virtex-E is better and > cheaper. > Is it a matter of production volume? Virtex-E is a redesign to smaller geometries, resulting in a smaller chip, but on a different process ( that's why the 1.8 V instead of 2.5 V). We pass on the savings... Yes, Virtex-E is a better buy. The only concern might be the need for a 1.8 V supply, and the lack of direct 5-V tolerance on the inputs ( although there are ways around that, with external resistors). Peter AlfkeArticle: 32035
FPGAs are quite large chips. Chip area is therefore a relatively large cost factor. In a modern process technology you get more gates on a wafer therefore reducing the cost per gate. Also, FPGAs have a lot of wiring. Using more metal layers further reduces the chip size. Virtex uses a 0,22um 5 layer metal technology. Virtex-E uses a 0,18um 6 layer metal technology. Virtex-II uses a 0,15um 8 layer metal technology. If you look up old devices at www.nuhorizons.com you will find that the cost per gate becomes very expensive for older parts. This is mainly due to manufacturing costs. Once our webserve is back online you can look up a comparison where the FPGA price is plotted against the gate count for various xilinx families. http://www.em.informatik.uni-frankfurt.de/~prak/ss01/Woche1/sld033.htm The feature size shown in the slide is the effective channel length and therefore differs form the above numbers. For a good laugh also look at the following slides. Kolja Sulimma Falk Brunner wrote: > Kolja Sulimma schrieb: > > > > Virtex is too expensive. > > You should buy Virtex-E or Spartan-II. > > Do you know why Virtex is that expensive?? Virtex-E is better and > cheaper. > Is it a matter of production volume? > > -- > MFG > FalkArticle: 32036
Peter Alfke schrieb: > > > Virtex-E is a redesign to smaller geometries, resulting in a smaller chip, but > on a different process ( that's why the 1.8 V instead of 2.5 V). > We pass on the savings... Nice. > > Yes, Virtex-E is a better buy. The only concern might be the need for a 1.8 V > supply, and the lack of direct 5-V tolerance on the inputs ( although there > are ways around that, with external resistors). No problem in a 3.3V environment. -- MFG FalkArticle: 32037
Kolja Sulimma schrieb: > > > For a good laugh also look at the following slides. ;-)))))))))))))))))) -- MFG FalkArticle: 32038
What version SW are you using? The currrent release, 10.0, is pretty solid with Quartus fitter enabled or disabled. Previous versions did have a problem with the Quartus fitter (which could be disabled). Version 10.0 has been around for about 6 months or more. -- bob elkind, the e-team -- fpga design, consulting Russell Shaw wrote: > > Using the Quartus fitter in maxplus2 (for acex1k), it crashes at > 28% when doing a simple 32x8 lpm fifo function and not much else > (pc has 256MB ram). By setting the option not to use quartus, the > compilation completes without error. Have you found the same bugginess? > > bob elkind wrote: > > > > The Max7K family, in my experience, tends to be more finicky about > > being filled to >80% utilisation with pinouts pre-defined. The 6K and the > > Acex 1K families (my current favourites) are much more forgiving in this > > regard (and of course, they also have many more pins :=) ). > > > > You may wish to consider replacing your Max7Ks device with a > > Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system > > programmable config EEROM). You probably won't be very far > > removed in cost, and you will be light-years ahead in usable gates, > > power consumption, AC performance, and pinot flexibility. > > > > -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.) > > > > -- > ___ ___ > / /\ / /\ > / /__\ / /\/\ > /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ > \ \ / Victoria, Australia, Down-Under \ \/\/ > \__\/ \__\/Article: 32039
> The difference here is that ViewDraw et al are proprietary whereas the 2 major > HDLs are public standards. > Hence if you stick to the defined synthesisable subset you know that all the > tools have to support your code. The FPGA tools are proprietary too! Also, I tell clients to archive the tools with the project. > One of the big uses of modern, large, FPGAs is for ASIC prototyping. How big? I don't believe it sells many FPGAs...and I don't believe it's THAT big... It certainly IS a use, but big...I'm skeptical... > The second place where portability comes in is the entire IP arena. > > Portability takes some work but with effort its possible to reduce the > technology changes to this list: > > o IO buffer selection. > o Clock trees. > o DP RAMs. > o DLL/PLLs. > o Choosing a cell for any clock domain synchronisers. > > I also notice that you haven't taken up the question re version control & the > ability to do a diff between revisions. Because it has never ever been an issue with me, or any of my clients. You can version control the schematics, what's so hard about that? I've never had to diff between revisions...I can visually see what the differences are, that is if the schematic is drawn correctly. The reason you DO need "diff" with text based is because it is so hard to find the differences!Article: 32040
I'm trying to work out whether its possible to do Ethernet in an FPGA. Not just the MAC layer and then out on MII to an external PHY but connect directly to the TP transformer. Does anybody know if any of the Virtex2 differential IO standards would work either directly or with a minimal amount of level shifting ?Article: 32041
"iglam" <rluking@deletethispart.home.com> wrote: > In general, I agree. Grey code address counters and a comparitor in > one clock domain. One trick I like to do is use an extra address bit. > If you have a 16 word fifo, use a 5 bit address counter. Bzzzzzt. This won't work. Consider a 4-word fifo using a 3-bit gray-code counter. The count sequence is: 000 001 011 010 110 111 101 100 The low 2 bits follow a different sequence between the first 4 counts and the second 4 counts. Your data would get scrambled. To do this correctly, you'd have to implement your counters as a binary counters, and then translate them to gray code to cross the clock boundary, and then translate them back to binary to do the arithmetic.Article: 32042
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3B254B35.D80BFD4F@algor.co.uk... > > I'm trying to work out whether its possible to do Ethernet in an FPGA. > Not just the MAC layer and then out on MII to an external PHY but > connect directly to the TP transformer. Does anybody know if any of the > Virtex2 differential IO standards would work either directly or with a > minimal amount of level shifting ? > Nope. We researched this pretty throughly and from our perspective there's too much mixed signal crap involved to make it worthwhile. Good idea though :) Don't despair, 'cause I have heard rumors of Phy-in-an-FPGA floating around. I think this is a solution that many designers wish for--we just have to wait for a "big" customer to want it enough to cough up the development costs and then have it filter down the product channels as a standard part for the rest of us. good luck, Jeff -- *********************************************** Jeffrey Vallier Sr. FW Engineer Gibson Guitar Corp. GMICS Division 1283 F Old Mtn View/Alviso Rd. Sunnyvale, CA 94089 408 734 4394 ***********************************************Article: 32043
Jeffrey Vallier wrote: > > (snip) > > > > > Xilinx: are you listening? > > > > --andy > > > > Welcome to the world of Xilinx :) In an unusual defensive stance for Xilinx, > I should let you know I met with the team leader for the Webpack project a > few weeks ago to discuss my _long_ list of gripes with the tool. They were > sincerely interested in listening to customer comments, so we should see > some improvements down the road... Ahhh, I've been living the Xilinx world for quite some time. I'm still sorta annoyed that the nifty tristate registers in the XC4KX/XL/XLA parts are never going to be supported without a hack, but the newere chips are cheaper. Actually, I'm trying to figure out where Xilinx positions Webpack. I mean, it doesn't support a lot of the chips, but the tools (other than the goofy project manager) seem to be the same as the mainstream F3.3i stuff. > Jeffrey Vallier Sr. FW Engineer > Gibson Guitar Corp. GMICS Division Gibson, huh? Mebbe you could explain to me why my new (in 1996, when I bought it, anyways) Gibson Les Paul Special needed a fret dress... -andyArticle: 32044
Ian, I think the documentation should've come right out and said: "We don't support VHDL'93." A good question would be: "Why the hell not?" I mean, even Synopsys supports some of VHDL'93... Ian Young wrote: > > "Andy Peters" <andy(@)exponentmedia(.)com> wrote: > > >Hmmm..Ashenden sez this is OK; so does ModelSim. > > I'm also a Xilinx WebPACK user. I also have a copy of that book. > > Ashenden says this is OK in _VHDL-93_, which ModelSim also supports. > > >So, what's wrong? Does XST support generates? > > The problem is that, as far as I can tell, XST only understands > _VHDL-87_. > > Turning to p.645 of your copy of Ashenden, note that some syntax is > underlined. Anything underlined is VHDL-93 only, and I haven't found > any of it usable under XST. > > [Not quite true, you can bind ports to literal values in XST, but I > think that is strictly a VHDL-93 extension.] > > >But the example in the docs does NOT have the BEGIN, and the synth > >is happy if I remove it from my code. But I'm not happy, since I > >have to modify my code to satisfy the quirks of a non-compliant tool. > > It annoys me too, but you can't really say it is a non-compliant tool > just because it isn't compliant with the most recent version of the > language. Archaic, yes, but not non-compliant. > > >OK, so the tools are FREE. What should I expect? > > Curiously, I understand that Xilinx also sell the XST stuff > (certainly, a synthesis bug in the WebPACK XST I found was apparently > also present in the pay-for package). Now, 1993 is quite a long time > ago and I'm pretty surprised that XST apparently doesn't include most > of the later extensions. However, if you take this limitation into > account and re-read Ashenden with that in mind (in other words, ignore > the huge tracts of useful stuff it turns out you can't actually use) > then things fall into place fairly well. > > Actually, if you're using Ashenden as a reference I'm surprised you > didn't hit the lack of direct instantiation in VHDL-87 and XST first, > as he spends eight pages (136--144) on how that's the obvious way to > do things before finally saying you can't do it at all in VHDL-87... > > >Xilinx: are you listening? > > I'd certainly be interested to know if they plan to do something about > this, but given the size of the differences between VHDL-87 and -93, I > don't imagine it will happen at all soon. > > -- IanArticle: 32045
Jamie, That's a feature and a bug: . the feature: the TBUF placement algorithm is assuming that the datapath (ADs and CBEs) is surrounding RDY signals, which makes some sense timing wise. . the bug: the test that was supposed to enforce this didn't report an error as it was supposed to. Gathering all PCI signals on a single bank is freeing up a bank where a different IO standard could be used. The new version of the UCF Generator to be released this Friday would now allow you to do that. Meanwhile, I could generate for you the UCF you need. Sorry for the inconvenience, - Matt Jamie Sanderson wrote: > Hi all; > > I am working on the initial floor plan of a design using the Xilinx PCI > core. Using their constraints generator, I have requested that the PCI pins > be on the slot side of the device. This causes them to be spread evenly > across the end of I/O bank 2 and beginning of bank 3. I would like to shift > the core and its I/O such that it resides within a single quadrant of a > device. I've been experimenting with their UCF generator, but am having a > problem. In the device I'm using, the IRDY and TRDY pins are the first two > pins in the 3rd bank. In the UCF generator, I have re-ordered the signals > such that the RDY lines are first, with all others following them. > > This has nearly the desired effect. All of the pins are now in the third > bank. However, the internal location constraints do not make sense to me. > While most are shifted downwards in the Y plane, the address/data TBUFs are > shifted up. In other words, while the pins and everything else move down > into the South-East quadrant, the AD TBUFs have moved further into the > North-East quadrant. > > Does anyone know why this is? Is it a bug in their UCF generator, or due to > some peculiarity of what I'm trying to do? > > Thanks in advance, > JamieArticle: 32046
Robin Kinge wrote: > > > Shameless plug ;-) > > Sounds like a good start though. Anyone in the UK give us a clue if this available here? > > Robin I got one a while ago, before the new 'select-any-frequency-you-like' module was part of it :-( Apart from a rather zealous customs inspection, it arrived fine - Customs managed to put about 6 tons of yellow 'This has been inspected' tape all over the packaging, inside and out ... God alone know what they thought it was:-) I've got Webpack, (it comes on a CD with the kit, although I'd already downloaded it - ADSL is great :-)) and it works pretty well, although I'm told it's not as good as the stuff you pay for (FPGA editor ?) I think it's good enough for my (hobby-like) purposes though... Frankly, I think it's worth a shameless plug :-) No I'm not in any way associated, yada yada yada... Simon. -- Freedom ? What's that ? (see http://www.domesday.co.uk/ )Article: 32047
Don, I'm disappointed you didn't give iglam the benefit of the doubt in his short response. Converting both ways between binary and Gray and using 4 bit comparators is more resource intensive than the Gray counter's msb inversion of the lsbs of the address and the comparator xor. No data scramble. Of course using the lsbs unmodified would scramble your data. Iglam incorrectly mentioned the msb was ignored but I don't see that as reason to dismiss the idea out of hand. Don Husby wrote: > Bzzzzzt. This won't work.Article: 32048
Don, I'm disappointed you didn't give iglam the benefit of the doubt in his short response. Look at your example of why the count sequence "won't work" and take an xor of the two msbits instead of ignoring the msbit. Suddenly there's no data scramble. Converting both ways between binary and Gray and using 4 bit comparators is more resource intensive than the xor of the Gray counter's two msbits and the comparator xor. Of course using all the lsbs unmodified would scramble your data. Iglam incorrectly mentioned the msb was ignored but I don't see that as reason to dismiss the idea out of hand. Gray is powerful, but you can't ignore the fact that it's different from what we're "used to." > Bzzzzzt. This won't work. > > Consider a 4-word fifo using a 3-bit gray-code counter. The > count sequence is: > 000 > 001 > 011 > 010 > 110 > 111 > 101 > 100Article: 32049
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