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
2017JanFebMarApr2017

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 24925

Article: 24925
Subject: Re: Some notes on metastability
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 22 Aug 2000 14:12:28 GMT
Links: << >>  << T >>  << A >>
Well, I think by now all smart designers ( that's us...) are convinced
of the
inevitability ( like death and taxes ) of metastable events, usually
just 
delaying. The difficulty is measuring them and thus providing
quantitative, useful
information. It seems to me that, over the past few years, the
improvement in the
speed at which flip-flops resolve metastable events has outstripped our
( at least
my ) ability to measure it, to derive quantitative ( albeit statistical )
guidance.
That's the bad news of the recent past.

Now the good news:
I have high hope (almost confidence) that, within a few months, I will
have access
to chips that allow me again to measure metastable delays easily, and
thus re-issue the
old exponential graphs with fresh data.
Let's hope by Xmas...

Peter Alfke, Xilinx Applications
============================
Philip Freidin wrote:

> This is an informational (I hope) posting, hopefully giving some additional
> insight to the behavior of metastables.
>
> The following is an edited version of some of my postings to
> sci.electronics.design, during May of 2000.
>

snip. Thank you Phil.
Article: 24926
Subject: Re: Some notes on metastability
From: rk <stellare@nospamplease.erols.com>
Date: Tue, 22 Aug 2000 10:17:47 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:

previous author wrote:

> > The topic of designing circuits for dealing with metastability is a very
> > well researched area. The now widely held belief is that it is impossible
> > to design such a circuit. Indeed, ALL claimed metastable free circuits
> > have been proven not to be. Usually the only thing achieved by complex
> > circuits that try and deal with all sorts of special cases, is that they
> > obscure the metastable mode during analysis. The best way to deal with
> > the metastable problem (the synchronization of an asynchronous signal
> > feeding into and affecting a synchronous system) is to synchronize the
> > signal with a multi stage synchronizer, comprizing of no more than 2 or
> > more flipflops, connected as a shift register, and clocked by the clock
> > of the destination domain.

I would suggest that the best way to deal with the problem is to first try to
change the system design.  It is surprising how many system "designs" are done
a bit haphazardly by piecing things together.  In many cases, asynchronous
signals can be made synchronous by changing the design.  While this is, of
course, simple and obvious, it is often not done.  Synchronizers and various
kludges are added which, along with complicating things, can hurt performance.

There are also other techniques that work quite well.  Consider, for example, a
set of counters that count external events (pulses) which by nature are
asynchronous.  The counters needed to be sampled periodically and stored for
later analysis.  Should the pulses all be latched and then synchronized and
then fed into the circuits?  This can be impractical if the pulse-pair
resolution is small and you don't want to miss any - remember what the curve
looks like for probability of interarrival times of random events.  Another
approach is to run individual counters clocked by the external event and
asynchronous to the basic sychronous system and then asynchronously sample the
counters' output, periodically, using a gray code scheme.

rk

Article: 24927
Subject: Chipscope problem
From: Daixun <daixun.zheng@ee.surrey.ac.uk>
Date: Tue, 22 Aug 2000 07:32:53 -0700
Links: << >>  << T >>  << A >>
I wonder if anyone can help me solve my problem. 

I am trying the Demo program of Chipscope. But I got the problem when I want to set up Trigger. The error message is "ILA Unit communication Failed" 

The following is the situation: 

Software: Chipscope Hardware: Multilinx Prototyping board Connection Mode: Slave serial mode Target Device: Virtex-800hq240 

The steps: 

1. Regenerate the MCS file of V800hq240 for Slave-serial mode. 
2. Connect the Multilinx cable with the board through Slave-serial mode.
3. Run chipscope, create the project 
4. open the serial communication port,Baudrate is auto. 
5. Setting up Boundary scan chain to 'One target device, alone in the chain' 
6. Configuring device to slave-serial mode and download MCS file to V800 FPGA. The DONE status appears at the lower right corner of the window. 

7.(At this step, I got error message) Then I set up trigger, select data>trigger setup. The message 'Init cable for JTAG' is displayed. At last, I got 'ILA Unit communication Failed' 

Thanks! 

Daixun
Article: 24928
Subject: Re: Mealy vs Moore FSM model
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Tue, 22 Aug 2000 07:52:44 -0700
Links: << >>  << T >>  << A >>
Hi - 

The way I remember the distinction:

 - Moore: outputs are a function of current state
 - Mealy: outputs are a function of current state and inputs

In other words, Moore is Less :-)

I like Moore FSMs, and also like the idea of including outputs in the
state vector.  But what I do is a bit different.  If an output is
supposed to be HIGH during states FRED and WILMA, I generate a signal
whenever the next state is going to be either FRED or WILMA, and pass
that signal through a flip-flop.  Strictly speaking, the output isn't
part of the state vector, but the result is the same: either way,
outputs occur concurrent with the change of state, without additional
state decode delay or decoder glitches.  Not that designers of
synchronous systems care about decoder glitches...

Mealy machines are useful, too.  Sometimes a state machine has to
respond to an input by asserting an output signal in the same cycle,
and Mealy is more or less mandated.  

Take care,
Bob Perlman


On Tue, 22 Aug 2000 08:57:09 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

