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
I designed an SPDIF to I2S audio disembedder about 2 years ago for a client. It's pretty straightforward, like a couple of days max. should see it done ok once you're up to speed on what you need. The one I did was for an Altera Stratix but the only family specific bit was a fifo. AlanArticle: 87401
I have a UCF file for ML401. If you'd like please contact me directly (remove all capital letters in my email address) and I will send it to you. JimArticle: 87402
"Tullio Grassi" <tgrassi@mail.cern.ch> schrieb im Newsbeitrag news:Pine.LNX.4.58.0507222100100.9491@lxplus064.cern.ch... > Slightly off-topic post: > > I am looking for parallel optic (12-way) transmitter > and receiver at ~2.7Gbps, to use with xilinx Rocket IO. Why do you want to use parallel optics? Why not using one single transmitter. Fibre Channel II reaches 2.something Gbit/s, if this is a lab setup it might be possible to overclock them. Some also offer 2.5 Gbit/s. And finally there are 4 Gbit/S Fibre Channel Tranceiers. Or use two Gigabit tranceivers (1.25 Gbit/s) in parallel with slightly overclocking. These tranceivers are cheap and easily availible (~$50). Regards FalkArticle: 87403
What is blif format? You are probably talking about synthesis tool, aren't you? Vladislav "junaid" <k.najeeb@gmail.com> wrote in message news:1122026304.657790.4750@g14g2000cwa.googlegroups.com... > Hi All, > > Can anyone suggest a method to convert verilog file into blif (LUT) > format. Does altera or xilinx support this file conversion ?. Kindly > help me in this regard > > Thanking you in advance >Article: 87404
Hello all, Does anyone around here has ever transfer data from PC to Memec card using Virtex II FPGA? If yes, could you please tell me how dis you do that? Thank you! JacquesArticle: 87405
Hi Sean, Thanks for a well thought-out posting with a lot of good questions and comments. > How often can you > share 4 inputs with two seperate functions? Or share 6 inputs with two > seperate functions? My guess is that the 5 + 3 or 5 + 4 is where it > helps more. We found functions could share inputs often enough to justify the small amount of extra hardware required to allow these modes. But yes, it is primarily the ability to implement a 4 + 4, a 3 + 5, a 6, etc. that helps the most on density, since this allows us to efficiently pack most of the LUTs that come out of synthesis + tech mapping without wasting much of the ALM. The other modes are not as commonly used but are used often enough to justify their existance. > I think the biggest advantage is reduced levels of logic > isn't it? One important point will be what is the Fmax difference > between these designs. Aren't more packed designs slower? Yes, the main advantage of the 6-LUT is speed. In a classic 6-LUT architecture, the added speed of reduced logic levels would come at a large increase in silicon cost (due to unused logic in 6-LUTs used to implement 5-, 4- and 3-input functions). The ALM is designed to get the speed benefit of reduced logic levels, without that area penalty. Packing *can* slow things down, depending on how smart the tool is. If you take two unrelated 4-LUTs that want to be on opposite sides of the chip and pack them into one ALM (or one Slice), then you have probably hurt performance. On the other hand, taking LUTs that have some common fan-in and packing them together probably doesn't hurt performance much, since they likely come from parts of the design that wanted to be together anyway. Also, by packing more tightly, the average distance a routing connection must travel may be reduced, improving performance. For example, the shared LUT mask mode of the ALM that implements 2 6-LUTs sharing 4 inputs into one ALM likely doesn't hurt performance at all -- if anything, it probably helps since it doubles the density of those circuits, such as bused multiplexors, that use it. > Anyway, the truth is something that will not be talked about on here. > [snip - discussion on area of ALM vs. alternatives] This is a good observation and is the heart of the logic architect's design problem. In designing Stratix II, we experimented with numerous Logic Element designs; each was evaluated on the "silicon area per logic function" metric. We are claiming that you need 1.3 Slices to implement the same functionality as an ALM (on average). Provided the ALM is no more than 1.3X bigger than a Slice, then the "silicon area per logic function" is better off for the ALM. > Since the LX200 has 200K and the S2 has 180K, my guess is that > the SliceM + SliceL is a bit smaller than 2 x ALM. Remember, LX200 has 89,088 Slices, and 2S180 has 71,760 ALMs. So *assuming* that the two dice have the same area, and *assuming* that all that area is ALMs/Slices (which it is not), then you get an area ratio of ALM:Slice = 1.24:1, which is lower than the logic density ratio of 1.3:1, indicating that the ALM has better density by a ratio of 1.30/1.24. Of course, there are enough assumptions here to completely invalidate this result; we both spend considerable area on other functions, and we have overhead for redundancy technology, but get more yield, etc... and routing is a considerable part of the logic + routing area... In the end Altera chose to move to the ALM. This involved re-writting much of our LE-optimized IP, new Quartus synthesis, new 3rd party synthesis, considerable changes to our CAD flow, and a lot of other work to do so. The only way we would have committed the resources needed and taken this big risk is if we believed the ALM was a big win in silicon cost and speed. Regards, Paul Leventis Altera Corp.Article: 87406
On Fri, 22 Jul 2005, Falk Brunner wrote: > > Slightly off-topic post: > > > > I am looking for parallel optic (12-way) transmitter > > and receiver at ~2.7Gbps, to use with xilinx Rocket IO. > > Why do you want to use parallel optics? Why not using one single > transmitter. Fibre Channel II reaches 2.something Gbit/s, if this is a lab > setup it might be possible to overclock them. Some also offer 2.5 Gbit/s. > And finally there are 4 Gbit/S Fibre Channel Tranceiers. Or use two Gigabit > tranceivers (1.25 Gbit/s) in parallel with slightly overclocking. These > tranceivers are cheap and easily availible (~$50). > > Regards > Falk > the parallel optics modules that I mentioned handle 12 x 2.7Gb/s = 32.4 Gb/s. For example Agilent HFBR-779B. I need some 6 of these modules per board. Using individual transceivers become a pain in the neck (that is actually what we have done so far with a smaller scale project). Going above 3.125 Gb/s on a single link is complicate because require the RocketIO X that are less available, and I prefere to avoid extreme S.I. problems... TullioArticle: 87407
jacques77@gmail.com wrote: > Hello all, > > Does anyone around here has ever transfer data from PC to Memec card > using Virtex II FPGA? If yes, could you please tell me how dis you do > that? > > Thank you! > Jacques > What is a Memec card?Article: 87408
at Thu, 21 Jul 2005 19:57:02 GMT in <dboukf$id8$04$1@news.t-online.com>, r.fridolin@gmx.de (Ralph Friedrich) wrote : >Hello I compiled the stapl player for our testsystem. >One function is to calculate the checksum of the JAM file. >Regards Ralph > Did you also do a STAPL composer? And do you have source for that? I have a STAPL player, that's not a problem - what I need is a STAPL composer. -- Alex Rast ad.rast.7@nwnotlink.NOSPAM.com (remove d., .7, not, and .NOSPAM to reply)Article: 87409
Fred Marshall skrev: > <jjlindula@hotmail.com> wrote in message > news:1121970065.257771.127820@g43g2000cwa.googlegroups.com... > > Hello, I'm interested in how individuals or design groups manage > > complexity in their design projects. What things do you do or things > > the group does that can take complex tasks and break them into simpler > > or more manageable tasks? It may sound like a weird question, but there > > must be some guidelines, best practices, or habits used to achieve > > success in designing/developing a complex project. I'm sure there must > > be some individuals out there that are constantly taking complex tasks > > and just about every time have success with it. Short of speaking, I > > want to know what's the secret to their success. All comments are > > welcomed, even the most obvious suggestions. > > > > As an engineer, I'm constantly trying to improve my design processes. > > > > Joe, > > Here is another perspective: > > People are the source of complexity. I'd say some problems are complex before adding the people factor. > Better" is the enemy of "good enough". Hmm... I've seen this in the form "'perfect' is the enemy of 'good enough'", which I agree with. I am not sure I agree with "'better'...". > One reason the requirements need to be understood is to avoid changes. > > You should have a process to prevent changes. Design freezes are a way to > do this. This avoids bringing in the latest and greatest idea and perhaps > even doing that again and again and again..... Then you should probably > have a higher-level process to embrace great ideas for change. I made the mistake some time ago to browse through a book on project management (don't remember the title, though). As far as I remember, there were four basic modes of project planning: A) Goals fixed, resources fixed. B) Goals fixed, resources relaxed[*] C) Goals relaxed[*], resources fixed D) Goals relaxed[*], resources relaxed[*] [*] "relaxed" means that the goals or resources either are unknown at project planning time, or they change significantly troughout project lifetime. While no one knows everything that will happen in the future, I do agree with you that changes in goals should be avoided, as far as possible, during project lifetime. I was not happy to discover the emphasis on cases C) and D) above, in the book I browsed. Perhaps I am too naive? > It doesn't happen often that it isn't, but try to make sure that the thing > is feasible in our lifetime - otherwise it isn't engineering it's an > experiment. Agreed. > Sometimes you won't know the requirements until you've tried some things. Would this type of project qualify as cases C)-D) above? RuneArticle: 87410
Rune Allnor wrote: > > Fred Marshall skrev: > >><jjlindula@hotmail.com> wrote in message >>news:1121970065.257771.127820@g43g2000cwa.googlegroups.com... >> >>>Hello, I'm interested in how individuals or design groups manage >>>complexity in their design projects. What things do you do or things >>>the group does that can take complex tasks and break them into simpler >>>or more manageable tasks? It may sound like a weird question, but there >>>must be some guidelines, best practices, or habits used to achieve >>>success in designing/developing a complex project. I'm sure there must >>>be some individuals out there that are constantly taking complex tasks >>>and just about every time have success with it. Short of speaking, I >>>want to know what's the secret to their success. All comments are >>>welcomed, even the most obvious suggestions. >>> >>>As an engineer, I'm constantly trying to improve my design processes. >>> >> >>Joe, >> >>Here is another perspective: >> >>People are the source of complexity. > > > I'd say some problems are complex before adding the people factor. > > >>Better" is the enemy of "good enough". > > > Hmm... I've seen this in the form "'perfect' is the enemy of 'good > enough'", which I agree with. I am not sure I agree with "'better'...". > > > >>One reason the requirements need to be understood is to avoid changes. >> >>You should have a process to prevent changes. Design freezes are a way to >>do this. This avoids bringing in the latest and greatest idea and perhaps >>even doing that again and again and again..... Then you should probably >>have a higher-level process to embrace great ideas for change. > > > I made the mistake some time ago to browse through a book on project > management (don't remember the title, though). As far as I remember, > there were four basic modes of project planning: > > A) Goals fixed, resources fixed. > B) Goals fixed, resources relaxed[*] > C) Goals relaxed[*], resources fixed > D) Goals relaxed[*], resources relaxed[*] > > [*] "relaxed" means that the goals or resources either are unknown > at project planning time, or they change significantly troughout > project lifetime. > > While no one knows everything that will happen in the future, I do > agree with you that changes in goals should be avoided, as far as > possible, during project lifetime. I was not happy to discover the > emphasis on cases C) and D) above, in the book I browsed. Perhaps > I am too naive? > > >>It doesn't happen often that it isn't, but try to make sure that the thing >>is feasible in our lifetime - otherwise it isn't engineering it's an >>experiment. > > > Agreed. > > >>Sometimes you won't know the requirements until you've tried some things. > > > Would this type of project qualify as cases C)-D) above? In some fields, it's typical. If you can specify the outcome and the path to it, it isn't research. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87411
Jerry Avins skrev: > Rune Allnor wrote: > > > > Fred Marshall skrev: > >>Sometimes you won't know the requirements until you've tried some things. > > > > > > Would this type of project qualify as cases C)-D) above? > > In some fields, it's typical. If you can specify the outcome and the > path to it, it isn't research. Ah, sorry. I didn't mention that these cases applied to projects in general, not necessarily R&D projects. R&D comes into case C) and D) almost by default. RuneArticle: 87412
In comp.arch.fpga,comp.software-eng and comp.dsp, On 21 Jul 2005 11:21:05 -0700, "jjlindula@hotmail.com" <jjlindula@hotmail.com> wrote: >Hello, I'm interested in how individuals or design groups manage >complexity in their design projects. What things do you do or things >the group does that can take complex tasks and break them into simpler >or more manageable tasks? It may sound like a weird question, but there >must be some guidelines, best practices, or habits used to achieve >success in designing/developing a complex project. I'm sure there must >be some individuals out there that are constantly taking complex tasks >and just about every time have success with it. Short of speaking, I >want to know what's the secret to their success. All comments are >welcomed, even the most obvious suggestions. > >As an engineer, I'm constantly trying to improve my design processes. The big company I worked for at the time sent me to a week-long "Software Engineering Training Program" while in the middle of a longish project. I recall it being a mostly "positive learning experience" but the only thing I now (10 years later) remember from it was "Do a post-mortem on the project." When you get done with a project (whether it's shipping or it was trashed), you (meaning the whole team) look it over (perhaps not so much the design itself but rather how you did it), see what you did right and what went wrong, what you could have done better, etc. The point of this is that you might have better insight at the start of the next project, rather than at the end of it. Of course, at the end of the project I was working on, we did NOT do a post-mortem. >Thanks everyone, >joe ----- http://www.mindspring.com/~benbradleyArticle: 87413
Ben Bradley wrote: > > The big company I worked for at the time sent me to a week-long > "Software Engineering Training Program" while in the middle of a > longish project. I recall it being a mostly "positive learning > experience" but the only thing I now (10 years later) remember from it > was "Do a post-mortem on the project." When you get done with a > project (whether it's shipping or it was trashed), you (meaning the > whole team) look it over (perhaps not so much the design itself but > rather how you did it), see what you did right and what went wrong, > what you could have done better, etc. The point of this is that you > might have better insight at the start of the next project, rather > than at the end of it. > Of course, at the end of the project I was working on, we did NOT > do a post-mortem. Very common. I was involved in one of those hellish development projects that resembles a slow moving train wreck. The project was supposed to take 9 months but ended up taking over 2.5 years. Near the end, I offered to write a paper on what went wrong and how to avoid similar problems in future projects. I made it clear that I was not looking to blame anyone but I wanted the company and the development team to learn from the mistakes made. My offer was ignored and I left the company 4 months later to go to a job with about 5% less pay. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "Linux is produced to be used, whereas the others are produced to be sold" -- Bobby D. BryantArticle: 87414
<jjlindula@hotmail.com> wrote in message news:1121970065.257771.127820@g43g2000cwa.googlegroups.com... > Hello, I'm interested in how individuals or design groups manage > complexity in their design projects. What things do you do or things > the group does that can take complex tasks and break them into simpler > or more manageable tasks? Easy: 1) Make sure the chief architect or engineer is responsible for getting the project delivered on time. 2) Make sure he doesn't have enough time to do too much of the work himself. 3) Make sure there are enough other resources available to make it worth his while to take advantage of them. Then, the chief architect or engineer will have to divide much of the project into manageable components that can be assigned to others. -- MattArticle: 87415
Erik de Castro Lopo wrote: > I was involved in one of those hellish development projects that > resembles a slow moving train wreck. Only one? Your career must have been truly blessed. :-) SteveArticle: 87416
Steve Underwood wrote: > > Erik de Castro Lopo wrote: > > I was involved in one of those hellish development projects that > > resembles a slow moving train wreck. > > Only one? Your career must have been truly blessed. :-) Well after that disaster I spent three and a half years doing technical support in the most senior level of support at SUN Microsystem. I'm now back doing development work and find that things haven't changed much :-). Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "I don't think any MS Exec will ever die of old age. Satan doesn't need the competition." -- Digital Wokan on LinuxToday.comArticle: 87417
Rune Allnor wrote:
> While no one knows everything that will happen in the future, I do
> agree with you that changes in goals should be avoided, as far as
> possible, during project lifetime.
But there is a significant class of projects - at least in failure
visibility - where you beforehand can be practically certain that the
goals will change during the project lifetime: Projects which shold
manage public sector policies (i.e. payment of unemployment benefits,
health insurance, taxes, ...)
Greetings,
Jacob
PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
and "comp.dsp"?
--
ğWhat fun is it being "cool" if you can't wear a sombrero?Ğ
Article: 87418Moro Back from a successful trip in .ch I have to change my contact details at Altera and they provide an email address for doing this: csecom@altera.com which just leads into nirvana and bounces back with "user unknown"... Any other address to use? Or why is it not allowed to change address online? rickArticle: 87419
Jacob Sparre Andersen skrev: > Rune Allnor wrote: > > > While no one knows everything that will happen in the future, I do > > agree with you that changes in goals should be avoided, as far as > > possible, during project lifetime. > > But there is a significant class of projects - at least in failure > visibility - where you beforehand can be practically certain that the > goals will change during the project lifetime: Projects which shold > manage public sector policies (i.e. payment of unemployment benefits, > health insurance, taxes, ...) Do such activities satisfy the definition of of a project? As far as I remember, a project is defined as something like "An activity with a priori specified goals and resources, that takes place once, and that is of limited duration." The activites you describe seem to be programs, to me. Somehow, I have the impression that the words "project" and "activity" are on their way to become synonyms. I prefer to stick to the definition of a project, with a priori known goals and resources, and handle the changes as "deviations from plans". Labeling the changes like that, may put some pressure on planners to get their estimates right the next time, or make them choose to organize the activity as something other than a project. > PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga" > and "comp.dsp"? I don't know about comp.arch.fpga, but the last few weeks the threads on comp.dsp have not been all that on-topic, not least thanks to me. Every now and then, threads of more "philosophical" nature occur. I think project organization and company policy are very important parts of engineering projects these days. Every now and then, such questions, rather than technology, are the roots of the problems. I don't necessarily see this thread as off topic, what comp.dsp is concerned. But then, I'm a major contributor to the noise on comp.dsp. > =BBWhat fun is it being "cool" if you can't wear a sombrero?=AB Indeed. RuneArticle: 87420
Erik de Castro Lopo wrote: (snip) > I was involved in one of those hellish development projects that > resembles a slow moving train wreck. > The project was supposed to take 9 months but ended up taking over > 2.5 years. Near the end, I offered to write a paper on what went > wrong and how to avoid similar problems in future projects. I made > it clear that I was not looking to blame anyone but I wanted the > company and the development team to learn from the mistakes made. Read "Mythical man-month", which pretty much has the same description, though on a different scale. It is written by the head of the OS/360 project. The examples relate to software projects, but it should be more generally applicable. -- glenArticle: 87421
I'm looking at the fastest way to compute floating point (32bit) log and exp on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon which can do that in 18.5 clock cycles on average on a 1000 float vector (using SSE3) So far I've found that with a few tables and floating point MUL and ADD blocks I should be able to do that at 160MHz on a Stratix II (not tested yet). It's still slower than the Xeon but at least it's close. I've looked at cordic at a glance, but it looks slower or bigger if totally unrolled. Any ideas or pointers on a better way to do that? Thanks MarcArticle: 87422
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message news:1122079067.583190.317210@o13g2000cwo.googlegroups.com... > > > Jerry Avins skrev: >> Rune Allnor wrote: >> > >> > Fred Marshall skrev: >> >>Sometimes you won't know the requirements until you've tried some >> >>things. >> > >> > >> > Would this type of project qualify as cases C)-D) above? >> >> In some fields, it's typical. If you can specify the outcome and the >> path to it, it isn't research. > > Ah, sorry. I didn't mention that these cases applied to projects in > general, not necessarily R&D projects. R&D comes into case C) and D) > almost by default. > > Rune > Yeah, I thought we were talking about projects that result in a product of some sort. Now, research results would be a "product" to a researcher but I was thinking in terms of "harder" deliverables: a system, a box, an application program, etc. So, research papers weren't in my frame of reference as a "product". Engineeers do research but is research "engineering"? A narrower definition for engineering is to "build" something (as in design, build, test). A definition from the web: 1.. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. I thought that was the context and perhaps beyond into "project management". So, when we are engineering something, sometimes we have to do a little research along the way and that was the crux of "sometimes you don't know the requirements until you've tried something". But, at that, I think this is about finding out how certain things interact or behave that require some experimentation but I don't think of that as "research" as such. I can think of lots of examples in real life. Here's an example: An underwater vehicle that looks like a torpedo would be launched and would deploy a towed array rather immediately after launch. The vehicle was controlled by a circular shroud at the tail around the propellors that would move up/down port/starboard. The tow cable was wrapped around the shroud and held in place with some hardware claptrap. The idea was that the claptrap would be released, the flow of water would pull it aft and away. The cable would deploy and the control surface would be free to move. When it failed to work that way, not only did the cable not deploy but the vehicle had no dynamic control. Off to the water tunnel.... It became apparent that the flow of water over the tail cone had velocity not only aft but *toward* the skin of the vehicle. It pressed the claptrap *toward* the tail cone - which was in direct opposition to the force needed for it to deploy. ... that was an experiment to support development but it wasn't research. The result changed the specifications for the claptrap and its release mechanisms. ...shake, rattle and roll testing often ends up with new requirements on the design unless the designers are very experienced. That's probably a good example. Once I managed a project that had the purpose of "developing technology" - which meant that we were trying new ideas for known end applications within a system context. Now that was somewhat researchy and was certainly development. Having best practices regarding how to do research yields a different set of suggestions doesn't it? Here's an example: We were trying to reduce the drag of underwater vehicles using all sorts of very high tech methods. One of the groups (no doubt with a vested interest) reported experimental success of their technique. But, some the of the tests had failed. When asked why they threw out those results, they said: "something must have been wrong and invalidated those tests". But, they had no idea what might have been wrong or if the tests were truly invalid. In the end we decided that the technology lacked robustness and the results were valid: they were indicative of a technology that was "on the edge" of working or not working. So, for research we add to best practices: design of experiments, how to handle results, repeatability, etc. FredArticle: 87423
Fred Marshall skrev: > "Rune Allnor" <allnor@tele.ntnu.no> wrote in message > news:1122079067.583190.317210@o13g2000cwo.googlegroups.com... > > > > > > Jerry Avins skrev: > >> Rune Allnor wrote: > >> > > >> > Fred Marshall skrev: > >> >>Sometimes you won't know the requirements until you've tried some > >> >>things. > >> > > >> > > >> > Would this type of project qualify as cases C)-D) above? > >> > >> In some fields, it's typical. If you can specify the outcome and the > >> path to it, it isn't research. > > > > Ah, sorry. I didn't mention that these cases applied to projects in > > general, not necessarily R&D projects. R&D comes into case C) and D) > > almost by default. > > > > Rune > > > > Yeah, I thought we were talking about projects that result in a product of > some sort. Now, research results would be a "product" to a researcher but I > was thinking in terms of "harder" deliverables: a system, a box, an > application program, etc. So, research papers weren't in my frame of > reference as a "product". Engineeers do research but is research > "engineering"? A narrower definition for engineering is to "build" > something (as in design, build, test). A definition from the web: > 1.. The application of scientific and mathematical principles to practical > ends such as the design, manufacture, and operation of efficient and > economical structures, machines, processes, and systems. > I thought that was the context and perhaps beyond into "project management". > > So, when we are engineering something, sometimes we have to do a little > research along the way and that was the crux of "sometimes you don't know > the requirements until you've tried something". But, at that, I think this > is about finding out how certain things interact or behave that require some > experimentation but I don't think of that as "research" as such. How would you prepare for such a project, if you were to take on something you knew/suspected would need to break new ground? Divide it into lots of small projects, where one could decide whether to proceed or not, after each sub-project? Allocate large fractions (25% - 50%) of the budget to "unexpected expenses"? > I can > think of lots of examples in real life. > > Here's an example: > An underwater vehicle that looks like a torpedo would be launched and would > deploy a towed array rather immediately after launch. The vehicle was > controlled by a circular shroud at the tail around the propellors that would > move up/down port/starboard. The tow cable was wrapped around the shroud > and held in place with some hardware claptrap. > The idea was that the claptrap would be released, the flow of water would > pull it aft and away. The cable would deploy and the control surface would > be free to move. > When it failed to work that way, not only did the cable not deploy but the > vehicle had no dynamic control. > Off to the water tunnel.... > It became apparent that the flow of water over the tail cone had velocity > not only aft but *toward* the skin of the vehicle. It pressed the claptrap > *toward* the tail cone - which was in direct opposition to the force needed > for it to deploy. > > ... that was an experiment to support development but it wasn't research. > The result changed the specifications for the claptrap and its release > mechanisms. I'd say this example involves "unexpected expenses". The goal, to make this device work, has not changed. Getting it to work, takes a little bit longer and involves more cost than previously anticipated. > ...shake, rattle and roll testing often ends up with new requirements on the > design unless the designers are very experienced. That's probably a good > example. I can see how the design requirements are refined or adjusted, as experience is gained. But do the goals change? Perhaps we are splitting hairs here, but I don't see that they do. > Once I managed a project that had the purpose of "developing technology" - > which meant that we were trying new ideas for known end applications within > a system context. Now that was somewhat researchy and was certainly > development. Having best practices regarding how to do research yields a > different set of suggestions doesn't it? The goals for that kind of project are not easy to measure/quantify. "You are two weeks late on the breakthrough idea!" Can't really see that happening... ;) > Here's an example: > We were trying to reduce the drag of underwater vehicles using all sorts of > very high tech methods. One of the groups (no doubt with a vested interest) > reported experimental success of their technique. But, some the of the > tests had failed. When asked why they threw out those results, they said: > "something must have been wrong and invalidated those tests". But, they had > no idea what might have been wrong or if the tests were truly invalid. In > the end we decided that the technology lacked robustness and the results > were valid: they were indicative of a technology that was "on the edge" of > working or not working. These are questions of craftmanship, regardless of whether we define this as an engineering or R&D project. If you do a set of tests, there are certain standards one would like to keep in order to "sell" the results. Explaining large amounts of "anomalies" should include a discussions of reasons, including the possible non-robust method. A few years ago, I met a former colleague who had got a new job in a company dealing with marine operations, since I last met him. He described a project he was involved in, where they had as ambition to deploy certain types of kit at the sea floor, at given locations in the deep sea and with very high accuracy. As he finished describing the goals, my reaction, expressed as a combination of body language and verbal comments was to the effect of "You guys must be mad to attempt something like this!" "Oh yes, that's how it might look." he responded. "We don't expect to actually meet the ambitions, though, but we would like to see how close we can get, and what it takes to get there." Most reassuring. We went on to discuss various ways of getting close to these goals. My friend said that somebody from some service company had approached him to discuss methods to deploy the kit. The people from the service company had said they could do this with standard technology. "Do you believe they can?" I asked quietly. "No. The representatives didn't even blink an eye when I described our ambitions." Our unspoken mutual understanding was that anyone who understood the complexity (well, semi-sanity) of the stated goals, would be very sceptical to whether this was at all possible. The service company showed, as I understood my friend's tale, no signs of understanding what this was all about, and did thus not get the contract. > So, for research we add to best practices: design of experiments, how to > handle results, repeatability, etc. Exactly. To me, these aspects are embedded in the term "craftmanship". RuneArticle: 87424
Marc Battyani wrote:
>I'm looking at the fastest way to compute floating point (32bit) log and exp
>on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon
>which can do that in 18.5 clock cycles on average on a 1000 float vector
>(using SSE3)
>
>So far I've found that with a few tables and floating point MUL and ADD
>blocks I should be able to do that at 160MHz on a Stratix II (not tested
>yet). It's still slower than the Xeon but at least it's close. I've looked
>at cordic at a glance, but it looks slower or bigger if totally unrolled.
>
>Any ideas or pointers on a better way to do that?
>
>Thanks
>
>Marc
>
>
>
>
You didn't mention how much precision you need, nor for that matter what
the log base is to be. Log
is actually easier to compute for a floating point argument, since the
significand is already presumably
normalized, which reduces the complexity of computing the log since the
range is limited. for fixed point,
the usual approach is to normalize it first, essentially converting to
floating point. Log base 2 is a little
bit easier than other bases because the floating point exponent is the
integer portion of the log. The fraction
portion can be computed with a small (4 input) look-up to get you to 1/2
dB or so. If you need more
precision, there are iterative techniques that can get you to whatever
precision you need. Exponent is the
reverse: you use a look-up to exponentiate the fractional portion and
then use the integer portion to control
how much the exponentiated fraction is shifted. This can be pipelined,
and run at over 200 MS/sec in a single
thread in Spartan3 FPGAs, faster in premium devices.
Do you need the log in floating point too, or is it fixed point log
notation? Most importantly, what is the precision requirement?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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