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 14475

Article: 14475
Subject: Re: Worst service in India by Xilinx
From: Peter Alfke <peter@xilinx.com>
Date: Sun, 31 Jan 1999 13:29:31 -0800
Links: << >>  << T >>  << A >>
kebm@flash.net wrote:

> While I agree that it does sound like satish is whining or
> trying to lay
> blame for why he hasn't gotten started on his project yet,
> it really is the
> responsibility of the local reps to keep the customer
> happy.  If they can't
> help this guy out before he gets frustrated enough to post
> a message like
> this, perhaps one of their competitors can...
>  

Let's put this silly case to rest. Right after I read the
original posting, I forwarded it to our office in Hong-Kong,
who forwarded it to our Indian rep. And satish is happy and
has apologized profusely about his posting, as you can read
here:

"I am sorry to put the blame on such an well established
company. After my
request the local rep. has turned to me. Any how I apologise
for putting this
in the net."

Serving a subcontinent that has a relatively small revenue
base, is not easy. And just flaming on the internet is not
the appropriate complaint procedure.  End of story.

Peter Alfke, Xilinx Applications
 

Article: 14476
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sun, 31 Jan 1999 18:53:39 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

> I am curious what the cost difference is between the two parts.

Perhaps someone will post some prices.  Spartan XL (say XCS05pc84-4)
would be another interesting point.  It would probably top the
schematic's speed (the schematic is still locked into whatever Orca's
cost and speed is), and I suspect it would be cheaper.  Got the
numbers?  The VHDL design isn't locked into any part by non portable
schematics.


> Personally, that is how I compare parts...since it is difficult to
> establish comparative parameters between two different vendors, I just look
> for comparably priced parts that the design will work in....and choose the
> cheaper part...  It is silly to take a design that can work in a $14 part,
> and implement it in a $45 part...unless you REALLY need the room for future
> upgrades...or you really insist on using an HDL ;-)

Total cost is a key metric, not cost per part.  As an example,  suppose
you are building 30 boards (total, forever, that's the whole market)
with 4 FPGAs each.  The difference between the $45 parts and the $14
parts is less than $1000.  How many hours do you work for $1000?  How
many hours would it take you to port this simple design to:  Xilinx
Spartan?  Or Gatefield?  Or for real speed and/or minimum cost per part,
a gate array?

Suppose you needed to make a RAD-hard variant?  How long would it take
to convert from a SRAM based FPGA to a antifuse based FPGA like for
example, Actel?  It took me about 71 seconds to have a fair idea as to
what sort of speed this design would run in an a3265dx.  Is ~25 MHz good
enough?  Or should I spend some time looking at other parts (like say a
a1225xl)?  Or doing some physical VHDL to improve the critical path?  Is
there a lot to be gained by floorplanning this design?

Suppose that you evaluated all parts for a design and found that the
BAR3456 was the only realistic choice, at $800 (gasp) each.  Just as you
finishing the design FOO inc. announced the FOO6543, same functionality,
at $100 each..  Schematics would require a major redo.  HDLs, on the
other hand, might be as simple as running the tools again...


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 14477
Subject: Espresso logic tool
From: Gerald Shin <gshin@ucsd.edu>
Date: Sun, 31 Jan 1999 19:23:49 -0800
Links: << >>  << T >>  << A >>
I was wondering where I could get a hold of Espresso, the logic
minimization tool, or any other logic minimization tool for a
non-industrial price (under $100 or shareware) somewhere on the net.
This information would be very valuable to me.

Thanks,
Gerald
Article: 14478
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 1 Feb 1999 04:41:24 GMT
Links: << >>  << T >>  << A >>
>  The VHDL design isn't locked into any part by non portable
> schematics.

Since when are schematics non-portable?  I guess they can be if you draw
them 'instantiating' every element of the explicit library....but only a
very inexperienced person would do such a thing.  Anyone with any savvy
would use higher lever symbols, and only 'instantiate' the very lowest
level elements, making the schematics 98% portable.  Once you 'instantiate'
the low level schematic elements for a given technology, you can re-use
them for future designs...and once you make the high level symbols, they
are good for almost any technology....  It appears to be a very overlooked
method of design....because it takes a bit of work up front.

> Total cost is a key metric, not cost per part.

Obviously.

> How
> many hours would it take you to port this simple design to:  Xilinx
> Spartan?  Or Gatefield?  Or for real speed and/or minimum cost per part,
> a gate array?

Not much time at all (Gatefield?) as I have libraries for most 'common'
FPGAs and gate arrays.  And even if I didn't have the library, it would
take maybe a half an hour for 'normal' designs to make a new library...
 
> Suppose you needed to make a RAD-hard variant?  How long would it take
> to convert from a SRAM based FPGA to a antifuse based FPGA like for
> example, Actel?

I only have to change a library reference line.  Probably about 10 seconds.

> Is
> there a lot to be gained by floorplanning this design?

In 98% of the designs I have done, yes.  It takes so little time to do if
the design is done correctly up front, and the benefit is always
substantial.

> Suppose that you evaluated all parts for a design and found that the
> BAR3456 was the only realistic choice, at $800 (gasp) each.  Just as you
> finishing the design FOO inc. announced the FOO6543, same functionality,
> at $100 each..  Schematics would require a major redo.  HDLs, on the
> other hand, might be as simple as running the tools again...

Your assumptions are just not true.  Schematics are usually as simple as
changing a library reference, if the design is done correctly.

We (this group) have hashed out this before.  It is a fact HDLs fall short
when it comes to doing high performance designs (speed/density) unless you
'over buy' the part (get a faster larger part then you need, which usually
will cost you more).  With HDLs floorplanning is currently difficult,
especially if you change the design at all.  Also, you can end up fighting
with the HDL and the tools to get the thing to generate the gates you want.
 Every time I take a job that started as an HDL and the client wonders why
they can't get the performance and density they were promised, it
reinforces my belief that yes, schematics are more work up front...but in
the long run, they are worth it.  This experience comes from over 68 FPGA
designs, 32 clients, and 11 years of doing mostly FPGAs.

Austin

"The fastest way from the top of the Empire State Building to the bottom is
to jump, but better results would be achieved by taking the elevator.  That
is, of course, dependant on what the desired results were in the first
place."

Article: 14479
Subject: Re: Off topic DRAM/SIMM question....
From: Achim Gratz <gratz@ite.inf.tu-dresden.de>
Date: 1 Feb 1999 09:30:21 +0100
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) writes:

> The way a CPU interfaces to RAM is determined by the hardware, not
> the O/S. But lots of people say what you say.

The hardware would be the chipset and that is in turn controlled by
the OS (and/or the BIOS).  NT does, AFAIK, test the RAM at bootup and
also interrogates the modules for their parameters (that's what the
little EEPROM on the modules is for).  If any of these informations
mismatch, it gets extremely concerned.  As a matter of fact, sometimes
the data in the EEPROM is wrong or the EEPROM is missing altogether on
cheap modules.  NT will cry foul if it encounters this situation,
whereas Win95 will live with whatever parameters (hopefully
conservative) have been set by the BIOS.


Achim Gratz.

--+<[ It's the small pleasures that make life so miserable. ]>+--
WWW:    http://www.inf.tu-dresden.de/~ag7/{english/}
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 463 - 8325

Article: 14480
Subject: Re: Off topic DRAM/SIMM question....
From: z80@ds2.com (Peter)
Date: Mon, 01 Feb 1999 09:17:05 GMT
Links: << >>  << T >>  << A >>

Yes Austin but how? I know you are an experienced h/w man; you must be
asking yourself the same question :)

It has to be down to NT actually *using* the extra RAM, or doing
something different with the chipset (e.g. wait states), or the RAM
interface was marginal to start with and NT generates the violation
traps whereas win9x doesn't and falls over some time (perhaps much
later) instead.

Most motherboards are built in Taiwan these days. My experience of
their *high-end* design expertise is not good. And 100MHz, or even
66MHz, motherboard design is not far off state of the art.

>I have experienced the exact same thing.  It is even fussy about DIFFERENT
>manufacturers SIMMs/chips in the same system....


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

Article: 14481
Subject: FPGA Express Evaluation...
From: Samer EL HAJJ <samer@dotcom.fr>
Date: Mon, 01 Feb 1999 11:02:50 +0100
Links: << >>  << T >>  << A >>
Hi to all!!
I installed an evaluation version of FPGA Express, but It ask me for a
key...
Viewlogic Support didn't reply!!!
Do someone know how to resolve this problem????

Thanks in advance!

mailto:samer1@hotmail.com

Article: 14482
Subject: Hazard again
From: Duck Foot <duckfoot11@hotmail.com>
Date: Mon, 01 Feb 1999 21:31:02 +0900
Links: << >>  << T >>  << A >>


Duck Foot wrote:

>     Textbooks tell how to get rid of static hazards inherent in a sum of
> products network. They say the hazard comes from transitions between
> neighboring product terms, and can be eliminated by adding redundant
> implicants.
>     Do we also call the transitions between two apart product terms,
> e.g. diagonally positioned ones, hazard? How can I eliminate glitches
> born of this kind of network? - In this case circling 0's to eliminate
> 0-hazard also results in diagonal configuration.


    I use sychronous logic, and most of the glitches were found to be
combinations of synchronous signals. I could eliminate some of them by
adding redundant implications, but I still couldn't when the implicants were

not adjacent.
    I wonder why most of you say glitches doesn't matter in synchronous
logic. In my humble view, it matters when it occurs on the edge of clock.
What do you think?

