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
Peter, I agree. This is a "shell and pea game" being conducted. "Keep you eye on the LUTs -- they will grow right before your eyes!" Amazingly, this keeps the eye off: the domain specific solutions (ie SX is the least cost for DSP centric designs, LX is the best for logic, FX for embedded systems), signal integrity, power, speed, EMAC, PPC, MGT, FIFO BRAM, DCM, as well as the other hundred innovations in Virtex 4. For all of these, there is no defense. Nothing to say. So, let us just fool everyone into arguing about something else? I applaud their marketing department's ability to put a ring through the customer's nose, and lead them around at will. Xilinx has always marveled at their ability to do this. However, we do believe our customers are smarter than that. By focusing the conversation, and all the brain cells on what they want to have you focused on, they have succeeded in making a large number of engineers do exactly what they wanted. Keeps them from looking at the other hundred innovations that make the Virtex 4 an undisputed winner. For me, I will continue to point out the other 100 reasons to choose V4. I'll let the LUT shaped heads battle this one out, but be aware that you are being used. AustinArticle: 87426
"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net... > One reason the requirements need to be understood is to avoid changes. > > You should have a process to prevent changes. ACK! Preventing changes, the good old "requirements freeze" is a sure way to kill a project. Requirements are going to change. To pretend otherwise is just putting your head in the sand. The name of the game is to manage the requirements. For some reason, many software professionals seem to believe that "requirements management" is the same as requirements elicitation, but there is a bunch more than that. You need to understand the impact of requirements changes, and deal with them. Yes, some changes should be resisted. Requirements changes that will significantly affect the development effort must be identified, and then the effort re-sized. That may mean renegotiation. The renegotiation may cause the customer to re-think how urgent the change is, or not. Most requirements changes, though, are not of that nature. Most are probably just refinements of our understanding of the requirements. Usually, we try to pretend that these are not changes by simply not documenting them. That way we'll have to re-learn them. Other times we discover that we misunderstood the requirement in the first place. Well, recognize that as soon as possible when it has the minimum impact, and recognize the impact. Requirements management isn't easy, but it's not a black art either. It's mostly about keeping your eyes wide open. ..Article: 87427
Fred Marshall wrote: ... > 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'm sorry, Fred, but that doesn't fly most of the time. Not only with electronic design, but with "simpler and more straightforward" (hah!) projects like bridges and buildings. As the chairman of the construction committee during the building of a regional sewerage installation that included a main plant, two satellite plants, three pumping stations, and over 40 miles of trunk line, I can tell you than no piece of the project was finished without change orders. The Mercury space capsules' audio amplifiers were changed twice after the design was thought to be final. First, to replace power transistors to increase allowable dissipation, then to correct the near disaster caused by the change. When you go to the market and discover that some ingredients are unavailable, you substitute other ingredients or change the recipe. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87428
Jerry Avins skrev: > Fred Marshall wrote: > > ... > > > 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'm sorry, Fred, but that doesn't fly most of the time. Not only with > electronic design, but with "simpler and more straightforward" (hah!) > projects like bridges and buildings. As the chairman of the construction > committee during the building of a regional sewerage installation that > included a main plant, two satellite plants, three pumping stations, and > over 40 miles of trunk line, I can tell you than no piece of the project > was finished without change orders. The Mercury space capsules' audio > amplifiers were changed twice after the design was thought to be final. > First, to replace power transistors to increase allowable dissipation, > then to correct the near disaster caused by the change. When you go to > the market and discover that some ingredients are unavailable, you > substitute other ingredients or change the recipe. Eh, Jerry... do you and Fred talk about the same things? I interpret Fred's post such that he talks about freezing the *design*. Freezing the design still leaves the freedom to change the *implementation*, which, for some reason, I believe you are discussing. To put it in a DSP context, the major design decision is to decide whether to use a FIR filter or an IIR filter, since this is likely to have some implications for what DSP chips can be used. Having chosen the IIR filter, the implementation could be based on a Butterworth or Chebyshev analog prototype or some optimized discrete-time design. It could be a direct-form I or II, depending on whatever suits the application. Yes, I know, the example is perhaps a bit far-fetched but I hope you see my point. Freezing the decision to use IIR filters still allows implementation details like filter orders and filter coefficients to be changed, for yet some time. RuneArticle: 87429
Rune Allnor wrote: > > Jerry Avins skrev: > >>Fred Marshall wrote: >> >> ... >> >> >>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with >>electronic design, but with "simpler and more straightforward" (hah!) >>projects like bridges and buildings. As the chairman of the construction >>committee during the building of a regional sewerage installation that >>included a main plant, two satellite plants, three pumping stations, and >>over 40 miles of trunk line, I can tell you than no piece of the project >>was finished without change orders. The Mercury space capsules' audio >>amplifiers were changed twice after the design was thought to be final. >>First, to replace power transistors to increase allowable dissipation, >>then to correct the near disaster caused by the change. When you go to >>the market and discover that some ingredients are unavailable, you >>substitute other ingredients or change the recipe. > > > Eh, Jerry... do you and Fred talk about the same things? I interpret > Fred's post such that he talks about freezing the *design*. Freezing > the design still leaves the freedom to change the *implementation*, > which, for some reason, I believe you are discussing. > > To put it in a DSP context, the major design decision is to decide > whether to use a FIR filter or an IIR filter, since this is likely to > have some implications for what DSP chips can be used. Having chosen > the IIR filter, the implementation could be based on a Butterworth or > Chebyshev analog prototype or some optimized discrete-time design. > It could be a direct-form I or II, depending on whatever suits the > application. Yes, I know, the example is perhaps a bit far-fetched > but I hope you see my point. Freezing the decision to use IIR > filters still allows implementation details like filter orders and > filter coefficients to be changed, for yet some time. That's well put. How would you classify adding the two satellite plants to the sewerage system? Originally, the system was designed with one plant, and pipelines to it from all participating communities. One administration blocked the two lines from the upstream communities, forcing the Sewerage Authority to build the satellite plants. The pipeline plans were scrapped, and we considered reducing the size of the main plant. Is that a change of implementation, or of plans? Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87430
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message news:1122167921.820607.126720@g47g2000cwa.googlegroups.com... > Eh, Jerry... do you and Fred talk about the same things? I interpret > Fred's post such that he talks about freezing the *design*. Freezing > the design still leaves the freedom to change the *implementation*, > which, for some reason, I believe you are discussing. What we call "implementation" in the software business is just the easy or less significant part of the design process. There is no sharp distinction. Design is everything between inception and mass production. > [ for example ] Freezing the decision to use IIR > filters still allows implementation details like filter orders and > filter coefficients to be changed, for yet some time. Yes, and with this example you can see how the world outside of engineering would have no knowledge of or respect for the distinction you make between "design decisions" and "implementation details". That's because the distinction is artificial -- it is the process of design that determines what will be easy to change later and what will not. A good designer should avoid tying excessive investments of time or money to decisions which are likely to be undone later. -- MattArticle: 87431
On Sat, 23 Jul 2005 19:39:13 +0200, "Marc Battyani" <Marc.Battyani@fractalconcept.com> 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 Some time back, a company called LogPoint was offering an alternative to floating point arithmetic, based on logarithms, and depended on a fairly efficient float to log conversion. (I had discussions with them, at least 8 years ago) I seem to remember that the LOG wizard was a guy by the name of Lester Pickett. http://www.mjourney.com/news/News_from_Greece/632.Log_Point.shtml unfortunately, this seems to be dead: www.logpoint.com (as in, a place holder) Have a look at patent 5197024 at www.uspto.gov for all the details. Philip Philip Freidin FliptronicsArticle: 87432
On Fri, 22 Jul 2005 16:39:38 +0200, "Stefan" <holzi_stefan@hotmail.com> wrote: >Hi all, > >I'm using a Spartan 3 test board with a xc3s200 fpga. Before, I used a >larger device (Virtex II ) and had no problems with my design (microblaze >with my own IP, connected to the OPB-bus). But now, I get errors during the >map process due to the small amount of slices... --> it seems that the >device is too small. But: when I don't connect my IP with the OPB, >everything's fine. At the moment when I click in Xilinx Platform Studio on >the white square to connect to OPB that a 'S' appears , the problem with the >overmapped slices occurs. Without connection about 50% of slices are used, >connected to the OPB more than 230%. >How could that be possible?? The software may be trimming logic from your design when you don't have the IP connected. For an unrelated example, if you had a design that was 1000 slices, and the end result is a single signal, connected to an IOB, and all the rest of the IOBs are inputs. Assuming no other issues, this design places and routes and uses 1000 slices. If you then make a change that just does not connect the output to the IOB, the whole design would be trimmed, and zero slices used. What happens is that the SW deletes logic that cannot change the external behavior of the chip. So what happens is the logic that generates the final signal is trimmed. Then the logic that was feeding it is now not driving anything, and it is trimmed, and this continues all the way back to the inputs. In your design, if the IP is not connected to the OPB, then all its outputs can be trimmed, and then work back to the start of the IP. If there are no other outputs of the IP, the whole thing could be trimmed. Same thing is true of the OPB. Also trimming can start at the input end of a design. If an input does not connect to an IOB, or it is a constant, then logic trimming can start at the input end, and work forward towards the output. The trimming report is the place to start examining this issue. >I'm using the latest versions of ISE and XPS. > >Thanks in advance, > >Stefan > Philip Philip Freidin FliptronicsArticle: 87433
Memec makes Xilinx (and other) dev kits. Jacuqes, I have done it for a Virtex 4. What is it that you are trying to do?Article: 87434
Austin gave an interesting analogy: I can visualize Altera Marketing trying to put a ring in designers' noses, and (mis)leading them so that they can see nothing else but LUTs, oblivious to all the more exciting aspects of FPGAs. We could then call them LUTites, in memory of the Luddites in 1812 Nottingham, who also did not appreciate the technological progress coming at them, destined to really change their lives. Many suspected Luddites were convicted, imprisoned, or hanged. Those were the days... But don't get us wrong: We love LUTs. Xilinx invented the concept of LUT-based FPGAs. LUTs are great and flexible, whether they have 4, 5, or 6 inputs. But LUTs are not everything anymore, and the really exciting progress in FPGA performance and density happens outside the LUTs. Don't let anybody put a ring in your nose... Peter Alfke, Xilinx Applications (from home)Article: 87435
"A good designer should avoid tying excessive investments of time or money to decisions which are likely to be undone later. " In other words designers have to be fortune tellers.Article: 87436
"Rune Allnor" <allnor@tele.ntnu.no> wrote in message news:1122157921.866725.149310@g44g2000cwa.googlegroups.com... > > > 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 guess you might budget a lot for unexpected expenses. But, I didn't think we were talking here so much about project management as about best practices in development. Frankly I'd not be too comfortable with such an allocation *if* cost and schedule were paramount - which they often are. Maybe you could break things down into smaller pieces and maybe not. The notion is a good one to be sure - but agreeing or disagreeing in such general terms is too speculative for me. Maybe that's the essence of "complex" - that something hasn't been well partitioned and organized, eh? I can imagine control systems engineering as dealing with things that are complex and making them simpler by virtue of the tools. Once you know about the tools then most things in this context are perceived as simpler aren't they? That doesn't make them easier to deal with "seat of the pants" - but knowing that the tools are there and what they do, etc. makes things appear to be simpler. Computers are great for keeping track of a lot of things at once - much better than humans. We designed a control system for a semisubmersible oil and gas production platform in Sweden. The thing had over 50 ballast tanks that we would control with a computer program (model, etc.). When it went to sea the crew tried to trim the tanks by hand and were never able to level the platform. Eventually they decided to try out the new-fangled computer thingy and the platform leveled out directly. The task was too *complex* for humans unless they used the computer controls and then the task was made simple for them. They were incapable of dealing with all the subsystems and their interactions. Too many subsystems and too many interactions. So, breaking it into smaller parts wasn't the solution. > >> 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. The point was whether it was development or "research" - not that it cost a bit more to accomplish. > >> ...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. I agree that the goals don't change. The point was that some try/fix process was likely. > >> 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... ;) In this case the schedule was fixed for a wide array of technologies. Either things panned out in time or they didn't. If someone was trying to make too great a breakthrough then they would probably fail. That was OK because the next step was to take the best, proven technologies and build something real. Nobody in their right mind would start a product development with an unproven technology while there were proven technologies available. The goals were easy to measure and quantify. Either the technology appeared to work well or it didn't or it never really got off the ground. The next phase of system development would decide which technologies really made sense. (In the end, some technologies were carried a bit too far into development - for reasons that seemed good at the time but were really more emotional than real. "High risk, high payoff" turned out to be really "high risk, very modest payoff". In the end, money determined the best approach - which was the right outcome). > >> 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". I agree. It was just that the original question was about best practices for development and not for research. So, the responses were about development. Then Jerry brought up "research" and we started a bit down that path. I simply tried to say that changing the question would change at least some of the answers. It's a bit harder for me to envision a product engineering team deciding that failed tests were actually "OK" - although I know that it happens. (e.g. see Richard Feynman's treatment of the space shuttle disaster. Thus, I say "harder" not impossible). Maybe there needs to be another item on the list: "Make sure there is good craftsmanship in every discipline" FredArticle: 87437
these optic modules (12x and 4+4) are available from agilent and zarlink. Infineon has stopped production of paoli. I do not know emcore or picolight. -FranklinArticle: 87438
"xpyttl" <xpyttl_NOSPAM@earthling.net> wrote in message news:IWAEe.15990$bG4.3120@fe06.lga... > "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message > news:NpKdnVShBI2o9H3fRVn-uA@centurytel.net... > >> One reason the requirements need to be understood is to avoid changes. >> >> You should have a process to prevent changes. > > ACK! > > Preventing changes, the good old "requirements freeze" is a sure way to > kill a project. > I'm sure we could argue about this forever. I think it's mostly a matter of context. One can just as easily say: "allowing changes is a sure way to kill a project". Then, all you have to do is sort out what the heck either of us is talking about... Because both perspectives are fine. I once worked on a project where the box was going to be painted blue. And then it was going to be painted silver. And then it was going to be painted green. So, we kept going to meetings and never finishing. That's a good example for when a requirement should have been frozen. At least it would have saved a lot of precious time! It really didn't matter all that much but a lot of stuff was left hanging pending the decision on the color of the box! Sure requirements change with new awareness, changed conditions, etc. Here's an example of how "new awareness" messed up a project: We were building a processor-based system. It was new technology. The operating system had been selected and we were on a path to getting the system implemented. Then, the principal in software went to a symposium and met a real OS guru. Actually our software principal was a guru in his own right. Anyway, he came home convinced that our OS could have a much smaller footprint in memory. He trashed everything that had been done and started over because it appeared that "better" was indeed better and "good enough" wasn't good enough. ....... and the project did not complete on time to matter. It fell off the edge of the table. Ever hear: "if it ain't broke don't fix it" ? That's a design freeze and it makes sense. FredArticle: 87439
"Jerry Avins" <jya@ieee.org> wrote in message news:Nf-dnavJit7de3_fRVn-ow@rcn.net... > Fred Marshall wrote: > > ... > >> 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'm sorry, Fred, but that doesn't fly most of the time. Not only with > electronic design, but with "simpler and more straightforward" (hah!) > projects like bridges and buildings. As the chairman of the construction > committee during the building of a regional sewerage installation that > included a main plant, two satellite plants, three pumping stations, and > over 40 miles of trunk line, I can tell you than no piece of the project > was finished without change orders. The Mercury space capsules' audio > amplifiers were changed twice after the design was thought to be final. > First, to replace power transistors to increase allowable dissipation, > then to correct the near disaster caused by the change. When you go to the > market and discover that some ingredients are unavailable, you substitute > other ingredients or change the recipe. Jerry, You were the chairman of the construction committee. You were in control of the "higher level process to embrace great ideas for change". So, you changed things when necessary. I don't see any problem with that or any contradiction with what I said. In the context of what I said first: "better is the enemy of good enough". That's when you need to freeze. For example: We have a filter requirement. We design a FIR filter that works fine. It has been implemented and tested. Then somebody figures out that a few memory locations can be saved and we can still meet the requirement with an IIR filter. So, with no design controls in place, the designer decides to re-design the filter. Hey, it's fun and the experience gained is great. Except now the impulse response is longer and that affects parts of the system that had already been tested and the difference shows up rather late in the development cycle and the filter designer has gone and the FIR filter is forgotten and people are wondering how to get back to what worked and ...... you get the idea. I didn't say: "don't allow any changes". I said that freezing is good *and* overruling the freeze process can also be good. I'm sure that many of us have had experiences where things were controlled by idiots. That makes any good idea look bad. It doesn't invalidate the good ideas. I think we're back to Rune's suggestion that there has to be good craftsmanship. That applies in management too. Here is a very positive story about design freeze: I took over a group that was building a rather complex board - of a design that had never been done before. Their plan was to build the board and then "spin" it - i.e. do a second pass at the layout because they figured there would be changes, errors, things that didn't work, etc. The second pass added precious months to the schedule. So, I told them that we had to get first-pass success and that's what we had to plan on. They had to get it right the first time. The idea isn't exactly the same as design freeze but pretty close. The design was "going to be frozen" in their minds so they had to get it right the first time. They did it. Interesting, eh? FredArticle: 87440
"jjlindula@hotmail.com" <jjlindula@hotmail.com> writes: > 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. > > Thanks everyone, > joe Joe, What a great question! As the responses have shown, you've really hit a nerve with many engineers. Some may have said some of this already, but allow me respond in my own words. 1. Define the requirements. In performing this task, try not to think too much about the details of how the requirements will be implemented. On the other hand, knowledge of implementation and/or current capabilities will almost certainly shape the requirements. For example, it would be silly to require (at this time in history) the capabilities of a Pentium 4 processor at a power consumption of a microwatt. 3. Face the fact that if requirements are added (or changed in certain ways), the schedule for the design WILL slip. 4. Design from the top down. That is, begin the design decomposition at the top level and then iteratively break the higher level blocks into lower level blocks. AKA hierarchical design. Something (at least for me) very interesting happens at this stage of the design. I find that there are two tricks when defining blocks at a specific level that are almost contradictions. On one hand, it seems that a good design decomposition comes by doing some "back-and-forth" between one level and the next lower level, or maybe even two levels. On the other hand, it is necessary to discipline your mind to view the design at the current level and avoid the tendency to "drop down" to the lower levels, at least for a time. It seems that by alternately viewing the design at the current level, and then also skitting back and forth between levels and looking for optimal configurations, you come out with the best design decompositions. Another set of ABSOLUTELY CRUCIAL guidelines at this stage, especially when performing software design, is to partition the modules or blocks such that you MAXIMIZE COHESION and REDUCE COUPLING. You can find a lot of material on these two concepts, e.g., http://www.ugolandini.net/AccoppiamentoCoesioneE.html 5. Implement from the bottom up. 6. Be patient. Waiting for a system to be properly designed will almost always be more efficient (time-wise) than "waterfall development," i.e., the type of development for impatient managers that want to see something almost immediately. My $0.02. -- % Randy Yates % "My Shangri-la has gone away, fading like %% Fuquay-Varina, NC % the Beatles on 'Hey Jude'" %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Shangri-La', *A New World Record*, ELO http://home.earthlink.net/~yatescrArticle: 87441
Peter Alfke <alfke@sbcglobal.net> wrote: > Austin gave an interesting analogy: > Don't let anybody put a ring in your nose... > Peter Alfke, Xilinx Applications (from home) Could you Xilinx people please grow up, this is not insightful, this is not even zealous company loyalty, this is just boyclub bickering. A reasoned discussion about advantages and disadvantages of FPGA architectures is interesting, but do you really think that this kind of posting is informative for /anyone/?Article: 87442
Jerry Avins skrev: > Rune Allnor wrote: > > > > Jerry Avins skrev: > > > >>Fred Marshall wrote: > >> > >> ... > >> > >> > >>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with > >>electronic design, but with "simpler and more straightforward" (hah!) > >>projects like bridges and buildings. As the chairman of the construction > >>committee during the building of a regional sewerage installation that > >>included a main plant, two satellite plants, three pumping stations, and > >>over 40 miles of trunk line, I can tell you than no piece of the project > >>was finished without change orders. The Mercury space capsules' audio > >>amplifiers were changed twice after the design was thought to be final. > >>First, to replace power transistors to increase allowable dissipation, > >>then to correct the near disaster caused by the change. When you go to > >>the market and discover that some ingredients are unavailable, you > >>substitute other ingredients or change the recipe. > > > > > > Eh, Jerry... do you and Fred talk about the same things? I interpret > > Fred's post such that he talks about freezing the *design*. Freezing > > the design still leaves the freedom to change the *implementation*, > > which, for some reason, I believe you are discussing. > > > > To put it in a DSP context, the major design decision is to decide > > whether to use a FIR filter or an IIR filter, since this is likely to > > have some implications for what DSP chips can be used. Having chosen > > the IIR filter, the implementation could be based on a Butterworth or > > Chebyshev analog prototype or some optimized discrete-time design. > > It could be a direct-form I or II, depending on whatever suits the > > application. Yes, I know, the example is perhaps a bit far-fetched > > but I hope you see my point. Freezing the decision to use IIR > > filters still allows implementation details like filter orders and > > filter coefficients to be changed, for yet some time. > > That's well put. How would you classify adding the two satellite plants > to the sewerage system? Originally, the system was designed with one > plant, and pipelines to it from all participating communities. One > administration blocked the two lines from the upstream communities, > forcing the Sewerage Authority to build the satellite plants. The > pipeline plans were scrapped, and we considered reducing the size of the > main plant. Is that a change of implementation, or of plans? That's certainly a change of plans, what I am concerned. RuneArticle: 87443
Matt Timmermans skrev: > "Rune Allnor" <allnor@tele.ntnu.no> wrote in message > news:1122167921.820607.126720@g47g2000cwa.googlegroups.com... > > Eh, Jerry... do you and Fred talk about the same things? I interpret > > Fred's post such that he talks about freezing the *design*. Freezing > > the design still leaves the freedom to change the *implementation*, > > which, for some reason, I believe you are discussing. > > What we call "implementation" in the software business is just the easy or > less significant part of the design process. There is no sharp distinction. I know. > Design is everything between inception and mass production. To me, "design" si the intellectual effort of concocting (choosing) a way of meeting the goals. "Implementation" is about putting the design into practice. > > [ for example ] Freezing the decision to use IIR > > filters still allows implementation details like filter orders and > > filter coefficients to be changed, for yet some time. > > Yes, and with this example you can see how the world outside of engineering > would have no knowledge of or respect for the distinction you make between > "design decisions" and "implementation details". Which is why I made the point that project managment must be recruited amongst the engineers. > That's because the > distinction is artificial -- Sorry, I don't agree. Again, "design" is about choosing what algorithms to use, how to organize the program, getting a block diagram representation etc. It's the intellectual effort invested in making a program or system. "Implementation" is about getting a software function or piece of machinery to perform a pre-determined action. Which could involve an excercise in design on its own. I don't know if you have experience with matlab. It's a computer system for numerical computing, that allows just about anything in software computing: Scripts, Structured programming, Object oriented programming, GUIs, typed programming, non-typed programming... the one thing I have not been able to do with matlab, is to implement GOTO statements. Students who have matlab as their computing experience (as opposed to C/C++, pascal, Fortran...) don't have any concepts of program design. They find a way of getting something done, usually a severe mixture of all concepts above, and do it. Program maintenance is impossible, even understanding the code can be a nightmare. That's before whe start speaking of how matlab handles trivial control statements and conditionals. Regardless of matlab, the scientists don't have much grasp of design, they just implement. One infamous example was an ocean acoustics propagation model, that easily could use hours on one computation. There was a graphical interface added on that program, to plot the results. The guy who implemented the code did not separate the two, so you specified the visualization along with the physics of the simulation. If you after 2 - 10 hours found that the data selection was a bit "off", you had to do the whole 2 - 10 hour simulation again before seeing the new data selection. The distinction was made in later versions of the program. This guy knew his implementation. He was the first to get this particular sort of simulation to work, and used all sorts of tricks, both algorithms and data structures, to get a numerically stable simulation code. But he knew squat about design. Similarly, I had a young engineer help me make a driver for some arcane tape driver. The engineer knew his implementations - he got the thing to work - but he had no concepts of design. He was not concious about the great speed difference between the computer and the tape drive, he did not use I/O buffers so his program read gigabytes of data from the tape, on a byte-by-byte basis. It took hours to read the tapes, where minutes ought to have sufficed. "Design" is an independent skill that needs a conscious effort to be learned. "Implementation" is actually handling the kit, be it the computer or the lathe. Perhaps "design" is the "strategy" and "implementation" the "tactics". > it is the process of design that determines > what will be easy to change later and what will not. As user of a software program, you don't necessarily acknowledge the difference between a structured design of the source code, or an Object Oriented design of the source code. OO was so new when I went to universirty, that only the specialized computer science guys got courses that covered it. We, the engineers, could learn it on our own, but few did: "OO is so hard to wrap one's mind around, and we don't need it for the small projects we program". I did make the effort, and now I hardly do anything that isn't Object Oriented in one way or another. In this case, the difference between the two designs are basicaly that they are two different states of mind. The implementations "hardly" change at all: A little bit of voodoo with function declarations, some added restrictions on the class declarations, and that's it. Deciding whether to go OO or not, is a major design desicion. In my world of scientific computing, it will have very little impact on the "scientifically important" stuff, which is the numerics. OO could make all the difference with respect to communication with other programs, extensions of functionality, etc. > A good designer should > avoid tying excessive investments of time or money to decisions which are > likely to be undone later. RuneArticle: 87444
steve wrote: > "A good designer should > avoid tying excessive investments of time or money to decisions which > are > likely to be undone later. " > > In other words designers have to be fortune tellers. They certainly do. Most successful projects are those where the decision maker(s) could adequately forsee where enough flexibility had to be incorporated to cope with the most likely changes in requirements. Add flexibility everywhere in a project and the cost, timescale, hassle, risk, etc. go through the roof. Provide no flexibility are the 100% absolutely certain changes in need that will occur over the project's life will make it obsolete before completion. Regards, SteveArticle: 87445
Rune Allnor skrev: > Jerry Avins skrev: > > Rune Allnor wrote: > > > > > > Jerry Avins skrev: > > > > > >>Fred Marshall wrote: > > >> > > >> ... > > >> > > >> > > >>>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'm sorry, Fred, but that doesn't fly most of the time. Not only with > > >>electronic design, but with "simpler and more straightforward" (hah!) > > >>projects like bridges and buildings. As the chairman of the construction > > >>committee during the building of a regional sewerage installation that > > >>included a main plant, two satellite plants, three pumping stations, and > > >>over 40 miles of trunk line, I can tell you than no piece of the project > > >>was finished without change orders. The Mercury space capsules' audio > > >>amplifiers were changed twice after the design was thought to be final. > > >>First, to replace power transistors to increase allowable dissipation, > > >>then to correct the near disaster caused by the change. When you go to > > >>the market and discover that some ingredients are unavailable, you > > >>substitute other ingredients or change the recipe. > > > > > > > > > Eh, Jerry... do you and Fred talk about the same things? I interpret > > > Fred's post such that he talks about freezing the *design*. Freezing > > > the design still leaves the freedom to change the *implementation*, > > > which, for some reason, I believe you are discussing. > > > > > > To put it in a DSP context, the major design decision is to decide > > > whether to use a FIR filter or an IIR filter, since this is likely to > > > have some implications for what DSP chips can be used. Having chosen > > > the IIR filter, the implementation could be based on a Butterworth or > > > Chebyshev analog prototype or some optimized discrete-time design. > > > It could be a direct-form I or II, depending on whatever suits the > > > application. Yes, I know, the example is perhaps a bit far-fetched > > > but I hope you see my point. Freezing the decision to use IIR > > > filters still allows implementation details like filter orders and > > > filter coefficients to be changed, for yet some time. > > > > That's well put. How would you classify adding the two satellite plants > > to the sewerage system? Originally, the system was designed with one > > plant, and pipelines to it from all participating communities. One > > administration blocked the two lines from the upstream communities, > > forcing the Sewerage Authority to build the satellite plants. The > > pipeline plans were scrapped, and we considered reducing the size of the > > main plant. Is that a change of implementation, or of plans? > > That's certainly a change of plans, what I am concerned. > > Rune My answer still stands, but I try not to use the word "plan" in this discussion. In my mind, a "plan" is a list of things that need be done in order to implement some system or strategy, or otherwise achieve a goal. If circumstances change, the plan must change. Here, "circumstances" include both "implementation" and "design". Your original goal, make a sewerage facility to serve the community, was still valid. The feasible way to achieve it changed. Hence your change of implementation and of plans. When I talk of "changing goals" or "changing designs", I mean "changing the purpose" of the activity. It would be a "changed design" if you started out to build a sewerage facility but ended up building, say, a parking lot or a mall. I like to watch BBC's "Top Gear", a weekly TV show where new cars are reviewed, tested and commented on. The hosts are very clear in their opinions about what is good and what is bad. Particularly high-profile brands and models (Ferraris, Porches, BMWs,...) are put through their paces in the show. With these types of cars, one main reason for giving bad reviews is often the purpose of the car: "The designers did not decide what kind of car this would be. They wanted this to be a sports car. They wanted this to be a muscle car. They wanted this to be a road cruiser. It is none of the above". Of course, when the purpose of the car is undisputed, the hosts go on to explain, in the most English way, why the purpose was not achieved. RuneArticle: 87446
Randy Yates wrote: > 6. Be patient. > > Waiting for a system to be properly designed will almost always be > more efficient (time-wise) than "waterfall development," i.e., the > type of development for impatient managers that want to see something > almost immediately. I disagree. A better model (than either big up-front design or waterfall), in software development, is the spiral / agile model of development. I've found this model to be excellent, especially when the requirements change or are not fully elicited --- as they usually are in the sorts of software I've developed (greenfield ones). Big up-front design can be a killer when requirements change. For some reason, managers and customers seem to think that software can be changed much more easily than mechanical systems... so they do. The trick is to figure out when they're really expressing a new requirement, or just jumping on the latest Big Thing. I wholeheartedly agree with your previous point of keeping this as abstract as possible for as long as possible. This really helps the whole design and elicitation process.... without investing huge amounts of effort in implementing something that is not critical to success. Ciao, Peter K.Article: 87447
Also check out CORDIC algorithms. GoergeArticle: 87448
Fred Marshall wrote: ... > I agree. It was just that the original question was about best practices for > development and not for research. So, the responses were about development. > Then Jerry brought up "research" and we started a bit down that path. I > simply tried to say that changing the question would change at least some of > the answers. It's a bit harder for me to envision a product engineering > team deciding that failed tests were actually "OK" - although I know that it > happens. (e.g. see Richard Feynman's treatment of the space shuttle > disaster. Thus, I say "harder" not impossible). > > Maybe there needs to be another item on the list: > "Make sure there is good craftsmanship in every discipline" I didn't mean to sidetrack the discussion. My ought to have been more explicit: some exploration is inevitable for all but the most mundane projects. It surprises none of us that R&D has become a single concept. I recall choosing an ADC converter peripheral card with bipolar multiplexer whose specs suited the needs of a project well, only to find -- after the hardware was assembled and drivers written -- that dielectric storage in the holding capacitor made the sampler unable to follow the multiplexer at speeds well within the spec. Oops! (That time, I didn't have to start over. I found and fixed the problem and told the manufacturer how. They issued a recall and change order.) Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87449
Rune Allnor wrote: > > Rune Allnor skrev: > >>Jerry Avins skrev: ... >>>That's well put. How would you classify adding the two satellite plants >>>to the sewerage system? Originally, the system was designed with one >>>plant, and pipelines to it from all participating communities. One >>>administration blocked the two lines from the upstream communities, >>>forcing the Sewerage Authority to build the satellite plants. The >>>pipeline plans were scrapped, and we considered reducing the size of the >>>main plant. Is that a change of implementation, or of plans? >> >>That's certainly a change of plans, what I am concerned. >> >>Rune > > > My answer still stands, but I try not to use the word "plan" in this > discussion. In my mind, a "plan" is a list of things that need be done > in order to implement some system or strategy, or otherwise achieve a > goal. If circumstances change, the plan must change. Here, > "circumstances" > include both "implementation" and "design". > > Your original goal, make a sewerage facility to serve the community, > was still valid. The feasible way to achieve it changed. Hence your > change of implementation and of plans. > > When I talk of "changing goals" or "changing designs", I mean "changing > > the purpose" of the activity. It would be a "changed design" if you > started > out to build a sewerage facility but ended up building, say, a parking > lot > or a mall. > > I like to watch BBC's "Top Gear", a weekly TV show where new cars > are reviewed, tested and commented on. The hosts are very clear in > their opinions about what is good and what is bad. Particularly > high-profile brands and models (Ferraris, Porches, BMWs,...) are > put through their paces in the show. > > With these types of cars, one main reason for giving bad reviews is > often the purpose of the car: "The designers did not decide what kind > of car this would be. They wanted this to be a sports car. They wanted > this to be a muscle car. They wanted this to be a road cruiser. It is > none of the above". > > Of course, when the purpose of the car is undisputed, the hosts go > on to explain, in the most English way, why the purpose was not > achieved. You made my point, I think. "One plant downstream" can be either a plan or an implementation, depending on how long a view one takes. We had other design goals, not stated above. Among them, we wanted to avoid despoiling the countryside we live in. The main plant discharges into a river. When the inflow from heavy rains degrades the quality of the effluent, the river becomes a torrent that can accommodate heavy BOD* loading. Where before, one community's outfall caused periodic fish kills, now fish congregate just downstream of our much larger plant's discharge pipe. Not only is dissolved oxygen higher there, but the water is clearer than upstream. It's a great place to fish. The upstream plants pose a different problem. Both discharge into the headwaters of streams that, without their flow, would be dry for weeks at a time. Before the plants were built, fish and other aquatic life would ride out the dry spells in pools in the stream bed, and many would survive. (Some of the pools are spring fed.) Since they began operation, each upstream plant discharges about 0.3 million gallons a day of treated sewage into each stream. The streams never run dry. Clearly, for weeks at a time, there is nothing in the stream but sewage, and sewage is a major component at all times. We didn't want that responsibility. _That wasn't the original plan._ But the original goal gas been met: there have been no fish die-offs in the 25 years that the plants have been in operation. Kids swim and wade without harm; animals drink. _But we spend a lot more to treat upstream sewage upstream_ than it would have cost to send it downstream and treat it there. When the downstream plant operates normally, as it does an average of 363 days a year, its effluent tests purer than most bottled water. http://www.sbrsa.org/ Jerry ___________________________ * Biological oxygen demand -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
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