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
"colin" <colin_toogood@yahoo.com> schrieb im Newsbeitrag news:1138108267.480703.95060@g14g2000cwa.googlegroups.com... > Guys > > Does anyone know whether ISE simulator lite will simulate the RocketIOs > on the virtex 4 that webpack supports? > > I have a simulator that doesn't support smartmodels so I could live > with the poor performance of simulator lite just to check the rocket IO > bit of my design. > > regards > > Colin > WAU what a question. No idea, but guessing NO. And and advice about rocketIO do not trust simulations, so better to test out in real silicon anyway. -- Antti Lukats http://www.xilant.comArticle: 95576
yyqonline wrote: > Im designing a module working as an fm0-encoder, the clk and max > datarate of which are both 640KHz. It is not complicated when the > datarate is lower than 320K, the half of clk. But when the datarate of > 640K, the clk frequency, is concerned, the problem comes that I have to > change the state at both the rising and falling edge of the clk. Now I > am using a mothod via combinational output, which is not so good and > expansible as registered output using an FSM. I think that an FSM using > DET(dual-edge flip-flop) would work, but I am not sure wether it is > recommandable to use det and I don't know how to describe a det using > synthesizable Verilog? > It would be appreciated very much if some of you can > *comments about the det method, > *the methed about how to describe a det flip-flop > > thans a lot for any help! Do you really mean KHz and not MHz? If this is not a typo I would suggest using a much faster clock to run an FSM that samples the 640KHz clock and uses edge detection (XOR on two stages of flip-flop) to enable data transfer. If you're really talking MHz, modern FPGA's have ways to deal with this at the I/O buffer (double-data-rate flip-flops). Generally multi-edge flip-flops are not synthesizable, but if the part has them, they can be instantiated. i.e. you can't just write: always @ (posedge clk or negedge clk) ... and expect the synthesis tool to generate useful RTL.Article: 95577
Check out the spec sheets on the Cyclone or Cyclone2. You will likely need to use the PLL(s), but I believe in the smalles cyclone has more LVDS channels than you require.Article: 95578
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:TvbBf.20580$F_3.3236@newssvr29.news.prodigy.net... > Hello Paul, > >> >> The PE 's giving you refeence/verification do NOT have to be EEs. I just >> was approved to take the exam this April and 2 of my references were >> licensed mechanical PEs, not EE. Don't let this deter you....you can >> find PEs of any field and use for reference. >> > > Interesting. Then I would already know two (civil engineers). Was that in > California? > > 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 (?) Perhaps you could take the exam in a neighboring state instead? AZ/NV? Good luck! BoArticle: 95579
"Joerg" <notthisjoergsch@removethispacbell.net> wrote in message news:vmcBf.20595$F_3.5792@newssvr29.news.prodigy.net... > Hello Ray, > > >> When I applied for mine, they wanted 5 references, 3 of which needed to >> be familiar with my work, and 3 of which had to be registered engineers. >> As it happened, all 3 were familiar with my work through past >> engagements, only one was licensed as an EE, the other two were MEs, both >> working for medical equpment companies I had done work for. In addition, >> none of the references could be past employees or supervisors (the >> supervisors were interviewed too). ... > > > Oops, that may put another crimp in there since I was their boss all the > time. The CEO was my boss and has a degree but no license either. The > other assigment where I wasn't boss was outside the country. > > >> You could always call the licensing board and discuss your predicament >> with them. They are well aware that there are few PEs in manufacturing, >> and again, I found them to be very helpful navigating the application >> process, including helping you find your references. ... > > > Yes, maybe talking to them is the best course of action. They might be > more willing now than before (I did call them about PE several years ago) > because they are hurting budgetwise AFAIK and may be hungry for the $275 > fee. They had already jacked up the fees substantially to make up. Not > enough applicants anymore it seems. > > >> BTW, yes, you generally do need 4 years between the FE exam and your PE. > > > Beats me why they do that. Doesn't make much sense. > It seems a fine-line to walk between not getting enough applicants and getting too many (thus lowering the perceived value or 'exclusivity' of the PE club). In large part, I think the whole thing is just a huge money making scam-- the states make good money (and keep a significant perpetual income from annual fees), the Universities make money from review courses and of course the publishers make a killing on the prep materials. It's looking like my venture is going to run about $1200 for fees, books, travel, etc. Multiply that by say 1000 examinees per year and it's $1.2million. Not bad, heh? Nevertheless, if you want to play the game, you have to play by their rules-- as ridiculous as they might be (for example, no longer giving examinees their scores--even if they fail!) Hoping to pass the 1st time around, PaulArticle: 95580
Simon Peacock wrote: > So who is unqualified? I have no degree or formal university training. I > went to a polytech and studied electrical. Now I design radios and > interface them to a digital world. Based on my experience in industry, I would say between 10-15% of people titled "engineer" do not have a degree (and practically none of them have a "license"). This has no correlation at all with quality of output, of course. I'm actually now back at school to get the ol' parchment, because my workplace is only 15 minutes drive from an ABET-accredited college, and my employer has 100% tuition+books reimbursement with no annual limits. It's a great morale-builder, because the stress level is negligible compared with work. In fact I would almost qualify school as a leisure activity; I feel more relaxed at work during the school term because school gives me some problems that I KNOW to have answers. If you have access to programs of this sort, I heartily recommend them... not that I place any intrinsic value on the paper, but it's handy to have and fun to acquire. Plus it expands your networking opportunities in several ways, useful if you're a consultant^H^H^H^H^H^H^H^H^H^Hpolitically correct term for person doing this work without licenses/degrees/other bureaucratic irrelevancies.Article: 95581
I think the only device that supports this are the Xilinx CoolRunner II. This Should work: always @(posedge Clk or negedge Clk) begin if(Rst == 1) Cnt <=0; else Cnt <= Cnt +1; end yyqonline wrote: > Im designing a module working as an fm0-encoder, the clk and max > datarate of which are both 640KHz. It is not complicated when the > datarate is lower than 320K, the half of clk. But when the datarate of > 640K, the clk frequency, is concerned, the problem comes that I have to > change the state at both the rising and falling edge of the clk. Now I > am using a mothod via combinational output, which is not so good and > expansible as registered output using an FSM. I think that an FSM using > DET(dual-edge flip-flop) would work, but I am not sure wether it is > recommandable to use det and I don't know how to describe a det using > synthesizable Verilog? > It would be appreciated very much if some of you can > *comments about the det method, > *the methed about how to describe a det flip-flop > > thans a lot for any help! >Article: 95582
fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>OK, OK. We have heard you. >>As I said, Peter and I will do our best to influence "truth in counting." > > > Does that mean we will see either total power or derating curves for > LUT/FF toggles to define power and thermal limits as both a percentage > of active logic or size of the active design? > > While you may not see this as important from a perspective of past > uses for traditional hardware design, as reconfigurable computing takes > off there is a completely different mindset hitting your market. > Software > tools WILL be packing active algorithms into devices to get the best > computational effciency per device. Good packing WILL yield close to > 100% active logic in a device, and yeild exactly what you are mocking: > > >>Sure, go ahead and toggle every single flip flop and IO simultaneously >>at max frequency, and I will assure you that you will not like the result. > > > Devices that are by design not expected to be more than 10% active will > greatly disappoint their customers. You will increasingly see large > applications reduced to netlists which have a very high toggle > percentage. The user will see that his application compiles to X number > of LUTs, and will be buying devices with just over that number of LUTs > to run the application. If the user does not encounter a clear warning > to derate the device, then we have a truth in advertising problem. > > Something akin to purchasing a family car advertised to cruise on the > freeway at 75mph with an economy of 35mpg. Customers will not find the > car acceptable, if it can only be operated at those speeds for 10 > minutes, and require a 50 minute inactive period on the side of the > road to cool down because some engineer decided to save a few > horsepower by removing the water pump and the rest of the cooling > system. Cars are assumed to have short term duty cycles in hours, not > minutes. > > While hardware design engineers may have grown used to the omissions in > the data sheet about duty cycles for FPGAs, the new reconfigurable > computing market is going to be much less tollerant of devices that can > only be operated with a 10% duty cycle, or at 10% of rated capacity. > > If the data sheet says 1M LUTs capable of 800Mhz, then that is what is > expected by end users looking at the data sheets to purchase FPGA's for > computing. If the device is really only capable of 10% of 1M LUTs at > 800Mhz, then from a reconfigurable computer perspective it's really > just that, a 100K LUT device, not a 1Mhz LUT device. > > Likewise, if there is only one routing solution that will achieve 100% > utilization of the device, and a typical reconfigurable computing > netlist will be route limited at 65% utilizaton, then a 1M LUT device > is NOT a 1M usable LUT device, but rather only a 650K LUT device for > typical reconfigurable computing uses. > > So, this is not the 1980's any more, or even the 1990's ... a new > emerging primary market for FPGAs is reconfigurable computing and we > need devices which are clearly specified for worst case loads that will > be typical ... not the exception ... in that market. > I think you are a little off track here. As a practical matter, without a significant amount of handcrafting, you are not going to pack a device close to 100% AND achieve corner of the envelope operating speeds. It just isn't going to happen with a typical synthesized RTL design. Further, unless the design is all bit-serial, you are going to have average toggle rates across the die less than 15%. Even with 100% bit serial designs, you'll very rarely see average toggle rates exceed even 50%. Yes, you can drive a part hard, and in some cases you'll need a heatsink on it, but the synthesized RTL designs being turned out are not typically going to get you into that corner.Article: 95583
fpga_toys@yahoo.com wrote: > fpga_toys@yahoo.com wrote: > > >>absoulutly true ... but not the whole thread, or even vary many of the >>authors in the thread ... the brash branding of the entire thread, even > > > For those that missed it, there is a long wonderful thread in the > middle of the junk regarding EE's and PE's by people like Ray that are > always generally respected in this forum. The brash branding of the > entire thread is knee jerk - ignore the trolls, follow the content. > Yeah, I should have changed the subject in my first reply.Article: 95584
fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>OK, OK. We have heard you. >>As I said, Peter and I will do our best to influence "truth in counting." > > > Does that mean we will see either total power or derating curves for > LUT/FF toggles to define power and thermal limits as both a percentage > of active logic or size of the active design? <snip> Just so that I understand you (as someone watching from the peanut gallery) are you suggesting that there is not enough information to determine whether a heavily-loaded device will work? The maximum allowable junction temperature is in the data sheet, the heat transfer values are package-specicif so they're included in the package documentation. Since each I/O can handle such large currents, I'm assuming (I do nt know for certain) that the Vccint and Gnd pins can handle any current you push into the device. It *is* an engineering exercise to determine the power draw of any non-simple FPGA and provide an appropriate power and cooling environment or do you believe otherwise? So... If someone can attach a heat-pipe cooling apparatus with 0.295 deg C/watt (recently seen for high ambient temperature CPU cooling) and a power supply capable of pushing in unlimited current, will the large devices just not work? I love the idea of getting the information "clean" in the data sheet but I don't understand what information could be provided to an unsupervised newbie engineer biting off more of a design than he should be allowed to develop because he obviously doesn't have the experience to understand engineering tradeoff in programmable devices without clouding the datasheet with significant amounts of information of little interest to 98% of engineers who actually do their work with the information already at hand. The arguement in this thread was that misleading numbers suck for engineers. Do you honestly believe that it's misleading not to hand-hold the engineer by applying 20 more pages of drivel that should be in app notes or analysis tools? I'd really hate to see the attitude of communicating information to the data sheet's target audience effectively be hampered by the attitude that any engineer should be able to know everything about how to design FPGAs from the data sheet alone. So, if you're not just venting because you blew up a board in the past because you didn't do a proper engineering job, WHAT information in a properly cooled, powered, analyzed FPGA design should NOT be in a decent application note but in every device data sheet? "Derating" doesn't float with me unless you have specific ideas on how this information should be effectively delivered in the technical document intended to communicate the details of the specific FPGA device family. - John_HArticle: 95585
news@rtrussell.co.uk wrote: > In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote: > : But I'm probably biased - I apparently have mostly German Blood, which > : is probably why the "Americanized" version of my family name is so hard > : to pronounce. > > I've always wondered, does the American surname Straub originate > from a mis-reading of Strauss with an Eszett (German double-s) ? Sounds very plausible. GrahamArticle: 95586
<news@rtrussell.co.uk> wrote in message news:dr597s$bif$1@nntp0.reith.bbc.co.uk... > In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote: > : But I'm probably biased - I apparently have mostly German Blood, which > : is probably why the "Americanized" version of my family name is so hard > : to pronounce. > > I've always wondered, does the American surname Straub originate > from a mis-reading of Strauss with an Eszett (German double-s) ? Because it looks like a B to eyes not accusomed to reading German.Article: 95587
On Tue, 24 Jan 2006 07:54:47 -0800, "Richard Henry" <rphenry@home.com>
wrote:
>
><news@rtrussell.co.uk> wrote in message
>news:dr597s$bif$1@nntp0.reith.bbc.co.uk...
>> In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote:
>> : But I'm probably biased - I apparently have mostly German Blood, which
>> : is probably why the "Americanized" version of my family name is so hard
>> : to pronounce.
>>
>> I've always wondered, does the American surname Straub originate
>> from a mis-reading of Strauss with an Eszett (German double-s) ?
>
>Because it looks like a B to eyes not accusomed to reading German.
>
Yep. Strauss <=> Strauß
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
It's what you learn, after you know it all, that counts.
Article: 95588Hello, My knowledge on fpga field is almost zero. Ive got few questions. I would like to enter into fpga world. Ive thought about buying starter kit to start to play. Ive found few spartans boards and arm's. Whats the diffrence between them (development utils, hardware) ? Ive seen that arm has gnuarm and arm-linux, does it mean that I can program arm processor using C / C++ ? If yes that seems to be quite fast method rather then writing the same in HDL ? HDL describes hardware circuits, C / C++ is software programming language - does it mean that arm is rather "hardware procesor" and spartans are rather fpga's ? Is it possible to write in C/C++ into spartan and vice versa in HDL with arm ? Are there others processors which counts on this field ? Ive would like to start feel whats going on fpga field .. soo if anyone would point me in some directions would be great. Thanks -- un.Article: 95589
For all those who care to respond to this thread, PLEASE REMOVE comp.arch.fpga from the cross-postings. <news@rtrussell.co.uk> wrote in message news:dr597s$bif$1@nntp0.reith.bbc.co.uk... > In comp.arch.fpga Rich Grise, but drunk <yahright@example.net> wrote: > : But I'm probably biased - I apparently have mostly German Blood, which > : is probably why the "Americanized" version of my family name is so hard > : to pronounce. > > I've always wondered, does the American surname Straub originate > from a mis-reading of Strauss with an Eszett (German double-s) ? > > Richard > http://www.rtrussell.co.uk/ > To reply by email change 'news' to my forename.Article: 95590
Hi Antti, The bitpatch.exe worked for the Xilinx XCV1000. It calculated the CRC and replaced the default CRC. I tested it this past weekend by starting with a known good bit file and updating the BRAMs used as cache with 6 different programs. XCV1000 don't support DISABLE_CRC, so the output of data2mem did not program the FPGA. I have a wrapper script/batch file that uses data2mem + .bmm file and does the correct replacment. I then use your bitpatch to replace the default CRC. This saved several hours of recompilation and all resulting downloads to the FPGA worked. Thanks for the help. You have streamed this process and saved several days of me hacking something based on Xilinx specs. THANKS! John On Mon, 23 Jan 2006, Antti Lukats wrote: > "John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag > news:Pine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU... > > Is your library for the CRC generation available to others. > > > > JOhn > > http://help.xilant.com/Xilinx:Configuration:CRC > > the code snippet that does calc the CRC is at the above link, > bitpatch utility with the ability to inject fixed CRC is scheduled for > release as well > > -- > Antti Lukats > http://www.xilant.com >Article: 95591
toys, Our FPGAs do not thermally "run away." Yes, you can melt solder, with enough power. But, we also provide the tools (web/spreadsheet/xpower) to predict that the power might be excessive. That is engineering. There is no way to 'derate' a design, until we know the entire design (or at least enough of it to run the web/spreadsheet power tools) Sorry, there is just no other way to deal with the 200,000+ seats of software, and the 20,000+ designs happening at any given moment. It is not an ASIC nor an ASSP that does one thing, one way. It is a programmable device that can do just about anything from applications just below 1 watt, to applications just above 25 or 30 watts. Why don't you try using the power prediction tool, and get a feel for what you can, and can not do? How would you put that in a data sheet? The recommended use of the tools is already in the users guides. AustinArticle: 95592
Ray Andraka wrote: > I think you are a little off track here. As a practical matter, without > a significant amount of handcrafting, you are not going to pack a device > close to 100% AND achieve corner of the envelope operating speeds. It > just isn't going to happen with a typical synthesized RTL design. I haven't tried hard yet, and easily got "close" with several large pipelined demos. I am concerned about what someone really concerned about performance may fairly easily do. And in particular what does that translate into regarding design envelopes for those that make PCI add in FPGA accelerator boards, and what should the customer clearly be aware of and have disclosed for selection guidelines in Reconfigurable Computing (RC) platforms. Issues like monitoring the on die temp diode is barely optional. The programmers for these platforms are not expected to be EE's with 10 years of designing FPGA systems under their belts. Having good, easy to read and understand limits for dynamic power, that the board can handle by design, is critical. Both for platform selection, and operation. The Virtex 4 users manual is very clear about derating I/Os for concurrent switching limits. We need similar data for the fpga core resources in equally well documented clarity so that these "programmers" have clear bounds. > Further, unless the design is all bit-serial, you are going to have > average toggle rates across the die less than 15%. Even with 100% bit > serial designs, you'll very rarely see average toggle rates exceed even 50%. :) 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. > Yes, you can drive a part hard, and in some cases you'll need a heatsink > on it, but the synthesized RTL designs being turned out are not > typically going to get you into that corner. 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.Article: 95593
Ray Andraka wrote:> > Yeah, I should have changed the subject in my first reply. I will do everything I can to keep this newsgroup focused on FPGAs. It is already a wide span from naive newbie questions and homework assignments to spicy comments about data sheet content. But that is what we can and should handle in this newsgroup. I issued my warning when I saw that mountain of crud descending on us: off-topic, xenophobic, rambling like a drunken sailor, and often downright stupid. The fact that our beloved and respected Ray Andraka inserted some pearls of wisdom does not change the general view. The thread started with a provocative question, and then degraded into rambling chaos. I have watched other newsgroups fall into a similar trap, and I suggest we band together to avoid this here. The subject is FPGAs, and we should not get dragged into semi-intelligent (often un-informed and even stupid) discussions about completely different subjects. There are thousands of other newsgroups that do ventilate all sorts of ideas. We have avoided spam, we should also be able to avoid an invasion like the one I objected to. Peter AlfkeArticle: 95594
fpga_toys@yahoo.com writes:
>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.
But you can measure the core supply current. Should be easy enough to do some
correlation between current und temperature, at least for a user warning.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 95595On Tue, 24 Jan 2006 01:55:29 +0000, Michael A. Terrell wrote: > Proverbs 23:9 > Speak not in the ears of a fool: > for he will despise the wisdom > of thy words. Hm. Sounds like a good idea. Cheers! RichArticle: 95596
"Peter Alfke" <peter@xilinx.com> wrote in message news:1138123958.101066.307150@g43g2000cwa.googlegroups.com... <snip> > I issued my warning when I saw that mountain of crud descending on us: > off-topic, xenophobic, rambling like a drunken sailor, and often > downright stupid. The fact that our beloved and respected Ray Andraka > inserted some pearls of wisdom does not change the general view. The > thread started with a provocative question, and then degraded into > rambling chaos. > I have watched other newsgroups fall into a similar trap, and I suggest > we band together to avoid this here. The subject is FPGAs, and we > should not get dragged into semi-intelligent (often un-informed and > even stupid) discussions about completely different subjects. There are > thousands of other newsgroups that do ventilate all sorts of ideas. > We have avoided spam, we should also be able to avoid an invasion like > the one I objected to. > Peter Alfke I started watching sci.electronics.design since analog and RF stuff tends to show up there, not here. It was sad to see just how many "OT:" posts there are and how miserable they get. Politics, bigotry, and general downright ugliness. The only reason we got the inappropriate thread - as far as I can tell - is because the original poster cross-posted to three groups. The scum-factor in sci.electronics.design spilled over full-force into our otherwise helpful usenet forum. I don't even bother looking for the pearls of wisdom in anything with "OT:" in the header unless the rest of the subject catches my attention. There are better places for those rants but some people feel "obliged" to "sling poo" through the internet where it shouldn't be slung. - John_HArticle: 95597
<fpga_toys@yahoo.com> wrote in message news:1138123483.242619.84800@g49g2000cwa.googlegroups.com... <snip> > I haven't tried hard yet, and easily got "close" with several large > pipelined demos. I am concerned about what someone really concerned > about performance may fairly easily do. And in particular what does > that translate into regarding design envelopes for those that make PCI > add in FPGA > accelerator boards, and what should the customer clearly be aware of > and have disclosed for selection guidelines in Reconfigurable Computing > (RC) platforms. <snip> 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. The board manufacturer should have specific published design limits for the board. 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. 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: 95598
In article <1138066953.145439.135570@f14g2000cwb.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Brian Drummond wrote: >> IMO there should be no conflict between the continued existence of a >> technology in open-source form using XDL, and the same or derived >> technology streamlined into the push-button flow using NCD. >> Xilinx use open-source tools for PPC development already. > >As long as the project didn't inadvertently compile and disclose the >routing >database as the JHDLbits project did, things are probably ok. As Phil >notes though, and others have suggested, one set of tools that would >be interesting would be ones capable of fixing bad nets, and that would >require a database of chip capabilities and architecture that is >currently >only visible from the floor planner and device editors. Extracting that >data and archiving it in a format useable for third party tools is >pretty >much what got the JHDLbits project shut down. > I'm not aware of the history of JHDLbits; can you give a few details? I'm assuming it was an open source project (as JHDL is) so they must've gotten a cease & desist letter at some point. Is there any way of avoiding the same fate? PhilArticle: 95599
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. Regards, Joerg http://www.analogconsultants.com
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