Article: 14483
Subject: Re: Hazard
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Mon, 01 Feb 1999 14:04:30 +0000
Links: << >>  << T >>  << A >>
Duck Foot wrote:
> I used sychronous logic, and most of the glitches were found to be
> combinations of synchronous signals. I could eliminate some of them by
> adding redundant implications, but I still couldn't when the implicants were
> not adjacent.
> I wonder why most of you say glitches doesn't matter in synchronous
> logic. In my humble view, it matters when it occurs on the edge of clock.
> What do you think?

Well, I can speak only for myself, not for "most of you"; but here's my 
$0.02 anyway.

If you have a classically-designed synchronous system of the Mealy type
(i.e. with no output combinatorially dependent on any asynchronous input)
then of course, as you say, any output glitches will occur close to
clocking transitions because that's the only time that an internal signal
is allowed to change.  These glitches are not, however, "on the edge" of
the clock.  They occur one clock-to-output delay after the clock that
caused the relevant internal state changes.  This can't affect circuit
operation - it truly doesn't matter - because of the way synchronous
circuits, and in particular edge-triggered flipflops, work.  Each 
flipflop looks at its inputs just _before_ the clock edge and computes
what to do with its outputs just _after_ the clock edge.  Clock-induced
glitches can't affect the action of the flipflop.

To be a little more precise about it: suppose the flops in your 
system have a setup time requirement (inputs must be
stable at least this time before the clock edge) of Tsu; a clock-
to-output delay (outputs change this time after the clock edge) of 
Tco; and, to be realistic, let's accept that the clock doesn't arrive 
at every flop in the system simultaneously, and the worst difference 
between any two flops' clock arrival time is Tskew.  We must also 
take into account the propagation delay of the combinatorial logic 
that generates the new set of inputs from the existing outputs; 
call that Tpd.  Finally we need to consider how long after a 
clock edge the inputs must remain stable for the flop to do its 
stuff reliably; that's the hold time, Thold.  Then we put the whole 
thing into a real system which is being clocked with a 
clock period Tcyc.

So, after the clock edge, flops see new inputs after Tco+Tpd. It's not
hard to see where these two golden rules must come from:

Tco(min)+Tpd(min)-Tskew(max) >= Thold(max)    --(1)
Tco(max)+Tpd(max)+Tskew(max)+Tsu(max) <= Tcyc --(2)

(1) says that we must avoid the situation where an output change might
appear as an input change on another flop so early that it violates the
second flop's hold time requirement. (2) says we must not clock the
system so fast that output changes appear as input changes so late that
they violate the setup time.

I suspect that you are worrying about (1): glitches around the clock
edge might affect the behaviour of other flops _on that same edge_.
But if the synchronous system is to work at all, (1) must be satisfied,
glitches or no glitches; and so your glitches are harmless.  Of course,
there _is_ a problem if you have downstream logic which might be upset
by the glitches on these outputs.  But that occurs only when you have
an output combinatorially dependent on two or more synchronous outputs
that are changing on the same clock edge, and it is easily avoided by
Gray-coding of the relevant internal state.

Rule (2) is commonsense and says that you can't run the system 
faster than it is capable of going.  But rule (1) is of a rather 
different kind: note that it is independent of the cycle time Tcyc!
Rule (1) is the synchronous tyranny: it leads us to designing 
miraculous clock distribution arrangements so that Tskew(max) is
minimised; and it leads to IC designers doing amazing things inside
flipflops to make Thold negative if possible, because everyone is
always fighting to make Tpd and Tco as SMALL as possible in order to
allow faster clock speeds (see (2)).  Note that Tpd and Tco can
never be negative, by causality; but Thold can easily be negative
if a delay path is introduced on the input signal within the flop
(although this trick has a corresponding adverse effect on Tsu).

[ End of lecture, start of personal opinion ]

It's the existence of this synchronous tyranny that leads me to 
believe that fully synchronous design is ultimately a blind alley.
It's by far the best we have right now, but that's only because the 
tools and techniques for proper asynchronous design are not yet 
fully developed into the mainstream.

As I said at the start, just my $0.02.

Jonathan Bromley

Article: 14484
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 01 Feb 1999 09:32:24 -0500
Links: << >>  << T >>  << A >>
Phil Hays wrote:

> Austin Franklin wrote:
>
> > Personally, that is how I compare parts...since it is difficult to
> > establish comparative parameters between two different vendors, I just look
> > for comparably priced parts that the design will work in....and choose the
> > cheaper part...  It is silly to take a design that can work in a $14 part,
> > and implement it in a $45 part...unless you REALLY need the room for future
> > upgrades...or you really insist on using an HDL ;-)
>
> Total cost is a key metric, not cost per part.  As an example,  suppose
> you are building 30 boards (total, forever, that's the whole market)
> with 4 FPGAs each.  The difference between the $45 parts and the $14
> parts is less than $1000.  How many hours do you work for $1000?  How
> many hours would it take you to port this simple design to:  Xilinx
> Spartan?  Or Gatefield?  Or for real speed and/or minimum cost per part,
> a gate array?

i've done designs and moved them between actel, q-logic, gatefield, and gate
arrays.  by making symbols filled in with the lower-level, technology-specific
primitives, it's relatively straightforward.  of course, it's not optimal for a
technology, and more work needs to be focused on the critical paths.  you may
even wish to re-optimize when switching between families from a particular
vendor  then again, from the output that i've seen from synthesizers, the human
can usually do a far better job (where size doesn't make it impractical, there's
limits to the size of a karnaugh map i'll do:) without very much trouble.  if the
design fits speedwise and spacewise into an available part, for a lot of
situations i would agree that the hdl is faster, but not in all cases, as we can
see below ...

another thing that i have found is that different synthesizers do better and
worse with different types of logic.  so if you wish to push a technology, it
frequently pays (pun intended) to have several synthesizers on hand for different
sections of the design.  no offense to the cae vendors out there, but one
schematic package is a lot cheaper then buying, maintaining, and training on
multiple tools.  another example is the size of a design.  for certain
synthesizers who claim great speed in synthesis and technology mapping, they are
frequently very fast as compared to older, slower synthesizers.  for small
designs.  for large designs, i've seen the fast and nimble synthesizers break
down and take many times longer and produce designs that are an order of
magnitude larger than the normally slower synthesizer.

========================================================

> Suppose you needed to make a RAD-hard variant?  How long would it take
> to convert from a SRAM based FPGA to a antifuse based FPGA like for
> example, Actel?  It took me about 71 seconds to have a fair idea as to
> what sort of speed this design would run in an a3265dx.  Is ~25 MHz good
> enough?  Or should I spend some time looking at other parts (like say a
> a1225xl)?  Or doing some physical VHDL to improve the critical path?  Is
> there a lot to be gained by floorplanning this design?

this is a good example as two things are changing; 1) the technology and 2) the
application (rad-hard).  which is easier and better?

1. just as a side point, i would say that the a3265dx and the a1225xl are poor
choices for a rad-hard application.

2. commercial hdl tools tend to naturally choose flip-flops that are "rad soft"
in the XL and DX technologies. so, you need to fuss with the tool some, which has
become easier over the last year, to get the tool to specify either "c-mod"
flip-flops for rad-tolerant applications or perhaps a tmr-triplet + voter
configuration for harder applications.  of course, these flip-flops are slower
and larger than the flip-flops normally chosen by the synthesizer.  and
structures like ripple counters don't work well with tmr if your synthesizer just
substitutes tmr-based f-f's for rad-soft ones; in this case, a bit different
architecture is needed, which i haven't seen any synthesizers implement yet.  but
it's straightforward to implement with schematics.

complicating matters with current software is getting the tool to infer
flip-flops with differing levels of radiation hardness in the same design without
going to structural vhdl.  for example, some data registers may be non-critical
and can take smaller, faster flip-flops while control sections may need to be
fully radiation-hardened.  this may result in more fussing with the code, perhaps
repartitioning it into several smaller modules, which can be awkward.  or perhaps
synthesizer specific attributes.  with schematics, one can just toss down the
type of flip-flops that is wanted in each situation, leaving the design
partitioning in its natural state.  we have spent a bit of time [a few days]
making up flip-flops that are ready to drop on the schematic with the same symbol
but having different radiation characteristics.

3. don h., in a previous post, mentioned that the synthesizer replicated logic.
this has been one of the weaknesses of commercial hdl tools and can be a serious
issue for hi-rel/rad-hard applications, as two flip-flops, logically identical,
may not physically have the same value as a result of radiation.  i have seen
cases where the cae tool, for example, replaced one flip-flop+inverter with two
flip-flops, one having a true output the other having a complemented one.
hopefully the next-state logic will eventually recover into a good state.
however, in the case mentioned above, it was possible that two power fets were
turned on (that's a longer story and gets us into the designer having used this
same flip-flop asynchronously) with the result being quite a bit of current in
the motor (and fuses did pop).  so, with the hdl, you have to keep your eyes open
for when the tools want to replicate logic and perhaps convince it not to do
that.  like in 2), above, controlling logic replication for a particular
application is easy for a human to decide with a schematic; more awkward to
control through a hdl.

4. lockout states are often, well, bad for this sort of application.  using a
schematic for a sequencer, which is frequently a pain, it's straightforward to
ensure that there are no problems.  if the cae tool uses a one-hot encoding to
synthesize the state machine, for example, which does not have illegal state
detection in it (and most synthesizer do not do that), you have a poor circuit
for a radiation environment.  then again, even if you use binary encoding (and
make sure that the cae tool doesn't over-ride your selection because it knows
better), and the number of your states is not exactly a power of 2, then you have
to worry about the logic that is generated if you happen, as a result of
radiation, to enter an unspecified state.  vhdl's "others" clause doesn't help
you here.  one thing to do is to specify the number of states to be exactly a
power of 2.  then you must go in and make sure that the optimizer did not

