Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > rickman <gnu...@gmail.com> writes: > > Anyone know if 3.3 volt I/O is still with us in the new Spartan 6 > > devices? > > http://www.xilinx.com/publications/prod_mktg/Spartan6_Overview.pdf > > says : > > > Multi-voltage, multi-standard SelectIO banks > > ... > > - 3.3V to 1.2V I/O standards and protocols > > So yes - hurrah! > > Any bets on whether the next Spartan family will still have it? > > Cheers, > Martin I would say that depends on when it comes out. I don't see any sign of the 3.3 volt standard going away any time soon. So over the next five years, any FPGA aimed at the general logic market will pretty much *have* to support 3.3 volts. As the feature sizes shrink we hear that (at least in the case of Xilinx) it becomes prohibitively expensive to continue to support higher voltage I/O standards. Although the semi companies that are making parts that aren't FPGAs still seem to manage to support 5 volt tolerant I/Os, I guess at some point this really is true. It is just a matter of where your market is. The FPGA vendors have decided that the market for 5 volt tolerance is not worth the extra per part cost. They trade off the design wins they miss out on because of price vs. the ones they lose on I/O voltages. That is why the Spartan and the Virtex lines have diverged at this point. The high end stuff does not use as much 3.3 volt TTL I/O as it demands high speed serial and LVDS. Spartan is aimed at a different market that still demands a lot of 3.3 volt I/O without adding expensive and bulky interface chips. At some point even the 3.3 volt I/Os will become a liability and the low cost product lines will drop support. I think it is especially interesting that Lattice has dropped their pursuit of the high end market. I am sure that X and A will spin this as L not being able to keep up with the big boys. But there is also the dynamics of the FPGA market. It may well be that the high end is not where the future is. They may make $500 per 1500 pin/ 10,000,000 gate FPGA, but how many can they sell? On the other hand, if they can cost effectively get an FPGA into a digital camera they only need to make a buck per chip to make millions. Right now, in the cellular market, they are pretty much limited to the low quantity base stations. If they can ever get a seat at the cell *phone* table, then the sky is the limit! And they might not need 3.3 volt compatibility to do that... RickArticle: 138701
On Mar 5, 7:50=A0am, igalko...@gmail.com wrote: > I'm using a deserializer 7 to 1 core (from xapp265) in Spartan 3AN. > After power up it is not functional until I'm retriggering prog_b or > loading the bit file from JTAG. It's impossible to debug this problem > with Chipscope because in order to do that I need to load the bit file > and after that it's working. > What might be the problem? Chipscope should be able to use the wake-up configuration without re-loading the bit file. You just need to program the version with the Chipscope core in it into the flash. Then if the chipscope core doesn't "fix" the problem you can at least see the state of the part while it isn't working (Chipscope won't be able to show you what happens at power-on because the trigger needs to be armed after you connect).Article: 138702
On Mar 4, 2:30=A0pm, Luc wrote: > but ECP2M is a good alternative. I'll use those, then. It is easy enough to design different boards later on. Thanks for the advice, -- JecelArticle: 138703
oktem@su.sabanciuniv.edu wrote:
> Actually I was not able to do it with the makefile approach since it
> seems harder for me. I need a little more explanation.
Sometimes just editing a file n times
is quicker than automating the process.
Date and time information is already attached
to the source files. This is really a job
for a version control system like svn.
Production is more likely concerned with
release numbers, and these do not change
nearly as often as builds do.
-- Mike Treseler
Article: 138704I hope this isn't terribly inappropriate to post here. I want to buy three FPGA-related T-shirts. I know that Altera and Xilinx have in the past given out freebie shirts, and I'm trying to track some down as gifts for my roommates, who work with FPGAs. I will pay good money for them!! Let me know if you have something lying around that you don't mind parting with. They primarily use Altera, so that's preferable. Thanks!Article: 138705
On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > Multi-voltage, multi-standard SelectIO banks > > ... > > - 3.3V to 1.2V I/O standards and protocols > > So yes - hurrah! Not so fast. Listing 3.3v I/O and having it usable in the real world are not the same thing. You need to check how much allowance there is for overshoot, which will determine how perfect your impedance match needs to be to be able to use 3.3v I/O in the real world. I don't know about the part in question, but for some recent fab processes there hasn't been much in the way of safety margin.Article: 138706
All, The fabs will make anything you want. If you want a 5V IO, that is what you get. The market (and here I mean where the money is) wants very fast DDR3 interfaces. To do this one requires 180nm IO transistors (optimally), or 250nm IO transistors. That means 1.8v IO or 2.5v IO. So, for a FPGA, one must choose the highest performance you need, and that will constrain your highest voltage options (unless you decide to have more than one oxide for IO, which greatly increases cost, and design complexity, decisions as to what to provide, and thus time to market). So, Xilinx doesn't decide to 'drop' 3.3v. The V6 doesn't support 3.3v IO like in previous families, but S6 does. The customers told us quite clearly what was required, for their dollars (yen, NT$, euros, pounds, etc.). As for 'safety margin' it is true that more aggressive process means perhaps less tolerance to overshoot and undershoot. Hopefully, the recommended operating levels in the specifications are clear, and good signal engineering practices are followed. If you don't care about SI, then you are likely to have other problems, so it isn't such a big deal anymore. AustinArticle: 138707
I was able to generate a character ROM using the Xilinx 10.1 ISE Core generator and also a RAM using the same. This is only a part of my final year project, not the project as a whole. But during implemetation the following error occurred. ERROR:NgdBuild:604 - logical block 'U_TEXT' with type 'mem_text' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'mem_text' is not supported in target 'spartan3e'. ERROR:NgdBuild:604 - logical block 'U_FONT' with type 'mem_font' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'mem_font' is not supported in target 'spartan3e'. the 'mem_text' is the generated RAM module and 'mem_font' is the generated character ROM. U_TEXT and U_FONT are their instants in the highest level module. does anyone have a solution. I consulted the Xilinx website for these errors but of no use.Article: 138708
Mike Treseler wrote: > oktem@su.sabanciuniv.edu wrote: >>Actually I was not able to do it with the makefile approach since it >>seems harder for me. I need a little more explanation. > Sometimes just editing a file n times > is quicker than automating the process. It would seem that one would want the date/time of the last make, or at least the last change to be checked in. With a manual process it is too easy to forget. > Date and time information is already attached > to the source files. This is really a job > for a version control system like svn. I think with make it is possible to have it remake a file each time, but I don't remember how to do it. Is there a way to have cvs or svn update the date/time on one file when any in the project is checked in? Interestingly, pretty much the same question came up yesterday on comp.lang.fortran. > Production is more likely concerned with > release numbers, and these do not change > nearly as often as builds do. -- glenArticle: 138709
rickman wrote: (snip) > I would say that depends on when it comes out. I don't see any sign > of the 3.3 volt standard going away any time soon. So over the next > five years, any FPGA aimed at the general logic market will pretty > much *have* to support 3.3 volts. As the feature sizes shrink we hear > that (at least in the case of Xilinx) it becomes prohibitively > expensive to continue to support higher voltage I/O standards. > Although the semi companies that are making parts that aren't FPGAs > still seem to manage to support 5 volt tolerant I/Os, I guess at some > point this really is true. Even for the original TTL, logic high was just 2.0 volts. For an output, you only need to get up to 2.0. For inputs, many Xilinx families will do it with a current limiting resistor such that the protection diodes aren't overdriven. I suppose one could add external diodes for extra protection. For tristate (bidirectional) I/O, though, the resistor approach probably won't work. An external protection diode might, though. > It is just a matter of where your market is. The FPGA vendors have > decided that the market for 5 volt tolerance is not worth the extra > per part cost. They trade off the design wins they miss out on > because of price vs. the ones they lose on I/O voltages. As far as I understand it, the thicker oxide for higher voltage results in slower transistors. You can have speed or volts, but not both. > That is why > the Spartan and the Virtex lines have diverged at this point. The > high end stuff does not use as much 3.3 volt TTL I/O as it demands > high speed serial and LVDS. Spartan is aimed at a different market > that still demands a lot of 3.3 volt I/O without adding expensive and > bulky interface chips. At some point even the 3.3 volt I/Os will > become a liability and the low cost product lines will drop support. -- glenArticle: 138710
Glen Herrmannsfeldt wrote:
> It would seem that one would want the date/time of
> the last make, or at least the last change to be
> checked in.
That is what version control does.
That is why I use it.
> With a manual process it is too
> easy to forget.
Maybe for the OP it is better than nothing.
> Interestingly, pretty much the same question came
> up yesterday on comp.lang.fortran.
Guess I've lost interest.
It comes up here regularly.
-- Mike Treseler
Article: 138711Mike Treseler wrote: > Glen Herrmannsfeldt wrote: >>It would seem that one would want the date/time of >>the last make, or at least the last change to be >>checked in. > That is what version control does. > That is why I use it. I suppose I will have to look in the CVS or SVN manual. I know it updates each file as it is checked in, but in this case one wants one file/module to contain the time/date of the last change to any other file/module. Last time I used SVN or CVS we didn't need that. -- glenArticle: 138712
Ise 9.2i will not accept a .ngc file as a source file via the gui,
but it does seem to find and use it if I just copy it
into the project directory with where the .v and .vhd files end up.
If anyone has a cleaner method, without regenerating the core,
I would like to hear about it.
Thanks.
-- Mike Treseler
Article: 138713So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has onboard ddr memory to which I'd like to get access. What's the best way to get a simple read/write interface to the memory? I'm learning verilog and prefer examples or code written in it. I've tried a couple options: 1. Memory Interface Generator from Xilinx. (MIG 23) This looks like the most robust solution, but the code that is output seems overly complicated, mostly uncommented, and the example test bench is anything but straight forward. The user guide UG086 is written ok. 2. Couple of opencores solutions, including ddr ctrl (the non wishbone version) While it's commented better, there is zero documentation. I can't get it to synthesize even though it's specifically designed for my kit. The problems are related to .ucf constraints, but when I manually look through them, most of them seem ok. It's as if the format of the .ucf file is not what XST(or whatever component that is) expects, so it generates about 40 errors. Is accessing this DDR memory more simple via Picoblaze or Microblaze? Is Microblaze and associated parts free? I didn't get any CDs whatsoever w/ my board. Thanks KeithArticle: 138714
Keith M wrote: > So being new to FPGAs, I've bought a Digilent 3E Starter Kit that has > onboard ddr memory to which I'd like to get access. > What's the best way to get a simple read/write interface to the > memory? I'm learning verilog and prefer examples or code written in > it. I asked this question not so long ago. I am also interested in a simple (if not fast) solution. -- glenArticle: 138715
>I know it updates each file as it is checked in, but >in this case one wants one file/module to contain the >time/date of the last change to any other file/module. I'm not a make wizard. I've worked with people who are. If you have something like a clump of compile steps and then a link step, it's simple to put an extra clump of shell commands in front of the link step. One of them can touch a file and then do whatever you want, or just use the date command. That gives you the date/time when you run that part of make rather than the time of last checkin. With a bit more work, you could get the checkin time of the last file checked in. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138716
On Mar 5, 8:25=A0pm, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > I asked this question not so long ago. =A0I am also interested > in a simple (if not fast) solution. > > -- glen Yeah Glen, I saw the thread. I should have mentioned that I scanned the various threads in the ng before posting --- but saw nothing that approached an answer that could help. Thanks KeithArticle: 138717
On Thu, 05 Mar 2009 15:01:47 -0800, Mike Treseler <mtreseler@gmail.com> wrote: >Ise 9.2i will not accept a .ngc file as a source file via the gui, >but it does seem to find and use it if I just copy it >into the project directory with where the .v and .vhd files end up. > >If anyone has a cleaner method, without regenerating the core, >I would like to hear about it. >Thanks. > > -- Mike Treseler Add the associated .xco file to your project. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138718
This FPGA configuration device uses SPI to receive new FPGA configuration bitstreams. Most processors and mezzanine cards have SPI capability. Slower than PCIe of course, but would this be useful? http://www.intellitech.com/products/systembist.asp Satish On Feb 27, 1:58=A0am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > rickman wrote: > > When you refer to "high end" processors, you are talking about a > > literal handful of devices compared to the hundreds or thousands of > > types of CPUs that are used in embedded systems. =A0If you are talking > > I'm referring to chips like Intel atom, new PowerQuicc IIP/III > processors etc. They usually have few PCIe ports as a default and if > they are not enough a switch is needed. And I don't see why > low end would not adopt PCIe. Each saved pin helps to get into a > smaller and cheaper package (altough wirebond and PCIe frequencies > might be challenging). > > > about adding a "switch" then you are adding an extra chip and you can > > just as easily add any sort of chip to facilitate booting the FPGA. > > The problem is that there are only few vendors for special bridge chips > to GPIO etc. But for PCIe switches there are many vendors even > some with identical pinouts. That helps multisourcing for manufacturing. > Also Industrial temperature requirements narrow down the choices. > > > I'm not familar with PCIe, but I know in PCI apps you can't use the > > PCI interface to boot the FPGA. =A0Are you talking about an embedded ap= p > > You could use it, if there would be FPGA on the market with hardcore IP > for PCI and someone would have thought of using it for configuration at > FPGA vendor. But that would have required too many pins etc. to be a > good and widely used solution. > > > where you can work "around" the PCIe spec and just talk to the FPGA > > without worrying about the spec'd protocol? =A0In that case you have on= e > > I'm thinking that if you have hardcore IP for PCIe then it can > immediatly answer to the bus even if the FPGA is not loaded. If the > PCI configuration space would then have extended configuration register > that could be used to bang the data in via configuration cycles. Or > other option would be one hardcoded PCI BAR for the configuration image. > Memory mapped configuration image also might create some pretty > interesting opportunities for dynamic reconfiguration. > > > of the few apps where your PCIe port is dedicated to the FPGA. =A0Yes, > > in that case this works. =A0But that is rare enough that the FPGA > > vendors aren't going to add that capability for those few apps. > > With hardcore it can be done in a standard way, altough the boot > code needs some changes. And SIVGX, V5LXT, V5FXT, V6, S6, ArriaIIGX > at least have PCIe hardcore already. They just haven't built the > configuration interface yet (or they might have, but are not > documenting it). There are usually undocumented features in FPGAs > that are just not enabled, and might be enabled for few customers > with custom IP for testing. > > > I seem to recall that there was support for a JTAG or some other > > serial interface on PCI, but it has been so long that I don't recall. > > I think you are referring to SMBus. It is I2C style slow (10kHz-100kHz) > interface. I think it would be too slow for FPGA configuration. >Article: 138719
Rob Gaddi wrote: > On Mon, 02 Mar 2009 01:57:58 -0800 > Alex Freed <alex_news@mirrow.com> wrote: > >> dracosilv wrote: >>> I think I'm going to go with Verilog or VHDL (not 100% sure which >>> yet, but probably VHDL), since the logic seems pretty simple. >> I wonder what drives you towards VHDL - not to start a religious war >> here. The same functionality can look like >> >> module BUFF4(input e, input [3:0] I, output [3:0] O); >> >> assign O = (e == 1) ? I : 4'bz; >> endmodule >> >> -Alex. > > And in VHDL as: > > library IEEE; > use IEEE.STD_LOGIC_1164.all; > > entity BUFE4 is > > port( > O : out std_logic_vector(3 downto 0); > E : in std_logic; > I : in std_logic_vector(3 downto 0); > ); > end BUFE4; > > architecture BUFE4_V of BUFE4 is > begin > > O <= I when (E = '1') else "ZZZZ"; > > end BUFE4_V; > > What made the original code a little cumbersome was not using vectors, > not language choice. > That I understand. In fact I learned VHDL before Verilog because it was the standard at the time and used in the company I worked for. My point is that even this optimized VHDL is 13 lines vs. my 3 lines. More than a factor of 4. Does it buy any clarity? I'm not arguing. Just trying to understand what is it that atracts people to VHDL if they have a choice and start from scratch. -Alex.Article: 138720
Keith M wrote: > On Mar 5, 8:25 pm, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >>I asked this question not so long ago. I am also interested >>in a simple (if not fast) solution. > Yeah Glen, I saw the thread. > I should have mentioned that I scanned the various threads in the ng > before posting --- but saw nothing that approached an answer that > could help. OK. I thought it was interesting to see pretty much the same question. I haven't been working on that much lately. I will probably try using the BRAMs first and get that working before going on to the DDR RAM. Also, I wasn't sure that the MIG output could be used in open source projects. -- glenArticle: 138721
Alex Freed wrote: > dracosilv wrote: >> >> I think I'm going to go with Verilog or VHDL (not 100% sure which >> yet, but probably VHDL), since the logic seems pretty simple. > > I wonder what drives you towards VHDL - not to start a religious war > here. The same functionality can look like > > module BUFF4(input e, input [3:0] I, output [3:0] O); > > assign O = (e == 1) ? I : 4'bz; > endmodule > > -Alex. Qbasic. If/then/else and A <= 'B' (basically an A=B sort of thing. -- But they spend 90% of their time standing there looking stupid and (in your case) eyeballing everyone and wondering how they look naked. gregvk on what he thinks WalMart greeters do. In the immortal words of §ñühw¤£f: This is you not giving a shit? HA HA I MADE YUO POST! I win & stuff. "Over the years, I've seen many jerks come and go. The latest crop is not as smart. They're less ass and more hole or is it the other way around? <snicker>" The Daring Dufas How do he produce so much doo-doo so fast? It's amazing! The Daring Dufas Yeah, UPS, Usenet Performance Stupidity. ^_^ Onideus Mad Hatter Golly Wiggle! Uncle MonsterArticle: 138722
On Mar 5, 2:03=A0pm, cs_post...@hotmail.com wrote: > On Mar 5, 3:44 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > > > Multi-voltage, multi-standard SelectIO banks > > > ... > > > - 3.3V to 1.2V I/O standards and protocols > > > So yes - hurrah! > > Not so fast. =A0Listing 3.3v I/O and having it usable in the real world > are not the same thing. =A0You need to check how much allowance there is > for overshoot, which will determine how perfect your impedance match > needs to be to be able to use 3.3v I/O in the real world. =A0I don't > know about the part in question, but for some recent fab processes > there hasn't been much in the way of safety margin. That reminds me of the initial versions of the Spartan 3 which had *very* tight specs on over and undershoot. The eventually relaxed it a bit as a lot of people screamed about it... at least they did here. Hopefully that lesson has been learned. RickArticle: 138723
Hi Steve, I am running Windows XP Pro No shorting of anything being used. The mode jumper JP9 is set to JTAG. I have even used the board with an Altium USB JTAG interface and it detects the JTAG chain. You may have a faulty board. Good luck. Dave... On Feb 4, 10:59=A0am, "freesp...@gmail.com" <freesp...@gmail.com> wrote: > * your OS version > * whether you are shorting any pins on the JTAG port > * setting of the MODE jumper (jp9) > > Cheers, > SteveArticle: 138724
On Thu, 2009-03-05 at 15:01 -0800, Mike Treseler wrote: > Ise 9.2i will not accept a .ngc file as a source file via the gui, > but it does seem to find and use it if I just copy it > into the project directory with where the .v and .vhd files end up. > > If anyone has a cleaner method, without regenerating the core, > I would like to hear about it. > Thanks. > > -- Mike Treseler Of course, ISE accepts NGC files as sources but you have to set the "Top-Level Source Type" to NGC/NGO instead of HDL. Jan
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