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 144325

Article: 144325
Subject: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: whygee <yg@yg.yg>
Date: Thu, 26 Nov 2009 17:41:30 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> you cant get it all.
> getting GOOD smd oscillators at 0.50$ at low qty
While we're speaking about oscillators, I have a couple
of remarks :

  - power consumption : I see that many osc draw from 6 to 32mA
(depending on some factors). That's a lot ! I know it is specified
for a 15pf load and a short trace to a FPGA pin won't draw as much,
but it's still an order of magnitude above what I imagined.
I can choose a lower frequency (like 3.5458MHz) to reduce the
toggle rate but are there other methods ? Can a discrete
oscillator consume less ? I doubt, but I could compare with
circuits based on the SN74LVC2G14 or LMV7219.

  - output signal : my first proto used a 25MHz osc,
directly connected to the PLL input pin of the A3P250.
I checked that it worked with my 'scope and I saw a distorded
signal with almost 1V of undershoot and overshoot.
The trace is short (15mm ?) so no such effect should occur.
I added a series SMT resistor (68 Ohms that I had around)
and the trace looked better. I have not seen schematics
that add a series resistor (I analysed Actel's and ACME's
boards), and I have never heard about oscillator overshoot.
The power rails are abundantly decoupled and the PLL works
well with the serie resistor. Did I miss something ?


> Antti
yg
-- 
http://ygdes.com / http://yasep.org

Article: 144326
Subject: Re: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 26 Nov 2009 09:30:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 26, 6:41=A0pm, whygee <y...@yg.yg> wrote:
> Antti wrote:
> > you cant get it all.
> > getting GOOD smd oscillators at 0.50$ at low qty
>
> While we're speaking about oscillators, I have a couple
> of remarks :
>
> =A0 - power consumption : I see that many osc draw from 6 to 32mA
> (depending on some factors). That's a lot ! I know it is specified
> for a 15pf load and a short trace to a FPGA pin won't draw as much,
> but it's still an order of magnitude above what I imagined.
> I can choose a lower frequency (like 3.5458MHz) to reduce the
> toggle rate but are there other methods ? Can a discrete
> oscillator consume less ? I doubt, but I could compare with
> circuits based on the SN74LVC2G14 or LMV7219.
>
> =A0 - output signal : my first proto used a 25MHz osc,
> directly connected to the PLL input pin of the A3P250.
> I checked that it worked with my 'scope and I saw a distorded
> signal with almost 1V of undershoot and overshoot.
> The trace is short (15mm ?) so no such effect should occur.
> I added a series SMT resistor (68 Ohms that I had around)
> and the trace looked better. I have not seen schematics
> that add a series resistor (I analysed Actel's and ACME's
> boards), and I have never heard about oscillator overshoot.
> The power rails are abundantly decoupled and the PLL works
> well with the serie resistor. Did I miss something ?
>
> > Antti
>
> yg
> --http://ygdes.com/http://yasep.org

canned oscillator make extreme power supply noise, and their output
can easy overshoot as well

I had a design(protoboard) where 100mhz canned oscillator did give
such noise that the Spartan 3E
did constantly return Virtex-4 JTAG ID, problems was noise on VCCINT
(from the osciallor, passing
via LDO or GND)

series resistor is not un-common, and local inductor-cap or res-cap on
osc supply is always a good idea

so small inverter with crystal may be a better option

Antti





Article: 144327
Subject: Re: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: whygee <yg@yg.yg>
Date: Thu, 26 Nov 2009 19:00:59 +0100
Links: << >>  << T >>  << A >>
Hi,

Antti wrote:
> canned oscillator make extreme power supply noise, and their output
> can easy overshoot as well
This is never explained in the datasheets.
but when a small thing like that draws 32mA,
it rings an alarm bell...

> I had a design(protoboard) where 100mhz canned oscillator did give
> such noise that the Spartan 3E did constantly return Virtex-4 JTAG ID,
 > problems was noise on VCCINT (from the osciallor, passing via LDO or GND)
OK, I have an inductor on the Vpll but not for the supply of the osc.
It would not solve the overshoot problem, because this probably comes
from the crystal itself, it looks unbuffered.
Then if this is the case, the output is probably unsufficiently
capacitively loaded ?

> series resistor is not un-common, and local inductor-cap or res-cap on
> osc supply is always a good idea
I'll add an inductor next time, a resistor seems unsufficient.

> so small inverter with crystal may be a better option
now, the questions are
  - how to correctly tune the circuit ?
      by a strange coincidence I just got an old frequency meter
      but this device certainly requires a good recalibration :-/
  - how to be sure that the circuit consumes less ?
      well... we'll have to measure. But hints are welcome...

> Antti
yg

-- 
http://ygdes.com / http://yasep.org

Article: 144328
Subject: Re: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: -jg <jim.granville@gmail.com>
Date: Thu, 26 Nov 2009 10:30:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 5:41=A0am, whygee <y...@yg.yg> wrote:
> Can a discrete oscillator consume less ?

Yes, but you need care.

Numbers from a 74LVC1GX04 on the test bench :
http://pdf.dzsc.net.cn/CAR/CARD_74LVC1GX04.pdf

Xtal: 25.8MHz
Vcc_Start =3D 1.3V
Vcc_stop  =3D 0.9V
Icc@1.8V  =3D 1.93mA  [6MHz ~ 500uA]
Icc@2.5V =3D 4.04mA
Icc@3.3V  =3D 8.26mA

