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 130650

Article: 130650
Subject: Re: ISE 10.1 - Initial experience
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 29 Mar 2008 16:29:58 +0100
Links: << >>  << T >>  << A >>
emeb wrote:

> I'm in the process of adding more timing exceptions and this seems to
> help, but I still haven't had a successful PAR run. Let me re-iterate:
> 9.2.04 didn't have any trouble with this design using the exact same
> source and constraints.
> 
> Summary: 10.1 isn't working as well as 9.2.04. I'll probably be
> shelving it and waiting for the service pack.
> 
> Comments / Criticism / Suggestions welcome.

Sounds like the usual software quality from Altera and Xilinx. The general
advise: Don't use a new release until the first service pack is released.
And for some releases even the versions with service packs are not
recommended, e.g. Quartus 7.0 is fine and I've heard Quartus 7.2 is fine,
but with Quartus 7.1 a design which worked with Quartus 7.0 didn't work any
more.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 130651
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 29 Mar 2008 11:41:38 -0400
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000

Not quite sure what you mean by a 'double clk pulse' but I'm assuming that 
you're feeding the 4MHz clock into 'something' in the FPGA that is clocked 
by 50 MHz.  If that's the case, then what you need to verify in the final 
technology map that the 4MHz signal comes into exactly one flip flop and the 
output of that exactly one flip flop is what you use to clock anything 
else...and to mitigate metastability a bit more, that 'anything else' logic 
might consist of again exactly one flop, the output of which is fed into the 
real logic (i.e. you're constucting a two flop synchronizer).  You'll also 
want to add synthesis attributes to any of these synchronizing flops to 
insure that the logic doesn't get opotomized in a way that ends up 
replicating the flops.  In any case, verify the final routed result brings 
4MHz into exactly one flop (and if adding a second sync flop that it too is 
the only load on the flop that captures the 4MHz)

4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input
Pin

Since you haven't stated just how you're using the 4MHz clock inside the 
FPGA, you should probably clarify that, but a failure rate every 0.2 seconds 
(10 M of the 50MHz clock) then it's quite apparent that one of the most 
likely causes of the failure is one of the following:
- Simple timing (whch will be fixed by what I outline in the previous 
paragraph).
- Signal quality
    1. Measured at the FPGA, are the rising and falling edges of the 50 MHz 
monotonic?
    2. Measured at the FPGA, the 4 MHz clock doesn't have to be absolutely 
monotonic since it doesn't appear to be used to sample anything, but if it 
dips and comes back up and the dip is low enough to appear to be a logic low 
than the 50 MHz could (and eventually will) sample it at precisely that bad 
point.
- Could be power as well, not dipping out of spec at the FPGA are you?

> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
Might want to elaborate on the reason for the 'without phase delay' 
requirement, but assuming that to be the case then a different solution that 
would minimize the phase delay would be to feed the 4MHz into an onchip PLL 
(if you have one) to create a 48 MHz and use that instead of the 50 MHz. 
That way, the two clocks would maintain a fairly accurate phase relationship 
to one another thus avoiding violation of setup/hold time windows.

If the reason for 'without phase delay' requirement is because of other FPGA 
inputs that are synchronized to the 4MHz, then another solution might simply 
be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz clock 
domain.

> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>

This sounds like you are using the 4MHz to drive logic...big mistake (see 
first paragraph for the solution).

> any ideas how to really clean the 4mhz clock?

Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?

> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?

Violating timing, inadequate power at the point of use and signal 
quality....when it comes right down to it those are the ONLY reasons.  In 
the end, that's what you'll find here as well.

> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>

Sure, it simply depends on precisely what the setup/hold timing window of 
the actual part is.  If you have freeze spray, a hot air gun and a simple 
way to quickly get your error rate measurement then try hitting your FPGA 
with the hot, measure your error rate (repeat with the cold) and see if it 
has a temperature dependency.  If it clearly does, then you have a timing 
problem (see first paragraph for the solution), if it doesn't or is not 
clearly temp dependent, then you likely have a power problem.  Based on the 
bits of info you've provided, I'm leaning towards the timing.   This is 
simply science experiment stuff and is not needed to engineer the solution, 
for that you need static timing analysis, proper clock domain crossing 
design technique and proper power supply distribution.

> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>

No need to guess or speculate, unless you don't have a scope to simply 
measure.

> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>

Timing problems produce those symptoms as well.

> :) any good suggestions are welcome, how to troubleshoot the issue
>

Hopefully you'll find the above useful....to reiterate though, I can dang 
near guarantee the fundamental reason for the failure will be
- Violating setup/hold time in the 50 MHz clock
- Signal quality (50 MHz or 4 MHz)
- Power

What you need to do is measurement or analysis to either eliminate causes or 
turn up the design error.

> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>

You shouldn't need to bring out anything, static timing analysis and a scope 
will get you to the root cause.

Good luck.

Kevin Jennings 



Article: 130652
Subject: Re: ISE 10.1 - Initial experience
From: job@amontec.com
Date: Sat, 29 Mar 2008 08:50:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 29, 4:18 pm, emeb <ebromba...@gmail.com> wrote:
> I've got a fairly large design that I've been working with in ISE
> 9.2.04 for a while - it takes about 90% of a V2P100 and runs to
> completion in about 3.5 to 4 hours on my Linux x86_64 system (Athlon
> dual core 3800 w/ 4GB) using home-made make scripts. I decided to take
> 10.1 out for a spin to see if it really helps speed things up. Here's
> what I've seen on the first few runs:
>
> - XST seems to run about as fast as it used to.
> - NGDBUILD seems faster and seems to find errors in timing exceptions
> more quickly.
> - MAP works about the same.
> - PAR takes a lot longer to run. I'm seeing 8 hour runs that used to
> take 2 - 2.5 hours in 9.2.04 with the same constraints. It appears to
> be coming up with bad placements (Phase 12.27 seems to take _forever_)
> that are impossible to route successfully.
>
> I'm in the process of adding more timing exceptions and this seems to
> help, but I still haven't had a successful PAR run. Let me re-iterate:
> 9.2.04 didn't have any trouble with this design using the exact same
> source and constraints.
>
> Summary: 10.1 isn't working as well as 9.2.04. I'll probably be
> shelving it and waiting for the service pack.
>
> Comments / Criticism / Suggestions welcome.
>
> Eric

