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 have FPGA DSP design that has several RAM blocks. What is the easiest way to transfer the content of the RAM to the PC? I am using Xilinx Virtex-4 ML402 board with Platform Cable USB. Thanks, DanArticle: 122676
We want to be able to save our PPC state to ram, shut off our fpga, and be able to restore the PPC when we wake up later. Seems like this should be a pretty common problem. Can anyone suggest how best to do this or maybe provide a working example? Thanks, ClarkArticle: 122677
TimeQuest is not quite PrimeTime, but a very impressive STA tool especially as part of a low-cost suite. Coming from a Design Compiler / PrimeTime background, I managed to find many of the kinks and shortcomings in early versions of TimeQuest, and Altera worked through them quickly and diligently. I could probably still find a few SDC constraints it doesn't support (or support exactly like PT), but it's been good enough for a HardCopyII tapeout. As far as accuracy goes, when Quartus/TimeQuest generates a netlist for PrimeTime, it also generates the SDF timing data, which is coincidentally the exact same numbers TQ computed. PT reads the SDF and obviously reports the same numbers as TQ, so PT adds no value there. If you don't use the SDF, then PT's calculations are garbage, because PT is optimized to do deep submicron timing calculations based on SPF/SPEF and other detailed physical information that it just doesn't get from Altera's libraries or placement files. However, if you're fluent in Tcl scripting and familiar with PrimeTime, PT offers a lot more powerful netlist navigation commands for finding and reporting on certain nodes, collections of nodes, and so on. Since those are really API commands instead of SDC constraints, Altera does not have to support them to be SDC compliant. As a result, some of my fancy PrimeTime scripts won't run in TimeQuest. I also found that some of the naming conventions were not the same in the TQ netlist/database and PT netlist/database, and areas like clock pins on a source-synchronous DDR output were not handled correctly a few revisions ago (I haven't revisited them lately). Another oddity is that TQ makes some kind of modifications to the database when operating on it (and I really disapprove of that). I typically open 4 STA windows (HardCopy fast, HardCopy slow, Stratix fast, Stratix slow) and analyze them all as one big interactive session. PrimeTime has no problem with this, but since the Quartus max and min data for a Stratix run winds up in the same directory, you can't (couldn't a few revs ago) analyze max and min simultaneously in TimeQuest. However, I could compare Stratix fast and HardCopy fast side-by-side (ditto for slow corner), but never all 4 at the same time in TQ. As far as performance goes, TQ (standalone) is fast. As the integrated timing engine used during quartus_fit, it seems to run faster and produce faster designs (on my limited testcases). As far as whether PT catches more violation than TQ, I don't really think that's quite the issue. Both only report timing on paths that are constrained (be default), so if you've missed some constraints, neither tool can report a timing violation. In both tools you can check for unconstrained paths, and both tools do a good job of catching them. For unconstrained paths, you can set a variable that allows PT to report them with the report_timing -from -through -to commands. I think TQ requires a report_path command or something slightly different in that case (another minor annoyance). Summary: PT = no major advantage for FPGAs, except in netlist navigation and scripting (and vendor independence) TQ = very good imho, but not in the same ballpark as PT. (The $50K+ price difference and maturity of the tool might have something to do with that! ;)Article: 122678
Good luck! I think the fastest LVDS serdes you can do in StratixII (non-GX) is 840 Mbps nominal, and 1Gbps with their ALT_LVDS macro and DPA (dynamic phase alignment) turned on. If anyone can get it running faster, I look forward to seeing how.Article: 122679
I am relying to the older "Spartan 3E starter kit DDR SDRAM code Options" thread. Is there such a demo out, mentioned in the thread? I read in several groups that it is a problem to get this DDR Ram running ?Article: 122680
On Aug 2, 3:53 pm, fpgauser <fpgaengineerfrankf...@arcor.de> wrote: > I am relying to the older "Spartan 3E starter kit DDR SDRAM code > Options" thread. > > Is there such a demo out, mentioned in the thread? > > I read in several groups that it is a problem to get this DDR Ram > running ? I'm not sure what you're refering to, but David Ashley ported the OpenCore DDR SDRAM controller to the Spartan-3E500 start kit and posted it here. I only had to adjust the .ucf file a bit to get it on the Spartan-3E1600 Starter kit. TommyArticle: 122681
Hi Steve, Could you give us (Xilinx users) some more detailed recommendations on what would be the best platform to run ISE/EDK tools when working on midsize to big designs? Tell us what you are using @ Xilinx? :) Thanks, /Mikhail <steve.lass@xilinx.com> wrote in message news:f8tksu$caa1@cnn.xilinx.com... > "Wei Wang" <camwwang@gmail.com> wrote in message > news:1186091680.680639.251840@z24g2000prh.googlegroups.com... >> Found similar memory recommendations for Xilinx's largest XC5VLX330 >> FPGA, >> http://www.xilinx.com/ise/products/memory.htm#v5lx >> only Linux-64 machines are supported, memory recommendation: typical >> 7.2GB and peak 10.6GB. > > This web page needs to be updated: NT64 is also supported, but runtime > will be faster on Linux64, so that's what we recommend. > > Steve >Article: 122682
I can give you some general recommendations. For the best place and route runtimes, use a 64bit Linux system. If your design is small enough to fit into 4G of memory (LX110 or smaller), and you are not programming devices (the 32bit cable drivers don't work on a 64bit system), you can use the 32bit executables to save memory. Otherwise, go ahead and use the 64bit executables. They use more memory and the runtime is simular. As mentioned earlier, synthesis, map, place and route do not use multithreading, so you will not get an advantage using multiple processors for a single design. However, ProjNav is multithreaded so if you are doing different tasks, other processors will be used. In addition, upcoming software releases will use those processors. Steve "MM" <mbmsv@yahoo.com> wrote in message news:5hf8n2F3k0uqkU1@mid.individual.net... > Hi Steve, > > Could you give us (Xilinx users) some more detailed recommendations on > what would be the best platform to run ISE/EDK tools when working on > midsize to big designs? Tell us what you are using @ Xilinx? :) > > > > Thanks, > /Mikhail > > > > > <steve.lass@xilinx.com> wrote in message > news:f8tksu$caa1@cnn.xilinx.com... >> "Wei Wang" <camwwang@gmail.com> wrote in message >> news:1186091680.680639.251840@z24g2000prh.googlegroups.com... >>> Found similar memory recommendations for Xilinx's largest XC5VLX330 >>> FPGA, >>> http://www.xilinx.com/ise/products/memory.htm#v5lx >>> only Linux-64 machines are supported, memory recommendation: typical >>> 7.2GB and peak 10.6GB. >> >> This web page needs to be updated: NT64 is also supported, but runtime >> will be faster on Linux64, so that's what we recommend. >> >> Steve >> > >Article: 122683
Steve Lass wrote:
> I can give you some general recommendations. For the best place and
> route runtimes, use a 64bit Linux system. If your design is small
> enough to fit into 4G of memory (LX110 or smaller), and you are not
> programming devices (the 32bit cable drivers don't work on a 64bit
> system), you can use the 32bit executables to save memory.
> Otherwise, go ahead and use the 64bit executables. They use more
> memory and the runtime is simular.
Note that it works just fine to install 32-bit ISE on a 64-bit Linux
system, and to install the 64-bit cable drivers.
In my experience, the open source user-space-only cable interface works
far better than the Xilinx-supplied cable drivers anyhow:
http://www.rmdir.de/~michael/xilinx/
Article: 122684Erik Widding wrote: > Mike, given that Xilinx did not do this in the unisim package, what do > you consider to be the cleanest way to verify functional code that > interfaces with these badly written (IMHO) models? Inserting delays > on signals, that the synthesis tool is later going to ignore, seems > like a horrible band-aid. My choice is to write my own code that can be used directly for synthesis and simulation. If I instance a vendor netlist to "save time" I have no choice but to make due, somehow, with the vendor sim model. > Does it make any difference to the simulation tool if the primitives > are instantiated in parallel with a functional module within a higher > level structural module, versus being instantiated within an otherwise > functional module? I don't simulate primitives, just code. I use STA to verify timing. -- Mike TreselerArticle: 122685
On 2007-08-02, Wei Wang <camwwang@gmail.com> wrote: > Why only 3GB max of 4GB? thanks, -Wei The short answer is that the upper 1GB is reserved for the kernel. If you want a bit more detail you can look at for example the following article: http://kerneltrap.org/node/2450 /AndreasArticle: 122686
hi I am trying to interface a camera module to FPGA board. i am new to VLSI. can any suggest and help me out of where to start and how to proceed. i am working on Altera DE1 board. not sure yet of which camera module to use. can you people help me out/..Article: 122687
<steve.lass@xilinx.com> wrote in message news:f8tr6p$c9h1@cnn.xilinx.com... > I can give you some general recommendations. For the best place and route > runtimes, > use a 64bit Linux system. If your design is small enough to fit into 4G of > memory > (LX110 or smaller), and you are not programming devices (the 32bit cable > drivers > don't work on a 64bit system), you can use the 32bit executables to save > memory. > Otherwise, go ahead and use the 64bit executables. They use more memory and > the runtime is simular. Is there a 64-bit version of EDK ? If not, can I mix 64 bit ISE with 32 bit EDK? Thanks, /MikhailArticle: 122688
Unless you want to build the A-D, you'll need one with a digital output, try the: C3188A - 1/3" Digital Output Colour Camera Module "sriman" <srimankk@gmail.com> wrote in message news:1186120969.013793.20900@d30g2000prg.googlegroups.com... > hi > > I am trying to interface a camera module to FPGA board. i am new to > VLSI. can any suggest and help me out of where to start and how to > proceed. i am working on Altera DE1 board. not sure yet of which > camera module to use. can you people help me out/.. >Article: 122689
I should probably add: More information on MIG can be found on the Memory Corner on xilinx.com: http://www.xilinx.com/products/design_resources/mem_corner/Article: 122690
On Aug 3, 1:00 am, <steve.l...@xilinx.com> wrote: > I can give you some general recommendations. For the best place and route > runtimes, > use a 64bit Linux system. If your design is small enough to fit into 4G of > memory > (LX110 or smaller), and you are not programming devices (the 32bit cable > drivers > don't work on a 64bit system), you can use the 32bit executables to save > memory. > Otherwise, go ahead and use the 64bit executables. They use more memory and > the runtime is simular. > > As mentioned earlier, synthesis, map, place and route do not use > multithreading, so > you will not get an advantage using multiple processors for a single design. > However, > ProjNav is multithreaded so if you are doing different tasks, other > processors will > be used. In addition, upcoming software releases will use those processors. > > Steve > > "MM" <mb...@yahoo.com> wrote in message > > news:5hf8n2F3k0uqkU1@mid.individual.net... > > > > > Hi Steve, > > > Could you give us (Xilinx users) some more detailed recommendations on > > what would be the best platform to run ISE/EDK tools when working on > > midsize to big designs? Tell us what you are using @ Xilinx? :) > > > Thanks, > > /Mikhail > > > <steve.l...@xilinx.com> wrote in message > >news:f8tksu$caa1@cnn.xilinx.com... > >> "Wei Wang" <camww...@gmail.com> wrote in message > >>news:1186091680.680639.251840@z24g2000prh.googlegroups.com... > >>> Found similar memory recommendations for Xilinx's largest XC5VLX330 > >>> FPGA, > >>>http://www.xilinx.com/ise/products/memory.htm#v5lx > >>> only Linux-64 machines are supported, memory recommendation: typical > >>> 7.2GB and peak 10.6GB. > > >> This web page needs to be updated: NT64 is also supported, but runtime > >> will be faster on Linux64, so that's what we recommend. > > >> Steve- Hide quoted text - > > - Show quoted text - What I found was very interesting, it was taking me 12 hours to run the MAP process before, but yesterday it only took me ~3 hours to run MAP, and PAR only too took ~40 mins as well. I was trying to figure out the reasons, then found in *.map *.mrp files that there was always a map phase which took such a long time as ~10+ hours, and that phrase was always very memory hungry. I was using Linux64 with 2GB real memory and 4GB swap memory, as I just found that the real 2GB memory was much smaller than the required peak memory 10.6GB. Yesterday, I was running ISE9.1i for XC5VLX330 on another Linux64 machine with 11G real memory and 8G swap memory, the there wasn't any MAP phrase which took a ridiculous ~10+ hours. Can Xilinx guys shed some more light on the runtime of MAP and PAR, wrt different memory sizes and CPU cores?Article: 122691
On Aug 3, 10:55 am, "jacob...@xilinx.com" <naude.j...@gmail.com> wrote: > I should probably add: More information on MIG can be found on the > Memory Corner on xilinx.com:http://www.xilinx.com/products/design_resources/mem_corner/ Looks like my first message was not posted correctly: The Xilinx Memory Interface Generator (MIG) generates ready-to-use HDL for the Spartan-3E Startker Kit. Cheers, JacoArticle: 122692
Evan Lavelle schrieb: > On 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? > > Evan A video game cartridge. Containing the EPROM (program and data), EEPROM (for savegames) and CPLD (bank switching, access to I²C). PhilippArticle: 122693
On Aug 2, 11:11 am, vasile <picli...@gmail.com> wrote: > Hi, > Who could enlighten me with the followings: > > I need to interface a SERDES transciever from a VIRTEX5 FPGA with a > STRATIX II IO. Things would be easiest if I'll have a Stratix II GX > instead of Stratix II, but the GX FPGA has no HARDCOPY II structured > Altera ASIC corespondent, so I can't use a GX because of finacial > reasons (and huge ball numbers, improper for this design). > > How could I get an equivalent of 3Gbps SERDES transciever (like GX > has) using only high speed differential IO available in STRATIX II? > > thank you, > Vasile If cost and size is a concern and you're not stuck on Altera you might want to look at Lattice's ECP2M family. Comes in packages as small as 256 pins, provides 3 Gig SERDES, and is very cost effective. Thanks, John DimtsiosArticle: 122694
On 2 ao=FBt, 15:15, jjohn...@cs.ucf.edu wrote: > P.S. Those QX6850's are hard to come by; Dell's overclocked XPS720's > look sweet, but my company won't spring for overclocked boxes... Polywell has some desktop computers with QX6850 available. Although since you're looking at an 8-way workstation (!), QX6850 is probably not an option. Polywell has AMD or Intel workstations with the CPUs you're looking at as well. For one socket, Intel clearly has the edge over AMD I think. For multi- socket workstations/servers however, I'm not so sure. Benchmarks are harder to find. I would suspect that the Hypertransport bus would help AMD close the gap with Intel a little. Their integrated memory controller probably helps as well in a multi-socket machine. I searched for benchmarks for the newest 90-nm Opteron but couldn't find any unfortunately... PatrickArticle: 122695
"Wei Wang" <camwwang@gmail.com> wrote in message news:1186135446.310054.313850@g4g2000hsf.googlegroups.com... > > What I found was very interesting, it was taking me 12 hours to run > the MAP process before, but yesterday it only took me ~3 hours to run > MAP, and PAR only too took ~40 mins as well. > > I was trying to figure out the reasons, then found in *.map *.mrp > files that there was always a map phase which took such a long time as > ~10+ hours, and that phrase was always very memory hungry. I was using > Linux64 with 2GB real memory and 4GB swap memory, as I just found that > the real 2GB memory was much smaller than the required peak memory > 10.6GB. Yesterday, I was running ISE9.1i for XC5VLX330 on another > Linux64 machine with 11G real memory and 8G swap memory, the there > wasn't any MAP phrase which took a ridiculous ~10+ hours. > > Can Xilinx guys shed some more light on the runtime of MAP and PAR, > wrt different memory sizes and CPU cores? > Yes, that indeed would be great! With my current design I found that timing-driven MAP either crashes or takes very long time to complete (relative to PAR). Even more interesting is that I get much better timing and much faster run times by actually disabling timing-driven mapping and use of RLOC constraints in MAP... /MikhailArticle: 122696
Rob wrote: > Peter, > > I'm not being a wise guy by an stretch. I am seriously inquiring for my own > edification. > > Name some things that Xilinx can do that Altera can't or more specifically, > is there an application out there in the world today that can only be solved > with a Xilinx part? Would it be a fair statement to say that >90% of the > designs out there can be done effectively with either company and the real > advantages lie more with: > > 1. Service > 2. Tools > 3. Price > 4. Delivery > 5. Familiarity: meaning that once someone starts with a certain vendor, > uses them for a while, and understand the hardware and how to flex it, > they're less likely to switch--especially since most of us are put on > ridiculous delivery schedules. > > Again, not trying to raise ire, just humbly asking a question. > > Best regards, > Rob > The different devices have different features. As a result a design for the same end purpose executed in an Altera device may be very different from a design executed in a Xilinx device. This is particularly true if you are pushing the performance or density envelopes. An example of this is a design that needs many very small memories (short reorder queues for example) might be considerably more compact in Xilinx by taking advantage of the SRL16 primitives. A design with strictly 8 or 9 bit arithmetic and lots of multiplies might be a better fit to Altera Stratix because of it's 9x9 multipliers. It isn't a matter of one device being unsuitable as much as it is an issue of one device being better suited.Article: 122697
On Thu, 02 Aug 2007 15:36:59 -0700, jjohnson@cs.ucf.edu wrote:
>However, if you're fluent in Tcl scripting and familiar with
>PrimeTime, PT offers a lot more powerful netlist navigation commands
>for finding and reporting on certain nodes, collections of nodes, and
>so on. Since those are really API commands instead of SDC constraints,
>Altera does not have to support them to be SDC compliant. As a result,
>some of my fancy PrimeTime scripts won't run in TimeQuest.
I had a quick look at the 'SDC and TimeQuest API Reference Manual'
this morning. It looks pretty good at first sight, but some of the
omissions look like they might be a problem. It's got the basic
all_clocks/inputs/outputs/registers, for example, but doesn't support
any options on all_inputs/outputs/registers. how do you do something
simple like
report_timing -from [get_ports {CLK}] -to [all_registers -clock CLK -
clock_pins]
?
The filter option on the get_ commands is much more limited than the
PT filter option. Collections also look very limited; no
add_to_collection, remove_from_collection, filter_collection, etc.
Still, it looks pretty good for an FPGA tool.
>Summary:
>PT = no major advantage for FPGAs, except in netlist navigation and
>scripting (and vendor independence)
>TQ = very good imho, but not in the same ballpark as PT.
>(The $50K+ price difference and maturity of the tool might have
>something to do with that! ;)
I have to admit that I don't understand what the big deal in FPGA
timing is. All the hard work has already been done by the big-$ tools,
before the customer even starts a design. The FPGA tool then just
summarises what PT/whatever has already told it. So, if you're an
end-user, what's the point of using PT *again* to get back the same
numbers?
Evan
Article: 122698"Wei Wang" <camwwang@gmail.com> wrote in message news:1186135446.310054.313850@g4g2000hsf.googlegroups.com... > Can Xilinx guys shed some more light on the runtime of MAP and PAR, > wrt different memory sizes and CPU cores? > Even though our memory requirement table lists devices, memory is more dependent on the design and the timing constraints. Since we can't predict what is in your design, we just give you the typical and max numbers from our collected test cases. An example for constraints which will reduce memory is instead of creating a bunch of individual from to timespecs, you can create timegroups with the endpoints, then put one timespec on that. Also, ISE 9.2i is getting an average of 27% improvement in memory utilization. I don't have any data regarding runtime of different CPU cores. SteveArticle: 122699
Evan Lavelle wrote:
> I have to admit that I don't understand what the big deal in FPGA
> timing is. All the hard work has already been done by the big-$ tools,
> before the customer even starts a design.
For a conservative designer with a rational
synchronization plan, I agree. Certainly I
can't move devices around, and I find it
difficult to beat the vendor tools at floorplanning.
I find that my time is better spent at
the code and device selection level.
Maybe I have to add some latency.
Maybe I have to spec a faster part.
-- Mike Treseler
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