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'm sorry, I though the implied shift was obvious. The important thing is that repeating patterns of bits in a multiplicand result in simple chains of two input adders. In the above example, Y1 is X multiplied by 11 (= 3 decimal) Y2 is X multiplied by 110011 (= 51 decimal) Y3 is X multiplied by 11001100110011 (= 13107 decimal) Y4 is X multiplied by 110011001100110011001100110011 (= 858993459 decimal) (Y1 >> 4) is X multiplied by 0.0011 (= 0.1875 decimal) (Y2 >> 8) is X multiplied by 0.00110011 (= 0.19921875 decimal) (Y3 >> 16) is X multiplied by 0.0011001100110011 (= 0.199996948242188 decimal) (Y4 >> 32) is X multiplied by 0.00110011001100110011001100110011 (= 0.199999999953434 decimal) It's really just moving the binary point around. I get used to thinking in 'fixed point' with implied binary points all over the place. The underlying arithmetic is based on integers. Ray likes to think of his digits as being to the right of the point; I like them to the left. I think Ray's view may be more prevalent amongst designers (hence the comment about right shift being more intuitive).Article: 87376
uuyu wrote: > I was arguing with a friend about SSE2 (Intel's SIMD vector > CPU instructions), and how useless it is to most general > computer programs. > > But he correctly pointed out any analog simulation (SPICE) > likely use floating-point numeric computations. Furthermore, > he claimed that in native 64-bit mode, the AMD64/EM64T > instruction-set doesn't have x87 (legacy FPU) instructions. > A 64-bit application MUST use SSE registers for all > floating-point math. Quoted from the Wikipedia AMD64 entry (for what that's worth): "SSE instructions. The AMD64 architecture includes Intel's SSE and SSE2 instructions, newer E-stepping CPU include SSE3 as well. The x87 and MMX instructions are supported." Windows for AMD64/EM64T won't save the x87 FPU context for a 64-bit process, so that makes the x87 essentially useless on that OS (except for older 32-bit code). You *can* use the x87 FPU in a 64-bit process under Linux for AMD64, but it will be difficult to call FP library routines - the AMD64 ABI uses the SSE2 registers for float argument passing. -JasonArticle: 87377
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. I don't have much experience in project managment (exept for some of my own more or less "hobby" projects), but I have been around a couple of bad projects, and there are one or two things I would like to see tested out in practice. First, there must be *one* person in charge, and this must be the person who really *is* in charge. To take the last first, I have seen projects here one person is nominally in charge (e.g. the young, ambitious "fast-track'er") while another person is de facto in charge (e.g. the "old fox" in the engineering staff.) That's basically a recipe for disaster. You have to have *one* project boss (who might be held responsible by a board of directors, but they are outside the project as such) that has all the responsibility within the project. Divided responsibilities just don't work at the project managment level. Second, the person in charge must be competent. The whole problem scope must fit in the mind of one person. The application, the technology, the implementation. All such aspects bring their own issues into the project, and must be considered. There may be (and probably are) people in the project who have deeper/more specialized knowledge than the boss of each single aspect, but the project boss must have working knowledge of all relevant aspects. A "trival" corollary from the above, is that project managers are recruited amongst the more experienced engineering staff, not amongst lawyers, economists or "fast-trackers" (even engineering "fast-trackers"). Third, you need to get trained engineers in the staff, and you need to supervise them "properly" during the project. Put younger people work along side the elderly, novices with experts. The inexperienced get to know what's expected from them, and have a chance of seeing what it takes to deliver. The experts get some help in doing the more mundane tasks, some even find it fun/rewarding to train novices and youngsters. Fourth, keep the teams small and keep them responsible for their deliveries. Make sure to give them credit where credit is due. If something goes wrong, have a look at the brief the team had to work from, whether the goals were feasible within the allocated time and resources etc, before blaming single members of the teams for any sort of failure. Fifth, as boss you are most likely to face people in the team who have more specialized skills (and perhaps even more overall skills) than yourself. Be aware of that, and show that you are aware. The kind of people you work with can be *really* smart in their respective fields. Such people tend not to take lightly on people who try to display a competence they in reality don't have. It is way better to ask "would you help me understand how to do this" instead of taking on some sort of "bravado" mask of "this was obvious" when presented with a clever piece of engineering. The humble approach might gain the boss some respect, it certainly provides the generalist with an oportunity to learn from the specialists. Sixth, set a three-level goal for the project: A) The "bare survival" delivery, that *just* meets the project goals, without you being sued/fired/go bancrupt/flunk the exam... B) The "decent" delivery, that meets the goals with a comfortable margin, where there are used "decent" techniques and solutions as opposed to "quick'n dirty" ones, all documentation is ready etc. C) The "ideal" solution, where absolutely everything went your way, and where you used all the nifty algorithms, included all the fun bells'n whistles etc, the whole software program is fully portable, easily extendable, on-the-fly reconfigurable, everything is documented and available in six languages... Being aware of level A) is an absolute must. Being aware of the difference between levels A) and B) comes in handy. Level C) is, as of yet, just an illusive dream in my world, and was included more for completeness than anything else... Seventh, don't demand from others what you are not willing to, or capable to, yield yourself. It's basically about the manager/boss setting an example of what is expected from the project team. If there are demands to, say, documentation of the product, the development process, or anything else, provide the tools for the programmers to make that documentation. If the project documents are required to have a certain layout, the boss provides the (working!) macros or packages that make the text processor produce the layout. You would be surprised how much "bad blood" is generated by putting hard (allbeit reasonable) demands to the crew *without* providing the means to meet them. Basically, once the project team respects the project boss, on a personal and professional level and see that he knows what he is doing, there will be a lot less strain once the going gets though. As it always does. As far as I am concerned, it's all about getting the right people in the right places, and once there, getting them to work efficently. I know it isn't always possible, but paying some attention to who goes in what position, what tools are available to them etc, makes quite a difference. If the team can't find a way to work together, the project is lost. If the team members don't trust or respect the boss, the project is lost. If the boss doesn't know his way around either one of the application, the technology, the tools or the implementation, the project is lost. > As an engineer, I'm constantly trying to improve my design processes. That's a goal I sincerely sympathize with. There is always something to learn, something to improve on. RuneArticle: 87378
this mentality has been adopted in our company, the natural result of this is ultra conservative designs because everyone is afraid that they will be the one to screw up the schedule. there is something to be said for prototypes, I can't imagine your going to build anything innovative by just thinking it all out on paper and/or computer simulation, data sheets are typically not comprehensive or contain errors, circuit simulations are not accurate (especially noise estimates, almost impossible to predict accurately) , engineers are not perfect, they sometimes misread a datasheet or just make a error, a prototype can quickly confirm the robustness of a designArticle: 87379
Well it comes in a form of schematic diagram which is messy to read. i couldn't find table of pinouts like i had for other boards i worked with. but i think i worked it out this way. i went trough some crazy files and extracted what i needed. thanks for answeringArticle: 87380
Andre, If you have one cycle to answer with the appropriate data byte, it means that there is no "no time". I think that this is the choice you have: (*) Sample NXT and then do everything combinationally. (**) Do everything combinationally and then sample the result (FSM state, data, etc) Both cases are viable solutions, but to resolve our worries with regards to setup/hold time, this is what you can do. 60 Mhz is ~16 ns. Let's talk about constraints again. What is the budget available for NXT signal? What's the budget for DATA in its output path (i.e. the input delay of the PHY device)? Regardless of the answer, you need to define a clock constraint, and OFFSET IN BEFORE / OFFSET IN AFTER for NXT signal. For the DATA output path, you have to use FROM TO to place the data_out FF accordingly. Vladislav <ALuPin@web.de> wrote in message news:1122016975.381235.236820@o13g2000cwo.googlegroups.com... >Maybe I am wrong, but where you need to do everything on one cycle? If I use the NXT signal directly from pin and I use the PHY clock as my FSM clock I have one cycle to answer with the appropiate data byte. The problem that arises is that I have to care about SETUP/HOLD timings because I check the signal NXT in almost all of my FSM states. If the FSM becomes large I have to assure that these timing are violated in NO state of the FSM. When working directly from pin it is not that easy as having registered NXT before. Am I right? Rgds AndréArticle: 87381
John Larkin wrote: > As opposed to, say, thinking it through carefully and getting it right > the first time? The secret message of the book is that's what "heroic" architects like Frank Lloyd Wright do. Google his name and "leaky". -- Phlip http://www.c2.com/cgi/wiki?ZeekLandArticle: 87382
Cheers with all lucky guys who loaded XLNX yesterday. Thanks XLNX, for your products and earnings. GO GO GO XLNX!!!Article: 87383
ALuPin@web.de wrote:
> The problem that arises is that I have to care about SETUP/HOLD timings
> because I check the signal NXT
You don't have to worry about that if you use a synchronizer.
Just assume that it works and the output is synchronous.
Remember that you are using a 120MHZ fpga clock so you
have several ticks to work with.
> in almost all of my FSM states. If the FSM becomes large I have to
> assure that
> these timing are violated in NO state of the FSM.
> When working directly from pin it is not that easy as having registered
> NXT before. Am I right?
No. Everything, even the synchronizer runs
on the FPGA clock.
-- Mike Treseler
Article: 87384Hi, I am trying to implement the Opencores PCI Bridge on a MEMEC 2s200 Spartan II. When I synthezise using a .UCF file I get the following error: ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in your design cannot be automatically placed. Any help? ThanksArticle: 87385
Vladislav Muravin wrote:
> If you have one cycle to answer with the appropriate data byte, it means
> that there is no "no time".
One cycle is plenty of time with a 120MHZ fpga clock.
> I think that this is the choice you have:
> (*) Sample NXT and then do everything combinationally.
> (**) Do everything combinationally and then sample the result (FSM state,
> data, etc)
Or synchronize: NXT_raw-->[DQ]--[DQ]--NXT_Q--
and do nothing combinationally.
-- Mike Treseler
Article: 87386Joe wrote: >All comments are >welcomed, even the most obvious suggestions. "The Mythical Man-Month: Essays on Software Engineering" by Frederick P. Brooks. The hardware types should not focus on "Software" in the title, the book is about the nature of individuals and groups working on complex projects. -- Phil Hays Phil-hays at comcast.moc (remove moc and add net) should work for emailArticle: 87387
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?? I'm using the latest versions of ISE and XPS. Thanks in advance, StefanArticle: 87388
"Mike Treseler" <mtreseler@gmail.com> wrote in message news:TKqdncuTH9VhYn3fRVn-tQ@comcast.com... > Vladislav Muravin wrote: > >> If you have one cycle to answer with the appropriate data byte, it means >> that there is no "no time". > > One cycle is plenty of time with a 120MHZ fpga clock. Yeah, I said " no "no time" ", which means !(!(time)) = plenty of time > >> I think that this is the choice you have: >> (*) Sample NXT and then do everything combinationally. >> (**) Do everything combinationally and then sample the result (FSM state, >> data, etc) > > Or synchronize: NXT_raw-->[DQ]--[DQ]--NXT_Q-- > and do nothing combinationally. > > -- Mike Treseler Possibly, but 60 MHz constraints also would do just fine. In addition, if the state machine of Andre may be too complicated to run it on 120 MHz, we might have a problem. VArticle: 87389
stbcasa wrote: > Hi, > > I am trying to implement the Opencores PCI Bridge on a MEMEC 2s200 > Spartan II. When I synthezise using a .UCF file I get the following > error: > > ERROR:Place:207 - Due to SelectIO banking constraints, the IOBs in your > design cannot be automatically placed. > Since you are using a board product, you need to place your IOB's in order to match the actual board layout. This error message indicates that there are at least some IOB's without LOC constraints in your .UCF file. Generally this message will only occur when your I/O type requires special voltage (Vcco) or other resources (Vref or DCI resistors). If you are using a .UCF file provided by MEMEC, make sure the pin names for PCI match the net names in the Opencores PCI Bridge. Also look at your place and route report. Near the top there is a summary of device usage. One line of this indicates the percentage of LOC'd IOB's. For a design on a board product, this should be 100%. Regards, GaborArticle: 87390
<ytregubov@yahoo.com> wrote in message news:1122021099.971139.117790@f14g2000cwb.googlegroups.com... > The design rule is Minimizing The Complexity. Do not rely on the false > and unfortunately quite popular idea that any simple HW/SW design is > 'stupid'. It's better to make $$$ with 'stupid' product than stuck with complex but 'clever' one ... I agree with the assessment, but keep in mind that it's a lot easier for others to compete against someone making simple designs than those making complex designs. On the other hand, my experience is that many projects fail much more due to poor planning, customer service (not meeting the customer's needs, even if the customer isn't fully aware of their own needs!), etc. than any real technical hurdles. I also would say that, while nothing should be more complex than it needs to be (a variant of Einstein's quote), many products today are expected to 'evolve' over time. That is, the same basic hardware/software platform gets reused in more than one project. In such cases, increases in complexity are warranted if they make the '2nd generation' product that much easier to produce. Many engineers and programmers try to make the excuse that they don't have time to make a flexible, structured, 'polished' design and end up building something that -- while the first article out the door might happen sooner -- the product has higher failure rates during production or in the field and the 2nd generation timeline ends up being completely shot. Most critical of all, though, is finding the right people. Really good engineers and programmers vs. the average ones can easily make a 2:1 difference in productivity, and given the option I'd rather have all those folks around and pay them twice as much as the average folks. ---Joel KolstadArticle: 87391
Rune Allnor wrote: > > 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. > > > I don't have much experience in project managment (exept for some > of my own more or less "hobby" projects), but I have been around > a couple of bad projects, and there are one or two things I would > like to see tested out in practice. > > First, there must be *one* person in charge, and this must be the > person who really *is* in charge. > > To take the last first, I have seen projects here one person is > nominally in charge (e.g. the young, ambitious "fast-track'er") > while another person is de facto in charge (e.g. the "old fox" > in the engineering staff.) That's basically a recipe for disaster. > > You have to have *one* project boss (who might be held responsible > by a board of directors, but they are outside the project as such) > that has all the responsibility within the project. Divided > responsibilities just don't work at the project managment level. > Delagated responsibilities, however, are a must. > Second, the person in charge must be competent. The whole problem > scope must fit in the mind of one person. The application, the > technology, the implementation. All such aspects bring their own > issues into the project, and must be considered. There may be (and > probably are) people in the project who have deeper/more specialized > knowledge than the boss of each single aspect, but the project boss > must have working knowledge of all relevant aspects. > If you mean that the project manager must be able to work on any piece of the thing that isn't so. On a really complex project no one person can embrace the whole thing in detail. The project manager should be able to grasp the interactions of the pieces, however. > snip > Sixth, set a three-level goal for the project: > > A) The "bare survival" delivery, that *just* meets the project > goals, without you being sued/fired/go bancrupt/flunk the exam... > B) The "decent" delivery, that meets the goals with a comfortable > margin, where there are used "decent" techniques and solutions > as opposed to "quick'n dirty" ones, all documentation is ready etc. > C) The "ideal" solution, where absolutely everything went your way, > and where you used all the nifty algorithms, included all the > fun bells'n whistles etc, the whole software program is fully > portable, easily extendable, on-the-fly reconfigurable, > everything is documented and available in six languages... > > Being aware of level A) is an absolute must. Being aware of the > difference between levels A) and B) comes in handy. Level C) is, > as of yet, just an illusive dream in my world, and was included > more for completeness than anything else... > This sort of excersize is very good for focussing the mind, and also works for each of the pieces. It's always a good idea to put as many hooks into the design to let you achieve 'C' later, even if you can only achieve 'A' now. > Seventh, don't demand from others what you are not willing to, or > capable to, yield yourself. It's basically about the manager/boss > setting an example of what is expected from the project team. > If there are demands to, say, documentation of the product, the > development process, or anything else, provide the tools for the > programmers to make that documentation. If the project documents > are required to have a certain layout, the boss provides the > (working!) macros or packages that make the text processor produce > the layout. > Here again I'm going to disagree. I've been on well run projects where this sort of task (not this exact one) has been delagated by the project manager to someone better able to do it. Note, however, that the project manager still takes responsibility for what he delagates. Frankly, if the project manager can delagate effectively and keep the team happy he doesn't have to know squat -- except that not knowing squat is a barrier to effective delagation... > You would be surprised how much "bad blood" is generated by putting > hard (allbeit reasonable) demands to the crew *without* providing > the means to meet them. Yea verily. > Basically, once the project team respects > the project boss, on a personal and professional level and see that > he knows what he is doing, there will be a lot less strain once the > going gets though. As it always does. > > As far as I am concerned, it's all about getting the right people > in the right places, and once there, getting them to work efficently. > I know it isn't always possible, but paying some attention to who > goes in what position, what tools are available to them etc, makes > quite a difference. If the team can't find a way to work together, > the project is lost. If the team members don't trust or respect the > boss, the project is lost. If the boss doesn't know his way around > either one of the application, the technology, the tools or the > implementation, the project is lost. > > >>As an engineer, I'm constantly trying to improve my design processes. > > > That's a goal I sincerely sympathize with. There is always something > to learn, something to improve on. > > Rune > -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 87392
Ray Andraka wrote: > Hierarchical design. Every complex design or algorithm is an aggregate > of simpler subsystems. By using hierarchy, you get a fairly simple > representation at every level in the design, and with the exception of > the leaf nodes, the design is an exercise of defining and then stitching > together the sub-blocks. The designs at the leaf nodes are simple > designs (if they aren't then they should also be broken into sub-modules). > > With a proper definition of each block, the blocks can be broken out > into independent designs with the responsibility of meeting the > interface specifications falling on whoever designs that block. > This should be done, however, by an individual (or _very_ small team) who understands what can reasonably be asked of each node -- otherwise you end up with an imbalanced or just plain impossible design. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 87393
<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. > > Thanks everyone, > joe > What I've found, (in short) is that a project manager has to active in the art form of communications. He has to be a "people person". Start treating someone like one of those little MS Project bars and you'll soon see those bars grow. It very easy for a engineer to pass the buck when so many people are involved. It's a lot better if he cares about the projects completion and respects the project manager. Oh ya, and the term "commands respect" doesn't work with the smart engineers. ThomasArticle: 87394
Tim Wescott wrote: > Rune Allnor wrote: > > > > > 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. > > > > > > I don't have much experience in project managment (exept for some > > of my own more or less "hobby" projects), but I have been around > > a couple of bad projects, and there are one or two things I would > > like to see tested out in practice. > > > > First, there must be *one* person in charge, and this must be the > > person who really *is* in charge. > > > > To take the last first, I have seen projects here one person is > > nominally in charge (e.g. the young, ambitious "fast-track'er") > > while another person is de facto in charge (e.g. the "old fox" > > in the engineering staff.) That's basically a recipe for disaster. > > > > You have to have *one* project boss (who might be held responsible > > by a board of directors, but they are outside the project as such) > > that has all the responsibility within the project. Divided > > responsibilities just don't work at the project managment level. > > > Delagated responsibilities, however, are a must. Agreed. "Divided" and "delegated" are two very different concepts. > > Second, the person in charge must be competent. The whole problem > > scope must fit in the mind of one person. The application, the > > technology, the implementation. All such aspects bring their own > > issues into the project, and must be considered. There may be (and > > probably are) people in the project who have deeper/more specialized > > knowledge than the boss of each single aspect, but the project boss > > must have working knowledge of all relevant aspects. > > > If you mean that the project manager must be able to work on any piece > of the thing that isn't so. On a really complex project no one person > can embrace the whole thing in detail. The project manager should be > able to grasp the interactions of the pieces, however. Yep. That ability comes with experience, and from working over a long time with specialists from other diciplines. As for myself, I don't know how to run a ship. But having been to sea, I have an impression of what can and what can not be done. And I try to take those experiences into account when I discuss sea trials and marine operations. > > > > snip > > > Sixth, set a three-level goal for the project: > > > > A) The "bare survival" delivery, that *just* meets the project > > goals, without you being sued/fired/go bancrupt/flunk the exam... > > B) The "decent" delivery, that meets the goals with a comfortable > > margin, where there are used "decent" techniques and solutions > > as opposed to "quick'n dirty" ones, all documentation is ready etc. > > C) The "ideal" solution, where absolutely everything went your way, > > and where you used all the nifty algorithms, included all the > > fun bells'n whistles etc, the whole software program is fully > > portable, easily extendable, on-the-fly reconfigurable, > > everything is documented and available in six languages... > > > > Being aware of level A) is an absolute must. Being aware of the > > difference between levels A) and B) comes in handy. Level C) is, > > as of yet, just an illusive dream in my world, and was included > > more for completeness than anything else... > > > This sort of excersize is very good for focussing the mind, and also > works for each of the pieces. It's always a good idea to put as many > hooks into the design to let you achieve 'C' later, even if you can only > achieve 'A' now. My thoughts exactly. > > Seventh, don't demand from others what you are not willing to, or > > capable to, yield yourself. It's basically about the manager/boss > > setting an example of what is expected from the project team. > > If there are demands to, say, documentation of the product, the > > development process, or anything else, provide the tools for the > > programmers to make that documentation. If the project documents > > are required to have a certain layout, the boss provides the > > (working!) macros or packages that make the text processor produce > > the layout. > > > Here again I'm going to disagree. I've been on well run projects where > this sort of task (not this exact one) has been delagated by the project > manager to someone better able to do it. Note, however, that the > project manager still takes responsibility for what he delagates. While my post may be phrased that way, I don't mean litterally that the manager should do it himself. "See to that it is done" suffices. But that's a must. > Frankly, if the project manager can delagate effectively and keep the > team happy he doesn't have to know squat -- except that not knowing > squat is a barrier to effective delagation... My point exactly. > > You would be surprised how much "bad blood" is generated by putting > > hard (allbeit reasonable) demands to the crew *without* providing > > the means to meet them. > > Yea verily. > > > Basically, once the project team respects > > the project boss, on a personal and professional level and see that > > he knows what he is doing, there will be a lot less strain once the > > going gets though. As it always does. > > > > As far as I am concerned, it's all about getting the right people > > in the right places, and once there, getting them to work efficently. > > I know it isn't always possible, but paying some attention to who > > goes in what position, what tools are available to them etc, makes > > quite a difference. If the team can't find a way to work together, > > the project is lost. If the team members don't trust or respect the > > boss, the project is lost. If the boss doesn't know his way around > > either one of the application, the technology, the tools or the > > implementation, the project is lost. > > > > > >>As an engineer, I'm constantly trying to improve my design processes. > > > > > > That's a goal I sincerely sympathize with. There is always something > > to learn, something to improve on. > > > > Rune > > > > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com RuneArticle: 87395
John Larkin wrote: > On Thu, 21 Jul 2005 19:46:17 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote: > > >>jjlindula wrote: >> >> >>>Hello, I'm interested in how individuals or design groups manage >>>complexity in their design projects. >> >>Read /Notes on the Synthesis of Form/ by Christopher Alexander. It makes the >>best case possible for incremental design. You build a prototype, see if it >>works, tweak it a little, and repeat over many iterations. >> > > > As opposed to, say, thinking it through carefully and getting it right > the first time? > > John I found that when I wrote a version of code that I intend to discard, I got a good product more quickly. I couldn't often do that because some stupid boss type was too likely ti insist that it be "shipped", so I had to work everything out in my head, on the sly, or at home. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87396
ituspam@yahoo.com wrote: > Cheers with all lucky guys who loaded XLNX yesterday. > Thanks XLNX, for your products and earnings. > GO GO GO XLNX!!! It's still waaay down from where I bought it a few years ago. -aArticle: 87397
junaid wrote: > 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 Standard synthesis and place-and-route tools? -aArticle: 87398
Hello Vladislav, Singhal and Andraka, As this is not my top-level design I did not want IOB assigned, then I turned off the trim unconnected signals. This way the tool does not remove away all the logic. Thanks fls for all the help. -Azam Vladislav Muravin wrote: > Dear Azam, > > I can think of only missing I/O buffers, so you need to tuirn on "Add I/O > Buffers" option in XST synthesis options. > But there supposed to be a section which says exactly what logic has been > optimized (i think it's called "trimmed") > > Are you still having this issue? > > Regards, > Vladislav > > > "azam" <azamirfan@gmail.com> wrote in message > news:1121891799.121943.136460@g43g2000cwa.googlegroups.com... > > Vladislav, > > > > The warnings are related to the I/O's of my top level module. > > > > Release 7.1.03i Map H.41 > > Xilinx Mapping Report File for Design 'sata_device_gasket' > > > > Design Information > > ------------------ > > Command Line : C:/Xilinx_71i/bin/nt/map.exe -ise > > e:\gasket_xilinx\gasket_xilinx.ise -intstyle ise -p xc4vlx40-ff668-11 > > -timing > > -ol high -t 1 -register_duplication -cm speed -detail > > -ignore_keep_hierarchy -pr > > b -u -k 4 -c 100 -o sata_device_gasket_map.ncd sata_device_gasket.ngd > > sata_device_gasket.pcf > > Target Device : xc4vlx40 > > Target Package : ff668 > > Target Speed : -11 > > Mapper Version : virtex4 -- $Revision: 1.26.6.4 $ > > Mapped Date : Wed Jul 20 10:42:22 2005 > > > > Design Summary > > -------------- > > Number of errors: 0 > > Number of warnings: 87 > > Logic Utilization: > > Number of Slice Flip Flops: 573 out of 36,864 1% > > Number of 4 input LUTs: 1,296 out of 36,864 3% > > Logic Distribution: > > Number of occupied Slices: 865 out of > > 18,432 4% > > Number of Slices containing only related logic: 865 out of > > 865 100% > > Number of Slices containing unrelated logic: 0 out of > > 865 0% > > *See NOTES below for an explanation of the effects of unrelated > > logic > > Total Number 4 input LUTs: 1,304 out of 36,864 3% > > Number used as logic: 1,296 > > Number used as a route-thru: 4 > > Number used as Shift registers: 4 > > > > Total equivalent gate count for design: 13,582 > > Peak Memory Usage: 291 MB > > > > Table of Contents > > ----------------- > > Section 1 - Errors > > Section 2 - Warnings > > Section 3 - Informational > > Section 4 - Removed Logic Summary > > Section 5 - Removed Logic > > Section 6 - IOB Properties > > Section 7 - RPMs > > Section 8 - Guide Report > > Section 9 - Area Group Summary > > Section 10 - Modular Design Summary > > Section 11 - Timing Report > > Section 12 - Configuration String Information > > Section 13 - Additional Device Resource Counts > > > > Section 1 - Errors > > ------------------ > > > > Section 2 - Warnings > > -------------------- > > WARNING:Map:120 - The command line option -c can not be used when > > running in > > timing mode. The option will be ignored. > > WARNING:LIT:243 - Logical network mrconStart has no load. > > WARNING:LIT:243 - Logical network rst_spd_chng_en has no load. > > WARNING:LIT:243 - Logical network genAlign_i<1> has no load. > > WARNING:LIT:243 - Logical network AGS_en has no load. > > WARNING:LIT:243 - Logical network pllClkDiv5 has no load. > > WARNING:LIT:243 - Logical network pwrdnBiasGeno has no load. > > WARNING:LIT:243 - Logical network pwrdnPLLBo has no load. > > WARNING:LIT:243 - Logical network snoozePHYo<1> has no load. > > WARNING:LIT:243 - Logical network snoozePHYo<0> has no load. > > WARNING:LIT:243 - Logical network comType<1> has no load. > > WARNING:LIT:243 - Logical network comType<0> has no load. > > WARNING:LIT:243 - Logical network pwrdnTxBo<1> has no load. > > WARNING:LIT:243 - Logical network pwrdnTxBo<0> has no load. > > WARNING:LIT:243 - Logical network resetDigToPHYB<1> has no load. > > WARNING:LIT:243 - Logical network resetDigToPHYB<0> has no load. > > WARNING:LIT:243 - Logical network pwrdnTxDrvBo<1> has no load. > > WARNING:LIT:243 - Logical network pwrdnTxDrvBo<0> has no load. > > WARNING:LIT:243 - Logical network pwrdnDetBo<1> has no load. > > WARNING:LIT:243 - Logical network pwrdnDetBo<0> has no load. > > WARNING:LIT:243 - Logical network forceIdle<1> has no load. > > WARNING:LIT:243 - Logical network forceIdle<0> has no load. > > WARNING:LIT:243 - Logical network offlinePHYo<1> has no load. > > WARNING:LIT:243 - Logical network offlinePHYo<0> has no load. > > WARNING:LIT:243 - Logical network partialPHYo<1> has no load. > > WARNING:LIT:243 - Logical network partialPHYo<0> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<9> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<8> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<7> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<6> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<5> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<4> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<3> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<2> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<1> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_0<0> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<9> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<8> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<7> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<6> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<5> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<4> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<3> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<2> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<1> has no load. > > WARNING:LIT:243 - Logical network txDataToPHY_1<0> has no load. > > WARNING:LIT:243 - Logical network comStart<1> has no load. > > WARNING:LIT:243 - Logical network comStart<0> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<9> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<8> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<7> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<6> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<5> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<4> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<3> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<2> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<1> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_0<0> has no load. > > WARNING:LIT:243 - Logical network slumberPHYo<1> has no load. > > WARNING:LIT:243 - Logical network slumberPHYo<0> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<9> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<8> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<7> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<6> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<5> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<4> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<3> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<2> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<1> has no load. > > WARNING:LIT:243 - Logical network rxDataToLL_1<0> has no load. > > WARNING:LIT:243 - Logical network resetCDRToPHYB<1> has no load. > > WARNING:LIT:243 - Logical network resetCDRToPHYB<0> has no load. > > WARNING:LIT:243 - Logical network pwrdnRxBo<1> has no load. > > WARNING:LIT:243 - Logical network pwrdnRxBo<0> has no load. > > WARNING:LIT:243 - Logical network halfRateToPHY<1> has no load. > > WARNING:LIT:243 - Logical network halfRateToPHY<0> has no load. > > WARNING:LIT:243 - Logical network phyrdy<1> has no load. > > WARNING:LIT:243 - Logical network phyrdy<0> has no load. > > WARNING:LIT:243 - Logical network txSigSel_0<1> has no load. > > WARNING:LIT:243 - Logical network txSigSel_0<0> has no load. > > WARNING:LIT:243 - Logical network txSigSel_1<1> has no load. > > WARNING:LIT:243 - Logical network txSigSel_1<0> has no load. > > WARNING:LIT:243 - Logical network genD10_2_i<1> has no load. > > WARNING:LIT:243 - Logical network spareIn<1> has no load. > > WARNING:LIT:243 - Logical network spareIn<0> has no load. > > WARNING:LIT:243 - Logical network spareOut<1> has no load. > > WARNING:LIT:243 - Logical network spareOut<0> has no load. > >Article: 87399
Slightly off-topic post: I am looking for parallel optic (12-way) transmitter and receiver at ~2.7Gbps, to use with xilinx Rocket IO. Several companies have them on their web sites (Agilent, Infineon, emcore, Picolight, Zarlink), but none of them really sell them, at least in small quantities. They don't even answer to calls and emails. Anybody knows the trick to get them other than faking my email as @cisco.com ? -- Tullio Grassi
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