>Lars Rzymianowicz wrote:
>> 
>> Jimmy Roberts wrote:
>> > What are the advantages and disadvantages of using Mealy model of FSMs vs
>> > Moore model, on FPGA.
>> > In Mealy model, the outputs depends on the states only, whereas in Moore
>> > model, the outputs depend on the states and the actual inputs. I presume
>> > Mealy model is better (less combinatorial logic). Do you agree? Any other
>> > thoughts.
>> 
>> It's the other way 'round. Outputs in Moore are dependent on the state,
>> in Mealy on the state and inputs.
>> So with Mealy, you can get glitches, etc., if your inputs arrive at
>> different times (or stabilize very late). And you have more logic. But
>> you can react within the present clk cycle.
>> With Moore, you avoid glitches, but still have an output delay due to
>> the output logic.
>> One step further is, what we call Simple-Moore. Use a user-defined state
>> encoding and include the outputs in the state vector. Then you have a Moore
>> machine with only clk-to-output delay, the fastest version you can get.
>
>Thanks, I never remember which name is which. But I would dispute your
>claim that the Moore (outputs depend on the state only) is
>"glitch-free". The glitches in this machine come from the state
>variables switching at the same time. So you not only get delay, you get
>glitches. 
>
>The Mealy machine (outputs depend on inputs and state) can be made to be
>glitch free. This depends on how you interpret the machine. I don't
>think many people really need a machine whose output changes
>asynchronously with the input, but really want a clock synchronized
>output. In this case the Mealy machine uses FFs to store the outputs
>that correspond to the state transitions. These outputs are remembered
>until the next clock. This will be a truly "glitch-free" output. 
>
>The way I learned it is that the Moore machine outputs depend on the
>states, the Mealy machine outputs depend on the transitions. 

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 24929
Subject: Re: Fully constrained designs...
From: beerbaron@my-deja.com
Date: Tue, 22 Aug 2000 15:25:07 GMT
Links: << >>  << T >>  << A >>
Shouldn't the router be smart enough to know that these 'static'
signals etc. are static and they have a lot of 'slack' with respect to
the clock?  Is this just a fundamentally very difficult problem to
solve, or do current routers just not do it well, or does it just take
them a long time?




In article <01c00960$4f9fb170$6905f7a5@drt1>,
  "Austin Franklin" <austin@darkroom65.com> wrote:
> Means the same thing to me too, Bob.  Well put.
>
> Constraining the non-critical paths (like multi-cycle paths,
or 'static'
> signals, like a writeable register) will help routing, as the router
will
> know how hard it has to try on each net.
>
> The other advantage of doing complete constraints is you do not need
to do
> timed simulation.  Providing your constraints are correct, and your
design
> meets this timing, your functional simulation will give you all the
> simulation you need.
>
> When constraining every net, you can group them, if you have one
module
> that every input or output to/from it have the same time spec, or
every one
> internal to that module, you can use a wild-card timing constraint
like
> FROM:FFS(FRED*):TO:FFS(FRED*) and that will constrain everything in
that
> block  to that TIMESPEC.  Or, FROM:FFS(FRED*):TO:FFS(*)...etc.
>
> Yet another advantage, is you readily know what didn't make timing...
>
> Bob Perlman <bobperl@best_no_spam_thanks.com> wrote in article
> <fd5rps013bckun9rkjbpaobn976vq210ut@4ax.com>...
> > On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote:
> >
> > >Hi,
> > >
> > >I've been working a couple of designs and have heard that "your
design
> > >really should be fully contrained" to acheive the best results.
Can
> > >someone give me a good definition of what fully constrained
means?  Are
> > >they implying that I should provide timing contraints for every
net in
> > >my design?
> > >
> >
> > Hi -
> >
> > That's what it means to me: every path, "critical" or not, is
covered
> > by a timing constraint.  In the Xilinx world, it means that, when
you
> > run trce (the static timing analyzer) with the -u option, it reports
> > no unconstrained paths.
> >
> > Why would anyone bother constraining paths that are completely
> > non-critical?  The idea is to avoid the embarrassing situation where
> > you overlook a single report of a path that doesn't meet timing
> > because it's buried amidst hundreds or thousands of reports of
> > unconstrained paths that don't matter.  Constraining all paths also
> > eliminates the possibility of the router creating a very, very long
> > delay on a path where just a long delay would have been OK.
> >
> > Constraining all paths can be something of a pain in the butt, but
> > it's not as bad as it sounds.  You can often place constraints on
> > large sets of paths, rather than on individual paths.
> >
> > Take care,
> > Bob Perlman
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24930
Subject: Re: Non-disclosures in job interviews, Round One
From: Neil Nelson <n_nelson@pacbell.net>
Date: Tue, 22 Aug 2000 08:27:01 -0700
Links: << >>  << T >>  << A >>

Jon Kirwin,

Your plan of action seems to be a recommendation that in the
case where a company requests written agreement to an NDA at
the interview that we do not take the interview.

After having identified a primary objective and an initial
solution path, frequently we find that the identified solution
path is too weak in the likelihood of reaching the objective
or is against other desirable objectives such that we lose
elsewhere in making an advance here--we rob Peter to pay Paul.
This was a thrust of my prior post.

But fortunately a single objective can be usually obtained in
a variety of ways such that we can search the different solution
paths to maximize the likelihood and efficiency of reaching the
objective while minimizing, say, collateral damage.

For example,

Darin Johnson wrote:

> I had one interview where I actually had to sign a form, before going
> in, saying I would waive my rights under a California labor law
> (something about ability to sue when terminated).  Being desperate, I
> did it anyway.  But I don't know if it was a sign of how the company
> was going to operate in the future, or if it was a normal company that
> happened to have an over-zealous lawyer.

Rickman was saying ``Company A'', Darin Johnson is saying ``one interview''
and you were not clear as to which company you had a legal issue with.
Here we are somehow against NDAs while exhibiting a non-disclosure pattern
of behavior that in one sense is against our objective.  I.e., if we let
everyone know who these companies are who are behaving in a manner we
feel is objectionable _and_ these companies knew their behavior was
being made widely known, we may have a more desirable solution path.

But what other solution paths come to mind?  I have a few in mind but I
expect more minds would get us more and better solutions.  With each of
these alternate solution paths we will have a schedule of desirables and
undesirables that need to be considered.  E.g., if I was inclined to
speak publicly and effectively against specific large companies, and
though my speech was truthful and fair, I might think that legal action
by a large company against a small individual would disuade me from
speaking up.  Their pockets are large and mine are small such that I
might be made financially destitute even if I win the case while the
company would just bury the costs under miscellaneous expenses.  Or I
might be blacklisted somehow as a general troublemaker and be unable to
obtain good employment.