-jg

Article: 144329
Subject: Re: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: whygee <yg@yg.yg>
Date: Thu, 26 Nov 2009 19:45:50 +0100
Links: << >>  << T >>  << A >>
-jg wrote:
> On Nov 27, 5:41 am, whygee <y...@yg.yg> wrote:
>> Can a discrete oscillator consume less ?
> Yes, but you need care.
of course ...

> Numbers from a 74LVC1GX04 on the test bench :
> http://pdf.dzsc.net.cn/CAR/CARD_74LVC1GX04.pdf
I know this circuit already.
But it is as expensive as a cheap osc :-/
(at least from my resellers)

> Xtal: 25.8MHz
> Vcc_Start = 1.3V
> Vcc_stop  = 0.9V
> Icc@1.8V  = 1.93mA  [6MHz ~ 500uA]
> Icc@2.5V = 4.04mA
> Icc@3.3V  = 8.26mA

Sweeeeet !
So if I use a 3.6468MHz crystal, it will draw even less.
I could use the 1.5V core voltage as well
but it will require some capacitive coupling
and some resistors for level translation to 3.3V-land.

What about frequency stability ?

> -jg
yg

-- 
http://ygdes.com / http://yasep.org

Article: 144330
Subject: Re: some issues with canned oscillators (was Re: 32KHz RTC for FPGA)
From: -jg <jim.granville@gmail.com>
Date: Thu, 26 Nov 2009 12:28:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 7:45=A0am, whygee <y...@yg.yg> wrote:
>
> What about frequency stability ?

You get what you pay for :)

If you need 2.5ppm, then you have to get a TCXO.
(eg the FOX924 series - 6mA Icc is good for a TCXO)

Simple Crystals are usually 50ppm-100ppm, and you ADD the tempco
curves on top of that.

You can pay more, and get down to 10ppm initial, but that still leaves
the tempco curves...

The advantage of using a OscModule, is you can usually choose what
Price/ppm balance your product needs, without a PCB change. (or, offer
a premium product model, with a TXCO)

Most important step: What ppm do you ACTUALLY NEED ?

-jg

Article: 144331
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 26 Nov 2009 14:09:50 -0800
Links: << >>  << T >>  << A >>
rOn Thu, 26 Nov 2009 12:05:24 -0000, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:

>YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>

This maybe true to some extent

>The tools aren't designed to handle/analyse them.

but this is simple not true in general, especially for the analyse
case. Here is what a timing report from Xilinx flow looks like:

=========================================
Timing constraint: TS_clkdiv2 = PERIOD TIMEGRP "clkdiv2" TS_clk / 2
HIGH 50%;
 9 paths analyzed, 9 endpoints analyzed, 8 failing endpoints
 8 timing errors detected. (8 setup errors, 0 hold errors, 0 component
switching limit errors)
 Minimum period is   3.108ns.
--------------------------------------------------------------------------------
Slack (setup path):     -0.608ns (requirement - (data path - clock
path skew + uncertainty))
  Source:               datar1_6 (FF)
  Destination:          dataout_6 (FF)
  Requirement:          2.500ns
  Data Path Delay:      0.971ns (Levels of Logic = 0)
  Clock Path Skew:      -2.102ns (1.205 - 3.307)
  Source Clock:         clk_BUFGP rising at 0.000ns
  Destination Clock:    clkdiv2 rising at 2.500ns
  Clock Uncertainty:    0.035ns
...


So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
of timing the source and target clock delays and reporting a path
between the two clocks correctly. Whether you are interested/capable
of fixing this issue is another problem but I don't think it's
necessary to blame the tools, at least not anymore.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144332
Subject: Re: Development boards for CPU development ?
From: =?UTF-8?B?SsO8cmdlbiBCw7ZobQ==?= <jboehm@gmx.net>
Date: Thu, 26 Nov 2009 23:20:58 +0100
Links: << >>  << T >>  << A >>
Jurgen Defurne wrote:
> I have a hobby project which consists of developing a complete
> computer system from the ground up. With complete I mean that it
> should have character display capabilities, keyboard input
> capabilities and mass storage capabilities. Graphics and networking
> might come in the future, but I feel that adding these is probably
> more a team effort than a single person effort, and I need time first
> to implement what should be a reasonable system stack.
> 
> This is what I mean with from the ground up : a system stack
> consisting of an ISA, a simulator for the ISA and processor
> architecture, basic display and keyboard capabilities for the
> simulator, and system software which is based on Lisp. I have already
> the simulator running, together with the IO capabilities and an
> assembler.
> 

Maybe you would like to take a look at

http://www.aviduratas.de/lisp/lispmfpga/


> 
> Regards,
> 
> Jurgen


Greetings


Jürgen



-- 
Jürgen Böhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom

Article: 144333
Subject: Altera SerialLite II configuration
From: rreuter@gmx.net
Date: Thu, 26 Nov 2009 22:43:57 -0800 (PST)
Links: << >>  << T >>  << A >>
I would like to use SerialLite II on Altera Cyclone IV GX22 (when
available). I already studied the literature, and there's an open
question concerning configuration of the SerialLite interface:
I plan to use all 4 high-speed transceivers in unidirectional
transmitter mode to send bursts of image data (I've an additional low-
speed control path where I can return link status and errors), and
want to include the link layer for package encapsulation, CRC, lane
striping; I do not need priority packets, retry-on-error handling,
flow control. So in my opinion there is no need for a high-speed
receiver line. Nevertheless the Quartus MegaWizard Plug-In Manager
does not allow this configuration. In transmitter only mode it
restricts the number of lanes to 1, saying "the number of lanes is
limited to 1 while Self-Synchronized Link-Up is enabled" - but I
cannot disable it. In bidirectional mode the selectable number of
receivers is >= 1. Obviously, the 4 transmitters only configuration is
not supported? Why and how to solve? Who can help?