Evaluate and send feedback to Xilinx Teeam.

But do not use new version before its first service pack is released!

- Laurent
 http://www.amontec.com

Article: 130653
Subject: Re: async clk input, clock glitches
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 29 Mar 2008 10:00:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 29, 2:41=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>
> any ideas how to really clean the 4mhz clock?
> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?
> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>
> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>
> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>
> :) any good suggestions are welcome, how to troubleshoot the issue
>
> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>
> Antti

Antti, click on

http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/=
xl34_54.pdf

which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that many years ago, and published it in Xilinx XCell magazine
#34
Peter Alfke


Article: 130654
Subject: Re: Newbies: Answer to "What is an FPGA?" in video
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 29 Mar 2008 10:03:54 -0700
Links: << >>  << T >>  << A >>
sky465nm@trline4.org wrote:

> I find it hard to elegantly explain sometime what an fpga is for people used
> to program sequential machines in sequential languages. And for everyone else
> what's is good for. They easily get caught in the "how do I get my sequential
> programs on it".

I say, use variables and a single process/block.


      -- Mike Treseler

Article: 130655
Subject: Announcement: Releasing LogicSim 3.3 and WaveProbe 1.1
From: Joe <ngsayjoe@gmail.com>
Date: Sat, 29 Mar 2008 10:11:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'd like to announce the release of LogicSim 3.3 and WaveProbe 1.0.

LogicSim is an affordable and user-friendly Verilog simulator for ASIC
and FPGA design verification. It offers a powerful and easy-to-use
graphical user interface that lets you quickly simulate your Verilog
designs. Please check out the release notes for more info.

WaveProbe is a waveform viewer useful for examining the output of
various logic simulators (like LogicSim, ModelSim, VCS). It offers a
powerful and easy-to-use graphical user interface that lets you
quickly analyze and debug your waveform files. Please check out the
release notes for more info.

For existing customers, please receive your free upgrade here, just
enter your purchase time email address and an activation key will be
sent to you immediately.

I'd like to thank those who continue submitting bugs and feedbacks.
Without them, we would not be able to improve our software. Thanks for
being our valuable customers and users.

Download LogicSim: http://www.zeemz.com/logicsim_overview.php
Download WaveProbe: http://www.zeemz.com/waveprobe_overview.php

Thanks,
Joe, Zeemz

Article: 130656
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 29 Mar 2008 10:13:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
>
> > Hi
>
> > FPGA has
> > 1) 50mhz system clock from ext oscillator
> > 2) 4Mhz clk that is async to the 50mhz
>
> > problem, the 4MHz clk input sees double clk pulse, error rate
> > approximate 1 to 10.000.000
>
> Not quite sure what you mean by a 'double clk pulse' but I'm assuming that
> you're feeding the 4MHz clock into 'something' in the FPGA that is clocked
> by 50 MHz.  If that's the case, then what you need to verify in the final
> technology map that the 4MHz signal comes into exactly one flip flop and the
> output of that exactly one flip flop is what you use to clock anything
> else...and to mitigate metastability a bit more, that 'anything else' logic
> might consist of again exactly one flop, the output of which is fed into the
> real logic (i.e. you're constucting a two flop synchronizer).  You'll also
> want to add synthesis attributes to any of these synchronizing flops to
> insure that the logic doesn't get opotomized in a way that ends up
> replicating the flops.  In any case, verify the final routed result brings
> 4MHz into exactly one flop (and if adding a second sync flop that it too is
> the only load on the flop that captures the 4MHz)
>
> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input
> Pin
>
> Since you haven't stated just how you're using the 4MHz clock inside the
> FPGA, you should probably clarify that, but a failure rate every 0.2 seconds
> (10 M of the 50MHz clock) then it's quite apparent that one of the most
> likely causes of the failure is one of the following:
> - Simple timing (whch will be fixed by what I outline in the previous
> paragraph).
> - Signal quality
>     1. Measured at the FPGA, are the rising and falling edges of the 50 MHz
> monotonic?
>     2. Measured at the FPGA, the 4 MHz clock doesn't have to be absolutely
> monotonic since it doesn't appear to be used to sample anything, but if it
> dips and comes back up and the dip is low enough to appear to be a logic low
> than the 50 MHz could (and eventually will) sample it at precisely that bad
> point.
> - Could be power as well, not dipping out of spec at the FPGA are you?
>
> > unfortunatly the 4mhz clock needs to be used inside without phase
> > delay, so oversampling and filtering with 50mhz is not an option,
> > unless using very clever no delay glitch surpression filter
>
> Might want to elaborate on the reason for the 'without phase delay'
> requirement, but assuming that to be the case then a different solution that
> would minimize the phase delay would be to feed the 4MHz into an onchip PLL
> (if you have one) to create a 48 MHz and use that instead of the 50 MHz.
> That way, the two clocks would maintain a fairly accurate phase relationship
> to one another thus avoiding violation of setup/hold time windows.
>
> If the reason for 'without phase delay' requirement is because of other FPGA
> inputs that are synchronized to the 4MHz, then another solution might simply
> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz clock
> domain.
>
> > external small R/C circuit on 5mhz doesnt change the error rate much,
> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> > give better results as using the 4mhz clock directly
>
> This sounds like you are using the 4MHz to drive logic...big mistake (see
> first paragraph for the solution).
>
> > any ideas how to really clean the 4mhz clock?
>
> Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?
>
> > or any thumb guess what is the likeliness to see double clk edges when
> > sampling 4mhz with async 50mhz?
>
> Violating timing, inadequate power at the point of use and signal
> quality....when it comes right down to it those are the ONLY reasons.  In
> the end, that's what you'll find here as well.
>
> > could the "error rate" of such sampling be that 1:10M what I am
> > seeing?
>
> Sure, it simply depends on precisely what the setup/hold timing window of
> the actual part is.  If you have freeze spray, a hot air gun and a simple
> way to quickly get your error rate measurement then try hitting your FPGA
> with the hot, measure your error rate (repeat with the cold) and see if it
> has a temperature dependency.  If it clearly does, then you have a timing
> problem (see first paragraph for the solution), if it doesn't or is not
> clearly temp dependent, then you likely have a power problem.  Based on the
> bits of info you've provided, I'm leaning towards the timing.   This is
> simply science experiment stuff and is not needed to engineer the solution,
> for that you need static timing analysis, proper clock domain crossing
> design technique and proper power supply distribution.
>
> > I assume the 4 mhz clock is rather good, it coming from an ASIC and
> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> > connector). I did kinda think its hard to belive that the clock edge
> > is so slow or noisy that 50mhz sampling could ever see double/wrong
> > edges but guess i am wrong
>
> No need to guess or speculate, unless you don't have a scope to simply
> measure.
>
> > it doesnt seem to be cross talk either, as there arent much IOs
> > toggling at all
>
> > hm it looks like in rare cases the error is also one clock pulse
> > missing!
>
> Timing problems produce those symptoms as well.
>
> > :) any good suggestions are welcome, how to troubleshoot the issue
>
> Hopefully you'll find the above useful....to reiterate though, I can dang
> near guarantee the fundamental reason for the failure will be
> - Violating setup/hold time in the 50 MHz clock
> - Signal quality (50 MHz or 4 MHz)
> - Power
>
> What you need to do is measurement or analysis to either eliminate causes or
> turn up the design error.
>
> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> > core, and the chip is rather full also, some internal signal could be
> > routed out to external logic analyzer though if badly needed, but so
> > far i am trying to fix the issue by thinking, and error-retry...
>
> You shouldn't need to bring out anything, static timing analysis and a scope
> will get you to the root cause.
>
> Good luck.
>
> Kevin Jennings

