Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sun, 23 May 2010 19:30:37 +0000, Philip Pemberton wrote: > INTERNAL_ERROR:Xst:cmain.c:3464:1.56: Process will terminate. For > technical support on this issue, please open a WebCase with this project > attached at http://www.xilinx.com/support. OK, in the interests of documentation... this is how you provoke the bug, and how to work around it. Phase 1: Provocation ==================== Create a bus port in the design's 'top' module, but make it wider than the UCF pin specification. Assign an IOB constraint (IOB=TRUE or IOB=FORCE) to it. Assign a varying value to all pins of the bus (that is, a value that can change depending on the input to the logic). For example: // top.v (* IOB = "TRUE" *) output [12:0] SDRAM_A # top.ucf NET "SDRAM_A<0>" LOC = "J12" | IOSTANDARD = LVTTL ; NET "SDRAM_A<1>" LOC = "A3" | IOSTANDARD = LVTTL ; # ... NET "SDRAM_A<10>" LOC = "J13" | IOSTANDARD = LVTTL ; NET "SDRAM_A<11>" LOC = "C4" | IOSTANDARD = LVTTL ; # NET "SDRAM_A<12>" LOC = "D11" | IOSTANDARD = LVTTL ; Note that SDRAM_A12 is commented out in the UCF. Phase 2: Resolution (or rather "workaround") ============================================ Either specify a pin location constraint for SDRAM_A[12] in the UCF, or reduce the size of the SDRAM_A bus in the Verilog source. Phase 3: The Executive Summary ============================== Xst doesn't like it when you specify an IOB constraint on an output port that hasn't been assigned a pin on the chip. I'd still like to find out how to report this to Xilinx... "just open a Webcase" is only a valid solution when you can actually get to Webcase... -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147776
On 23 May 2010 18:21:25 GMT, Philip Pemberton <usenet10@philpem.me.uk> wrote: >It seems I set "Pack I/O Registers into IOBs" to "Yes" on the working >version (which causes A LOT of warnings), while it's set to "Auto" in the >"broken" version. Can I force FFs in the IOBs in the UCF constraints, or >do I need to do that with a "// synthesis IOB=FORCE" constraint in the >Verilog source? UCF is a bit too late for synthesis... the only tool that reads it is NGDbuild, aka "Translate", which embeds the UCF information in other files passed downstream. I don't do Verilog but it makes sense that there's an equivalent to setting attributes for such things in VHDL. And applying them directly to the correct signals will save warnings elsewhere... Be aware that XST is finicky though. Your "FORCE" attributes may merely result in "constraint is being ignored" warnings unless everything else lines up right (duplicate regs not being optimised away) so if you don't get what you expect in the .mrp, check the synth report carefully... - BrianArticle: 147777
LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBXZWQs IDE5IE1heSAyMDEwIDE4OjIzOjUxICswMjAwDQpwZXMgPGRvbnRzcGFtbWVAdGhhbmtzLmNvbT4g d3JvdGU6DQoNCltzbmlwXQ0KPiB3aGF0IG90aGVyIHNvbHV0aW9uIHdvdWxkIHlvdSBjaG9vc2Ug Zm9yIHRoZSBtZW1vcnkgY29uZmlndXJhdGlvbiBhbmQgDQo+IHdoaWNoIGNhbiBiZSB1cGRhdGVk IHdpdGggYSBtaWNyb2NvbnRyb2xsZXI/DQo+IA0KPiANCj4gVGhhbmsgeW91DQoNCkkgZG9uJ3Qg a25vdyB0aGUgU3BhcnRhbiA2IGZhbWlseSBwZXIgc2UsIGJ1dCBteSBhcHBsaWNhdGlvbiBpcyB1 c2luZw0KYSBTcGFydGFuIDNBIGFuZCBJIHVzZSB0aGUgU1BJIEZsYXNoIGNvbmZpZ3VyYXRpb24g b3B0aW9uLiBRdWl0ZSBuaWNlDQphbmQgZWFzeSB0byB1cGRhdGUgZnJvbSBhIG1pY3JvY29udHJv bGxlciwgb3IgZXZlbiB0aGUgRlBHQSBpdHNlbGYgaWYNCnlvdSB3YW50ZWQgKEkgZG8gbXkgdXBk YXRlcyBvdmVyIGEgcmFkaW8gbW9kdWxlKS4NCg0KQ2hyaXMNCi0tLS0tQkVHSU4gUEdQIFNJR05B VFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjE0IChHTlUvTGludXgpDQpDb21tZW50OiBH bnVQVCAyLjcuMg0KDQppRVlFQVJFQ0FBWUZBa3Y1OFBRQUNna1FYVUY2aE9UR1A3ZGZvZ0NlSitG aEhsUTFuZVNKTEtIQWYxOWJYbUJaDQoxa1VBbkE3RW9aTTBxZ0x4VVgzeG1URmZySjVWZW50VA0K PVBaMkcNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KArticle: 147778
On May 22, 11:40=A0pm, rombios <h...@here.com> wrote: > I bought a few of these on ebay but I cant find Xilinx Xact software > needed to design with these FPGAs > > Can someone point me in the right direction? > Anyone have a copy I can buy? > > sincerely > hungry student These devices are not worth your time and energy to try to use. Get a low cost Spartan-3A board and use the free ISE Webpack software. Ed McGettigan -- Xilinx Inc.Article: 147779
I'd second Ed's opinion. These devices were released circa 20-25 years ago and their only useful place now is a museum. Almost anyone that does have software for these will have a reason like long term product maintainence and they are unlikely to let go the software. John Adair Enterpoint Ltd. - Home of Merrick1. The FPGA HPC Solution. On 23 May, 07:40, rombios <h...@here.com> wrote: > I bought a few of these on ebay but I cant find Xilinx Xact software > needed to design with these FPGAs > > Can someone point me in the right direction? > Anyone have a copy I can buy? > > sincerely > hungry studentArticle: 147780
> These devices are not worth your time and energy to try to use. Get a > low cost Spartan-3A board and use the free ISE Webpack software. > > Ed McGettigan Id like to build a board around these chips (simple projects to aid the learning process - which is not limited to hdl digital design but board manufacturing as well). More "modern" fpgas come in formfactors that make it all but impossible to solder at home. The xc2xxx and xc3xxx chips come in plcc68/84 arrangements. I can buy plcc to dip sockets cheap from many online electronic retailers as well as ebay. I did something like these for the xc9xxxx CPLD's which are still supported in xilinx webpack software Listen, it would really help if I can buy XACT. I dont need support, just the software. If its reached end-of-life, I assume you guys would post it AS IS on some ftp server link right? For what its worth future projects that advance past what am working on would benefit from the spartan series ...Article: 147781
On May 24, 3:03=A0am, fpgahobbyist <noth...@onearth.com> wrote: > > Id like to build a board around these chips (simple projects to aid the > learning process - which is not limited to hdl digital design but board > manufacturing as well). I'd suggest you'll get very little education on modern board fabrication from producing a through-hole board. You actually *want* to use surface mount caps, resistors, and hand-solderable TQFP devices. And you'll want to lose the 5V unless you're doing analog and/or RF. > > Listen, it would really help if I can buy XACT. I dont need support, just > the software. If its reached end-of-life, I assume you guys would post it > AS IS on some ftp server link right? The XC2000 series reached end-of-life around 2000. You're a DECADE past that point. There is no point.Article: 147782
On May 23, 12:41=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > > http://lekernel.net/blog/?p=3D1023 Many thanks for finding the blog.Article: 147783
In article <1274684612.909547@nntp.aceinnovative.com>, nothere@onearth.com says... > > These devices are not worth your time and energy to try to use. Get a > > low cost Spartan-3A board and use the free ISE Webpack software. > > > > Ed McGettigan > > Id like to build a board around these chips (simple projects to aid the > learning process - which is not limited to hdl digital design but board > manufacturing as well). Well you are looking at small FPGA/large CPLD then for HDL language, get yourself afew schmart boards which make TQFP and similar easier for hobby or learning process that suit the available PLD/FPGA devices you can get. Use the available software Xilinx/Altera/Lattice/....... > More "modern" fpgas come in formfactors that make it all but impossible > to solder at home. There are variants in TQFP, that can be hand soldered using Schmart boards or get a demo board. > The xc2xxx and xc3xxx chips come in plcc68/84 arrangements. I can buy plcc > to dip sockets cheap from many online electronic retailers as well as > ebay. More devices are available in TQFP. > I did something like these for the xc9xxxx CPLD's which are still > supported in xilinx webpack software > > Listen, it would really help if I can buy XACT. I dont need support, just > the software. If its reached end-of-life, I assume you guys would post it > AS IS on some ftp server link right? > > For what its worth future projects that advance past what am working on > would benefit from the spartan series ... Then get the Spartan demo board now and don't waste your money on dead ends. Schmart boards are easy to find, hust do a google search. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hateArticle: 147784
null <anonymous.reply.sender@n_o_s_p_a_m.gmail.com> wrote: > In the Virtex 4 FPGA, slices within a CLB are interconnected with each > other. However, in Virtex 5 and Virtex 6, there is no direct connection > between slices of a CLB. Why was this change made? On what connections do you refer? Give some reference to the appropriate diagram in the userguide/datasheet. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 147785
On Mon, 24 May 2010 01:26:07 +0100, Brian Drummond wrote: > I don't do Verilog but it makes sense that there's an equivalent to > setting attributes for such things in VHDL. And applying them directly > to the correct signals will save warnings elsewhere... I had another look at the constraints manual last night and found what I was looking for. Apparently, the syntax I was looking for was: (* IOB="TRUE" *) output sdram_xyz; (replace 'output sdram_xyz' with the I/O spec). This also turned up a nasty INTERNAL_ERROR bug in Xst, see my other thread for more info on this (my second post in that thread contains an explanation of the bug, and a workaround). > Be aware that XST is finicky though. Your "FORCE" attributes may merely > result in "constraint is being ignored" warnings unless everything else > lines up right (duplicate regs not being optimised away) so if you don't > get what you expect in the .mrp, check the synth report carefully... Actually, it seems that IOB=FORCE makes Xst bail out if it can't honour the constraint. Some of the SDRAM controller cache logic uses BA internally; setting IOB=FORCE stops the Translate process from completing. Use IOB=TRUE, and ISE appears to add a couple of extra FFs to allow SDRAM_BA to be pushed into the IOB. I've also noticed that it's running the SDRAM pins in slew-rate limited (SLOW) mode, so I'm going to see if adding a "SLEW=FAST" constraint in the UCF helps out any (hopefully it'll get the setup/hold times down from ~6ns to something a little more reasonable). -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147786
fpgahobbyist wrote: > > > These devices are not worth your time and energy to try to use. Get a > > low cost Spartan-3A board and use the free ISE Webpack software. > Id like to build a board around these chips (simple projects to aid the > learning process - which is not limited to hdl digital design but board > manufacturing as well). > > More "modern" fpgas come in formfactors that make it all but impossible > to solder at home. Seems hobbyists are no market in these days. Sure, they maybe only buy 10 pieces, but if this is done by many people then this my become still a big quantity. I really would like to see a FPGA in PLCC84 package with 5 V I/O voltage (and maybe an additional smaller core voltage). There are still much older TTL gates so why shouldn't there also be a XC3195 (including the developement software). > The xc2xxx and xc3xxx chips come in plcc68/84 arrangements. I can buy plcc > to dip sockets cheap from many online electronic retailers as well as > ebay. > > I did something like these for the xc9xxxx CPLD's which are still > supported in xilinx webpack software > > Listen, it would really help if I can buy XACT. I dont need support, just > the software. If its reached end-of-life, I assume you guys would post it > AS IS on some ftp server link right? I really can understand you, but it's not so simple to get a working Viewlogic/XACT system. You will need a DOS-PC (a real DOS, not a DOS box in Windows) a graphics card which provides the graphic mode Viewlogic needs and a three button V24 mouse. And then you need the original software because both, Viewlogic and XACT use a parallel port dongle (but this should be the smallest problems, because they seem to be simple passive dongles of the first generation). But on the other side you will get a professional system (ok, Viewlogic was quite expensive compared to the free Webpack). We still have a laboratory course were we use Vielogic/XACT using a XC3195 FPGA. And we have saved a few old PCs and V24 mouses as a replacement because the course will die when we run out of old hardware. And we can't convert it to the actual ISE software, because then we would need twice the time for the course which simple isn't available. We have converted a simpler course (implementation of an extremely simple CPU in about 10 hours) using a DARNAW1 board and ISI9 (schematic entry, not VHDL). This design is so simple that you nearly can't make any design error, but still the students now need at least 50% more time to finish the course. But at least this can be used as a good example what happens if you let software engineers develop software. The Viewlogic system seems was written by hardware engineers to support their daily work. When the system become popular (despite it's prices), software engineers where hired and that seems was the end of Vielogic (I installed the Windows version of Vielogic, but removed it immediately). Every software engineer should be forced to work whit his product for a few month, then we would have much better software.Article: 147787
In comp.arch.fpga John Adair <g1@enterpoint.co.uk> wrote: > I'd second Ed's opinion. These devices were released circa 20-25 years > ago and their only useful place now is a museum. Almost anyone that > does have software for these will have a reason like long term product > maintainence and they are unlikely to let go the software. When I first knew about FPGAs, about 15 years ago, XC2000 devices were still in the book, but no-one I knew used them. I believe that Xilinx still has software for XC4000 devices on their web site, and I might even believe that some would still use them. If you want a hobbyist device, go for XC4000 series. -- glenArticle: 147788
> Seems hobbyists are no market in these days. Sure, they maybe only buy > 10 pieces, but if this is done by many people then this my become still > a big quantity. I really would like to see a FPGA in PLCC84 package with > 5 V I/O voltage (and maybe an additional smaller core voltage). There > are still much older TTL gates so why shouldn't there also be a XC3195 > (including the developement software). I completely agree. I have done a lot of projects, some I have sold, some I have given away. Its great to be able to design/develop without a HUGE investment in manufacturing tools (for smd parts) This is another reason I maintain a large stock of 22v10 in dip and plcc form along with an assorted collection of 8bit micros in dip form as well. Lately I have been trying to get a hold of the xc95xxx CPLD's and the Altera EPM71XX parts. Guess Ill have to dump these xc2018/30xx parts ;(Article: 147789
On May 24, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga John Adair <g...@enterpoint.co.uk> wrote: > > > I'd second Ed's opinion. These devices were released circa 20-25 years > > ago and their only useful place now is a museum. Almost anyone that > > does have software for these will have a reason like long term product > > maintainence and they are unlikely to let go the software. > > When I first knew about FPGAs, about 15 years ago, XC2000 devices > were still in the book, but no-one I knew used them. > > I believe that Xilinx still has software for XC4000 devices on > their web site, and I might even believe that some would still > use them. =A0If you want a hobbyist device, go for XC4000 series. > > -- glen I disagree with the suggestion to use an XC4000. HDL support for this family (and the Spartan/SpartanXL) ended 5+ years ago. And by ended, I mean that there is no legal way of obtaining the necessary software. RKArticle: 147790
Depending on what you want to achieve there are ways to make boards simple by using modules like our previously mentioned Darnaw1. There are also the DIL format Craignell1 http://www.enterpoint.co.uk/component_replacements/craignell.html and Craignell2 http://www.enterpoint.co.uk/component_replacements/craignell2.html modules. These modules allow you to develop your own carrier board but handle the complex and costly BGA bit for you. There are other low cost products like our Polmaddie series http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html offer ways into FPGA and CPLD technology at not a lot of cost. These particular boards sell 1 off at GBP 40 (approx USD 60, Euro 50) in one off and you get a free programming cable (parallel port) for that money. Club together with a couple of friends and you can get free worldwide shipping on our web shop if you can get the order over GBP 100. All of these products are bought by hobby engineers. Tools for all of the above are free to download. We also use 0.1 inch/ 2.54mm pitch headers/sockets a lot to facilitate hobby and student markets with many customers even building their add ons with simple stripboard. John Adair Enterpoint Ltd. On 24 May, 18:19, fpgahobbyist <noth...@onearth.com> wrote: > > Seems hobbyists are no market in these days. Sure, they maybe only buy > > 10 pieces, but if this is done by many people then this my become still > > a big quantity. I really would like to see a FPGA in PLCC84 package with > > 5 V I/O voltage (and maybe an additional smaller core voltage). There > > are still much older TTL gates so why shouldn't there also be a XC3195 > > (including the developement software). > > I completely agree. I have done a lot of projects, some I have sold, some > I have given away. Its great to be able to design/develop without a HUGE > investment in manufacturing tools (for smd parts) > > This is another reason I maintain a large stock of 22v10 in dip and plcc > form along with an assorted collection of 8bit micros in dip form as well. > > Lately I have been trying to get a hold of the xc95xxx CPLD's and the > Altera EPM71XX parts. > > Guess Ill have to dump these xc2018/30xx parts ;(Article: 147791
On May 24, 1:33=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > On May 24, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > In comp.arch.fpga John Adair <g...@enterpoint.co.uk> wrote: > > > > I'd second Ed's opinion. These devices were released circa 20-25 year= s > > > ago and their only useful place now is a museum. Almost anyone that > > > does have software for these will have a reason like long term produc= t > > > maintainence and they are unlikely to let go the software. > > > When I first knew about FPGAs, about 15 years ago, XC2000 devices > > were still in the book, but no-one I knew used them. > > > I believe that Xilinx still has software for XC4000 devices on > > their web site, and I might even believe that some would still > > use them. =A0If you want a hobbyist device, go for XC4000 series. > > > -- glen > > I disagree with the suggestion to use an XC4000. =A0HDL support for this > family (and the Spartan/SpartanXL) ended 5+ years ago. =A0And by ended, > I mean that there is no legal way of obtaining the necessary software. > > RK I'll third that opinion. Also the XC4000 series is much more expensive than many newer, larger, faster devices. If you want 5V tolerance, look into Spartan 2, also long in the tooth but supported by ISE 10.1 and available in VQ and TQ package types. Regards, GaborArticle: 147792
In comp.arch.fpga d_s_klein <d_s_klein@yahoo.com> wrote: (snip, I wrote) >> I believe that Xilinx still has software for XC4000 devices on >> their web site, and I might even believe that some would still >> use them. If you want a hobbyist device, go for XC4000 series. > I disagree with the suggestion to use an XC4000. HDL support for this > family (and the Spartan/SpartanXL) ended 5+ years ago. And by ended, > I mean that there is no legal way of obtaining the necessary software. I meant it in the sense that one shouldn't go farther back than that. I thought the software was on the "Classic" section of the Xilinx web site, but didn't try actually installing it. -- glenArticle: 147793
On May 24, 3:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga d_s_klein <d_s_kl...@yahoo.com> wrote: > (snip, I wrote) > > >> I believe that Xilinx still has software for XC4000 devices on > >> their web site, and I might even believe that some would still > >> use them. =A0If you want a hobbyist device, go for XC4000 series. > > I disagree with the suggestion to use an XC4000. =A0HDL support for thi= s > > family (and the Spartan/SpartanXL) ended 5+ years ago. =A0And by ended, > > I mean that there is no legal way of obtaining the necessary software. > > I meant it in the sense that one shouldn't go farther back than that. > > I thought the software was on the "Classic" section of the Xilinx > web site, but didn't try actually installing it. > > -- glen I'm still running version 4.1 of the Xilinx tools, but the "Foundation" not "ISE" version. You can still get ISE 4.1, but it doesn't include synthesis or schematics, so you'd need some third party tools to make up the gap. Xilinx no longer offers the original Foundation versions, since they don't own the third party (Aldec) content. The Alliance tools, by the way also required additional third party tools for synthesis or schematics. Definitely not on a hobbyists budget. Regards, GaborArticle: 147794
Hi, how does an (unclocked) 2:1 multiplexer behave if input B is selected and input A becomes metastable ? Does the metastability of A have an influence on the stability of the mux output at any point of time ? cheers, hssigArticle: 147795
On May 24, 3:58=A0pm, hssig <hs...@gmx.net> wrote: > Hi, > > how does an (unclocked) 2:1 multiplexer behave if input B is selected > and input A becomes metastable ? Does the metastability of A have an > influence on the stability of the mux output at any point of time ? > > cheers, > hssig For an ideal multiplexer, I'd have to say that input A should have no effect if B is selected. However in an FPGA, muxes are often built from look-up tables, which could exhibit odd behavior if one input stayed in the logic threshold region long enough. Think of a LUT as a bunch of ones and zeroes feeding a larger (usually 16:1) mux. Then A, B and SEL would all be select inputs to the LUT. Theoretically if SEL is low, then the output value should not depend on B, but if the mux uses decoders and FETs to connect one input at a time to the output, and the B input is neither 1 nor 0, the output could float. Normally this period of floating would be too short for the output to glitch while B is transitioning. But a particularly long metastable event could float the output long enough for it to change state. Such an event would indeed be rare. Regards, GaborArticle: 147796
The other problem you get with old software is the OS. I keep some machines with NT for times I need to run my old version software. John Adair Enterpoint Ltd. On 24 May, 20:15, Gabor <ga...@alacron.com> wrote: > On May 24, 3:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > In comp.arch.fpga d_s_klein <d_s_kl...@yahoo.com> wrote: > > (snip, I wrote) > > > >> I believe that Xilinx still has software for XC4000 devices on > > >> their web site, and I might even believe that some would still > > >> use them. =A0If you want a hobbyist device, go for XC4000 series. > > > I disagree with the suggestion to use an XC4000. =A0HDL support for t= his > > > family (and the Spartan/SpartanXL) ended 5+ years ago. =A0And by ende= d, > > > I mean that there is no legal way of obtaining the necessary software= . > > > I meant it in the sense that one shouldn't go farther back than that. > > > I thought the software was on the "Classic" section of the Xilinx > > web site, but didn't try actually installing it. > > > -- glen > > I'm still running version 4.1 of the Xilinx tools, but the > "Foundation" > not "ISE" version. =A0You can still get ISE 4.1, but it doesn't include > synthesis or schematics, so you'd need some third party tools > to make up the gap. =A0Xilinx no longer offers the original Foundation > versions, since they don't own the third party (Aldec) content. =A0The > Alliance tools, by the way also required additional third party > tools for synthesis or schematics. =A0Definitely not on a > hobbyists budget. > > Regards, > GaborArticle: 147797
Gabor <gabor@alacron.com> wrote: > On May 24, 3:58 pm, hssig <hs...@gmx.net> wrote: >> how does an (unclocked) 2:1 multiplexer behave if input B is selected >> and input A becomes metastable ? Does the metastability of A have an >> influence on the stability of the mux output at any point of time ? > For an ideal multiplexer, I'd have to say that input A should > have no effect if B is selected. However in an FPGA, muxes are > often built from look-up tables, which could exhibit odd > behavior if one input stayed in the logic threshold region > long enough. I believe that the LUT/mux design on most FPGAs is such that they won't glitch in the case of a single input changing with LUT entries that don't change the output. One way to do that would be to implement the 16:1 mux as 15 2:1 mux chained together. That might be a little too much, but you are supposed to be able to rely on them not glitching. > Think of a LUT as a bunch of ones and zeroes > feeding a larger (usually 16:1) mux. Then A, B and SEL would > all be select inputs to the LUT. Theoretically if SEL is > low, then the output value should not depend on B, but if > the mux uses decoders and FETs to connect one input at > a time to the output, and the B input is neither 1 nor 0, > the output could float. Normally this period of floating > would be too short for the output to glitch while B is > transitioning. But a particularly long metastable event > could float the output long enough for it to change state. > Such an event would indeed be rare. The one that I would wonder about is, if the metastable input was oscillating at a high frequency, that it might capacitively couple through. My guess is that either they don't oscillate that fast, or that they won't couple even if they do. (With the current high-speed devices, it might not be possible to oscillate that fast.) -- glenArticle: 147798
On Mon, 24 May 2010 18:32:32 -0500, "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz> wrote: >>>>I don't drive the Xilinx software myself, but R, my guy who does, >>>>uses MAKE files and avoids the top-level GUI, which is apparently >>>>crap. >>> >>>Interesting. I haven't used the latest Xilinx stuff. >>> >>>>Xilinx puts pin assignments into a UCF "universal constraints file", >>>>which we create from the PADS pcb netlist. We tell The Brat what >>>>signals we prefer on which banks and such, she routes it the way that >>>>works best, and we make the pin file for Xilinx. Seems to work. >>> >>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta). >> >>The "universal" part has occasioned some humor. It is handy to have >>the pin numbers in a file off to the side, but we could just as well >>have taken the PADS netlist and mashed that into VHDL, if VHDL were >>the way to name pins. For Xilinx, it isn't. > >It used to be *A* way. Seems they've removed the possibility. Maybe it makes >it too easy to retarget for the competition. ;-) Speaking of which, we're looking very seriously at cutting over to Altera for new designs. The Xilinx software is so broken they will probably never fix it. And the support is ghastly... when you get any at all. JohnArticle: 147799
On Mon, 24 May 2010 19:53:09 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Mon, 24 May 2010 18:32:32 -0500, "krw@att.bizzzzzzzzzzzz" ><krw@att.bizzzzzzzzzzzz> wrote: > >>>>>I don't drive the Xilinx software myself, but R, my guy who does, >>>>>uses MAKE files and avoids the top-level GUI, which is apparently >>>>>crap. >>>> >>>>Interesting. I haven't used the latest Xilinx stuff. >>>> >>>>>Xilinx puts pin assignments into a UCF "universal constraints file", >>>>>which we create from the PADS pcb netlist. We tell The Brat what >>>>>signals we prefer on which banks and such, she routes it the way that >>>>>works best, and we make the pin file for Xilinx. Seems to work. >>>> >>>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta). >>> >>>The "universal" part has occasioned some humor. It is handy to have >>>the pin numbers in a file off to the side, but we could just as well >>>have taken the PADS netlist and mashed that into VHDL, if VHDL were >>>the way to name pins. For Xilinx, it isn't. >> >>It used to be *A* way. Seems they've removed the possibility. Maybe it makes >>it too easy to retarget for the competition. ;-) > > >Speaking of which, we're looking very seriously at cutting over to >Altera for new designs. The Xilinx software is so broken they will >probably never fix it. And the support is ghastly... when you get any >at all. I get fantastic support from the Altera guys, though Arrow. They came in and set up my machine and gave me a day's driving lessons. They've even offered to do coding for us (not likely). Of course I always mention the cool features of their new Spartan-6 parts. ;-)
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