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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 59775

Article: 59775
Subject: Re: Lithium cell on Virtex2 Pro
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Thu, 28 Aug 2003 11:27:36 +0100
Links: << >>  << T >>  << A >>
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4a0737@dnews.tpgi.com.au...
> I notice that the maximum recommended Virtex2pro Vbatt is 2.63V.
> Lithium cells put out more than that.

Many chips don't go to sleep mode until the VDD has dropped quite a bit.

See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm

The 2V63 value might be the ideal value on their VDD/IDD graph, with most
headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work
just as well.

> Is the solution as simple as a series Si diode on the Vbatt line?

Textbooks show zero current up to Vf but I suspect Vf drop depends on
current, even before then.

It should be a quick experiment to see what happens.





Article: 59776
Subject: Period constraint
From: RobertP <rpudlik@poczta.onet.pl>
Date: Thu, 28 Aug 2003 11:52:46 +0100
Links: << >>  << T >>  << A >>
I am using DCM in VirtexII device. I feed 40 MHz clock to CLKIN and use 
CLK2X output (80Mhz) and CLKDV output (2.5MHz), so these clocks should 
be in phase.
Can I feed output from flip/flop clocked by CLKDV directly to FF clocked 
by CLK2X without additional constraints except of PERIOD for CLKIN?

The PERIOD constraint propagates to both clocks, but I'm not sure that
path from CLKDV FF to CLK2X FF is checked as well.

Constraints Guide says:

"A clock period specification checks timing between all synchronous 
elements within the clock domain as defined in the destination element 
group. The group may contain paths that pass between clock domains if 
the clocks are defined as a function of one or the other."

Also examples show that it is possible to specify phase shift between 
clock and clock derived from this base clock. I think just to check path 
between two created in this way clock domains.

So, I think this path is checked, but I'm looking for some confirmation.

--
RobertP


Article: 59777
Subject: Re: Thinking out loud about metastability
From: oen_br@yahoo.com.br (Luiz Carlos)
Date: 28 Aug 2003 04:02:32 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...
> The output level of a flip-flop during its metastable time is
> irrelevant. If it were in the middle ( which it isn't) we could easily
> fix this with a zener diode.
> The problem is timing. The Q output  can - and will - change to the
> opposite state at a totally unpredictable time. That's the problem:
> unpredictable timing, not unknown levels.
> 
> Cascading flip-flops is the standard remedy, but it introduces latency.
> 
> Remember: Metastability causes an extra 3 ns of unpredictable delay once
> in a billion years...  Seems to be an affordable risk.
> 
> Peter Alfke

Peter, kind of disagree.

Of course for the designer, the problem is timing. But the timing
problem is caused by the voltage problem. If we had a well defined
voltage behavior (as I thought, but now I know I were wrong), we could
fix the timing problem (as you said for the "in the middle" problem).
Anyway, I undestood what you said.

I also disagree that the problem has no solution. As an engineer I
don't believe in no solution problems, we just don't know the
solutions yet. But this is philosophy!

Luiz Carlos

Article: 59778
Subject: Re: Thinking out loud about metastability
From: oen_br@yahoo.com.br (Luiz Carlos)
Date: 28 Aug 2003 04:08:55 -0700
Links: << >>  << T >>  << A >>
Thankyou Philip.
But as I said, I don't believe "There is no cure for metastability",
or any other problem. It's just a question of time.

Luiz Carlos.

Article: 59779
Subject: Re: Implementing FIFO in Spartan-II
From: "Jim Wu" <jimwu88NOOOOSPAM@yahoo.com>
Date: Thu, 28 Aug 2003 11:33:24 GMT
Links: << >>  << T >>  << A >>

> I'm thinking to implement it in the Block RAM (Is there any other
> method which is more efficient than this one in SpartanII?).
> The dual RAM ports of Spartan-II are configurable to any size from
> 4Kx1 to 256x16. (In the XAPP173 "Using Block Select Ram+ Memory in
> Spartan-II" of Xilinx, there is a table1 which don't have port aspect
> ratios for 32x1)
> Can I implement FIFO of 32x1 in this BlockRam of Spartan-II?