Hi all and thanks for all suggestions!
some additional info

failing circuit

ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
FPGA input >

>F-F strobed with 50mhz > global clock buffer > 2 bit counter

now, this 2 bit counter sees
* double clock from asic in about 1:10M pulses
* missing clock from asic in about 1:100m pulses

the asic clock is know to be perfect many other devices can receive it
and have 0 error rate (have not seen error ever!)
the 50mhz clock signal quality, well it doesn matter, as whatever
could be wrong, it could not explain the double and missing pulse
counts ?

using PLL on 4mhz is not an option as it is not free running clock but
byte strobe with 4mhz pulses

so what is failing is really simple circuit!
it also looks like when double pulses are seen the FPGA is not
changing any of its output so its no SSO noise

I could understand power supply noise to cause double pulses, but how
to explain the missing pulses?

I dont have scope here now, but i have tried to troubleshoot the clock
problem before and have looked the signals with scope without seeing
anything helpful to get to the problem, i will do it again if I dont
get it working this weekend

the timing analyze with actel FPGA is something so:so, I have seen a
shift register clocked at 4mhz working 100% when FPGA utilization
below 90% and failing 100% when FPGA utilization over 90%, without any
problem reported by the timing tools or post place simulation. I wasnt
belive my eyes when i did see that, but so it was. Later i found some
actel appnote about methods of dealing with such cases. I hoped that
actel tools take of such situations but they do not.

so I have little hope that some more detailed timing analyzes gives
the solution to the problem

at the moment the 4mhz strobe should have small internal delay so 2 FF
at 50mhz is already too much, so i need either deglitch with no phase
delay or then need change my other logic to tolerate the delay

I have some other options too, but all they are not so simple and easy
to implement, so I am hoping some magic hint to fix the problem :)
will try use the 4mhz directly and measure error rate, with 50mhz
running and disabled, as last resort i can use other free running
clock entering FPGA from different side and PLL, and disable the 50mhz
oscillator completly this should hopefully decrease the overall power
and crosstalk noise

Antti

Article: 130657
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 29 Mar 2008 10:21:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Mrz., 18:00, Peter Alfke <al...@sbcglobal.net> wrote:
> On Mar 29, 2:41 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > FPGA has
> > 1) 50mhz system clock from ext oscillator
> > 2) 4Mhz clk that is async to the 50mhz
>
> > problem, the 4MHz clk input sees double clk pulse, error rate
> > approximate 1 to 10.000.000
> > unfortunatly the 4mhz clock needs to be used inside without phase
> > delay, so oversampling and filtering with 50mhz is not an option,
> > unless using very clever no delay glitch surpression filter
>
> > external small R/C circuit on 5mhz doesnt change the error rate much,
> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> > give better results as using the 4mhz clock directly
>
> > any ideas how to really clean the 4mhz clock?
> > or any thumb guess what is the likeliness to see double clk edges when
> > sampling 4mhz with async 50mhz?
> > could the "error rate" of such sampling be that 1:10M what I am
> > seeing?
>
> > I assume the 4 mhz clock is rather good, it coming from an ASIC and
> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> > connector). I did kinda think its hard to belive that the clock edge
> > is so slow or noisy that 50mhz sampling could ever see double/wrong
> > edges but guess i am wrong
>
> > it doesnt seem to be cross talk either, as there arent much IOs
> > toggling at all
>
> > hm it looks like in rare cases the error is also one clock pulse
> > missing!
>
> > :) any good suggestions are welcome, how to troubleshoot the issue
>
> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> > core, and the chip is rather full also, some internal signal could be
> > routed out to external logic analyzer though if badly needed, but so
> > far i am trying to fix the issue by thinking, and error-retry...
>
> > Antti
>
> Antti, click on
>
> http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
>
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that many years ago, and published it in Xilinx XCell magazine
> #34
> Peter Alfke

