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 14500

Article: 14500
Subject: Re: Hazard
From: Duck Foot <duckfoot11@hotmail.com>
Date: Tue, 02 Feb 1999 10:46:58 +0900
Links: << >>  << T >>  << A >>


Jonathan Bromley wrote:

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

Sorry to say I still don't understand. Only in the caseTco(min) >= Thold(max) and
Tpd(min) =< Tskew(max),

the next inequality will hold
Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) >= Thold(max),

and the glitch actually doesn't affect hold time rule. Otherwise the glitch will
be within hold time interval, therefore the new input is not really HOLD.

 Did you already assume the above facts, or am I still missing something?


Article: 14501
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 02 Feb 1999 03:03:06 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley writes:

> Indeed.  Does the '!' cost one cycle for the sender, the same cycle as
> the target uses to action its '?' ?

Yes.

>> 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)

It's beyond standard Occam.  The bug isn't anything to do with seizing
up -- that behaviour is fine and good if the output channel isn't ready.

The bug is that if the output blocks, `var3' that it is outputting is
overwritten by the assignment on the previous line, so eventually the
wrong value is output.  The assignment takes place _during the same
cycle_ as the first cycle of the output attempt.

The above code works fine if you remove the `par' and reverse the order
of the channel/assignment statements.  But then, it runs 4 times slower.
It also works fine if you place `par' around the first three statements,
and put the send before the `par'.  Then it only runs 2 times slower (2
cycles per datum instead of 1).  Example is below.

This is what I mean by the Handel-C timing rules allowing for succint
code.  A lot of things in both code examples are defined to happen
during the same clock cycle -- something which isn't possible in Occam.
It allows for some powerful and compact pipeline code.

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

No overruns, unless I made a mistake.  1-place buffer is there
_specifically_ to prevent overrun problems, and it works.  It doesn't
swallow input data -- it's a proper blocking pipeline.  Did you miss the
inner do..while loop?