I am not saying that the prior undesirables should or should not be
given serious weight, but it is better to account for and avoid risks
before you find yourself in the middle of one.  Can we reasonably
avoid the indicated risks?  Is it better to know who the primary source
is for some particular information?  Otherwise we may be inclined to
value such information with less credibility.  However, it is better to
have some less credible information as against none at all, and there
are ways to achieve that.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
  <head>
    <title>Anonymous Remailers</title>
  </head>

  <body bgcolor=ffffff>
    <h1>Anonymous Remailers</h1>

    An anonymous remailer (also called an "anonymous server") is a
    free computer service that privatizes your e-mail. A remailer
    allows you to send electronic mail to a Usenet news group or to a
    person without the recipient knowing your name or your e-mail
    address.
    <p></p>

    <a href="http://www.anonymizer.com/">Anonymizer.com -- Privacy is
      Your Right</a>
    <p></p>

    <a href="http://www.gilc.org/speech/anonymous/remailer.html">
      W3- ANONYMOUS REMAILER</a>
    <p></p>

    <a href="http://www.publius.net/rlist.html">Remailer list</a>
    <p></p>

    <a href="http://www.publius.net/n.a.n.html">nym.alias.net, a
      second generation nymserver</a>
    <p></p>
    <a href="http://www.publius.net/n.a.n.help.html">Help for
      nym.alias.net</a>
    <p></p>

    <a href="http://www.andrebacard.com/remail.html">Anonymous
      Remailer FAQ</a>
    <p></p>

    <a href="http://anon.efga.org/Remailers">Brought to you by
      Electronic Frontiers Georgia </a>
    <p></p>

    <a href="http://www.obscura.com/~loki/index.cgi">Lance Cottrell's
      home page</a>, which has his Chain script, and the Mixmaster
    remailer client<br>
    <a HREF="http://www.obscura.com/~loki/remailer-essay.html">
      Possible Mixmaster and Remailer Attacks</a>
    <p></p>

    <a href="http://security.tao.ca/www.html">Web Based Anonymous
      Remailer Interfaces</a>
    <p></p>

    <a href="http://www.angelfire.com/biz/teachkorea/remailer.html">
      Anonymous Remailer</a><br>
    No longer working. Depended on replay.
    <p></p>

    <a
href="http://www.whatreallyhappened.com/RANCHO/CRASH/TWA/WANTED/wanted.html">

TWA Flight 800: EYEWITNESS STATEMENTS TO POLICE</a>
    <p></p>

    <hr>
    <address><a href="mailto:shrdlu@deaddrop.org">Etaoin
Shrdlu</a></address>
<!-- Created: Thu Jul 20 22:59:01 PDT 2000 -->
<!-- hhmts start -->
Last modified: Sat Jul 22 08:14:51 PDT 2000
<!-- hhmts end -->
  </body>
</html>

Regards,

Neil Nelson


Article: 24931
Subject: Re: Mealy vs Moore FSM model
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Tue, 22 Aug 2000 16:14:35 GMT
Links: << >>  << T >>  << A >>

"Jimmy Roberts" <j_robby@hotmail.com> wrote in message
news:8nu195$k8$1@news.qub.ac.uk...
> > It's the other way 'round. Outputs in Moore are dependent on the state,
> > in Mealy on the state and inputs.
>
> You are right, I always call it the other way round.
>
> > One step further is, what we call Simple-Moore. Use a user-defined state
> > encoding and include the outputs in the state vector. Then you have a
> Moore
> > machine with only clk-to-output delay, the fastest version you can get.
>
> Is it always possible to encode the states so that the outputs are in the
> state vector?
> I do not think so...

--You are correct, especially if you are using one-hot!
-Simon Ramirez, Consultant
 Synchronous Design


Article: 24932
Subject: Re: Mealy vs Moore FSM model
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Tue, 22 Aug 2000 09:43:03 -0700
Links: << >>  << T >>  << A >>
Hi - 

It's true that if you place outputs in the state vector of an
otherwise one-hot FSM, the state vector is no longer one-hot.  But
this is a semantic difficulty, not an implementation barrier.

If you are designing an FSM whose outputs are strictly a function of
state, one-hot or otherwise, you should be able to encode the outputs
in the state vector.  Instead of decoding the output from the current
state, you decode it from the next state, and register the decoded
signal.

In other words, if you're designing a Moore FSM, placing outputs in
the state vector shouldn't be a problem, at least logically.  (Timing
may be another matter, but we all know how unimportant that is. :-) )

Bob Perlman


On Tue, 22 Aug 2000 16:14:35 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
wrote:

>
>"Jimmy Roberts" <j_robby@hotmail.com> wrote in message
>news:8nu195$k8$1@news.qub.ac.uk...
>> > It's the other way 'round. Outputs in Moore are dependent on the state,
>> > in Mealy on the state and inputs.
>>
>> You are right, I always call it the other way round.
>>
>> > One step further is, what we call Simple-Moore. Use a user-defined state
>> > encoding and include the outputs in the state vector. Then you have a
>> Moore
>> > machine with only clk-to-output delay, the fastest version you can get.
>>
>> Is it always possible to encode the states so that the outputs are in the
>> state vector?
>> I do not think so...
>
>--You are correct, especially if you are using one-hot!
>-Simon Ramirez, Consultant
> Synchronous Design
>

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 24933
Subject: Re: Permanently programming FPGAs
From: rk <stellare@nospamplease.erols.com>
Date: Tue, 22 Aug 2000 13:13:39 -0400
Links: << >>  << T >>  << A >>
Phil Hays wrote:

> Elftmann wrote:
>
> > Good designers that follow a disciplined design flow have no problem using
> > Antifuse based FPGAs.
>
> It's hard to follow a disciplined design flow when you have two different
> specifications (and both are incomplete!) for the same function, and both are
> different from what the programmers claim the function does.  I had this joyful
> task as part of my first FPGA design.  We were designing a replacement for
> hardware designed in 1969.
>
> The ability to upgrade both hardware and software without opening the box also
> can be very useful.
>
> I think that EEPROM, antifuse and SRAM based programable parts all have
> advantages, and I expect that all of them will be around for quite a while.

I have to say I like the concept of the non-volatile, reprogrammable, single chip,
"instant-on" type of device.

I agree that all different types will be kicking around for a while; Xilinx,
Altera, Actel, Quicklogic have all been around for a few years and I haven't heard
rumors that any of the them are close to closing up shop.

One thing that is "bad" about programmable logic is sort of that it lets the people
required to generate requirements and specifications off of the hook since it's
relatively painless, in their eyes, to just either plunk down a new chip (antifuse,
OTP SPROM) or upload some code (EEPROM, SRAM with reprogrammable configuration
memory [perhaps on a hard disk]).  Twenty years ago, changes would require hacking
up boards or spinning more PCB's; now it's just a software upload.  Putting some
PAIN into the process can, I believe, help with the requirements and
specifications.  :-)

I don't think the cost of prototype parts is a major issue, independent of the
technology, for many jobs.  For large volume runs, it's generally a non-issue.  For
low volume custom jobs, it is often a relatively small percentage of the cost for
development.  If it's a small programmable, then the cost is generally trivial.  If
it's a large one, then at the cost of designers it still won't be a killer.  I
think the largest antifuse device is a few hundred bucks or so, commercial, so
tossing a few for some changes in specifications or design errors just ain't that
bad (and that's in ceramic packages).  For low-volume, hi-rel devices (military and
aerospace), along with the arguments above, the cost of the target parts is
typically two orders of magnitude difference in price, if package compatibility is
not a major issue.  Otherwise, it's about an order of magnitude difference or so.

I think the device's characteristics and available tools and IP for the particular
application is more of a driver.

rk



Article: 24934
Subject: Re: Fully constrained designs...
From: "Austin Franklin" <austin@darkroom65.com>
Date: 22 Aug 2000 17:30:57 GMT
Links: << >>  << T >>  << A >>
How does the router know a register isn't changing every clock cycle?

This isn't difficult, it just takes time, as do most 'engineered' things,
in order to do them right.  You just have to clearly, and accurately,
timespec your design...the only one who knows how your design is supposed
to work is you, the tools can't (for the most part) guess at what paths are
multi-cycle...

It does take time up front to do this, but trust me, it saves you a LOT of
time in the long run.  Also, taking the time to engineer an optimal pinout
up front saves a LOT of time in the long run too...


beerbaron@my-deja.com wrote in article <8nu5vq$k65$1@nnrp1.deja.com>...
> Shouldn't the router be smart enough to know that these 'static'
> signals etc. are static and they have a lot of 'slack' with respect to
> the clock?  Is this just a fundamentally very difficult problem to
> solve, or do current routers just not do it well, or does it just take
> them a long time?
> 
> 
> 
> 
> In article <01c00960$4f9fb170$6905f7a5@drt1>,
>   "Austin Franklin" <austin@darkroom65.com> wrote:
> > Means the same thing to me too, Bob.  Well put.
> >
> > Constraining the non-critical paths (like multi-cycle paths,
> or 'static'
> > signals, like a writeable register) will help routing, as the router
> will
> > know how hard it has to try on each net.
> >
> > The other advantage of doing complete constraints is you do not need
> to do
> > timed simulation.  Providing your constraints are correct, and your
> design
> > meets this timing, your functional simulation will give you all the
> > simulation you need.
> >
> > When constraining every net, you can group them, if you have one
> module
> > that every input or output to/from it have the same time spec, or
> every one
> > internal to that module, you can use a wild-card timing constraint
> like
> > FROM:FFS(FRED*):TO:FFS(FRED*) and that will constrain everything in
> that
> > block  to that TIMESPEC.  Or, FROM:FFS(FRED*):TO:FFS(*)...etc.
> >
> > Yet another advantage, is you readily know what didn't make timing...
> >
> > Bob Perlman <bobperl@best_no_spam_thanks.com> wrote in article
> > <fd5rps013bckun9rkjbpaobn976vq210ut@4ax.com>...
> > > On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote:
> > >
> > > >Hi,
> > > >
> > > >I've been working a couple of designs and have heard that "your
> design
> > > >really should be fully contrained" to acheive the best results.
> Can
> > > >someone give me a good definition of what fully constrained
> means?  Are
> > > >they implying that I should provide timing contraints for every
> net in
> > > >my design?
> > > >
> > >
> > > Hi -
> > >
> > > That's what it means to me: every path, "critical" or not, is
> covered
> > > by a timing constraint.  In the Xilinx world, it means that, when
> you
> > > run trce (the static timing analyzer) with the -u option, it reports
> > > no unconstrained paths.
> > >
> > > Why would anyone bother constraining paths that are completely
> > > non-critical?  The idea is to avoid the embarrassing situation where
> > > you overlook a single report of a path that doesn't meet timing
> > > because it's buried amidst hundreds or thousands of reports of
> > > unconstrained paths that don't matter.  Constraining all paths also
> > > eliminates the possibility of the router creating a very, very long
> > > delay on a path where just a long delay would have been OK.
> > >
> > > Constraining all paths can be something of a pain in the butt, but
> > > it's not as bad as it sounds.  You can often place constraints on
> > > large sets of paths, rather than on individual paths.
> > >
> > > Take care,
> > > Bob Perlman
> >
> >
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> 
Article: 24935
Subject: Re: Mealy vs Moore FSM model
From: steve (Steve Rencontre)
Date: Tue, 22 Aug 2000 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <8ntagh$nvq@src-news.pa.dec.com>, murray@pa.dec.com (Hal 
Murray) wrote:

> 
> I'm missing the big picture.  Why do I care which type of FSM I use?
> 
> I normally lump the state and output bits together.  If an output
> signal happens to be useful as a state bit, then I use it.  This
> is fairly common in one-hot state machines.
> 
> Is there something wrong with doing that?

I agree with you. I've never really seen the value of the Mealy/Moore 
distinction anyway. Perhaps it makes sense from an analysis POV, but not 
when designing.

> I'm usually working with small state machines.  Does that matter?

I don't see why. 

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24936
Subject: Re: Leonardo Spectrum with Altera - am I being stupid???
From: steve (Steve Rencontre)
Date: Tue, 22 Aug 2000 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <8ntdn8$pmt$11$1@news.t-online.com>, 
ernst.zwingenberger@elca.de (Ernst Zwingenberger) wrote:

> Hi steve,
> 
> you may receive this error if you have not chosen Exemplar as the
> third-party vendor in the MAX+PLUS II software or if your Library
> Mapping File (.lmf) is set incorrectly in the MAX+PLUS II Compiler.
> [...]

Thanks to you and others who've pointed it out to me. I now find that it 
is documented but I guess I missed it first time through. 

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>

Article: 24937
Subject: Re: Mealy vs Moore FSM model
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 22 Aug 2000 10:51:14 -0700
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> I'm missing the big picture.  Why do I care which type of FSM I use?

I don't think it matters one bit to engineers.

It is digital design history that lives on 
only through textbooks and fuzzy app. notes.

If everything is synched up and simulates
like you expect, you don't have to categorized it. 

> I normally lump the state and output bits together.  If an output
> signal happens to be useful as a state bit, then I use it.  This
> is fairly common in one-hot state machines.
> Is there something wrong with doing that?

No. Might complicate design changes slightly.

> I'm usually working with small state machines.  Does that matter?

For small machines, using state bits as outputs is reasonable.

For complex machines, the state assignments become difficult
using that method. In this case I use variables for state
information and update output signals at the end of the clocked process.
The simulator is pretty smart and rarely wastes a flop.


--    mike.treseler@flukenetworks.com or
--             tres@tc.fluke.com
Article: 24938
Subject: Re: Permanently programming FPGAs
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 22 Aug 2000 11:34:50 -0700
Links: << >>  << T >>  << A >>


rk wrote:

> I don't think the cost of prototype parts is a major issue, independent of the
> technology, for many jobs.

Yes, but the pain of unsoldering and re-soldering BGA parts is.
And isn't it nice to be able to change something on-the-fly, even in a complete
system.

But these arguments have been made over and over again,
and many of us have an obvious axe to grind.
(That includes me.)

Peter Alfke


Article: 24939
Subject: Re: Mealy vs Moore FSM model
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Tue, 22 Aug 2000 18:38:48 GMT
Links: << >>  << T >>  << A >>

"Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message
news:9ja5qscmb7f13cojsonuq6an9v6e8mg5cb@4ax.com...
> Hi -
>
> It's true that if you place outputs in the state vector of an
> otherwise one-hot FSM, the state vector is no longer one-hot.  But
> this is a semantic difficulty, not an implementation barrier.

     Bob, this "is" an implementation barrier because one cannot have a one
hot design AND outputs that are 1 for more than one state.  Therefore, the
"outputs in a state vector" technique of a Moore FSM is not really
compatible with one-hot encoding.  There are reasons for one-hot encoding,
and it and the "outputs in a state vector" technique to do not jive well.

> If you are designing an FSM whose outputs are strictly a function of
> state, one-hot or otherwise, you should be able to encode the outputs
> in the state vector.  Instead of decoding the output from the current
> state, you decode it from the next state, and register the decoded
> signal.
>
> In other words, if you're designing a Moore FSM, placing outputs in
> the state vector shouldn't be a problem, at least logically.  (Timing
> may be another matter, but we all know how unimportant that is. :-) )

     It seems to me that "placing outputs in the state vector" would not be
a problem logically if 1)one-hot encoding is not used, and 2) it will route.
Timing should not be a problem, because by definition, the outputs are bits
of the state vector, which are register outputs, i.e., minimal clock to out
times.
     I knew an engineer who used the "outputs in the state vector" once upon
a time.  After he did the design, he had to make a design change.  This
change caused routing problems, because by changing the output vector, he
was also inadvertently changing the state vector and vice-versa.  These
changes did not go well in the FPGA, which was quite filled.  We switched
the design over to one hot and used the "outputs decoded in parallel
registers" technique (of a Moore FSM design) that rickman so very much
loves, and it solved the problem.  It's weird that using more registers
solved the problem, but it uses less combinatorial logic to determine next
states and next outputs.
     I myself am a proponent of the Moore FSM "outputs decoded in parallel
registers" design technique.  Not only does it separate the state vector
from the output vector, but it also generates glitch free minimal clock to
out timed signals.  Separating the state vector from the output vector
simplifies maintenance in a device that is essentially register rich (FPGA).
     There is a good write-up of Moore and Mealy FSMs, along with the
different design techniques like what I mentioned above, and their pros and
cons, in "VHDL for Programmable logic" by Kevin Skahill of Cypress
Semiconductor.  I used to help teach that class, and the book was handed out
for free.  (Note: I was not an employee of Cypress!)  Although Cypress has
not kept up with the other FPGA/CPLD vendors, they did start out quite
strong, and this book was one of their crown jewels, in my opinion.

--Simon Ramirez, Consultant
--Synchronous Design, Inc.

> Bob Perlman


Article: 24940
Subject: Re: Looks like Xilinx is at it again!
From: Anna Acevedo <acevedo@xilinx.com>
Date: Tue, 22 Aug 2000 12:09:51 -0700
Links: << >>  << T >>  << A >>
You are under current maintenance and should receive the 3.1i software upgrade.
Customer service is looking into why you do not have your upgrade and will get one
out to you asap.  If you do not hear from customer service or receive your upgrade
by the end of next week please contact the Xilinx University Program at  xup@xilinx.com