Hi Peter,

thanks I do know those things think also but i still printed the xcell
pages out :)
now, in Xilinx FPGA I dont see the problem :)
but the final target is actel FPGA (because: cost+security+package)
and in Actel i see both double and missing clocks

so i am still puzzled, there must be something very basic bad thing
somewhere

Antti
















Article: 130658
Subject: Re: async clk input, clock glitches
From: mk <kal*@dspia.*comdelete>
Date: Sat, 29 Mar 2008 10:42:56 -0700
Links: << >>  << T >>  << A >>
On Sat, 29 Mar 2008 10:00:50 -0700 (PDT), Peter Alfke
<alfke@sbcglobal.net> wrote:
>Antti, click on
>
>http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf
>
>which shows two different ways to avoid the effect of double-edges on
>a clock.
>I wrote that many years ago, and published it in Xilinx XCell magazine
>#34
>Peter Alfke

I think it's highly humorous for a Xilinx employee to post a link to a
university in India for a document which Xilinx has created but unable
to archive apparently.

Article: 130659
Subject: Re: async clk input, clock glitches
From: mk <kal*@dspia.*comdelete>
Date: Sat, 29 Mar 2008 11:03:15 -0700
Links: << >>  << T >>  << A >>
On Sat, 29 Mar 2008 10:42:56 -0700, mk <kal*@dspia.*comdelete> wrote:

>On Sat, 29 Mar 2008 10:00:50 -0700 (PDT), Peter Alfke
><alfke@sbcglobal.net> wrote:
>>Antti, click on
>>
>>http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf
>>
>>which shows two different ways to avoid the effect of double-edges on
>>a clock.
>>I wrote that many years ago, and published it in Xilinx XCell magazine
>>#34
>>Peter Alfke
>
>I think it's highly humorous for a Xilinx employee to post a link to a
>university in India for a document which Xilinx has created but unable
>to archive apparently.

Actually the whole magazine is tucked away at a directory on Xilinx
FTP site but google doesn't seem to like FTP sites too much so a
search doesn't get you there.

