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
Blackie Beard wrote: > > Nothing to say about it except that Verilog rules. It takes 1/3 > the typing to get stuff done, and it's more intuitive and easier > to read. VHDL looks clunky, whereas Verilog looks like C. > Oh, but you are not trying to start a war, here, are you? We already have a Xilinx vs. Altera war going on. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48201
hamish@cloud.net.au wrote: > > Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > > hamish@cloud.net.au wrote: > > : Still waiting for v5.1 to arrive. Upgrading all machines to Win2000 in > > : anticipation. > > > > For a start, use the free downloadable Webpack, which is based on 5.1. > > Does it do 2V6000s? I'd guess not! Does that really matter? Do you really expect to be targeting a part in a week or two? You can do a lot of work under Webpack before you have to do P&R. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48202
Neil Franklin wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > That brings us back to one of my points. > > The open source tools will *never* be up to date. The chip cycle is > > just too short for a bunch of freeware guys to keep up with. > > Xilinx still sells XC4000/Spartan. After that came XC4000XL/Spartan-XL, > then Virtex/Spartan-II, then Virtex-E/Spartan-IIE, then Virtex-II, now > Virtex-IIpro. > > That makes 6 families being sold in parallel. Actually 3 large families, > with each 2 subfamilies. Looks like an active sales life of about 10 > years for one particular family. > > So any tool supporting Virtex/Spartan-II in say 1-2 years, and extendable > to Virtex-E/Spartan-IIE, has at least an 5 year market life in it. > Reverse-engineering Virtex-II should not take 5 years, so we can keep up... You are working from the wrong end. No one cares about what tools will support a chip after it has been on the market after 2 years. By that point all the *major* new designs that are going to be done with it *have* been done and every thing else is maintenance. At that point the *new* designs will be on the *new* parts which the open source tool will not support. So if you want to be guaranteed to be behind the cutting edge, then by all means use tools that are perpetually out of date. > > who say it is inevitable. But we never see the tools... > > You can now see an actual project, started, that has an planned out > path leading to tools. I did check out the web site and I am not clear about where it is going. Can you explain in terms that an FPGA engineer can understand? > > > When my tools arrive, it is going to be Xilinx that profits (because I > > > started from JBits out). And any extra chip they sell because of them > > > will be the best "thanks" (dollars, not words) I can give them for > > > enabling my stuff. > > > > And when can we expect this tool? > > First minimal stuff in estimated 1 years time, decently usable in 2 > years, is my current estimate. > > > What devices will it support? > > Initially Virtex/Spartan-II (what JBits does), later Virtex-E/Spartan-IIE. > > > What > > will be *better* about it than the tools already in use? > > All that in open source is better: > > - simple download/compile/install/use, any computer/OS native don't care, I only use one OS and that will be what the tool is compatible with. I'm an FPGA engineer, not a SW engineer. > - no licensing, can give copy to anyone. allows "config&compile at > customers site" designs, and yes, that includes "customer selects > modules and generates bitstream that runs them" style adaption to > modular interface hardware (see recompiling Linux kernel as an example) don't care. X and A both give away tools and the paid for versions are affordable in the context of running a business. > - bugs can be fixed by anyone, or more likey have already got fixed > before you ever hit them, even OpenBSD style code audits go If that is true, then that will be a plus. X and A tools have quite a few bugs in them and they never really get fixed, they are just substituted for other ones. > - guaranteed to remain available (because user-adaptable to new > systems ad infinitum), no forced upgrade cycle No one forces you to upgrade. Many engineers stay with a given version all the way through a design or several designs. Just read here about Xilinx 5.1. Many are choosing to stay with 4.x for now. > - anyone can add their brains to development, wherever they have the > expertise (compare the open process of science vs pronouncements > from high from any closed governing body) don't care. I want tools to use to do work, not tools I can work on. > For such features many (including myself) are willing to sacrifice > using the latest chip family for the time needed to reverse-engineer, > dito also not wringing the last drop of power out of an chip. Many does not include the majority of FPGA engineers, IMHO. In the FPGA world you have to work with the best chip for the job and that is often the most current chip. > > > And in the embedded market (more similar to FPGAs than desktop PCs > > > are) we see 8051s from various cloners (with different feature sets) > > > and official Intel tools vs open source ones. > > > > This has also been discussed before. Compilers have become commodity > > items where one is about as good as another for 99% of the work done > > with them. FPGA software is still in the stage of being very highly > > tuned to the chip else it is of little value. > > FPGAs are newer than CPUs, they are bound to be at an earlier stage in > the normal industrial process from novelty to mature technology. I don't know how this is relevant. You are carrying an analogy outside of its usefulness. > Screws from one manufacturer once did not fit nuts from an other, > about 120 years ago, due to everyone using their own threads. Once the > basic issues and design space in thread design were explored, standards > came. Bad analogy. It was in the best interest of the dozens or hundreds of manufacturer's interests to be compatible. Just as chip vendors have to work with the same power supply voltages and signal levels. But X and A have no reason to use the same tools. Ask them, they will tell you... It is a competitive advantage for them to have their own tools so they can be better than the competition's. > > If you are doing simple > > designs in uncrowded chips then you don't care what tools you use, but > > most FPGA users push their designs if not initially, they do when being > > upgraded in the field. They need tools that work very well with their > > chip. > > How many today forgo the ultimate performance of FPGA Editor in favor > of the simpler life with VHDL or Verilog? > > How many forgo the power increases of floorplanning for less work? > > How many are going to soon start using things like Handel-C because > programmer time costs more than chip space (in small series work)? > > There exist "ultimate power" users, and they will demand "ultimate > power" tools (and pay for them). There also exist less demanding users > who will put up with an less powerfull tools if they offer them an > better deal for their particular circumstances. > > It is horses for courses. Not sure what that means, but I have seen $1000 FPGAs go on a board. If they had known that they would need a $2000 chip, the board would have never been designed. Tools are important and good tools are essential. > > > I expect an similar open/wide/basic vs vendor/power/complex split in > > > FPGA tools. And yes, at the prices of top end FPGA tools (5-digit-$), > > > and the cost structure of their paying customers, they should be able > > > to do this. > > > > You can expect what you want, but that won't make it happen. There are > > very few engineers that are going to start a significant project with > > open source FPGA tools when their company will pay for the commercial > > tools. > > Some companies can expect an >5-digit profit increase from 5-digit > tools. They will stay with them (stupid if they did not). Others can > not expect such added profits, they already today do not afford them > (they are those that today demand free Webpack&so on). So? Few if any significant companies can't afford the low end tools that will get the job done. Not all tools are 5 figure. In fact very few are. What is your point? > > You make a lot of predictions that won't be tested for 10 years > > or more. > > Anyone planning on shaping the future has to make predictions. The > best we can do is look for similar cases. CPUs, in particular > embedded/DSP are the nearest case. It happened there. When it happens with FPGAs I will be happy to use the new tools... but I expect to be retired by then. :) > > Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit > > tools (unless you are counting the pennies). The expensive tools are > > the synthesis and simulation tools. > > I was talking of those. And you can live a rich full life without the $10,000+ tools. Right? > > These are third party and they > > charge so much because they are so good. > > And all the better for their makers, an for those users (their > customers), that can convert such tools into the profit that can pay > for them. > > They prove my point: vendor tools will not die (that was your claim) > just because open source tools appear and reduce user count of vendor > tools. Vendor tools can survive in that market. I am not talking about Synthesis and Simulation. I am talking about the back end tools. If Xilinx loses > 50% of its tool market to open source or third party tools, I expect they will drop their inhouse tools. They would have to either cut their tool staff by half which would ruin their tools in the future or start charging more for the chips to make up the differernce which would make it harder for them to compete. So sucessful open source tools will drive FPGA vendors out of the tool market. Then they would have to compete on just the chips and be a driving force somehow with the tools. > > But this is the first place > > that open-source tools should show up. > > Why? Those that can pay have no needs. They are satified (nice for them). > > Those that can not pay have needs. Those that want open stuff have > needs. And those that are unsatisfied are those that will experiment > with new stuff, and accept the costs of working with untried stuff. > > All the interfaces are defined > > in public standards, the functionality is known, all that is needed is > > the open source code. So where is it??? Where are the open source > > synthesizers and simulators? > > You are forgetting the most important part of open source: motivation. > It takes a lot of it. To accept sacrifice of the time to make software > without pay. That motivation must come from somewhere. Look for the > "somewheres" if you want to know where to look for the first appearances. Why would anyone be more motivated to develop backend tools? What is their value without the front end tools? > > they are much more like the gcc target. But the back end tools are very > > different. *That* is why there are no third party back end tool > > vendors. > > They are software, like all other. I.e. designs to be specced, lines > of implementing program code to be written, work time to be spent. > That process is well understood. I am glad that you think *all* software is the same. Technology is a matter of solving problems, not writing code. If you don't have good agorithms, you code will be lousy. Writing code is the *easy* part. Developing the algorithm is the hard part. > > > > FPGA tools > > > > are a moving target and very different from software development tools. > > > > Every new generation of FPGAs require very different software. > > > > > > So did every generation of CPUs in the days when every generation had > > > an new instruction set. Today it is less work, because we have binary > > > compatibility and improvement goes into making the existing "bitfiles" > > > (read: binary applications) move faster. > > > > As soon as the x86 came out (~1981, IIRC) the basic instruction set was > > cast in concrete. About 5 years later compilers matured and by 1991 > > they had become commodities. > > 8086 was 1977 or 78, 8088 one year later. 386 was an massive update, > nearly a new architecture, around 1984. Neither were particularly > compiler friendly. > > But I expect 5 years "catch up" to be realistic for FPGA tools. > > > > I expect FPGAs will have to go the same route: mass market with binary > > > compatibility, cloners[2], etc and an more diversifed "specialist" market > > > where everything goes, for max performance, at high price. > > > > Patents will stop cloners. There is no market force driving FPGAs in > > this direction, just as there is no market force driving all CPU makers > > to adopt a common instruction set. > > Huh? I never said "all" CPUs, nor did I say all FPGAs. I clearly > stated 2 markets, "mass" and "specialist". What is your point? NO ONE can make a Xilinx compatible FPGA except Xilinx. NO ONE can make an Altera FPGA except Altera... Just ask Clearlogic. :) > > > The Virtex vs Spartan split already points in that direction. Think of > > > an non-compatible max-power series of Virtex-II, -III, -IV, -V and an > > > Virtex(-I) compatible staying low cost line of Spartan-II, -IIE, -IIEM, > > > -IIX, -II? as an possible future. > > > > I'm not sure what you mean by this. Are you talking about a competitor > > chip? Xilinx won't let that happen... > > No I was pointing out an possible development path for Xilinx. If > binary compatible becomes important, they can play with it. > > You claimed that binary incompatible is neccessary, and as such will > break tools, I pointed out that binary compatibility is possible in this > market, just as it turned out to be in CPUs, and sketched what its > result could look like. How is compatibility necessary in CPUs or FPGAs? It only exists in the x86 world because the cat is out of the bag. With other processors, it is not available unless you pay a license fee. Just ask the student who developed the ARM core HDL. Notice you can't get it anymore... > > > [2] Think of the next Clearpath with the same size relationship to Altera > > > or Xilinx that AMD has to Intel. And aiming for full pin and bit compatible > > > SRAM based chips (not mask based specials). Drop in replacement, like an > > > AMD K6 (what I am typing this on) fitting an Pentium I socket. And an > > > power/price race ensuing, fought on process technology and feature. > > > > I think you mean Clearlogic... and they have gone the way of the dodo > > bird because of infringement issues. > > And those were infringment on the software licenses on the Altera > devel tools used to make the bitstreams that 100% of all their > customers would be sending them. > > It is interesting that Altera did not chose the direct course of > attacking them with their patents on the actual chip technology. That > they needed to use such an indirect method of helping users breach the > the devel tools software license, which is less likely to succeed in > court, is telling us a lot. You are talking about making chips, now you are talking about the tools. What are you talking about? THERE WILL BE NO BITSTREAM COMPATIBLE CHIPS!!! > > AMD could make parts that fit the Pentium socket because they had a > > license for that. After Socket 7 (IIRC) they no longer had that license > > and they now have to make their own interfaces. > > Socket 7 did not require any license. It is only with Slot 1 and later > Socket 370 that Intel introduced an patented signalling protocol (not > pinout) which required an license that they then refused to AMD. The > pinout is copyable, but useless it one can implement the signalling. No, you are confused. Socket 7 required a license, but AMD and several other companies already had that license due to manufacturing agreements that Intel had set up previously. They were later interpreted to include the pinout, the instruction set and even the microcode for processors up to the 386. There are *always* licenses. You buy them or you trade for them. But they are always there... > > No FPGA company is > > going to let a startup copy their technology. > > No copying the technology is needed. Just making something compatible > with the bitstreams. May not happen, may well happen. But it sould be > kept in mind as something that could happen in an future bit-compatible > market. Again you are talking tools now when we were talking chips. > > > The "magnet" is a running bitstream, and the shortest path to that is > > > interesting. So the action starts at the back end. > > > > So you want to do the hardest part first, show the least result and have > > your work obsoleted most rapidly? > > Also known as: do the most/first needed part first, show an actually > usable result, and accept that obsolence will happen and require an > "chase the moving target" attitude. gcc did/does this (different CPUs), > Linux did/does this (different computer architectures). Sure. I disagree that the backend is needed most or first. But then it is not my decision to make. > > > I started coding 2.5 months ago. I expect to arrive at 2nd milestone > > > > > > [3] http://neil.franklin.ch/Projects/VirtexTools/ > > > > I looked at your page and I do not see where you are headed. > > See the "2.5 months" (should have been 3.5, oops) remark? > > > Once you > > have built all the parts of the intended toolchain, what will the flow > > be? > > Tentatively (subject to changes while implementing): > > Users chosen language -> compiler (3rd party, multiple) > -> design reduced to LUT-sized elements, relative placed, their connections > reduced design -> vas (from my toolset) > -> design fitted to LUTs/F5s/etc, absolute placed, connections to PIP lists > placed/routed design -> vm and libvirtex it calls (from my toolset) > -> .bit file to be used or displayed/debugged (using existing vd and vv) I don't understand any of this. What are you planning to do? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 48203
rickman wrote: > > Neil Franklin wrote: > > > You are working from the wrong end. No one cares about what tools will > support a chip after it has been on the market after 2 years. By that > point all the *major* new designs that are going to be done with it > *have* been done and every thing else is maintenance. At that point the > *new* designs will be on the *new* parts which the open source tool will > not support. So if you want to be guaranteed to be behind the cutting > edge, then by all means use tools that are perpetually out of date. Many designs want availability and cheapness instead of cutting edge. With process problems, life cycles will get longer. > > All that in open source is better: > > > > - simple download/compile/install/use, any computer/OS native > > don't care, I only use one OS and that will be what the tool is > compatible with. I'm an FPGA engineer, not a SW engineer. Irrelevant. > > - no licensing, can give copy to anyone. allows "config&compile at > > customers site" designs, and yes, that includes "customer selects > > modules and generates bitstream that runs them" style adaption to > > modular interface hardware (see recompiling Linux kernel as an example) > > don't care. X and A both give away tools and the paid for versions are > affordable in the context of running a business. Irrelevant. The tools are broken compared to what a decent open source tool would be like. > > - anyone can add their brains to development, wherever they have the > > expertise (compare the open process of science vs pronouncements > > from high from any closed governing body) > > don't care. I want tools to use to do work, not tools I can work on. Irrelevant. The tools are broken compared to what a decent open source tool would be like. > > For such features many (including myself) are willing to sacrifice > > using the latest chip family for the time needed to reverse-engineer, > > dito also not wringing the last drop of power out of an chip. > > Many does not include the majority of FPGA engineers, IMHO. In the FPGA > world you have to work with the best chip for the job and that is often > the most current chip. Rarely. The biggest latest chips have the highest profile. > > They prove my point: vendor tools will not die (that was your claim) > > just because open source tools appear and reduce user count of vendor > > tools. Vendor tools can survive in that market. > > I am not talking about Synthesis and Simulation. I am talking about the > back end tools. If Xilinx loses > 50% of its tool market to open source > or third party tools, I expect they will drop their inhouse tools. They > would have to either cut their tool staff by half which would ruin their > tools in the future or start charging more for the chips to make up the > differernce which would make it harder for them to compete. So > sucessful open source tools will drive FPGA vendors out of the tool > market. Then they would have to compete on just the chips and be a > driving force somehow with the tools. No. Internal tools can be fixed in short time if companies have a 4 digit support contract, which many will. > > You are forgetting the most important part of open source: motivation. > > It takes a lot of it. To accept sacrifice of the time to make software > > without pay. That motivation must come from somewhere. Look for the > > "somewheres" if you want to know where to look for the first appearances. > > Why would anyone be more motivated to develop backend tools? What is > their value without the front end tools? Without free chip information to make backend tools, frontend tools are useless. Compilers and fitters are fun to make. GUIs are boring.Article: 48204
rickman wrote: > > Russell wrote: > > > > rickman wrote: > > > However there is *nothing* to adapt to. There are *no* open source > > > tools that can be used on a production design. > > > > Linux and open source are only fairly new, and there's a certain > > learning curve before capable developers appear for more specialized > > tool development. Also, before jbits, creating open source tools is > > completely uninteresting if all it involves is making a pretty front-end. > > The front end doesn't have to be the *only* part, but it makes sense to > me that it should be the *first* part. The backend tool is of no value > without a frontend tool. Right now you can get by without an open > source backend because you can use the only *good* backend tool > available which just happens to be available for free. To start with > building the backend tool, you would need a good front end tool. You > could use the one from Xilinx, but I hear a lot of complaints about it > and that is where a lot of improvements can be made with much less > effort. The front end tools have a lot more in common with current > compiler technology. > > Maybe I am wrong, and I am not planning to help with any of this. So if > you no playah da game, you no makeah dah rules. So I will butt out. > > > > You can expect what you want, but that won't make it happen. There are > > > very few engineers that are going to start a significant project with > > > open source FPGA tools when their company will pay for the commercial > > > tools. You make a lot of predictions that won't be tested for 10 years > > > or more. > > > > I would start with an open source tool if there was one at the time. I'd > > also be doing bug fixes and adding *useful* features (i'm not quite up > > to that level on linux yet). > > I would submit that you would start with an open source tool not because > that would be the best for your project, but because that is what > interests you. The engineers that use these tools need to get design > work done and don't have time to improve the tools. > > > > Someone correct me if I am wrong, but Xilinx and Altera have NO $5-digit > > > tools (unless you are counting the pennies). The expensive tools are > > > the synthesis and simulation tools. These are third party and they > > > charge so much because they are so good. > > > > Leonardo-spectrum GUI good? Most of the other tools could be improved > > too. > > I don't give a rat's ass about the GUI. I care about how well a tool > works to give me usable gates. I also have never used > Leonardo-spectrum. The tools I have used may have warts, but I could > get my work done with them. That is what I care about. > > > > But this is the first place > > > that open-source tools should show up. All the interfaces are defined > > > in public standards, the functionality is known, all that is needed is > > > the open source code. So where is it??? Where are the open source > > > synthesizers and simulators? > > > > There's no motivation to do it if there's no info available for the > > low-level control of most fpgas. It would be like doing open source > > development if the only compilers available had to be bought from > > microsoft. The opcodes and assembly instructions of microprocessors > > are freely released by cpu vendors to encourage tool creation. The > > same should apply to fpgas. FPGAs have a short life cycle because > > the industry is immature. Process limits will slow this down in a > > few years, when open-source will be much more common-place. > > I don't know what motovates you, but I don't think it is the same as > most users of the tools. I would like to stop working with analogies > and hear what the game plan is. Can you give us a roadmap of how you > would procede? You compile a design a subcircuit at a time in HDL. You manually place all the primitives into a compact area, or let a fitter do it for you with suitable constraints, making an RPM. Repeat for all subcircuits. Place these RPMs into bigger groups of RPMs if needed. Place these 'mega' RPMs. Proceed up the hierarchy until the whole design is done (one big RPM). This is what webpack 5.1i should allow you to do, but i still need to try it. 4.2i was aimed there, but was broken. Naturally, a GUI is involved in the floorplanning stage, and is a suitable technical challenge for an open-source project. The fitter would also be an excellent thing to work on. I once made a pcb autorouter in dos that caused all the tracks to naturally 'coalesce' into parallel paths and minimize track lengths/bends.Article: 48205
wv9557@yahoo.com (Will) writes: > VHDL has tons of inconsistencies. > (0) component ends with "end component" > and > package ends with package name. > But I use VHDL-mode for emacs, so I never notice that sort ofthing as I never have to type them :-) > (1) in the following the first <= test for equalities , the > second is an assignment > > if a <= 2 > then a <= 2; > Granted - I've never understood that! > (2) VHDL goes all of its way to forbid you from assigning > std_logic_vector to unsigned, but then provides a zillion > helper functions to let you do it > That's because its strongly typed. if you want all your vectors to be treated as unsigned, declare them as unsigned. VHDL is not Verilog (and vice versa :-) Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 48206
"Nicholas C. Weaver" wrote: > > In article <6uadliarw7.fsf@chonsp.franklin.ch>, > Neil Franklin <neil@franklin.ch.remove> wrote: > >> >The way I do it... > > But how many man-years would it take to write a place and route tool > which would produce results roughly as good as the Xilinx one? Verses > the 1 month its availailability would have saved perhaps two dozen > researchers? It would take longer to understand the chip structure and quirks. In the end, most algorithms are really very easy to dream up. The current tools are nothing special.Article: 48207
Ahh, so that's why my CAF messages come in bursts every few days or weeks... Kevin Brace wrote: > > For some reason, Mailgate.org was down for about 5 days. > The postings I made right after Mailgate.org resumed the service didn't > seem to make it to the newsgroup, but more recent ones did finally show > up at Google's newsgroup search engine. > So, I guess Mailgate.org working OK now. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > Speedy Zero Two wrote: > > > > yep, > > I made a similar observation several months ago but never did rectify it !!! > > > > DaveArticle: 48208
On Mon, 14 Oct 2002 00:57:44 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >hamish@cloud.net.au wrote: >> >> Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >> > hamish@cloud.net.au wrote: >> > : Still waiting for v5.1 to arrive. Upgrading all machines to Win2000 in >> > : anticipation. >> > >> > For a start, use the free downloadable Webpack, which is based on 5.1. >> >> Does it do 2V6000s? I'd guess not! > >Does that really matter? Do you really expect to be targeting a part in >a week or two? You can do a lot of work under Webpack before you have >to do P&R. When you already have XC2V6000 designs working in 4.2, and you want to try them in 5.1, yes, this does matter. It's been a few years since I've done a design that was small enough to allow webpack to be used. YMMV. Allan.Article: 48209
Hello: I´m a spanish estudent, sorry for my bad english. I have created a proyect with Xilinx Foundation Series 2.1, all in VHDL. I have not create a library, I have create a package where put all the components of my proyect. BUFE8, OBUFE8, OBUF4, BUFG, IBUF, OBUF, IBUF8 are declarated like components in my package (without architecture) and after are maped in my top_myproyect.vhdl. The are two types of errors when i try to create myproyect.bit. 1) ERROR:NgdBuild:432 - logical block 'I1' with type 'BUFE8' is unexpanded. The same with the others (OBUFE8, OBUF4, ...) What happens?? Must i put other library in my proyect? 2) I have two BUFE8, both are conected in OBUFE8 and i get another error. What an i do about this? two sinals in the same in of OBUFE8? Thank you very much!!!Article: 48210
"Steve Casselman" <sc@vcc.com> skrev i meddelandet news:nDHp9.3372$IW6.286352602@newssvr13.news.prodigy.com... > Hey new joke in town: > > Question: How can both Xilinx and Altera have the "worlds lowest cost FPGA" > ? > Answer: They come from different Worlds! > > Check it out! > http://xilinx.com/ > http://www.altera.com/corporate/news_room/releases/products/nr-cyclone.html? > xy=whp1_cycpr > > Steve > I remember that the town of Kyoto has the largest wooden building in the world, while the town of Nara some kilometers away has the largest wooden building in Japan. (It might have been the other way around) Tokyo has the worlds largest Tokyo Tower... Maybe Xilinx and Altera have attended Japanese marketing training... -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 48211
Thank you for the answer. Interesting. But if the SRL16 primitive is able to lock the pins, the software tool must be able to support that kind of thing. One should think that a user-made device should be able to do the same thing. I am looking into using the SRL16 instead. I might get something to work using that instead, but it won't be as compact and "nice" as my own CLB-slice hardmacro. Asbjørn Ray Andraka <ray@andraka.com> writes: > For this case, you are only changing the LUT content and not the routing. > > You really have several options, one of which does not even require > reconfiguring the device to reload the LUT. > > 1) you can put an SRL16 in as a placeholder, then replace it with a LUT > in the reconfiguration. SRL16's (the shift register primitive in virtex > parts) lock the pin assignments, so the mapper is forced to leave them > alone. > > 2) If you can live with the minor route restrictions an SRL16 imposes > (namely, you can't use the direct set/reset to the flip-flop), you can > also leave the LUT as an SRL16. The SRL16 behaves exactly like a LUT > when the WE pin is held low. > > 3) If you do use an SRL16, you can replace the LUT contents with new ones > in 16 clocks by bringing the WE pin high and presenting the LUT contents > serially to the D pin. This gives you a capability of reloading 'LUT' > contents without actually reconfiguring the part. It is really handy for > distributed arithmetic filters where the coefficients are programmable > or in some cases for adaptive filters. > > 4) As I understand it, starting with version 4.1 there is a pin lock > constraint for LUTs similar to the MAP constraint under XACT. I haven't > used it yet, so I can't tell you how well or if it really works. I don't > believe it is in the documentation at all. > > My preference is for 3), since it gives you a capability of > reconfiguration that works in the context of the current FPGA > configuration, which means that your simulator can also handle simulating > the configuration, plus you don't have to manage multiple bitstreams. > Option 1, even though you replace the SRL16 with a LUT in the operational > bitstream, still blocks the reset pins on the flip-flops since the > routing is done with an SRL16 there. Option 2 puts the SRL16's in but > disables the shift permanently. Option 3 just adds a small amount of > support logic to allow you to shift in new LUT contents. > > The best part is that you don't have to mess with the bitstream at all > (and in fact, you don't even need to know where the LUT is placed). > > > Asbjørn Djupdal wrote: > > > Hello, > > > > I have designed a hard macro (a CLB slice) with the FPGA editor from > > Xilinx foundation. > > > > The problem is that when I instantiate this macro in my VHDL code and > > synthesize/implements the code, the input pins to the CLB slice LUTs > > are swapped. > > > > Normally, this would not be a problem, because the LUT contents are > > also changed. But I need to be able to change the LUT contents with > > special made software after the bitfile is generated, something that > > gets impossible if I can't predict how the inputs to the LUTs are > > connected. > > > > Was this question understandable? Does some of you know if it is > > possible to stop the xilinx tools from swapping these LUT input pins? > > > > Asbjørn > > -- > --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, 1759Article: 48212
In 1992 I designed a product which was a PC (ISA) card containing 32 (yes thirty two) XC3064 devices. It is basically a complicated pulse generator. Each of the devices contains the same config data. There is also an XC3030 which implemented the PC interface and some other simple stuff. The FPGA config data, for all 33 devices, is loaded from a simple program running under MS-DOS which reads in a Motorola S-record file and loads it into the card. The customer had a few of these, then came back in 1996 for some more. By then, Xilinx had almost dropped these parts and I had to redesign the card to use a TQFP version of the 3064, of a higher speed than the original one. Fortunately it still worked! I say "fortunately" because there have always been config loading problems with Xilinx parts - if you had a lot of them on a board (I last did FPGA design in 1997). They were very sensitive to the CCLK edges, not too fast and not too slow. I had to play around with different types of CMOS drivers to get the edges exactly right, and I do have a 400MHz scope. There was no explanation for this behaviour, other than the CCLK input having multi-GHz-speed and picking up non-monotonic risetimes which a 400MHz scope did not show. I never had this problem on any single-device FPGA products, which I suspect is the vast majority of FPGA applications. Also, as Xilinx parts got faster through the 1990s, the D-Q flip-flop propagation time got faster a lot faster than the interconnect delays got faster. This meant that designs which used long-lines (with some short local interconnect) for clock distribution (a method freely recommended by Xilinx in the early days) stopped working if implemented in faster parts. Eventually, one really did have to use just the global clock nets for any concurrently-clocked structures (e.g. shift registers and counters), in conjunction with the CE feature, to have any hope of reliability. An experienced Xilinx engineer confirmed this was indeed the case. The design I did has not been done "properly" as above, but once the config loaded OK, it was always rock solid. This customer now wants to buy some more of these cards. There is no way I am going to risk building some more - unless I could get the exact same parts, which I can't - because the cost of populating a card with 33 expensive parts, and finding it doesn't work properly, is just too high. I also don't have the time to do any major design work like this, so I am offering this project to somebody interested. Xilinx ran the XC3000 and XC4000 parts for a long time, but nowadays things change too fast. I will try to monitor this NG anyway but if anyone is interested in actually doing this, taking on the risk, and paying me a small % when it's all done. I would give him the original VL4 designs, which are actually pretty simple, and whatever else I have. Please email me direct on the address below. The value of the design, including a PCB redesign if necessary, is likely to be of the order of GBP 20k. The customer wants only two of the cards but last time he paid about GBP 6k each. One can either do this with a board containing 32 cheap little Atmel AVRs (which, realistically, I think is a lot better than using FPGAs if one at all can, because FPGAs keep changing, the tools keep changing; I paid GBP 13,000 for Viewlogic 4 / XACT6.01, 2 useless dongles, covering the XC3k and XC4k parts up to 1992 / 1996, etc). But on a 2-off project an FPGA is probably the best way. Preferably a common Xilinx part with a future upgrade route looking OK for another 10 years, which loads up the same way so the same PC loading program can be used. Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 48213
Hi there ... when replacing the SRAM interface OPB_MEMCON in microBlaze\examples\Memec_Design_VirtexII1000\external_sram with the ZBT interface OPM_ZBT_CONTROLLER all interface I/O pins disappear. Any hints ? AndreasArticle: 48214
The SRL16 is kind of a special case to the software. It is conceptually a 16
bit shift register followed by a 16:1 multiplexer that uses the LUT inputs as
the select code. Because of this structure, the pins can't be permuted. If
they were, the addressing would no longer track the shift tap. The software is
aware of this, and treats the SRL16 different than the LUTs. Basically, it
appears that the pin locking is present in the software, but until 4.1 there
was no user control over it. There is apparently a ucf constraint that can be
applied to LUTs to lock the pins in the recent versions of the software, but it
is not documented. You'll have to bug your FAE for the details.
I missed the fact that you are doing a hard macro. I think there is an option
there to lock the pins, but I am not sure. If you use the SRL16, there are a
few routing restrictions that may or may not fit in with your hard macro. The
restrictions are:
1) BX, BY inputs are used as the D inputs to the SRL16s. If you intend to use
the F5 or F6 muxes, then the select has to be the same as the respective DI for
the SRL16. If you never bring WE high, that is not an issue...so BX and BY are
really only a restriction if you intend to write the SRL16. Note that you may
have to jump through hoops a little to convince the tools that it is OK though
(been there, done that). In cases where you also need to write the SRL16, this
does become a restriction that can be hard to work around.
2) The SRL16 and the flip-flop have to use the same clock. The SRL16's clock
is a write clock only, so again if you are not writing the SRL16, this is not a
restriction. Even if you do write the SRL16, it just means that the write
clock has to be the same as your system clock...not a significant restriction
in most cases.
3) The slice's SR input is used as the WE to the SRL16, so it needs to be held
low to hold the SRL16 contents. This basically means that the direct set/reset
into the flip-flops is not available. Again, this is not a show stopper, but
it can be a pain in some designs.
The bottom line is that for doing pin locking, the only real restriction to
using the SRL16 instead of a LUT is that you can't use the direct set/reset.
BX/BY and clock only become an issue if you are writing to the SRL16 (which you
would do to avoid reconfiguration altogether, but not just to lock pin
locations). You nice compact hard macro is unchanged unless you used that SR
pin.
Asbjørn Djupdal wrote:
> Thank you for the answer. Interesting.
>
> But if the SRL16 primitive is able to lock the pins, the software tool
> must be able to support that kind of thing. One should think that a
> user-made device should be able to do the same thing.
>
> I am looking into using the SRL16 instead. I might get something to
> work using that instead, but it won't be as compact and "nice" as my
> own CLB-slice hardmacro.
>
> Asbjørn
>
> Ray Andraka <ray@andraka.com> writes:
>
> > For this case, you are only changing the LUT content and not the routing.
> >
> > You really have several options, one of which does not even require
> > reconfiguring the device to reload the LUT.
> >
> > 1) you can put an SRL16 in as a placeholder, then replace it with a LUT
> > in the reconfiguration. SRL16's (the shift register primitive in virtex
> > parts) lock the pin assignments, so the mapper is forced to leave them
> > alone.
> >
> > 2) If you can live with the minor route restrictions an SRL16 imposes
> > (namely, you can't use the direct set/reset to the flip-flop), you can
> > also leave the LUT as an SRL16. The SRL16 behaves exactly like a LUT
> > when the WE pin is held low.
> >
> > 3) If you do use an SRL16, you can replace the LUT contents with new ones
> > in 16 clocks by bringing the WE pin high and presenting the LUT contents
> > serially to the D pin. This gives you a capability of reloading 'LUT'
> > contents without actually reconfiguring the part. It is really handy for
> > distributed arithmetic filters where the coefficients are programmable
> > or in some cases for adaptive filters.
> >
> > 4) As I understand it, starting with version 4.1 there is a pin lock
> > constraint for LUTs similar to the MAP constraint under XACT. I haven't
> > used it yet, so I can't tell you how well or if it really works. I don't
> > believe it is in the documentation at all.
> >
> > My preference is for 3), since it gives you a capability of
> > reconfiguration that works in the context of the current FPGA
> > configuration, which means that your simulator can also handle simulating
> > the configuration, plus you don't have to manage multiple bitstreams.
> > Option 1, even though you replace the SRL16 with a LUT in the operational
> > bitstream, still blocks the reset pins on the flip-flops since the
> > routing is done with an SRL16 there. Option 2 puts the SRL16's in but
> > disables the shift permanently. Option 3 just adds a small amount of
> > support logic to allow you to shift in new LUT contents.
> >
> > The best part is that you don't have to mess with the bitstream at all
> > (and in fact, you don't even need to know where the LUT is placed).
> >
> >
> > Asbjørn Djupdal wrote:
> >
> > > Hello,
> > >
> > > I have designed a hard macro (a CLB slice) with the FPGA editor from
> > > Xilinx foundation.
> > >
> > > The problem is that when I instantiate this macro in my VHDL code and
> > > synthesize/implements the code, the input pins to the CLB slice LUTs
> > > are swapped.
> > >
> > > Normally, this would not be a problem, because the LUT contents are
> > > also changed. But I need to be able to change the LUT contents with
> > > special made software after the bitfile is generated, something that
> > > gets impossible if I can't predict how the inputs to the LUTs are
> > > connected.
> > >
> > > Was this question understandable? Does some of you know if it is
> > > possible to stop the xilinx tools from swapping these LUT input pins?
> > >
> > > Asbjørn
> >
> > --
> > --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
--
--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: 48215
This is basically what we already do with the existing tools. We build a set of
hierachical RPMs by structural instantiation with RLOCs in the VHDL, and then use
them as blocks in bigger RPMs. The tools are reasonable (sure they have warts,
but for the most part I can get the job done in a reasonable amount of time
without having to go outside the normal flow). There are some extra features that
would be nice, but certainly not essential. The weakest part of the existing
tools is the floorplanner, so if I were to identify a first hit, it would be a
hierarchical floorplanner with a capability to back-annotate to structural
source. In any event, the existing tools do support this kind of design flow.
Russell wrote:
>
> You compile a design a subcircuit at a time in HDL. You manually
> place all the primitives into a compact area, or let a fitter do
> it for you with suitable constraints, making an RPM.
> Repeat for all subcircuits. Place these RPMs into bigger
> groups of RPMs if needed. Place these 'mega' RPMs. Proceed
> up the hierarchy until the whole design is done (one big RPM).
>
> This is what webpack 5.1i should allow you to do, but
> i still need to try it. 4.2i was aimed there, but was
> broken.
>
> Naturally, a GUI is involved in the floorplanning stage,
> and is a suitable technical challenge for an open-source
> project. The fitter would also be an excellent thing to
> work on. I once made a pcb autorouter in dos that caused
> all the tracks to naturally 'coalesce' into parallel
> paths and minimize track lengths/bends.
--
--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: 48216You are absolutely right. I misunderstood your first answer (I am not very experienced with fpga design), so I got a bit confused. Doing what you suggest seems to solve my problems regarding this. Thank you very much, it was very helpful. Asbjørn Ray Andraka <ray@andraka.com> writes: > The SRL16 is kind of a special case to the software. It is conceptually a 16 > bit shift register followed by a 16:1 multiplexer that uses the LUT inputs as > the select code. Because of this structure, the pins can't be permuted. If > they were, the addressing would no longer track the shift tap. The software is > aware of this, and treats the SRL16 different than the LUTs. Basically, it > appears that the pin locking is present in the software, but until 4.1 there > was no user control over it. There is apparently a ucf constraint that can be > applied to LUTs to lock the pins in the recent versions of the software, but it > is not documented. You'll have to bug your FAE for the details. > > I missed the fact that you are doing a hard macro. I think there is an option > there to lock the pins, but I am not sure. If you use the SRL16, there are a > few routing restrictions that may or may not fit in with your hard macro. The > restrictions are: > > 1) BX, BY inputs are used as the D inputs to the SRL16s. If you intend to use > the F5 or F6 muxes, then the select has to be the same as the respective DI for > the SRL16. If you never bring WE high, that is not an issue...so BX and BY are > really only a restriction if you intend to write the SRL16. Note that you may > have to jump through hoops a little to convince the tools that it is OK though > (been there, done that). In cases where you also need to write the SRL16, this > does become a restriction that can be hard to work around. > > 2) The SRL16 and the flip-flop have to use the same clock. The SRL16's clock > is a write clock only, so again if you are not writing the SRL16, this is not a > restriction. Even if you do write the SRL16, it just means that the write > clock has to be the same as your system clock...not a significant restriction > in most cases. > > 3) The slice's SR input is used as the WE to the SRL16, so it needs to be held > low to hold the SRL16 contents. This basically means that the direct set/reset > into the flip-flops is not available. Again, this is not a show stopper, but > it can be a pain in some designs. > > The bottom line is that for doing pin locking, the only real restriction to > using the SRL16 instead of a LUT is that you can't use the direct set/reset. > BX/BY and clock only become an issue if you are writing to the SRL16 (which you > would do to avoid reconfiguration altogether, but not just to lock pin > locations). You nice compact hard macro is unchanged unless you used that SR > pin. > > > Asbjørn Djupdal wrote: > > > Thank you for the answer. Interesting. > > > > But if the SRL16 primitive is able to lock the pins, the software tool > > must be able to support that kind of thing. One should think that a > > user-made device should be able to do the same thing. > > > > I am looking into using the SRL16 instead. I might get something to > > work using that instead, but it won't be as compact and "nice" as my > > own CLB-slice hardmacro. > > > > Asbjørn > > > > Ray Andraka <ray@andraka.com> writes: > > > > > For this case, you are only changing the LUT content and not the routing. > > > > > > You really have several options, one of which does not even require > > > reconfiguring the device to reload the LUT. > > > > > > 1) you can put an SRL16 in as a placeholder, then replace it with a LUT > > > in the reconfiguration. SRL16's (the shift register primitive in virtex > > > parts) lock the pin assignments, so the mapper is forced to leave them > > > alone. > > > > > > 2) If you can live with the minor route restrictions an SRL16 imposes > > > (namely, you can't use the direct set/reset to the flip-flop), you can > > > also leave the LUT as an SRL16. The SRL16 behaves exactly like a LUT > > > when the WE pin is held low. > > > > > > 3) If you do use an SRL16, you can replace the LUT contents with new ones > > > in 16 clocks by bringing the WE pin high and presenting the LUT contents > > > serially to the D pin. This gives you a capability of reloading 'LUT' > > > contents without actually reconfiguring the part. It is really handy for > > > distributed arithmetic filters where the coefficients are programmable > > > or in some cases for adaptive filters. > > > > > > 4) As I understand it, starting with version 4.1 there is a pin lock > > > constraint for LUTs similar to the MAP constraint under XACT. I haven't > > > used it yet, so I can't tell you how well or if it really works. I don't > > > believe it is in the documentation at all. > > > > > > My preference is for 3), since it gives you a capability of > > > reconfiguration that works in the context of the current FPGA > > > configuration, which means that your simulator can also handle simulating > > > the configuration, plus you don't have to manage multiple bitstreams. > > > Option 1, even though you replace the SRL16 with a LUT in the operational > > > bitstream, still blocks the reset pins on the flip-flops since the > > > routing is done with an SRL16 there. Option 2 puts the SRL16's in but > > > disables the shift permanently. Option 3 just adds a small amount of > > > support logic to allow you to shift in new LUT contents. > > > > > > The best part is that you don't have to mess with the bitstream at all > > > (and in fact, you don't even need to know where the LUT is placed). > > > > > > > > > Asbjørn Djupdal wrote: > > > > > > > Hello, > > > > > > > > I have designed a hard macro (a CLB slice) with the FPGA editor from > > > > Xilinx foundation. > > > > > > > > The problem is that when I instantiate this macro in my VHDL code and > > > > synthesize/implements the code, the input pins to the CLB slice LUTs > > > > are swapped. > > > > > > > > Normally, this would not be a problem, because the LUT contents are > > > > also changed. But I need to be able to change the LUT contents with > > > > special made software after the bitfile is generated, something that > > > > gets impossible if I can't predict how the inputs to the LUTs are > > > > connected. > > > > > > > > Was this question understandable? Does some of you know if it is > > > > possible to stop the xilinx tools from swapping these LUT input pins? > > > > > > > > Asbjørn > > > > > > -- > > > --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 > > -- > --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, 1759Article: 48217
In our lab we'd like to add an reconfigurable module to a mobile Bluetooth-Node (BT & uC). Issues as low-power, flexibility and performance are important for us. I first thought about a CoolRunner II implementation but I think we are too limited with CPLDs. We also want to enable partial and dynamic reconfiguration where I believe that the Virtex family is leading. Has anyone used Virtex FPGAs in an low power embedded design? What system-level power saving possibilities do I have (not in the FPGA design)? Or do you have other suggestions for other components? Thanks for any help Matthias Dyer -- ------------------------------------------------------------- Matthias Dyer phone: +41-1-6327061 Gloriastr. 35, ETZ G-63, fax: +41-1-6321035 CH-8092 Zurich, Switzerland email: dyer@tik.ee.ethz.ch Computer Engineering and Networks Lab (TIK) Swiss Federal Institute of Technology (ETH) Zuerich -------------------------------------------------------------Article: 48218
Hello. Is it possible to configure a Xilinx device using the JAM player ? (the JAM player is supposed to be device-independent, isn't it ?) Thanks, Harry.Article: 48219
Hi, I am presently designing for a Spartan II using Foundation 3.3 software. We have upgrades (still in their boxes) to Foundation 4.2 aswell as ISE 4.2. We need to upgrade the software sometime as I am going to be redesigning and modifying for a Spartan IIE. My question is the following: I was under the impression the ISE was really only useful if I was going to design for Virtex. Under this understanding, will probably want to install the software for Foundation 4.2. However, I still want to use Foundation 3.3 as I am still working on the design, and am worried about the design having problems in 4.2. So what I want to do is put Foundation 4.2 onto a separate hard drive, and plug into the same system. Will I have any registry issues? Is it possible to run two versions of the Xilinx Foundation software on the same machine? Do have to do the entire Xilinx licensing thing again when I install 4.2? Finally, should I rather be install ISE instead? Thanks AdrianArticle: 48220
epson wrote:
>
> Hi Kevin
> Much thanks for your extensive reply. Sorry that I didn't describe so
> precisely my FSM sequencer, that you had to think about many possibilities
> causing my problems.I had PCI LB specification rev 2.1, and I've tried
> carefully carry about all specifications. My FSM have got B_Busy state and
> support Burst Read&Write but haven't got Disconect With/Without Data yet(and
> probably never would have).
Okay, that's good that you got the specification.
Also, that's good that you are aware of the Bus Busy pitfall.
In my opinion, all PCI devices must be able to signal Disconnect (With
or Without Data), regardless of whether or not the device is capable of
handling burst cycles because a burst configuration cycle allowed by the
specification.
Your state machine doesn't have to be exactly same as the one in
Appendix B, but should look similar.
> It turned out that the condition to change
> between Idle and B_Busy wasn't full enough. I'd been decoding AD(10..0) ,
> CBE, IDSEL and FRAME# lines but I didn't write condition which detect change
> FRAME# from 1 to 0 ( only I detected low state on FRAME# line).
> I was sure
> that IDSEL could be only asserted when FRAME# goes low, at the beginning of
> new transaction on addres phase, was it? I thought that detecting falling
> edge of FRAME# is obligatory on all others transactions except Configuration
> Access,(signal IDSEL high for me was enough)
Are you saying that you figured out the issue?
Anyhow, even for a configuration cycle, FRAME# going from high to low
signals the start of a transaction.
If you read the specification, it says that IDSEL is undefined except
during an address phase of a configuration cycle.
That's because in x86-based PCI systems, one of the bit of AD[31:16] bus
line is tied to IDSEL of each PCI slot.
> Visibly I was wrong,becouse
> that additional condition cause that my card doesn't do any conflicts.
> Perhaps TV card or LAN which are additionaly Masters, had done some actions
> which require to detect falling edge of FRAME# by my card(but I haven't seen
> that actions in PCI Specification) Lucky now that problem's gone:)
My new theory (The previous theory of why your PCI device was
crashing was wrong because you already had a bus busy cycle.) of why
your PCI device is crashing will be that, because you were not watching
for FRAME# assertion, but instead was looking at IDSEL, when the crash
occurred, likely AD[10:0], C/BE#[3:0], and IDSEL (Tied to one of the bit
of AD[31:16].) just happened to match the combination you were looking
for during a data phase of some other device.
When that happens, your device will mistakenly start a transaction,
leading it to a crash.
> Your post give my attention to many problems which earlier I haven't take so
> seriously. Until now I haven't seriously take care about timing parameters,
> especially Tval, which in my PCI core is about 15ns(in Post P&R simulation).
> Could you explain me more precisely using FFs(Flip-Flops??) with Clock
> Enable to get right Tval? In my project synthesis generate latches for AD
> signals with direction from card to PCI, and after them there are Tri-State
> IOBUFT_PCI33_5. What do you think about it?
I probably shouldn't have brought up about the CE FFs at this
point because it probably confused you somewhat.
The trick to meeting Tval < 11ns is to use IOB FFs (output FF and
tri-state control FF).
The problem of using the IOB FFs is that almost all of the time, you
need to get the synthesis tool to handle the task.
The tricky part is that, in order to get a FF to be pushed into an IOB,
the FF needs to have fanout of 1, but that will make it difficult to
retain the value of the FF.
The problem can be solved by letting the synthesis tool duplicate the FF
so that you got one getting pushed into the IOB, and the other one
letting you retain the value (Creating a feedback loop to a LUT, and
back to the two FFs. Of course, the feedback loop can be the input of
other LUTs or FFs.).
This posting by me should explain how to do it in case you are using XST
as the synthesis tool.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=cc7b0b5f.0210081256.22ba2b1f%40posting.google.com
In order to utilize the IOB output and tri-state control FFs,
let the synthesis tool duplicate the ones you already got in your VHDL
code.
There is no need to make modifications to your VHDL code.
The real problem of meeting timings is meeting Tsu < 7ns, and
that's where using the CE FFs helps for AD[31:0].
Hold time requirement (Th <= 0 ns) can be easily solved by using IOB
input FFs, and that's not too difficult.
But again, don't waste too much time trying to get the timings right at
this point since this is a course project (Finish up the rest of the
design, and then worry about it.).
> As I said in previous post I'm
> not experinced in programmable logic, I had only few xilinx .pdf (one about
> webpack4(for beginers) and spartan2 documentation) and two books about
> writting in VHDL read yet.
I used ISE WebPACK throughout the development of my PCI IP core.
There really is no need to pay for expensive tools like Synplify in my
opinion for your project.
> I've got another questions for you.Signals SERR# and INTx# are o/d(open
> drain).Could you tell me if I can use OBUFT_PCI33_5 to drive them?? I
> haven't seen output that type yet.
Here is an example in VHDL (I don't use VHDL myself.).
INTA_n <= 'Z' when INTA_n_OE = '1' else '0';
SERR_n <= 'Z' when SERR_n_OE = '1' else '0';
The above code says, if INTA_n_OE is 1, keep the tri-state buffer
tri-stated, but if INTA_n_OE is 0, drive INTA_n low.
The same thing for SERR_n, too.
In Spartan-II, the tri-state buffers are active high tri-state or active
low OE (Output Enable).
The above tri-state buffers will get converted to OBUFT by the synthesis
tool.
I personally don't recommend using Xilinx specific library primitives in
your HDL code, unless you really have to.
Instead I recommend using the generic VHDL tri-state buffer, and specify
the I/O buffer type in a .UCF file.
That will make your code more portable.
> And last thing, when software wants to do Memory Read Access, but my card
> "knows" that for many clocks it couldn't establish transaction,because it's
> busy(in high speed writting samples from analog/digital converter to SRAM
> memory).Is good way then ignore initiator and don't assert DEVSEL# & TRDY#
> although that addres&command is right?
> Memory Access C++ functions, which
> I'm going to use in my software, returns some value when transaction was
> failed or didn't established.
>
> Many thanks Kevin,
> Regards
> Leszek
Nope, don't ignore the transaction even when the PCI device
isn't ready.
Signal Retry (DEVSEL# = 'L', TRDY# = 'H', STOP# = 'L') to the initiator
if your PCI device isn't ready to return the data requested.
If you don't, the host will abort the transaction (Master Abort), and
will set the host's Received Master Abort to 1.
When that happens, the device driver isn't supposed to repeat the
transaction because the target didn't respond.
It sounds to me, the better way to handle this issue is to signal an
interrupt when your PCI device is ready.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 48221
I mostly agree, but some minor additions.
In article <3DAA5782.D3869B5@yahoo.com>,
rickman <spamgoeshere4@yahoo.com> wrote:
>Many does not include the majority of FPGA engineers, IMHO. In the FPGA
>world you have to work with the best chip for the job and that is often
>the most current chip.
OR it is the cheapest chip possible, in which case one wants really
good quality because of the resource constraints.
>> Some companies can expect an >5-digit profit increase from 5-digit
>> tools. They will stay with them (stupid if they did not). Others can
>> not expect such added profits, they already today do not afford them
>> (they are those that today demand free Webpack&so on).
>
>So? Few if any significant companies can't afford the low end tools
>that will get the job done. Not all tools are 5 figure. In fact very
>few are. What is your point?
Also, lets face it, the NRE time to design just a board to do what you
want it to is fairly substantial, let alone the FPGA chip.
WHen you are paying the engineers $50k/year, so they cost you
$100k/year, you aren't going to blanch at the ~$1000 for the back-end
xilinx tools.
Even front end tools at $10k are going to be "Will this, over the
project lifetime, save you 10% of your time? Yes? Good, here you
go."
>> You are forgetting the most important part of open source: motivation.
>> It takes a lot of it. To accept sacrifice of the time to make software
>> without pay. That motivation must come from somewhere. Look for the
>> "somewheres" if you want to know where to look for the first appearances.
>
>Why would anyone be more motivated to develop backend tools? What is
>their value without the front end tools?
And back end tools are LESS valuable, as they cost less, generally
work better, and don't have very many interesting problems anymore.
And if you want to do open source synthesis, you don't touch the
back-end, you jsut feed it to the Xilinx/Altera P&R flow which have
nicely documented interfaces.
>I am glad that you think *all* software is the same. Technology is a
>matter of solving problems, not writing code. If you don't have good
>agorithms, you code will be lousy. Writing code is the *easy* part.
>Developing the algorithm is the hard part.
Ohh, strongly disagree. Developing the algorthms and proving the
concepts in code is the easy part (its prototyping), its turning or
recreatingthat code into something robust an widely usable thats hard,
IMO.
>How is compatibility necessary in CPUs or FPGAs? It only exists in the
>x86 world because the cat is out of the bag. With other processors, it
>is not available unless you pay a license fee. Just ask the student who
>developed the ARM core HDL. Notice you can't get it anymore...
Or they made a strategic decision to make it avaiable, because their
market doesn't cover small/embedded generally (SPARC).
>> Also known as: do the most/first needed part first, show an actually
>> usable result, and accept that obsolence will happen and require an
>> "chase the moving target" attitude. gcc did/does this (different CPUs),
>> Linux did/does this (different computer architectures). Sure.
>
>I disagree that the backend is needed most or first. But then it is not
>my decision to make.
I'll second this. Front end tools cost more. Most of the room for
improvment is in the front end.
Place and route and bitgen and static timing analysis are really just
boring crud needed to get the parts to work.
{flow munched}
>I don't understand any of this. What are you planning to do?
Back end tools. Starting with bitgen and working backwards.
Oh, where was static timing analysis?
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 48222I am trying to link several CLKDLL components in order to create a frequency divider. I am getting an error message that "Period specification references the TNM group, which contains only pad elements. Only synchronous elements are permitted in a period specification...." How should I set the period constraints when I am linking several CLKDLLs?Article: 48223
"Sanjay Patil" <sanjay@cg-coreel.com> schrieb im Newsbeitrag news:aodgq3$ksn7h$1@ID-164436.news.dfncis.de... > Hi Group > I have a question regarding the implementation through VHDL flow. > My target chip is spartan 2. > Question is : How to assign clk through startup while implementation. ??? What do you excatly mean? > I want to use manual clock. > If I use an external clock . how to interface it to the chip. Just connect the output of a canned oscillator to an clock input (Spartan-II has 4 of them) What kind of homework is this? -- MfG FalkArticle: 48224
If you want to use an external clock, you should use one of the dedicated global clock pins (GCK0, GCK1, etc.). Determine which GCK pin you want to use and then lock your system clock to that pin using the .UCF file.
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