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
I've polished off the xr16vx microcontroller in JHDL, and posted it, along with tools, tests and documentation: http://www.easystreet.com/~mbutts/xr16vx_jhdl.html xr16vx is a 16-bit microcontroller design for FPGAs, which I've released as open source programming under the GPL. Including memory, serial and parallel ports and a timer, it fits in only 29% of a Xilinx Spartan-II XC2S100-5, at up to 39 MHz. xr16vxcpu implements the xr16 16-bit RISC instruction set architecture of Jan Gray: http://www.fpgacpu.org/xsoc/README.html Jan's xsoc package includes an assembler and ANSI C compiler for xr16 based on lcc. My xr16vxcpu runs at one cycle per instruction, except taken branches and loads used next cycle. It takes advantage of the dual-ported BlockRAM to fetch instructions and data in parallel. xr16vx is written in JHDL, a set of Java classes and tools for FPGA design developed at BYU: http://www.jhdl.org/release-latest/docs/overview/intro.html In JHDL you do register-level design but without synthesis. I've found JHDL a very satisfying development environment, and am getting slightly better speed and area than I got in Verilog with FPGA Express. Since the xr16vx microcontroller is completely contained in the FPGA, you can write a C program for xr16vx, init the BlockRAMs with it in the EDIF file, and thus have the application built into the bitstream, executing at power-up. I include some tools I wrote to make doing this easy. Thanks to Jan Gray's xsoc, BYU's JHDL and Xilinx WebPACK ISE, the entire design flow for xr16vx is available on the Web at no cost. I've developed xr16vx myself on my own time, because I love FPGAs and I love CPU design. I hope students, experimenters, and anyone on a limited budget will find xr16vx useful. --MikeArticle: 32576
"marco" <mpriarone@tiscalinet.it> wrote > has anyone tried to implement one on the free cpu cores available on the > net on a spartan2 with an external sram ? Free6502 works o.k. with external SRAM. Maybe you have to clock the SRAM faster if you use pipelined SRAM as the CPU expects valid SRAM data on the next rising_edge of CPU clock. A 166 Mhz pipelined SRAM ISSI IS61SP25618-166TQ works well if the cpu is clocked at 1/4 SRAM clock. AndreasArticle: 32577
Bugger. Oh well, a MUX replacement it is, then.Article: 32578
Phil Hays <spampostmaster@home.com> writes: > There isn't much you can do in a TTL package that you can't do in 8 CLBs, and > the XC2S150 has 800+ CLBs. Smaller would probably be more than enough This brings up something I still don't have a good feel for. If a TTL pack is equivalent to an average of four Spartan-II CLBs (just to make a wild-ass guess), and the XC2S150 has 800 CLBs, how likely is it that I can cram a design that had 200 TTL chips into the XC2S150? In other words, how many CLBs are going to go to waste due to insufficient routing resources? I know that's going to be different depending on floor planning, but I haven't yet been able to even come up with a rough rule-of-thumb sort of estimate. I'm playing with the XC2S200 using the BurchEd board, and I haven't run out of space yet, but my designs aren't very big yet either.Article: 32579
Mike Butts <mbutts@realizer.com> writes: > I've polished off the xr16vx microcontroller in JHDL, and > posted it, along with tools, tests and documentation: > http://www.easystreet.com/~mbutts/xr16vx_jhdl.html I see that you've released it under the GPL. While I am a big advocate of the GPL for software, I'm not sure I'm 100% certain I understand the implications for hardware. Is it your intent that If I ship a product incorporating an FPGA or ASIC containing your core, that I must be willing to provide all the design files for the FPGA or ASIC? Or the design files for the entire product? For software, the issue is usually a matter of linking, and Stallman claims that dynamic linking does count, but the GPL specifically excludes operating systems and standard libraries. In other words, if I link a GPL'd program on Solaris, it doesn't mean that the Solaris libraries become GPL'd, or that I have to offer my customer source to those libraries. So if I put your core in an FPGA, along with more hardware of my own design, is the core analagous to a operating system or standard library? Note that I am asking these questions for clarification. Nothing I am asking or stating should be construed as any kind of complaint. I fully respect your right to license the code under whatever terms you consider appropriate. Best regards, EricArticle: 32580
Hi Eric, Thanks, I'm glad you raised the question. Legally, the GPL says what it says, and my opinions here don't have any legal bearing on the question. Having said that, I'm not 100% certain I understand GPL's implications for hardware either. But in my opinion, the xr16vx source code isn't hardware, it's software, programming for an FPGA. I don't see the difference between programming for an FPGA and programming for anything else. You load bits from some storage into electronic circuits, which then work accordingly. If someone translated xr16vx into another form and used it in an ASIC design, then that's permanent hardware, not programming. I doubt very much anyone would do that, for the simple reason that building an ASIC is very expensive, and it's foolish not to use commercially developed and supported IP which is optimized for ASICs. As for whether xr16vx is analogous to an OS or stdlib, that's a lot less clear. Maybe it's like a library, but it's hardly standard. Maybe it's not like a library in that it's fully useful on its own. By the way, I see the OS exclusion in the GPL, but where is the one for standard libraries? I considered using the Lesser GPL instead, but I like Stallman's arguments against its use for free software: http://www.fsf.org/philosophy/why-not-lgpl.html Since I wrote xr16vx in that spirit, I've licensed it under the GPL. So if someone uses xr16vx in an FPGA in a product, as I understand the GPL, it says the product's FPGA source must be available. By the way, these are my own personal opinions, which apply only to this xr16vx work. They're not necessarily the opinions of my employers, who pay me good money in my day job to develop proprietary EDA tools for proprietary hardware developers, which is also a good thing in its place. I believe there's room in the world for both models. Thanks again. --Mike Eric Smith wrote: > I see that you've released it under the GPL. While I am a big > advocate of the GPL for software, I'm not sure I'm 100% certain > I understand the implications for hardware. > > Is it your intent that If I ship a product incorporating an FPGA or ASIC > containing your core, that I must be willing to provide all the design > files for the FPGA or ASIC? Or the design files for the entire product? > For software, the issue is usually a matter of linking, and Stallman > claims that dynamic linking does count, but the GPL specifically > excludes operating systems and standard libraries. In other words, if > I link a GPL'd program on Solaris, it doesn't mean that the Solaris > libraries become GPL'd, or that I have to offer my customer source > to those libraries. > > So if I put your core in an FPGA, along with more hardware of my own > design, is the core analagous to a operating system or standard library? > > Note that I am asking these questions for clarification. Nothing I > am asking or stating should be construed as any kind of complaint. > I fully respect your right to license the code under whatever terms > you consider appropriate.Article: 32581
I should also have reminded in my previous posting that, regardless of the license on xr16vx, the xr16 instruction set architecture and XSOC tools that xr16vx is based on are copyrighted by Gray Research LLC and subject to the XSOC license. See http://www.fpgacpu.org/xsoc/README.html --MikeArticle: 32582
> This brings up something I still don't have a good feel for. If a TTL > pack is equivalent to an average of four Spartan-II CLBs (just to make a > wild-ass guess), and the XC2S150 has 800 CLBs, how likely is it that I > can cram a design that had 200 TTL chips into the XC2S150? In other words, > how many CLBs are going to go to waste due to insufficient routing > resources? The smart design point of FPGAs is an FPGA that does not have wnough routing. The argument is like this: Consider a fully routable FPGA. The silicon area of this device is going to e something like 4% Logic, 6% configuration space and 90% routing. (Estimates by Andre DeHon). This means that for about 5% area penalty you can double the number of LUTs. Of course most of the time you will not be able to use all of them due to limit routing, but they are essentially free and for some designs they might be really useful. The problem is that marketing could not make that point to customers. They felt, that they had paid for all the LUTs and they wanted to use them. (This of course is not true, in FPGAs you pay for routing, not LUTs) So routability become one of the main marketing aspects of FPGAs and the Manufacturers put insane amounts of rounting ressources on the chip. I have not seen routing problems in a long time. Especially for smaller parts of larger families you have routing in abundance. Students of mine finished a project that used 798 LUTs out of 800 on a XC4010XL without floorplanning. Spartan2-200 might have some problems, because it is the larges part of its kind, but the routing architecure is based on Virtex which was designed for much larger chips... > I know that's going to be different depending on floor planning, but > I haven't yet been able to even come up with a rough rule-of-thumb > sort of estimate. Anyone seen Spartan-II routing problems??? Kolja SulimmaArticle: 32583
Hello. Does anyone happen to know what the closest Xilinx alternative is to the Altera EPF10K100E FPGA? TIA! PaulArticle: 32584
Hi all, can anyone please help on what is the proper technique on using the locked signal of a PLL/DLL as a reset for an FPGA. I tried to look for papers on the web that deal with that, but hadn't had much success... many thanks in advance Nir DahanArticle: 32585
Just finishing my first design and using an XC9572-PC84. I have a clock input (PHI) which goes to a bufg primitive, and then that feeds a couple of AND gates. Problem is, when I run the software to get a file to burn, I get the following message: WARNING:nd201 - Removing unused input(s) 'phi'. The input(s) are unused after optimization. Huh? Unused? Don't think so. I have an input marker called PHI, a wire going to the input of a BUFG, a wire going from that output, then 2 AND gates. Hardly unused. I removed BUFG and substituted BUF. Same thing. Then I removed BUF and just had a wire going from PHI pad to the AND gates. Still the same thing. Why is this removing what appears to be a perfectly valid pin? I've tried replacing the pad - no difference.Article: 32586
I've downloaded the Xilinx WebPack software, and am having problems with PAR for Spartan-II: EXEWRAP detected that program '__prepar.bat' completed successfully. Starting: 'par -f __par.opt jc.ncd jc.pcf ' fatal error(0011): An attempt was made to load a program with an incorrect format. Unable to run the process due to a system error. Done: failed with exit code: 0011. I notified Xilinx support about this some days ago, but haven't had any response. Has anyone else had this problem? Leon leon_heller@hotmail.comArticle: 32587
In article <upgrjt0auhdc19kfi5ek8iorvcqs1rg47u@4ax.com>, brian@shapes.demon.co.uk says... > On Fri, 29 Jun 2001 14:44:27 -0400, Keith R. Williams > <krw@attglobal.net> wrote: > > >In article <gr7mjt0b652u7ujjinhehq6r714bdr5n9i@4ax.com>, > >brian@shapes.demon.co.uk says... > >> On Wed, 27 Jun 2001 09:13:20 -0400, Keith R. Williams > >> <krw@attglobal.net> wrote: > >> > >> >In article <9hb26c$jav$1@slb6.atl.mindspring.net>, > >> >austin@da98rkroom.com says... > > >> >> map -pr b filename > >> > > >> >I've tried all of the above and it still appears the flops aren't > >> >getting pushed into the IOBs (this is a XCS40XL-BG256). Map reports: > > >> > >> map -pr b doesn't always map IOB flops. > > >Polarity? Ouch! My style is everything inside the package is > >positive, controls I design (I'm stuck with what I buy) outside the > >package are negative (hang over from years of TTL design). Isn't that > >why I'm using a HDL? Isn't that why the boss plunked down $50K for the > >tools? > > No kidding. > I have Renoir too, and use it to wrap the specials and warts (inc. this > one and only polarity inversion) into IO versions of my blocks instead > of the general-purpose versions. Some people like Renoir, some don't. I > do. It keeps all the structural coding and component interfaces intact, > and there are parts of the problem where I think schematically. I've never really tried Renoir. I'm using Synplicity (SynplifyPro and Amplify) tools. I guess I'm going to have to change my coding style to isolate the I/Os so I can do this. Ich! I'll have to ponder this one. > >> Modifying the design into one that the synthesiser won't screw up has > >> been, for me, a tedious and iterative process (not helped by the poor > >> diagnostics) > > > >...and I thought HDLs were intended to improve productivity. > > IMO - you need both (HDL and schematic), rather than trying to force all > your ideas to fit one paradigm. I took this job so I could learn HDL. Schematics would have made the job too easy. ;-) I hear you though. Having spent a while coding VHDL now, I'd prefer to do my data flows in schematics. HDL really shines for FSMs though. > But I/O interfaces ... should be very easy for synth tools to treat as > special cases, allowing explicit definitions instead of trying to infer > them from the HDL code. I'd think so. On my critical paths I've already explicitly defined what I *think* should be my IOBs. It should be pretty easy for the synthesizer to do the right thing and move the inverter up the chain. That's just too easy! > >> Keith: you could check your design for the abovementioned conditions > >> (not an exhaustive list) and see if fixing them corrects the problem. > > > >Keith has no time for this on my SpartanXL design now. > > Understood... > > >> XILINX: > >> 1) You could improve the MAP diagnostics to say why flops couldn't be > >> mapped ... e.g. > >> <pin>: ENBFF - not mapped into IOB, shared enable signal. > >> <pin>: OUTFF - not mapped into IOB, shared output signal. > >> etc... > > > >Amen! If I explicitly tell it I want FFs swept into IOB and explicitly > >code them, I sure want to know, *in neon*, if it can't or won't do what > >I tell it. > > Of course... you already know that map.mrp tells you what has and hasn't > been migrated, at the level of each pin. Just not why... Why not why? Now that I'm looking I can easily see that it's not doing what I told it to. ---- KeithArticle: 32588
Dean,
You might have a problem with the AND gates and not the clock input. These
tools have logic trimming functions butilt in. If there is anything wrong
with the way that the and gates are hooked so that they can be trimmed, your
PHI input will get trimmed also if those are its only loads. Usually there
is a logic trimming report that tells the story in a hierarchical format.
Something like:
AND gate 1 trimmed because of no load.
AND gate 2 trimmed because of no load.
IBUFG trimmed because of no load.
Just make sure that there is some kind of functional path all the way out to
a primary output.
--
Pete Dudley
Arroyo Grande Systems
"Dean" <www@plexus-technologies.com> wrote in message
news:3b3f3669.292265555@news.zip.com.au...
> Just finishing my first design and using an XC9572-PC84. I have a clock
> input (PHI) which goes to a bufg primitive, and then that feeds a couple
of
> AND gates. Problem is, when I run the software to get a file to burn, I
get
> the following message:
>
> WARNING:nd201 - Removing unused input(s) 'phi'. The input(s) are unused
> after optimization.
>
> Huh? Unused? Don't think so. I have an input marker called PHI, a wire
> going to the input of a BUFG, a wire going from that output, then 2 AND
> gates. Hardly unused.
>
> I removed BUFG and substituted BUF. Same thing. Then I removed BUF and
just
> had a wire going from PHI pad to the AND gates. Still the same thing.
>
> Why is this removing what appears to be a perfectly valid pin? I've tried
> replacing the pad - no difference.
Article: 32589Hello All, I have an application where I am using an 18 by 256 block ram to supply the coefficients for a filtering operation. The coefficients need to be loaded from a host computer but during filter operation the address is supplied by counter logic. For coefficient loading it appears that I could just use a dual port ram configuration and use one port for loading the ram and the other for addressing the coefficients during filter operation. The alternative is to put a mux in front of the address bus and switch over to host addressing when the coefficients are being loaded. I don't really need to be able to reload the coefficients during filter operation and the host and filter logic run on the same system clock. Is the dual port capability of the BRAM "free" or is there some hidden cost in using the second port of the BRAM that might make the address mux a better alternative? -- Pete Dudley Arroyo Grande SystemsArticle: 32590
The second port is totally free, and ideal for your application. --MikeArticle: 32591
I don't know of any simple/clean solution to your problem. I think you have two separate problems. One is converting the LVPECL level into something useful. The second is reducing the clock speed to something you can handle. Several companies are making tiny chips - 1 gate or FF or function. The Fairchild '74 that somebody else mentioned is a good example. IDT makes a few and On-Semi (was Motorola) have a large offering, including many ECL/PECL versions. There are also a lot of clock distribution chips. Some of them take differential LVPECL inputs. Some of them include outputs that are divided by 2 or maybe 4. >How about to use a voltage divider to set the bias on an input near the >switching point (1.4 V for TTL) and then capacitiv couple the LVPECL >signal into the pin. Since this signal is a clock signal, no problems >with low frequency components. Will this work? If you are going to use AC coupling, one trick to add to your collection is that you can make a self biasing setup if you connect a large R from an inverted output back to the input. That will adjust the input switching level to make a 50% duty cycle output. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 32592
Mike Butts <mbutts@realizer.com> writes: > I should also have reminded in my previous posting that, regardless > of the license on xr16vx, the xr16 instruction set architecture and > XSOC tools that xr16vx is based on are copyrighted by Gray Research > LLC and subject to the XSOC license. The tools certainly are, as are Gray's documentation. But I don't think that one can copyright an instruction set. Certainly it's never worked for mainstream microprocessor vendors; many of their products were cloned without licenses, and the legal battles were over patents, or over mask or microcode copyrights, but not over instruction set copyrights. MIPS has sued cloners over implementing certain instructions, specifically the unaligned load and store support, but that is over a patent.Article: 32593
Hal Murray schrieb: > > Several companies are making tiny chips - 1 gate or FF or function. > The Fairchild '74 that somebody else mentioned is a good example. > IDT makes a few and On-Semi (was Motorola) have a large offering, > including many ECL/PECL versions. Right, but these are no real options. > If you are going to use AC coupling, one trick to add to your > collection is that you can make a self biasing setup if you > connect a large R from an inverted output back to the input. > That will adjust the input switching level to make a 50% duty > cycle output. Hmm, nice trick. Thanks. -- MFG FalkArticle: 32594
Hello! I'm exploring the field of evolvable hardware and I'm using JBits SDK from Xilinx. I found the tool extremely useful, but I didn't succeed in using GeneticFPGA together with VirtexDS, the device simulator which comes along with JBits. Whenever I write : java com.xilinx.GeneticFPGA.Virtex.Test.PRec2x2 -virtexDS:XCV1000 .\data\Bitstream\Xcv1000\null1000gsr.bit I don't see any evolution at all in the example circuit (even with the option @GCLK3:XCV1000). Does any of you got any results? The tutorial suggests a Celoxica RP1000pp FPGA board and I'm planning to get one. Did any of you ever try with a Xess XSV100 and GeneticFPGA? Were there particular problems? Thanks, Fabio.Article: 32595
Advantage Custom Chips, Inc. would like to announce the availability of an Intel 82380 DMA controller IP core. The core has been tested in customer products using a Xilinx Virtex 300-5. A pin compatible daughter board replacement is also available. For pricing on replacement boards or source code of the IP core contact Daniel Morelli of Advantage Custom Chips, Inc. at the email address below. Thanks Advantage Custom Chips, Inc. dmorelli@zoominternet.net -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 32596
Pete, you are pointing out one of the many advantages of a dual-ported RAM. Yes, it's free. There is no hidden cost. The only thing you should look out for is to avoid reading the content of one address on one port while the same content is being written by the other port. Apparently not your problem. Address multiplexing would be silly in your application. Enjoy the dual-ported BlockRAMs. Peter Alfke, Xilinx Applications ================================================= pete dudley wrote: > Hello All, > > I have an application where I am using an 18 by 256 block ram to supply the > coefficients for a filtering operation. The coefficients need to be loaded > from a host computer but during filter operation the address is supplied by > counter logic. > > For coefficient loading it appears that I could just use a dual port ram > configuration and use one port for loading the ram and the other for > addressing the coefficients during filter operation. The alternative is to > put a mux in front of the address bus and switch over to host addressing > when the coefficients are being loaded. I don't really need to be able to > reload the coefficients during filter operation and the host and filter > logic run on the same system clock. > > Is the dual port capability of the BRAM "free" or is there some hidden cost > in using the second port of the BRAM that might make the address mux a > better alternative? > > -- > Pete Dudley > > Arroyo Grande SystemsArticle: 32597
Greetings This is semimonthly announcement of Verilog FAQ. Verilog FAQ is located at http://www.parmita.com/verilogfaq/ Alternate Verilog FAQ is an attempt to gather the answers to most Frequently Asked Questions about Verilog HDL in one place. It also contains list of publications, services, and products. Alternate Verilog FAQ is divided into three logical parts. Part 1 : Introduction and misc. questions Part 2 : Technical Topics Part 3 : Tools and Services What's New section outlines the changes in different versions and announcements. Links connects you to related informative links in internet. Your suggestions to make this FAQ more informative are welcome. Rajesh Bawankule (Also Visit Chip-Guru : http://www.chip-guru.com/ )Article: 32598
Hi, There was a company called LEDA which was offering a product that does exactly what you are looking for. It was called KRYPTON. But Synopsys acquired them and since then there is no news about this particular product. Checkout the ESNUG thread on this topic: http://www.deepchip.com/items/0341-09.html So if you are still interested try sending a mail to Bruno Verhaeghe <bruno@leda.fr> (as I see from the ESNUG page) else to Synopsys. Also there was a PERL script posted in this NG that does similar task, I have it and I can send you if you wish. HTH, Srini Goran Bilski wrote: > > Hi > > Thanks but I need a much higher obfuscation then a netlist. > Something like: > all names on signals,port,enities,.. to be strings of 'O', '0', '1', 'l' > and also using the fact that VHDL is free-typing so put as much as possible > on the same line. > > Göran > -- Srinivasan Venkataramanan (Srini) ASIC Design Engineer, Chennai (Madras), IndiaArticle: 32599
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:<qhu20wihs8.fsf@ruckus.brouhaha.com>... > Mike Butts <mbutts@realizer.com> writes: > > I should also have reminded in my previous posting that, regardless > > of the license on xr16vx, the xr16 instruction set architecture and > > XSOC tools that xr16vx is based on are copyrighted by Gray Research > > LLC and subject to the XSOC license. > > The tools certainly are, as are Gray's documentation. But I don't think > that one can copyright an instruction set Yes, The Xr16 Specifications *document*, test suite, etc., and the other works in the XSOC Kit (www.fpgacpu.org/xsoc/), are copyrighted. And I agree with Eric that I don't think you can copyright an instruction set architecture. To be clear, my company does not and never has asserted any copyright on the xr16 architecture or other instruction set architectures we have described. On the fpga-cpu list, I have stated "... we welcome the "from scratch" "clean room" reimplementation of the xr16, xr32, and gr00x0 instruction set architectures.". Congratulations, and thanks, to Mike Butts, for sharing this interesting work with us. It has already led me to learn more about JHDL -- speaking of which, congratulations and thanks also go to the JHDL team for providing such a useful, substantial, and well documented set of design and verification tools. Jan Gray, Gray Research LLC
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