You can use any depth for your FIFO as long as it is below 4K. XAPP175 talks
about FIFO implementation in SpartanII.

Jim Wu
jimwu88NOOOSPAM@yahoo.com
http://www.geocities.com/jimwu88/chips



Article: 59780
Subject: Input comparator
From: oen_br@yahoo.com.br (Luiz Carlos)
Date: 28 Aug 2003 04:41:54 -0700
Links: << >>  << T >>  << A >>
I want to use an FPGA input as an high speed analog comparator.
Let's say I'm using an Spartan2 and configured one it's inputs as HSTL
class 3.
I want to sample an analog input signal.
The manual says:
Vout = low,  if Vin <= Vref - 0.5
Vout = high, if Vin >= Vref + 0.5
But, what does hapen if Vin=Vref+0.1? Does Vout still go high? What's
the maximum clock (sample) frequency? Is there a formula for the
settling time versus Vin-Vref difference?
I think this is related to the metastability problem, but I preferred
to start a new thread.
Is there a better input configuration for this purpose (HSTL, AGP,
etc)?

Now let's suppose this works, and that I don't care the value of Vref,
and it's not a problem if Vref changes slowly. I will configure the
input as LVCMOS. What can produce a fast change of the internal Vref?
Other pins of the same IO bank configured as outputs and swithcing?

Luiz Carlos

Article: 59781
Subject: Re: Thinking out loud about metastability
From: Ray Andraka <ray@andraka.com>
Date: Thu, 28 Aug 2003 07:52:46 -0400
Links: << >>  << T >>  << A >>
You sound like a good candidate to spend you time pursuing a perpetual motion machine.
The physics stipulate that you'll have a probability of hitting a  metastable state.  As
processes improve, we can narrow the width of the window, but we can't eliminate it.
Narrowing the width reduces the probability of hitting it for a fixed clock rate.  Trouble
is, as the process improvements occur that permit narrowing the window, the clock speeds
also increase, so unless the designer designs for metastbility, the odds may not improve.

Luiz Carlos wrote:

> Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...
> > The output level of a flip-flop during its metastable time is
> > irrelevant. If it were in the middle ( which it isn't) we could easily
> > fix this with a zener diode.
> > The problem is timing. The Q output  can - and will - change to the
> > opposite state at a totally unpredictable time. That's the problem:
> > unpredictable timing, not unknown levels.
> >
> > Cascading flip-flops is the standard remedy, but it introduces latency.
> >
> > Remember: Metastability causes an extra 3 ns of unpredictable delay once
> > in a billion years...  Seems to be an affordable risk.
> >
> > Peter Alfke
>
> Peter, kind of disagree.
>
> Of course for the designer, the problem is timing. But the timing
> problem is caused by the voltage problem. If we had a well defined
> voltage behavior (as I thought, but now I know I were wrong), we could
> fix the timing problem (as you said for the "in the middle" problem).
> Anyway, I undestood what you said.
>
> I also disagree that the problem has no solution. As an engineer I
> don't believe in no solution problems, we just don't know the
> solutions yet. But this is philosophy!
>
> Luiz Carlos

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 59782
Subject: Re: Lithium cell on Virtex2 Pro
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 28 Aug 2003 22:41:57 +1000
Links: << >>  << T >>  << A >>
kryten_droid wrote:
> "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
> message news:3f4a0737@dnews.tpgi.com.au...
> 
>>I notice that the maximum recommended Virtex2pro Vbatt is 2.63V.
>>Lithium cells put out more than that.
> 
> 
> Many chips don't go to sleep mode until the VDD has dropped quite a bit.
> 
> See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm


Is this relevant to Virtex2pro?


> The 2V63 value might be the ideal value on their VDD/IDD graph, with most
> headroom for battery voltage droop, but lower voltages (e.g. 2V4) might work
> just as well.


The data sheet indicates voltages down to 1.0V are fine.


>>Is the solution as simple as a series Si diode on the Vbatt line?
> 
> 
> Textbooks show zero current up to Vf but I suspect Vf drop depends on
> current, even before then.

You might like to Google for the "diode equation".  It will confirm your 
suspicion.  BTW, you need better textbooks ;)