apeters@noao.edu wrote:

> On Mon, 21 Aug 2000 16:58:34 GMT, Ray Andraka <ray@andraka.com> wrote:
> > Hey folks, has anyone tried to get support from xilinx lately for 3.1?  They've
> > now got a web page you have to log into to get support.  All well and good if it
> > worked I suppose.  Thing is I've registered several times now.  For registering
> > you get an autogenerated note back saying it will take a day to grant access to
> > websupport.  THing is even after two weeks it still gives you the new
> > registration page when you log in (frustrating part is it fills in all the
> > blanks except the registration code, so I'm already there in the data base).
> > Used to be you could submit a case directly without this crap.  No more though.
> > Now we have to waste more time dealing with stupidity to get legitimate issues
> > on registered and licensed software resolved.  I suppose this is par for the
> > course in the trend to make the tools and support more customer unfriendly.
> > Whoever came up with this farce ought to be taken out back and shot.
>
> Oh, Ray, stop complainin'!  At least they sent you the software. ;)
>
> I just got the maint. renewal form.  Maybe they're waiting for me to renew for NEXT
> year before sending me what they owe me for THIS year?
>
> Apparently you've got to register before you can download the 3.1 service packs (up
> to #2 already, and I still don't have the software).  What's annoying is that I've
> already registered.  Maybe they should figure out how to get their databases to talk
> to each other.  You know, like the database that says, "This guy's paid his maint.
> for this year -- maybe we should send him his software."
>
> -andy
> --
> ---------------------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatory
> 950 N. Cherry Ave
> Tucson, AZ 85719
> 520-318-8191
> apeters@noao.edu

--
*****************************
Anna M. Acevedo
Xilinx University Program
2100 Logic Drive
San Jose, CA 95124
PH: (408) 879-5338
FAX: (408) 879-4780

Email: anna.acevedo@xilinx.com
http://www.xilinx.com/programs/univ.htm
*****************************


Article: 24941
Subject: Re: Mealy vs Moore FSM model
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Tue, 22 Aug 2000 13:11:32 -0700
Links: << >>  << T >>  << A >>
Hi - 

I'd like to respond, but the fact of the matter is that I no longer
have any idea what we're arguing about.

Bob Perlman


On Tue, 22 Aug 2000 18:38:48 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
wrote:

>
>"Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message
>news:9ja5qscmb7f13cojsonuq6an9v6e8mg5cb@4ax.com...
>> Hi -
>>
>> It's true that if you place outputs in the state vector of an
>> otherwise one-hot FSM, the state vector is no longer one-hot.  But
>> this is a semantic difficulty, not an implementation barrier.
>
>     Bob, this "is" an implementation barrier because one cannot have a one
>hot design AND outputs that are 1 for more than one state.  Therefore, the
>"outputs in a state vector" technique of a Moore FSM is not really
>compatible with one-hot encoding.  There are reasons for one-hot encoding,
>and it and the "outputs in a state vector" technique to do not jive well.
>
>> If you are designing an FSM whose outputs are strictly a function of
>> state, one-hot or otherwise, you should be able to encode the outputs
>> in the state vector.  Instead of decoding the output from the current
>> state, you decode it from the next state, and register the decoded
>> signal.
>>
>> In other words, if you're designing a Moore FSM, placing outputs in
>> the state vector shouldn't be a problem, at least logically.  (Timing
>> may be another matter, but we all know how unimportant that is. :-) )
>
>     It seems to me that "placing outputs in the state vector" would not be
>a problem logically if 1)one-hot encoding is not used, and 2) it will route.
>Timing should not be a problem, because by definition, the outputs are bits
>of the state vector, which are register outputs, i.e., minimal clock to out
>times.
>     I knew an engineer who used the "outputs in the state vector" once upon
>a time.  After he did the design, he had to make a design change.  This
>change caused routing problems, because by changing the output vector, he
>was also inadvertently changing the state vector and vice-versa.  These
>changes did not go well in the FPGA, which was quite filled.  We switched
>the design over to one hot and used the "outputs decoded in parallel
>registers" technique (of a Moore FSM design) that rickman so very much
>loves, and it solved the problem.  It's weird that using more registers
>solved the problem, but it uses less combinatorial logic to determine next
>states and next outputs.
>     I myself am a proponent of the Moore FSM "outputs decoded in parallel
>registers" design technique.  Not only does it separate the state vector
>from the output vector, but it also generates glitch free minimal clock to
>out timed signals.  Separating the state vector from the output vector
>simplifies maintenance in a device that is essentially register rich (FPGA).
>     There is a good write-up of Moore and Mealy FSMs, along with the
>different design techniques like what I mentioned above, and their pros and
>cons, in "VHDL for Programmable logic" by Kevin Skahill of Cypress
>Semiconductor.  I used to help teach that class, and the book was handed out
>for free.  (Note: I was not an employee of Cypress!)  Although Cypress has
>not kept up with the other FPGA/CPLD vendors, they did start out quite
>strong, and this book was one of their crown jewels, in my opinion.
>
>--Simon Ramirez, Consultant
>--Synchronous Design, Inc.
>
>> Bob Perlman
>

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.cambriandesign.com
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 24942
Subject: Re: Fully constrained designs...
From: "Austin Franklin" <austin@darkroom65.com>
Date: 22 Aug 2000 21:08:33 GMT
Links: << >>  << T >>  << A >>

> Mind you you have to watch for circular problems.
> If you are trying to evaluate several designs for gross timing,
> how do know the optimal layout to get the timing right
> to time the layouts?

My designs flow through, and my pinouts reflect this, as well as my
architecture.  Perhaps I'm not quite clear what you are saying...  Would
you mind elaborating with an example?


