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
This is part of the console output when I run the FPGA editor.
Use a wide screen to view it.
Why don't you look to see if it matches what you get?
Bank 4 has 16 pads, 2 (12%) are utilized.
Name IO Select Std Vref Vcco Pad Pin
---- -- ---------- ------ ------ ------ ------
sys_clk_in I LVCMOS33 NR 3.30 IOB_X1Y55 AE14
None L
sram_clk_fb I LVCMOS33 NR 3.30 IOB_X1Y51 AD17
None Vr-Term L
Brad Smallridge
AI Vision
> When I set the IO standard for sram_clk_fb, as in your example,
> I cannot get through the PAR stage as it terminates with errors:
>
> ERROR:Place:311 - The IOB ZBTRAM_CLKFB_PIN is locked to site IOB_X1Y51
> in bank 4. This violates the SelectIO banking
> ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in
> your design cannot be automatically placed.
>
> This confuses me a lot since it's not the first time I've got this
> message (it happens quite frequently when I set IO standards
> manually). There are no other specific constraints in my design that
> could mess with those settings (or at least I think there aren't),
> I just make some simple pin assignments.
>
> Regards,
> Tomasz Dziecielewski
>
Article: 102751Didi wrote: > Jim, > > >> Sounds a strange idea - how does one macrocell, know that it's >>neighbours are used ? > > > strange things like that can indeed happen. On the oldest > coolrunner, for which I have written my logic compiler, there > was a possibility to use some more multiplexor paths than > the manufacturers software was using (IIRC it was 40 vs. 36). > I tried it only to discover that when it came to that, the > chip was becoming unstable... so I lowered my limit as well. That's rather a different case, even unique :) > Perhaps it is about power distribution, who knows. Coolrunners are low power devices - All I could think of was possibly longer programming times, for more device usage, but that is also a stretch... That's why the TIME-LINE of failures is important. Also, Vcc shorts do not sound like any device-mapping failures, but do sound like ESD/latchup .... -jg > > Nigel, > the fpga newsgroup should be better for this thread, > Austin or Peter (both highly knowledgeable Xilinx employees) > might be able to give some more info. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > > Jim Granville wrote: > >>Nigel wrote: >> >>>has anyone experienced problems when operating Cool Runner (XPLA3) >>>CPLDs near the capacity of their macrocells? specifically, i have two >>>devices that have failed independently with hard short circuits to >>>ground on the 3.3V power supplies. i have heard some anecdotal evidence >>>that this can happen when too many of the macrocells are used. has >>>anyone heard of this or seen it documented or reported elsewhere? >> >> Sounds a strange idea - how does one macrocell, know that it's >>neighbours are used ? >> Check things like ESD ratings, and latchUp ratings. >>When did the failures occur ? >> >>-jg > >Article: 102752
Hi, I have a cutom IP that i want to run at lest say at 80 Hz. I want to atatch this IP to PLB Bus which has clock running at 100 MHz. The IPIF interface provides you the Bus clock and all the required interface signals. What are my options to make the data cross from 100 Mhz clock domain to 80 Hz clock domain. i also need to drive 80 Hz clock from 100 Mhz clock so the both can be synchronous. ThanksArticle: 102753
c d saunter wrote: > Perhaps the real battleground is the software environments - development > and runtime. HDLs embrace parallelism naturally, but are stuck at a very > low level, procedural languages map to how most people thing and how CPU > cores work, and stink at parallelism. Many attempts are in various stages > of existence for a mix between these two extremes, none have yet to find > acceptence, and none (AFAIK) are usable across the range of technologies. > > Perhaps this is the real battleground? Not Really, software is one component of the greater architectural problem. What it does show is that Intel is willing to address cost issues, which are critical in the consumer and high end systems markets, while mappi9ng a course that will intersect with the cash market that Xilinx is seeking to grow into. Any die with hundreds of cores becomes a cluster on a chip and will need ready access to high speed external connects for memory, storage and communications. The solution that Intel maps out, intersects solidly with using Xilinx parts for reconfigurable computing, and it would not suprise me of at some point the end solution was a mix of ISA cores meshed into FPGA fabric. While FPGAs are very low density functionality wise with high overheads in little used interconnects, a dense ISA core design will have both high functional density and high utilitization on the interconnect by using both bus and on chip networking solutions. When these two architectures turn into systems, the Intel design provides more usable performance for the buck. Given Xilinx's inability to think visonary at the systems level and manage costs by design of their product and process, I suspect one likely course is that they are swallowed up with the stroke of a pen for their patents by a consumer level systems company. Sun, Intel, AMD, Sony, Fujitsu, etc .... The whole Itanium 64 bit thing has been the best case of doing something stupid, as heat and power grow faster than usable performance. The other end of the spectrum is bit serial, which has high architectural overheads. The sweet spot in size, heat, power is a dense fabric of simple cores, and lots of them to deliver the performance ... which is where reconfigurable computing has had it's small wins by building that using an inefficient FPGA technology. Wearing my Sr Architect hat, I've looked past FPGAs as the short term solution, into a path not that different in strategy to Intels ... but not using large x86 ISA cores, using something much smaller and cache dominated to balance the memory/processing ratio.Article: 102754
cds, Very astute. I agree with you. When we get together, and ponder the future, is it the technology, architecture, or tools? Or, is it all of the above? More and more of our customers want a 'pre-baked' solution that they can add their 'secret sauce' to (sorry for the mixed metaphor, not very appealing...no one bakes burgers). How can anyone possibly create IP for every possible application? Yet, that is what we are being asked to do. I hope you found the link to the pdf of the Intel talk that was also posted by me. It is certainly worth looking though, especially since Intel felt it was worth presenting. The caveat is that this presentation of Intel's is just one of many possible futures. How the future may change may not be obious, but it will change. Austin c d saunter wrote: > Austin Lesea (austin@xilinx.com) wrote: > : All, > > : A recent Intel presentation at an IEEE Workshop admitted that clock > : frequency has max'd out, and now has to go down (not up) in order to not > : create heat. > > : We have known that for years now. So has AMD. > > : The only choice is "multi." > > : Intel proposes a future with more than 200 x86 cores on one die, with a > : "communications fabric" and many memories. All on one die. Small > : software problem to be solved by the need to have it solved.... > > : One attendee of the conference (not me!) quipped, "sounds like you are > : describing a FPGA..." > > : Boy did the presenter get mad! To be ccompared to a lowly FPGA! He was > : spitting venom back at the attendee. "There is no comparison! FPGAs > : are fine grained, and this is not!" > > : Sounds like if that is the only difference, the FPGA wins. Again. > > : Oh, and I can't wait for Intel to stub their toes on that > : "communications fabric" (left as an exercise for the student). Or the > : software. > > It looks to me like different technologies - CPUS, FPGAs - are on a > collision course - FPGAs are incoperating more and more advanced corse > grained features and CPUs are segmenting, going parallel and more fine > grained, there're flexible interconnects in the former and roadmapped in > the later. Middle(ish) ground devices like offerings from Clearspeed and > the STI Cell procssor already exist. > > Convergence of the differnet hardware solutions is happening. > > Perhaps the real battleground is the software environments - development > and runtime. HDLs embrace parallelism naturally, but are stuck at a very > low level, procedural languages map to how most people thing and how CPU > cores work, and stink at parallelism. Many attempts are in various stages > of existence for a mix between these two extremes, none have yet to find > acceptence, and none (AFAIK) are usable across the range of technologies. > > Perhaps this is the real battleground? > > cdsArticle: 102755
"alpha" <zhg.liu@gmail.com> writes: > My design is from scratch. Its instruction set is almost same as MIPS > 3000 (without Multiplication). Lcc C compilier was ported. > I can publish the source verilog files, do we have public domain for > this purpose? I'm not sure I understand your question. If you've written it yourself, you can certainly put it in the public domain if you so choose. Or you could release it under any of a number of existing "open source" licenses. If you're asking about places to distribute it, you could try submitting it as a project for www.opencores.org. If you don't find anywhere else, you could send it to me, and I'd be happy to put it on a web page for you. EricArticle: 102756
"Marco T." <marc@blabla.com> writes: > You can use also emac from opencores, but in this way you don't have any > kind of support in your design. The OpenCores Ethernet MAC seems to work fine. It's very large, though. I think it should be possible to design a much smaller one, by using a simple microprogrammed controller to replace much of the hardwired logic. (I'm not complaining; getting a functional Ethernet MAC core for free is very nice.)Article: 102757
Austin Lesea wrote: > When we get together, and ponder the future, is it the technology, > architecture, or tools? > > Or, is it all of the above? It's certainly all of the above, as being weak in any area just drags down the ability to perform well in the other areas. Having the vision to staff broadly and design broadly is the difference between a technology vendor (IE FPGA/CPLD company) and a systems level company (that architects, designs, and implements) with both broad market and detailed systems level implementations as core architectural/design constraints. > More and more of our customers want a 'pre-baked' solution that they can > add their 'secret sauce' to (sorry for the mixed metaphor, not very > appealing...no one bakes burgers). pre-baked is just another word for systems level requirements. > How can anyone possibly create IP for every possible application? Yet, > that is what we are being asked to do. Yep ... which is a real problem. Xilinx is too small to be a full systems level company (and isn't staffed with the vision to become one in the short term), but rather sees itself as a technology only company (a rather big fish, in a very little pond). There are ways to deal with it ... like leveraging the customer community as a broad partnership to provide the parts that Xilinx hasn't, or cann't, staff and manage well ... systems level architecture and systems level software. But that does mean that Xilinx needs to be much more customer oriented, have an open interface to cusomter community, and actively seed, support, and foster that partnership. Open source is one of several alternative models to leverage the customer community to fill in the rest of the solution to drive changes in architecture, software, and tools. > How the future may change may not be obious, but it will change. yep :)Article: 102758
Replication can help timing mostly by generating more placement freedom. Actual loading effects are minimized in modern FPGAs by buffering in the routing. Synplify will automatically perform some replication based on estimated timing, but tries to avoid increasing the area to much because that can backfire. A fanout constraint is most useful when you discover that Synplify's timing estimates have diverged from P&R results and use it surgically to force some replication. A good alternative is to use Synplify Premier which performs full placement and local routing (on singles and doubles). Timing in Synplify Premier correlates much better with final P&R so it optimizes in the right places. - Ken CTO Synplicity, Inc. srini wrote: > Hi, > My target architecture is ViretxII FPGA. I dont know whether there is > any fanout limitation or not. But I was of the opinion that a driver > having a high fanout might affect the timing in my design and I kept it > to minimum(100). I could see some synthesis notes telling that some of > the nets were replicated 'x' times bcoz of soft fanout limit of 100. I > am meeting my timing constraints with this spevs. Now, if I increase > the fanout limit to the default value of 10,000, will it affect my > timing or will there be any change in the synthesis results? >Article: 102759
Fizzy schrieb: > Hi, > > I have a cutom IP that i want to run at lest say at 80 Hz. I want to > atatch this IP to PLB Bus which has clock running at 100 MHz. The IPIF > interface provides you the Bus clock and all the required interface > signals. What are my options to make the data cross from 100 Mhz clock > domain to 80 Hz clock domain. i also need to drive 80 Hz clock from 100 > Mhz clock so the both can be synchronous. Still the same problem? But hey, what kind of stuff is running at 80 Hz? Such things are much better done in software. But to answer your your question (again). Run the 80 Hz stuff at 100 MHz and use a 80 Hz clock enable. Regards Falk > > Thanks >Article: 102760
Hi All, Let say I have one bank in V4 device with all single ended outputs and one differential output. I'd like to have VCCO =3.3V. This is not allowed in V4, because obufds_33 doesn't exist in V4 and PAR ends with error. What going to happen if I'll declare all outputs in this bank as LVCMOS_25 and LVDS_25, but physically connect VCCO to 3.3V on board? Will it damage the device? Probably I'll get some out-of-spec voltage levels for LVDS output. But it's fine for me. My situation is that diff output CLK signal was overlooked on the board and placed in the 3.3V bank. Board can work with single ended CLK signal but it's better to have differential. ThanksArticle: 102761
On Sat, 20 May 2006 07:48:18 +1200, in article
<446e20cb@clear.net.nz> no.spam@designtools.co.nz
"Jim Granville" wrote:
>Didi wrote:
>> Jim,
...
>> Perhaps it is about power distribution, who knows.
>
>Coolrunners are low power devices - All I could think of was
>possibly longer programming times, for more device usage, but
>that is also a stretch...
>
>That's why the TIME-LINE of failures is important.
>
>Also, Vcc shorts do not sound like any device-mapping failures, but
>do sound like ESD/latchup ....
Don't rule out manufacturing problems, I remember a short on a CPLD
(which just happened to be a Philips Coolrunner), but our clue was
the short was not permanent. turned out to be a tiny ball of solder
under a PLCC package, careful 'nudging' and heating a few pins in turn
made it melt onto an existing pad only.
Some conductive muck may have got on one batch of boards, that went to one
site as well.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Article: 102762John, you like to point out that Xilinx is not a systems company, and you probably are right. But let me also point out that I know of no company that is simultaneously good at broad-based systems and at broad-based components. Most of the system companies you mention are abominable at components. Sun and IBM never were seriously in the component business, except for internal consumption. Intel is very narrowly focused on a certain systems and a narrow components sector, as is AMD. They are both getting better and better at less and less. Xilinx is focused on programmable devices for a very wide range of systems applications, from glue logic in cell phones to telecom routers and medical / instrumentation / mil/aerospace applications. Reconfigurable computing, large on your RADAR screen, is a tiny part of our business (and attention). In order to be successful in our chosen field, we have to satisfy many conflicting requirements and many different customers. We are not perfect, but we are not as bad as you try to make us look. Peter Alfke, XilinxArticle: 102763
Ben Jones wrote: > I love the LUT6 architecture, particularly for muxes (4:1 in a single LUT, > 16:1 in a single slice, with no wasted inputs). Yep ... I was already looking at that for the RC5 cracker demo code I did last year, as it should have a much better fit and performance. Not that many LX330 devices would have equiv performance to all of dnet, assuming you can actually power the device and keep it cool fully packed. > I don't believe you get anything to cascade between slices, but a single > SLICEM will give you 256x1-bit by using all four LUTs. You can also get a > variety of dual-port configurations: up to 128x1 true dual-port, or up to > 64x3-bit simple dual-port per slice. My personal favourite: 32x2 or 64x1 > quad-port per slice (that's 1xRW and 3xRO ports). Yippie ... that is more than enough(for now) ... and the dual/quad port configurations are exactly what I've found useful in FpgaC for typical loops, one, two or three references with a writer. Being able to have both the array storage and most of the arithmetics LUTS packed into the same slice/clb really cuts down on routing requirements/delays. > It's also possible (with some degree of cunning) to create an efficient > 3-input adder in the fabric, although there is some speed penalty to this. Hmm ... interesting ... space/time tradeoffs are another area we need to spend more time looking at for FpgaC. So far that balance has been static, and favors performance in most cases. Dense packing like that could certainly be useful. One of the interesting side effects of doing bit level optimization and packing in FpgaC, is applications like the RC5 cracker end up packing both arithmetics and the barrel shifter components into the same LUT and avoids wasting inputs and logic levels (which offsets the poor/general technology mapping to some extent) ... that just gets better with LUT6s. The down side is that it get's harder to extract from the truth table possible fits to specialized logic in the slice as the truth table grows 2^n in size and the number of permutations to search does as well.Article: 102764
Hi: You may as well cross over to Atmel ATF15xx Family of CPLDs You can take advantage of Atmel's Architecture and Software to pack in twice the logic. For your application check if you have a Bus contention issue ; Are you driving a number of I/Os ? YadArticle: 102765
Atmel_PLDs_Rock schrieb: > Hi: > > You may as well cross over to Atmel ATF15xx Family of CPLDs > > You can take advantage of Atmel's Architecture and Software to pack in > twice the logic. Blablablabla. The marketing-droids are in town! Safe our kids! Regards FalkArticle: 102766
Peter Alfke wrote: > John, you like to point out that Xilinx is not a systems company, and > you probably are right. Systems companies span from embedded to super computers, both ends of which cover both ends of the Xilinx product line and target markets. The lack of systems level tools for both ends is clearly a problem in getting broader market penitration to drive chip sales. > We are not perfect, but we are not as bad as you try to make us look. Nobody is perfect, that is for sure. Speculating about futures isn't so much about making Xilinx look bad, as being objective about core limitations that impact potential success and bottom line growth for your stock holders -- and design in decisions by your chip customers. There are clear dollar limits that Xilinx can achieve as an FPGA and PLD supplier, and the huge amounts of dollars get spent for systems level tools that don't drive high volume chip sales or turn into high revenue sources (like expensive development boards, ML310 for example). That market I suspect will be the target of off shore competitors with a mean and lean agressive competitive style ... something Xilinx isn't, and patent protection for those markets will remain difficult with core patent expiration and lots of prior art. Having Intel propose chips which severely cut away at the upper end of Xilinx's market, with a large number of cores and interconnect fabric, will ultimately limit severely Xilinx DSP, communications, and specialty reconfigurable computing sales for high end applications. All markets that Intel has targeted before, and continues to. Including PPC cpu cores and communications interfaces on FPGAs puts Xilinx clearly in Intel's sights. It's not hard to figure out which of the two companies has a strong alliance with software developers to deliver systems level solutions in high volumes, or to compare the degree of openness to 3rd party developers. Being a chip supplier and a systems company is a difficult balance, as one competes with the other divisions customers either way. So there is a reason that Sun, HP, IBM, SGI had problems selling chips and systems at the same time .... and is almost certainly why Intel walks a careful line doing so as well. Even Motorola had a difficult time at it, did some spinoffs and became a systems level company. That solution, which some have used, is to spin off the chip technologies as arms length divisions, that are only partially captive, combined with licensing. So that certainly begs the question today, of where is Xilinx headed in the market with their technology given threats to both the bottom and top end that are likely. So just where and how is Xilinx going to maintain their "market share", revenue and profitability, to avoid a stock holder purge of the current Xilinx management? I don't think it's another decade of business as usual. Do you? Now is a critical time in the market, as nearly every company is trying to plot their future for the next 7 years to ride the next tech wave, before the next bubble burst in the early to mid 2010 decade. With that comes a lot of second guessing long term viability of suppliers critical to your product line and strategy, plus buying into certain technologies with are core to your product. If Intel, AMD, IBM, and some half dozen other large players are headed into the high core count highly integrated cpu business, they will run into Xilinx and Altera's patents ... where litigation or licensing may be far more expensive than purchasing 15-25% of the common stock and doing a takeover without a bidding war . That is one potential to consider, that either or both of the high end FPGA companies may go largely capitive for their IP value. Xilinx thumping around with we are taking over the world and circle the drain talk, could make the more likely, than sliding under the radar. Similar consolidation is possible at the bottom end too. Another is that Xilinx and Altera, which have been moving up into the embedded systems CPU business, go ahead find some way to expand solidly into systems businesses in one or more markets, plus sit the fence as a chip supplier to smaller systems companies in other markets. Follow the Motorola path, more or less. The current road map of expanding share holder returns by continuing to expand into Intels market, doesn't look nearly as rosey these days.Article: 102767
Lattice has released a new version of our downloadable ispLEVER Starter software, concurrent with version 6.0. Device support includes the 90nm LatticeECP2-50 and can be downloaded here: http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm Regards, Bart Borosky, LatticeArticle: 102768
I give my email address in order to get support and Xilinx feels the need to send me spam. I know it is through the support channels because I create a different address every time I use support. Every time I end up getting spam. It's not just Xilinx, I once contacted Altera because I was getting spam from a third party at an address I only gave to Altera. I don't recall using this address, tektronix.drawing@arius.com, but I don't know why I would be receiving spam from Analog Devices using it. The list goes on and on. Don't these companies realize the ill will it creates?Article: 102769
Paul Carpenter wrote: >>Coolrunners are low power devices - All I could think of was >>possibly longer programming times, for more device usage, but >>that is also a stretch... >> >>That's why the TIME-LINE of failures is important. >> >>Also, Vcc shorts do not sound like any device-mapping failures, but >>do sound like ESD/latchup .... > > > Don't rule out manufacturing problems, I remember a short on a CPLD > (which just happened to be a Philips Coolrunner), but our clue was > the short was not permanent. turned out to be a tiny ball of solder > under a PLCC package, careful 'nudging' and heating a few pins in turn > made it melt onto an existing pad only. > > Some conductive muck may have got on one batch of boards, that went to one > site as well. Good point. Replacement=works, does not always mean the removed device is faulty, the OP should verify that failure on the removed devices. I was assuming his description was precise, but you could be right... -jgArticle: 102770
Yeah, you keep posting the same question but never really tell what you are doing. Why don't you explain what the super-slow signals are being used for. Maybe you have in one of your multiple other posts about this and I don't know.Article: 102771
Peter Alfke wrote: > We are not perfect, but we are not as bad as you try to make us look. Given other Xilinx employees posturing and dissing, even in this thread, shouldn't be so thin skinned when someone provides counter points.Article: 102772
Hennesy and Patterson do not consider reconfigurable logic and their prime concern is the raw performance of general-purpose processors. Even though the techniques they describe make sense, given this goal, reconfigurable logic makes it possible to reconsider their initial assumptions, maybe coming to different conclusions. -HansArticle: 102773
"Eric Smith" <eric@brouhaha.com> wrote in message news:qhodxt90xy.fsf@ruckus.brouhaha.com... > "Marco T." <marc@blabla.com> writes: >> You can use also emac from opencores, but in this way you don't have any >> kind of support in your design. > > The OpenCores Ethernet MAC seems to work fine. > > It's very large, though. I think it should be possible to design a much > smaller one, by using a simple microprogrammed controller to replace much > of the hardwired logic. (I'm not complaining; getting a functional > Ethernet > MAC core for free is very nice.) > > Eric, you are right. It's a great thing getting a fully functional emac core for free. Opencores is a wonderful site, and also all developers which have contributed to it. But if you decide to put that emac core into your design and you find some errors, you can't contact the assistance. It is a trouble if you don't have the necessary time to solve by yourself. MarcoArticle: 102774
"bart" <bart.borosky@latticesemi.com> schrieb im Newsbeitrag news:1148084503.179769.316340@j73g2000cwa.googlegroups.com... > Lattice has released a new version of our downloadable ispLEVER Starter > software, concurrent with version 6.0. Device support includes the 90nm > LatticeECP2-50 and can be downloaded here: > http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm > > Regards, > Bart Borosky, Lattice > are XP devices now suported in schematic? antti
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