Article: 14485
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 1 Feb 1999 15:00:16 GMT
Links: << >>  << T >>  << A >>
> (that's what the
> little EEPROM on the modules is for).

What little EEPROM?  There are 'PD' pins on the 72 pin interface that, if
used, give the size and speed of the SIMMs.  There is no EEPROM on any of
the 72 pin SIMMs I have...

> NT will cry foul if it encounters this situation,
> whereas Win95 will live with whatever parameters (hopefully
> conservative) have been set by the BIOS.

Well, NT actually crashes.  That is not really crying 'foul', is it?

Austin

Article: 14486
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 1 Feb 1999 15:03:50 GMT
Links: << >>  << T >>  << A >>
> Yes Austin but how? I know you are an experienced h/w man; you must be
> asking yourself the same question :)

Yes, I agree completely...I haven't researched the answer, because
replacing the memory in the systems that have problems cures the
problem....

I doubt NT changes BIOS or chip set parameters....it would have to know
about every BIOS and chip set made, and to be made....and that just won't
work.  I think it actually uses the memory, that W95 just doesn't...  A
good question is, does Linux have the same issue?  I'll do a DejaNews
search, and post a question in a Linux news group...

Austin



Article: 14487
Subject: Re: Q:Installing Xilinx F1.4 license server
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Mon, 01 Feb 1999 10:06:18 -0500
Links: << >>  << T >>  << A >>
I think you missed the boat here.. :-)

I believe what Lim Sung-taek was referring to is server based licensing
where a network server dishes out licenses upon request. This allows
software to be installed on as many machines as desired, but only allows
as many copies to run at once as the user has licenses for. Since he has
the license locked to the NT server, that server must be running license
manager software and have the license.dat file. Each client pc has an
environment variable indicating that the license is served over the
network, usually
LM_LICENSE_FILE=_some_id_number_@_the_name_of_the_server

We use it extensively here in our EDA Design Center. That is as much as
I know about it, perhaps someone else can fill in more details on the
server side. Also Lim Sung-taek may want to try contacting Xilinx
Customer Support.

Ray Andraka wrote:
> 
> 1.4 used the ethernet address or c drive serial in place of a dongle.  To
> install it on multiple machines you either need unique license files for
> each machine, or you need to make all the machine IDs the same.  If your
> key were the c drive serial number, you could get into Norton or similar to
> alter the c drive serial numbers so they all match.  Where your key is the
> ethernet tag, you are stuck using it only on the machine with the matching
> tag unless you can get an update license file from Xilinx.
> 
<snip> 
> Lim Sung-taek wrote:
> 
> >  Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated
> > license.dat indicates  an ethernet card number of an NT server. I think
> > that
> > I should install so-called 'license server' but I have no information
> > about
> > it. I can't even figure out what should I start with. Can anyone advice
> > me what to do or where can I  get the related information?
> > Thank you for reading this.

Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>

Article: 14488
Subject: SPWM model needed
From: fangbin@public.bta.net.cn (Bin Fang)
Date: Mon, 01 Feb 1999 15:14:26 GMT
Links: << >>  << T >>  << A >>
Hello,

I'm looking for the SPWM controller VHDL/Verilog/ABEL model.
Does anyone have this model ?

Thanks in advance.

B.Fang
Article: 14489
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Mon, 01 Feb 1999 15:24:22 +0000
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> 
> Jonathan Bromley writes:
> > All I meant was that it is sometimes handy to be able to express
> > certain types of logic as a sequence of intermediate calculations
> > even though the result will NOT be pipelined.
> 
> `shared expr' gets close to what you want.  I.e.:
> shared expr value1 = f1 (value);
> shared expr value2 = f2 (value);
> shared expr value3 = f3 (value1, value2);
> etc.  All combinational.

Thanks, I'll look it up.  Tho' it's not quite what I meant.  I'll
post some examples in due course.
 
> > what happens when you communicate over a Handel-C channel?  For the
> > three different scenarios:  sender gets there first, target gets there
> > first, both arrive in the same clock cycle.  This is something that
> > is rather skated-over in the published documentation.
> 
> 1.  Sender waits until a target is ready.  Goto 3.
> 2.  Target waits until a sender is ready.  Goto 3.
> 3.  Expression on sender side is assigned to variable on target side.
>     Takes 1 cycle, as all assignments.
> 
> Easy :-)
Indeed.  Does the '!' cost one cycle for the sender, the same cycle as
the target uses to action its '?' ?

> Well I know nobody used `prialt' because I found tons of bugs a few
> months ago :-)  (All fixed now).

which just goes to show that I _didn't_ use it; but then again, I
already came clean about that :-)

