Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 87375

Article: 87375
Subject: Re: Optimizing out a divide on altera cyclone fpga
From: allanherriman@hotmail.com
Date: 22 Jul 2005 04:08:37 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: (x86 linux) SSE2 usage by simulation applications?
From: Jason Ozolins <jason_abroad@yahoo.com.au>
Date: Fri, 22 Jul 2005 21:52:20 +1000
Links: << >>  << T >>  << A >>
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.

-Jason

Article: 87377
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 22 Jul 2005 04:58:27 -0700
Links: << >>  << T >>  << A >>


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.

Rune


Article: 87378
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "steve" <bungalow_steve@yahoo.com>
Date: 22 Jul 2005 06:01:19 -0700
Links: << >>  << T >>  << A >>
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 design


Article: 87379
Subject: Re: DDR SDRAM on ML401
From: "Nenad" <n_uzunovic@yahoo.com>
Date: 22 Jul 2005 06:06:59 -0700
Links: << >>  << T >>  << A >>

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 answering


Article: 87380
Subject: Re: Using unregistered inputs in FSM
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Fri, 22 Jul 2005 09:28:34 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Phlip" <phlip_cpp@yahoo.com>
Date: Fri, 22 Jul 2005 13:54:37 GMT
Links: << >>  << T >>  << A >>
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?ZeekLand



Article: 87382
Subject: What a nice day for XLNX
From: "ituspam@yahoo.com" <ituspamin@yahoo.com>
Date: 22 Jul 2005 07:08:31 -0700
Links: << >>  << T >>  << A >>
Cheers with all lucky guys who loaded XLNX yesterday.
Thanks XLNX, for your products and earnings. 
GO GO GO XLNX!!!


Article: 87383
Subject: Re: Using unregistered inputs in FSM
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 22 Jul 2005 07:11:16 -0700
Links: << >>  << T >>  << A >>
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: 87384
Subject: Place Error
From: "stbcasa" <jtrabal@engin.umass.edu>
Date: 22 Jul 2005 07:15:51 -0700
Links: << >>  << T >>  << A >>
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.

Any help?

Thanks


Article: 87385
Subject: Re: Using unregistered inputs in FSM
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 22 Jul 2005 07:17:31 -0700
Links: << >>  << T >>  << A >>
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: 87386
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Phil Hays <Spampostmaster@comcast.net>
Date: Fri, 22 Jul 2005 07:19:03 -0700
Links: << >>  << T >>  << A >>
Joe 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
email


Article: 87387
Subject: Overmapped
From: "Stefan" <holzi_stefan@hotmail.com>
Date: Fri, 22 Jul 2005 16:39:38 +0200
Links: << >>  << T >>  << A >>
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,

Stefan



Article: 87388
Subject: Re: Using unregistered inputs in FSM
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Fri, 22 Jul 2005 10:42:59 -0400
Links: << >>  << T >>  << A >>

"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.

V



Article: 87389
Subject: Re: Place Error
From: "Gabor" <gabor@alacron.com>
Date: 22 Jul 2005 07:54:42 -0700
Links: << >>  << T >>  << A >>
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,
Gabor


Article: 87390
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Joel Kolstad" <JKolstad71HatesSpam@yahoo.com>
Date: Fri, 22 Jul 2005 08:32:21 -0700
Links: << >>  << T >>  << A >>
<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 Kolstad



Article: 87391
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 22 Jul 2005 08:57:55 -0700
Links: << >>  << T >>  << A >>
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.com

Article: 87392
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 22 Jul 2005 08:59:43 -0700
Links: << >>  << T >>  << A >>
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.com

Article: 87393
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Thomas Magma" <somewhere@overtherainbow.com>
Date: Fri, 22 Jul 2005 16:17:04 GMT
Links: << >>  << T >>  << A >>
<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.

Thomas 



Article: 87394
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Rune Allnor" <allnor@tele.ntnu.no>
Date: 22 Jul 2005 09:22:48 -0700
Links: << >>  << T >>  << A >>


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

Rune


Article: 87395
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Fri, 22 Jul 2005 12:26:33 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: What a nice day for XLNX
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 22 Jul 2005 10:19:26 -0700
Links: << >>  << T >>  << A >>
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.

-a


Article: 87397
Subject: Re: verilog to blif(lut)
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 22 Jul 2005 10:20:09 -0700
Links: << >>  << T >>  << A >>
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?

-a


Article: 87398
Subject: Re: All of the design is being optimized away and logic removed
From: "azam" <azamirfan@gmail.com>
Date: 22 Jul 2005 10:24:02 -0700
Links: << >>  << T >>  << A >>
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
Subject: parallel optic availability
From: Tullio Grassi <tgrassi@mail.cern.ch>
Date: Fri, 22 Jul 2005 21:07:48 +0200
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search