Article: 130660
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 29 Mar 2008 14:27:12 -0400
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...
> On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>>
>> news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
>>
>> > Hi
>>
>> > FPGA has
>> > 1) 50mhz system clock from ext oscillator
>> > 2) 4Mhz clk that is async to the 50mhz
>>
>> > problem, the 4MHz clk input sees double clk pulse, error rate
>> > approximate 1 to 10.000.000
>>
>> Not quite sure what you mean by a 'double clk pulse' but I'm assuming 
>> that
>> you're feeding the 4MHz clock into 'something' in the FPGA that is 
>> clocked
>> by 50 MHz.  If that's the case, then what you need to verify in the final
>> technology map that the 4MHz signal comes into exactly one flip flop and 
>> the
>> output of that exactly one flip flop is what you use to clock anything
>> else...and to mitigate metastability a bit more, that 'anything else' 
>> logic
>> might consist of again exactly one flop, the output of which is fed into 
>> the
>> real logic (i.e. you're constucting a two flop synchronizer).  You'll 
>> also
>> want to add synthesis attributes to any of these synchronizing flops to
>> insure that the logic doesn't get opotomized in a way that ends up
>> replicating the flops.  In any case, verify the final routed result 
>> brings
>> 4MHz into exactly one flop (and if adding a second sync flop that it too 
>> is
>> the only load on the flop that captures the 4MHz)
>>
>> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input
>> Pin
>>
>> Since you haven't stated just how you're using the 4MHz clock inside the
>> FPGA, you should probably clarify that, but a failure rate every 0.2 
>> seconds
>> (10 M of the 50MHz clock) then it's quite apparent that one of the most
>> likely causes of the failure is one of the following:
>> - Simple timing (whch will be fixed by what I outline in the previous
>> paragraph).
>> - Signal quality
>>     1. Measured at the FPGA, are the rising and falling edges of the 50 
>> MHz
>> monotonic?
>>     2. Measured at the FPGA, the 4 MHz clock doesn't have to be 
>> absolutely
>> monotonic since it doesn't appear to be used to sample anything, but if 
>> it
>> dips and comes back up and the dip is low enough to appear to be a logic 
>> low
>> than the 50 MHz could (and eventually will) sample it at precisely that 
>> bad
>> point.
>> - Could be power as well, not dipping out of spec at the FPGA are you?
>>
>> > unfortunatly the 4mhz clock needs to be used inside without phase
>> > delay, so oversampling and filtering with 50mhz is not an option,
>> > unless using very clever no delay glitch surpression filter
>>
>> Might want to elaborate on the reason for the 'without phase delay'
>> requirement, but assuming that to be the case then a different solution 
>> that
>> would minimize the phase delay would be to feed the 4MHz into an onchip 
>> PLL
>> (if you have one) to create a 48 MHz and use that instead of the 50 MHz.
>> That way, the two clocks would maintain a fairly accurate phase 
>> relationship
>> to one another thus avoiding violation of setup/hold time windows.
>>
>> If the reason for 'without phase delay' requirement is because of other 
>> FPGA
>> inputs that are synchronized to the 4MHz, then another solution might 
>> simply
>> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz 
>> clock
>> domain.
>>
>> > external small R/C circuit on 5mhz doesnt change the error rate much,
>> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
>> > give better results as using the 4mhz clock directly
>>
>> This sounds like you are using the 4MHz to drive logic...big mistake (see
>> first paragraph for the solution).
>>
>> > any ideas how to really clean the 4mhz clock?
>>
>> Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?
>>
>> > or any thumb guess what is the likeliness to see double clk edges when
>> > sampling 4mhz with async 50mhz?
>>
>> Violating timing, inadequate power at the point of use and signal
>> quality....when it comes right down to it those are the ONLY reasons.  In
>> the end, that's what you'll find here as well.
>>
>> > could the "error rate" of such sampling be that 1:10M what I am
>> > seeing?
>>
>> Sure, it simply depends on precisely what the setup/hold timing window of
>> the actual part is.  If you have freeze spray, a hot air gun and a simple
>> way to quickly get your error rate measurement then try hitting your FPGA
>> with the hot, measure your error rate (repeat with the cold) and see if 
>> it
>> has a temperature dependency.  If it clearly does, then you have a timing
>> problem (see first paragraph for the solution), if it doesn't or is not
>> clearly temp dependent, then you likely have a power problem.  Based on 
>> the
>> bits of info you've provided, I'm leaning towards the timing.   This is
>> simply science experiment stuff and is not needed to engineer the 
>> solution,
>> for that you need static timing analysis, proper clock domain crossing
>> design technique and proper power supply distribution.
>>
>> > I assume the 4 mhz clock is rather good, it coming from an ASIC and
>> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
>> > connector). I did kinda think its hard to belive that the clock edge
>> > is so slow or noisy that 50mhz sampling could ever see double/wrong
>> > edges but guess i am wrong
>>
>> No need to guess or speculate, unless you don't have a scope to simply
>> measure.
>>
>> > it doesnt seem to be cross talk either, as there arent much IOs
>> > toggling at all
>>
>> > hm it looks like in rare cases the error is also one clock pulse
>> > missing!
>>
>> Timing problems produce those symptoms as well.
>>
>> > :) any good suggestions are welcome, how to troubleshoot the issue
>>
>> Hopefully you'll find the above useful....to reiterate though, I can dang
>> near guarantee the fundamental reason for the failure will be
>> - Violating setup/hold time in the 50 MHz clock
>> - Signal quality (50 MHz or 4 MHz)
>> - Power
>>
>> What you need to do is measurement or analysis to either eliminate causes 
>> or
>> turn up the design error.
>>
>> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer
>> > core, and the chip is rather full also, some internal signal could be
>> > routed out to external logic analyzer though if badly needed, but so
>> > far i am trying to fix the issue by thinking, and error-retry...
>>
>> You shouldn't need to bring out anything, static timing analysis and a 
>> scope
>> will get you to the root cause.
>>
>> Good luck.
>>
>> Kevin Jennings
>
> Hi all and thanks for all suggestions!
> some additional info
>
> failing circuit
>
> ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
> FPGA input >
>
>>F-F strobed with 50mhz > global clock buffer > 2 bit counter
>
> now, this 2 bit counter sees
> * double clock from asic in about 1:10M pulses
> * missing clock from asic in about 1:100m pulses
>

OK, so it appears that the 4 MHz input is being synchronized to the 50 MHz 
clock through a single flip flop, but have you verified that the final 
routed design uses only one flip flop?

Are you using the now synchronized 4 MHz signal as a clock?  Do you know for 
sure that the Actel device will properly generate an internal clock signal 
from the output of a flip flop?  You can't see clock signal quality internal 
to a device but that doesn't imply that it doesn't matter.  If "output of a 
flip flop to the clock input of another" is not something that Actel handle 
then maybe you shouldn't be doing that.

> the asic clock is know to be perfect many other devices can receive it
> and have 0 error rate (have not seen error ever!)

That's good to know.

> the 50mhz clock signal quality, well it doesn matter, as whatever
> could be wrong, it could not explain the double and missing pulse
> counts ?

Signal quality on the 50 MHz clock does matter...what if the osc is bad or 
flaky?  It's not my first suspect either but again worth verifying at the 
input to the FPGA with a scope (when you get access to one) so that it can 
be eliminated as a cause.

> so what is failing is really simple circuit!
> it also looks like when double pulses are seen the FPGA is not
> changing any of its output so its no SSO noise
>

That would also tend to lower power supply noise as a culprit too in my 
mind...again, it can only be eliminated as a cause by verification with a 
scope when you get a chance.

> I could understand power supply noise to cause double pulses, but how
> to explain the missing pulses?
>

Bad power is worse than a bad clock, all sorts of bad things can happen.

> I dont have scope here now, but i have tried to troubleshoot the clock
> problem before and have looked the signals with scope without seeing
> anything helpful to get to the problem, i will do it again if I dont
> get it working this weekend
>

From here it really smells like the problem is not properly synchronizing 
the 4 MHz signal or that the internally generated clock is not a good clock 
for whatever reason.