You don't even need the buffer if you're prepared to take an extra cycle
per datum.  I only use `prialt' when I need a really fast pipeline.

[ And IMO, this is the elegant, if suboptimal version.  It is the
  fastest of the smallest (measured in cycles & flip-flops):

  while (1) {
    output ! var3 - 1;     // Step 3.
    par {
      input ? var1;
      var2 = var1 * 10;    // Some misc. calculation step 1.
      var3 = var2 * var2;  // Step 2.
    }
  }

]


> 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?

Given that you and I are the only people having this discussion, I think
the NG could be a bit premature :-)

Still, votes from people watching would be welcome...

-- Jamie

Article: 14502
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Matthias Sauer <masa@wagner.hl.siemens.de>
Date: 02 Feb 1999 09:42:08 +0100
Links: << >>  << T >>  << A >>
Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk> writes:
[ snip ]
> the NG could be a bit premature :-)

Indeed! There is also the danger that other, more VHDL-ish, people
might be tempted to look away from Handel-C if the discussion about it
only happens in an esoteric newsgroup. I'd rather see more about
Handel-C in other groups as well (such as comp.cad.synthesis etc.)

By the way: Has anybody thought of using Handel-C in conjunction with
system-level simulators such as COSSAP or SPW? Yes, I know this means
multorate and everything but it would be extremely useful.


> 
> Still, votes from people watching would be welcome...
> 
> -- Jamie

Don't make Handel-C esoteric, it should be seen by everybody :)

Cheers

Matthias

--
Matthias Sauer
Siemens AG, Semiconductor Group         Phone: +49-89-63684921
HL CR CE                                Fax:   +49-89-63681066
PO Box 801760                           email: Matthias.Sauer@siemens-scg.com
D-81617 Munich, Germany

Article: 14503
Subject: Re: FPGA Express Evaluation...
From: "Jim King" <j_e_king@snotmail.com>
Date: Tue, 2 Feb 1999 10:44:21 -0000
Links: << >>  << T >>  << A >>

Bruce Nepple wrote in message ...
>Just a wild guess, but isn't FPGA Express from Synopsys
>
Yes, but I have heard that they don't sell it themselves, it only comes
bundled with other packages.

>>Viewlogic Support didn't reply!!!
>>Do someone know how to resolve this problem????
>>
We have FPGA Express as part of Workview Office, hence Samer talking about
Viewlogic.

Jim


Article: 14504
Subject: Re: Hazard
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Tue, 02 Feb 1999 12:36:12 +0000
Links: << >>  << T >>  << A >>
Brian Dam Pedersen wrote:
> 
> 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.
Whoops.  Got it the wrong way round, sorry.  I never had a good memory
for names :-)  At least I had the wit to define what I meant as well!

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

Of course you are right; but all your points would be answered by a 
synthesis methodology that could develop a truly self-timed logic
system (so that manufacturing tolerances *don't* cause trouble) from
a suitable functional description.  AFAIK the basic theory needed to 
underpin such a methodology is already in place; I think you will find
that, at least in principle, your "worst problem" is *not* insoluble.
Self-timed logic gurus, where are you now?

Jonathan Bromley

Article: 14505
Subject: Re: Hazard
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Tue, 02 Feb 1999 13:00:26 +0000
Links: << >>  << T >>  << A >>
Duck Foot wrote:
> 
> Jonathan Bromley wrote:
<big snip> 
> >
> > 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.
> 
> Sorry to say I still don't understand. Only in the case
> Tco(min) >= Thold(max) and
> Tpd(min) =< Tskew(max),
> 
> the next inequality will hold
> Tco(min) >= Tco(min) + Tpd(min) - Tskew(max) >= Thold(max),
> 
> and the glitch actually doesn't affect hold time rule.
> Otherwise the glitch will be within hold time interval,
> therefore the new input is not really HOLD.

You've lost me.  To take your last line of algebra in two parts
 Tco(min) >= Tco(min) + Tpd(min) - Tskew(max)
is just the same as
 Tpd(min) >= Tskew(max)  (by subtracting Tco(min) from both sides)
contradicting your earlier hypothesis.

I think you are assuming that what matters is

 Tco(min) >= Thold(max)   --(3)

which is not the whole story.  Consider two flops.  FF1
receives a clock at t=0; its output changes at Tco.  This
output provides a new input to FF2 at Tco+Tpd.  But FF2
is clocked Tskew later than FF1, so the time from FF2's
clock to the "glitchy" change on its input is Tco+Tpd-Tskew.
This time must be larger than FF2's hold time: hence my
relationship (1), where I've filled-in the worst case
values for everything.  So my (1) is a much stronger 
condition than your (3), because it takes into account
the clock skew (note that Tpd(min) is almost invariably
zero because some of the inter-flop logic is just wire).

You can't get a glitch any earlier than the earliest
possible output change, Tco(min) after the clock;
to guarantee successful operation of the state machine
you must meet my condition (1);  by so doing, you have
also effectively guaranteed that any output glitches 
will not affect the state machine's synchronous
operation.

Sorry if this wasn't clear.

BTW if my two criteria (1) and (2) are applied globally
to the whole state machine they will be unduly pessimistic
because the worst-case left-hand-side of the equality
will probably not occur on the same flop as the worst-case
right-hand-side.  But they provide an easy way of making
things 100% safe.

Jonathan Bromley

Article: 14506
Subject: Opinions requested : Minc/Synario alternatives
From: rjmyers@ti.com (Robert Myers)
Date: 2 Feb 1999 13:26:20 GMT
Links: << >>  << T >>  << A >>
As some/many of you may know, Minc/Synario closed their
doors and had turn over their assets to be liquidated
(see EETimes article, dated around Dec 18, 1998).

I am trying to determine what people/other organizations
are doing to support the programming of PLDs (and possibly
CPLDs) now that the company that supplied ABEL has shut down.
It appears that Logical Devices may be the only "non-biased"
vendor out their, with their CUPL system that targets
multiple PLD vendor devices.

Any thoughts/insights on this matter are welcomed.  

-Bob

p.s.  I have not received any inputs from our AVNET reps
regarding what Xilinx's plans are regarding what Xilinx
purchased from the liquidator.


Article: 14507
Subject: Re: Espresso logic tool
From: jerry english <jenglish@planetc.com>
Date: Tue, 02 Feb 1999 08:43:06 -0500
Links: << >>  << T >>  << A >>
Gerald Shin wrote:

> 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

Here are some links to pages that may have what you are looking
for.Happy Hunting
 http://pages.tico.com/chase/hdl.html
http://www.optimagic.com/

--

      ~~~     "It's not a BUG,
     /o o\  /  it's how I make my living"
    (  >  )
     \ ~ /       Jerry English
     _]*[_     FOE of Script Lords



Article: 14508
Subject: Re: Opinions requested : Minc/Synario alternatives
From: randy.robinson@xilinx.com (Randy Robinson)
Date: Tue, 02 Feb 1999 14:34:37 GMT
Links: << >>  << T >>  << A >>
Go to

 http://www.xilinx.com/products/software/mincsynario/ms-infosite.htm

to get the official word on how Xilinx will handle things.

Randy

On 2 Feb 1999 13:26:20 GMT, rjmyers@ti.com (Robert Myers) wrote:

>As some/many of you may know, Minc/Synario closed their
>doors and had turn over their assets to be liquidated
>(see EETimes article, dated around Dec 18, 1998).
>
>I am trying to determine what people/other organizations
>are doing to support the programming of PLDs (and possibly
>CPLDs) now that the company that supplied ABEL has shut down.
>It appears that Logical Devices may be the only "non-biased"
>vendor out their, with their CUPL system that targets
>multiple PLD vendor devices.
>
>Any thoughts/insights on this matter are welcomed.  
>
>-Bob
>
>p.s.  I have not received any inputs from our AVNET reps
>regarding what Xilinx's plans are regarding what Xilinx
>purchased from the liquidator.
>
>

Article: 14509
Subject: Job: New York; Senior Engineer; FPGA, Imaging, Video
From: lisa_crawford@cmagroup.com
Date: 2 Feb 1999 16:13:34 GMT
Links: << >>  << T >>  << A >>

New York, Syracuse; Senior Engineer; Hardware, Imaging, Video, FPGA

-Senior Engineer
-Syracuse, NY
-Salaried, Full-Time, Direct Employee, Solid Benefits
(Relocation Assistance Available)

Must have: signal processing, algorithms,  FPGAs, and exposure to...video, 
or imaging &/or sensor systems applications. Client using Altera, ViewLogic 
and Spice CAE/CAD tools. 60-70% design/detailed design; 30-40% systems 
level work.

Please refer to JO# 582RJS in your response.

lisa_crawford@cmagroup.com 

Lisa Crawford
Sr. Researcher & Associate Recruiter
ljc@cmagroup.com
IT & Software Solutions Team
Career Marketing Associates
http://www.cmagroup.com/IT.html
Article: 14510
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Tue, 02 Feb 1999 18:25:52 +0000
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> >> (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.
> >> }
> 
> It's beyond standard Occam.  The bug isn't anything to do with seizing
> up -- that behaviour is fine and good if the output channel isn't ready.
> The bug is that if the output blocks, `var3' that it is outputting is
> overwritten by the assignment on the previous line, so eventually the
> wrong value is output.  The assignment takes place _during the same
> cycle_ as the first cycle of the output attempt.
OK, I see what you mean.