Thanks, Roland.

Article: 144334
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 27 Nov 2009 10:20:14 -0000
Links: << >>  << T >>  << A >>
> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
> of timing the source and target clock delays and reporting a path
> between the two clocks correctly. Whether you are interested/capable
> of fixing this issue is another problem but I don't think it's
> necessary to blame the tools, at least not anymore.


Aye, that was badly worded, although I wouldn't fancy having to get a
design working with a multitude of ripple clocks driving between
clock domains!



Nial




Article: 144335
Subject: Re: webpack crashed how do I get these things back?
From: Gabor <gabor@alacron.com>
Date: Fri, 27 Nov 2009 10:01:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 25, 5:33=A0pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
> webpack crashed whilst synthesising my design. This is the first time
> that I have had this. I have managed to get the design to synthesise
> properly and do a p&r netlist. I didn't change the design.
>
> The things that are missing are mainly cosmetic but I would like to
> reinstate them. The snapshot list is blank. I can see a snapshot
> directory and there are files inside it. How do I get webpack to
> re-create the snapshot area? When I do a synthesis run I don't get an
> errors/warnings report. Yes I can look at the synthesis log. It would be
> good to get the list of errors and warnings on the design summary page.
>
> Any ideas/pointers. Thanks in advance Andy

If you're running ISE version 10.1 you should have a restore
script for the project <project_name>.restore

Instructions for regenerating the project from the restore
script are inside the script.  Basically:
In the GUI click the TCL Shell tab
change the directory to your project directory
type "source <project_name>.restore"
type "restore"

If you're lucky and the original restore file hasn't
already been clobbered, you should get back all of
your settings.

Regards,
Gabor

Article: 144336
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 27 Nov 2009 12:23:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 26, 5:09=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> This maybe true to some extent
>

Yes...to the extent that you want to have a working, robust design in
the end...to that extent.  If that's not where you're trying to get
to, then generate all of the clocks that you want.

> >The tools aren't designed to handle/analyse them.
>
> but this is simple not true in general, especially for the analyse
> case. Here is what a timing report from Xilinx flow looks like:
>

Nial wasn't quite correct about the analyze portion of his statement.
The tools certainly can analyze them, what he was getting at is that
you just shouldn't use them.  The issue is that there will be a skew
between a flop that receives the master clock and a flop that receives
ANY generated clock (whether that clock is generated combinatorially,
or is the output of a flop like in a ripple counter) and there will be
nothing you can do from a design perspective to compensate for that
skew short of hand placement and routing and cross your fingers, hope
for the best.

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Timing constraint: TS_clkdiv2 =3D PERIOD TIMEGRP "clkdiv2" TS_clk / 2
> HIGH 50%;
> =A09 paths analyzed, 9 endpoints analyzed, 8 failing endpoints
> =A08 timing errors detected. (8 setup errors, 0 hold errors, 0 component
> switching limit errors)
> =A0Minimum period is =A0 3.108ns.
> -------------------------------------------------------------------------=
--=AD-----
> Slack (setup path): =A0 =A0 -0.608ns (requirement - (data path - clock
> path skew + uncertainty))
> =A0 Source: =A0 =A0 =A0 =A0 =A0 =A0 =A0 datar1_6 (FF)
> =A0 Destination: =A0 =A0 =A0 =A0 =A0dataout_6 (FF)
> =A0 Requirement: =A0 =A0 =A0 =A0 =A02.500ns
> =A0 Data Path Delay: =A0 =A0 =A00.971ns (Levels of Logic =3D 0)
> =A0 Clock Path Skew: =A0 =A0 =A0-2.102ns (1.205 - 3.307)
> =A0 Source Clock: =A0 =A0 =A0 =A0 clk_BUFGP rising at 0.000ns
> =A0 Destination Clock: =A0 =A0clkdiv2 rising at 2.500ns
> =A0 Clock Uncertainty: =A0 =A00.035ns
> ...
>
> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
> of timing the source and target clock delays and reporting a path
> between the two clocks correctly. Whether you are interested/capable
> of fixing this issue is another problem but I don't think it's
> necessary to blame the tools, at least not anymore.