Article: 24943
Subject: Re: Mealy vs Moore FSM model
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Tue, 22 Aug 2000 21:45:11 GMT
Links: << >>  << T >>  << A >>
That's okay, Bob, I get into those "states" too!
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


"Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message
news:7fn5qsk0av5ihhm6it4nft81kpu0d4rnbq@4ax.com...
> Hi -
>
> I'd like to respond, but the fact of the matter is that I no longer
> have any idea what we're arguing about.
>
> Bob Perlman
>
>
> On Tue, 22 Aug 2000 18:38:48 GMT, "S. Ramirez" <sramirez@cfl.rr.com>
> wrote:
>
> >
> >"Bob Perlman" <bobperl@best_no_spam_thanks.com> wrote in message
> >news:9ja5qscmb7f13cojsonuq6an9v6e8mg5cb@4ax.com...
> >> Hi -
> >>
> >> It's true that if you place outputs in the state vector of an
> >> otherwise one-hot FSM, the state vector is no longer one-hot.  But
> >> this is a semantic difficulty, not an implementation barrier.
> >
> >     Bob, this "is" an implementation barrier because one cannot have a
one
> >hot design AND outputs that are 1 for more than one state.  Therefore,
the
> >"outputs in a state vector" technique of a Moore FSM is not really
> >compatible with one-hot encoding.  There are reasons for one-hot
encoding,
> >and it and the "outputs in a state vector" technique to do not jive well.
> >
> >> If you are designing an FSM whose outputs are strictly a function of
> >> state, one-hot or otherwise, you should be able to encode the outputs
> >> in the state vector.  Instead of decoding the output from the current
> >> state, you decode it from the next state, and register the decoded
> >> signal.
> >>
> >> In other words, if you're designing a Moore FSM, placing outputs in
> >> the state vector shouldn't be a problem, at least logically.  (Timing
> >> may be another matter, but we all know how unimportant that is. :-) )
> >
> >     It seems to me that "placing outputs in the state vector" would not
be
> >a problem logically if 1)one-hot encoding is not used, and 2) it will
route.
> >Timing should not be a problem, because by definition, the outputs are
bits
> >of the state vector, which are register outputs, i.e., minimal clock to
out
> >times.
> >     I knew an engineer who used the "outputs in the state vector" once
upon
> >a time.  After he did the design, he had to make a design change.  This
> >change caused routing problems, because by changing the output vector, he
> >was also inadvertently changing the state vector and vice-versa.  These
> >changes did not go well in the FPGA, which was quite filled.  We switched
> >the design over to one hot and used the "outputs decoded in parallel
> >registers" technique (of a Moore FSM design) that rickman so very much
> >loves, and it solved the problem.  It's weird that using more registers
> >solved the problem, but it uses less combinatorial logic to determine
next
> >states and next outputs.
> >     I myself am a proponent of the Moore FSM "outputs decoded in
parallel
> >registers" design technique.  Not only does it separate the state vector
> >from the output vector, but it also generates glitch free minimal clock
to
> >out timed signals.  Separating the state vector from the output vector
> >simplifies maintenance in a device that is essentially register rich
(FPGA).
> >     There is a good write-up of Moore and Mealy FSMs, along with the
> >different design techniques like what I mentioned above, and their pros
and
> >cons, in "VHDL for Programmable logic" by Kevin Skahill of Cypress
> >Semiconductor.  I used to help teach that class, and the book was handed
out
> >for free.  (Note: I was not an employee of Cypress!)  Although Cypress
has
> >not kept up with the other FPGA/CPLD vendors, they did start out quite
> >strong, and this book was one of their crown jewels, in my opinion.
> >
> >--Simon Ramirez, Consultant
> >--Synchronous Design, Inc.
> >
> >> Bob Perlman
> >
>
> -----------------------------------------------------
> Bob Perlman
> Cambrian Design Works
> Digital Design, Signal Integrity
> http://www.cambriandesign.com
> Send e-mail replies to best<dot>com, username bobperl
> -----------------------------------------------------
>


Article: 24944
Subject: Re: Looks like Xilinx is at it again!
From: "Robert Sturm" <sxc_feedback@xilinx.com>
Date: Tue, 22 Aug 2000 15:32:13 -0700
Links: << >>  << T >>  << A >>
Hi all-

I'd like to apologize for the registration problems some of you were experiencing with our online case management tool on support.xilinx.com.  We manually review each and every access request to WebSupport before granting a customer clearance to this utility.  Security is a big concern for many of our customers and we want to do everything in our power to protect the intellectual property of our users.  

Recently, a spike in the number of WebSupport requests has delayed the processing of a typical submission.  We've added a few resources to address this deludge and turnaround times should be greatly reduced within a few business days.  Please note that users who try to login before their request has been approved will be redirected back to the registration page.  Undoubtedly, this was what was happening in Ray's situation.   Users who have been granted access will receive an email notification that they can start using the tool.

We've deployed WebSupport to help you become more productive.  This utility allows you to add notes, track changes, and manage cases without picking up the phone.  Please don't hesitate to let us know how we can make you more efficient.

Thanks for your patience.

Robert Sturm
support.xilinx.com
Article: 24945
Subject: Re: Looks like Xilinx is at it again!
From: Ray Andraka <ray@andraka.com>
Date: Wed, 23 Aug 2000 00:01:57 GMT
Links: << >>  << T >>  << A >>
It is resolved now, after putting a substantial delay in the reporting of a
problem.  In my case it was not a problem of getting registered, I got an email
the first time I re-registered this time around but still could not get in. 
Apparently there was something goofy with the web database.  It got resolved
after a few  phone conversations with the webmaster.

Besides the late nights and too many cups of coffee, what got me cranky was
having to deal with the additional burden of a broken webserver on top of bugs
in the tools that were costing me time.  On fixed price contracts, the time
spent chasing these types of things comes out of my pocket, and when it gets to
be a day chasing chickens**t, it gets me a little hot under the collar.