Extrapolating a curve in the 1N914 datasheet gives about 120 - 130mV 
forward voltage at 100nA forward current.
(This diode has an ideality factor of about 2.)

The V2P data sheet indicates 100nA typical Ibatt over the recommended 
operating conditions.  They don't specify a maximum current - I hope 
it's not 10uA or something.  ;)

Regards,
Allan.


Article: 59783
Subject: Re: Thinking out loud about metastability
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 28 Aug 2003 10:02:59 -0400
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> 
> In article <3F4D5682.AA13889@yahoo.com>,
> rickman  <spamgoeshere4@yahoo.com> wrote:
> >I understand how the resolution time affects the failure rate.  I also
> >understand that the timing window is so small that it is very hard to
> >hit even if you try.  My point is that the analysis has been done
> >assuming a random distribution of timing which is not valid for this
> >case.  If you have an MTBF of 100 years with the standard model, you may
> >well see an MTBF of an hour or less with this situation.  I will be
> >using a half clock cycle (10 ns) minus some 5 ns of delay which should
> >give me lots of room for settling.  But unless I acutally know something
> >about my timing distribution it will be hard to say what my expected
> >MTBF is.
> 
> Then add random jitter into your CLOCK, and now you are back into the
> randomized model, no?

There is already jitter in any clock you pick.  I expect this jitter is
much larger than the fs window that Peter has calculated for the
metastable time window.  But unless all values of delay are equally
likely, the original equations do not apply.  If your clock cycle period
is p and your jitter is j, the occurance of failure compared to the
standard model is p/j times more likely.  I think knowing this helps a
lot since it should be easy to add enough extra delay to offset any
fixed value for this ratio.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 59784
Subject: Re: Period constraint
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 28 Aug 2003 10:07:54 -0400
Links: << >>  << T >>  << A >>
RobertP wrote:
> 
> I am using DCM in VirtexII device. I feed 40 MHz clock to CLKIN and use
> CLK2X output (80Mhz) and CLKDV output (2.5MHz), so these clocks should
> be in phase.
> Can I feed output from flip/flop clocked by CLKDV directly to FF clocked
> by CLK2X without additional constraints except of PERIOD for CLKIN?
> 
> The PERIOD constraint propagates to both clocks, but I'm not sure that
> path from CLKDV FF to CLK2X FF is checked as well.
> 
> Constraints Guide says:
> 
> "A clock period specification checks timing between all synchronous
> elements within the clock domain as defined in the destination element
> group. The group may contain paths that pass between clock domains if
> the clocks are defined as a function of one or the other."
> 
> Also examples show that it is possible to specify phase shift between
> clock and clock derived from this base clock. I think just to check path
> between two created in this way clock domains.
> 
> So, I think this path is checked, but I'm looking for some confirmation.

I am not certain, but I think the above text is saying that if you
specify the derived clocks in terms of the starting clock, then the tool
will check paths between the clock domains.  This means you should say
the period of CLKIN is 25 ns and the period of CLK2X is half of this and
the period of CLKDV is 16 x this value.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 59785
Subject: Re: Lithium cell on Virtex2 Pro
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Thu, 28 Aug 2003 15:14:13 +0100
Links: << >>  << T >>  << A >>
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:3f4df8f2$1@dnews.tpgi.com.au...
> > See: http://www.howell1964.freeserve.co.uk/MyHitachiPage.htm
> Is this relevant to Virtex2pro?
The bits about chips often having definite thresholds for low-power modes
kicking in.

> The data sheet indicates voltages down to 1.0V are fine.
Great, a 2V4 batt should be fine then.

> You might like to Google for the "diode equation".  It will confirm your
> suspicion.  BTW, you need better textbooks ;)

No insult to your intelligence intended.
It's just that on most graphs of Vf/If, it does look flat below Vf
threshold.

> The V2P data sheet indicates 100nA typical Ibatt over the recommended
> operating conditions.  They don't specify a maximum current - I hope
> it's not 10uA or something.  ;)