<re. a different pipeline example>
> > (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.
> 
> No overruns, unless I made a mistake.  1-place buffer is there
> _specifically_ to prevent overrun problems, and it works.  It doesn't
> swallow input data -- it's a proper blocking pipeline.  Did you miss the
> inner do..while loop?
Just being careless I think.  Thanks for the clarification.

You have nicely made the point that, as with any new tool, one gets
to understand its subtler ramifications only after using it for 
serious work for a while.  Time for me to go and get in some practice.

Meanwhile, some folk out there should be eating their hearts out
when they see how much you can do with even simple use of
Handel-C channels.

Jonathan Bromley

Article: 14511
Subject: Re: PLL in FPGA
From: z80@ds2.com (Peter)
Date: Tue, 02 Feb 1999 19:22:19 GMT
Links: << >>  << T >>  << A >>
Sounds like a Binary Rate Multiplier.

>It can only generate a pulse train that _ON AVERAGE_ is a multiple of the signal
>input frequency. It cannot produce the steady locked frequency an analogue PLL
>can.


--
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: 14512
Subject: Re: Off topic DRAM/SIMM question....
From: z80@ds2.com (Peter)
Date: Tue, 02 Feb 1999 19:22:21 GMT
Links: << >>  << T >>  << A >>

NT does thrash the hell out of the hard disk (Microsoft's wonderful
memory "management") but how can it "thrash" a RAM? I don't know of
any way to thrash a RAM. Either the interface is marginal (in which
case you will get many immediate problems) or not.

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


--
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: 14513
Subject: Re: Off topic DRAM/SIMM question....
From: z80@ds2.com (Peter)
Date: Tue, 02 Feb 1999 19:22:21 GMT
Links: << >>  << T >>  << A >>

I think this is the *only* possible answer, together with win95
probably being less sensitive to wrong opcodes being executed ;)