> prialt makes perfect sense and there's nothing deep really.  But there
> are some really useful tricks you can pull.  E.g., this pipeline does
> not work if the send blocks (spot the bug):
> 
>   while (1)
>     par {
>       input ? var1;
>       var2 = var1 * 10;    // Some misc. calculation step 1.
>       var3 = var2 * var2;  // Step 2.
>       output ! var3 - 1;   // Step 3.
>     }

(for occam virgins, and for JL to check I understood:  a par doesn't
complete until _all_ its components complete, so the 'output !' blocking
will sieze up the entire pipeline)

> But this pipeline does work all the time (assuming no typos).  The logic
> is small too, despite the code size.  Note: code does not normally have
> to look like this.  Good use of macros etc...
<snip complicated-looking thing> 
> Enjoy, <ahem>

Enjoyed as invited.

(1) I hadn't read the manual carefully enough, and didn't know
you could 'alt' on a send in Handel-C;  I and many other occam users
would have given many pints of beer for that....
(2) it's a nice 1-place FIFO, elegantly done, but it still suffers
from overruns just like your FIFO-less pipeline: only it behaves
somewhat differently, swallowing and losing input data rather than
blocking it, and the existence of the 1-place buffer makes the
overrun much less likely of course.

I still think we're about due for a comp.lang.handelc NG.  Are you
listening, Embedded Solutions? If so, how about lobbying for it?

Jonathan Bromley

Article: 14490
Subject: Re: Off topic DRAM/SIMM question....
From: "Pascal Dornier" <pdornier@pcengines.com>
Date: Mon, 1 Feb 1999 09:13:37 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote in message <01be4df3$71c96bd0$3fab15d1@drt1>...
>> (that's what the
>> little EEPROM on the modules is for).
>
>What little EEPROM?  There are 'PD' pins on the 72 pin interface that, if
>used, give the size and speed of the SIMMs.  There is no EEPROM on any of
>the 72 pin SIMMs I have...
>
>> NT will cry foul if it encounters this situation,
>> whereas Win95 will live with whatever parameters (hopefully
>> conservative) have been set by the BIOS.
>
>Well, NT actually crashes.  That is not really crying 'foul', is it?


Presence detect on 72 pin modules is not used consistently, most BIOSes use
a trial and error method to detect memory type.

EEPROM is found on most SDRAM DIMM modules.

I doubt that NT goes in and fiddles with the EEPROM - this is highly
specific to the system board / chipset, and not supported by the BIOS. It is
more likely that NT just "thrashes" the hell out of the DRAMs, and exposes
weaknesses more quickly.

--------------------------------------------------------------------
Pascal Dornier   pdornier@pcengines.com     http://www.pcengines.com
Your Spec      + PC Engines            = Custom Embedded PC Hardware
--------------------------------------------------------------------


Article: 14491
Subject: NT sensitivity to PC hardware errors
From: Alexander Sherstuk <Sherstuk@amsd.com>
Date: Mon, 1 Feb 1999 20:28:34 +0300
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4E08.4B317CC3
Content-Type: text/plain;
	charset="koi8-r"

My guess is that NT produces much more intensity of memory (and other PC
resources) references, than any other operating system. It has rather
large kernel, and rather large interrupt latency - which means a lot of
DIFFERENT instructions executed on every clock tick, and a lot of memory
locations interrogated.
Some interesting observation: when I work on my home computer in WinNT,
one of TV channels loses colour signal! When I load MS DOS, everything
is OK.

	-----Original Message-----
	From:	Austin Franklin [mailto:aus3tin@darkroom.com]
	Posted At:	Monday, February 01, 1999 6:00 PM
	Posted To:	comp.arch.fpga
	Conversation:	Off topic DRAM/SIMM question....
	Subject:	Re: Off topic DRAM/SIMM question....

	> (that's what the
	> little EEPROM on the modules is for).

	What little EEPROM?  There are 'PD' pins on the 72 pin interface
that, if
	used, give the size and speed of the SIMMs.  There is no EEPROM
on any of
	the 72 pin SIMMs I have...

	> NT will cry foul if it encounters this situation,
	> whereas Win95 will live with whatever parameters (hopefully
	> conservative) have been set by the BIOS.

	Well, NT actually crashes.  That is not really crying 'foul', is
it?

	Austin

