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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
PCLK |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |
_______
ALE __/ \______________________________________________________
__________________ ___ ___ ___ __
WRITE# \_______/ \_______/ \_______/ \_______/
_______ __________ __________ __________ __________
DTADD ______/ ADDR \/ DATA0 \/ DATA1 \/ DATA2 \/ DATA3 \__
\_______/\__________/\__________/\__________/\__________/
Mike,
PCLK is 175MHz (DSP internal peripheral clock).
I can generate a 175MHz clock, but it will probably not be in phase
with PCLK.
As you can see, WRITE# signal is low for just one clock. If I have the
bad luck of sampling it at the transition points it is possible that
I'll miss the low part of it.
A 350MHz clock is too high! Maybe something a bit higher than 175.
If the "dangerous" aproach does not work, I'll try this one.
Luiz Carlos
Article: 110151> Also, when the Quartus web edition is "free," my license file is only > good for 6 months and must renew it afterwards. I guess Altera can > pull the plug any time if they decide to do so. > While this is true, I do not think that this is some we have to be afraid of, because the users have the option to "pull the plug", too. ThomasArticle: 110152
thanks Antti LEON looks pretty interesting but it is too large to fit into xc3s500e (starter kit)... as soon as the 1600 starter kit is available... altium ? why not... an other tool I will ask xilinx for an evaluation license... (all that is for edu. and if we pay for software, we could no more pay for hardware...) I am new to SoC, coming from software world... It seems to me that these numerous buses (whisbone AHB simpcon EDK...) look like the .DLL hell Antti wrote: > rponsard@gmail.com schrieb: > > > for those who have done it : > > no one around! > > > how much work is it to integrate a CAN controler as the one in opencore > > into an =B5blaze-EDK design (day, week, month ???) > > choice 1: > > NO WORK, just take Altium Designer and use MicroBlaze or PPC with CAN, > well it will be on wishbone as Altium designer uses MicroBlaze with wb > wrapper > its a bit cheating, AD uses MB from EDK, but it really isnt true EDK > solution? > > choice 2: > 1 day - integration > 1+ month - testing and verification > > dumb estimates (your mileage may vary) > > choice 3: > use GRLIB/LEON3 it already has OC CAN to AHB(APB?) wrapper >=20 > AnttiArticle: 110153
John Adair schrieb: > One of the problems with OPB is that the more peripherals you add the > slower it goes. All of the control signals data returns from modules > etc are ORed together. There are ways to improve module response to > clock e.g. pipelining the return of data. It is worth looked at the > results in timing analyser to identify problem modules and see if you > can do anything to improve the speed of them. > > On the brute force approach try using multiple place and route. Option > can be set in the Placement options in ISE. Also playing with > synthesiser switches - especially hierarchy settings may also help. > > John Adair > Enterpoint Ltd. > John, the OP was already doing multi-pass optimization with the xplorer script and he has pretty much minimal bare bones system so he should be able to meet 65MHz+ timing well there is almost another option ethernet lite requires only 50mhz clock frequency - unfortunatly Petalogix has only released the binary demo with the ethernet lite uclinux drivers (GPL licensed ASFAIK) so the only option currently is really getting the system clock freq above 65 and use full ethernet core AnttiArticle: 110154
hi i got a couple 500e pq208 from them. MICRO COMPONENTS GMBH LACKNERGASSE 32 A - 1170 WIEN ING. ERNST RUTH TEL.: +43 1 4789154 41 FAX : +43 1 4789154 43 urbanArticle: 110155
I had the same thing happen to me using ISE to synthesize a arithmatic unit. I can guarantee that no real changes were made, I just merged two modules into one and it was faster (didn't look at the size). ---Matthew Hicks <burn.sir@gmail.com> wrote in message news:1160071377.108163.26640@m73g2000cwd.googlegroups.com... > > I was playing with this old design the other day and decided to > "clean it up" a little bit (it was kinda messy). I moved some > logic to their own modules for better readability. I also grouped > some signals into VHDL records (don't know what its called, but > if you ever browsed the LEON code, you know what i mean). > > > I didn't change the functionality of the design (I did ran a > large number of tests to be sure, of course). Furthermore, the changes > were very isolated (only two files affected in a relatively large > design) > > I was kind of surprised to see that after synthesis and PAR, > I got a design that was: > > 1. 10% slower > 2. marginally larger (few hundred LUTs) > > (yes, with same tool, same speed grade and so on) > > > Has anyone seen this kind of behaviour before? > Would this go away if I somehow "flattened" my design? > > > > > bruns >Article: 110156
Are there any functional languages that can be compiled to hardware at the same or greater level of abstraction than languages like Mitrion-C and Handel-C. Is it all research or is there anything that is practical?Article: 110157
On Oct 11, 8:03 am, "Brandon Jasionowski" <killerhe...@gmail.com> wrote: > Why is ISE ignoring my constraint? Your statement: > The first two nets listed are assigned to a timing name belonging to > paths that are asychronous to another clock. may show a mis-understanding of how the TNM and TNM_NET constraints form timing groups (not "timing names", the name is just a label to refer to the group). Timing groups are composed of instances of FFs, memories, and other synchronous devices, they are _not_ composed of nets. TNM_NET fans _forward_ from the named net and collects any devices whose inputs are reached either directly or combinatorically from that net. To get a clue what's happening, use Timing Analyzer to take a look at the timing groups that are formed by your grouping constraints: > NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr"; > NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr"; > NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr"; > NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr"; Look at the group "TN_ctrl_clr". Does it contain "Source: ctrl2_ins/curr_st_FFd1 (FF)"? Look at the group "TN_sync_drpp_clr". Does it contain "Destination: sync_drpp_clr_inst/sync_r1_1 (FF)"? (I'm guessing no on both...) If the groups don't contain the source and destination devices for the timing path you want to ignore, the TIG constraint is not applied (or worse, applied to a different set of sources/destinations that you did not intend). Three possible suggestions are: 1) If you want to ignore _all_ cross clock domain timing, you easily do that with a TIG applied from your CLK1 group to your CLK2 group: NET "adc_clk_dcm_clk0" TNM_NET "TG_Clk1"; NET "adc_clk_dcm_clkfx" TNM_NET "TG_Clk2"; TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" TIG; (or whatever names you want to use for your TIMEGROUPsand TIMESPEC.) I don't particularly like this though, it may hinder Place/Route by allowing domain crossing nets to be excessively long, thus getting in the way of more critical nets. It may be nicer to simply use a small but achievable value: TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" 2 ns; (or whatever value works for you). 2) Closer to what you seem to want to do, use TPTHRU: NET "ctrl1_clr" TPTHRU=3D TH_clr; NET "ctrl2_clr" TPTHRU=3D TH_clr; and either: TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" TIG; or possibly better for P/R: TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" 2 ns; 3) To pick out only the particular paths that you show failing, use the instance grouping constraint: INST "ctrl2_ins/curr_st_FFd1" TNM "TG_Src1"; INST "sync_drpp_clr_inst/sync_r1_1" TNM "TG_Dst1"; TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" TIG; or TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" 2 ns; Hope one of these is of some help. Regards, John > I've been performing post-map static timing analysis and have noticed > that my TIG UCF constraint is being ignored for some reason. Here is > what I have: > > <SNIP> > ## TIG > NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr"; > NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr"; > NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr"; > NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr"; > TIMESPEC "TS_TIG_clr2synch" =3D FROM "TN_ctrl_clr" TO "TN_sync_drpp_clr" > TIG; > </SNIP> > > The first two nets listed are assigned to a timing name belonging to > paths that are asychronous to another clock. This clock drives > registered ports of an instance (synchronization circuit) with port > name sync_r2(1:0). Normally I would edit the UCF manually, but it > absorbed some of the signal names, so instead I used the constraint > tool to generate the above. > > When I run timing I get the following: > <SNIP> > WARNING:Timing:3223 - Timing constraint PATH "TS_TIG_clr2synch_path" > TIG; > ignored during timing analysis. > </SNIP> > > Here is one of the timing errors from the post-map static timing > analyzer: > <SNIP> > Timing constraint: TS_adc_clk_dcm_clkfx =3D PERIOD TIMEGRP > "adc_clk_dcm_clkfx" TS_adc_clk / 0.7 > HIGH 50%; > > 278920 items analyzed, 4 timing errors detected. (4 setup errors, 0 > hold errors) > Minimum period is 8.415ns. > -------------------------------------------------------------------------= --=AD----- > Slack: -0.270ns (requirement - (data path - clock path > skew + uncertainty)) > Source: ctrl2_ins/curr_st_FFd1 (FF) > Destination: sync_drpp_clr_inst/sync_r1_1 (FF) > Requirement: 0.571ns > Data Path Delay: 0.590ns (Levels of Logic =3D 1) > Clock Path Skew: 0.000ns > Source Clock: adc_clk_dcm_clk0_bufg rising at 28.000ns > Destination Clock: adc_clk_dcm_clkfx_bufg rising at 28.571ns > Clock Uncertainty: 0.251ns > Timing Improvement Wizard > Data Path: ctrl2_ins/curr_st_FFd1 to sync_drpp_clr_inst/sync_r1_1 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tcko 0.291 ctrl2_ins/curr_st_FFd1 > net (fanout=3D22) e 0.100 ctrl2_ins/curr_st_FFd1 > Tfck 0.199 ctrl2_ins/curr_st_Out11 > sync_drpp_clr_inst/sync_r1_1 > ---------------------------- --------------------------- > Total 0.590ns (0.490ns logic, 0.100ns route) > (83.1% logic, 16.9% route) > > </SNIP> > > Why is ISE ignoring my constraint? How am I supposed to know what my > true worst path is if I can't eliminate this timing error? >=20 > Thanks, > -BrandonArticle: 110158
does anyone port JOP (www.jopdesign.com) to the spartan 3E starter kit (xc3s500e) ? there is an implementation for the spartan 3 starter kit (xc3s200), but if the work is already done for the new one, I will apreciate...Article: 110159
I completely agree with John. The groups that you have created might not have a valid connection at all to ignore. The Instance based grouping of the elements(third option) looks like the preferred solution for you to dig out the actual critical paths..Please refer to the constraints guide from the ISE --documents--software manuals(pdf) for the correct syntax and to understand the grouping of elements and create constraints,to inform the tool about such exceptions(path specific).Article: 110160
Most synthesis tools will not share resources across module boundaries, other than really trivial identical registers, etc. Splitting it up into more modules may have defeated some sharing going on. Andy Matthew Hicks wrote: > I had the same thing happen to me using ISE to synthesize a arithmatic unit. > I can guarantee that no real changes were made, I just merged two modules > into one and it was faster (didn't look at the size). > > > ---Matthew Hicks > > > <burn.sir@gmail.com> wrote in message > news:1160071377.108163.26640@m73g2000cwd.googlegroups.com... > > > > I was playing with this old design the other day and decided to > > "clean it up" a little bit (it was kinda messy). I moved some > > logic to their own modules for better readability. I also grouped > > some signals into VHDL records (don't know what its called, but > > if you ever browsed the LEON code, you know what i mean). > > > > > > I didn't change the functionality of the design (I did ran a > > large number of tests to be sure, of course). Furthermore, the changes > > were very isolated (only two files affected in a relatively large > > design) > > > > I was kind of surprised to see that after synthesis and PAR, > > I got a design that was: > > > > 1. 10% slower > > 2. marginally larger (few hundred LUTs) > > > > (yes, with same tool, same speed grade and so on) > > > > > > Has anyone seen this kind of behaviour before? > > Would this go away if I somehow "flattened" my design? > > > > > > > > > > bruns > >Article: 110161
Austin All I need is someone at Xilinx to tell me where the scan cells are in the IOB. I'm fairly certain that they are in a simillar place to where ALTERA clearly document them otherwise it would slow down the pin. I'm almost certain that the pin will be SSTL for JTAG if I make it SSTL functionally. Your asking me to cripple a design functionally for the sake of the right person at XILINX answering the question. If I make the whole design CMOS then I can use a MAX II which I can power from 2.5v without needing a vreg to 1.8. Regards, in total exasperation Colin Austin Lesea wrote: > Colin, > > Do not use any termination. > > If you use any termination at all, it will not work. > > That simple. > > If you don't use any termination, you may get reflections, and that > might be a problem, too. > > Get Hyperlynx, and run the simulations yourself. > > Austin > > colin wrote: > > Austin > > > > I'm fairly sure that you understand most/all of this but you have > > suggested to the world that I don't...... :-) > > > > I am using a third party boundary scan tool from assett intertech which > > uses the JTAG port to twiddle pins on certain devices and read back the > > values on other pins on the same net so yes I'm fairly certain that I'm > > using JTAG. > > > > If the coolrunner II is not programmed then there is no confusion, one > > uses the bsdl file provided by xilinx which defines the jtag behaviour > > of the device and the coolrunner will drive outputs and receive inputs > > as CMOS to the value of whatever I have set VCCIO to for that bank. > > > > If the coolrunner has been programmed then there is a tool from xilins > > called BSDLANNO which looks at the fitter output and the original bsdl > > file and creates a new bsdl because inputs are input only for jtag, but > > outputs can be IO still for JTAG. > > your tech support took a week to tell me that outputs are output only > > for jtag so 13 days ago > > I showed them the bsdlanno documentation and they said they would get > > back to me. > > > > There is no issue with SSTL receiving CMOS because CMOS drives rail to > > rail (2.5v) which is what the SSTL driver does. > > However a CMOS receiver threshold is somewhat different to a SSTL rx > > threshold which means there is not as much (I said it was a marketing > > thing) noise immunity by the time the sstl signal has gone through the > > sstl termination scheme. > > My question is therefore what do I do to ensure that my boundary scan > > gets done using sstl levels. Now waiting 3 weeks for this bit. > > > > Colin > > > > > > > > Austin Lesea wrote: > >> So, you wish to drive a LVCMOS input from a SSTL output? > >> > >> If this is what you are doing, at 2.5 volts, then if the CPLD is > >> programed for SSTL class I, and there are no resistors used (no > >> terminations), then the SSTL output is compatible with the LVCMOS input. > >> > >> This can be simulated with any signal integrity simulation tool (like > >> Mentor's Hyperlynx) in about 60 seconds (which I did). > >> > >> To really know, and to be absolutely sure, I would need the part number > >> and manufacturer of the CPLD, and the IBIS file for the SSTL output (I > >> used the SSTL_I output for a V4 FPGA). > >> > >> I think I understand the hotline's confusion now. Your boundary scan > >> has nothing to do with JTAG. How confusing, as the only context that we > >> have heard of boundary scan in, is JTAG. > >> > >> Austin > >Article: 110162
rickman wrote: > Jim Granville wrote: > >>scott moore wrote: >> >>>I don't see testability as a barrier. Your yield is not dependent on the >>>good or bad design of the customer (as it is in custom ICs), so the >>>design as burned is testable. The design flow becomes more like an ASIC, >>>with the customer providing bits and vectors. All the maker cares about >>>is the go/no go for the device. It certainly argues for the maker >>>getting more involved in the programming process, and judging from >>>typical makers web sites, that is exactly what they do (Actel, etc.). >> >>Where that matters, is in the impacts of < 100% yield. >> You can't really mount the devices before programing, and so >>suffer another handling step. Then you ideally need to >>be able to decide which devices are duds _before_ you mount them >>on your expensive PCB (that means costly vector testing), and >>finally, who pays for the dud's ? >> I think only TI still makes OTP CPLDs (Atmel have a couple of MilSpec >>ones alive )- everyone else has gone to EE, and that's on small/simple >>devices. >> Looking at Actel's latest push, I see their FLASH devices are >>pushed as low power (not their antifuse), and Actel claim the QuickLogic >>PolarPro benchmark as the worst battery life of the low power alternatives. >>http://www.actel.com/products/igloo/ >> >>Pretty much places any OTP device in the NFND bucket ? > > > I think you missed Scott's point. He is saying that for a production > of any volume, you can let the manufacturer program the devices. They > are better equipped and at that point it adds little to the price. > Let's face it, the cost of testing any large FPGA is not trivial and > the cost of factory programming antifuse parts is lost in the noise. > In fact, once you let the factory program the parts, you can likely > save on test costs since you only need to test the logic you are using, > just like EasyPath, if I have the right name. So factory programming > will likely reduce the price of the antifuse parts over buying them > yourself even without considering the cost of programming them in > house. <snip> OK, but I don't see a lot of OTP vendor noise offering this. Plus, a key AntiFuse pitch is security, and that paranoid user base is not likely to ship code out the door... Also, if you shove programming 'out', how exactly do you develop/change the design ? [maybe like another poster, who uses RAM fpgas to develop for OTP ones ? ] -jgArticle: 110163
Colin, Where are the scan cells? What does that have to do with anything whatsoever? The scan cells are where they are convenient. The scan chain is wired to the JTAG controller, and the JTAG controller is wired to the JTAG pins. Since I seem to be completely unable to help you, I apologize, as I think I am answering your questions, only to have you be frustrated, and ask me a seemingly completely unrelated new question. Perhaps I should quit, right now, and trouble you no further, AustinArticle: 110164
>From my (biased?) vantage point, I see antifuse parts being used only in the niche markets where they offer an advantage that overcomes their weakness: Single-chip, instant-on, some level of security, and radiation-hardened logic (flip-flops are a different matter). Antifuse parts do not address the general market, as can be seen from the sales and market-share numbers. Peter Alfke, trying to be fair. ================================= Jim Granville wrote: > > OK, but I don't see a lot of OTP vendor noise offering this. > Plus, a key AntiFuse pitch is security, and that paranoid user base is > not likely to ship code out the door... > > Also, if you shove programming 'out', how exactly do you develop/change > the design ? > [maybe like another poster, who uses RAM fpgas to develop for OTP ones ? ] > > -jgArticle: 110165
Thanks for the insight. I thought that the synthesis engine would make a huge netlist/graph out of all of my modules and optimize from there ... but now that I think about it, ISE does report optimization of only single modules. ---Matthew Hicks "Andy" <jonesandy@comcast.net> wrote in message news:1160599670.498873.57930@m7g2000cwm.googlegroups.com... > Most synthesis tools will not share resources across module boundaries, > other than really trivial identical registers, etc. > > Splitting it up into more modules may have defeated some sharing going > on. > > Andy > > > Matthew Hicks wrote: >> I had the same thing happen to me using ISE to synthesize a arithmatic >> unit. >> I can guarantee that no real changes were made, I just merged two modules >> into one and it was faster (didn't look at the size). >> >> >> ---Matthew Hicks >> >> >> <burn.sir@gmail.com> wrote in message >> news:1160071377.108163.26640@m73g2000cwd.googlegroups.com... >> > >> > I was playing with this old design the other day and decided to >> > "clean it up" a little bit (it was kinda messy). I moved some >> > logic to their own modules for better readability. I also grouped >> > some signals into VHDL records (don't know what its called, but >> > if you ever browsed the LEON code, you know what i mean). >> > >> > >> > I didn't change the functionality of the design (I did ran a >> > large number of tests to be sure, of course). Furthermore, the changes >> > were very isolated (only two files affected in a relatively large >> > design) >> > >> > I was kind of surprised to see that after synthesis and PAR, >> > I got a design that was: >> > >> > 1. 10% slower >> > 2. marginally larger (few hundred LUTs) >> > >> > (yes, with same tool, same speed grade and so on) >> > >> > >> > Has anyone seen this kind of behaviour before? >> > Would this go away if I somehow "flattened" my design? >> > >> > >> > >> > >> > bruns >> > >Article: 110166
KJ wrote: > radarman wrote: > > KJ wrote: > > > > > > Maybe because there are companies like Synplicity and Mentor Graphics that > > > sell tools that are not vendor specific and do not sell parts. When > > > Microsoft bundles things in and 'gives things away' people rant about how > > > they drive the independent software vendors out of business....a similar > > > argument would likely apply here. > > > > > > Altera, Xilinx, Synplicity, Mentor Graphics et al pay out hard cash to > > > provide software tools and all expect some return on that investment in some > > > form (either directly from the tool or indirectly through parts or both). > > > If one (or more) of the parts guys gives the tools away it can probably be > > > construed by the legal eagles in Washington as a tactic to drive a > > > competitor out of business thus deserving of some close and unprofitable > > > scrutiny. Obviously they can get away with giving limited versions of the > > > tool away; I'm sure Synp and Ment would prefer to make money off of those as > > > well but apparently the perceived loss in revenue is not considered to be > > > worth trying to recoup via the legal system, anti-trust laws, that sort of > > > approach. > > > > > > Just my speculation. > > > > > > > No, I think Altera and Xilinx give away the low-end stuff so that > > students and hobbiests will get exposure to their products. After all, > > if the price of entry is > $3k, how many college's, much less students, > > will be able to provide a reasonable number of seats to do FPGA > > designs? Also, the best students are going to want to do some work at > > home, and most are certainly NOT going to be able to afford the full > > Quartus or ISE package. With both Xilinx and Altera giving away low-end > > versions of the software, those students can now choose either, or > > both, to try out at home. The cost of development boards becomes the > > next issue. (Xilinx is still winning this one) > > > > Thus, the free software is almost a promotional expense for the FPGA > > vendors. It gives people a taste of what's available, and (hopefully) > > gives the users a good impression. > > I have no doubt that it's in Altera and Xilinx and all other FPGA/CPLD > vendors to supply free design software as a mechanism to hook potential > and future customers. My point was that if you're Mentor Graphics or > Synplicity your flagship product is now competing against the free > stuff. Giving stuff away for 'free' causes companies to wave the > 'anti-trust' flag when they see their business going down the tubes or > rally the 'anti-dumping' troops when it comes from a foreign owned > company. Their are of course other responses as well but if you're > running the business you might want to limit your exposure to that sort > of thing. > > For yet another reason for a nominal charge..... > > Obviously one business strategy for the Mentors and Synplicitys of the > world to try to compete in that environment is to wangle their way in > and make the FPGA/CPLD vendors pay a license in exchange they will > supply the hobbled version of their software.....which is why > practically every FPGA vendor has some 'free' form of Modelsim for > anyone who wants it basically. > > Now if the license fee that say Altera (or whoever) pays to Mentor > Graphics is based on the number of Modelsim seats that they give away > then Altera has an economic incentive to keep track of just how many of > these 'freebies' they've given away. Charging even a nominal fee to > get that license is generally enough to thwart the spam attacks that > might otherwise cause them to pony up a big chunk of cash to pay for > all those freebies that were simply someone hatching an e-assault on > them. The FPGA vendors that choose to not charge even a nominal fee > are potentially opening themselves up to a big cash payout if the fee > they must pay is tied to how many seats they give away and someone > decides to hit them up with a cyber attack. > > I'm not saying what they're doing is right, wrong or indifferent or > that I even have a clue about how the agreements between the companies > are worded just that I see a very plausible reason for some modest > amount money to change hands, not as a profit making measure (since it > isn't) or for future business (which it might), or for goodwill (which > it is) but simply to limit their exposure to a license fee. > > KJ I don't think a fee would work well, because they are very likely not only treating the eval/hobby licenses as a promotional item, but fighting software piracy as well. Remember, the "free" stuff is very limited - really only good for hobby and student work. These seats would probably have gone to pirated software, were it not for the free licenses. Seriously, how many students or hobbyists are going to be able to cough up $2.5k/year for a Quartus subscription? If they do, would they have any money left over for devices or boards? By giving away the limited licenses, they remove (most of) the desire to pirate the software, while simultaneously getting positive exposure, feedback, and useful marketing information from the users. By requiring talkback for advanced features, they even get a free beta test dept as well. Lastly, as an added bonus, those users who choose to develop with Altera or Xilinx at home will likely suggest using their favorite device at work. So, what would have likely been a loss becomes a potential gain. Believe me, they make a buck off of those free licenses. It's a win for the users as well. Rather than going through the hassle of finding a pirated copy, figuring out how to hack it, and then getting no support on a very complex product, end users get the real (if limited) deal and access to limited technical support. I can definitely say for myself that I appreciate the freebie licenses, as I fall into the category of people who couldn't otherwise afford to do serious FPGA work at home. Now, the Modelsim situation is a bit different. There could potentially be other EDA companies that would look askance at Xilinx and Altera giving away free Modelsim software, instead of their EDA software - especially since Mentor Graphics is the 800 lb gorilla / Microsoft in the EDA market. However, the "free" Modelsim software is virtually useless for much more than homework problems. I'm actually a little surprised at how many features, like code coverage, are excluded given the product is virtually a live demo. I actually wouldn't be surprised if the freebie Modelsim licenses get yanked because of a lawsuit from another EDA tool vendor. This actually does smack of the kind of illegal bundling that Microsoft has been accused of. As for Synplicity, they don't compete with the free versions anyway. At over $20k/seat, only serious users are going to be buying Synplify licenses, and those are the folks who weren't satisfied with the built-in synthesis tools already. It would be like Ferrari getting upset that Ford is giving away Escorts.Article: 110167
rickman wrote: > Jim Granville wrote: > > scott moore wrote: > > > > > > I don't see testability as a barrier. Your yield is not dependent on the > > > good or bad design of the customer (as it is in custom ICs), so the > > > design as burned is testable. The design flow becomes more like an ASIC, > > > with the customer providing bits and vectors. All the maker cares about > > > is the go/no go for the device. It certainly argues for the maker > > > getting more involved in the programming process, and judging from > > > typical makers web sites, that is exactly what they do (Actel, etc.). > > > > Where that matters, is in the impacts of < 100% yield. > > You can't really mount the devices before programing, and so > > suffer another handling step. Then you ideally need to > > be able to decide which devices are duds _before_ you mount them > > on your expensive PCB (that means costly vector testing), and > > finally, who pays for the dud's ? > > I think only TI still makes OTP CPLDs (Atmel have a couple of MilSpec > > ones alive )- everyone else has gone to EE, and that's on small/simple > > devices. > > Looking at Actel's latest push, I see their FLASH devices are > > pushed as low power (not their antifuse), and Actel claim the QuickLogic > > PolarPro benchmark as the worst battery life of the low power alternatives. > > http://www.actel.com/products/igloo/ > > > > Pretty much places any OTP device in the NFND bucket ? > > I think you missed Scott's point. He is saying that for a production > of any volume, you can let the manufacturer program the devices. They > are better equipped and at that point it adds little to the price. > Let's face it, the cost of testing any large FPGA is not trivial and > the cost of factory programming antifuse parts is lost in the noise. > In fact, once you let the factory program the parts, you can likely > save on test costs since you only need to test the logic you are using, > just like EasyPath, if I have the right name. So factory programming > will likely reduce the price of the antifuse parts over buying them > yourself even without considering the cost of programming them in > house. > > If the programming were done with something other than electricity, the > programming circuitry could be eliminated. I seem to recall a company > that used to provide fast ASIC-like prototypes with laser cutting of > traces. I have not heard much about them lately. What was the down > side of this approach? I'm sure there are others, but I think you are referring to Altera's "Hard Copy", which is technically a "structured ASIC". It's essentially an ASIC comprised of a selection of pre-wired IP components from their FPGA lines. (You get the same PLL/DLL's, M4K blocks, etc as a real FPGA, but hard-wired together based on your netlist) The advantage is that you get to develop your design in an FPGA, then port to an ASIC little or no modification to the original design. You get a high level of confidence that if the design worked in the FPGA, it will work in the ASIC, since the ASIC is essentially your FPGA design with "hard" routing. The ASIC will even replace the FPGA on your board without any modifications, since the pinout is identical save the configuration pins. Lastly, you get an automatic speed boost (in some cases, up to 100%). The structured ASIC's do cost more than a true ASIC, so you have higher recurring costs, but the initial investment is lower (by an order of magnitude - $100k vs $1M), and you lose less of your NRE, since you aren't reworking the design to operate in an standard ASIC flow. There is also the lock-in problem as well. If the firm ever quit making the parts, you are SOL, as they own most of the ASIC IP. You have to hope that you pick the right structed ASIC firm, or do a lifetime buy at some point. The only saving grace is that you still have the original design files, and can begin migrating to another process while you sell off your current inventory. I haven't had a chance to use the process myself, since my employer can afford to use FPGA's, or when the time arises, pony up for a true ASIC, but it makes sense for middle tier players. You get most of the advantages of an ASIC without the ridiculously expensive upfront costs.Article: 110168
Hi Urban, u_stadler@yahoo.de wrote: > well that was a bit early. > thanks again for the tip that solved the firs problem. but now i have > another If this is just the auto-generated Makefile created by EDK, then your best bet is just to force EDk to re-write it. From the Cygwin command line, in your project directory do $ xps -nw system.xmp (or whatever you XMP project file is called) % save make % exit Then do $ make -f system.make clean to clean everything up before trying again. If the design was created with an older version of EDK, xps will first run the revup process. Hope this helps, JohnArticle: 110169
Austin Lesea wrote: > Colin, > > Where are the scan cells? What does that have to do with anything > whatsoever? > > The scan cells are where they are convenient. The scan chain is wired > to the JTAG controller, and the JTAG controller is wired to the JTAG pins. > > Since I seem to be completely unable to help you, I apologize, as I > think I am answering your questions, only to have you be frustrated, and > ask me a seemingly completely unrelated new question. > > Perhaps I should quit, right now, and trouble you no further, I think the OP is questioning how the device programming affects JTAG ? He mentions before programming, and after programming. If you are going to JTAG-scan a post-pgmd full system, I'd say it helps to know which are IPs (to prevent accidental drive) - I'm guessing that's what BSDLANNO does ? My understanding of bondary scan is that once you are in that mode, the config fuses actually don't care, and the system does not know if the device is new/blank/pgmd, so scan is the same in all cases. I think Colin is trying to confirm that, but with modern devices with many IO options, it is not a silly question - and one could argue that ideally, post pgm scan _should_ use the Pin-option information. (but I don't think it does, on anyones CPLDs - correct me if I am wrong ? ) -jgArticle: 110170
Hello Frank, Quartus II 6.0 has the new Virtual JTAG megafunction, sld_virtual_jtag, with which you can gain access to the device JTAG interface and develop your own IP to use the JTAG interface as a simple serial communication channel. A set of TCL commands in the jtag package available in the quartus_stp.exe TCL shell provide you a way to communicate with the device using any of the Altera programming hardware, such as USBBlaster, or to figure out the low level JTAG scan sequence if you need to control the JTAG using your own hardware. Please read the user guide at http://www.altera.com/literature/ug/ug_virtualjtag.pdf for more detailed information. Hope this helps, Subroto Datta Altera Corp. On Oct 10, 4:59 am, Frank van Eijkelenburg <some...@work.com.invalid> wrote: > I know about the bscan blocks in the xilinx virtex devices (bscan_virtex4 for > instance). With these blocks you can make your own interface by use of the > boundary scan usercode instruction. > > Does something like this exists for altera devices? > > TIA, > FrankArticle: 110171
Yes. I see now. Thank you. > Yes, but you made it complicated again be delaying > the clock. The ZBT is designed to have a full clock > cycle of setup. If anything you need to have a negative > delay on the clock to avoid hold issues. But in principle > the ZBT interface is design for SRAM an FPGA using the same > undelayed clock. >Article: 110172
fpga_toys@yahoo.com wrote: > That they block both 3rd parties and open source from having access to > the FPGA internals and tools internals means their customers are > limited to what tools their limited resource development teams can > cobble togather. > > With a more open disclosure, it would be interesting to see what both > open source and for-profit 3rd parties could do to make a market out of > providing high performance FPGA tools and integrated development > systems with FPGA assisted routing. To this day, I'm flabbergasted that silicon vendors actually charge money for their tools!?! If you want to push your silicon, then wouldn't giving away tools only serve to sell more devices??? I'm *sure* more than one decision on Altera vs Xilinx has been made purely on the cost and strength (or otherwise) of the tools!?! As for open-source, I'd love to see it myself, but it would be a vendor's nightmare! "My design simulates fine but doesn't work in silicon... I'm using the red-hat disto of Quartus II v7.4.5 patch level 12 with the turbo annealing enhancements v2.1b4. Oh, and I found a bug so I patched the timing analyzer myself too..." Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266 From john_mccluskey@hotmail.com Wed Oct 11 18:36:35 2006 Path: newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!news.linkpendium.com!news.linkpendium.com!news.glorb.com!out02b.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!wesley.videotron.net!weber.videotron.net.POSTED!not-for-mail From: John McCluskey <john_mccluskey@hotmail.com> Subject: Re: ISE/EDK computer selection User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) Message-Id: <pan.2006.10.12.01.36.35.687521@hotmail.com> Newsgroups: comp.arch.fpga References: <1160399541.151483.7330@k70g2000cwa.googlegroups.com> <452d2e85$1@news.fhg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 13 Date: Wed, 11 Oct 2006 21:36:35 -0400 NNTP-Posting-Host: 66.131.182.144 X-Complaints-To: abuse@videotron.ca X-Trace: weber.videotron.net 1160616986 66.131.182.144 (Wed, 11 Oct 2006 21:36:26 EDT) NNTP-Posting-Date: Wed, 11 Oct 2006 21:36:26 EDT Xref: prodigy.net comp.arch.fpga:121112 On Wed, 11 Oct 2006 19:49:35 +0200, Michael Schöberl wrote: >> I am buying a new for my work. I do a lot of synhesis, map and P&R >> using ISE 8.2 (Windows) in Xilinx EDK with quite complex systems. >> Building a HW for such a system can take a very long time, so selection >> of an appropriate computer is a must. get a big whack (4 Gbytes or more) of PC6400 ECC DDR2 memory. ECC is important, because without, you won't be able to detect memory errors, which can cause weird PAR problems. JohnArticle: 110173
Hi there it seems now that there is another download as "xapp730.zip" at the Xilinx website. Has anyone checked this out? (i'm on pstn so will check it tomorrow from office). so it was a leak :(Article: 110174
Hi Radarman, This is probably a bug in Quartus II 5.1 SP1. If you have an support incident opened email me the number so that we can verify it with the design, or zip the project archive and emailit to me separately. We can ley you know if this has been fixed in 6.0 or if it is still a problem fix it for 6.1. Thanks, Subroto Datta Altera Corp. "radarman" <jshamlet@gmail.com> wrote in message news:1160531029.492131.266030@m7g2000cwm.googlegroups.com... >I posted a service request with Altera on this, but I thought I would > see if anyone else has seen this problem. > > I have written a small 8-bit microcomputer system for my Altera DE2 > board. The system has 16kB ROM that I preinitialize with an intel .hex > format file. > > The design takes quite a while to fit because I want to operate it at a > relatively high clock rate (100MHz), so I turned on smart-compile. Now > that the basic hardware is functioning, and I am only changing the ROM > image, I would expect to simply recompile and let Quartus read in the > new .hex file. > > However, when I try to recompile, I get an error: > Internal Error: Sub-system: QATM, File: qatm_mif_update.cpp, Line: 554 > RAM/CAM MIF reconfig failed > Quartus II Version 5.1 Build 216 03/06/2006 SJ Web Edition > Service Pack Installed: 2 > > Note, the fitter doesn't (seem) to have a problem reading the .hex > file. I can manually rerun the fitter, and it appears to work just > fine. I believe the fitter is working properly because the address > patterns seems consistent with a hang - not an uninitialized memory. > > This is on a Windows XP workstation. The project files are mounted from > a file server on drive Y:. > > Thanks! >
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