Also, is the output of the two bit counter directly observable to you and is 
that the reason you say that you miss a clock or get two every now and then 
or is it because of some other downstream logic output?  The reason for 
asking is because no matter what you do, if you use the 'synchronized 4 MHz' 
to actually clock a flip flop the output of that two bit counter will be 
skewed a bit from the 50 MHz clock because of the unavoidable clock to 
output delay of the flip flop (plus possible additional skew from 
differences in the clock distribution between the 50 MHz and the 
'synchronized 4 MHz' internal to the device.

I've found and fixed many other designer's errors by getting rid of 
internally generated clocks because, no matter how well you do, there is 
inherent design skew that can not be eliminated and yet can not be tolerated 
either.

> the timing analyze with actel FPGA is something so:so, I have seen a
> shift register clocked at 4mhz working 100% when FPGA utilization
> below 90% and failing 100% when FPGA utilization over 90%, without any
> problem reported by the timing tools

Is there an option in the timing analysis that causes it to not analyze 
clock domain transfers?  I know with Altera, the default is to not analyze 
paths that start in one clock domain (i.e. the 'synchronized 4 MHz' domain) 
and end in another (i.e. the 50 MHz domain).  When you turn that option on, 
it does do the analysis.  Check with the Actel stuff to see how it analyzes 
(or doesn't) stuff in between two domains.

> or post place simulation.

In my experience, post route simulation generally does not catch any timing 
problems....it just takes a long time to do and really doesn't catch hardly 
anything.

> I wasnt
> belive my eyes when i did see that, but so it was. Later i found some
> actel appnote about methods of dealing with such cases. I hoped that
> actel tools take of such situations but they do not.
>

Not sure what you're referring to here.


> so I have little hope that some more detailed timing analyzes gives
> the solution to the problem
>

Given that you're (likely) operating this in a non-radioactive, Earth bound 
environment, the only things that will cause intermittent failures though as 
I stated earlier are:
- Timing
- Signal quality
- Power

Nothing else.

Since signal quality and power don't appear to be the most likely suspects 
based on what you've posted, that leaves timing as the lurking design issue 
so timing analysis will find the problem.

> at the moment the 4mhz strobe should have small internal delay so 2 FF
> at 50mhz is already too much, so i need either deglitch with no phase
> delay or then need change my other logic to tolerate the delay
>

Since you're only driving a two bit counter, I'd suggest instead that you 
get rid of the synchronizing flop on the 4 MHz and instead use it as the 
direct input to a two or three bit shift register that is clocked by 50 MHz. 
Inherently then you're building in the proper synchronization, and the 
outputs of the shift register will all be in the 50 MHz clock domain, not 
something that you hope to be close to it (i.e. the 'synchronized 4 MHz' 
domain).  Except for the very first shift reg output those other outputs can 
be combined however needed to emulate whatever it is that you were really 
doing with the 2 bit counter.

I'm suspecting that it shouldn't take too much effort to make the 2 bit 
counter run off of the 50 MHz with a clock enable signal that is computed by 
combinatorially combining the last two taps of the shift register (i.e. 
Tap(2) and not(Tap(3)).

> I have some other options too, but all they are not so simple and easy
> to implement, so I am hoping some magic hint to fix the problem :)

Magic won't help ;)

> will try use the 4mhz directly and measure error rate, with 50mhz
> running and disabled, as last resort i can use other free running
> clock entering FPGA from different side and PLL, and disable the 50mhz
> oscillator completly this should hopefully decrease the overall power
> and crosstalk noise

Except that you haven't measured anything that indicates that power supply 
noise or crosstalk is the issue.

Kevin Jennings 



Article: 130661
Subject: Re: async clk input, clock glitches
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 29 Mar 2008 12:34:59 -0700
Links: << >>  << T >>  << A >>
Antti wrote:

> any ideas how to really clean the 4mhz clock?

I would try soldering on one of those
little schmitt trigger packs. Sometimes
a low slew rate will clock both edges
once in a while.

          -- Mike Treseler



Article: 130662
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 29 Mar 2008 12:59:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
> Antti wrote:
> > any ideas how to really clean the 4mhz clock?
>
> I would try soldering on one of those
> little schmitt trigger packs. Sometimes
> a low slew rate will clock both edges
> once in a while.
>
>           -- Mike Treseler

yes schmit trigger input could be the cure..
but i still cant understand the missing clock pulses!

Antti

Article: 130663
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 29 Mar 2008 16:21:42 -0400
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:860e9a98-ef7c-4228-b5d8-ee2c44c95054@i7g2000prf.googlegroups.com...
> On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
>> Antti wrote:
>> > any ideas how to really clean the 4mhz clock?
>>
>> I would try soldering on one of those
>> little schmitt trigger packs. Sometimes
>> a low slew rate will clock both edges
>> once in a while.
>>
>>           -- Mike Treseler
>
> yes schmit trigger input could be the cure..
> but i still cant understand the missing clock pulses!
>
> Antti

Your post never mentioned anything about having measured a slow edge on the 
4MHz signal either.  If the edge rate is within spec, adding a Schmitt 
trigger will have no effect.  Have you taken a scope to that signal and 
measured the edge rate?

Kevin Jennings 



Article: 130664
Subject: Re: async clk input, clock glitches
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 29 Mar 2008 14:14:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 29, 10:42=A0am, mk <kal*@dspia.*comdelete> wrote:
> On Sat, 29 Mar 2008 10:00:50 -0700 (PDT), Peter Alfke
>
> <al...@sbcglobal.net> wrote:
> >Antti, click on
>
> >http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
>
> >which shows two different ways to avoid the effect of double-edges on
> >a clock.
> >I wrote that many years ago, and published it in Xilinx XCell magazine
> >#34
> >Peter Alfke
>
> I think it's highly humorous for a Xilinx employee to post a link to a
> university in India for a document which Xilinx has created but unable
> to archive apparently.

Not so strange when the Xilinx employee (and incidentally also the
author of the article) is at home and in a hurry, and just googles for
the first hit.
Who cares about geography in the age of the internet...
Peter Alfke

Article: 130665
Subject: Re: async clk input, clock glitches
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 30 Mar 2008 09:30:51 +1200
Links: << >>  << T >>  << A >>
Antti wrote:
> On 29 Mrz., 18:00, Peter Alfke <al...@sbcglobal.net> wrote:
> 
>>On Mar 29, 2:41 am, Antti <Antti.Luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>>Hi
>>
>>>FPGA has
>>>1) 50mhz system clock from ext oscillator
>>>2) 4Mhz clk that is async to the 50mhz
>>
>>>problem, the 4MHz clk input sees double clk pulse, error rate
>>>approximate 1 to 10.000.000
<snip>