>I think it actually uses the memory, that W95 just doesn't...


--
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: 14514
Subject: Re: Opinions requested : Minc/Synario alternatives
From: Steve@s-deweynospam.demon.co.uk (Steve Dewey)
Date: Tue, 02 Feb 99 20:14:50 GMT
Links: << >>  << T >>  << A >>

Be VERY careful with CUPL. About 2 years ago we sent back version 4.7 as
being "unfit for purpose" and under English law eventually got our money
back. 

At that time there was no support for hierarchal design and only limited 
macro functions. To produce a counter you had two choices - hand write the 
equations yourself, or, using a for-generate construct, construct a state
machine with an explicit state for every counter value. The second method would 
not allow counters longer than 10 bits. 

The device independant compilation was not great, the documentation poor and the
supplied fitters mostly those available for free from vendor's websites. 

Some months after we settled on Altera, I noticed on their web site that CUPL 
were charging $300 USD to upgrade to the 32 bit version, even to those who had 
purchased "Keep Current Maintenance".

I have ranted on about this at length before, look up deja news under 
"cupl opinions anyone" I think the thread was called.

Of course, their version 5.0 might be completly wonderful, but their web site
does not give me confidence that it is. 

In short you get what you pay for. CUPL is the cheapest.


In article <796uds$cb3@news.rsc.raytheon.com> rjmyers@ti.com  writes:

> As some/many of you may know, Minc/Synario closed their
> doors and had turn over their assets to be liquidated
> (see EETimes article, dated around Dec 18, 1998).
> 
> I am trying to determine what people/other organizations
> are doing to support the programming of PLDs (and possibly
> CPLDs) now that the company that supplied ABEL has shut down.
> It appears that Logical Devices may be the only "non-biased"
> vendor out their, with their CUPL system that targets
> multiple PLD vendor devices.
> 
> Any thoughts/insights on this matter are welcomed.  
> 
> -Bob
> 

-- 
Steve Dewey
Steve@s-deweynospam.demon.co.uk
Too boring to have an interesting or witty .sig file.

Article: 14515
Subject: Re: Off topic DRAM/SIMM question....
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Tue, 02 Feb 1999 21:18:08 GMT
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> NT does thrash the hell out of the hard disk (Microsoft's wonderful
> memory "management") but how can it "thrash" a RAM? I don't know of
> any way to thrash a RAM. Either the interface is marginal (in which
> case you will get many immediate problems) or not.
> 
> >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.
> 
> --
> Peter.
> 

AFAIK NT will bypass the bios and do it's own disk access(you can for
example access disks not detected in the bios), I have have not idea
how, but could
it be possible that it does something similar to RAM???  Because I've
seen 
several maschines that have been running 95 for years with no more than
the
usual problems:), and when trying to install NT it can't even get
through the 
installation without crashing, and often changing the RAM has solved the
problem, sometimes just swapping the RAM modules will help 

makes you wonder :)

--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org

Article: 14516
Subject: Re: PLL in FPGA
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 02 Feb 1999 13:44:15 -0800
Links: << >>  << T >>  << A >>
Let's get back to basics:
A synchronous digital design can only generate output
changes that are separated by n times the clock period ( or
half period when clocking by either clock edge is possible).

