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
BTW, there are dev kits available for Cyclone II. The DSP dev kit, Cyclone II edition and the Nios II dev kit, Cyclone II edition (which use an EP2C35) are now shipping. The PCI dev kit, Cyclone II edition will start shipping next month. Customers can place orders for all these today. DSP: http://www.altera.com/products/devkits/altera/kit-dsp-2C35.html Nios II: http://www.altera.com/products/devkits/altera/kit-nios-2c35.html PCI: http://www.altera.com/products/devkits/altera/kit-pci-2c35.html Regards, Paul Leventis Altera Corp.Article: 84351
Phil Tomson wrote: > Well Big EDA (your Mentors, Cadences, Synopsys-es :) support more than 3 > platforms already depending on the tool (Solaris, HPUX, Linux, Windows). > I would imagine that it would be a lot easier to support OSX than it would > be to support HPUX ;-) (if you've ever had to support HPUX, you know what I > mean) But in general, you're right, they won't support another platform > (OSX) unless they suddenly find a financially compelling reason to do so. I know a handful of scientists who've dumped their Solaris machines for G5 Macs running OS X. Their applications are either homegrown simulations which were easily ported (X11 is X11, after all) or commercial programs like Mathematica and Matlab. Point being that I don't think there's as much pain in going from Solaris to OS X as their is in going from any Unix to Windows. -aArticle: 84352
"Paul Leventis" <paul.leventis@utoronto.ca> schrieb im Newsbeitrag news:1116355134.958776.172170@z14g2000cwz.googlegroups.com... > BTW, there are dev kits available for Cyclone II. The DSP dev kit, > Cyclone II edition and the Nios II dev kit, Cyclone II edition (which > use an EP2C35) are now shipping. The PCI dev kit, Cyclone II edition > will start shipping next month. Customers can place orders for all > these today. > > DSP: http://www.altera.com/products/devkits/altera/kit-dsp-2C35.html > Nios II: > http://www.altera.com/products/devkits/altera/kit-nios-2c35.html > PCI: http://www.altera.com/products/devkits/altera/kit-pci-2c35.html > > Regards, > > Paul Leventis > Altera Corp. > those all are WAY over priced compared to hpe-mini http://www.trs-asic.com Antti PS Paul, I recently sent you an private email, just out of curiosity did you receive it?Article: 84353
Austin Lesea wrote: > > Two fabs: It is a challenge, but then having two qualified sources of > supply is a definite advantage for our customers. Hmm.. Do these parts have different label codes, so users can readily identify which FAB they came from ? This could be an advantage to some, but to others it might mean having to double-up on the qualification work, or worse... -jgArticle: 84354
I'm sure this kind of things has come up in the past, but given that things change, I'd like to throw this out there. Which simulators do people like to use for their HDL purposes? I have tried a couple of simulators and I was curious about peoples recommendations. I have used Modelsim XE starter for my purposes (I am just a hobbyest now), icarus verilog and GPL cver. I have used the built-in quartus simulator as well. So a couple questions regarding these. Which simulators do people consider feature complete? Why do I never hear about cver in this group? Does nobody use it? If not, why? What's really wrong with Modelsim. People seem faily opposed to it. They say the error messages are bad, but I certainly feel that icarus error messages are worse. Also, I haven't really discussed VHDL. Which are best for this? I've heard GHDL is pretty good. I've mostly discussed free simulators, but I'm also interested in how expensive simulators compare to the free sims. -ArlenArticle: 84355
Jim, Yes, they are marked so they an be identified easily. For qualification we advise customers to obtain parts from both fabs (ie request them) so they do not have to do qualification more than once. Of course, customers are free to request parts from a single vendor, although that may subject them to supply issues if they are not planning far enough ahead. Austin Jim Granville wrote: > Austin Lesea wrote: > >> >> Two fabs: It is a challenge, but then having two qualified sources of >> supply is a definite advantage for our customers. > > > Hmm.. Do these parts have different label codes, so users can > readily identify which FAB they came from ? > This could be an advantage to some, but to others it might mean having > to double-up on the qualification work, or worse... > > -jg >Article: 84356
gallen wrote: > I'm sure this kind of things has come up in the past It has. See: http://groups-beta.google.com/groups?q=fpga+recommend+simulator -- Mike TreselerArticle: 84357
...what are their really use for ? For several years, I developped and succesfully used FPGA(Xilinx, Altera, Actel) designed with strongs Static Timing analyses, with a good constraint coverage and only some lite back annotated simulations. After some recent discussions, I'm looking for external experiences that can prove me that back-annotated simulations in min/typ/max timings are not only better for design verification - I'm convinced of this-, but are necessary, even if done with the static timing analyses. Is there something I missed ? Thank you for your attention, and your remarks. Frederic.Article: 84358
Hi Peter, Peter Alfke wrote: > Click on > http://www.xilinx.com/xlnx/xweb/xil_tx_home.jsp > and look for "Six easy pieces #3" by yours truly. Just read them, and they turned out very helpfull for the tinkering I'm doing. Thanks for sharing! Any plans on 'Six not so easy pieces"? Regards, Paul Boven.Article: 84359
Fred C wrote: > About back annotated simulations ...what are their really use for ? Evaluating synthesis tools. Debugging synthesis problems. > For several years, I developped and succesfully used FPGA(Xilinx, > Altera, Actel) designed with strongs Static Timing analyses, with a good > constraint coverage and only some lite back annotated simulations. > After some recent discussions, I'm looking for external experiences that > can prove me that back-annotated simulations in min/typ/max timings are > not only better for design verification - I'm convinced of this-, but > are necessary, even if done with the static timing analyses. If you're already convinced, why pose the question? > Is there something I missed ? STA provides 100% timing verification for synchronous designs in much less time than a back-annotated simulation requires. -- Mike TreselerArticle: 84360
Fred C wrote: >...what are their really use for ? >For several years, I developped and succesfully used FPGA(Xilinx, >Altera, Actel) designed with strongs Static Timing analyses, with a good >constraint coverage and only some lite back annotated simulations. >After some recent discussions, I'm looking for external experiences that >can prove me that back-annotated simulations in min/typ/max timings are >not only better for design verification - I'm convinced of this-, but >are necessary, even if done with the static timing analyses. >Is there something I missed ? Suppose you were designing an FPGA that would control some part of an oil refinery. Or the landing of a probe to Mars. Or the engines on an airliner. Or the dosage of radiation given to a cancer patient. Wouldn't you want to verify the design as correct in as many ways as you could? After all, do you really know that static timing analysis is correct and complete? Sure, you can check it twice, but what if you made the same mistake twice? Do you really know that the synthesis, place and route was all done correctly? I've only once know this to fail, but once might be one too many. A back-annotated simulation isn't fool proof, there are still lots of issues like crossing clock boundaries that can't be checked this way, but it is a way to decrease the risk of something critical being missed. And sometimes that matters a lot. -- Phil Hays Phil-hays at posting domain (- .net + .com) should work for emailArticle: 84361
B. Joshua Rosen wrote: > On Sun, 15 May 2005 04:57:06 +0000, Ronald H. Nicholson Jr. wrote: > > Get yourself a Linux machine (x86 obviously, not Linux on PPC) to run your > FPGA development environment. You can use the Mac as an X-Server, but > thats as close as you are going to be able to get. It's inconceivable that > the FPGA or CAE companies would add a third platform. Well, that's nice in theory, but certainly with the Wind/U toolkit it's a no-go. Some X widgets (especially pulldown menus) are rendered in the top-left corner of the screen, and the first choice is unavailable. In other cases, the program simply crashes with a BadAccess error. I have a dual 2.5GHz box, running Tiger with a linux machine sitting next to it, and a DVI KVM switchbox to switch between the two. I use the linux box for FPGA work, and the mac for everything else - it's nice to have one of the Apple 23" monitors though - especially when opening floorplanner :-) The Linux box is significantly faster than the Mac anyway - a single 2.4GHz Opteron is about 2x as fast as a dual (I think it doesn't use both processors) 2.5 GHz Mac, at least in my experience. SimonArticle: 84362
In this case, the replication of the flip-flop is architecturally required in order to satisfy the iob=true attribute. The Q output of the output flip-flops in the IOBs connect ONLY to the output driver for the pin. There is NO other route available to this signal - it MUST go off chip. Since your HDL specifies connectivity both to the output pin as well as to internal logic, the synthesis tools must replicate them. Since the Q output of the IOB flip flop cannot connect to internal logic, and you have specified that the flip-flop driving the output pin must be in the IOB, the tools have to create two flip flops; one internally in the "core" of the FPGA (in a slice), so that the Q output of this flip flop can drive the internal connections you have asked for, and a second one in the IOB to drive the output pin. Avrum <giachella.g@laben.it> wrote in message news:1116313518.015049.170990@g47g2000cwa.googlegroups.com... > Dear all, > when synthesizing my design with XST, i get some messages like this > one; > "Flip-flop ... has been replicated 1 time(s) to handle iob=true > attribute". > The replicated flip-flops have their output shared between internal > logic and IO pins. I understand that this replication could improve IO > performances and that is the reason for adding such flip-flops on IOB. > Am I right ? > > Moreover, both XST and Precision RTL show the same behavior in > synthesis (under the default synthesis settings), so it seems this > replication is strongly recommended. Can someone clarify this point ? > > Thanks in advance, > > Giuseppe >Article: 84363
giachella.g@laben.it wrote: > The replicated flip-flops have their output shared between internal > logic and IO pins. I understand that this replication could improve IO > performances and that is the reason for adding such flip-flops on IOB. > Am I right ? > > Moreover, both XST and Precision RTL show the same behavior in > synthesis (under the default synthesis settings), so it seems this > replication is strongly recommended. Can someone clarify this point ? If you place all flip-flops on a bus in the IOBs, then the only timing stuff you have to worry about is the clock to out parameter (with maybe a bit of clock skew, package skew - small effects). If you don't put them in the IOBs then they are somewhere in the fabric - with potentially widely varying times to get from the flip-flop to your output. Secondly, if they are in the general fabric and they are not locked down, then their position may vary across synthesis/p&r runs, generating inconsistant results. JeremyArticle: 84364
Hi there, I'm having a bit of confusion using arrays in VHDL. I know I can: type heap is array (0 to 800) of std_logic; signal que: heap; ... que(0)<='1'; que(1)<='1'; ... que(7)<='1'; to set 8 bits of an array, but is there a way of setting all 8 bits at once? Something like que(0 to 7)='11111111' which I thought I could do, but can't. And how does the string type work? I was first trying to do this using it ( que(0)='a' ) , but I don't understand how to address single bits (I'm making an RS232 port so I need to.). Also.. if anyone can recommend some good (hobbyist/student priced) books, that would be appreciated. Another question I've been meaning to ask for a while - on optimization. Is it the general rule in VHDL that making the entire project in a schematic would be more efficient, but hellishly complex? Or is it (similar to C, arguably) the consensus that the compiler (is that the right word?) can optimize more effectivly at that level, and the coder should concentrate on algorithms? Or is it a religeous argument I shouldn't get in to? ;) Ta muchly. -Alan/RandomdudeArticle: 84365
Andre, The syntax of the assignment you made looks wrong to me. You want to set a "virtual pin clock" on some "virtual pin", say Pin_name1 (name from your original post). The syntax for that is: To Assignment name Value Enabled Pin_name1 Virtual Pin Clock clk_90_sys Yes Note that I changed the "To" value to the name of the virtual pin. The assignment above says "make virtual pin Pin_name1 use signal clk_90_sys as its clock. Hope this helps. Vaughn [v b e t z (at) altera.com] <ALuPin@web.de> wrote in message news:1116319794.571927.286760@g47g2000cwa.googlegroups.com... Answered last question by myself. I have made the virtual clock pin assignment in the Assignment Editor. To Assignment name Value Enabled clk_90_sys Virtual Pin Clock clk_90_sys Yes And yet when compiling the design I get the warnings described in my first post. The problem is that I NEED the virtual pins to be registered and therefore clocked because I want to have a look at them with SignalTapII. Or is that a problem because of using virtual pins ? Rgds AndréArticle: 84366
"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message news:PaudnRAmKPtWBhTfRVn-vA@rogers.com... > Hi Peter, > -snip- > The short version is that Adaptive Logic Module (ALM) can do 2 4-LUTs > (like a Slice or 2 Stratix LEs), but also can do a 5-LUT + 3-LUT, 6-LUT, > and other more powerful combinations (such as 2 6-LUTs that share 4 > inputs, etc). When you technology map a design into a specific look-up > table (LUT) size, you get a variety of LUT sizes -- you can't map all the > logic to use exactly 4-inputs (for example). Since you have a > distribution of LUT sizes, the capability to pair more than just 2 4-LUTs > into a single ALM will result in a decrease in the number of ALMs > required. > > Regards, > > Paul Leventis > Altera Corp. > > P.S. Ours is bigger -- and we can use it better too! As a frequent Xilinx user (4K, Virtex-2, V2P, soon V4), I note that in the slice (2 4-input LUTs), there is also available a 3-input LUT following those two. That LUT can be fed the input of [at least] one independent input (besides the outputs from the two 4-input LUTs), creating the opportunity to broaden the input set with minimal cost (delay, routing.) I have also extensively used the distributed RAM (sometimes as ROM), and occasionally the SLR function. I also have had occasion to use Altera, although not lately. In '96 I had a design where Altera had the appropriate solution (love those embedded block RAMs, which Xilinx now has--features may vary), but in '97 I had a design where Xilinx was better from a planning perspective (read: growth path.) Over the past 10+ years, I've had to get "under the hood" of the Xilinx tools: hand floorplanning, extensive timing constraints, reading lots of app notes. So you could say that I'm fairly comfortable with their architecture(s) and tools. However, I'd have to agree with some previous posters: if you think you have a challenging design, evaluate what you can before committing. That's what I have done in the past, and prefer to do in the future (though usually, I'm stuck with a pre-determined selection.) Typically, you can budget key resources (be that memory, LUTs, registers, multipliers, pins, ...) You can also do a test-case design that tests the anticipated critical path. The same principle applies for synthesis and simulation tools, too. JasonArticle: 84367
Hi Edwin, I'm glad you had a positive experience with Quartus and Stratix II. I'm sorry to hear you got an unroute in one of your compiles though. I'd greatly appreciate it if you could send me the design, so my team can take a crack at routing it. We don't have very many unroutes these days, even at very high logic utilization, so case studies like this are very useful for improving our tools. We would use the design only to tune our tools, will never release it outside Altera, and frankly we won't understand your design as anything but a place and route problem instance anyway :). It's most likely we can route it in house with more "routability tuned" compiler settings, which we will send back to you as well. Regards, Vaughn Betz [v b e t z (at) altera.com]Article: 84368
Mike, I definitely agree that STA provides 100% coverage, if you get all the constraints correct. But there are many designs where the constraints are incomplete, or may not be completely correct, and in those cases timing simulation provides some level of back-up test. In designs with multicycles & cut paths set that I think there's value to simulating to double-check you didn't cut or multicycle something you shouldn't have. Generally such constraints are set manually, and hence there is the possibility of an error in entering them. Of course, a timing simulation is not guaranteed to catch a problem even if you did make a mistake, but if you can afford the time, it may catch an issue. Most designs I see use asynchronous clears, and don't set a recovery and removal timing constraint to make sure the reset release occurs sufficiently far from a clock edge for the design to come out of reset cleanly. You can design things such that everything works even if you wouldn't pass a recovery & removal timing analysis, but again, if you don't know exactly what you're doing, or you make a mistake, you can get into trouble without this constraint. Timing simulation provides some level of back-up, although it's definitely a poor substitute for a disciplined reset strategy and a static timing analysis on it. Regards, Vaughn Altera [v b e t z (at) altera.com] "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:3eva9tF570msU1@individual.net... > Fred C wrote: >> About back annotated simulations ...what are their really use for ? > > Evaluating synthesis tools. > Debugging synthesis problems. > >> For several years, I developped and succesfully used FPGA(Xilinx, >> Altera, Actel) designed with strongs Static Timing analyses, with a good >> constraint coverage and only some lite back annotated simulations. >> After some recent discussions, I'm looking for external experiences that >> can prove me that back-annotated simulations in min/typ/max timings are >> not only better for design verification - I'm convinced of this-, but >> are necessary, even if done with the static timing analyses. > > If you're already convinced, why pose the question? > >> Is there something I missed ? > > STA provides 100% timing verification > for synchronous designs in much less > time than a back-annotated simulation requires. > > > -- Mike TreselerArticle: 84369
Avrum wrote: > In this case, the replication of the flip-flop is architecturally required > in order to satisfy the iob=true attribute. > > The Q output of the output flip-flops in the IOBs connect ONLY to the output > driver for the pin. There is NO other route available to this signal - it > MUST go off chip. Howdy Avrum, Actually there is a route available - how else would bi-directional I/O's work? It's true that the tools typically don't do this (probably for signal integrity and prop delay time reasons), but it can be done. Have fun, MarcArticle: 84370
On 16 May 2005 14:50:26 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >"Unlike a liar, who knows the truth and wants to keep people away from >it, the bullshitter exhibits a complete lack of concern in >differentiating between truth and falsehood. >What matters to the bullshitter is: will it further my aims?" > >As Frankfurt writes in his book, >"It's impossible for someone to lie unless he thinks he knows the >truth. >Producing bullshit requires no such conviction." >This lack of concern for the truth - which even the liar must exhibit >in order to lie - is what makes b.s. a greater enemy of the truth >than lies, he believes. > >"On B.S.", by Professor Harry G Frankfurt, is published by Pinceton >University Press > >posted by Peter Alfke, speaking for himself Well, sure. The easiest person to lie to is yourself. JohnArticle: 84371
Just wondering if it is possible to detach the schematic viewer from the main ise window. (in 7.1i or so.) Also is it possible to configure a third party tool for viewing the schematic ? I know that it is possible to configure the text editor. But is it possible for the schematic viewer too ? Thanks, GeorgeArticle: 84372
"Geogle" <georgevarughese@indiatimes.com> schrieb im Newsbeitrag news:1116392539.922971.178880@g49g2000cwa.googlegroups.com... > Just wondering if it is possible to detach the schematic > viewer from the main ise window. (in 7.1i or so.) > Also is it possible to configure a third party tool for > viewing the schematic ? > > I know that it is possible to configure the text editor. > But is it possible for the schematic viewer too ? > > Thanks, > George > ASFAIK, NO AnttiArticle: 84373
Yes, I tried it, and it works. Thank you for your help :o) Rgds Andr=E9 Duane Clark schrieb: > ALuPin@web.de wrote: > > ... > > t_Bidir_data <=3D t_tx_data when t_drive_tx_data=3D'1' else (others = =3D> > > 'Z'); > > t_rx_data <=3D t_Bidir_data when t_drive_tx_data=3D'0' else (others =3D> > > '0'); > > ... > > > > My question : > > In the port map > > Bidir_data =3D> t_Bidir_data > > > > an INOUT port of the unit under test is connected to a signal within > > the testbench. > > > > Will the Tristate Description shown work ? (Which "direction does > > "t_Bidir_data" have ?) > > The testbench "t_tx_data" generation takes over the tristate bus master > > role. > > > > Did you just try it? That would be the easy thing to do. Sure, it will > work. There is normally no reason to tristate the receive data. Just do >=20 > t_rx_data <=3D t_Bidir_data;Article: 84374
what about http://www.8ung.at/raimy/study/vhdl/FAQ1.html#0 Jochen
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