Even with 700 mV drop, a 2V4 batt should be fine.
By the time it drops to 1V7, it is pretty much out of juice anyway.



Article: 59786
Subject: Re: Thinking out loud about metastability
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 28 Aug 2003 08:48:23 -0700
Links: << >>  << T >>  << A >>
Luiz,
you need to read up on metastability.
There are things even in physics that have no solution. Perpetual motion
is one. If you want to get philosophical about metastability, read
Heisenberg's Uncertainty papers.

Phil Freidin has described the problem very well. He and I agree 100% on
the problem. But I have made quantitative tests and know the (very low)
probability. Everybody has an opinion, very few have performed measurements...

Peter Alfke
=================================
Luiz Carlos wrote:
> 
> Peter Alfke <peter@xilinx.com> wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>...
> > The output level of a flip-flop during its metastable time is
> > irrelevant. If it were in the middle ( which it isn't) we could easily
> > fix this with a zener diode.
> > The problem is timing. The Q output  can - and will - change to the
> > opposite state at a totally unpredictable time. That's the problem:
> > unpredictable timing, not unknown levels.
> >
> > Cascading flip-flops is the standard remedy, but it introduces latency.
> >
> > Remember: Metastability causes an extra 3 ns of unpredictable delay once
> > in a billion years...  Seems to be an affordable risk.
> >
> > Peter Alfke
> 
> Peter, kind of disagree.
> 
> Of course for the designer, the problem is timing. But the timing
> problem is caused by the voltage problem. If we had a well defined
> voltage behavior (as I thought, but now I know I were wrong), we could
> fix the timing problem (as you said for the "in the middle" problem).
> Anyway, I undestood what you said.
> 
> I also disagree that the problem has no solution. As an engineer I
> don't believe in no solution problems, we just don't know the
> solutions yet. But this is philosophy!
> 
> Luiz Carlos

Article: 59787
Subject: Re: pricing, cyclone or spartan
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 28 Aug 2003 08:55:38 -0700
Links: << >>  << T >>  << A >>
John, there is only one way to find your answer:
Contact your local sales representative or distributor or FAE for the X
andalso for the A company and explain your requirements in as much
detail as possible ( speed, package, delivery date, etc).
Then let them each give you a quote.

Peter Alfke
============================
John Lee wrote:
> 
> Hi all,
> 
> What is the price for a maximux of 50K system gates, IO counts is not
> an issue, with more than 100K volumn per year? We look at cyclone and
> spartan series because Xilinx and Altera claimed they are cheap.
> 
> 100K is the minimum.
> 
> Thanks,
> John

Article: 59788
Subject: Re: Is Platform Flash PROM an electrically erasable??
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 28 Aug 2003 08:57:39 -0700
Links: << >>  << T >>  << A >>
The word "Flash" means that it is electrically erasable.

Peter Alfke
====================
Atif wrote:
> 
> Can anyone please tell me is Xilinx Platform Flash PROM an Electrically
> erasable? If no, which technology it uses?
> 
> Regards
> Atif

Article: 59789
Subject: Moving Sum
From: "Christos" <chris_saturnNOSPAM@hotmail.com>
Date: Thu, 28 Aug 2003 18:09:12 +0200
Links: << >>  << T >>  << A >>
Hi to all,



The sum or average of a certain number of samples (for ex. the last 100
values received) have to be checked constantly against a threshold.



I thought of implementing this by keeping a "Moving Sum" which will work by
adding the new value and subtracting the oldest. I think that can be
implemented by adding to a register the value just arriving and subtracting
the value coming out of an 100 word deep shift register.



Now, if a longer sum has to be checked then there is a memory problem
because a lot of values have to be stored. In addition more than one "Moving
Sums" is needed so if I use the above implementation I will have in addition
to store the same data more than once (for ex. the 1000 word Shift Register
will include the 100 word S.R. data).



Any idea of how this could be implemented?



The final system will have to keep 10 moving sums with the largest being
250,000 (8-bit) values for each of the 16 independent input channels.



Help to the design problem will be appreciated and acknowledged.


Christos

__________________________________________________

Christos Zamantzas
CERN, European Organization for Nuclear Research
Div. AB/BDI/BL                         tel: +41 22 767 3409
CH-1211 Geneva 23                  fax: +41 22 767 9560
Switzerland                                 christos.zamantzas@cern.ch
__________________________________________________



Article: 59790
Subject: Re: How to listen to music through an FPGA pin?
From: "Pete Fraser" <pete@rgb.com>
Date: Thu, 28 Aug 2003 09:43:02 -0700
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F4D8155.A14C666F@andraka.com...
> How about not just music out of an FPGA pin, but a complete shortwave
receiver using just a SpartanII FPGA
> and an AtoD converter?  See the block diagram on my website.

Sounds like fun.
Are you going to post the HDL?



Article: 59791
Subject: Re: Moving Sum
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 28 Aug 2003 16:50:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <bil9f7$4o2$1@sunnews.cern.ch>,
Christos <chris_saturnNOSPAM@hotmail.com> wrote:
>
>I thought of implementing this by keeping a "Moving Sum" which will work by
>adding the new value and subtracting the oldest. I think that can be
>implemented by adding to a register the value just arriving and subtracting
>the value coming out of an 100 word deep shift register.
>
>Now, if a longer sum has to be checked then there is a memory problem
>because a lot of values have to be stored. In addition more than one "Moving
>Sums" is needed so if I use the above implementation I will have in addition
>to store the same data more than once (for ex. the 1000 word Shift Register
>will include the 100 word S.R. data).
>
>Any idea of how this could be implemented?

Can you cheat?  That is, instead of having a 250,000 deep moving sum,
have it be 250,000 deep but only at intervals of every 1000 samples?  

The other option is once you have to go off-chip for memory for the
FIFO's, the size doesn't matter much because you can easily just throw
~1GB of DRAM on the other side.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 59792
Subject: Re: Thinking out loud about metastability
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 28 Aug 2003 17:01:02 GMT
Links: << >>  << T >>  << A >>
On 28 Aug 2003 04:08:55 -0700, oen_br@yahoo.com.br (Luiz Carlos) wrote:
>Thankyou Philip.
>But as I said, I don't believe "There is no cure for metastability",
>or any other problem. It's just a question of time.

Yep, you are right, it is just a matter of time. In this case
it is infinite.

When you do your designs do you

A) Do nothing special for async signals entering a synchronous
   domain, because some day someone will solve this problem.