So if you use a 10 MHz clock, the output transitions can
only be spaced integer multiples of 100 ns. ( or 50 ns as
mentioned above ).
So if you want to generate 30 MHz, ( 33.33333... ns period )
or any other frequency that does not have a ns-period ending
in two zeros, the output cannot possibly be a pure
frequency, but will only average the desired frequency,
which means it has sidebands.
 
The classical case is a phase accumulator that, if long
enough, can generate an average output frequency with very
fine resolution, down to the milliHz, but it it is still
limited to output changes occurring as a result of the
internal clock edge.  If you can live with this, FPGAs offer
a beautiful, fast and compact implementation. Hint, hint,
end of commercial :-)

An analog VCO does not have this limitation, but suffers of
course from random phase noise and other problems that might
be introduced by the generation and analog filtering of the
VCO control voltage.

Peter Alfke, Xilinx Applications
 
 

Article: 14517
Subject: Re: Off topic DRAM/SIMM question....
From: Brian Dam Pedersen <brian@kom.auc.dk>
Date: Tue, 02 Feb 1999 23:01:21 GMT
Links: << >>  << T >>  << A >>
Lasse Langwadt Christensen wrote:
> AFAIK NT will bypass the bios and do it's own disk access(you can for
> example access disks not detected in the bios), I have have not idea
> how, but could
> it be possible that it does something similar to RAM???  Because I've
> seen
> several maschines that have been running 95 for years with no more than
> the
> usual problems:), and when trying to install NT it can't even get
> through the
> installation without crashing, and often changing the RAM has solved the
> problem, sometimes just swapping the RAM modules will help

Well. There is no direct software layer between RAM and the CPU (such as the
BIOS with HDDs) but Win NT treats everything controllable by the BIOS settings
as it's own property including RAM timing and cache strategy. This can mess up
things pretty bad if the BIOS is set, so that things are running fine, and then
NT gets the idea that tweaking a few timing parameters can optimize things. This
optimization ends up blowing up the system. Newer (faster) RAM is usually the
solution to a problem that shouldn't have been there in the first place (the MS
"we know better" attitude). Win 95 is too stupid to make any assumptions about
low level HW, and thus happily works with whatever settings are put in the BIOS
- the Forrest Gump of OSs. 

