Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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
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. rkArticle: 24927
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! DaixunArticle: 24928
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
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
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"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 DesignArticle: 24932
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
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. rkArticle: 24934
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
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
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
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.comArticle: 24938
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 AlfkeArticle: 24939
"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: 24940You 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
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
> 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
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
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.comArticle: 24945
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.comArticle: 24946
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.htmlArticle: 24947
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
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: 24949Neil 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:
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