or

B) Use multistage synchronizers to move signals from one clock
   domain to another, because some day someone will solve this
   problem, but it hasn't happened yet.

or

C) Not sure, because I haven't ever seen this problem.

>Luiz Carlos.

Philip



Article: 59793
Subject: Selecting between two clock signals
From: "David Lamb" <gretzteam_nospam@yahoo.com>
Date: Thu, 28 Aug 2003 12:57:07 -0500
Links: << >>  << T >>  << A >>
Hi all,
I have a vhdl component with a "clock_in" input. Depending on the mode of
operation, I want to switch between two different clock signals. I will
never switch on the fly though.  Can I use a mux in front of the clock_in
input? I'm afraid it might glitch.
Thanks
David



Article: 59794
Subject: Re: Free FPGA samples anywhere?
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Thu, 28 Aug 2003 18:18:01 GMT
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:
> On a sunny day (Tue, 26 Aug 2003 18:58:54 GMT) it happened Rene Tschaggelar
> <tschaggelar@dplanet.ch> wrote in
> <d8a593f9a0070578ab8201755480f4a3@news.teranews.com>:
> 
> 
>>NOSPAM@NOSPAM.invalid.com wrote:
>>
>>>Hello,
>>>Please, does anybody know if there's any FPGA manufacturer
>>>that will give a sample FPGA for free?
>>
>>You're going to spend days and weeks with the free software,
>>to become familiar.
>>And you may have to build your own programmer, again a day of
>>layout and etching, so what does it help if you don't have to
>>pay 4$ for a 4$ part ?
> 
> That will buy you a huge peche melba here, nice if its 40 celcius.
> 
Yes.
I'd get the peche melba by saving my time by not spending a
few hours on the internet looking for free samples of 4$ parts.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 59795
Subject: Re: Selecting between two clock signals
From: "Marten" <thedude@DieSpamBots.xs4all.nl>
Date: Thu, 28 Aug 2003 20:46:06 +0200
Links: << >>  << T >>  << A >>