> Hi Peter,
> 
> thanks I do know those things think also but i still printed the xcell
> pages out :)
> now, in Xilinx FPGA I dont see the problem :)
> but the final target is actel FPGA (because: cost+security+package)
> and in Actel i see both double and missing clocks
> 
> so i am still puzzled, there must be something very basic bad thing
> somewhere
Hi Antti,
If you have a clean design using Xilinx, and the EXACT SAME (?)
design fails in Actel, then that does seem to exclude the ASIC.

Does Actel have pin Hysteresis ?

Can you move the 4MHz pin about on the device, and check the
failure stats ?.

Try a tiny-logic schmitt right at the Actel device ?

And also try a Tiny-Logic D-FF as an external syncroniser.

Can you simplify the Actel logic to the very lowest to verify clock 
integrity
(even some test code that is a FreqDetector, looks for 2MHz or 8MHz
timeframes, and sticky latches (or counts) - should be only a few FFs,
then try this with/without the rest of ther chip alive.


The only time I've seen double clocking, is on slowish edges,
on pins without Hysteresis.
(oh, and when I've gone looking for it, with test waveforms :)

Cables are NOT nice, as they have significant series inductance.

Floating pins have done strange things too, as I suspect the
buffer stages go into transistion oscillation, at very high
frequencies, and the internal ground inductance is simply too high
at those frequencies and things get 'quite confused'

-jg






Article: 130666
Subject: Re: async clk input, clock glitches
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 30 Mar 2008 09:37:14 +1200
Links: << >>  << T >>  << A >>
Antti wrote:

> failing circuit
> 
> ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
> FPGA input >
> 
>>F-F strobed with 50mhz > global clock buffer > 2 bit counter
> 
> 
> now, this 2 bit counter sees
> * double clock from asic in about 1:10M pulses
> * missing clock from asic in about 1:100m pulses

10M is at 4MHz rate  so every 2.5s, and 25 secs ?

Can you clarify the double-clocking ?
Do you mean one 4Mhz Edge, causes two INCs, 20ns apart ?
(rather than the expected INC @ 250nS +/- 20ns ) ?

What if you set up two of these one on each 4MHz edge ?
- are the error stats the same on rising/falling ?

-jg


Article: 130667
Subject: Re: async clk input, clock glitches
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 30 Mar 2008 09:47:10 +1200
Links: << >>  << T >>  << A >>
Antti wrote:

> the timing analyze with actel FPGA is something so:so, I have seen a
> shift register clocked at 4mhz working 100% when FPGA utilization
> below 90% and failing 100% when FPGA utilization over 90%, without any
> problem reported by the timing tools or post place simulation. I wasnt
> belive my eyes when i did see that, but so it was. Later i found some
> actel appnote about methods of dealing with such cases. I hoped that
> actel tools take of such situations but they do not.

  That may not be a 'tools' problem at all, but could be a real hardware
issue. It is unlikely their test coverage is that great in
such 'corner cases' - most vendors expect you to go to a larger device
when you hit 90% ! :)

  As more and more of the device is active, the ground noise and 
crosstalk has to get steadily worse - what external loads is the device 
driving, and what package ?.

  I get the impression this was part of the driving force behind the 
flip-chip-bga and all-die-bondpads

-jg


Article: 130668
Subject: Re: TCL testcase in Modelsim.
From: jeffery_dong@hotmail.com
Date: Sat, 29 Mar 2008 16:09:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Feb 18, 5:20=A0pm, bigyellow <bigyel...@gmail.com> wrote:
> Hello,
>
> Does anybody have experience on writing TCL testcase in Modelsim? I
> only have VHDL simulation license of Modelsim, I used to write both
> testbench and testcase in VHDL. But I feel VHDL is not that nice to
> implement testcase.
>
> So I am thinking to implement my testbench in VHDL, and write the
> testcases in TCL for my next project. Of course the verification
> should be self-checking.
>
> Does it sounds feasible? How is the simulation speed? =A0Can anyone give
> me some reference? =A0Thanks in advance.
>
> -Best Regards
> Jim

Dear Jim,

Have you solve the problem? I also had such idea.
Our method is like yours. Testbench written in VHDL (I am using System
Verilog now), and the test case are text based command. I want to add
TCL script in the test case.

I think we are using an advanced method in the simulation
(verifiation). Hope we can keep touch.

My email addres : jeffery_dong@hotmail.com

Thanks

Jeffery

Article: 130669
Subject: Re: async clk input, clock glitches
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 30 Mar 2008 11:10:42 +1200
Links: << >>  << T >>  << A >>
KJ wrote:

> "Antti" <Antti.Lukats@googlemail.com> wrote in message 
> news:860e9a98-ef7c-4228-b5d8-ee2c44c95054@i7g2000prf.googlegroups.com...
> 
>>On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
>>
>>>Antti wrote:
>>>
>>>>any ideas how to really clean the 4mhz clock?
>>>
>>>I would try soldering on one of those
>>>little schmitt trigger packs. Sometimes
>>>a low slew rate will clock both edges
>>>once in a while.
>>>
>>>          -- Mike Treseler
>>
>>yes schmit trigger input could be the cure..
>>but i still cant understand the missing clock pulses!

Wait until you have it proven-fixed, before making
guesses :)