I guess the point is, if you are going to do these type of changes that have the
potential for disrupting the normal flow if they break, PLEASE make sure they
work before you make it a major obstacle.

Robert Sturm wrote:
> 
> Hi all-
> 
> I'd like to apologize for the registration problems some of you were experiencing with our online case management tool on support.xilinx.com.  We manually review each and every access request to WebSupport before granting a customer clearance to this utility.  Security is a big concern for many of our customers and we want to do everything in our power to protect the intellectual property of our users.
> 
> Recently, a spike in the number of WebSupport requests has delayed the processing of a typical submission.  We've added a few resources to address this deludge and turnaround times should be greatly reduced within a few business days.  Please note that users who try to login before their request has been approved will be redirected back to the registration page.  Undoubtedly, this was what was happening in Ray's situation.   Users who have been granted access will receive an email notification that they can start using the tool.
> 
> We've deployed WebSupport to help you become more productive.  This utility allows you to add notes, track changes, and manage cases without picking up the phone.  Please don't hesitate to let us know how we can make you more efficient.
> 
> Thanks for your patience.
> 
> Robert Sturm
> support.xilinx.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 24946
Subject: Re: Some notes on metastability
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 23 Aug 2000 00:31:50 +0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
 
> Are the summer doldrums getting to us? Nothing meaningful to say, so we
> start posting about line breaks, create deliberate silly misunderstandings
> and have a hundred posts about NDAs during job interviews. And Moore vs
> Mealy ad infinitum...
> Must mean that there are no more serious subjects to talk about.

Yes - we have to get back to "Use only Xlinix Parts"
"No open source of FPGA's" "No Free software tools" "My latest RISC cpu"
"My latest Forth cpu" "Why suppliers can't supply products" "Who has the
fastest chip (Not counting routing delays)".

Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
 http://www.jetnet.ab.ca/users/bfranchuk/index.html
Article: 24947
Subject: Re: Non-disclosures in job interviews
From: Simpleton Greives <simpleton-greives@nosedive.att.net>
Date: Wed, 23 Aug 2000 00:35:11 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> I don't know where you got your information. I have been asked to sign a
> non-disclosure agreement for the interview process. One company
> specifically said that they don't feel they can conduct a proper
> interview without revealing sensitive information. I think that is
> nonsense! 
Yes, this is nonsense, and unless you can't refuse the offer, send them f
themselves. Many companies are into gouging non-competes these days--this
is nothing but crude attempts of enslavement. At any rate, if you do intend
to go for an interview, ask for a copy of this non-compete and visit a
lawyer. Do NOT limit yourself to what people on usenet say, this is a
potentially serious issue having to do with your livelihood, please make
sure you get a competent legal advice.


> This was stated as a precondition to the interview along with
> completing an application. It did not even come out until I asked if
> there was anything that I needed to sign. I have been through a few
> interviews over the years.
I'd send them on their way right now. If they're that obnoxious even before
they got you by the balls, you can only imagine what will happen if you do
join. Consider this an early warning and do not walk, run away. Bad news.

-- 
    .-'~~~-.
   .'o oOOOo`.  
  :~~~-.oOo   o`. 
   `. \ ~-.  oOOo.
     `.; / ~.  OO:
     .'  ;-- `.o.'
    ,' ; ~~--'~
    ;  ; 
_\\;_\\//_ 
nosedive. 4 all your munging needs
Article: 24948
Subject: Re: Non-disclosures in job interviews
From: Simpleton Greives <simpleton-greives@nosedive.att.net>
Date: Wed, 23 Aug 2000 00:39:34 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> I don't know where you got your information.
I would have to pass some information onto you: ERTisdale is somewhat known
around the net as a nonsense person. I personally don't know why and had
(until now) no personal reasons to believe one way or another, but there's
certain notoriety to his name. By looking at his response, I begin to
believe that these reports are not entirely without foundation. Really,
where did he get his information? Not from you original post, that's
fersure. OK, I'll go away now.

-- 
    .-'~~~-.
   .'o oOOOo`.  
  :~~~-.oOo   o`. 
   `. \ ~-.  oOOo.
     `.; / ~.  OO:
     .'  ;-- `.o.'
    ,' ; ~~--'~
    ;  ; 
_\\;_\\//_ 
nosedive. 4 all your munging needs
Article: 24949
Subject: Re: Non-disclosures in job interviews, Round One
From: Darin Johnson <darin@usa.net>
Date: Wed, 23 Aug 2000 01:39:40 GMT
Links: << >>  << T >>  << A >>
Neil Nelson <n_nelson@pacbell.net> writes:

> After having identified a primary objective and an initial
> solution path, frequently we find that the identified solution
> path is too weak in the likelihood of reaching the objective
> or is against other desirable objectives such that we lose
> elsewhere in making an advance here--we rob Peter to pay Paul.
> This was a thrust of my prior post.

Whoah...  I'm recovering from jetlag, and just reading that is
making me dizzy :-)

> Here we are somehow against NDAs while exhibiting a non-disclosure pattern
> of behavior that in one sense is against our objective.  I.e., if we let
> everyone know who these companies are who are behaving in a manner we
> feel is objectionable _and_ these companies knew their behavior was
> being made widely known, we may have a more desirable solution path.

It's simpler perhaps to just let the company know why you're leaving
the interview.  If several people do this, they will get the idea.
In the majority of cases, employers may not even know the negative
vibes they're putting out.

On the other hand, if there really is a shortage of skilled workers,
employers should be treating prospective hires more nicely.  The
situation I mentioned happened during a recession, when the employers
held the best cards.

But perhaps this sort of thing is still happening today because
employers *think* they still have the cards.  Ie, "we're a startup and
we're going to make billions, so people should be begging us for
jobs".  That sort of company isn't going to be set straight anyway,
so best just to ignore and move on.


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
2017JanFebMarApr2017

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