"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
news:bilfne$sel$1@home.itg.ti.com...
> Hi all,
> I have a vhdl component with a "clock_in" input. Depending on the mode of
> operation, I want to switch between two different clock signals. I will
> never switch on the fly though.  Can I use a mux in front of the clock_in
> input? I'm afraid it might glitch.
> Thanks
> David
>
>

David,

Do a query for 'clock sources' in the category 'XCELL Journals' on the
Xilinx web site. This will provide you with a link called 'XCELL 24 -
Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead you
to xl24_20.pdf, a neat little circuit that hopefully will ease your worries
:)

Keep in mind that whatever you put in the clock path will affect the setup
and hold time requirements for the particular component.

Take care,


Marten

] remove the obvious to repy by e-mail [



Article: 59796
Subject: Re: Thinking out loud about metastability
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 28 Aug 2003 19:15:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <8471ba54.0308280308.232c7bfe@posting.google.com>,
Luiz Carlos <oen_br@yahoo.com.br> wrote:
>Thankyou Philip.
>But as I said, I don't believe "There is no cure for metastability",
>or any other problem. It's just a question of time.

You can make the capture window small, but there is always a finite
chance that you will capture the metastable point.

Basic calculus:  IF a curve has two local minima (the stable points),
there must be one local maximum (the metastable point) between the
two.  If you happen to capture the input data when it is at the
metastable point, metastability/unstable equilibria happens.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 59797
Subject: Re: Moving Sum
From: Ray Andraka <ray@andraka.com>
Date: Thu, 28 Aug 2003 15:19:23 -0400
Links: << >>  << T >>  << A >>
Look for "CIC filter".  CIC is a Cascaded integrator Comb filter.  It is a
recursive implementation of a moving sum.   In your case, it sounds like you are
sampling the output once for every input sample, so you don't get the benefit of
decimation (if you could decimate, then the delay queue is shortened by a ratio
equal to the decimation ratio).  The CIC consists of an integrator, a subtractor
and a delay queue.  For a moving sum, you are stuck with the storage and the key
is to minimize the number of transactions you need to do with the storage per
sample.  In the case of the CIC, you need to do one read and one write per
sample.  For the depth you are looking at, you'll need to use off chip memory
for the storage (you might fit it into the bulk storage on an Altera Stratix).
You did not mention the sample rate.  If the data rate is sufficiently low, you
can time multiplex the data in/out of the external memory so that you can trade
memory width for depth, which might get you a lower parts count.

Christos wrote:

> Hi to all,
>
> The sum or average of a certain number of samples (for ex. the last 100
> values received) have to be checked constantly against a threshold.
>
> I thought of implementing this by keeping a "Moving Sum" which will work by
> adding the new value and subtracting the oldest. I think that can be
> implemented by adding to a register the value just arriving and subtracting
> the value coming out of an 100 word deep shift register.
>
> Now, if a longer sum has to be checked then there is a memory problem
> because a lot of values have to be stored. In addition more than one "Moving
> Sums" is needed so if I use the above implementation I will have in addition
> to store the same data more than once (for ex. the 1000 word Shift Register
> will include the 100 word S.R. data).
>
> Any idea of how this could be implemented?
>
> The final system will have to keep 10 moving sums with the largest being
> 250,000 (8-bit) values for each of the 16 independent input channels.
>
> Help to the design problem will be appreciated and acknowledged.
>
> Christos
>
> __________________________________________________
>
> Christos Zamantzas
> CERN, European Organization for Nuclear Research
> Div. AB/BDI/BL                         tel: +41 22 767 3409
> CH-1211 Geneva 23                  fax: +41 22 767 9560
> Switzerland                                 christos.zamantzas@cern.ch
> __________________________________________________

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 59798
Subject: Re: Moving Sum
From: "Josh Model" <model@ll.mit.edu>
Date: Thu, 28 Aug 2003 15:19:30 -0400
Links: << >>  << T >>  << A >>
Another option, if you're using Xilinx parts, is to take advantage of those
SRL16's.  In V2P parts (and I think V2) there are 2 per slice.  With 64 of
these guys cascaded together, you've got a 1-bit wide, 1024-bit long moving
sum (barrel shift down for the average).  That's 32 slices, or 8 CLB's per
bit-width, depending on the level of abstraction you like to think about.

--Josh


"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bilbs8$1ck0$2@agate.berkeley.edu...
> In article <bil9f7$4o2$1@sunnews.cern.ch>,
> Christos <chris_saturnNOSPAM@hotmail.com> wrote:
> >
> >I thought of implementing this by keeping a "Moving Sum" which will work
by
> >adding the new value and subtracting the oldest. I think that can be
> >implemented by adding to a register the value just arriving and
subtracting
> >the value coming out of an 100 word deep shift register.
> >
> >Now, if a longer sum has to be checked then there is a memory problem
> >because a lot of values have to be stored. In addition more than one
"Moving
> >Sums" is needed so if I use the above implementation I will have in
addition
> >to store the same data more than once (for ex. the 1000 word Shift
Register
> >will include the 100 word S.R. data).
> >
> >Any idea of how this could be implemented?
>
> Can you cheat?  That is, instead of having a 250,000 deep moving sum,
> have it be 250,000 deep but only at intervals of every 1000 samples?
>
> The other option is once you have to go off-chip for memory for the
> FIFO's, the size doesn't matter much because you can easily just throw
> ~1GB of DRAM on the other side.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



Article: 59799
Subject: Re: Moving Sum
From: "Josh Model" <model@ll.mit.edu>
Date: Thu, 28 Aug 2003 15:25:28 -0400
Links: << >>  << T >>  << A >>
Whoops, probably won't work in your case-- I didn't read that last
paragraph.  But the SRL's are still good for less gigantic moving sums.

--Josh
"Josh Model" <model@ll.mit.edu> wrote in message
news:cBs3b.78$Y5.41@llslave.llan.ll.mit.edu...
> Another option, if you're using Xilinx parts, is to take advantage of
those
> SRL16's.  In V2P parts (and I think V2) there are 2 per slice.  With 64 of
> these guys cascaded together, you've got a 1-bit wide, 1024-bit long
moving
> sum (barrel shift down for the average).  That's 32 slices, or 8 CLB's per
> bit-width, depending on the level of abstraction you like to think about.
>
> --Josh
>
>
> "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
> news:bilbs8$1ck0$2@agate.berkeley.edu...
> > In article <bil9f7$4o2$1@sunnews.cern.ch>,
> > Christos <chris_saturnNOSPAM@hotmail.com> wrote:
> > >
> > >I thought of implementing this by keeping a "Moving Sum" which will
work
> by
> > >adding the new value and subtracting the oldest. I think that can be
> > >implemented by adding to a register the value just arriving and
> subtracting
> > >the value coming out of an 100 word deep shift register.
> > >
> > >Now, if a longer sum has to be checked then there is a memory problem
> > >because a lot of values have to be stored. In addition more than one
> "Moving
> > >Sums" is needed so if I use the above implementation I will have in
> addition
> > >to store the same data more than once (for ex. the 1000 word Shift
> Register
> > >will include the 100 word S.R. data).
> > >
> > >Any idea of how this could be implemented?
> >
> > Can you cheat?  That is, instead of having a 250,000 deep moving sum,
> > have it be 250,000 deep but only at intervals of every 1000 samples?
> >
> > The other option is once you have to go off-chip for memory for the
> > FIFO's, the size doesn't matter much because you can easily just throw
> > ~1GB of DRAM on the other side.
> > --
> > Nicholas C. Weaver
nweaver@cs.berkeley.edu
>
>





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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search