OS/2 in its early versions did have the same problems, especially if the RAM
timing was different in some modules (could happen in the good ol' days). Then
OS/2 assumed that the fastest RAM was available in all modules leading to severe
timing problems in some memory areas. Guess who initially designed OS/2 ?

Completely off topic by the way..

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

Article: 14518
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <austin@dark3room.com>
Date: 3 Feb 1999 01:35:05 GMT
Links: << >>  << T >>  << A >>
> NT gets the idea that tweaking a few timing parameters can optimize
things. 

I do not believe NT goes out and changes any of the chip set timing for
DRAM access.  NT would have to have knowledge about EVERY chip set out
there, and that just isn't the case.

Austin

Article: 14519
Subject: Re: Off topic DRAM/SIMM question....
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 3 Feb 1999 02:33:00 GMT
Links: << >>  << T >>  << A >>
"Austin Franklin" <aus3tin@darkroom.com> writes:

>I just bought a 72pin standard PC SIMM.  It claims to be 64M 5V 60ns EDO. 
>OK, that's all well and good, but it has 12 chips on it.  If 72 pin SIMMs
>have a 32 bit data path, how is 32 divisible by 12?

I have a feeling this isn't what you have, but I have bought SIMMs
that were sold as 4Mx32, but were actually 4Mx36.  They are made
by Siemens.  I got the SIMM data sheet, and the chip data sheet.  THe
chips really are 4Mx3, and 12 of them make 4Mx36.  It is likely enough
easier to make 4Mx3 chips than 4Mx4.  

-- glen

Article: 14520
Subject: Re: Off topic DRAM/SIMM question....
From: Brian Dam Pedersen <brian@kom.auc.dk>
Date: Wed, 03 Feb 1999 07:40:19 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > NT gets the idea that tweaking a few timing parameters can optimize
> things.
> 
> I do not believe NT goes out and changes any of the chip set timing for
> DRAM access.  NT would have to have knowledge about EVERY chip set out
> there, and that just isn't the case.

No. It just keeps the hands off the ones that it don't know. As far as I can see
this is the only plausible explanation for NT (and OS/2) crashing where other
OSs succeed.

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

Article: 14521
Subject: Re: Hazard
From: madarass@cats.ucsc.edu (Rita Madarassy)
Date: 3 Feb 1999 09:10:22 GMT
Links: << >>  << T >>  << A >>
In article <36B6F6EA.F19A0F58@brookes.ac.uk>,
Jonathan Bromley  <jsebromley@brookes.ac.uk> wrote:
>
>You've lost me.  To take your last line of algebra in two parts
> Tco(min) >= Tco(min) + Tpd(min) - Tskew(max)
>is just the same as
> Tpd(min) >= Tskew(max)  (by subtracting Tco(min) from both sides)
>contradicting your earlier hypothesis.
>
>I think you are assuming that what matters is
>
> Tco(min) >= Thold(max)   --(3)
>

I dont follow your logic.
Lets go through the steps:

Tco(min) >= Tco(min)+Tpd(min)-Tskew(max)

Then by substracting Tco from both sides we get:

0>=Tpd(min)-Tskew(max)

Then Tskew goes to the left side and we get:

Tskew(max) >= Tco(min)

Which is the reverse of your inequality.

Article: 14522
Subject: Re: FPGA Express Evaluation...
From: "Matthias Brucke" <Matthias.Brucke@Informatik.Uni-Oldenburg.DE>
Date: 3 Feb 1999 10:03:16 GMT
Links: << >>  << T >>  << A >>
Samer EL HAJJ <samer@dotcom.fr> wrote in <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????
> 

You can get an evaluation license (for 14 days or so) from synopsys.
Look at the download pages for FPGA express.

> Thanks in advance!
> 

Hope it helps

> mailto:samer1@hotmail.com
> 

Mats
--
Matthias Brucke                                   Fachbereich Informatik
Entwurf Integrierter Schaltungen                  Universitaet Oldenburg
Tel: 0441-798-2153                                    Fax: 0441-798-2145
Article: 14523
Subject: Re: Hazard
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Wed, 03 Feb 1999 12:02:41 +0000
Links: << >>  << T >>  << A >>
Rita Madarassy wrote:

> I dont follow your logic.
A polite way of saying (correctly) that I was wrong.

> Lets go through the steps:
No, let's not, it's too embarrassing: two goofs in two successive
posts in the same thread. Inexcusable.  That's the downside
of getting older :-(

I was trying to point out that Duck Foot's previous comment
was some way off beam - he'd introduced the irrelevant 
requirement Tco>Thold which is just a special case of my
inequality (1) when Tpd=0, Tskew=0.  But I added fog to
confusion by getting it wrong.  Sorry!

for (i=0; i<100; i++)
  printf("I must not hit SEND before proof-reading \n");

Jonathan Bromley

Article: 14524
Subject: ANNOUNCE: Technical seminar on IP Integration (UK)
From: David Pashley <David@edasource.com>
Date: Wed, 3 Feb 1999 15:18:19 +0000
Links: << >>  << T >>  << A >>
PLDApplications, Altera, Direct Insight, and Viewlogic are pleased to
announce a one-off  technical seminar entitled "IP Integration - A
Practical Approach".

Using a real example in which a PCI-core was successfully integrated in
the design of a data-acquisition system, leading experts in the field
will guide you through the challenges of successful sourcing, design-in,
verification and implementation of IP.

Where:   Savill Court Hotel and Conference Centre, Egham, UK (M25 J13).
When:    Thursday March 4th, all day.
Booking: Free, first-come, first served.

See:

www.edasource.com/ipseminar.html 
or
www.plda.com
-- 
David Pashley                    <
 ---------------------------  <  <  <  --- mailto:david@edasource.com
| Direct Insight Ltd       <  <  <  <  >   Tel: +44 1280 700262      |
| http://www.edasource.com    <  <  <      Fax: +44 1280 700577      |
 ------------------------------  <  ---------------------------------


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