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
ctaniguchi1@gmail.com wrote:
> Has anyone recently done a comparision of the utility of Primetime vs.
> Xilinx or Altera timing analysis engines?
Don't know about Primetime, but
the latest spin from altera promotes
Synopsys Design Constraints (SDC) format:
http://www.fpgajournal.com/whitepapers_2007/q2_altera_1.htm
Quartus now supports this and their simpler "classic" STA.
I've tried both, and they work,
but I don't know enough to have a preference yet.
-- Mike Treseler
Article: 122626On Tue, 31 Jul 2007 13:36:03 +0200, Philipp Klaus Krause <pkk@spth.de> wrote: >It goes into a Z80-based system from the 80s. What is it? EvanArticle: 122627
On Jul 31, 8:25 am, Sylvain Munaut <tnt-at-246tNt- dot-...@youknowwhattodo.com> wrote: > Andy wrote: > > On Jul 31, 7:25 am, Sylvain Munaut <tnt-at-246tNt- > > dot-...@youknowwhattodo.com> wrote: > > >> I had a problem this morning in a functionnal simulation that I finally > >> traced to the unisim library. > > >> Basically, internally they do : > > >> prcs_clk: process (clk) > >> begin > >> if (clk'event) then > >> clk_wire <= clk; > >> end if; > >> end process; > > >> Then, they use clk_wire in their processes and co, to sample the data > >> that I generated using clk. > >> I can understand that it fails ... Because clk_wire will toggle 1 delta > >> after clk and so then the "rising_edges(clk_wire)" will be evaluated, > >> the value of my FF clocked on clk will already have switched ... > > >> Now, to my _BIG_ surprise, doing > > >> clk_wire <= clk; -- (no process, just an asignement ... ) > > >> ALSO fails ... with the same problem. I personnly think it should not, > >> because an assignement should be like an alias, I don't do > >> any operation on it so there is no point in making it > >> "toggle" one delta later ... > > >> I've done a little testbench ( seehttp://pastebin.com/m133bbae0, or also > >> at the end of this post) and that leads to surprising results ... > > >> Any one can enlighten me on _why_ this happens ? > > >> Sylvain > > > A concurrent assignment statement (unlike a port assignment), is not > > like an alias. Concurrent assignment statements are implied processes > > with a sensitivity list made up of all signals on the RHS of the > > assignment. So, they would incur a delta delay for the assignment as > > well. > > well, that sucks ... > For normal signals that doesn't matter much but for clock I'd like a > way to force a "zero delta assigment". > > Basically at several place I have a "GENERIC" that tells me either to > be synchronous or not. If it's true, all of my block will run at clk_1 > and instanciate a synchronous fifo. When it's false, part of the process > are clocked on clk_2 and I instanciate a async FIFO. > > Something like : > > ---- CUT ---- > > port ( > ... > ... > clk_1 : in std_logic; > clk_1 : in std_logic; > ... > ); > > ... > > signal clk_i : std_logic; > > sync: if SYNC generate > > -- Assign clock > clk_i <= clk_1; > > -- Synchronous FIFO instance > -- ... (using clk_1 only) > > end generate > > async: if SYNC generate > > -- Assign clock > clk_i <= clk_2; > > -- ASynchronous FIFO instance > -- ... (using clk_1 on writeclk and clk_2 on readclk ) > > end generate > > -- Sub Block (either clocked on > my_subblock_i: subblock > port map ( > -- The fifo signals > -- .... > clk => clk_i; > ... > ); > > ---- END OF CUT ---- > > But then clk_i is 1 delta too late ... that sucks. > > Sylvain Instead of wrapping the clk_i assignments in generate statements, wrap the my_sublock instantiation in two generate statements, one with clk_1, and one with clk_2. Maybe not the solution you were looking for, but it will work. AndyArticle: 122628
In article <1186005558.239970.72910@g12g2000prg.googlegroups.com>,
Andy <jonesandy@comcast.net> writes:
<VHDL and delta cycle for clocks>
|> Instead of wrapping the clk_i assignments in generate statements, wrap
|> the my_sublock instantiation in two generate statements, one with
|> clk_1, and one with clk_2.
|>
|> Maybe not the solution you were looking for, but it will work.
This leads to the question how to generally handle it. I had similar problems a
while ago by combining bus signals into a record along with its bus clock, so
everything is nicely encapsulated. But it doesn't work with the clock when
assigning the individual clock to the bus-record at higher levels. So the bus
clock must be treated separately in the component instantiation. And the
abstraction says good bye...
I can't believe that there is no cleanVHDL equivalent to a pure wire in a
schematic...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 122629Roger, Most of what is in this recently published white paper should be helpful, http://www.xilinx.com/bvdocs/whitepapers/wp248.pdf AustinArticle: 122630
Sebastian Goller wrote: > On Jul 31, 4:54 pm, "B. Joshua Rosen" > <bjro...@polybusPleaseDontSpamMe.com> wrote: >> On Tue, 31 Jul 2007 06:34:54 -0700, sego wrote: >>> During my work with the XUP development board another problem occured >>> when I tried to use the on-board DDR-SDRAM. A data stream is written >>> into the RAM using the PLB bus and burst mode (16 x 64 bit). When I read >>> the data from the RAM using the Power PC after some time an error >>> occurs. It looks like one 64 bit word has not been written into the RAM >>> (or it has been overwritten - I am not sure about this). When I use the >>> Block RAM of the Virtex-II Pro instead everything is fine. I do not >>> change anything but the address. Same protocol is used for both RAMs. >>> My problem is that I do not have a simulation model for the DDR RAM. It >>> is a Kingston KVR266X64C25/256. All I can do during simulation is to >>> look what the PLB DDR controller is writing to the output pins. And the >>> simulation does not show any wrong behavior at this point. I can not >>> perform any read accesses since there is no RAM model atttached. So >>> currently for tests the only way is to use the real board but here I can >>> not see, what is happening. >>> Does anybody know, where I can get a simulation model for this RAM? I >>> have searched the Kingston page. I have sent them an E-Mail (still >>> waiting for response). I have tried Google but I could not find >>> anything. Same here. >>> Thanks in advance >>> Sebastian Goller >> Kingston makes DIMMs not RAMs. You can find RAM models on Micron's >> website. > > Thanks for your answer. I have taken a look at http://www.micron.com > (Design Support etc.) The problem is that I can not find a module that > has the specifications of the RAM I use in my design. > The KVR2666X64C25//256 has the following specs (according to the data > sheet): > > - 256MB 32M x 64-Bit > - DDR266 > - CL2.5 > - 184-Pin DIMM > > There is no module on Micron's site that has these specs. Every DDR266- > Module has a CL2.0. I can only choose between pin count 66 and 66- > ball. A depth of 256 MB is not available for DDR266. > I have looked at my design. There are 106 pins used for the interface > between the PLB DDR controller and the RAM module. So a pin count of > 66 does not seem useful to me. > I am sorry if ask very stupid questions, but it is the first time I > use DDR SDRAM. > You'll have to use a 'generate' statement to set up an array of Micron DRAM models so that it matches the configuration of the Kingston DIMM. There are some `defines (in the Verilog version) that allow you to configure the particular flavor of DRAM. If you are doing an RTL simulation (i.e., no IDELAY UNISIMs) you will be assuming that your timing is correct. To get a more accurate model, you need to use wires with bidirectional delays to model the PCB and IOB delay. One of the biggest problems with making your own DRAM interface is getting the return data to line up with your local clock. -KevinArticle: 122631
sriman wrote: > hi everyone > > i am trying to use RTOS in NIOS processor. After going through its > documentation i found that UC/OS2 and UClinux are the two versions > avaliable. I am interfacing my design to a Ethernet. i am using a DE2 > board. i found that UClinux has got native TCP/IP protocols that wil > help in easy interfacing of the WLAN module which i am using. > But the problem what i am facing is i dont have a license in linux > version software. i have it for windows. also according what i read in > documentations UClinux can be used only in Linux platform. > So what shall i do now. Is programming in US/OS2 the only > alternative. or can i do somethin so that i can program the uclinux in > linux and migrate it onto a windows sytem and use it in my design > Hi Sriman, Just note that UClinux isn't a true "Real-Time" operating system - RTOS. It is more considered and "Embedded OS". However, there apparently are real-time "extensions" such as RTLinux and RTAI that can be used to make it "real-time". But if you don't need your OS to be a "real-time" OS but just need the TCP/IP stack, UCLinux is suitable. PretzelX.Article: 122632
Georg Acher wrote:
> I can't believe that there is no cleanVHDL equivalent to a pure wire in a
> schematic...
This does seem strange, but note
that this lack of zero-delay wire is
only a "problem" for interfacing to
models that chain combinational
signal assignments inside a process
or otherwise skew the simulation clock.
There are many ways to get this right.
Mine is to use signals only
in purely structural entities.
-- Mike Treseler
Article: 122633Ioiod wrote: (snip) > On Solaris SPARC, 64-bit mode was definitely slower than > 32-bit mode, by about 10-20%. > For the life of me, I can't understand why the AMD would > run 64-bit mode faster than its 32-bit mode > -- but for every other machine architecture, > 64-bit mode is almost always slower. It might be because more registers are available, and IA32 code is register starved. -- glenArticle: 122634
ghelbig@lycos.com writes: > My concern is that I don't see a stable replacement in the near > future. It really isn't fair to Xilinx to have them support the large > number of popular Linux systems. Xilinx supports Red Hat Enterprise Linux 3 and 4; I expect that they'll add support for RHEL 5 in the near future, if they haven't already. I've never had any significant problems running software intended for RHEL on Fedora and Centos (the latter being a clone of RHEL). Many people report success on Debian, Ubuntu, and other Linux distributions. Almost all commercial EDA software for Linux supports RHEL. It doesn't seem too onerous to expect customers that pay thousands of dollars for EDA software and want to run it on Linux to either run RHEL, or live with whatever minor issues might arise when trying to use a different Linux distribution. EricArticle: 122635
Christopher Cole wrote: > Does there exist a 64-bit Linux version of Xilinx Webpack? I see the > programming tools are available for Linux as 64-bit... No. The 32-bit version works fine on 64-bit Linux, aside from needing to trick the install script.Article: 122636
hitsx@hit.edu.cn wrote: (I wrote) >>You might prescale the floating point data in software before >>sending it through the FPGA based hardware. I would probably >>consider 24 bits intermediate data for a 16 bit result. >>Look for books or papers on systolic array implementations >>of matrix operations. >>About how much can you spend on hardware? hundreds, thousands, >>or millions of dollars? > Can you recommend some books about this field? > The budget should be tens of thousands of dollars. http://www.google.com/search?hl=en&q=%22systolic+array+processor%22+reconstruction Should get you started. Tens of thousands of $ might mean that you should use an existing board with FPGA(s) on it. One large one might be about right. -- glenArticle: 122637
Hi JJ, Here is a rather long but detailed reply to your questions courtesy of Adrian, one of our parallel compile experts. You were correct in guessing that quartus_fit included floating-point operations, but as other writers here have responded, memory accesses are easily as important in terms of runtime, if not more so. By contrast, quartus_sta is dominated by integer operations and memory accesses. Incidentally, this is why quartus_fit will produce a different fit on different OS's while quartus_sta will not - integer operations are exact across all platforms but the different compilers optimize floating-point operations differently between Windows and Linux, which result in a different fit. Quartus II's new NUM_PARALLEL_PROCESSORS is required to enable any kind of parallel compilation. We do not offer any support for HyperThreaded processors and actually recommend our users disable it in the BIOS, as it can decrease memory system performance even for a normal, non-parallel compilation. By contrast, multi-core machines yeild good results. If you have an Intel Core 2 Duo, for example, you'd set NUM_PARALLEL_PROCESSORS to 2. If you have two dual-core Opterons, you'd set it to 4, and so on. Currently, some parts of quartus_fit, quartus_tan and quartus_sta can take advantage of parallel compilation, though the best improvement is usually in quartus_fit. Small designs and those with easy timing and routability constraints will typically not see much improvement, but larger and harder-to-fit circuits (the designs that need it the most!) can see substantial reductions. While the speedups are currently modest and nowhere near linear with the number of processors used, they have improved with every release since Quartus 6.1 and we plan to continue this in future releases. We do not currently support additional parallel features during incremental compilation; ie, different partitions will not be mapped and fit completely in parallel; the fitter will get as much benefit from parallel compilation as it would without any partitions. One gotcha with parallel compilation is related to my first point about Quartus having lots of memory accesses. On some current systems, the memory system can become a significant bottleneck. For example, an Intel Core 2 Quad chip has two shared L2 caches, which enables very fast communication between cores (1,2) and (2,3), but relatively slow communication between (1,3) and (2,4) since those memory requests must all share the front-side bus. In this case, setting NUM_PARALLEL_PROCESSORS to 4 may even give a worse result than setting it to 2 by forcing half the communication to take place over this slower FSB. Even with only two processors in use, the OS may sometimes schedule the processes on cores (1,3) and (2,4) unless you specify otherwise. Solutions to this problem can be found at www.altera.com/support. Not all platforms are affected; you'll have to try it and see. At present, Quartus II currently supports a maximum of four processors (or cores), so your dual Quad configuration will mostly go unused. However, your intuition about leaving a processor free is correct; if you have a four-core system and leave NUM_PARALLEL_PROCESSORS to 3, you will never see Quartus take more than 75% of your computer's CPU. As for different OS's, the 32-bit Windows version of Quartus is a little faster than the Linux version; the differences are largely due to the quality and settings of the optimizing C compilers we use on these two platforms, and varies somewhat between various Quartus executables. 64-bit versions of Quartus are slightly slower than 32- bit versions due to the increase in working set size (memory) from 64- bit pointers; this in turn reduces cache hits and thus slows down the program. This behaviuor is true of most 64-bit applications. Note: You can run 32-bit Quartus in 64-bit Windows/Linux with no such performance penalty, and gain access to 4 GB of addressable memory. This should meet user needs for all but the largets and most complicated of Stratix III designs. See information on memory requirements of Quartus at http://www.altera.com/products/software/products/quartus2/memory/qts-memory.html. Also, I've posted on this topic previously (http://tinyurl.com/ 36boga). Regards, Paul Leventis Altera Corp.Article: 122638
> Anandtech ran an article which does quite a good job in explaining the 2 > and 3 GB barriers.http://www.anandtech.com/gadgets/showdoc.aspx?i=3034 As mentioned in the Anandtech article, there are stability issues with running in 3GB mode. We have seen these stability issues with Quartus on WinXP w/3GB mode. If you need more 2GB of memory for your Quartus executable, your best bet is to run 32-bit Quartus on (a) 32-bit or 64- bit Linux or (b) 64-bit Windows. Regards, Paul Leventis Altera Corp.Article: 122639
On Jul 27, 10:34 am, Frank Buss <f...@frank-buss.de> wrote: > Nial Stewart wrote: > > I ran a fairly quick FPGA build through Quartus to get a time for a > > before and after comparison before I did the swap. > > Did you changed the setting "use up to x number of CPUs" (don't remember > the exact name) somewhere in the project settings? Yes, turning on multiple CPU support (NUM_PARALLEL_PROCESSORS setting) will help :-) It will also depend on whether this is a slow or fast compile. A toy design will see no speed-up, since the run time will be dominated by aspects of the compiler that are normally a small portion of run time -- reading databases from disk, setting up data structures, etc. It is only the key time-consuming algorithms that have been parallelized (and only some of them at that). Gains will be the largest on large designs with compilcated timing assignments. Regards, Paul Leventis Altera Corp.Article: 122640
> Don't know about Primetime, but > the latest spin from altera promotes > Synopsys Design Constraints (SDC) format:http://www.fpgajournal.com/whitepapers_2007/q2_altera_1.htm > > Quartus now supports this and their simpler "classic" STA. > I've tried both, and they work, > but I don't know enough to have a preference yet. Hi Mike, We recommend that users switch to using TimeQuest. There are a number of benefits to doing so. In general, TimeQuest is better at handling complex timing assignments and analysis (multi cycles, related clocks, recovery/removal analysis, multi-corner timing analysis, etc). It also has a powerful, standard language (SDC) for specifying constraints, and is fully Tcl driven. It is really quite powerful. An addtiional benefit is you will get a few % faster design performance using TimeQuest as your analysis engine, especially on the latest Altera FPGA families. Because of some of the more advanced analysis capabilities in TimeQuest, complex timing phenomena that we needed to "guardband" in the classic Timing Analyzer can now be analyzed less conservatively (but still correctly). In short, you get more robust timing analysis and better design performance by moving to TimeQuest. There is a learning curve, but once you are over it I'm sure you will appreciate the added power that this tool gives you. Regards, Paul Leventis Altera Corp.Article: 122641
Hi Tommy, > > For the Stratix III, I see Altera called this feature "M-LAB." > MLAB are one of three different kinds of hard memory blocks. They are > not LUT RAM. The MLAB is a block that can function either as a normal LAB or as a 640-bit (32x20 or 64x10) memory; half of the logic blocks in Stratix III are MLABs, and half are logic-only LABs. You are right that there is a trade-off providing hybrid logic/memory capabilities in a device. There is additional circuitry that costs silicon area -- is that area better spent on conversion capability or should it just be spent directly on more area efficient but dedicated RAMs? In Stratix III, the circuitry necessary for RAM mode in MLAB is shared amoung all the ALMs in the MLAB, reducing the silicon area penalty associated with other techniques for combining logic and memory functionality. Readers are correct that Cyclone III does not support any form of hybrid logic/memory block, but the architecture is quite RAM rich as it stands. Regards, Paul Leventis Altera Corp.Article: 122642
> My wording may be a little unflatering, but I think that it's true for > low/medium-end designs. The real differences only show up when you > want to get the most out of these devices. Thats why I added the > specific designs exeption, there will be designs where it does matter. If you aren't pushing performance, power, or price and don't care about any particular software feature, any chip will probably do. But I would contend (perhaps even agree with Peter) that there are significant differences between Altera and Xilinx's products. I would suggest you sit down, take a quick inventory of what you need from your FPGA device, decide whether you fit in the low-cost (Cyclone / Spartan) or high-end (Stratix / Virtex) space, and then start comparing device features. Talk to a sales rep from each company to find out price. Download the free software and kick the tires a little and see what you like. And read some literature / marketing stuff on device performance and power. And Peter, the answer is clearly Canada :-) Regards, Paul Leventis Altera CANADA Corp.Article: 122643
On Aug 1, 9:29 pm, Paul Leventis <paul.leven...@gmail.com> wrote: > We recommend that users switch to using TimeQuest. There are a number > of benefits to doing so. In general, TimeQuest is better at handling > complex timing assignments and analysis (multi cycles, related clocks, > recovery/removal analysis, multi-corner timing analysis, etc). It > also has a powerful, standard language (SDC) for specifying > constraints, and is fully Tcl driven. It is really quite powerful. > > An addtiional benefit is you will get a few % faster design > performance using TimeQuest as your analysis engine, especially on the > latest Altera FPGA families. Because of some of the more advanced > analysis capabilities in TimeQuest, complex timing phenomena that we > needed to "guardband" in the classic Timing Analyzer can now be > analyzed less conservatively (but still correctly). > > In short, you get more robust timing analysis and better design > performance by moving to TimeQuest. There is a learning curve, but > once you are over it I'm sure you will appreciate the added power that > this tool gives you. I'm not a EE and have always been a bit daunted by the more obscure timing analysis. Assuming that I use only synchronous logic and the only timing constrain I used in the "classic tool" was on the clock, is there any benefit for me switching to TimeQuest and what to I need to do for such a trivial constraint? Thanks, TommyArticle: 122644
> I'm not a EE and have always been a bit daunted by the more obscure > timing analysis. Assuming that I use only synchronous logic and the > only timing constrain I used in the "classic tool" was on the clock, > is there any benefit for me switching to TimeQuest and what to I need > to do for such a trivial constraint? Hi Tommy, Take a look at the TimeQuest Analyzer Quick Start Tutorial (http:// www.altera.com/literature/hb/qts/ug_tq_tutorial.pdf). One advantage from using TimeQuest will be a small (few %) increase in achieved performance in recent FPGA families. Another is that recovery & removal analysis and optimization will be performed by default, which can identify timing and fix problems on asynchronous signals in your design. You also get a much more powerful GUI/interface that allows you to see more information on your failing paths. And don't forget that if you learn TimeQuest you'll be one step closer to correctly analyzing more complex timing relationships in the future! Regards, Paul Leventis Altera Corp.Article: 122645
On Aug 1, 9:48 pm, Paul Leventis <paul.leven...@gmail.com> wrote: > > > And Peter, the answer is clearly Canada :-) > Paul Leventis > Altera CANADA Corp. Of course, Paul. I thought of you when I wrote it... Cheers PeterArticle: 122646
In comp.arch.fpga, Paul Leventis <paul.leventis@gmail.com> wrote: > > If you aren't pushing performance, power, or price and don't care > about any particular software feature, any chip will probably do. But > I would contend (perhaps even agree with Peter) that there are > significant differences between Altera and Xilinx's products. I would > suggest you sit down, take a quick inventory of what you need from > your FPGA device, decide whether you fit in the low-cost (Cyclone / > Spartan) or high-end (Stratix / Virtex) space, and then start > comparing device features. Talk to a sales rep from each company to > find out price. Download the free software and kick the tires a > little and see what you like. And read some literature / marketing > stuff on device performance and power. Requirements are very modest and will fit with ease in the lowest cost chips. Got prices for both. Talked to one FAE, the other one is on holiday. I've ordered the low-cost dev-kit from both. I'll go through at least the first sample designs (led blink?) to get a feel for both. Have not checked power yet, will do when I get the boards. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 122647
Hello, I have a microblaze design which includes two bram with microblaze's bram. I want to write the addresses of dip_switches to second bram.How can i write this code in Xilinx Platform Studio SDK? PS:Where can i find detailed documentation about SDK's libraries and their functions? Regards, Fatih GunesArticle: 122648
On Aug 1, 4:00 pm, bybell <byb...@rocketmail.com> wrote: > On Jul 26, 6:07 pm, davem <david.maccu...@googlemail.com> wrote: > > > My version ofGtkWave(3.81) doesn't show the Signal Search Tree (SST) > > window by default either. You can bring it up by selecting Signal > > Search Tree from the Search menu. Or you can use the shortcut Shift- > > Alt-T. > > 1) Upgrade to the 3.x series. The latest is 3.0.30. > 2) Make sure you are compiling against gtk v2.8 or higher. The > collapsing widget needed for the integrated tree doesn't exist in > earlier versions of the toolkit. > After downloading and compiling the latest version of gtkwave, I see the SST widget now. Previously I was using the current stable debian package version of gtkwave, which often isn't the latest. > > When usingGtkWave, I can't show up vhdl signals created from > > enumerated types such as state vectors. I'm think older versions ofGtkWavedid show enumerated types, but I'm not sure. Anyone else had > > this problem? > > Nothing changed in the viewer; perhaps the dumper in your vhdl > simulator did. To see enumerated types your dumper needs to support > it (e.g., using the "s" gtkwave extension for VCD) or you need to use > an external process/file filter that converts values to text strings. > See the pdf user manual for specifics. > > -t I think your right, the problem is likely related to the older version of ghdl (the vhdl simulator I am using) which again is the debian stable version. Converting the enumerated types to strings sounds like a good idea. Thanks for the heads up, I will take a glance at the gtkwave user manual. DaveArticle: 122649
> > Any specific box recommendations? > I'd recommend running them on MicroBlaze.. good opportunities for h/w acceleration ;-) Jon
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