------_=_NextPart_001_01BE4E08.4B317CC3
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>NT sensitivity to PC hardware errors</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">My guess is that NT produces much more =
intensity of memory (and other PC resources) references, than any other =
operating system. It has rather large kernel, and rather large =
interrupt latency - which means a lot of DIFFERENT instructions =
executed on every clock tick, and a lot of memory locations =
interrogated.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Some interesting observation: when I =
work on my home computer in WinNT, one of TV channels loses colour =
signal! When I load MS DOS, everything is OK.</FONT></P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Austin Franklin =
[<A =
HREF=3D"mailto:aus3tin@darkroom.com">mailto:aus3tin@darkroom.com</A>]</F=
ONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Posted =
At:</FONT></B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Monday, February 01, 1999 6:00 PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Posted =
To:</FONT></B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">comp.arch.fpga</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Conversation:&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Off topic DRAM/SIMM question....</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: Off topic DRAM/SIMM =
question....</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; (that's what the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; little EEPROM on the modules is =
for).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What little EEPROM?&nbsp; There are =
'PD' pins on the 72 pin interface that, if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">used, give the size and speed of the =
SIMMs.&nbsp; There is no EEPROM on any of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the 72 pin SIMMs I have...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; NT will cry foul if it encounters =
this situation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; whereas Win95 will live with =
whatever parameters (hopefully</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; conservative) have been set by =
the BIOS.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Well, NT actually crashes.&nbsp; That =
is not really crying 'foul', is it?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Austin</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BE4E08.4B317CC3--

Article: 14492
Subject: Re: Hazard
From: Brian Dam Pedersen <brian@kom.auc.dk>
Date: Mon, 01 Feb 1999 17:36:00 GMT
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> If you have a classically-designed synchronous system of the Mealy type
> (i.e. with no output combinatorially dependent on any asynchronous input)

[snip]

Just to be picky. You just described a Moore FSM. A Mealy FSM is characterized
by the mere fact that the output is directly dependent on the input as well as
current state, while the Moore machine output is only depending on current
state.

[snip a lot of usefull insight into synchronous design]

>It's the existence of this synchronous tyranny that leads me to 
>believe that fully synchronous design is ultimately a blind alley.
>It's by far the best we have right now, but that's only because the 
>tools and techniques for proper asynchronous design are not yet 
>fully developed into the mainstream.

This statement is a little like the statements that sounds like "The only reason
we don't use analog electronics is that the tools are not developed enough".
Making a fully asynchronous (selfclocking) design may be possible, but changing
functionality in such a beast will be a pain, so will taking care of tolerances
- although small - in the silicon. That might be the worst problem, and it might
be unsolveable, no matter how good the tools will be. A mix of the two is
employed today, but in many applications it is not worth the cost of extra
development time. Controlling clock skew can be a nightmare, but at least it is
a smaller nigthmare than keeping track of hazard in a true asynchronous system.



--                                               
Brian Pedersen, DSP Student                    _/     _/_/_/  _/_/_/  _/
Applied Signal Processing and Implementation  _/_/   _/       _/   _/ _/
Department of Communication Technology       _/  _/   _/_/_/  _/_/_/  _/
Aalborg University, Denmark                 _/_/_/_/       _/ _/      _/
URL: http://www.danbbs.dk/~kibria/brian/   _/      _/ _/_/_/  _/      _/

Article: 14493
Subject: Re: Q:Installing Xilinx F1.4 license server
From: Bennet An <bennet.an@xilinx.com>
Date: Mon, 01 Feb 1999 10:40:18 -0800
Links: << >>  << T >>  << A >>
Sung-taek,

Is your current license a 'floating' license or a 'node-locked' license?

A node-locked license allows only one PC to use the tool.
A floating license allows multiple PCs (up to a limit which is set in
license.dat file) on a network to access the tool.

How do you figure out which one you have? A typical node-locked
license file has INCREMENT and PACKAGE sections where as
a typical floating license has SERVER and DAEMON sections in
addition to INCREMENT and PACKAGE sections.

If you have a node-locked license: upgrade to floating license to
run f1.4 on multiple PCs.

If you have a floating license: put license.dat on your NT server, set

set LM_LICENSE_FILE = %path_to_license.dat%; (NT server)
set LM_LICENSE_FILE = port_number@name_of_NT_server; (all other PCs)
port_number is indicated at the end of SERVER line (default is 2200) in
license.dat

then, run license manager from your NT server.

For more info, refer to Foundation Install and Release Documentation that
comes
with your F1.4 s/w package.  Chapger 6 explains you how to set up security

in detail.

Bennet An
Xilinx Applications


Lim Sung-taek wrote:

>  Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated
> license.dat indicates  an ethernet card number of an NT server. I think
> that
> I should install so-called 'license server' but I have no information
> about
> it. I can't even figure out what should I start with. Can anyone advice
> me what to do or where can I  get the related information?
> Thank you for reading this.
>
> Sung-taek Lim (totohero@poppy.snu.ac.kr)



Article: 14494
Subject: Re: Help for the scientifically-challenged
From: "Ken Coffman" <kcoffman@intermec.com>
Date: Mon, 1 Feb 1999 11:26:01 -0800
Links: << >>  << T >>  << A >>
I think a good example is the Boulder Creek Engineering logic analyzer, they
use a cheap 3xxx series Xilinx part, it gets configured to do a high speed
capture of the circuit data, then gets reconfigured as a serial interface
that dumps the capured data. Never do both functions live in the FPGA at the
same time. Very cheap, very clever, very elegant!