It's not apparent to me at least that the fast path was
analyzed...that's where the hold time problems will get fingered.  The
tool can probably do it (Quartus does, you have to specify it since
it's not in the 'default' analysis).

Anyway, take your ripple counter and put a heat gun or cold spray on
it and watch it change from working to not working.

Kevin Jennings

Article: 144337
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 27 Nov 2009 13:37:25 -0800
Links: << >>  << T >>  << A >>
On Fri, 27 Nov 2009 12:23:39 -0800 (PST), KJ
<kkjennings@sbcglobal.net> wrote:

>On Nov 26, 5:09pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>>
>> This maybe true to some extent
>>
>
>Yes...to the extent that you want to have a working, robust design in
>the end...to that extent.  If that's not where you're trying to get
>to, then generate all of the clocks that you want.
>

No only to the extent of simple designs which don't require much from
the designer, this is certainly good advice. There are times when a
surgical knife is required and in good hands they're an indispensible
and irreplaceble tool.

>The tools certainly can analyze them, what he was getting at is that
>you just shouldn't use them.  

I have no problem you or Nial not using them.

>there will be
>nothing you can do from a design perspective to compensate for that
>skew short of hand placement and routing and cross your fingers, hope
>for the best.
>
Again this maybe your experience base but it's certainly not true in
general. 

>It's not apparent to me at least that the fast path was
>analyzed...that's where the hold time problems will get fingered.  The
>tool can probably do it (Quartus does, you have to specify it since
>it's not in the 'default' analysis).
>
Why do you expect the tool to understand your design? It's your
responsibility to do so and specify the required timing constraints
and checks.

>Anyway, take your ripple counter and put a heat gun or cold spray on
>it and watch it change from working to not working.

I understand if that's your experience with some of your past designs
but please don't attribute it to others.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144338
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 27 Nov 2009 13:40:08 -0800
Links: << >>  << T >>  << A >>
On Fri, 27 Nov 2009 10:20:14 -0000, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:

>> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
>> of timing the source and target clock delays and reporting a path
>> between the two clocks correctly. Whether you are interested/capable
>> of fixing this issue is another problem but I don't think it's
>> necessary to blame the tools, at least not anymore.
>
>
>Aye, that was badly worded, although I wouldn't fancy having to get a
>design working with a multitude of ripple clocks driving between
>clock domains!

I don't think anyone would force you to  do something which you're
uncomfortable doing. It's certainly easier to work with single
synchronous clock but it's possible to do with multiple generated ones
too.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144339
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 27 Nov 2009 14:52:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 4:37=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> >On Nov 26, 5:09=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> >> This maybe true to some extent
>
> >Yes...to the extent that you want to have a working, robust design in
> >the end...to that extent. =A0If that's not where you're trying to get
> >to, then generate all of the clocks that you want.
>
> No only to the extent of simple designs which don't require much from
> the designer, this is certainly good advice.

Hand placement and routing is the only other way to get there.  That
was an effective and productive technique in the 80s and 90s when the
place and route tools weren't that good, not today.

You've also got it backwards since only the 'simple designs' or the
'cost is no concern' designs might be able to afford this kind of
additional effort.  Neither of those scenarios is typical.

> There are times when a
> surgical knife is required and in good hands they're an indispensible
> and irreplaceble tool.
>

A ripple counter is not a 'surgical knife' nor an 'irreplaceble tool',
it is just a ripple counter.  Trying to make it sound like something
only to be understood by the high priests is a load of you-know-what,
stick to actual specifics of the topic.  What a ripple counter brings
along is
1. Generally less logic than a synchronous counter
2. Generally less power consumption than a synchronous counter
3. Generally can be clocked faster than a synchronous counter
4. Generally more propagation delay than a synchronous counter
5. Generally more timing uncertainty in when the outputs are valid
than a synchronous counter to the point that there may be no time when
it is even theoretically possible to sample the counter output
accurately.

While one can always contrive a problem where the benefits of #1, #2
and #3 outweigh the drawbacks of #4 and #5, when you're operating in
an FPGA environment, those opportunities are at best very rare,
possibly non-existent.  The additional baggage of having to hand tweak
each design revision that adds some new feature makes for a fragile
design.

> >The tools certainly can analyze them, what he was getting at is that
> >you just shouldn't use them. =A0
>
> I have no problem you or Nial not using them.
>

OK...not that either of us, or anyone else for that matter needs your
blessing.

> >there will be
> >nothing you can do from a design perspective to compensate for that
> >skew short of hand placement and routing and cross your fingers, hope
> >for the best.
>
> Again this maybe your experience base but it's certainly not true in
> general.
>

It has nothing to do with anyone's 'experience', it has only to do
with the absolute basics:
1. The output of any flip flop will not change until some delay after
the input clock has changed
2. It is quite possible for the delay from #1 plus the routing delay
to get to some other flop to use as a clock (even on an adjacent logic
block) may exceed the delay of some other logic signal to the 'D'
input of that other flop...that's a hold time violation.  In an FPGA
environment, the ONLY mechanism to control this skew is hand placement
and routing.
3. Hand place/route is costly (designer time =3D money)
4. Free running counters that have no outside control are not of much
use.
5. Any  control of counters comes from clock domains other than the
plethora of clock domains created by the ripple counter.

So, if you want to refute any of the above points, feel free to do so
rather than being fuzzy about 'experiences'.

> >It's not apparent to me at least that the fast path was
> >analyzed...that's where the hold time problems will get fingered. =A0The
> >tool can probably do it (Quartus does, you have to specify it since
> >it's not in the 'default' analysis).
>
> Why do you expect the tool to understand your design? It's your
> responsibility to do so and specify the required timing constraints
> and checks.
>

1. Specifying timing constraints does not guarantee you a working
design.  After the fact, it tells you when your design has a problem
because it is an *analysis* step.
2. Timing constraints can not change a setup or hold time problem on a
ripple counter into a working design.  The only thing that can do that
is hand place and route or getting lucky.
3. As it relates to ripple counters, ANY design specific constraints
exist only to allow the timing analyzer to ignore what it would
ordinarily flag as an error.
4. No tool exists to validate that any timing constraints are actually
correct.

Again, feel free to refute any of the above.

> >Anyway, take your ripple counter and put a heat gun or cold spray on
> >it and watch it change from working to not working.
>
> I understand if that's your experience with some of your past designs
> but please don't attribute it to others.

Those are my experiences when working with other people's async
designs, I didn't attribute anything to anyone.

I simply suggested that if someone thinks that they have a working
FPGA design that uses asynchronous design techniques such as a ripple
counter, than they should try running that design over the full
temperature range of the part and verify whether or not the design is
still 'working'.

Kevin Jennings

Article: 144340
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 27 Nov 2009 15:16:00 -0800
Links: << >>  << T >>  << A >>
On Fri, 27 Nov 2009 14:52:32 -0800 (PST), KJ
<kkjennings@sbcglobal.net> wrote:

>On Nov 27, 4:37pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >On Nov 26, 5:09pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>>
>> >> This maybe true to some extent
>>
>> >Yes...to the extent that you want to have a working, robust design in
>> >the end...to that extent. If that's not where you're trying to get
>> >to, then generate all of the clocks that you want.
>>
>> No only to the extent of simple designs which don't require much from
>> the designer, this is certainly good advice.
>
>Hand placement and routing is the only other way to get there.  

I think you should add the caveat "that you know of" at the end of
that statement. Your response might be "tell me what else" but I
already spent more time than it's worth here.

>> >there will be
>> >nothing you can do from a design perspective to compensate for that
>> >skew short of hand placement and routing and cross your fingers, hope
>> >for the best.
>>
>> Again this maybe your experience base but it's certainly not true in
>> general.
>>
>
>It has nothing to do with anyone's 'experience', it has only to do
>with the absolute basics:
>1. The output of any flip flop will not change until some delay after
>the input clock has changed
>2. It is quite possible for the delay from #1 plus the routing delay
>to get to some other flop to use as a clock (even on an adjacent logic
>block) may exceed the delay of some other logic signal to the 'D'
>input of that other flop...that's a hold time violation.  In an FPGA
>environment, the ONLY mechanism to control this skew is hand placement
>and routing.

You seem to be under the impression that in today's FPGAs the clock
trees are absolutely perfect zero-skew and the FPGA PAR tools don't
have to do any hold fixes. I don't think that ever was the case but
today with 45nm processes and 10s if not hundreds of mmsq die sizes
that's definitely not true anymore. Open a timing report of any decent
size design and look at a certain path to see what the delays of the
clocks are. Also pay attention to what PAR is telling you in later
stages of the routing. 
FPGA tools try to hide most of the complexity of digital design and
give the illusion of a simple environment but this is not true in
reality and certainly limits the amount of design capabilities one
has.

>4. No tool exists to validate that any timing constraints are actually
>correct.
>Again, feel free to refute any of the above.

I am not sure how we got from divided clocks to ripple counters so
I'll discount the other comments but this one is certainly wrong. You
don't seem to think so but making such strong and wrong statements is
an indication of one's experience. There are no real zero-skew clock
trees, FPGA flops are not zero-hold and FPGA routers do hold fixing
and yes there are tools which can analyze your design and verify  your
constraints. The fact that you don't know about them doesn't make them
disappear.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144341
Subject: Re: webpack crashed how do I get these things back?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 28 Nov 2009 07:36:55 +0000
Links: << >>  << T >>  << A >>
On Fri, 27 Nov 2009 10:01:03 -0800 (PST), Gabor <gabor@alacron.com> wrote:

>On Nov 25, 5:33pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote:
>> webpack crashed whilst synthesising my design. 
...
>> Any ideas/pointers. Thanks in advance Andy
>
>If you're running ISE version 10.1 you should have a restore
>script for the project <project_name>.restore

>If you're lucky and the original restore file hasn't
>already been clobbered, you should get back all of
>your settings.

Trouble is, running ISE to discover the broken project file, you are liable to
rewrite the .restore file...

- Brian

Article: 144342
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: "HT-Lab" <hans64@ht-lab.com>
Date: Sat, 28 Nov 2009 10:32:13 -0000
Links: << >>  << T >>  << A >>

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:7eb143ac-bc28-489b-a753-b7c9469c5a27@d21g2000yqn.googlegroups.com...
On Nov 27, 4:37 pm, Muzaffer Kal <k...@dspia.com> wrote:
> >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> No only to the extent of simple designs which don't require much from
> the designer, this is certainly good advice.
>
>A ripple counter is not a 'surgical knife' nor an 'irreplaceble tool',
>it is just a ripple counter.  Trying to make it sound like something
>only to be understood by the high priests is a load of you-know-what,
>stick to actual specifics of the topic.  What a ripple counter brings
>along is
>1. Generally less logic than a synchronous counter
>2. Generally less power consumption than a synchronous counter
>3. Generally can be clocked faster than a synchronous counter

Right and this is the reason why they are used in ASIC designs and why Muzaffer 
is experienced with them.  However, it might not be the best design style for an 
FPGA and hence high-end synthesis tools like Precision automatically translates 
rippled counters to their synchronous equivalent (part of their ASIC ->FPGA 
prototyping conversion).

Hans.
www.ht-lab.com





Article: 144343
Subject: vga in virtex 4
From: "lalop" <euardop@yahoo.com.mx>
Date: Sat, 28 Nov 2009 08:29:36 -0600
Links: << >>  << T >>  << A >>
I am an electronics student and pretty new in FPGAs' use.

I am interested in to send images to a monitor from the FPGA. 
I have already performed a test using the Spartan 3 xilinx board based on
an example I found at the Internet and it worked perfectly. Now I am trying
to translate the same example to the ML405 xilinx board, however it doesn't
work correctly. 

I wonder if someone could give me a hand to solve this problem. I add my
vhdl code and ucf file

lalo




library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity top is
port(clk100_in  : in std_logic;
       red_out   : out std_logic_vector(4 downto 0);
       green_out : out std_logic_vector(4 downto 0);
       blue_out  : out std_logic_vector(4 downto 0);
       hs_out    : out std_logic;
       vs_out    : out std_logic);
end top;

architecture Behavioral of top is


signal clk25 : std_logic;
signal clk50 : std_logic;
signal hcounter : integer range 0 to 800;
signal vcounter   : integer range 0 to 521;
signal color: std_logic_vector(2 downto 0);


begin


-- generate a 50Mhz clock
process (clk100_in)
begin
  if clk100_in'event and clk100_in='1' then
    clk50 <= not clk50;
  end if;
end process;


-- generate a 55Mhz clock
process (clk50)
begin
  if clk50'event and clk50='1' then
    clk25 <= not clk25;
  end if;
end process;

-- change color every one second
p1: process (clk25)
	variable cnt: integer;
begin
	if clk25'event and clk25='1' then
		cnt := cnt + 1;
		if cnt = 25000000 then
			color <= color + "001";
			cnt := 0;
		end if;
	end if;
end process;

p2: process (clk25, hcounter, vcounter)
	variable x: integer range 0 to 639;
	variable y: integer range 0 to 479;
begin
	-- hcounter counts from 0 to 799
	-- vcounter counts from 0 to 520
	-- x coordinate: 0 - 639 (x = hcounter - 144, i.e., hcounter -Tpw-Tbp)
	-- y coordinate: 0 - 479 (y = vcounter - 31, i.e., vcounter-Tpw-Tbp)
	x := hcounter - 144;
	y := vcounter - 31;
  	if clk25'event and clk25 = '1' then
 		-- To draw a pixel in (x0, y0), simply test if the ray trace to it
		-- and set its color to any value between 1 to 7. The following example
simply sets 

		-- the whole display area to a single-color wash, which is changed every
one 
		-- second. 	
	 	if x < 640 and y < 480 then
--      	red_out  <= "0000" & color(0);
--      	green_out<= "0000" & color(1); 
--      	blue_out <= "0000" & color(2);
			red_out  <= "11111";
      	green_out<= "11111";
      	blue_out <= "11111";
    	else
			-- if not traced, set it to "black" color
      	red_out  <= "00000";
      	green_out<= "00000";
      	blue_out <= "00000";
    	end if;
		-- Here is the timing for horizontal synchronization.
		-- (Refer to p. 24, Xilinx, Spartan-3 Starter Kit Board User Guide)
	 	-- Pulse width: Tpw = 96 cycles @ 25 MHz
	 	-- Back porch: Tbp = 48 cycles
		-- Display time: Tdisp = 640 cycles
	 	-- Front porch: Tfp = 16 cycles
		-- Sync pulse time (total cycles) Ts = 800 cycles

    	if hcounter > 0 and hcounter < 97 then
      	hs_out <= '0';
    	else
      	hs_out <= '1';
    	end if;
		-- Here is the timing for vertical synchronization.
		-- (Refer to p. 24, Xilinx, Spartan-3 Starter Kit Board User Guide)
	 	-- Pulse width: Tpw = 1600 cycles (2 lines) @ 25 MHz
	 	-- Back porch: Tbp = 23200 cycles (29 lines)
		-- Display time: Tdisp = 38400 cycles (480 lines)
	 	-- Front porch: Tfp = 8000 cycles (10 lines)
		-- Sync pulse time (total cycles) Ts = 416800 cycles (521 lines)
    	if vcounter > 0 and vcounter < 3 then
      	vs_out <= '0';
    	else
      	vs_out <= '1';
    	end if;
	 	-- horizontal counts from 0 to 799
    	hcounter <= hcounter+1;
    	if hcounter = 800 then
      	vcounter <= vcounter+1;
      	hcounter <= 0;
    	end if;
	 	-- vertical counts from 0 to 519
    	if vcounter = 521 then		    
      	vcounter <= 0;
    	end if;
  end if;
end process;

end behavioral;




Net "clk100_in"    Loc = "AB14";


#------------------------------------------------------------------------------
# Viretex-4 VGA P2 Port:

#------------------------------------------------------------------------------

#RED
# LOC = R6; #VGA_R0
# LOC = R7; #VGA_R1
#NET red_out<0> LOC = P9; #VGA_R2
NET red_out<0> LOC = F3; #VGA_R3
NET red_out<1> LOC = H7; #VGA_R4
NET red_out<2> LOC = E3; #VGA_R5
NET red_out<3> LOC = G5; #VGA_R6
NET red_out<4> LOC = D3; #VGA_R7
# drive strength and speed for VGA
NET red_out<*> SLEW = FAST;
NET red_out<*> DRIVE = 8;

#GREEN
# LOC = N9; #VGA_G0
# LOC = N6; #VGA_G1
#NET green_out<0> LOC = P6;  # VGA_G2
NET green_out<0> LOC = J3;  # VGA_G3
NET green_out<1> LOC = K7;  # VGA_G4
NET green_out<2> LOC = K3;  # VGA_G5
NET green_out<3> LOC = G10; # VGA_G6
NET green_out<4> LOC = K6;  # VGA_G7
# drive strength and speed for VGA
NET green_out<*> SLEW = FAST;
NET green_out<*> DRIVE = 8;

#BLUE
# LOC = P10; #VGA_B0
# LOC = P11; #VGA_B1
#NET blue_out<0> LOC = P8;  # VGA_B2
NET blue_out<0> LOC = F4;  # VGA_B3
NET blue_out<1> LOC = J4;  # VGA_B4
NET blue_out<2> LOC = G9;  # VGA_B5
NET blue_out<3> LOC = J5;  # VGA_B6
NET blue_out<4> LOC = H3;  # VGA_B7
# drive strength and speed for VGA
NET blue_out<*> SLEW = FAST;
NET blue_out<*> DRIVE = 8;

NET clk25  LOC = AC7;  #VGA_CLK
NET clk25  IOSTANDARD = LVDCI_33;
NET clk25  SLEW = FAST;
NET clk25  DRIVE = 8;


NET hs_out LOC = C3;   #HSYNC
NET hs_out SLEW = FAST;
NET hs_out DRIVE = 8;



NET vs_out LOC = D4;	#VSYNC
NET vs_out SLEW = FAST;
NET vs_out DRIVE = 8;















Article: 144344
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 28 Nov 2009 06:37:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 6:16=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> >> >> This maybe true to some extent
>
> >> >Yes...to the extent that you want to have a working, robust design in
> >> >the end...to that extent. =A0If that's not where you're trying to get
> >> >to, then generate all of the clocks that you want.
>
> >> No only to the extent of simple designs which don't require much from
> >> the designer, this is certainly good advice.
>
> >Hand placement and routing is the only other way to get there. =A0
>
> I think you should add the caveat "that you know of" at the end of
> that statement. Your response might be "tell me what else" but I
> already spent more time than it's worth here.
>

No need for any caveats.  I covered the reasons in the list of points
starting with "The output of any flip flop will not change..." and
asked you to refute anything that is not accurate, you came up empty.

Apparently you'd like people here to believe that you know of
something that will guarantee proper operation of a ripple counter in
an FPGA that does not involve any form of hand place/route.  Since you
haven't refuted any of my points and you haven't backed up your own
claim, I'll simply leave it at that as speaking quite clearly about
your claim.

> >It has nothing to do with anyone's 'experience', it has only to do
> >with the absolute basics:
> >1. The output of any flip flop will not change until some delay after
> >the input clock has changed
> >2. It is quite possible for the delay from #1 plus the routing delay
> >to get to some other flop to use as a clock (even on an adjacent logic
> >block) may exceed the delay of some other logic signal to the 'D'
> >input of that other flop...that's a hold time violation. =A0In an FPGA
> >environment, the ONLY mechanism to control this skew is hand placement
> >and routing.
>
> You seem to be under the impression that in today's FPGAs the clock
> trees are absolutely perfect zero-skew and the FPGA PAR tools don't
> have to do any hold fixes.

No, I'm not under any of those impressions.  This is basic stuff, the
signal that is being sampled will always have a setup and hold
requirement around the time of the sampling edge.

Rather than responding to what I actually post and instead responding
to your impressions about what *you* think I may or may not know, is a
sign of arrogance on your part.

> Open a timing report of any decent
> size design and look at a certain path to see what the delays of the
> clocks are. Also pay attention to what PAR is telling you in later
> stages of the routing.

As it relates to the ripple counter also pay attention to what static
timing analysis is telling you for the 'minimum' delay paths and hold
times.

>
> >4. No tool exists to validate that any timing constraints are actually
> >correct.
> >Again, feel free to refute any of the above.
>
> I am not sure how we got from divided clocks to ripple counters so
> I'll discount the other comments but this one is certainly wrong.

Maybe you should read the postings to see how we got on to ripple
counters.  The originating comment has been there all along.

Discount my comments if you'd like.  I asked you to refute them if you
can, your reply speaks volumes and again implies arrogance.

Place and route may take timing constraints into account to help it do
its job, but it does guarantee that it will meet them.  If it did,
there would never be a failing timing path when it comes time to
performing static timing analysis.

> You
> don't seem to think so but making such strong and wrong statements is
> an indication of one's experience.

I'm accepting of when I've posted something incorrectly.  In this
particular thread I've also explicitly invited you to correct
something that is incorrect.  You've yet to refute any of my points
but seem to think that simply saying that I'm wrong is sufficient.
Good luck using that tact.

> and yes there are tools which can analyze your design and verify =A0your
> constraints.

You've possibly misread or misinterpreted my statement which was "No
tool exists to validate that any timing constraints are actually
correct".  I didn't say there were no tools that would take a design
and verify it meets the constraints, I said a tool that would verify
that the constraints themselves are correct.

> The fact that you don't know about them doesn't make them
> disappear.

The fact that you don't list them just makes your postings of low
information content.

> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>

Hopefully you don't represent your company with these postings.

End of Jennings' input to the Kal/Jennings thread

Kevin Jennings

Article: 144345
Subject: Re: vga in virtex 4
From: Gabor <gabor@alacron.com>
Date: Sat, 28 Nov 2009 08:27:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 28, 9:29=A0am, "lalop" <euar...@yahoo.com.mx> wrote:
> I am an electronics student and pretty new in FPGAs' use.
>
> I am interested in to send images to a monitor from the FPGA.
> I have already performed a test using the Spartan 3 xilinx board based on
> an example I found at the Internet and it worked perfectly. Now I am tryi=
ng
> to translate the same example to the ML405 xilinx board, however it doesn=
't
> work correctly.
>
> I wonder if someone could give me a hand to solve this problem. I add my
> vhdl code and ucf file
>
> lalo
>
[snip]

lalo,

  In what way doesn't it work right?  I assume you pretty much copied
the code from the other project.  You did check the pinout definitions
in your .ucf file against the board documentation?

  Does the Virtex 4 board have the same hardware for VGA output
(D/A Converter or just resistors) as the old board?  Most video
D/A Converters need a clock signal as well as synch and data.

  Your clocking is a bit of a mess.  I imagine you may have
inherited some of it from the prior project, but it's not
generally good practice to make ripple counters in an FPGA.

  Your net clk25 in the .ucf doesn't correspond to a top
module port.  Is this supposed to drive the D/A converter
clock?

Regards,
Gabor



Article: 144346
Subject: Re: Going mad trying to solve PLL setup/hold timing violation issues in Quartus
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 28 Nov 2009 09:44:40 -0800
Links: << >>  << T >>  << A >>
On Sat, 28 Nov 2009 06:37:19 -0800 (PST), KJ
<kkjennings@sbcglobal.net> wrote:

>> and yes there are tools which can analyze your design and verify your
>> constraints.
>
>You've possibly misread or misinterpreted my statement which was "No
>tool exists to validate that any timing constraints are actually
>correct".  I didn't say there were no tools that would take a design
>and verify it meets the constraints, I said a tool that would verify
>that the constraints themselves are correct.

What was said was quite clear and there are such tools. Here is one
example: http://www.bluepearlsoftware.com/products/azure.html

>> The fact that you don't know about them doesn't make them
>> disappear.
>
>The fact that you don't list them just makes your postings of low
>information content.

The web is full of information. You should spend some time to acquire
some on your own.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 144347
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Claytong_nz <clayton@isnotcrazy.com>
Date: Sun, 29 Nov 2009 01:42:22 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Jonathan,

Fred Kennedy, who is the leader of this project, has managed to
arrange for someone to pick up the programmer from you, at a time to
suit you. I think Fred has already contacted you. If not, his details
are Fred Kennedy email fredk@kcbbs.gen.nz
Again thank you for your assistance here.

Regards
Clayton



On Nov 26, 8:16=A0am, Claytong_nz <clay...@isnotcrazy.com> wrote:
> On Nov 26, 1:10=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
>
>
> > On Wed, 25 Nov 2009 03:30:36 -0800 (PST), Claytong_nz wrote:
> > >These FPGAs are apparently okay in low earth orbit. My understanding
> > >is that they are already up there and working fine - at least the
> > >older technologies such as this part
>
> > yeah, I guess they are fairly bulletproof (antifuse, 0.18um, ...)
>
> > >now hand-tied by ITAR - hence the US guys are not permitted to help
>
> > sheesh!
>
> > >I'd like to take you up on your programmer offer
>
> > I'd be happy to see it go to a good home; I don't see myself ever
> > using it again. =A0You get three or four 12x16B 84PLCC thrown in :-)
> > And I'll try to find my archived copy of the software, but
> > no promises on that; I haven't used it for years.
>
> > > (or possibly purchasing it)
>
> > Nah, you can have it - but we need to find a shipment method
> > that doesn't cost me anything, and doesn't cost you very much.
>
> > >BTW, where are you?
>
> > Oxford, England - but working in Munich, Germany for much of
> > the next few weeks.
> > --
> > Jonathan Bromley, Verification Engineer
>
> > Verilab =A0www.THAT_COMPANY.com
>
> Thank you. Your offer is very much appreciated Jonathan. I'll see if
> we can find someone local to you to collect or some other arrangement.
>
> Clayton


Article: 144348
Subject: Re: Help needed with Quicklogic QL8X12B-1PL68M tools and programmer
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sun, 29 Nov 2009 14:00:02 +0100
Links: << >>  << T >>  << A >>
On Sun, 29 Nov 2009 01:42:22 -0800 (PST), Claytong_nz wrote:

>Fred Kennedy, who is the leader of this project, has managed to
>arrange for someone to pick up the programmer from you

Cool.  I'll ping him today.

> Fred Kennedy email fredk@<snip>

I hope he has a good spamtrap :-)

>Again thank you for your assistance here.

As I said, it's a pleasure to see it going to good use.
-- 
Jonathan Bromley, Verification Engineer

Verilab   www.THAT_COMPANY.com

Article: 144349
Subject: chipscope in edk
From: "gentel" <gentel86@163.com>
Date: Sun, 29 Nov 2009 07:25:36 -0600
Links: << >>  << T >>  << A >>
hi,all
     i am facing a problem when obtaining port signals with chipscope in
edk. I can get only one  right data from ports,but following samples(total
16384 samples) are in high status (High-impedance state)at all ports ,then
the signal data are 1,8,64,0(width=8 port)or 0,2,16,128,1024,8192 (width=16
port) and so on.then these data display  with loop. what is the problem?
who can help me.
thanks in advance..	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com



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