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 Glen, I still don't understand what the problem is though. So when I changed RESET, shouldn't the register be changing as well???? Right now it's not doing that, I kept getting 21 out for some reason. If I change always @(posedge CLK_IN) to always @(CLK_IN), then it works, do you know why???? Thanks, AnnArticle: 79651
> be perfectly covered by the TI TPS75003RHLR chip with adequate > > Has anyone heard about the current development and sampling status of > that chip? I asked the same question to the email address in the TI page. They answered that samples and Evaluation modules are available now, but production at end of march. I'm now waiting for an answer by EBV.Article: 79652
Dig, glad to hear you like the look of the methodology. Regarding your question, then it rather depends on whether you are talking vs standard-cell ASIC, or Structured ASIC. All Structured ASICs have a larger die size and less ultimate performance than standard-cell ASICs. However, they make up for this (for the majority of applications) by offering much lower NREs, lower minimum order quantities, reduced risk and better time-to-market. For the current version of HardCopy that is shipping today (HardCopy Stratix - based on the same 0.13um process we use for Stratix FPGAs), then the only really meaningful performance figure I can give you is that we tend to find an average of 50% speed up from the Stratix FPGA. We have seen typical system speeds over 150MHz, though with pipelining, you could achieve more. Power is lower than the FPGA, typically 25-40% or so. Last month we announced the next generation, HardCopy II, based on the same 90nm process we are using for the Stratix II and Cyclone II FPGAs. This will increase performance significantly, typically doubling what is possible on the FPGA. We expect "real" system performance figures of 350MHz. Power will also be lower and we expect core figures of 50-70% lower than the FPGA. By yield, I assume you really mean cost. The die-size of any chip is of course what dominates the cost and in the case of Structured ASICs such as HardCopy, the die-size is larger than a fully optimised standard cell ASIC. However, the NRE charge will significantly lower and you therefore need to look at the total cost. For HardCopy Stratix, we tend to find above volumes of 50K-100K, standard cell ASIC tends to work out more cost effective, though we have seen some memorable exceptions where customers have gone well over these volumes, usually because time-to-market matters a lot more. Because HardCopy II is significantly more die-size optimised, (and because ASIC NREs are continuing to increase) we expect that the volumes at which break-even makes sense will increase significantly, to somewhere between 250K-500K units per year. So coming to time-to-market, Structured ASICs in general are typically far faster to market than standard cell ASICs, because so much of the back-end work is already done. HardCopy is a lot faster than any other structured ASIC because we guarantee the migration from a working FPGA to the HardCopy device. The typical turnaround time to protos is 10 weeks, including the migration in our design center and the fab and assembly time. If you're interested in learning more and can spare 40 mins to an hour, (and can forgive a blatant plug), we did a Net Seminar on this last week which includes information on the latest version - HardCopy II. You can look at it here. (Registration required) http://cmpnetseminars.com/TSG/default.asp?q=157&K=CALTERA1 I hope this helps answer your question. Regards, Paul Hollingworth Altera Marketing digari@dacafe.com wrote: > I was going through the hard copy product from altera. Methodology > seems really promising. I just wonder where hard copy products stands > as compare to ASIC wrt performance, power, yield & Time to marketArticle: 79653
"KCL" <kclo4_NO_SPAM_@free.fr> schrieb im Newsbeitrag news:421b902b$0$3103$8fcfb975@news.wanadoo.fr... > 1) how could I have the worst delay path in xilinx ise in a design? > Because if i put a timing constraint it give me the worst paths if the > constraints is not reach but if the constraint have been met we haven't the > worth path. Timing Analyzer is your friend. Tell him to check against tighter constraints, and it will show you the failing paths. > 2) When can we say that we have reached the max frequency possible for the > design? In my mind it 's for when we made an IP with no timing constraint > when can we say that we are fast enought?? Relative to time due to logic and > route , when we have more time due to route than logic or something else?? Again, timing analyzer is your friend. It will tell you exactly how much time is spent in logic and routing. > 3) Is it possible to put a part of the a design out of timing analyze? > because a part of my design is only here for simulation (it generates > stimuli when onboard) and the worst delay path is due to this part. Or > should I analyze each part of my design separately without the test part?? Yes, you can exclude paths/parts from timing analyze. But why? Tell the analyzer the real clock frequency of each part an everything is fine. Even just for testing/simulation/emulation, you test logic must be fast enough. Regards FalkArticle: 79654
Hi all, I'm asking if there is any difference between the Xilinx JTAG III and IV??? I saw that the speed of the second is 8 time quicker than the first, but i need a JTAG cable and all the schematics are for the old one. Is it matter if i use the JTAG III instead of the PC4??? thanksArticle: 79655
Dig, You really must listen to their presentation (completely). For example, they do not recommend using S2 to prototype today for H2. Prototyping with their FPGA means that there will be conversion issues that may affect the outcome. They admit this, and wish you to succeed, so they want to train you how to avoid problems. That is just good business. By their own figures, somewhere between 16% and 70% of conversions will 'suceed". (Or somewhere from 30 to 84% will FAIL). (With EasyPath (XIlinx tm), they all succeed, and the cost is less, and the availability is immediate...but you are not interested in FPGAs, so I apologize for this digression). With H or H2, it is just another ASIC, slightly larger, less optimal, but an ASIC none the less. 'Faster' is not usable, as there is no way to verify that 'faster' will actually work. (In fact one high profile customer failed miserably because it was 'faster'!) Count on designing it for the speed you need, and making sure that if some delays are shorter than those in the FPGA, it will still work. That said, for 2005, there are an estimated 1000 ASICs out there that need to be designed by the 11 vendors who do this (IBM, NEC, etc.). Most in 130 nm or larger (as perhaps only 3 to 5 of these will be rich enough to afford 90nm). Structured ASICs are expected to capture a significant (you figure out what that means - 10% or 90%? Who knows?) share of this market this year primarily because they allow advanced technologies (like 90nm) to be used. 'A' claims that are getting a design a week. 52/1000 =~ 5% of the designs. That might be a lot of the $20 billion market for those 1000 designs... For example, LSI is advertising that their structured ASIC solution is more cost effective, and has a faster delivery that the A company's offering. That is a real tribute to the 'A' company: LSI considers them serious competition! And, they are, as they are atempting to take LSI's bread, and butter from them. That makes the 'A' company an ASIC company (as they move forward and start to derive revenue from this market). Sad to see the only viable competitor leaving the field....for "greener grass" on the other side of the fence. Austin Paul Hollingworth wrote: > Dig, > > glad to hear you like the look of the methodology. Regarding your > question, then it rather depends on whether you are talking vs > standard-cell ASIC, or Structured ASIC. All Structured ASICs have a > larger die size and less ultimate performance than standard-cell ASICs. > However, they make up for this (for the majority of applications) by > offering much lower NREs, lower minimum order quantities, reduced risk > and better time-to-market. For the current version of HardCopy that is > shipping today (HardCopy Stratix - based on the same 0.13um process we > use for Stratix FPGAs), then the only really meaningful performance > figure I can give you is that we tend to find an average of 50% speed > up from the Stratix FPGA. We have seen typical system speeds over > 150MHz, though with pipelining, you could achieve more. Power is lower > than the FPGA, typically 25-40% or so. Last month we announced the next > generation, HardCopy II, based on the same 90nm process we are using > for the Stratix II and Cyclone II FPGAs. This will increase performance > significantly, typically doubling what is possible on the FPGA. We > expect "real" system performance figures of 350MHz. Power will also be > lower and we expect core figures of 50-70% lower than the FPGA. > > By yield, I assume you really mean cost. The die-size of any chip is of > course what dominates the cost and in the case of Structured ASICs such > as HardCopy, the die-size is larger than a fully optimised standard > cell ASIC. However, the NRE charge will significantly lower and you > therefore need to look at the total cost. For HardCopy Stratix, we tend > to find above volumes of 50K-100K, standard cell ASIC tends to work out > more cost effective, though we have seen some memorable exceptions > where customers have gone well over these volumes, usually because > time-to-market matters a lot more. Because HardCopy II is significantly > more die-size optimised, (and because ASIC NREs are continuing to > increase) we expect that the volumes at which break-even makes sense > will increase significantly, to somewhere between 250K-500K units per > year. > > So coming to time-to-market, Structured ASICs in general are typically > far faster to market than standard cell ASICs, because so much of the > back-end work is already done. HardCopy is a lot faster than any other > structured ASIC because we guarantee the migration from a working FPGA > to the HardCopy device. The typical turnaround time to protos is 10 > weeks, including the migration in our design center and the fab and > assembly time. > > If you're interested in learning more and can spare 40 mins to an hour, > (and can forgive a blatant plug), we did a Net Seminar on this last > week which includes information on the latest version - HardCopy II. > You can look at it here. (Registration required) > http://cmpnetseminars.com/TSG/default.asp?q=157&K=CALTERA1 > > I hope this helps answer your question. > > Regards, > Paul Hollingworth > Altera Marketing > > digari@dacafe.com wrote: > >>I was going through the hard copy product from altera. Methodology >>seems really promising. I just wonder where hard copy products stands >>as compare to ASIC wrt performance, power, yield & Time to market > >Article: 79656
AL wrote:
> Hi Glen, I still don't understand what the problem is though.
> So when I changed RESET, shouldn't the register be changing
> as well???? Right now it's not doing that, I kept getting 21
> out for some reason. If I change always @(posedge CLK_IN) to
> always @(CLK_IN), then it works, do you know why???? Thanks,
always @(CLK_IN) begin
means to do those operations on either edge of the clock.
As far as I know, real flip-flops don't do that, and the
synthesis programs won't compile it, but it will simulate.
No, it does not sense change in RESET. An asynchronous
reset should be
always @(posedge CLK_IN or posedge RESET) begin
if(RESET) cnt <= 0;
else cnt <= cnt+1;
end
Well, that is a counter with asynchronous reset, but you can
figure out the rest from there. In this case, if RESET goes
high, or if RESET is high while CLK_IN goes high it sets cnt
to zero, which is the normal property of asynchronous reset.
(Except that it doesn't model metastability, but then simulation
normally doesn't.)
(It should work with either blocking or non-blocking assignment,
but it is a little nicer with non-blocking.)
This is similar to what a 74LS74 flip-flop does, and what most
FPGA's do.
-- glen
Article: 79657For a university project we are looking for FPGA boards which offer the best possible cost/CLB ratio. We are interested in realizing a system with a large number (possibly hundreds) FPGAs running in parallel. Both single FPGA or multiple FPGA boards are an option as long as the price per logic function is "optimum". Thanks a lot, ChristofArticle: 79658
Paulo,
Unless your log is incomplete, there is no real error.
Your LibGen flow is being interrupted, because the make command is
invoked by a TCL interpreter in this case, and it is treating the make
command's return code as error.
Try adding a declaration,
int xilkernel_main ();
in your C source file, before main().
- Vasanth
paulojfonseca wrote:
>Hello everybody, i'm building up a system where i need to use a
>Microblaze uP with a RTOS, and my option was the XilKernel that comes
>with Xilinx EDK.
>I'm using a Spartan3 starter board to test my system.
>
>After reading the Xilinx documentation on XilKernel, and also after
>looking to some implementation examples i started to come my embbed
>program.
>
>I'm building a simple test program with an Uart ISR to recieve some
>messages, validate them in one task and send them back in another
>task.
>
>I've made all the Xilkernel configurations (just like in the working
>examples i've been looking to), OS defenition, OS configuration,
>Complier configuration (-lxilkernel), and i also included the xmk.h
>header file.
>
>But i allways get the same compile error:
>
>TELEC/Master.C: In function `int
>main()':
>TELEC/Master.C:72: implicit declaration of function `int
>xilkernel_main(...)'
>make: *** [telec/executable.elf] Error
>1
>
>
>this is when in the main routine i call the xilkernel_main() function,
>and my main task is just like it follows:
>[code:1:9b095c3f06]
>int main(){
> xilkernel_main();
> return 0;
>}[/code:1:9b095c3f06]
>
>Hope someone can give me some hints.
>Thanks in advance
>
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
>----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
>----------------------------------------------------------
> http://www.usenet.com
>
>
Article: 79659digari@dacafe.com wrote: > I was going through the hard copy product from altera. Methodology > seems really promising. I just wonder where hard copy products stands > as compare to ASIC wrt performance, power, yield & Time to market Here is my, admittedly simplistic, look at the difference between X and A. Xilinx (EasyPath) wants to provide you with a significant cost reduction, while eliminating any conversion issues and risks, for a seamless transition from FPGA to EasyPath. Altera (Hardcopy) wants to provide an ASIC that is somehow based on your FPGA design, but does not guarantee painless (or even successful) conversion. (If successful, the power might be lower.) As Austin wrote, this moves Altera into the ASIC business, something Xilinx does not want to touch with a ten-foot pole. Been there, done that, didn't like it at all. Just look at all the casualties... Peter AlfkeArticle: 79660
But the FPGA communicates with JTAG somehow, and JTAG is connected to the parallel port of the PC, so can't we use that connection to write code to get the PC to display something after some kind of event? Thanks, ALArticle: 79661
Hi Zerang Shah, But the FPGA communicates with JTAG somehow, and JTAG is connected to the parallel port of the PC, so can't we use that connection to write code to get the PC to display something after some kind of event? Thanks, ALArticle: 79662
Hi, I take that back, it works for always @(posedge CLK_IN) as well as always @(CLK_IN), but only for very simple logic, if else and case statement, etc. For harder logic such as a counter, it read back 00000000. Does anyone know why?Article: 79663
Hi, I take that back, it works for always @(posedge CLK_IN) as well as always @(CLK_IN), but only for very simple logic, if else and case statement, etc. For harder logic, it doesn't work, only read back 00000000 . Does anyone know why?Article: 79664
The PLL in the Cyclone device works down to -40 C. However the lock pin will not correctly show the PLL-locked status if junction temp is below -20 C AND fIN/N is 200 MHz or less. This detail is shown in the Cyclone datasheet and is what Alex Freed is referring to. N is the divider between the PLL input and the phase frequency detector. You can get a lock signal one of two ways: 1. Depending on your fIN/fOUT multiplier, set up the PLL so that fIN/N is more than 200 MHz. 2. Construct a circuit from LEs that generates a lock signal. One way of doing this is to have a counter driven by the non-PLL clock, and another one driven by the PLL output. (Assuming frequency is the same.) As long as the offset between the two is not changing then the PLL is locked. There's many possible variations of course. Greg Steinke Altera CorporationArticle: 79665
>> >> I think SD Cards are a very fine addition for an FPGA with a soft-core >> processor to be used as file system. Than it's better to connect the >> card direct with the 4-bit interface to the FPAG. >> If you use it also for configuration all above approaches use the >> SD Card in SPI mode. That maens 1/4 of the available bandwith. >> And AFAIK you cannot swith to the SD bus mode without powering >> off the card. And for a file system it can make a difference if your >> transfer rate is 12MB/s or only 3MB/s [6]. > > So perhaps the PLD, or 8-14 pin uC, could perform this power removal ? The power removal is only an additional hardware cost (i.e. a transistor and pcb place). It can be done by the FPGA after configuration/boot. > Next generation FPGAs could include native boot in 4 bit mode option ? I don't think so. The trend is more towards serial download. Parallel configuration was availbale in the ACEX family, but is not availabel in the Cyclone. It makes sense: Configuration time is not the issue, but pin count. > Is there a random access cost-hit in the 4 bit mode ? I don't understand this question. The 4-bit mode simply results in a four fold transfer bandwith compared to SPI. MartinArticle: 79666
Austin Lesea wrote: (snip) > Prototyping with their FPGA means that there will be conversion issues > that may affect the outcome. They admit this, and wish you to succeed, > so they want to train you how to avoid problems. That is just good > business. (snip) > 'Faster' is not usable, as there is no way to verify that 'faster' will > actually work. (In fact one high profile customer failed miserably > because it was 'faster'!) Count on designing it for the speed you need, > and making sure that if some delays are shorter than those in the FPGA, > it will still work. As far as I know, for synchronous design and zero hold time FFs, designs should still work with faster logic. (Not counting interaction with external logic that may not be synchronous.) There is still the case of different speed grades within an FPGA family, and tolerance within the speed grade. I always check for zero hold time FF's in any new logic family that I use. (snip) > For example, LSI is advertising that their structured ASIC solution is > more cost effective, and has a faster delivery that the A company's > offering. In days not so long ago there was "sea of gates", also known as gate array, then standard cell, and then full custom. For sea of gates, more accurately as I understood it sea of transistors, only the metal layers were custom for the design, reducing mask costs. I don't know if that still exists or not. -- glenArticle: 79667
> For a university project we are looking for FPGA boards which offer > the best possible cost/CLB ratio. We are interested in realizing a > system with a large number (possibly hundreds) FPGAs running in > parallel. Both single FPGA or multiple FPGA boards are an option as > long as the price per logic function is "optimum". > Hundreds of FPGAs in parallel is cool. You should consider to design your own boards ;-) Martin PS.: That's is not a joke. In that range it makes sense to build your own solution (or let it build).Article: 79668
Alessandro, there is nothing exotic about your requirements, and any FPGA from a reputable manufacturer should meet it. Plastic packages are very good in high-vibration environments, 25 years is a long time, but most people design for >10 years at elevated temperature ( a description of how many years at what temperature might help. Parts age at high temperature faster than at cold. High reliability is assumed today for all parts, but you might have to pay extra for any assurance. Low maintenance is the same as high reliability, i.e. long mean-time-between-failure. I do not know why you assume that Altera Cyclone fits this better than Altera Stratix or Xilinx Spartan or Xilinx Virtex. They are all candidates... Peter Alfke, Xilinx ApplicationsArticle: 79669
Alessandro Strazzero wrote: > Dear everybody, > > the goal of my post is to collect your opinions about the use of Altera Cyclone > devices in a rugged environment. I have to design a board which should control > a chopper based on GTOs. The environment is a railway vehicle and the following > are the conditions I have to consider: > > - extreme temperature range (-40°C to +85°C) > - strong mechanical vibrations > - long life duration (> 25 years) > - high degree of reliability > - very low frequency of maintenance > > From the point of view of the design I think Altera Cyclone is the best choise > for this kind of project beacuse its high flexibility. But I have some doubts > about its functionality in a rugged environment like above. > > Did you experience the use of Altera Cyclone in a rugged environment ? > What are your opinions about my choise ? You might also want to talk with Actel, as a GTO chopper is not likely to have massive gate counts, but you WILL want fairly quick power up, and high EMC immunity levels. What sort of standards and guarantees do you have to meet ? -jgArticle: 79670
stud_lang_jap@yahoo.com wrote: > Hello Guys, > I am interfacing the synopsys USB 1.1 core with the PHY. But the > problem is the USB core side transreciever signal doesnot match the PHY > signal. As any one interface USB core to PHY?. If so can you please > provide more information about it. > Is USB 1.1 also having UTMI interface to PHY? I searched the internet > but could not get the information. > > Thanks and regards > Williams I have written a free usb 1.1 IP Core that has a UTMI interface to a USB 1.1 PHY (also freely available). Look at www.opencores.org Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 79671
Martin Schoeberl wrote: > > For a university project we are looking for FPGA boards which offer > > the best possible cost/CLB ratio. We are interested in realizing a > > system with a large number (possibly hundreds) FPGAs running in > > parallel. Both single FPGA or multiple FPGA boards are an option as > > long as the price per logic function is "optimum". > > > Hundreds of FPGAs in parallel is cool. > You should consider to design your own boards ;-) > > Martin > > PS.: That's is not a joke. In that range it makes sense to build your > own solution (or let it build). Except for the time it'd take (and for college students, money), I'd agree with you, Martin. When I first read the posting, I assumed they would just build a proof-of-concept. Or maybe that was me just being hopeful that they aren't about to spend the money it would take to buy *that* many demo/eval/prototyping boards. Anyway, they need to find a board that is stuffed with as many Spartan 3 or Cyclone parts as possible. They will cost less if they are in a smallish package, and at least with Xilinx, the top device or two in each family may not be the most cost effective (i.e., for Xilinx, I'll bet either the XC3S2000 in the 676 pkg or XC3S1500 in the 320 or 456 pkg will be the most cost effective). It's mostly dependant on which part is running the highest volume. But as we started out discussing, the per/device cost is going to disappear due to using pre-made boards. In this case, I'm afraid they're just going to have to get quotes from each place and figure up the cost/logic. There are just too many variables: profit margins, exchange rates, number of FPGA's per board, and exactly which FPGA is on that board. Not to mention finding boards that are easy to tie together (using a backplane? cables?). MarcArticle: 79672
Hi Christof, Christof wrote: > For a university project we are looking for FPGA boards which offer > the best possible cost/CLB ratio. We are interested in realizing a > system with a large number (possibly hundreds) FPGAs running in > parallel. Both single FPGA or multiple FPGA boards are an option as > long as the price per logic function is "optimum". In addition to the other advice offered so far, it seems to me that unless your hundreds of FPGAs (or boards) are operating in complete or even relative isolation from each other (which is very unlikely), then suitability for interconnection should be a high-priority criteria in your search. In fact, it should possible be higher even than your stated $/LUT metric. If your architecture is as scaleable as you think it wil be, you can always just buy more boards. What you can't do is redesign the IO on the 100 boards you've already bought... Regards, JohnArticle: 79673
For me it really doesn't matter whether the solution is ASIC (hardcopy) or FPGA (Easypath) because both are not (re)configurable. But i see a performance and power gain in using hardcopy solution, which is welcome in most of the cases. On the other hand immediate availability of easypath solution is a plus because structured ASIC/FPGA user is always TTM hungry. > By their own figures, somewhere between 16% and 70% of conversions will > 'suceed". (Or somewhere from 30 to 84% will FAIL). this is what will increase the cost of hardcopy solution. So a direct question: If the volume is 30K-to -50K, who will be cheaper ?? Hardcopy or easypath ??? An indirect question: What is the volume range where hadrcopy is cheaper and what is the volume range where easypath is cheaper, if I don't consider TTM and power/performance gains. -- DigariArticle: 79674
"Antonio Pasini" <NOSPAM_pasini.a@tin.it> wrote in message news:<lQMSd.578225$b5.26446081@news3.tin.it>... > > be perfectly covered by the TI TPS75003RHLR chip with adequate > > > > Has anyone heard about the current development and sampling status of > > that chip? > > I asked the same question to the email address in the TI page. > They answered that samples and Evaluation modules are available now, but > production at end of march. > > I'm now waiting for an answer by EBV. OK Thank you for the help. I am also waiting for an answer from belgian distributors.
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