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
On Thu, 16 Mar 2006 14:47:19 -0800, Austin Lesea <austin@xilinx.com> wrote: >But I do trust engineers will do the best job they can given the tools.... there is absolutely no evidence that that assumption is valid. in fact, there is ample evidence all around us, that engineers will do whatever they're told; and that they produce -enormous- numbers of sub-optimal designs; along with many truly awful designs as well. >snip >>> Why? Because the microcontrollers can not be maintained for ten >>> years, whereas the car maker can always buy any future version of our >>> FPGA, and put their old VHDL/verilog into it. Maintaining stock for >>> all cars sold for replacement assemblies for ten years was driving the >>> maker broke (pun intended). >> >> >> ?!? - I'm hoping this is just Austin's enthusiasm, because if the >> Luxury Car vendor really believed this, that is truly scary. >> >> Would YOU drive off, in your luxury car, in 10 years time, where >> they had 'just respun' the VHDL code, thru new tools, into the >> newest FPGA ( _and_ assuming that newest FPGA _AND_ PCB will physically >> fit at all !? ). >> >> This is nothing but a lawyer's feeding trough.... >> >> -jg >> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98826
Peter Alfke wrote: > Amen. > I think an occasional typo happens, but this complete disregard for > manners is deplorable. > And: Urgent Help Needed with five exclamation marks is not the way to > enlist free assistance. > Who is responsible for teaching basic manners these days? It used to be > our mothers... Back in the BBS days, you generally just used to get ignored, or flamed to charcoal (In the stricter cases typos/mispellings would even get you some stick :))) if you went online with that kind of language.. Sadly, I'd associate that kind of language abuse as being around the age level of a 15 year old - a level where a person should be expected to be fairly competant with their first language. my 2c JeremyArticle: 98827
PeterC wrote:
> Ahh, Verilog strikes again. I don't speak Verilog but I'm sure there
> would be similar constructs in VHDL.
This would be right on-topic in comp.lang.vhdl.
-- Mike Treseler
Article: 98828Austin Lesea wrote: > Jim, > > Hee hee. > > Just the facts, Jim. When we see the PO for hundreds of thousands of > chips, we have to believe they are doing something with them. Believing > what they told us is one option. What _exactly_ did they tell you ? It was not the target I found surprising, but the _reason_ you offered. I _can_ think of some reasons to use FPGA on the higher priced/lower volume vehicles, but I find it very hard to believe a car companies design engineers, (or even middle managment!), truly believes they : ".. can always buy any future version of your FPGA, and put their old VHDL/verilog into it. Maintaining stock for all cars sold for replacement assemblies for ten years was driving the maker broke (pun intended)." Then what ? Do they think that any future version will drop into the same socket ? ( err Socket ?! ) .... ROTFL. > How is this use any different from the latest version of Windowz > controling the police car's computer dispatch system? Well, we can only hope those 10 FPGAs are going into the marketing froth interior, and not something like Airbag, Traction control, Fuel Injection.... -jgArticle: 98829
Users of SVF files need to "precompile" the chain composition and intended functionality into the SVF file itself. For instance, I have 8 devices, they are arranged as follows: TDI->X->X->X->A->L->X->X->X->TDO and I want to erase program the fourth device. All that would be encoded in an SVF file. If the number of devices changes, the algorithms change, the data changes or the desired operations change you need a new file. In addition, SVF has no algorithmic flow control (i.e., branch on condition) so come device configuration algorithms cannot be described. IEEE Std 1532 defines device behaviors, an extended BSDL file and a data format that allow you to dynamically describe device operations. You can also describe concurrent configuration algorithms in which multiple devices are accessed together for better programming throughput. Xilinx provides a free 1532 environment called JDrive which you can download from the their web site: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=dr_configsol_jdrivemain_page The actual standard can be purchased at the IEEE at: http://shop.ieee.org/ieeestore/Product.aspx?product_no=SH95071 And a really good book about in-system programming ;-) can be bought here: http://www.amazon.com/gp/product/140207655X/sr=8-2/qid=1142558227/ref=sr_1_2/102-5474416-6343348?%5Fencoding=UTF8 nemesis wrote: > Hi All, > > I would like to know when should I use the IEEE 1532 files. > > I found that "Users will now be able to program chains of ISC PLDs, from > multiple vendors using the same third-party software tools and the same > Boundary Scan interface. Users will no longer be required to have > vendor-specific programming support or knowledge". > > But if I want to program a device I use the SVF files, so what makes me > need the 1532? > > Where can I find detailed information about the way of use it and the > sofware for this? > > > Thanks for your attention. > >Article: 98830
Jim, OK, here is the problem: If you buy Froto's uP, they make a new one every year, and you have no choice but to switch to the new unit, or stock enough of the old units to serve your entire replacement need. So, the car company goes to Froto, and say "Froto: attention! We want the same uP guaranteed for a long time." and Froto says: "huh? did you hear anything? did someone say something?"..."nope, must have been the wind..." Then the car company comes to Xilinx, and says "do you have a solution?" and we say: sure, use a soft uP (like Microblaze), and just retarget the last version of the code to the next version of our FPGA (which we maintain for a much longer time in production -- just look at the products that we have that are more than ten years old, and we still sell lots of) when you go to the next model. Most of the IP is in c code, compiled for uBlaze, with a smattering of VHDL for interface. Not even a big change from what they do now, just more efficient because they buy fewer ICs to do the same job (special goofy peripherals are soft in the FPGA). And no strange ASICs ever required. Car company goes "darn, we could save 10M$ a year for just one model, just in the first year! Next trivia question: why did the new car need a xc4Vfx12? Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim, >> >> Hee hee. >> >> Just the facts, Jim. When we see the PO for hundreds of thousands of >> chips, we have to believe they are doing something with them. >> Believing what they told us is one option. > > > What _exactly_ did they tell you ? > > It was not the target I found surprising, but the _reason_ you offered. > > I _can_ think of some reasons to use FPGA on the higher priced/lower > volume vehicles, but I find it very hard to believe a car companies > design engineers, (or even middle managment!), truly believes they : > > ".. can always buy any future version of your FPGA, and put their old > VHDL/verilog into it. Maintaining stock for all cars sold for > replacement assemblies for ten years was driving the maker broke (pun > intended)." > > Then what ? Do they think that any future version will drop into the > same socket ? ( err Socket ?! ) .... ROTFL. > >> How is this use any different from the latest version of Windowz >> controling the police car's computer dispatch system? > > > Well, we can only hope those 10 FPGAs are going into the > marketing froth interior, and not something like Airbag, Traction > control, Fuel Injection.... > > -jg >Article: 98831
Apologies Mike, you're absolutely right. I have figured it out.Article: 98832
It was never meant to hurt you people.If my "u" instead of "you" caused so much trouble to understand the FPGA problem i mentioned in my post then it is something which nobody on this planet can help you(instead of "u"). Here is another kind of breed like Jeremy which is scared of exclamation marks...unbelievable... Also we are not discussing a particular language here rather we are here to sort out some technical problems so if u know the answer then you are most welcome.Otherwise showing your pedantic nature is not soloicited.Article: 98833
Thank you Saroj for your generosity. If we feel offended by his imbecile spelling, he graciously allows us to shut up. Thanks a million ! Peter PS. who was it that originally wanted some help from whom?Article: 98834
Thank you Peter for showing what you are good at.You have provided a new dimension to FPGA related problems. Thank you very much.Article: 98835
Peter Alfke wrote: > This thread has gotten much too esoteric and also too confrontational. > It is really quite simple and intuitively obvious: I'm trying hard not to be conrfontational. It's also intuitively obvious that 80% discounts do not materialize from reduced testing costs. > Everybody agrees that the manufacturing cost of chips grows > overproportionally with die size. certainly agreed > That's because, at a given defect density (=manufacturing quality > standard), a larger die is more likely to contain a defect than a > smaller die. Let's assume a percentage yield of 50% for a very large > perfect die. > The percentage yield for a 5 times smaller die would be much higher, > 85% or more. (This can be proven mathematically). > But we will also get that same higher percentage yield from the big > chip when we test only those 20% of the chip area that are really > needed by the user's design. Agreed. But a 70% increase in yield when silicon is a tiny fraction (5-20%) of the normal sales price (given high margins, fixed costs, labor, testing, etc totalling 80-95% of the cost structure) does not create an 80% discount. Maybe a 3-10% discount. That part of the math is intuitively obvious. > (Believe it or not, the average design uses less than 20% of the real > chip resources, even when the designer is using every CLB and BlockRAM > and thinks the chip is really full. You can call that the curse of > programmable logic and the reason for its higher cost than custom > circuits. Lots of internal circuits are unused in any specific user > implementation. But every design leaves different things unused.) > Throw in less testing cost, and EasyPath becomes a good business > proposition. I don't disagree at all. > We do not have to go "dumpster diving" to make money with > it. I've never suggested that. > It's all basic statistics and some sound reasoning. No need to > analyze our Annual Report either. > Peter Alfke That the 80% savings comes from testing is not sound reasoning. That it comes from other sources, like agressive competitive pricing to buy market share, I believe is sound reasoning. I have no problem is Xilinx stating that it wants to buy market share by dropping or eliminating it's high margin.Article: 98836
Austin Lesea wrote: > Sorry can't do. That would require an NDA, and a reason. I've lost track of the number of NDA's I'm party too ... have no problem taking yet another bit of information to the grave. The reason is harder to come up with ... that would be your call. > Seems I can't convince you of anything. > That is OK, I have gotten over that. > Keep me honest, When you can convince me that taking to zero an item which is less than 10% of the total pricing structure, will generate 25-80% cost savings to the customer, I will have seriously impaired facilities. Simply Amdhal's law applied to cost/price structures. Even Peter's example changing yields from 50% to 85% only reduces the total price by a few percent. Consider Peters example with some additional numbers -- 50% yeild on a $100 wafer with 100 parts, is $2 for each good part in silicon costs, to which testing, packaging, fixed production costs, and gross margin is added bring the total price of each part to $100 as an example. Increasing yield to 85%, only drops the silicon cost to $1.18, which at most would be an $0.82 drop in silicon cost and make roughly a $1.00 change (or 1% of price) in price since all the other costs, such as testing, packaging, fixed production costs, and gross margins (R&D, admin/sales, and stock holder return) dominate the per unit price. Assuming that testing costs as much as raw die, then 80% reduced testing will only change the cost from $2 to $0.40, saving $1.60 which might impact the price by another $2. Thus, by Peters example, based on yield increases, and testing saved, the net expected benifit to the customer would be $3 out of $100, or a 3% savings.Article: 98837
the schematic of that part is removed from the schematic printouts, its a duplicate of platform usb cable - as the platform cable pld on starterkit board is in non-BGA package it should be fairly simply to pull up the pins that go to on board jtag and use the starterkit as normal platform usb cable :) AnttiArticle: 98838
Mr Toy, I have never claimed 80% saving from reducing the testing cost. But I have shown, by a hypothetical example, that we can double the yield, and thus cut the EasyPath basic manufacturing cost in half. We can thus sell these parts for half price, while maintaining our usual margins. You do not have to explain to us how we are running, or how we should be running our business. I have been an electronics engineer since 1957, and Xilinx has been quite successful in its 21-year history. When we need your advice, we'll let you know. Peter Alfke, not ashamed to put his name under his writings.Article: 98839
Hi there.
I am testing out the WebServer demo for the ML403 card on a ML401.
When I try to connect to the card with the XMD I get the message:
UNKNOWN Processor Version (8)
Verify if FPGA Bitstream vas downloaded and DONE pin
went high.
(I even get this "error" if I start xmd on the WebServer demo that
comes with the card.)
(I suspect it is the same demo).
I found a possible answer to my problem at the Answer Database.
I should unzip the opb_mdm_v2_01_a.zip to the pcores folder in my
project, update
the coreversion in the MHS file from 2.00.a to 2.01.a and make the
project use/point to these
files instead of the default ones.
But how do I make the project point to these files instead of the
default ones?
Raymond
Article: 98840Chauhan You are still not getting it. Talk to your professors or project leaders about this thread. And mentioning your upcoming deadline suggests that you have not collaborated with anyone so far leaving it too late to figure it out. That usually invites a good luck comment, people here are not here to save students from deadlines. BTW where does Palnitkar say that Task and Function are synthesizable, page no please, that would be news to me. Actually language is very important! It is how we connect with other people well, since we don't see each other face to face. Language is the only way you can persuade perfect strangers to volunteer information, good language skills opens doors, trashy language closes doors. Don't they teach that anymore. First appearance comes through the keyboard. As for being pedantic, would you call your high school teacher pedantic for the same generous feedback. Pedantic would be if you were taken to task for a trivial spelling mistake or keyboard errors, everyone makes those and most people auto correct for that, but "u", "i", "ur" sticks out like a sore thumb. If you prefer to use infantile spelling as it seems many recent younger posters do, feel free to continue, it's your life. Would you write your resume or CV that way, perhaps you would, and if so you won't get hired in any advanced English speaking society. I was led to believe that India prided iteslf on having more good English speakers than the mother country, well maybe not. Netiquete may have gone away in many groups, but it survives pretty well in most of the technical groups that you posted to that have any content value. In case you didn't know, some groups (but not this one) will play good sport with homework questions, giving almost correct answers with a backward twist. There is an old rule, lurk for awhile before junping in. Too many old groups are falling apart due to spammage and homework and deliberate bad grammer, but this group is holding on for what its worth. Also the web can be easily googled these days, it doesn't forget what you post and if your identity can be connected to your posts, might as well play nice. JohnArticle: 98841
Hi all, I am trying to program a Spartan3 device. I can program the FPGA and it works.As well I can program the PROM. But the FPGA does not get programmed from the PROM. I checked the CCLK pin at boot on. There is no clock on that pin. Checked the INIT signal. It goes low and then high. Whats surprising is that I have been using this same design in the previous versions and they all work. For some reason the CCLK does not seem to start in this particular board. If anyone has faced a similar problem your suggestions would be very helpful. Also reading some errata sheet from Xilinx i thought maybe the VCCINT reaching its threshold last might cause problems. Since i have jumpers in the board for the power supplies I ensured that VCCINT is provided first and then the other voltages. Even then there is no difference. its actually surprising that the CCLK does not start at all. THanks and regards VasudevArticle: 98842
I've got a dev.board from Digilent (XUPV2P, [1]) with an Xilinx Virtex-II Pro (XC2VP30, to be exact). I've been reading up and it seems that most say it's impossible to implement SerialATA with this, even with additional logic? My plan was to use this device as a "snoop-device": - One connection to a PC motherboard - One connection to a DVD/HDD - Implement the ability to log traffic - Implement correct forwarding between the two so that they both think everything is like if they were connected directly to eachother. Is this really impossible with this FPGA, or is it possible with the right additional logic (I was thinking of connecting this additional logic to the SATA-ports on the devkit)? In advance, thanks! -- ThomasArticle: 98843
Peter Alfke wrote: > Mr Toy, I have never claimed 80% saving from reducing the testing cost. Maybe not, but that is the standing reason presented, was it not? > But I have shown, by a hypothetical example, that we can double the > yield, and thus cut the EasyPath basic manufacturing cost in half. We > can thus sell these parts for half price, while maintaining our usual > margins. Actually, that assumes that distribution of overhead costs and margin are proportional to die cost, which may well not be the case, and in fact it's likely they are proportional to total costs including packaging, support, and other overheads, which is the basis for probing the statements. It also ignores the additional direct higher NRE and costs of supporting an additional product with shipment volumes a tiny fraction of other FPGA sales. > You do not have to explain to us how we are running, or how we should > be running our business. I'm simply objecting that over simplified justifications for the market segment simply do not make sense as presented so far. Frankly Xilinx is free to do business as it pleases. As I and others are free to question and probe for understanding. We can agree to disagree. > I have been an electronics engineer since 1957, and Xilinx has been > quite successful in its 21-year history. > When we need your advice, we'll let you know. Frankly, you did not ask for any advice, nor did I OFFER any. Nor have I questioned your employers success. When any person posts on any topic, including speculation of your employers market, product, business plan that is NOT an inventation for YOU to tell them to SHUT UP. > Peter Alfke, not ashamed to put his name under his writings. Posting under this handle HAS NEVER BEEN A QUESTION OF SHAME. Your continued personal attacks are however grossly shameful on your part, and shame to the wonderful reputation of your employer you mistakenly think you are protecting with your lack of civility. John BassArticle: 98844
actually before anyone replies to this. I checked up the mode pins and one of them werre not soldered properly. did check that before. but seemed like i did a mistake the first time. sorry and thanksArticle: 98845
> Eric, I also believe you're mistaken about timer/counters; which have > been hardwired into virtually -every- microcontroller made since the > dawn of time; and nobody has had a problem using them in their fixed > configurations. Every time I've tried to use a timer built into a microcontroller, I've run up against arbitrary limitations. Most commonly, the inability to gate the timer on and off with an external signal, which using either a second signal or the CPU clock as the timer clock. Often the prescaler choices leave a lot to be desired. I dispute any claim that "nobody has had a problem using them". > And I think at least one or two engineers have found them to be an > "advantage"... LOL Sure. But having some simple-minded hardwired counter in an FPGA won't be an advantage, because it won't do exactly what you want, so you'll end up designing your own anyhow. > Perhaps you are focused on "computing"; judging by your comment that a > MAC is more "useful" than a timer-counter. No, I do a whole lot of embedded design, including a lot of stuff with timer-counters. I use MACs sometimes to interface embedded systems to computer networks. If I had a choice between having a hardwired MAC in the FPGA, or a hardwired counter-timer, I'd definitely take the MAC, even though I would use it in less than 10% of my designs, because I'd probably use the hardwired counter-timer in 0% of my designs. For instance, I wrote the firmware for the Precision Navigation TCM1 tilt-compensated electronic compass OEM module back in 1994, using a Mitsubishi M740 series 8-bit microcontroller (6502-like core). I was brought in after an expensive consulting firm billed them for a few months work, then told them that it was impossible to do it on that part, partly because the timers weren't good enough, and partly because there weren't enough CPU cycles to do both the measurements and the computations at the desired sample rate. I got it all to work, but I had to go through bizarre contortions with the timers and the interrupt logic. If the timers had been just a little bit different, it would have been easy, and we could have gotten at least 50% higher sample rate. I've also designed things where due to inadequate timers, I had to write sections of code that were cycle-counted through all paths in order to squeeze out a bit more performance than the hardware timers provided. So no, I definitely wouldn't say that "nobody has had a problem using them". Maybe "nobody doing trivial things has had a problem with them." > I couldn't care less > whether my chip has a MAC....I don't -do- massive high-speed computing > with my logic. Sometimes I do, sometimes I don't. > ps; jim is right, I had specifically mentioned a 64-128 cell part; > not a 3,000 register fpga. Obviously I'm not proposing putting a MAC on your 64-128 cell part. > In which case, using cells for timers eats > up a $10 chip REAL fast....while the silicon cost for a few 16b hard > counters on a chip like that would be near-zero... It's not near-zero. The counters themselves may not use up much die area, but they have to interface to the routing matrix just like macrocells do, and the routing area is where much of your die area goes. Add 16 more signals to the routing matrix, and it gets a LOT bigger. That translates into real dollars. I'd rather spend 1.1x dollars on 16 macrocells that do whatever I want,than 1.0x dollars on 16 bits of hardwired stuff (which is more than just 16 flops, since it may have input and output holding registers, etc.) that almost certainly doesn't do what I want, because I'll end up having to buy more macrocells for my own counters anyhow. "If only it had 17 bits" "If only it had a gate input" "If only the prescaler could be set to divide by 17" "If only the prescaler would reset when the counter is reset" or "If only the prescaler *wouldn't" reset when the counter is reset" "If only the PWM mode had complementary outputs to drive my H bridge" "If only the PWM mode had an adjustable dead band" etc. No matter what features you pick, they'll be wrong most of the time. And if you put ALL the features in, then it will use up a lot of silicon, and it will STILL be wrong a lot of the time. When I use counter-timers in microcontrollers, they rarely do what I want, so I often end up adding external logic anyhow. And when they do what I want, or close enough to it that I can do the rest in firmware, it's because the requirements I'm making of the counter-timer are really simple. Not the kind of stuff I'm going to put in an FPGA anyhow. If my requirements can be met by a microcontroller, I'll use that rather than an FPGA. By contrast, a MAC does a very well-defined function, and it's possible to design one that will be useful to >99% of people that need a MAC. (Of course, it's still no use to the people that don't need a MAC.) EricArticle: 98846
Hello, I have a problem with the Spartan 3E DCMs: I use two DCMs with the following configuration: - input clk = 50 MHz - output clk: clk0 (phase 0) = 50MHz - output clk: clk90 (phase 90) = 50 MHz - Clk FX: 50*7/2 = 175MHz I also use fine phase shifting. For the fine phase shifting I use a state machine. After a phase shift command the state machine waits for the done signal coming from the DCM. I've noticed that sometimes the DCM doesn't give a DONE signal, as a consequence the state machine is blocked. The PSClk is 50MHz, it is the same clock as clk0. Has anybody had a similar problem? thanks for the info and best regards, DolphinArticle: 98847
i am korean student studying for fpga
I try use modelsim but occur error on starting! help me plz~
my system is windows XP (korean version)
here is error message ---------------
------------------------------------------------
can't read "view_master": no such variable
while executing
"linsert $args 0 $view_master"
("Viewmaster" arm line 2)
invoked from within
"switch $cmd {
Create {
return [eval [linsert $args
0 $view_master Create]]
}
Viewmaster {
return [eval[linsert $args 0
$view_master]]..."
(object "::.vcop method "::vsimwidgets::Vcop::Action" body line 2)
invoked from within
"$vsimPriv(Vcop) Action Viewmaster varRef _LineNumbers"
invoked from within
"add_menucb "" view.source "show line numbers" \
-variable [$vsimPriv(Vcop) Action Viewmaster varRef
_LineNumbers] \
-command "$vsimPriv(Vcop) A...
invoked from within
"ncFyP12 "
(file "C;/Modeltech_6.0/win32/../tcl/vsim/transcript.op_" line 1)
invoked from within
"source [file join $MTI_LIB_DIR vsim transcript.op_]"
invoked from within
"if {[batch_mode]} {
source [file join $MTI_LIB_DIR vsim batch.op_]
} else {
set tcl_interactive 1
source [file join $MTI_LIB_DIR vsim tra..."
invoked from within
"
...
------------------------------------------------
------------------------------------------------
Article: 98848Peter Alfke wrote: > But I have shown, by a hypothetical example, that we can double the > yield, and thus cut the EasyPath basic manufacturing cost in half. We > can thus sell these parts for half price, while maintaining our usual > margins. And you DID NOT show that. Cutting die/test costs in half does NOT also cut packaging, post packaging test, intelectual property(amotized R&D), labor and other direct/indirect costs in half as well. Amdhals law of diminishing returns applies here when evaluating the cost savings of the die to the finished product, as the die/test cost is not the only cost, and very likely not the majority of the cost. SO, the math is simple ... cutting die/test in half, DOES NOT allow sale of the parts for half price with the usual margins as you clearly assert above. Thus, it remains speculation just where the quoted 25-80% savings comes from. Taking your example above to the logical limit, if a customer is able to directly contract with (pay) the fab to provide their wafers free to Xilinx, and waves all xilinx testing costs, then the final packaged parts would be completely free. IE there are no packaging, intelectual property, other direct and indirect costs. That would be the ONLY way the math would work as you suggest above.Article: 98849
Peter Alfke wrote: > Peter Alfke, not ashamed to put his name under his writings. Ok, if handles and other names represent a sense of shame, are you suggesting that the founders of Xilinx were ashamed to use their own names, as Hewlett and Packard, Ford, and many other great business do? Should we start riddiculing your employer for this too? I think not ... the only shame is that Xilinx is allowing you to dirty their name. John Bass
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