Dave Fuhriman wrote in message <36B2314E.B26485BE@email.byu.edu>...
>Hi, I've been researching reconfigurable computing for an article, and I
>have found some good explanations of how it works. What I lack is a
>solid analogy to give to other people to help them understand how it
>works and how it's an improvement over what we had before. Something
>like general purpose computing is like a Yugo, and reconfigurable
>computing like a 'Vette -- something that explains why it's better. Has
>anyone heard such an analogy that explains this concept to people like
>me who use computers but don't know how to make them? Any help would be
>appreciated. Thanks!
>


Article: 14495
Subject: Re: FPGA Express Evaluation...
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Mon, 1 Feb 1999 12:06:25 -0800
Links: << >>  << T >>  << A >>
Just a wild guess, but isn't FPGA Express from Synopsys

Try http://www.synopsys.com

bruce


Samer EL HAJJ wrote in message <36B57BCA.2D43F065@dotcom.fr>...
>Hi to all!!
>I installed an evaluation version of FPGA Express, but It ask me for a
>key...
>Viewlogic Support didn't reply!!!
>Do someone know how to resolve this problem????
>
>Thanks in advance!
>
>mailto:samer1@hotmail.com
>


Article: 14496
Subject: Re: Hazard again
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 01 Feb 1999 15:44:11 -0500
Links: << >>  << T >>  << A >>
Duck Foot wrote:
> 
> Duck Foot wrote:
> 
> >     Textbooks tell how to get rid of static hazards inherent in a sum of
> > products network. They say the hazard comes from transitions between
> > neighboring product terms, and can be eliminated by adding redundant
> > implicants.
> >     Do we also call the transitions between two apart product terms,
> > e.g. diagonally positioned ones, hazard? How can I eliminate glitches
> > born of this kind of network? - In this case circling 0's to eliminate
> > 0-hazard also results in diagonal configuration.
> 
>     I use sychronous logic, and most of the glitches were found to be
> combinations of synchronous signals. I could eliminate some of them by
> adding redundant implications, but I still couldn't when the implicants were
> 
> not adjacent.
>     I wonder why most of you say glitches doesn't matter in synchronous
> logic. In my humble view, it matters when it occurs on the edge of clock.
> What do you think?

Glitches won't matter in synchronous logic, because all of the inputs
change just after the clock edge. If you have met the setup time of the
next flip flop, then you won't have any glitches on the next clock edge.
That is the primary advantage of synchronous design. Just by measuring
the delays between flip flops, you can tell if a given design will have
timing problems and the design will never have race conditions or other
glitches regardless of how you wire the logic.

This type of synchronous design will also allow you to perform much
faster simulations, since you can ignore the timing aspects and just
simulate the functionallity of the logic. This is called "unit delay"
simulation. 


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 14497
Subject: Re: Off topic DRAM/SIMM question....
From: "SoonHuat Goh" <soonhuat@singnet.com.sg>
Date: Tue, 2 Feb 1999 05:27:53 +0800
Links: << >>  << T >>  << A >>

Pascal Dornier wrote in message <36b5e06e$0$16679@nntp1.ba.best.com>...
>Austin Franklin wrote in message <01be4df3$71c96bd0$3fab15d1@drt1>...
>>> (that's what the
>>> little EEPROM on the modules is for).
>>
>>What little EEPROM?  There are 'PD' pins on the 72 pin interface that, if
>>used, give the size and speed of the SIMMs.  There is no EEPROM on any of
>>the 72 pin SIMMs I have...
>>
>>> NT will cry foul if it encounters this situation,
>>> whereas Win95 will live with whatever parameters (hopefully
>>> conservative) have been set by the BIOS.
>>
>>Well, NT actually crashes.  That is not really crying 'foul', is it?
>
>
>Presence detect on 72 pin modules is not used consistently, most BIOSes use
>a trial and error method to detect memory type.
>
>EEPROM is found on most SDRAM DIMM modules.
>
>I doubt that NT goes in and fiddles with the EEPROM - this is highly
>specific to the system board / chipset, and not supported by the BIOS. It
is
>more likely that NT just "thrashes" the hell out of the DRAMs, and exposes
>weaknesses more quickly.


There is no EEPROM for SIMMs. EEPROMs are on DIMMs.



Article: 14498
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 1 Feb 1999 22:28:32 GMT
Links: << >>  << T >>  << A >>
>  A
> good question is, does Linux have the same issue?  I'll do a DejaNews
> search, and post a question in a Linux news group...

It appears Linux has the same issue with memory as NT, at least from what I
saw in my searching...

Austin


Article: 14499
Subject: Need Help! clock multiplier!
From: Barry Chu <barryc03@globalnet.co.uk>
Date: Mon, 01 Feb 1999 23:21:37 +0000
Links: << >>  << T >>  << A >>
Hi,

Would anyone tell me how to write a clock multiplier in VHDL?

BC



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