>>
>>Antti
> 
> 
> Your post never mentioned anything about having measured a slow edge on the 
> 4MHz signal either.  If the edge rate is within spec, adding a Schmitt 
> trigger will have no effect.  

Not entirely true.
In the real analog world, there are other details that can
trip you up. Ground level shifting and series inductances all
conspire against clean digital operation...

(The best schmitt is a non-inverting one.)

-jg





Article: 130670
Subject: Re: ISE 10.1 - Initial experience
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 30 Mar 2008 12:22:42 +1200
Links: << >>  << T >>  << A >>
job@amontec.com wrote:
> 
> But do not use new version before its first service pack is released!

Of course, if _everyone_ did this, they would not release a service 
pack, as

a) The beta testers (aka customers) have all gone

b) They would think the zero complaint feedback, meant there was
nothing to fix

;)

-jg


Article: 130671
Subject: Re: ISE 10.1 - Initial experience
From: austin <austin@xilinx.com>
Date: Sat, 29 Mar 2008 18:07:21 -0700
Links: << >>  << T >>  << A >>
Jim,

I agree, but you do need to get feedback, somehow.

Yes, as a practical matter, when I was using FPGA devices to solve 
problems, and trying to make money doing so, I would NEVER use an 
initial release, but I would always freeze the development of a product 
at some previous release.

"New software" = ? (a potential for risk): be it Microsoft, Xilinx, or IBM.

However, the new release always has benefits, so I would have one 
engineer looking at the new release, so we would be "ready" when the 
time came to freeze for the next real product.

I do not think any engineering manager is doing much different today.

You need something stable, and known, to develop the product (in order 
to manage the risks).

You also need the new release to support the new families and features 
you need for the next product family.

And, the vendor needs to know what is working, and what is broken.

So, (to everyone), keep the feedback coming, (life goes on)

Austin

Article: 130672
Subject: Re: Newbies: Answer to "What is an FPGA?" in video
From: Dave Pollum <vze24h5m@verizon.net>
Date: Sat, 29 Mar 2008 20:25:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 29, 12:48 am, sky46...@trline4.org wrote:
> Tony Burch <t...@burched.com.au> wrote:
> >Hi guys,
> >This is one just for FPGA newbies, and possibly also a place where you can
> >point people when they ask you what an FPGA is...
>
> I find it hard to elegantly explain sometime what an fpga is for people used
> to program sequential machines in sequential languages. And for everyone else
> what's is good for. They easily get caught in the "how do I get my sequential
> programs on it".
>
> The common answer is that it's a matrix of logic gates that can act as any
> other kind of chip at will, be it cpu, hdd controller, translator interface,
> dsp, etc.. I just don't think that answer really has a punch line though.

For those who understand hardware, I say that a CPLD or FPGA is like a
board full of chips of flip flops and gates.  This mind set keeps me
from the newbie mistake of "how do I wait for xx ns?" (no one-
shots!).  A simple view of a HARDWARE description Language (VHDL or
Verilog) is that it is used to describe how those gates and flops are
connected (wired).  If the FPGA is "large enough" one can make almost
anything, even a microprocessor.  I have done both simple hardware
design using 74LS chips in the past (but now I prefer CPLDs), and I do
software programming in embedded systems, too.  I understand how
peripheral chips work, but I suspect that many programmers don't
understand hardware.  When I started VHDL programming, I did have to
remind myself that I was designing hardware, even though I was writing
code that kinda looked like Pascal or Ada.
-Dave Pollum

Article: 130673
Subject: Re: ISE 10.1 - Initial experience
From: "A.D." <isd_mod@libero.ix>
Date: Sun, 30 Mar 2008 06:27:43 GMT
Links: << >>  << T >>  << A >>
emeb <ebrombaugh@gmail.com> wrote in message
06f833f3-110b-427c-baa2-96c012ea2e80@d21g2000prf.googlegroups.com...
> Summary: 10.1 isn't working as well as 9.2.04. I'll probably
> be shelving it and waiting for the service pack.

What about the IDE?
From ISE 8.1 it became increasingly heavier and slower
"per se", without adding any relevant new feature. While
main tools (XST, P&R, etc.) improved a lot over
time, the IDE simply get slower and slower, requiring
a lot of resources just for opening the project naigator...
I hope ISE 10.1 represent an inversion to this trend.
(Ok, I know, you can use third party tools or just
command line, but if this is the final result it would be
better instead to maintain it as light and efficient as
possible...)

Antonio




Article: 130674
Subject: Re: ISE 10.1 - Initial experience
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 00:01:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Mrz., 03:07, austin <aus...@xilinx.com> wrote:
> Jim,
>
> I agree, but you do need to get feedback, somehow.
>
> Yes, as a practical matter, when I was using FPGA devices to solve
> problems, and trying to make money doing so, I would NEVER use an
> initial release, but I would always freeze the development of a product
> at some previous release.
>
> "New software" = ? (a potential for risk): be it Microsoft, Xilinx, or IBM.
>
> However, the new release always has benefits, so I would have one
> engineer looking at the new release, so we would be "ready" when the
> time came to freeze for the next real product.
>
> I do not think any engineering manager is doing much different today.
>
> You need something stable, and known, to develop the product (in order
> to manage the risks).
>
> You also need the new release to support the new families and features
> you need for the next product family.
>
> And, the vendor needs to know what is working, and what is broken.
>
> So, (to everyone), keep the feedback coming, (life goes on)
>
> Austin

Austin,

just saying it the nth time again - Xilinx should do REAL beta-testing
BEFORE the releases!
not doing it the microsoft way and and release untested versions and
use ALL the client as beta-testers.

Antto







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