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
Hal, Good point. We have a customer who sits there idle until their 40 Gb/s of traffic bursts in upon them, and then they switch packets like crazy. I think they went from 0 to 22 amperes on 13 devices in 10 useconds (and I think the only reason in was useconds was there was 20K uF of caps to lessen the surge! and the dv/dt). For any bursty type of situation it is recommended to scramble the data so it is always transistioning, even when idle. Either that, or be prepared to spend a lot of time designing the worlds best power supplies. Austin Hal Murray wrote: > [context is picking regulator chips] > > >Avoid parts that say things like "high speed" as the FPGA is not an > >Intel chip, and doesn't require 20 amperes in 100 ns. > > Doesn't that depend upon the design? Seems reasonable to me > for the supply current to swing wildly. Consider a high speed design > that uses clock enables to conserve power. That could bang-bang > in a big way. Either the regulator has to track the usage or > you have to have a big pile of caps to do the work. > > Even if the current is steady once the FPGA gets going, you still > have to get over the transient of next-to-nothing to full load > when the chip comes out of configuration. > > If your load fluctuates, it's worth double checking the regulator > transient response. DC-DC "brick" type converters often have > troubles in this area. (Thank goodness that all the data sheets > I've looked at recently at least have some data.) I think it's > basically a hard problem. I haven't checked the fine print > for linear regulators recently. > > I got burned with a low-dropout regulator a couple of years ago. > Maybe it was ultra-low. It worked if I added enough dummy load. > Without that, it shutdown when I ran a test pattern with the clock set > within a particular frequency range. I never did underestand it, > even with some help from an apps guy. > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 43051
Hi,
I am attempting to use the automated TOPS option for the automated
Amplify flow. I've been able to synthesize the design and run
place and route in Xilinx, but when I attempt to back annotate the
xilinx guide file and re-optimize the design using Amplify I get the
following error:
'xcbackanno.c:8066 Error: Error in generating the physical database'
Has anybody attempted to use the automated Amplify flow? Any
suggestions ?
PS. I have tried this for both Virtex and Spartan family parts...
--
Everard
Article: 43052First, a preliminary question. Several people have noted that the PCI cores from Xilinx and Altera are both hard macros, and they don't have source. But with the Xilinx version for example, can I still get in with FPGA Editor and edit it manually? This is what I'd expect to do anyway by way of tweaking - I think that the kinds of tweaks we might need to do to get the PCI cores to work right in our device would be at the hard-macro level anyway. So as long as I could do this, the fact that both vendors supply only hard macros wouldn't be a real obstacle. In article <3cd77d21.0@news1.mweb.co.za>, "Victor Schutte" <victors@mweb.co.za> wrote: .. >- What is your profit margin (cost for components, manufacturing, marketing, >storage, shipping etc... +Profit)? It'll be very much like many new technologies: initially, quite high. Then, as adoption spreads, it will go much lower with much higher sales volumes. >- What is your time to market?... Well, the sooner we can get it to market, the better, but we're not willing to rush development along in the name of earliest possible market entry, only to release a product that screams "beta" - buggy, slow, unreliable, riddled with incompatibilities, etc. What we really care about is delivering maximum value to the customer - and customers expect products that work first time, every time, with a minimum of installation, that don't break down in a day, or a month, or a year, and that have high performance. In other words, customers aren't satisfied with anything less than absolutely turnkey. >- Is it very important that you have some control over your market (e.g. >some weird 273.6 point FFT (joke) that will keep your edge). Everybody has >some form of PCI bus interface, so if they want to copy it they can. Are you concerned about the possibility that someone will intercept the configuration bitstream and steal our IP? I don't think this is something you can prevent (at least, prevent people from trying) if you've got a hot technology. It is therefore incumbent on us to focus aggressively on continued development, releasing new, upgraded versions of the technology that make the old one obsolete before the clonemakers have a chance to enter anything but the commodity phase of the product's life cycle. As long as we continue to produce new generations that are better performing, lower-priced, and wider use than the previous version, we can stay ahead in supplying maximum value to the customer. >- Do you want to play? Do you want your company to fork out $xxx for a nice >new tool to play with FPGAs (I did that about 6 years ago) By "play" do you mean just general experimentation without a definite end goal? Assuming this definition, playing can be very productive and lead to new product ideas as well as determining some of the more unusual idiosyncracies of your parts. For the moment, I think, we need to focus on finishing development of our first product, but there will be an appropriate time for play in the future. By "tool" do you mean one of those nice FPGA proto boards like the ones DINI Group makes? Or do you mean new software? I don't think price would be an issue. We would look at it from a standpoint of value - i.e. What can the tool do for us? as opposed to How much will it cost? I'll admit that I've not been super-impressed with any of the S/W tools I've seen to date, but then again, it's hard for me ever to be satisfied with software. >- Do you want flexibility? FPGAs gives you this but with PCI you might >design yourself into a corner. Are you saying that typically the nature of the PCI cores you can find tend to be so touchy that even relatively small modifications to them tend to make them not work? If so, it may be just as well to get a PCI core developed from the ground up. I see much reduced development time, however, if we can modify an existing core. >- What is the life cycle of your product? ... I think the technology and basic device will have a very long life cycle, but the specific hardware version might have a short life cycle - perhaps even as short as months. >- Play devils advocate. What if somebody like me saw your product and wanted >to copy it?... As I said, I don't think this is something you can or should try to prevent. If you've got a good enough product to be worth copying, someone will copy it. And that's good. Each time a new clone enters it will expand our market, make it closer to a standard, and give the customer greater value through increased access to the technology. From our perspective the most important thing to do is design a product which has the most room for enhancement as new silicon and technologies become available, i.e. one designed with a view to the future so that we can proceed with our strategy of staying ahead on the technology curve. >- How complex are your other functions? ... You will >sometimes find that most of these functions can be bought off the shelf for >cheaper than one FPGA. Some of them will be *very* complex, far, far more complex than what you're likely to find in a typical off-the-shelf integrated chip. >- What are you views on IP protection? If I see a PCB with a configuration >EPROM I see something that can be copied and pushed on the grey market. You've seen it all above. If they want to duplicate the hardware slavishly, they probably can. If they want to intercept the configuration bitstream, they probably can. I think we can to a certain extent always have a head start on technology development, however, simply because as the original developers we're always going to have a slightly better or more complete grasp of the theory and implementation and be able to come up that much more readily with useful enhancements. >- Do you have investers? An intelligent invester will recognize that money >has to spent wisely and time/cost effectively... Are you really asking "Do you have investors that are looking over your shoulder every time you turn around and expect short-term results?" If so, that's the kind of investor we would never want. An investor whose only concern is ultimately how much money he will make in the short term is someone with no actual belief or commitment in your company and who will only cause bad blood and possibly delay introduction of your technology with constant demands for updates and "progress". I don't call that an investor. That's a speculator. *Real* investors (such as we have) have 2 main traits: First, they're prepared to wait many years (at least 10) for a technology in its infancy to mature and grow their initial investment into a solid company. Second, they're prepared to contribute in ways other than financial to help you succeed - and this doesn't mean simply sending in the MBA's. It means making some sort of personal contribution in whatever way thay can. These kind of investors don't pester you with constant "how soon?" questions. Rather, they ask, "how can I help?" >- Do you really understand the complexity of FPGAs? I can design a complete, working FPGA configuration at the low level, i.e. at the level of setting LUT values or routing pass transistors. >... Designing a FPGA into a new product, especially >one that you aim to sell zillions of, is very much like investing in the >stock market (you know the ability of performance but you cannot guarantee >it nor investor confidence). People investing money (or worse your boss) >might not be interested in: "oops, we need one more LUT" or "we cannot >tristate this pin because of .....". What I hate is that the documentation for all FPGA's is invariably incomplete, so that they never mention certain things that you have to do or not do a certain way. Very much the "oh, we've seen strange behavior if you don't have a pullup on xxx pin" or, "well, you actually have to have 3 adjacent blocks in order to do that". In other words, a major disconnect between information you can have when making a design and information you need to succeed in making a design. Even more irksome is the vast gulf between the S/W tools and the hardware capabilities of the device. Why can't a manufacturer release a tool that lets you set any valid configuration on the chip that the hardware will allow, regardless of if the manufacturer thinks that would be useful or logical? All the strategic banter I've heard from many respondents is useful food for thought, but still, I'd like to see if somebody can address my original question. By and large we've thought through the strategy quite carefully. What we need is more technical, practical advice: Has anyone out there acutally used PCI cores, who can give us good/bad opinions on the cores they've tried? Alex Rast arast@inficom.com arast@qwest.netArticle: 43053
Luis Cupido wrote: > > Hi, > > Although I use the 7000s and 3000s devices trouble less... > I'm still trying to find a way to use the > old altera 7000 devices (the non JTAG devices... I mean), as I do > have some stock and for the low-end applications they are just fine. > > I've tried to find out the information on how to program these, and > altera don't give the programming info (only sells the programming > hardware), > and it seems that nobody out there knows how ! > > I've tried to find a cheap (2nd hand) programmers (ebay and etc) but > no luck. All the MPU stuff that shows up never have the PC card... > And never find any third party programmer available... > > Programming info? > or a low cost 2nd hand programmer? > Any help out there ! They show up on my eetools TopMAX, but that is not an 'old' programmer, and it also works well, so you are not likely to find many 2nd hand :-) ( maybe a failed startup auction ? ) -jgArticle: 43054
In article <TKVC8.106$Kg.116730@news.uswest.net>, Alex Rast <arast@inficom.com> wrote: >First, a preliminary question. Several people have noted that the PCI >cores from Xilinx and Altera are both hard macros, and they don't >have source. But with the Xilinx version for example, can I still get >in with FPGA Editor and edit it manually? This is what I'd expect to >do anyway by way of tweaking - I think that the kinds of tweaks we >might need to do to get the PCI cores to work right in our device >would be at the hard-macro level anyway. So as long as I could do >this, the fact that both vendors supply only hard macros wouldn't be >a real obstacle. How much tweaking would you want/desire? I'm assuming that, since the hard macros force the pins, the rest of the layout ends up being nice and constrained along the interfaces. What sort of tweaking would you actually consider doing? >Well, the sooner we can get it to market, the better, but we're not >willing to rush development along in the name of earliest possible >market entry, only to release a product that screams "beta" - buggy, >slow, unreliable, riddled with incompatibilities, etc. What we really >care about is delivering maximum value to the customer - and >customers expect products that work first time, every time, with a >minimum of installation, that don't break down in a day, or a month, >or a year, and that have high performance. In other words, customers >aren't satisfied with anything less than absolutely turnkey. This directly issues the ASIC vs FPGA tradeoff, and the size of the FPGA you would use. Small FPGAs (eg, Spartan II 300) are relatively cheap and have some other nice properties (namely, low inventory costs), so that, combined with the lower NRE cost, end up being quite nice, until you start talking considerable volume of ASICs Large FPGAs, on the other hand, are HIDEOUSLY expensive, so may not be that useful outside the small quantity, high markup section of the market. >Are you concerned about the possibility that someone will intercept the >configuration bitstream and steal our IP? I don't think this is something you >can prevent (at least, prevent people from trying) if you've got a hot >technology. Virtex II can (but is pricey, and I'm not sure what glue you need outside to do 5V PCI), or at least make the obstacle pretty damn high (extracting the value of SRAM cells). >>- Do you want flexibility? FPGAs gives you this but with PCI you might >>design yourself into a corner. >Are you saying that typically the nature of the PCI cores you can >find tend to be so touchy that even relatively small modifications to >them tend to make them not work? If so, it may be just as well to get >a PCI core developed from the ground up. I see much reduced >development time, however, if we can modify an existing core. The problem is the couple of asynchronous paths, as well as pin constraints which may occur. >>- What is the life cycle of your product? ... >I think the technology and basic device will have a very long life cycle, but >the specific hardware version might have a short life cycle - perhaps even as >short as months. Tends towards FPGAs, from the inventory view. >>- Play devils advocate. What if somebody like me saw your product and wanted >>to copy it?... >As I said, I don't think this is something you can or should try to >prevent. If you've got a good enough product to be worth copying, >someone will copy it. And that's good. Each time a new clone enters >it will expand our market, make it closer to a standard, and give the >customer greater value through increased access to the >technology. From our perspective the most important thing to do is >design a product which has the most room for enhancement as new >silicon and technologies become available, i.e. one designed with a >view to the future so that we can proceed with our strategy of >staying ahead on the technology curve. Or patent things enough and sic the lawyers on them. >>- What are you views on IP protection? If I see a PCB with a configuration >>EPROM I see something that can be copied and pushed on the grey market. >You've seen it all above. If they want to duplicate the hardware >slavishly, they probably can. If they want to intercept the >configuration bitstream, they probably can. I think we can to a >certain extent always have a head start on technology development, >however, simply because as the original developers we're always going >to have a slightly better or more complete grasp of the theory and >implementation and be able to come up that much more readily with >useful enhancements. I don't think large scale gray market cloning should be TOO much of a problem: with good inventory control and distribution on your side, bogus product should be fairly recogniseable: Simply serial number everything, both the boards AND the configurations, and you should be able to track the leaks of configuration and cloners. >*Real* investors (such as we have) have 2 main traits: First, they're >prepared to wait many years (at least 10) for a technology in its >infancy to mature and grow their initial investment into a solid >company. Second, they're prepared to contribute in ways other than >financial to help you succeed - and this doesn't mean simply sending >in the MBA's. It means making some sort of personal contribution in >whatever way thay can. These kind of investors don't pester you with >constant "how soon?" questions. Rather, they ask, "how can I help?" Where do you find these investors? I could use a few. >What I hate is that the documentation for all FPGA's is invariably >incomplete, so that they never mention certain things that you have >to do or not do a certain way. Very much the "oh, we've seen strange >behavior if you don't have a pullup on xxx pin" or, "well, you >actually have to have 3 adjacent blocks in order to do that". In >other words, a major disconnect between information you can have when >making a design and information you need to succeed in making a >design. Even more irksome is the vast gulf between the S/W tools and >the hardware capabilities of the device. Why can't a manufacturer >release a tool that lets you set any valid configuration on the chip >that the hardware will allow, regardless of if the manufacturer >thinks that would be useful or logical? For the tool point: they have in the past, and you could do that now (XDL allows PIP level manipulation, so does Jbits, just in programatic ways), but it is actually pretty useful: The routing fabrics are so rich and so fast that, within a very small epsion, an automated tools is as good as the best human designer. So actually doing routing-level manipulations are mostly (not completely) useless. Placement, on the other hand, is a HUGE issue, and the vendors are pretty weak about supporting this (*cough* Xilinx Floorplanner *cough*). Worse, they are still stuck in the simulated annealing placement model, which I've ranted about enough. Similarly, the HDL toolflows support retiming, but not C-slow retiming, which ends up being a pretty simple fudge on conventional retiming. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43055
Hello ! I'm a beginner, so don't blame me for my ignorance ;) I need a 4 bit subtractor/adder. I've found adsu4 in schematic libraries, I can see it uses 4 CLB with carry logic configured as FORCE-F1, ADDSUB-FG-CI, ADDSUB-F-CI and EXAMINE-CI. After reading XAPP013 note I can see that 4 bit adder can be done with only 3CLB, if I don't need overflow output, using ADDSUB-G-F1, ADDSUB-FG-CI and ADDSUB-F-CI. 1. Am I right ?. Is it possible with 3CLBs ? 2. If so, are there any schematics macros I've overlooked ? 3. Have can I make such lowlevel designs usng VHDL ? How to instantiate carry logic blocks/ FMAPs in VHDL ? 4. How to instantiate RAM16x1 in VHDL ? -=Czaj-nick=-Article: 43056
There are some notes on building XC4000 counters on my website: http://members.iinet.net.au/~daveb/tricks/counter/counters.html Przemyslaw Wegrzyn <czajnik@czajsoft.pl> wrote: :Hello ! :I'm a beginner, so don't blame me for my ignorance ;) : :I need a 4 bit subtractor/adder. I've found adsu4 in schematic :libraries, I can see it uses 4 CLB with carry logic configured as :FORCE-F1, ADDSUB-FG-CI, ADDSUB-F-CI and EXAMINE-CI. After reading :XAPP013 note I can see that 4 bit adder can be done with only 3CLB, if I :don't need overflow output, using ADDSUB-G-F1, ADDSUB-FG-CI and :ADDSUB-F-CI. : :1. Am I right ?. Is it possible with 3CLBs ? :2. If so, are there any schematics macros I've overlooked ? :3. Have can I make such lowlevel designs usng VHDL ? How to instantiate :carry logic blocks/ FMAPs in VHDL ? :4. How to instantiate RAM16x1 in VHDL ? : :-=Czaj-nick=- :Article: 43057
Hi Hari, I'm having the same problem, except that I'm trying to install Foundation 2.1 (not 3.1). The workaround you mentioned is only applicable to 3.1 (since there is no ...\ce\jre\1.2 subdirectory anywhere with 2.1). Is there anything I can do to be able to install 2.1 on the machine with P4? Thanks, Greg Hari Devanath <harid@xilinx.com> wrote in message news:<3CBDDFDB.AD7B52B@xilinx.com>... > VAggelis, > Pentium 4 Processors were not available when Foundation 3.1i Software > was released, and this solution has not been fully tested by Xilinx. > Please refer this Answer for a work around: > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10634 > > Hope this helps, > Hari. > > Vaggelis Tripolitakis wrote: > > > Hello ppl , > > > > I 'm trying to install Xilinx Foundation 3.1 (Licensed version) on a > > P4 machine and during the installation it crashed repeatedly showing > > the following error : > > > > "java.exe Application error...." > > > > I tried to install Foundation 4.1 and it worked OK but I don't have > > a license version...So anyone can help ? > > > > Thanks in advance > > > > Vaggelis Tripolitakis > > Undergraduate Student > > Microelectronics & Hardware Lab > > Technical University of Crete > > GreeceArticle: 43058
I'm trying to locate an EEPROM equivalent to the X17S100A (OTP used for the Spartan2-100). Do you have any recommendations? TIA, YenArticle: 43059
Is there such component as dual port asynchronus fifo ???
I need to write(from time to time) to fifo on clk_in = 30MHz and read
from separate output(continuosly)with clk_out = 20MHz.
Maciek
Article: 43060In <3CD9BD2E.5884EE44@xilinx.com>, Peter Alfke wrote: > One reason we are not too eager to volunteer these numbers is that they > often are being abused for a strange purpose, namely to calculate Mean > Time Between Failure (MTBF). > There still exists a misguided opinion, especially in military circles, > that transistor count directly affects (un)reliabilty. Nothing could be > further from the truth. Transistors well inside the chip hardly ever > fail, I/O transistors are far more likely to fail. > > To say that an FPGA which may have many times more transistors than a > Pentium, would therefore be less reliable is a naive oversimplification > at best, total nonsense at worst. > (Now you heard my biased opinion). > > At the upper end, we are still well below 1000 million transistors ( a > billion in the US, a milliard in Europe). That should not be too > surprising: A 20 x 20 mm chip obviously has an area of 400 million > square microns, and a logic transistor is smaller than a square micron. > > Peter Alfke, Xilinx Applications > ================================ From a system reliability point of view the transistor count in an FPGA should be divided by 50 to give a fair comparison to microprocessor, i.e. an FPGA with 100 Million transistors should be about as reliable as a microprocessor with 2 million transistors. The reason for this is that any one FPGA pattern only uses 2-5% of the transistors in a device (FPGAs are mostly interconnect and only a very small percentages of the possible interconnect paths are used in any one design). In systems that load multiple patterns into the FPGAs the number of "used" transistors increases correspondingly and the reliablity decreases. The extreme example of this is an ASIC emulator where an unlimited number of patterns is loaded into it's FPGAs. In that circumstance it's fair to say that a 100 Million transistor FPGA is comparable to a 100 Million transistor microprocessor.Article: 43061
Maciek wrote: > > Is there such component as dual port asynchronus fifo ??? > I need to write(from time to time) to fifo on clk_in = 30MHz and read > from separate output(continuosly)with clk_out = 20MHz. > Maciek Cypress make a few stand-alone fifo chips, iirc.Article: 43062
"Maciek" <mkazula@elka.pw.edu.pl> schrieb im Newsbeitrag news:abj512$esc$1@julia.coi.pw.edu.pl... > Is there such component as dual port asynchronus fifo ??? > I need to write(from time to time) to fifo on clk_in = 30MHz and read > from separate output(continuosly)with clk_out = 20MHz. > Maciek Xilinx has some app-notes with source code for this. Also Core-Generator supplies asynchronous FIFOs. -- MfG FalkArticle: 43063
> > Is there such component as dual port asynchronus fifo ??? > > I need to write(from time to time) to fifo on clk_in = 30MHz and read > > from separate output(continuosly)with clk_out = 20MHz. > > Maciek > > Xilinx has some app-notes with source code for this. Also Core-Generator > supplies asynchronous FIFOs. Thx, I found it. Maciek > > -- > MfG > Falk > > > >Article: 43064
Anthony - I asked our marketing group for the details. Here it is. - Ken McElvain CTO, Synplicity Inc. > Yes, Synplicity does have a special promotional price > of $3,995 for a PC (Windows) locked, single-vendor, > one-year license of Synplify. This price does include > maintenance for the year. Also for an extra $1,000 > ($4,995) you can add HDL Analyst which is a graphical > HDL code analysis package. This price is "single- > vendor" meaning you can chose ONE of any of the > FPGA vendors we support including Xilinx. At the end > of the year the license and maintenance will expire. > > We are currently planning to run this promotion through > the year (2002), but it is subject to change at any time. > Since Xilinx is no longer offering the FPGA Express > product we wanted to provide an easy, cost-effective > way for these users to try Synplify. Please call your > Synplicity sales rep for additional information. They > can be found at: > http://www.synplicity.com/contact/offices.html Anthony Ellis wrote: > Hi, > Can anyone confirm that the Synplicity/Xilinx special promotion of $3995 for > Synplify and $1000.00 for HDL Analyst is a "one-year time based license" i.e > it will only be useable for one year?? > > Thanks Anthony > > >Article: 43065
Hi all esp. Phil and John, This is my first experience dealing with FPGA programming. I'm still scrutinizing my state machine, and it's part of higher-level block. I have performed synthesis with Leonardo Spectrum (however, the report said the max clock was lower than what I expected), then I just proceeded to Quartus for place-and-route, and not surprisingly I got the timing violations (for setup time and clock-to-output time) at several nodes. I got a bit frustrated but nevertheless I proceeded to perform post-synthesis (or post-place-and-route) simulation with ModelSim using the output files from Quartus (*.vho and *.sdo), just being curious to see what would happen. Surprisingly, I got the expected ouput (or behavior) of my design. There are some glitches though, but I noticed it didn't disturb the whole thing. Can anyone give comment about this? Does it mean that my design will work (I haven't downloaded the design to the chip)? To John, I'm interested in your 'self memo' about registering the counter. Is it possible for you to show your revised code here? TIA, RobertArticle: 43066
Several questions: How wide (# of bits ) and how deep (#of addresses) is your FIFO? Are the 20 and 30 MHz clocks generated from one 60 MHz master clock, thus phase synchronous, and do you have access to that 60 MHz clock? Are you willing and able to do some creative design, or do you want a ready-made solution that is less efficient? Why am I asking this? If you have a dual-port RAM, e.g. in Virtex devics, the FIFO design itself is trivial, but you must still create the exception flages, Full and Empty ( and perhaps Almost Full or Almost Empty.) This is all taken care of in the ready-made solutions. In your case, if 20 and 30 MHz are phase-locked, the control can be much simpler, but it takes a bit of logic- and timing-design and analysis to take advantage of it... Peter Alfke, Xilinx Applications Maciek wrote: > Is there such component as dual port asynchronus fifo ??? > I need to write(from time to time) to fifo on clk_in = 30MHz and read > from separate output(continuosly)with clk_out = 20MHz. > MaciekArticle: 43067
"Peter Alfke" <palfke@earthlink.net> wrote in message news:3CDDA3C6.DE490D0C@earthlink.net... > Several questions: > How wide (# of bits ) and how deep (#of addresses) is your FIFO? > Are the 20 and 30 MHz clocks generated from one 60 MHz master clock, thus > phase synchronous, and do you have access to that 60 MHz clock? > Are you willing and able to do some creative design, or do you want a > ready-made solution that is less efficient? Peter's solution is definitely useful, but if you have a larger FIFO depth requirement, you could try www.free-ip.com and look at the RAM library. Sadly no longer updated, but the fifo package includes a hybrid that puts a small asynchronous buffer FIFO ahead of a synchronous FIFO for simpler control. What makes this site better IMHO than several of the other (excellent quality ) open core sites is that their licence for use is simple, not at all onerous and not confusing. PaulArticle: 43068
Austin Lesea wrote: > Jim, > > The actual drive delay difference from one IOB to the next IOB is less than +/- 20 ps (using the > clock tree to adjacent IOB FFs) in this family of parts. > > Now that's a figure I've wanted to know for a week or so - to make some DDR differential clocks (or even diff HSTL) in a Virtex-E and save an external component. . Is it worst case figure ? Moral: You can always learn something even from someone else's arguments :-))Article: 43070
Hi, I made 6502 IP core to use in my class,
and I would like to release this core with GPL license.
See and enjoy with it.
http://shimizu-lab.dt.u-tokai.ac.jp/pgm/m65/index.html
Naohiko Shimizu
------------------------------------------------------
m65 - 6502 instruction compatible micro processor
Copyright (C) 2002-
Naohiko Shimizu <nshimizu@keyaki.cc.u-tokai.ac.jp>
m65 is provided as a synthesizable soft IP core under GPL.
The description language is SFL and can be synthesized for
any FPGA such as ALTERA or Xilinx. When synthesized for
ALTERA FLEX10K series, it will fit within 600 logic cells.
I successfully complied for a FLEX EPF10K10LC84-3.
When compiled for a gate array, it will use under 4000 gates.
If you want to try the core, you sould download PARTHENON tools
from NTT WEB page. (It is free for non-commercial use)
http://www.kecl.ntt.co.jp/parthenon/
Because this IP core is covered with GPL2, if you make
any products with this IP core, you should provide your
source code and/or schematics for the users, freely.
See the COPYING file for more details.
Anyone who wants other license, or VHDL version,
please contact me:
Associate Prof. Naohiko Shimizu
Dept. Communications Engineering,
School of Information Technology and Electronics,
Tokai University
1117 Kitakaname, Hiratsuka-city, 259-1292 Japan
Emal: nshimizu@keyaki.cc.u-tokai.ac.jp
URL: http://shimizu-lab.dt.u-tokai.ac.jp/
TEL: +81-463-58-1211(ext.4084)
FAX: +81-463-58-8320
The documents:
README.TXT: This file
COPYING : License document (GPL2)
The logic is consisted with:
inc16.sfl : 16bit PC incrementer
alu65.sfl : ALU logic
data65.sfl: Datapath logic of MPU
m65.sfl : Control logic of MPU
m6502.sfl : 6502 compatible soft IP core
m6505.sfl : 6505 compatible soft IP core
m6502chip.sfl : Bidirectional databus version
Simulation environment is provided with Lee Davison's EhBASIC
After you installed PARTHENON, you can run the simulator "seconds"
and input "basic.run" as a command. After 45000 cycles simulation,
the script will dump the Lee's BASIC output strings in hex format.
basic.sfl : Simulation main logic
basic.run : Simulation main script
instring.dat: BASIC command inputs script
o64tohex : o64 to hex conversion script
od2hex.awk : od dump to hex file conversion
*)monitor.rom : BIOS, interrupt vectors based on Lee's monitor
*)basic.rom : Lee Davison's EhBASIC ROM image
*) These two files are not covered with GPL,
see the license on the Lee's page:
http://members.lycos.co.uk/leeedavison/index.html
And for his EhBASIC,
http://members.lycos.co.uk/leeedavison/6502/ehbasic/index.html
Synthesized demo code:
The demo m6505's address space is restricted for 10bit,
though it has 12bit address lines. (The SFL source code
have 16/12 bit addressing capability.)
m6505/m6505.tdf : Converted TDF from the synthesized EDIF file
m6505/m6505.sym : Symbol file for m6505
m6505/m6505chip.gdf : Demonstration for make a real chip.
This code is free software IP; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Article: 43071
"Robert O. Taniman" wrote:
>
[snip]
> To John, I'm interested in your 'self memo' about registering the counter.
> Is it possible for you to show your revised code here?
Hi Robert,
Sure. I also make use of the idea from swier about default output
values at the top of the case statement, you'll see what i mean from the
attached code. It's still pretty long but you'll see quickly what it's
doing. Ask if you'd like some clarification.
Cheers,
John
-- begin RAM_WRITER.VHD
-- A Simple SRAM output driver. 8 bit data are clocked in and written
to
-- a 32K SRAM attached to the CEB, OEB, WEB, A and D lines
-- Each successive byte is written to the next address, up to 0x7FF
-- WEB, CEB and OEB are all active low RAM control signals
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity ram_writer is
Port ( reset : in std_logic;
clk : in std_logic;
strobe : in std_logic; -- data ready on the input
d_in : in std_logic_vector(7 downto 0);
en : in std_logic;
ceb : out std_logic; -- active low chip select
oeb : out std_logic; -- active low output enable
web : out std_logic; -- active low write signal
a_out : out std_logic_vector(14 downto 0);
d_out : inout std_logic_vector(7 downto 0));
end ram_writer;
architecture Behavioral of ram_writer is
-- the output address pointer register
signal pointer,pointer_next : integer range 0 to 32767;
-- a signal variable to tell us if we need to update the pointer
signal pointer_update : std_logic;
-- same setup for the data register
signal data,data_next : std_logic_vector(7 downto 0);
signal data_update : std_logic;
-- possible states for my state machine
type state_type is (init,ready, latch, write1, write2,
update, finished);
-- registered state variable
signal cur_state, next_state : state_type;
begin
-- convert the internal pointer to a std_logic_vector and hold it on
the
-- address bus. Can do this because we are the only bus driver
a_out <= conv_std_logic_vector(pointer,15) ;
-- state update process. State also includes the address pointer
-- and latched input data
state_reg:process(reset,clk)
begin
if(reset='1') then
cur_state <= init;
pointer <= 0;
data <= (others => '0');
elsif(clk'event and clk='1') then
if(en='1') then
-- normal state progression
cur_state <= next_state;
-- update the auxilliary state variables if necessary
if(pointer_update='1') then
pointer <= pointer_next;
end if;
if(data_update='1') then
data <= data_next;
end if;
else
-- hold in init state if en='0'
cur_state <= init;
end if;
end if;
end process;
-- state transition process
state_update:process(cur_state,strobe)
begin
-- setup default outputs and control signals before the CASE block
-- by default there are no aux. state variable updates
pointer_update<='0';
data_update <= '0';
-- RAM control signals
web<='1';
oeb<='1';
ceb<='1';
-- Don't drive the data bus
d_out <= (others => 'Z');
-- Now that actual state transitions
case cur_state is
when init =>
--reset the pointer
pointer_next <= 0;
pointer_update <= '1';
-- and data
data_next <= (others => '0');
data_update <= '1';
next_state <= ready;
when ready =>
if(strobe='1') then
-- latch the data off the input
data_next <= D_in;
data_update <='1';
next_state <= latch;
else
next_state <= ready;
end if;
when latch =>
next_state <= write1;
when write1 =>
-- assert the data bus and strobe the RAM
d_out <= data;
web <='0';
ceb <= '0';
next_state <= write2;
when write2 =>
-- hold the data stable to avoid glitching the RAM
d_out <= data;
next_state <= update;
when update =>
-- increment the pointer
if pointer<32767 then -- don't wrap past top of RAM
pointer_next <= pointer+1; -- increment the address for next
time
pointer_update <= '1';
next_state <= ready;
else
next_state <= finished;
end if;
when finished =>
next_state <= finished;
end case;
end process;
end Behavioral;
Article: 43072Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<abefie$lrb$1@newsreader.mailgate.org>... > > Assume that you got 4 modules, module_a.v, module_b.v, and > module_c.v, module_d.v. > To prevent module_b and module_c from being flattened, the following > constraint file should prevent it. > > ___________________________________________________________________________ > begin module_b > > attribute keep_hierarchy of module_b : entity is "yes"; > > end module_b; > > > begin module_c > > attribute keep_hierarchy of module_c : entity is "yes"; > > end module_c; > > ___________________________________________________________________________ > What if within module_b, there are two other submodules: module_x and module_y. Will their hierarchy be preserved too or flattened? Is the format in the constraints file the same for the submodules? > > To get the rest of the design flattened, just uncheck the Keep Hierarchy > option under Synthesize -> Properties -> Xilinx Specific Options or > Synthesis Options. > In this case, module_a and module_d should be flattened automatically. > Note that if you use a lot of blackboxes in your design (i.e., > Using netlisted IP cores.), it might be better not to flatten the design > at all because I have seen XST dropping valid FFs from a design. > It took me 2 days to track down the problem, and the only way I solved > it was by looking at the EDIF file, and play around with synthesis > options. > Eventually, I notice that if I didn't flattening the design, the problem > didn't occur. > I believe this was a bug of XST, and if there is any doubt, always check > the EDIF file XST generates. (If you are using XST Ver. D or older. The > latest XST Ver. E generates only an encrypted .ngc file.) > Thanks for the info. This will really help me a lot. Regards.Article: 43073
Edzel wrote:
>
>
> What if within module_b, there are two other submodules: module_x and
> module_y. Will their hierarchy be preserved too or flattened?
> Is the format in the constraints file the same for the submodules?
>
I believe if you don't specify whether or not you want the
hierarchy preserved by attaching a 'keep_hierarchy' synthesis attribute,
then XST will use the global keep hierarchy option instead.
The global keep hierarchy option is, of course, located under Synthesize
-> Properties -> Xilinx Specific Options or Synthesis Options.
If I want to add the keep hierarchy option to module_x and module_y, in
addition to module_b and module_c, here is how it will look.
___________________________________________________________________________
begin module_b
attribute keep_hierarchy of module_b : entity is "yes";
end module_b;
begin module_c
attribute keep_hierarchy of module_c : entity is "yes";
end module_c;
begin module_x
attribute keep_hierarchy of module_x : entity is "yes";
end module_x;
begin module_y
attribute keep_hierarchy of module_y : entity is "yes";
end module_y;
___________________________________________________________________________
Just because module_x and module_y will be instantiated by module_b, you
will still have to have a separate "begin ... end" statement for each
module, and they won't be nested within module_b.
So, to answer your second question of whether or not the syntax is the
same for the submodules (instantiated modules), I believe the answer is
yes.
Regards,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43074Hi satya i don't think such an FPGA exists. any how try this link www.gecocities.com/dsredy3/link.html enjoy maadi regards MPS
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