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
Hi, I use the ISE 6.3i. I also try it with the ISE 8.2i in my University, but it doesn't work with the macro, I think so. This is the error message when I use 8.2i: WARNING:Pds:119 - Attempted to load old format .nmc file "C:\THANG\CPR1\implementation\top_level_initial/bm_4b_v2p.nmc", but this format is no longer supported. EXCEPTION:Pds:Pds_PahFileConv.c:124:1.17 - Database conversion failed. FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:127:1.5.56.1 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. This project is really important to me. I start working on my master thesis, and this is my first step. Thank you for your answers.Article: 109751
Hi Thang, the NMC/NCD format has changed between ISE6/7. There is a way to convert the macros, but i would suggest to use the ones from the xilinx website for PREAT8 flow. The Early Access Partial Reconfiguration Suite contains basic busmacros, examples, and much more. It may also be possible, if you, for whatever reason, not be able to use ISE8.1, to use the old patch for partial reconfiguration, based on ISE6.3. A new partial reconfiguration patch, based on ISE 8.2, should become available soon. Regards, Jens THANG NGUYEN schrieb: > Hi, I use the ISE 6.3i. I also try it with the ISE 8.2i in my University, but it doesn't work with the macro, I think so. This is the error message when I use 8.2i: > > WARNING:Pds:119 - Attempted to load old format .nmc file "C:\THANG\CPR1\implementation\top_level_initial/bm_4b_v2p.nmc", but this format is no longer supported. EXCEPTION:Pds:Pds_PahFileConv.c:124:1.17 - Database conversion failed. FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:127:1.5.56.1 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. > > This project is really important to me. I start working on my master thesis, and this is my first step. Thank you for your answers.Article: 109752
Hello all,
Following some discussion in these groups and reading a couple of
articles (especially the first one turning up when you google for
"asynchronous synchronous reset design techniques", it seems that the
best and the safest way to use resets in FPGA designs is to use a
special synchronizer circuit that assures that the reset of the FFs is
asserted asynchronously, but is deasserted synchronously.
The circuit is something like (kindly borrowed from the aforementioned
article):
~~~~~~~~
entity reset_synchronizer is
port
(
clk, async_reset_n: in std_logic;
sync_reset_n: out std_logic;
);
end reset_synchronizer;
architecture rtl of reset_synchronizer is
signal rff1: std_logic;
begin
process (clk, async_reset_n)
begin
if async_reset_n = '0' then
rff1 <= '0';
sync_reset_n <= '0';
elsif rising_edge(clk) then
rff1 <= '1';
sync_reset_n <= rff1;
end if
end process;
end rtl;
~~~~~~~~
When the asynchronous reset line enters this module, the synchronous
output can then be used as the _asynchronous_ reset of all FFs in the
design, as follows:
process (clk, sync_reset_n)
begin
if sync_reset_n = '0' then
ff <= '0';
elsif rising_edge(clk) then
ff ....
end if;
end process;
This seems to bring the best of all worlds - all the FFs in the design
enter reset asynchronously, without being dependent on the clock, and
exit reset synchronously. The synthesis tools can analyze the path
delays for sync_reset_n and report the times and skews.
Moreover, from a talk I had with Altera support engineers - they claim
this is the recommended way to code resets in designs, and that
Altera's tools will know to route sync_reset_n via fast global
interconnects to minimize time delay and skews. And in any case,
there's a report to see for each compilation.
What does this technique lack to be the perfect solution for resets in
FPGA designs ? It seems that it evades all the common disadvantages of
conventional sync and async resets.
Thanks in advance
Eli
Article: 109753hello thank you for your replay we allready tried this option before, but we have a problam, because we need to modify the data in the memory while the system is runing ( the in system memory size is to small for ower application), every 512 clock cycles. can we update the memory automaticly with new data from predefine files (hex files) while the system is runing? (it's not practiclly to rewrite manually every 512 clocks cycles, we need the system to run at least for 32768 clock cycles continusly, we can spend clock cycles as need to rewrite the content of the memory) thanks david Subroto Datta =D7=9B=D7=AA=D7=91: > It is definitely possible to update the memory and constants in a program= med > device from Quartus using the In System Memory Content Editor. Details can > be found at: > > http://www.altera.com/literature/hb/qts/qts_qii53012.pdf > > You can use this in conjunction wiith SignalTap II Embedded logic analyzer > to debug your work. > > Hope this helps, > Subroto Datta > Altera Corp. > > "david" <1024.david@gmail.com> wrote in message > news:1159976602.300018.42380@e3g2000cwe.googlegroups.com... > > hello > > i am a student, working on development kit nios 2 cyclone edition. > > i want to use the logic analyzer to import data to the fpga from the > > logic analyzer, can i do it? > >Article: 109754
Hi, We have an eval board with a spartan FPGA and a 75MHz XTAL Within ourt design, we require an accurate 16MHz clock. It is not possible to generate this frequency using a single DCM, is it possible to chain 2 DCM's together to generate the 16MHz clock ? (the obvious solution is to change the XTAL, but I'd like to know whether it is possible without changing the XTAL :-) ) Thanks for any feedback, StevenArticle: 109755
Hello again, There is one other question, although I am supposed to find this by myself but just to get an idea I want to ask: what is the maximum throughput I can get while running PCI opencores core at 33 Mhz in windows environment and in embedded environment where there is a dedicated PCI bus between two devices for example in a scenario where FPGA is communicating with a RISC processor via PCI bus. with best regards, Muhammad AdnanArticle: 109756
rickman schrieb: > Over the years I have gotten a lot of junk email from Xilinx to email > addresses that I have given out only to support and never to any > marketing channel. I have always been disappointed that Xilinx has > done this. But now they have sunk to a new low, they are giving or > selling my email address to third party junk emailers. I see that too. I think it is bad business practice. It does not make me feel that I can share sensitive information with them in a webcase or similar. And who knows whom Foundation ISE sends your source codes to. If a company sees cloak and dagger methods as part of their business model you can not trust them anymore. Kolja SulimmaArticle: 109757
Kolja Sulimma schrieb: > rickman schrieb: > > Over the years I have gotten a lot of junk email from Xilinx to email > > addresses that I have given out only to support and never to any > > marketing channel. I have always been disappointed that Xilinx has > > done this. But now they have sunk to a new low, they are giving or > > selling my email address to third party junk emailers. > > I see that too. > I think it is bad business practice. It does not make me feel that I can > share sensitive information with them in a webcase or similar. > > And who knows whom Foundation ISE sends your source codes to. > If a company sees cloak and dagger methods as part of their business > model you can not trust them anymore. > > Kolja Sulimma and did you notice that in ISE 8.2 there is now also a WEB-TALKBACK feature that ask you to submit your design statistics to Xilinx !? (similar to Altera software) however if in Altera enabling the talkback enables the free use of jtag logic analyzer features then the talkback in Xilinx is simple additional burden for you and you get nothing in return ! AnttiArticle: 109758
"Eli Bendersky" <eliben@gmail.com> wrote in message news:1160034231.247522.286040@m73g2000cwd.googlegroups.com... > Hello all, > > > This seems to bring the best of all worlds - all the FFs in the design > enter reset asynchronously, without being dependent on the clock, and > exit reset synchronously. The synthesis tools can analyze the path > delays for sync_reset_n and report the times and skews. > > Moreover, from a talk I had with Altera support engineers - they claim > this is the recommended way to code resets in designs, and that > Altera's tools will know to route sync_reset_n via fast global > interconnects to minimize time delay and skews. And in any case, > there's a report to see for each compilation. > > What does this technique lack to be the perfect solution for resets in > FPGA designs ? It seems that it evades all the common disadvantages of > conventional sync and async resets. It lacks nothing. In fact any design that does NOT generate a synchronously timed trailing edge reset is 'lacking' and will eventually fail because at some point that trailing edge of reset will come along at a time relative to the clock that violates setup/hold timing requirements and cause a flip flop or two to go to the wrong state. This is all assuming that the clock is free running (or at least running at the trailing edge of reset). The next question to ponder is, given that the reset must be synchronized anyway, why use an asynchronous reset anywhere in your design (with the exception of course of the above mentioned synchronizer)? People will pontificate on the subject but have yet to produce any coherent reason to prefer async or sync. Or they will claim some logic resource advantage that when you test the claim is found to be baseless (in almost every case, the logic and performance is darn near identical). KJArticle: 109759
Hi I am using synplify to synth a design with some xilinx core gen devices. I get warnings on some of the core gen edif files stating that there is an interface mismatch between the verilog and the edif. I can only assume that it is something that core gen is not doing correctly. Has anyone else seen this problem? Here is the warning I get. @W: : | Interface mismatch for Entity/Module dplbuf_16x512 From removethisthenleavejea@replacewithcompanyname.co.uk Thu Oct 05 04:15:48 2006 Path: newssvr21.news.prodigy.com!newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newsfeed.telusplanet.net!newsfeed.telus.net!hwmnpeer01.phx!news.highwinds-media.com!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!newspeer1.nwr.nac.net!solnet.ch!solnet.ch!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!demeter.uk.clara.net From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> Newsgroups: comp.arch.fpga References: <ahn4i25ir1pnpqbol22na85ggkrjeoam3m@4ax.com> <1159882885.7617.0@proxy01.news.clara.net> <J8uUg.18192$Oh3.12154@trnddc04> <1159907018.668373.267310@i3g2000cwc.googlegroups.com> <eg24sg$h8c$02$1@news.t-online.com> Subject: Re: JTAG cable @ 2.5 V - where? Date: Thu, 5 Oct 2006 12:15:48 +0100 Lines: 124 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-RFC2646: Format=Flowed; Original X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: d258751c3e248630963c302dc23705000131250813041068233e30e44524e960 NNTP-Posting-Date: Thu, 05 Oct 2006 12:15:44 +0100 Message-Id: <1160046944.94302.0@demeter.uk.clara.net> Xref: prodigy.net comp.arch.fpga:120688 Ulrich It isn't one thing but a series of things from PCB layout through to choice of driver and decoupling. Actually as a cable our Prog1 cable does even better but it has the advantage of a Coolrunner-II CPLD and a voltage regulator built in. It is some way between what Xilinx do as Cable III and their Cable IV. At some stage we may effective take the best bits of Prog1 and Prog2 and a couple of other things we know will think will make life better and make Prog3 but that isn't until we exhaust our current Prog2 cable stock. We have a few new ideas we are trying out on our new development board Tarfessock1 which can double as a programming cable and depending if those work they may get fed back into the more general cable solutions. Some of the problems people see in programming are actually the target board in the main and not necessarily the cable or a combination of them. John Adair Enterpoint Ltd. - Home of Tarfessock1. The Cardbus Spartan-3E FPGA Development Board. http://www.enterpoint.co.uk "Ulrich Bangert" <df6jb@ulrich-bangert.de> wrote in message news:eg24sg$h8c$02$1@news.t-online.com... > John, > >>Prog2 actually performs very well against the competition and works in > circumstances where many others fail. > > is this a business secret or can you elaborate a bit on that? Using the > right buffers the high level to low level translation should not be a > problem anymore. Is it a question of TDO conditioning? > > Best regards > Ulrich Bangert > > "John Adair" <g1@enterpoint.co.uk> schrieb im Newsbeitrag > news:1159907018.668373.267310@i3g2000cwc.googlegroups.com... > Well I did say look-alike I didn't say the same. It looks the same to > the Xilinx software so it can use it without issue. Prog2 actually > performs very well against the competition and works in circumstances > where many others fail. We have tried several of these in compatibility > testing with our own boards. Our Prog2 isn't as good as Cable IV but > then it is about 1/5 th of the price when buying and we do give them > away with our own development boards. > > John Adair > Enterpoint Ltd. > > John_H wrote: >> I don't see where the "Parallel Cable III look-alike" PROG2 is 2.5V >> compliant since the Parallel Cable III doesn't work so well from 2.5V. >> >> I think I've gotten the III to work with a 3.3V supply for 2.5V JTAG but >> the IV or USB versions of the cable are certainly more robust. >> >> Perhaps the Xilinx online store could ship to Switzerland with a simple >> credit card purchase. >> >> The Parallel Cable IV doesn't include schematics but it does show what >> the input and output stages look like, easily replacing the simple >> buffers in the Parallel Cable III which does have full schematics. >> >> - John Handwork >> >> >> John Adair wrote: >> > Markus >> > >> > Our Prog2 cable(ask for narrow head version) is available in the > standard 14 >> > way 2mm connector. Cost GBP£10. It is a Cable III look-alike as most > third >> > party cables are. Schematics for Cable IV are generally not in public > domain >> > and generally not replicated by anyone as far as I know. >> > >> > The only advantage of the Cable IV is the download speed. >> > >> > Our shop website has those listed under programming solutions for an > easy >> > order solution. >> > >> > John Adair >> > Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development >> > Board. >> > http://www.enterpoint.co.uk >> > >> > "Markus Zingg" <m.zingg@nct.ch> wrote in message >> > news:ahn4i25ir1pnpqbol22na85ggkrjeoam3m@4ax.com... >> >> Hi group >> >> >> >> I'm a newbee, so please bear with me if this does not make sense. >> >> >> >> I got a AVNet (MEMEC) Virtex 4 based developper kit based on the >> >> Virtex-4 FX12 Mini Module whoes baseboard JTAG port is documented as >> >> "a 2.5V compatible JTAG chain header". The pinout is identical to what >> >> Xilinx seems to use (14 pins etc.). The docs seem to asume that one >> >> must use the Xilinx parallel cable IV which from what I understand >> >> seems to automatically sense the voltage needs of the target and is >> >> having other nice to have features. However, due to several reasons >> >> which are beond the scope of this post, I can't simply pick up the >> >> phone and order one from a supplier last not least also because I >> >> don't know any that would carry this item here in Switzerland. >> >> >> >> The net seems to be full of homebrew JTAG cable websites giving >> >> instructions to build you own. The question is can I use one of those? >> >> I'm a bit afraid that this will not work cause from what I understand >> >> they seem to be designed for 5V or 5V tolerant devices. What other >> >> options do I have? Any links to a schema of the Xilinx paralell cable >> >> IV or such to build my own JTAG cable running at 2.5V? >> >> >> >> I would also not mind to shell out the needed $$$ to get that original >> >> cable if I could easily purchase it somewhere online using paypal or a >> >> credit card and get it deliverd quickly. Any ideas? >> >> >> >> TIA >> >> >> >> Markus > >Article: 109760
yes urban, i've read that document and I think my board will adopt the solution propsed in the application note. In this moment I don't have such kind of PROM so I can't try it. If you have some good results with it, please contact me and let me know your solution! Thanks for the hint, Andrea.Article: 109761
Hi, I am using Xilinx ISE software for an FPGA project. Every time I do a small change in the HDL code I have to regenerate the bitstream file and the ISE software takes a long time to do the job. Is there a way to accelerate it? Is there a way to avoid synthesizing parts of the design that are untouched since the last synthesis? What about the rest of tue processes? Is it faster to use a batch file instead of using the software GUI? Thanks, RobertArticle: 109762
Thanks but does not work.... Also, using the MUXCY_L primitive does not work. I Also did not succeed with RLOCs - MAP exits the slice via local routing and reenters after quite a long path. But i CAN create a net using the Y/DY path with the FPGA-Editor without DRC warnings, so in principle there is no technical problem. still trying ... "Brannon" <brannonking@yahoo.com> schrieb im Newsbeitrag news:1159540838.116591.300510@m7g2000cwm.googlegroups.com... > Try using the LO output of the MUXCY_D primitive instead of the O > output. >Article: 109763
Eli, I use the technique you describe for system reset, i have a "reset_controller" block I paste into all my designs... One case where I have clear results showing that this implementation is more efficient than a complete synchronous reset is in some older CPLDs (XC9500). I assume that in these devices the implementation of an asynch reset (albeit one that has been synchronised) comes almost for free, whereas a synchronous one always appears to take more to be fitted. > Or they will claim some logic resource advantage that when you test the > claim is found to be baseless (in almost every case, the logic and > performance is darn near identical). I am one of "them"... Haha --fully asynchronous reset 16-bit down-counter mapped in an xc9536 Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used 16/36 (45%) 15/180 (9%) 16/36 (45%) 18/34 (53%) 23/72 (32%) --synchronous reset same circuit as before Macrocells Used Pterms Used Registers Used Pins Used Function Block Inputs Used 16/36 (45%) 31/180 (18%) 16/36 (45%) 18/34 (53%) 26/72 (37%) I agree macrocells & registers is the same, but obviously the routing and functions required to implement the synchronous reset is not easily achieved in xc9500s. BenArticle: 109764
dhruvakshad@gmail.com wrote: > Hello KJ, > I have added exactly one flip flop in between the asycnhronous inputs > and the state machines since the asynchronous input is coming at a much > lower rate. is it ok? > > Thanks, > D I said two flip flops. "What you need to do there is first synchronize the signal with two flip flops and feed the output of the second flip flop to the rest of your design. The output of the first flip flop goes nowhere except for the input of the second flip flop" The 'lower rate' is irrelevant, if it's asynchronous you have no idea when it will come in relative to the clock that is sampling it. KJArticle: 109765
dhruvakshad@gmail.com wrote: > how could I find the maximum frequency of the adder generated using > core generator? > thanks, > D > When you run through the place and route, ISE will produce a timing report telling you all of the numbers (Tsu, Tco, Tpd and T) that I mentioned in my first post. KJArticle: 109766
moogyd@yahoo.co.uk wrote: > Hi, > > We have an eval board with a spartan FPGA and a 75MHz XTAL > Within ourt design, we require an accurate 16MHz clock. > It is not possible to generate this frequency using a single DCM, is it > possible to chain 2 DCM's together to generate the 16MHz clock ? > > (the obvious solution is to change the XTAL, but I'd like to know > whether it is possible without changing the XTAL :-) ) Howdy Steven, Unfortunately you didn't provide enough information to really help you here. Which generation Spartan are you using? How accurate does the clock need to be? 16.00000MHz? Any duty cycle requirements? Jitter requirements? There are five different generations of the Spartan. As you probably know, DLL's likely wouldn't help you much. S3 and newer with DCM's have CLKFX which might get you close, depending on your exact frequency and jitter requirements. Going the non-DCM route, I think a combinational output of multiple flip-flop dividers would allow you to generate this clock pretty accurately, but might cause jitter/duty cycle distortions. Good luck, MarcArticle: 109767
Stefan Philipp wrote: > Thanks but does not work.... > Also, using the MUXCY_L primitive does not work. > I Also did not succeed with RLOCs - MAP exits the slice via local routing > and reenters after quite a long path. > But i CAN create a net using the Y/DY path with the FPGA-Editor without DRC > warnings, so in principle there is no technical problem. > > still trying ... > "Brannon" <brannonking@yahoo.com> schrieb im Newsbeitrag > news:1159540838.116591.300510@m7g2000cwm.googlegroups.com... >> Try using the LO output of the MUXCY_D primitive instead of the O >> output. I did have an issue the other day where a syn_hier="hard" in SynplifyPro caused some similar problems for a Spartan3E design. If your register is in the module where your MUXCY is used, the nuance may let the register pack. If you do use directives to keep the synthesizer from optimizing across module boundaries, try manipulating those. I think a "firm" was the only difference I needed.Article: 109768
Hi,
I am new to the Nios II core. I have built a simple system with a timer which is
set as periodically timer. I have registered an interrupt service routine:
alt_irq_disable(TIMER_0_IRQ);
res = alt_irq_register(TIMER_0_IRQ, NULL, timer_isr);
With this code I still come in my installed ISR. So registering is also enable
the interrupt. Is that correct, is there a way to register an ISR and leave the
interrupt disabled (until you decide to enable it manually)?
Another question: where can I find a list with available routines for the
peripheral. For instance, I saw in an example the call
IOWR_ALTERA_AVALON_PIO_DATA to write to my io-pins. But where can I find a
complete list. It not in the software developer's handbook.
best regards,
Frank
Article: 109769Benjamin Todd wrote: > Eli, > > > I assume that in these devices the implementation of an asynch reset (albeit > one that has been synchronised) comes almost for free, whereas a synchronous > one always appears to take more to be fitted. Careful when you say 'always', because you'll be wrong. A single test case does not imply 'always'. Even I said "almost every case". > > > Or they will claim some logic resource advantage that when you test the > > claim is found to be baseless (in almost every case, the logic and > > performance is darn near identical). > > I am one of "them"... Haha Only under some conditions, not all. Granted, the condition might be continued use of a particular part, or family of parts or even the software that you use. Try targetting an FPGA or use different front end synthesis software and see what the differences are. > > --fully asynchronous reset 16-bit down-counter mapped in an xc9536 > > Macrocells Used Pterms Used Registers Used Pins Used Function > Block Inputs Used > 16/36 (45%) 15/180 (9%) 16/36 (45%) 18/34 (53%) 23/72 (32%) > > --synchronous reset same circuit as before > > Macrocells Used Pterms Used Registers Used Pins Used Function > Block Inputs Used > 16/36 (45%) 31/180 (18%) 16/36 (45%) 18/34 (53%) 26/72 > (37%) > > I agree macrocells & registers is the same, but obviously the routing and > functions required to implement the synchronous reset is not easily achieved > in xc9500s. You didn't post clock cycle (i.e. performance numbers) which I'm guessing are identical or darn near. The reason for my "almost every case" disclaimer did have to do mainly with CPLDs since the and/or array physical implementation of those devices is completely different than the sea of LUTs inside an FPGA. Since this is the 'fpga' newsgroup I didn't really mention that but I should have. In an FPGA there is typically (but not always) a way for the fitter to use an otherwise unused address input to the LUT in order to implement the reset functionality. It's a bit harder (but not at all impossible) to come across the case where the synchronous reset will require an extra LUT and delay....but it also does not come up very often and I've yet to see it come up in the critical timing path (but it might). The thing is though depending on the device the async reset path might lead to timing issues as well that the sync reset wouldn't, so the 'best' advice is probably that your mileage will vary each has advantages and disadvantages in different scenarios...and that proponents of each method have a point (unlike those "two process state machine" guys ;) KJArticle: 109770
Hi, "but i would suggest to use the ones from the xilinx website for PREAT8 flow. The Early Access Partial Reconfiguration Suite contains basic busmacros, examples, and much more. It may also be possible, if you, for whatever reason, not be able to use ISE8.1, to use the old patch for partial reconfiguration, based on ISE6.3. " Could you tell me where I can find it? I try to search but I did not find the patch for ISE 6.3i. Thank you so much. Thang NguyenArticle: 109771
Steven, if yor Spartan device has the CLKFX option, then you just use one DCM to multiply by 16 and simultaneously divide by 15, which gives you an 80 MHz output. You can then use a simple 3-bit synchronous counter to divide by 5, and that gives you the 16 MHz accurately. Peter Alfke, Xilinx Applications (from home) ================ moogyd@yahoo.co.uk wrote: > Hi, > > We have an eval board with a spartan FPGA and a 75MHz XTAL > Within ourt design, we require an accurate 16MHz clock. > It is not possible to generate this frequency using a single DCM, is it > possible to chain 2 DCM's together to generate the 16MHz clock ? > > (the obvious solution is to change the XTAL, but I'd like to know > whether it is possible without changing the XTAL :-) ) > > Thanks for any feedback, > > StevenArticle: 109772
On the Xilinx Home Page XILINX OPENS DEVELOPMENT CENTRE IN INDIA TO STRENGTHEN GLOBAL R&D ECOSYSTEMArticle: 109773
> I am using Xilinx ISE software for an FPGA project. > Every time I do a small change in the HDL code I have to regenerate the > bitstream file and the ISE software takes a long time to do the job. > Is there a way to accelerate it? Yeah. It's called L1/2/3 cache. It costs several hundred dollars for a fair amount of it. If you can cut your compile times from 20min to 15min by purchasing a $1000 CPU, how long would it take the company to pay for that with the made-up time? > Is there a way to avoid synthesizing parts of the design that are > untouched since the last synthesis? What about the rest of tue > processes? You can resynth only part of the design currently. Using the GUI just select the subcomponent and compile that portion. The Map/Par tools support a similar functionality using what's called guide files. Last I heard Xilinx was working on a major upgrade of this feature. Search the news group for more info on it. > Is it faster to use a batch file instead of using the software GUI? There is no difference (assuming parameters are the same). I think I'll post a letter on this forum begging for more work on this...Article: 109774
> I am using synplify to synth a design with some xilinx core gen devices. I > get warnings on some of the core gen edif files stating that there is an > interface mismatch between the verilog and the edif. I can only assume > that it is something that core gen is not doing correctly. Has anyone else > seen this problem? Here is the warning I get. > > @W: : | Interface mismatch for Entity/Module dplbuf_16x512 Give us the Coregen version, OS, object and parameters so we can reproduce the problem.
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