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'm looking for a functional URL that hosts the Verilog tutorial by John Sanguinetti. Neither of these seem to work: http://turing.une.edu.au/~comp283/cdrom/Content/Tutorials/Verilog/ http://vol.verilog.com/ I have tried contacting what appears to be the primary/official site (vol.verilog.com) and have received no responses. Is anyone aware of other URLs or how to get this tutorial hosted on one's own site? Thanks, EricArticle: 95601
I do not see what's the problem with these sites? Both works here.. Although vol.verilog.com requires registration. Eric Crabill wrote: > Hi, > > I'm looking for a functional URL that hosts the Verilog tutorial by John > Sanguinetti. Neither of these seem to work: > > http://turing.une.edu.au/~comp283/cdrom/Content/Tutorials/Verilog/ > > http://vol.verilog.com/ > > I have tried contacting what appears to be the primary/official site > (vol.verilog.com) and have received no responses. > > Is anyone aware of other URLs or how to get this tutorial hosted on one's > own site? > > Thanks, > EricArticle: 95602
"Eric Crabill" <eric.crabill@xilinx.com> wrote in message news:dr5sd6$ng22@cliff.xsj.xilinx.com... > Hi, > > I'm looking for a functional URL that hosts the Verilog tutorial by John > Sanguinetti. Neither of these seem to work: <snip> It may just be your network that's having troubles. Access to your company's web pages from outside is a bit dodgey right now.Article: 95603
John_H wrote: > For anyone using a PCI add-in FPGA, the FPGA still needs to be configured. > If they're using Xilinx P&R tools, they're responsible for substantial > engineering aspects of the design. Since there is no other P&R for current xilinx parts, this is a given, not a conditional. > The board manufacturer should have > specific published design limits for the board. I'm not aware of, or have used one, that does. The norm is to ship you a board with some vendors FPGA on it, provide some minimal documentation for the board, and a pointer to the fpga's data sheets and that's it ... other than that the sales dept may wish you good luck too. This is true to PCI RC boards, student boards, and proto boards from all sources. > Armed with the > junction-to-ambiant thermal resistance of the realized design and the > engineering tools provided with the Xilinx toolset, proper engineering > analysis can be done. You must be a far better engineer than most if armed with the data sheets, user manual, and this magical "Xilinx toolset" do a proper engineering analysis. I'm amazed, dumb founded. Interesting how you might do it ... I've yet to figure out a way to determine peak ground path current for a specific device/package to get a clue about die observed vccint and ground ripple voltages. No where do I see a V4 spec for max ground currents, or even vccint currents for that matter, in order to make sure the die sees the spec'd min 1.14v between vccint and gnd on die after the drops on the carrier/package. The V4 users guide discussion is VERY general about max I/O switching per bank, nothing about peak currents, but does allows us to sum up the estimated ground currents for the I/O's. Peaks for I/O's are probably several times that. But I would love to know where you found the peak current for clb/ff/bram switching currents following a clock. I'd also like to see where you found the voltage drop between the balls and the die for this aggregate (IO + VccInt) current for both the vccint and gnd paths in terms of both resistance and the via inductance of the chip carrier from balls to die. Last time I went into power estimator for xc4vlx200 and put in 200mhz 25% toggle for luts/ff's for 97% of the device, there was not a viable thermal solution where the die remained within spec at 125C. The extimated power with very modest I/O was well about 40W generating ground currents that would most likely peak currents well above 120A at clock edges. I suspect the part will not work even derated this much, much less at a clock rate that would be expect or a higher utilization than 25%. Admittedly that was a long time ago, maybe it's better today. So, since you are cluefull about all this, what are the numbers? Is it really necessary to derate the device better than 50% in rated clock performance just to get these over thermal worst case numbers? Can the large FF packages handle a better than 100A peak current at clocks without leaving the device unstable? What is the die ripple at these values? For that matter, none of the board vendors disclose what their gnd/pwr plane to ball resistance and inductance is either, so the end user is double stuck ... no detailed board data, no detailed fpga vendor data, to do a "proper engineering job" to figure out just how much the board needs to be derated and not violate power limits. These are the easy questions :( So, where did you find any RC vendor that managed to do their own P&R? > If the RC is provided through alternative tools, those tools should be able > to deal with the design limits of the device; in this case the person > reconfiguring the PCI add-in board certainly won't be able to draw useful > information from the data sheet and may not know which data sheet values > even apply to them. They're dealing with the board, not the part. The > board data is what guides them.Article: 95604
In article <F8fBf.15030$Jd.5425@newssvr25.news.prodigy.net>, Joerg <notthisjoergsch@removethispacbell.net> writes >Hello Chris, > >Laws, regulations, more laws. One trait of engineers is or at least >should be that they know where their limits are. Not because they are >told by bureaucrats You keep going on about bureaucrats setting the rules and every reply has told you that the rules are set by qualified and experienced ENGINEERS. You seem to have a problem of being judged by your peers. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/Article: 95605
toys, A comment about modeling the FPGA and package: Look up Howard Johnson's presentations. Ball/pad inductance is useless (last year's solution). I am surprised you bring it up. HJ proves that it is the loops and their topology that matter. And without a 3D field solver, you have no hope of learning anything at all. Except if you use our FPGAs: we do the hard stuff so you don't have to (e.g ParseChevron (tm), patents pending). The number of planes, and bumps/balls for Vcc's and ground ensure that the voltage drops are kept within the required limits, even for your 40 watt design. It is up to you to design the PDS for your board, and we have applications notes to help you in that regard. Comments we have received include folks who now tell us that the SparseChevron packages(tm) are superior to IBM's "cross" design. I'm happy to just be in the same league. http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/advantages/sipi.htm http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf AustinArticle: 95606
Oops, SparseChevron(tm). Austin Austin Lesea wrote: > toys, > > A comment about modeling the FPGA and package: > > Look up Howard Johnson's presentations. Ball/pad inductance is useless > (last year's solution). I am surprised you bring it up. HJ proves that > it is the loops and their topology that matter. And without a 3D field > solver, you have no hope of learning anything at all. > > Except if you use our FPGAs: we do the hard stuff so you don't have to > (e.g ParseChevron (tm), patents pending). > > The number of planes, and bumps/balls for Vcc's and ground ensure that > the voltage drops are kept within the required limits, even for your 40 > watt design. It is up to you to design the PDS for your board, and we > have applications notes to help you in that regard. > > Comments we have received include folks who now tell us that the > SparseChevron packages(tm) are superior to IBM's "cross" design. > > I'm happy to just be in the same league. > > http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/advantages/sipi.htm > > > http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf > > AustinArticle: 95607
fpga_toys@yahoo.com wrote: > > :) for traditional state machine & data path designs sure, old accepted > numbers everyone uses as a rule of thumb. For packed hand crafted RC > application accelerators I think it's a lot worse than 15%, as my not > so hand crafted demos have easily done better. > > > > An RC5 pipelined cracking demo I did last year easily got the > XCV2000E's on the Dini board HOT quickly. Even after adding heat sinks > with forced air they were HOT. I was only using a little over half the > device for the demo. Similar experience with XC2V6000's. That's not > "some cases" from my view, and we have a very different view of > "typical" for RC uses. I haven't gotten my hands on XC4VLX200's yet, > but static analysis suggest similar problems. > > And yes, I've since cooked a couple XCV800's, so I have the sense now > to check FPGA's when testing a new application or demo. When RC cards > do not even have the temp diode monitor IC connected to the FPGA, it's > difficult for an RC programmer even to be able and check the chip temp > when it's stuffed in a box, and automatically shut the app down or > throttle back the clocks. > > So that brings us back to "typically" and "worst case" for acceptable > design standards for RC boards. Allowing the end user to easily toast > $10K boards, and returning them to mfgr as warranty replairs, isn't > good design practice. Nor does such poor reliability reflect well on > the supplier chain for the devices, or the industry in general. > Numeric apps will not exceed about 15% by the nature of the number system, unless you are alternating positive and negative numbers on alternate clock cycles. It isn't so much a function of the design, it is a function of the properties of the number system. Yes, I know you can make a part hot with an average design, been there done that many times. However, that was not what I was arguing. I was refuting your claim of near 100% utilization with near 100% toggle rates. I think if you evaluate the average toggle rates in your designs, you aren't going to find them to be much above 15% unless for some reason you are alternating the sign on alternate cycles. If that is the case, you can substantially reduce your power consumption by moving to a sign-magnitude number representation instead of 2's complement. It is pretty easy to come up with a design that will abuse the part by toggling every flip-flop and SRL16 at 100% with a clock near the upper limit. What does that prove? Well, about all it proves is that you can exceed the design limits of the system your FPGA is installed in if the FPGA has not been adequately cooled for that abuse. As to getting the FPGA too hot for the installation, that is not the fault of the FPGA, rather it is a fault of the board design. If the board is designed for general purpose use, either the power supply should (virtually all FPGA boards now have on-board power supplies) should current limit at some value less than where the FPGA or board are physically damaged, or the design should make use of the temperature diodes. These are provided for exactly that purpose. BTW, limiting power supply output is a very effective way of limiting the power dissipation of the FPGAs. The current limits are going to depend on how well the FPGA is cooled, so it is going to vary application to application. As for predicting the FPGA dissipation, that is difficult enough to do when the design is completely known, placed and routed, especially for designs the process data sourced off the FPGA, as the power dissipation is very much data pattern dependent. Xilinx provides tools for estimating power, which do about as good a job as they can given the constraints. For the spreadsheet, you the designer is responsible for estimating toggle rates, routing complexity, and part utilization. It is meant as a planning tool, although you can also back your completed design into it. Since it has no knowledge of the routing or your actual data, or for that matter the actual circuit, it is just an estimate. I find that it tends to be on the conservative side, especially with floorplanned designs, but as far as getting an actual number figure +/-12dB. The XPower tool uses the actual netlist and simulation vectors, and will give you very accurate worst case power....for the test vectors given. If the actual use doesn't match the test vectors exactly, the power will be different. That makes even the awkward to use Xpower tool of only marginal usefulness in designs that process data from outside the FPGA, simply because you can't accurately model all the possible data sets (if you could, you could replace the FPGA with a ROM). So my point is, the FPGA vendors give you the information they can about power dissipation. They can't know your design to provide you better numbers without you actually simulating the post PAR design with vectors that accurately reflect the actual usage. For a general purpose board, the board designer can limit the FPGA dissipation to whatever is safe for the board cooling environment by using thermal diodes or power supply current limits to avoid damage to the FPGA or board, and he can do that without knowing anything about your design. Isn't that a better tree to bark up?Article: 95608
Ray Andraka wrote: > So my point is, the FPGA vendors give you the information they can about > power dissipation. They can't know your design to provide you better > numbers without you actually simulating the post PAR design with vectors > that accurately reflect the actual usage. For a general purpose board, > the board designer can limit the FPGA dissipation to whatever is safe > for the board cooling environment by using thermal diodes or power > supply current limits to avoid damage to the FPGA or board, and he can > do that without knowing anything about your design. Isn't that a better > tree to bark up? So, my point is, and nobody seems to disagree, that it's unrealistic to assume that the devices can be 100% packed, use the marketing numbers for system design clock speeds, at a modest toggle rate, and not blow right thru the power the device can handle. Disagree? If not, then the device HAS TO BE DERATED from marketing numbers for RC use. Disagree?Article: 95609
On Tue, 24 Jan 2006 19:39:32 +0000 in comp.arch.embedded, Chris Hills
<chris@phaedsys.org> wrote:
>In article <F8fBf.15030$Jd.5425@newssvr25.news.prodigy.net>, Joerg
><notthisjoergsch@removethispacbell.net> writes
>>Hello Chris,
>>
>>Laws, regulations, more laws. One trait of engineers is or at least
>>should be that they know where their limits are. Not because they are
>>told by bureaucrats
>
>You keep going on about bureaucrats setting the rules and every reply
>has told you that the rules are set by qualified and experienced
>ENGINEERS.
>
>You seem to have a problem of being judged by your peers.
That's not the impression I got at all.
My impression is that Joerg has determined that the costs of
registration (not all of which are monetary, and which he's tried to
describe, but some people aren't listening) are too high for the
benefits obtained.
It also seems you feel his rejection of registration has somehow gored
your ox. As you often point out yourself, this is an international
forum, and things aren't the same everywhere.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Article: 95610Austin Lesea wrote: > Look up Howard Johnson's presentations. Ball/pad inductance is useless > (last year's solution). I am surprised you bring it up. HJ proves that > it is the loops and their topology that matter. And without a 3D field > solver, you have no hope of learning anything at all. I've watched his presentation ... and it explained the horrible problems I had with Virtex and Virtex-II packages when pushing the power envelope. > The number of planes, and bumps/balls for Vcc's and ground ensure that > the voltage drops are kept within the required limits, even for your 40 > watt design. It is up to you to design the PDS for your board, and we > have applications notes to help you in that regard. The point of the 40w design, is that it's derated. Doubling, or better, the clock rate to get best possible device performance per P&R timings with a netlist that is busier than 25% and you quickly hit the power limits of even an active cooler. The data sheets imply clock rates that would easily produce designs well over a 100w in this package ... and that is where I start to seriously worry about the cross section of copper/lead in the package. Worry, is because none of the data is specified to know where the limits are ... IE max currents for gnd and each power group, and what those current profiles look like in rise times. That provokes the question of is derating necessary, if so how much, and can we easily get numbers to calculate that? not currently. JohnArticle: 95611
Hello Chris, >> >>Laws, regulations, more laws. One trait of engineers is or at least >>should be that they know where their limits are. Not because they are >>told by bureaucrats > > You keep going on about bureaucrats setting the rules and every reply > has told you that the rules are set by qualified and experienced > ENGINEERS. > Huh? Maybe in the UK, not so much here. > You seem to have a problem of being judged by your peers. I don't. I do have a problem with overly restrictive regulations and so does our industry. Regards, Joerg http://www.analogconsultants.comArticle: 95612
I am usig xilkernel on microblaze spartan 3 board. I am getting an unusual
error that is
undefined reference to `xilkernel_main'
when i write the code below
int main (void) {
print("-- Entering main() --\r\n");
xilkernel_main();
print("-- Exiting main() --\r\n");
return 0;
}
Any idea what is wrong. I did configure input and output port (as RS232),
i am using timer1 as the sytem timer for xilkernel. I have statically
linked only two task using "software Platform Setting" in
'static_pthread_table' entry. There is no resource on this subject on
xilinx website. Please help.
David
Article: 95613fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>So my point is, the FPGA vendors give you the information they can about >>power dissipation. They can't know your design to provide you better >>numbers without you actually simulating the post PAR design with vectors >>that accurately reflect the actual usage. For a general purpose board, >>the board designer can limit the FPGA dissipation to whatever is safe >>for the board cooling environment by using thermal diodes or power >>supply current limits to avoid damage to the FPGA or board, and he can >>do that without knowing anything about your design. Isn't that a better >>tree to bark up? > > > So, my point is, and nobody seems to disagree, that it's unrealistic to > assume that the devices can be 100% packed, use the marketing numbers > for system design clock speeds, at a modest toggle rate, and not blow > right thru the power the device can handle. Disagree? > > If not, then the device HAS TO BE DERATED from marketing numbers for RC > use. Disagree? > Umm yes, I disagree. I've got several designs that are 90%+ packed and are being clocked at clock rates well beyond typical design clock rates. Many of these have active cooling, but it is certainly possible to fill up and use a device. You won't get the density and performance without handcrafting to meet both the density and performance limits. The typical user is going to run into place and route issues before he even gets close to the high density, high clock rate corner. I don't care if it is an RC application or not, you just don't get into that corner unless you do a considerable amount of handcrafting on the design. BTW, the handcrafting also helps tremendously with power, as a significant percentage of the power is dissipated in the routing rather than in the logic. If you keep the routing short and the design is maximally pipelined (stops lgitch propagation), the power dissipated by the routing can be kept relatively small. you can look at the designs on my gallery page for some older examples of designs that are dense and running near the limits of clock rate. My point is, you'll probably need to derate for shortcomings of an RTL synthesis tool flow before derating for a full device, and as for derating for a full device the power dissipation is so dependent on the design and PAR solution that there is no way to accurately predict it. Worst case numbers are totally meaningless in this scenario as well. You could generate a design that purposely toggles every ff and intentionally congests the routing by forcing poor placement, and have something that could easily melt the balls right off. With proper cooling and attention to I/O switching, you have a shot at making it actually work in silicon. So where do you set the max based on circuit configuration? The answer is you can't. Instead, the best one can do is give the thermal characteristics of the package/die combo, maximum die temperature and provide the tools to allow someone to simulate this if they are concerned about it (like I said, the simulation is also meaningless unless it accurately models the data in the operational deisgn). If you are using the spread sheet estimator, you may be setting it up wrong to get meaningful answers. The routing complexity knobs have a lot of influence over the result, and are difficult to set in a meaningful way. For a floorplanned design, setting those to low complexity often still gets power estimates that are 2-4x higher than what is measured on the board. For a design with poor placement, and multiple levels of logic, I've seen the estimator come in with much less margin. Again, for data designs, you will rarely see greater than a 15% average toggle rate, and as I said, that is a function of the number system more than of the design itself. Anything much above that can be considered high toggle rates, not modest toggle rates as you propose. A reminder too, it doesn't take many watts to make a chip without a heatsink feel hot to the touch. 5 watts is enough to burn your finger if the heat isn't dissipated. The same chip can handle 30 watts or more with a decent heatsink without excessive effort spent on cooling. The fact you burnt your fingers on an FPGA without a heatsink tells you very little about how close you were to the design corners for the FPGA, nor does the fact a device with a heatsink got warm to the touch. All it tells you is that in the first case, you probably didn't have adequate cooling for the design, and in the second case not even that (a chip cooled to 105F will feel warm to the touch, even though the silicon will run at nearly double that (85C) without any derating).Article: 95614
Access to Xilinx's web site always seems to be slow... and I've lost count of the # of times I get the "We apologize... A technical problem has interrupted your session. We apologize for the inconvenience this has caused you." I guess that's why you're a hardware company and not a software one :) StephenArticle: 95615
Antti Lukats wrote: > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag > news:43d60cb2$1@clear.net.nz... > >>Antti Lukats wrote: >> >><snip> >> >>>You right Peter, >>> >>>I am not fair. The life isnt either. >>> >>>But I am not making anything up. This is something I do not do. (Sure I >>>am wrong sometimes, that has happened). >>> >>>1) All my latest WebCase's are handled from China or at least from people >>>with chinese names. >>>2) someone else (I assume from US) reported the same for his 3 last >>>WebCases, he also called and reached answer machine in chinese. >>> >>>So thats why I assumed that the _global_ WebCase support has been moved >>>to China/chinese. What I said was/is true for me as to my best knowledge >>>of the time of my writing. >> >><snip> >> >> That's quite a large leap, Antti, from 'Chinese name' to 'Must live in >>China' - did you check the email time tags, that often gives a clue to the >>time zones you are working between ? >> China <-> EU is not the most natural choice ? >> >>-jg >> > > > maybe I mis-judged. I havent checked the email header time tags. Some else > (also having Xilinx issues) was complaining about the answer machine on his > WebCase contact to respond in chinese, so I checked the names from emails > and found his assumptions about the WebCases now being handled by people > with chinese like names to be true. > > Maybe I am too hard at (Xilinx WebCase support) as my issues are usually not > such that the WebCase assigned person has any chances to help. He always > needs to contact others and that makes it really long to get some meaningful > response. ..and I am sure your web cases send a shudder down any novice support person.. :) So I do not really have hopes that a WebCase helps if it is not > 'accelerated' but then ah, it makes possible more sense to immediate > 'accelerate' the issue, and that is something that Xilinx doesnt like of > course. But if immediate acceleration of an issue brings the solution even a > few hours faster then it is a few hours won. > > I am pretty sure that there are people at Xilinx who are thinking very > seriously how to actually improve the software, support and services so lets > hope it will get better. There is lots of space for improvements, in all > areas. I think your WEB Bug list is a good idea - Yes, we can understand ISE 8.1i is new SW, and yes there will be issues, but the backward-steps are the real 'eyebrow raisers'. Seems they suffer the big-company disease, and become too marketing dominated ( and worse, start to believe their own PR spin... ) - so nice public examples of user base problems are things the engineers left within Xilinx can use as leverage to get more resources to do the job properly, are a good thing. -jgArticle: 95616
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:ykuBf.2827$2O6.1794@newssvr12.news.prodigy.com... > Hello Bo, > > >>>I just re-checked the application form here in CA. It looks like it's up >>>to four refs now and says "These individuals must be licensed as >>>professional engineers in the discipline for which you are applying". >>>That would rule out my CE friends. Also, it says you must have been >>>"engaged" with them, meaning a work relationship. Well, I never designed >>>any bridges for them ;-) >>> >>>That would make it all toast I guess. I never worked with any PEs, just >>>with one EIT. >> >> That sucks. The rules do vary from state to state a little. I guess Ca is >> more anal than most (?) >> > > Well, as Ray said it may be best to talk to them. Last time I did they > wouldn't budge. Which makes the whole program kind of irrelevant because > they'll never reach critical mass. > > >> Perhaps you could take the exam in a neighboring state instead? AZ/NV? >> > > That won't help when you live in CA. The real paradox is that if you have > the certs in one state it still doesn't allow you to work under it in > another. So theoretically you'd need 51 registrations (with fees...) to be > able to work countrywide under PE. Makes no sense to me at all. > Not necessarily. Most states PE board have 'commity' licensure--ie recognition of PE from another state and will allow you to hang a shingle in their state if you pay the fees etc to have the license transferred--or maybe better stated "reissued in the commity state". A coworker of mine is PE in 3 states and only took exams in one. (ie NC, GA, AL). BoArticle: 95617
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>So my point is, the FPGA vendors give you the information they can about >>power dissipation. They can't know your design to provide you better >>numbers without you actually simulating the post PAR design with vectors >>that accurately reflect the actual usage. For a general purpose board, >>the board designer can limit the FPGA dissipation to whatever is safe >>for the board cooling environment by using thermal diodes or power >>supply current limits to avoid damage to the FPGA or board, and he can >>do that without knowing anything about your design. Isn't that a better >>tree to bark up? Yes, it is better to train designers to check thermal levels - after all, everyones car has a temperature guage, so even the real HW novice can relate to that ! There could be a case for multiple thermal diodes, in a FPGA die, to avoid missing a hot area - or some way to 'route relative' to the sense diode ? :) Does anyone do that now ? > So, my point is, and nobody seems to disagree, that it's unrealistic to > assume that the devices can be 100% packed, use the marketing numbers > for system design clock speeds, at a modest toggle rate, and not blow > right thru the power the device can handle. Disagree? That's correct. But apart from the thermal measurement, about all you could do is something like a transistor SOAR ( Safe Operating ARea ) polygon, - and that will have some many caveats, it might confuse more than it helps. I would push for thermal verify - if you are doing RC designs, then simply demand a PCB that HAS thermal management! > If not, then the device HAS TO BE DERATED from marketing numbers for RC > use. Disagree? Not entirely - so long as a usable portion of the fabric runs at Fmax, then that is a valid number. The bottom line is thermal: so why not just focus on that ? - more accurate than any predictive clock usage based modeling, which will be far more 'cockpit error' prone. I also like the idea of Freq tracking cells, that use ring oscillators to give Vcc/Temp/Process auto-correcting values, and allow you to clock _really_ at the safe-limits, but I have not seen that deployed yet. Do this, and the leading RC boards would quickly become VERY thermally efficent, as that gives the best performance. -jgArticle: 95618
Spartan = FPGA ARM = MicroProcessor The difference between them is pretty extensive. Yes, you can program an ARM uP using C/C++. All you need is software to compile that into assembly. You can't write HDL for an ARM. Why would you? It would have to be translated into assembly as well, which just doesn't make sense. HDL's are Hardware Definition Languages. They are used to describe hardware, not software. The key feature of HDL's is that there is a subset of the language that is synthesizable to hardware. You don't have to spend time connecting things at the gate level or macro level on a schematic. You write code that describes what you want your hardware to do. It is possible to embed a microprocessor (even an ARM) into an FPGA and have it control your hardware. This gets complicated. Quickly. An FPGA allows you to design your own hardware logic. A microprocessor allows you to write code targeted to a specific device to perform some function or functions. You cannot create any more hardware than what the ARM (or whatever you use) provides. The Spartan, like all FPGA's, are basically blank slates. Save for some internal structures like clock logic, RAM's, built-in DSP blocks, etc, it is up to you to create whatever you can realize in hardware, connect it all together and see if it works. It really depends on what you need to do. Each device has its own strengths and weaknesses. Hope this helps.Article: 95619
I suggest we wait for the original poster to clarify. I think there is no real need for a dual-edge triggered flip-flop. Definitely not at the low frequenciesmentioned. There is also a simple circuit that XOR differentiates the clock, thus generating a clock pulse at both the rising and the falling edge. (See, among others, at "Six Easy Pieces" in TechXclusives) Peter AlfkeArticle: 95620
Hi John ! I checked the XAPP 684, and don't see where it deals with fpga programming... Maybe I read it too fast X.Article: 95621
Brian,
Thanks, this was really useful.
I'm using version 7.1 of ISE and yes, I have the unisim library lines in the
code.
I used the generic ... IOSTANDARD = LVDS_25_DT on an IBUFDS as you suggested
and it worked! I don't know why and probably never will but it allows me to
progress with the design now. Thanks again.
Roger.
"Brian Davis" <brimdavis@aol.com> wrote in message
news:1138073412.403694.257500@o13g2000cwo.googlegroups.com...
> Roger wrote:
>> The part is Virtex IIPro. It's not the DCI I'm looking for, it's the
>> on-chip
>> 100R termination.
>>
> What version of ISE?
>
> Are you using the unisim library like this:
> library unisim;
> use unisim.vcomponents.all;
>
> Or, defining the component yourself?
>
> Instead of using the named suffix I/O buffer, try sticking an
> IO_STANDARD of LVDS_25_DT on an input buffer of type IBUF{G}DS
>
> See also Answer Record 17244
>
> Brian
>
Article: 95622Hello Bo, >>That won't help when you live in CA. The real paradox is that if you have >>the certs in one state it still doesn't allow you to work under it in >>another. So theoretically you'd need 51 registrations (with fees...) to be >>able to work countrywide under PE. Makes no sense to me at all. > > Not necessarily. Most states PE board have 'commity' licensure--ie > recognition of PE from another state and will allow you to hang a shingle in > their state if you pay the fees etc to have the license transferred--or > maybe better stated "reissued in the commity state". A coworker of mine is > PE in 3 states and only took exams in one. (ie NC, GA, AL). > That's what I meant. Comity allows for mutual recognition to avoid having to sit through umpteen exams. But they all want the paperwork and their fees. I just wonder why the states can't just accept each others licenses at face value. Guess it's a turf issue and they all want the money. Regards, Joerg http://www.analogconsultants.comArticle: 95623
Jim Granville wrote: > Neil Glenn Jacobson wrote: >> Jim Granville wrote: >> >>> Neil Glenn Jacobson wrote: >>> That's Spac 3 ?! - did I miss Spac 1 and Spac 2 ? - and 8.1i is only >>> days old.... >>> >>> -jg >>> >>> >> Jim, >> >> 8.1i was released December 5th, 2005. Service Pack 1 was released Jan >> 9th. Service Pack 2 is making its way through the release process >> with a projected release date of Feb 9th. Hope that helps. > > Thanks Glenn, I've given this a new title, as it is usefull > information for project planning. > Do you have a tentative date for Sp3 [ Mar 9th :) ] ? > > -jg > Typically, service packs are released every 4 to 6 weeks.Article: 95624
fpga_toys@yahoo.com wrote:
[ ... ]
> So, my point is, and nobody seems to disagree, that it's unrealistic to
> assume that the devices can be 100% packed, use the marketing numbers
> for system design clock speeds, at a modest toggle rate, and not blow
> right thru the power the device can handle. Disagree?
>
> If not, then the device HAS TO BE DERATED from marketing numbers for RC
> use. Disagree?
Looking in from the sidelines, it seems to me that quite a bit of this
conversation is taking place more or less cross-purposes.
First of all, I think "derating" is a poor term -- though I tend to
agree that they might be able to provide more useful numbers. One
possibility might be to more or less directly specify the heat output
from the chip (as a whole) per million (or whatever) transitions per
second. This might give a better idea about trade-offs between faster
clocks vs. more gates. Unfortunately, it has a substantial problem
(thats been alluded to elsethread): it's basically dealing with the
power consumed by logic, not by routing, so in any given design it
might be off by a fairly large factor. I can believe that it could be
reasonably useful for things like product selection though -- if you're
planning to encrypt at a rate of X gigabytes per second (for example)
it's fairly easy to figure a rough idea of the number of bit
transitions involved and see if you're at least in the right ballpark.
This wouldn't tell you that a design _will_ work, but it'd at least let
you separate things that stand a reasonable chance from those that
don't.
Second, in terms of providing a general-purpose computing resource, I
don't think anything Xilinx (or anybody else) can provide in a
datasheet is going to mean a whole lot. If you're providing a product
for end users (instead of engineers) you need to make it foolproof.
Nothing in the datasheet is going to
Whether Xilinx should provide a circuit like that on-chip (e.g. like
most CPUs now have) is open to some question -- it would likely add a
more or less fixed amount to the product price. An amount that would
hardly be noticeable in a big Virtex would be utterly prohibitive on a
small Spartan. Perhaps this would be a reasonable feature to add on the
next generation of Virtex chips though...
--
Later,
Jerry.
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