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 146875

Article: 146875
Subject: Migrating project from Xilinx ISE v7.1 to v11.1
From: "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com>
Date: Tue, 30 Mar 2010 19:17:52 -0500
Links: << >>  << T >>  << A >>
Hello,

We are trying to migrate a fully functional project from Xilinx ISE v7.1 to
Xilinx ISE v11.1. We started off by creating a new project under v11.1 and
bringing over all the .v (verilog source) files, .ise file, .xco files and
ucf file.

The project synthesizes successfully, however when trying to Implement
design, translate fails with several of the following errors

(a) NgdBuild 924: input pad net '....' is driving non-buffer primitives
(b) NgdBuild 455: logical net '....' has multiple drivers
(c) NgdBuild 462: input pad net '....' drives multiple buffers
(d) NgdBuild 809: output pad net'....' has an illegal load

Has anyone encountered these errors in the past while migrating from an
older version of Xilinx ISE to v11.1 ? Why are these caused and how do we
get rid off these errors ?

Thanks in advance for your help,
Regards.
Vikram.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146876
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: Symon <symon_brewer@hotmail.com>
Date: Wed, 31 Mar 2010 01:24:41 +0100
Links: << >>  << T >>  << A >>
On 3/30/2010 9:41 PM, austin wrote:
> Peak to peak,
>
> Austin

Hi Austin,

Right, but is that from one cycle to the next? Or from one cycle to 
infinity? Or beyond?

My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely 
gold colour!) gives me a signal, which it is claimed has 50ns of jitter. 
That's all the spec. I get. One pulse per second comes out of this 
bugger. Should I worry? Is 50ns "a lot"?

Syms!


Article: 146877
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: Patrick Maupin <pmaupin@gmail.com>
Date: Tue, 30 Mar 2010 17:49:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 30, 7:24=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> Right, but is that from one cycle to the next? Or from one cycle to
> infinity? Or beyond?
>
> My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely
> gold colour!) gives me a signal, which it is claimed has 50ns of jitter.
> That's all the spec. I get. One pulse per second comes out of this
> bugger. Should I worry? Is 50ns "a lot"?

Heh.

Reminds me of a few years ago, when I was pressed into service to
torture (I believe "verify" is the correct word, but whenever someone
wants me to test something, they're kidding themselves if they think
I'm anything other than a pit bull.  Maybe that's why they usually
just have me writing high level system specs and designing emulation
platforms.  But I digress...) a USB 2.0 high speed receiver.

I thought the USB definition of jitter for high speed was crystal
clear -- just stack up 480 bit times worth of data vertically and see
if the template was ever violated.  But, it turns out that a designer
dedicated to proving himself "right" can find something to disagree
about even there.  He decided that (since my test case that really put
his design into a tailspin was not running at exactly the nominal 480
Mb/s) the 480 bit times you were stacking had to be at exactly 480 Mb/
s, and not at the nominal transmit frequency.  This let him "prove"
that I was exceeding the jitter tolerance, by adding drift and jitter
together to show that the signal was outside the specified template!

I showed him (well, tried to show him) that, if you used his wacky
definition, then if you took a signal that was transmitted at the edge
of the specified frequency margin, and stacked up 480 of those bit
times using nominal rather than transmitted period, you would violate
the template EVEN WITH ZERO JITTER, so that couldn't be what they
mean, right?  I never convinced him of that, but the management
understood.

I also never convinced him that when his uber-fancy data recovery lost
lock and just started spewing garbage (which it did in a rather
spectacular way when it got lost, not just losing a bit here or
there), that a 16 bit CRC was mathematically reduced to the same
efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1
out of every 65536 bad packets.

Regards,
Pat

Article: 146878
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 30 Mar 2010 18:17:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 30, 7:58=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> are you assuming a 'classic PLL' design ? - it is unlikely the FPGA
> PLLs are classic in nature, but are more likely to have 'other tricks'
> and shortcuts to integrate better in digital process.
>
> -jg

There are silicon VCOs with on-board PLLs that do a fine job with
rather standard - albiet higher frequency - phase detector schemes.
We may not have the charge pumps with two caps and a resistor but the
schemes are still somewhat standard.  Maybe it's done very different
in the FPGA realm.

Article: 146879
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: rpw3@rpw3.org (Rob Warnock)
Date: Tue, 30 Mar 2010 20:41:10 -0500
Links: << >>  << T >>  << A >>
MitchAlsup  <MitchAlsup@aol.com> wrote:
+---------------
| The most memorable hardware structure is the vector indirect
| addressing mode.
+---------------

I was always rather fond of the PDP-10's multi-level indirect addressing
which allowed additional indexing with a different accumulator at each
level of indirection, and how that permitted multi-dimension array indexing
to be done in a *single* instruction, albeit requiring auxiliary Iliffe
vectors for the arrays [as was done in ALGOL-10]. Quoting myself:

    Newsgroups: alt.folklore.computers
    Date: Sun, 30 Aug 2009 06:03:04 -0500
    From: rpw3@rpw3.org (Rob Warnock)
    Subject: Re: PDP-10 Assembly Language Questions
    Message-ID: <HrWdnRhVz531wQfXnZ2dnUVZ_v6dnZ2d@speakeasy.net>
    ...
    For, say, a three-dimensional array, if A, B, & C were already
    in the proper registers, then "FOO[A,B,C] := FOO[A,B,C] + 1"
    could be done in *one* instruction!! (No joke!)
    What, you don't believe me?  ;-}  Here's the code:

    MOVE  T1,A          ; Load up the array indices
    MOVE  T2,B
    MOVE  T3,C
    AOS   @FOO(T1)      ; Increment FOO[A,B,C] (and don't skip).

[Assumes the first level of Iliffe vectors has the indirect-addressing
bit on and "T2" in the index field, and the second level of Iliffe vectors
has the indirect-addressing bit *off* and "T3" in the index field.]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607


Article: 146880
Subject: Re: Which is the most beautiful and memorable hardware structure
From: "Andy \"Krazy\" Glew" <ag-news@patten-glew.net>
Date: Tue, 30 Mar 2010 20:12:09 -0700
Links: << >>  << T >>  << A >>
The two hardware datastructures supporting out of order execution:

Reservation stations.

And, less beautifully, the register renaming map.

But then I am biased.

--

Really, I do think that the reservation stations are beautiful.  Even the naive CAM implementation.  Especially since 
there are more efficient implementations that are logically equivalent.

I am also pretty high on bit matrix schedulers.


Article: 146881
Subject: Re: Which is the most beautiful and memorable hardware structure
From: "Andy \"Krazy\" Glew" <ag-news@patten-glew.net>
Date: Tue, 30 Mar 2010 20:13:40 -0700
Links: << >>  << T >>  << A >>
On 3/29/2010 7:39 PM, MitchAlsup wrote:
> The most memorable hardware structure is the vector indirect
> addressing mode.
>
> Mitch


Aagh! No!  Although work I did on that veered towards reservation stations, which I like.

Nvidia has shown that vector indirect is unnecessary on a SIMT.

Although^2, it turns out that very similar hardware is needed for SIMT scalar indirect.

Article: 146882
Subject: Re: Any advice on which is the best book on CMOS digital circuit
From: pallav <pallavgupta@gmail.com>
Date: Tue, 30 Mar 2010 20:30:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Some good CMOS references:

1. Principles of CMOS VLSI Design by Weste/Harris
2. Digital Integrated Circuit Design: From VLSI Architectures to CMOS
Fabrication by Hubert Kaselin
3. CMOS Digital Integrated Circuits: Analysis and Design S.M. Kang and
Y. Leblebici
4. Low power design by Chandrakasan/Brodersen.
5. You can also look at books by John P. Uyemura but they might be
quite old.

Hope this helps.

Article: 146883
Subject: Re: Which is the most beautiful and memorable hardware structure in a CPU?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 31 Mar 2010 04:15:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote:
> The two hardware datastructures supporting out of order execution:
 
> Reservation stations.
 
> And, less beautifully, the register renaming map.

Both from the IBM 360/91, as far as I know.  

S/360 has only four floating point registers, so register
renaming was pretty important for out-of-order execution.

OK, how about imprecise interrupts?

-- glen

Article: 146884
Subject: Re: result on hyperterminal is not displayed
From: "weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 30 Mar 2010 23:16:04 -0500
Links: << >>  << T >>  << A >>
>On 26/03/2010 10:38, weldat wrote:
>> Hi every body;
>> i am working on xilinx EDK with MicroBlaze soft core processor. i am
using
>> Virtex 5 ML506 platform studio and my EDK is EDK 9.2
>> on this processor i am downloading C code for Elliptic curve
diffie-hellman
>> key exchange and it is done but result is not displayed on the
>> hyperterminal so is there any body who can help me how to fix my
problem?
>> but the connetion of the RS232_uart is working properly i have checked
it
>> with simple C code. the baud rate is all ok
>> thank you in advance.
>> kind regards
>> weldat	
>
>I have no idea about your system, but hyperterminal is notoriously 
>unreliable and entirely unsuitable to embedded development.  Try a 
>decent terminal emulator first to eliminate that source of problem. 
>Many people (including me) like Tera Term Pro, but there are hundreds of 
>alternatives.
>
>but when i power ON the FPGA(xilinx virtex 5 ML506)welcome to xilinx
virtex 5 is displayed on the hyperterminal.the problem is when download the
C code for the elliptic curve diffie hellman key exchange on the FPGA the
LEDs are blinking showing that downloading is performed bur the result of
the code is not displayed on the hyperterminal.even i have checked for
simple C codes of secure hash algorithm(SHA)and it works and result is
displyed on the hyperterminal.
but till now i did not fix why it is not displaying result of the elliptic
curvr diffie hellman key exchange.
thank you
weldat
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146885
Subject: Re: Which is the most beautiful and memorable hardware structure in a
From: James Harris <james.harris.1@googlemail.com>
Date: Tue, 30 Mar 2010 22:48:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Mar, 22:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

...

> No? =A0Don't like that? =A0OK, the Transputer's tiny 3-register
> evaluation stack, with context switches permitted only at
> points where the stack is known to be empty. =A0The
> 21st century operating system wonks could REALLY learn
> something about lightweight elegance from that one.

And from its one-byte instructions. Four-bit opcode and four-bit data
fields lead to 29 of the most-used instructions taking just one byte
and allowing for about 256 others to be encoded in two bytes (though
some used more). All this made effective on a 32-bit machine in the
1980s!

Of course the stack and zero-operand addressing made such tiny
encoding possible. These days a single stack would probably effect a
dependency between instructions which did not need one. Perhaps today
such would be built as many micro-cores.

James

Article: 146886
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: whygee <yg@yg.yg>
Date: Wed, 31 Mar 2010 09:42:30 +0200
Links: << >>  << T >>  << A >>
Patrick Maupin wrote:
> I also never convinced him that when his uber-fancy data recovery lost
> lock and just started spewing garbage (which it did in a rather
> spectacular way when it got lost, not just losing a bit here or
> there), that a 16 bit CRC was mathematically reduced to the same
> efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1
> out of every 65536 bad packets.

It is easily proved, sure, and CRC are not magic.
"Garbage in, garbage out", so if you input
random data, CRC fails in average every 2^N packet,
where N is the size of your CRC (in bits).
That's probably why the Ethernet protocols use 32 bits...

wait, did I just imply that 100BaseT is better than USB ??

> Regards,
> Pat
yg

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

Article: 146887
Subject: Re: Which is the most beautiful and memorable hardware structure in a CPU?
From: nmm1@cam.ac.uk
Date: Wed, 31 Mar 2010 09:38:31 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <houi8s$rdm$1@naig.caltech.edu>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>In comp.arch.fpga "Andy \"Krazy\" Glew" <ag-news@patten-glew.net> wrote:
>> The two hardware datastructures supporting out of order execution:
> 
>> Reservation stations.
> 
>> And, less beautifully, the register renaming map.
>
>Both from the IBM 360/91, as far as I know.  
>
>S/360 has only four floating point registers, so register
>renaming was pretty important for out-of-order execution.
>
>OK, how about imprecise interrupts?

Not a problem, until you try to resume after trapping them :-)

And the reason they were a problem was that they DID'T have a
lot of data structure to support them ....

I like them, as a design methodology, but only if integrated into
a restartable code sequence design and/or NOT used for anything
that might need resumption.  E.g. one of the Alpha's most stupid
mistakes was to try and merge them with the use of interrupts for
supporting IEEE's edge cases.  The 8087 was just plain idiotic.


Regards,
Nick Maclaren.

Article: 146888
Subject: FMC Boards ?
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 31 Mar 2010 01:51:32 -0700 (PDT)
Links: << >>  << T >>  << A >>

Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ?

HW-FMC-XM105-G	FMC XM105 DEBUG CARD
HW-FMC-XM104-G	FMC CONNECTIVITY MEZZANINE CARD

Buying Xilinx products now means going through Avnet, which is a
nightmare and HUGE lead times ...

Thanks,
rudi

Article: 146889
Subject: Re: Spartan 6 PLL - Why such a strict input jitter requirement?
From: Muzaffer Kal <kal@dspia.com>
Date: Wed, 31 Mar 2010 08:04:15 -0700
Links: << >>  << T >>  << A >>
On Wed, 31 Mar 2010 09:42:30 +0200, whygee <yg@yg.yg> wrote:

>Patrick Maupin wrote:
>> I also never convinced him that when his uber-fancy data recovery lost
>> lock and just started spewing garbage (which it did in a rather
>> spectacular way when it got lost, not just losing a bit here or
>> there), that a 16 bit CRC was mathematically reduced to the same
>> efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1
>> out of every 65536 bad packets.
>
>It is easily proved, sure, and CRC are not magic.
>"Garbage in, garbage out", so if you input
>random data, CRC fails in average every 2^N packet,
>where N is the size of your CRC (in bits).
>That's probably why the Ethernet protocols use 32 bits...
>
>wait, did I just imply that 100BaseT is better than USB ??
>

As opposed to USB, there is no CRC at the PHY level in 100B-TX (nor in
1000B-TX; which has FEC but still no CRC). The 32 bit CRC is at MAC
layer and is more or less independent of the PHY.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 146890
Subject: Re: Wrong DDR communication
From: "Pierpaolo" <pierpaolo.passarelli@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Wed, 31 Mar 2010 10:06:03 -0500
Links: << >>  << T >>  << A >>
>What version of ISE/EDK are you using?  Are you using a core or did
>you write your own interface to the DDR?
>

Hi! The version of ISE that I'm using is 9.2.
I'm using a DDR controller found on www.opencores.org for communication
with a memory that is on board with a Virtex2 then modified for my board
with a Virtex4.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 146891
Subject: Re: Migrating project from Xilinx ISE v7.1 to v11.1
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 31 Mar 2010 08:16:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 30, 5:17=A0pm, "vragukumar"
<vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote:
> Hello,
>
> We are trying to migrate a fully functional project from Xilinx ISE v7.1 =
to
> Xilinx ISE v11.1. We started off by creating a new project under v11.1 an=
d
> bringing over all the .v (verilog source) files, .ise file, .xco files an=
d
> .ucf file.
>
> The project synthesizes successfully, however when trying to Implement
> design, translate fails with several of the following errors
>
> (a) NgdBuild 924: input pad net '....' is driving non-buffer primitives
> (b) NgdBuild 455: logical net '....' has multiple drivers
> (c) NgdBuild 462: input pad net '....' drives multiple buffers
> (d) NgdBuild 809: output pad net'....' has an illegal load
>
> Has anyone encountered these errors in the past while migrating from an
> older version of Xilinx ISE to v11.1 ? Why are these caused and how do we
> get rid off these errors ?
>
> Thanks in advance for your help,
> Regards.
> Vikram. =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

These messages indicate that you have a top level port connected to
input of an IBUF and other internal logic at the same time and that
you have the a top level port connected to an output of an OBUF and
other internal logic at the same time.

The likely cause is a mixed use of IO buffer instantiation in the
Verilog code and IO insertion in synthesis.   This can also happen if
you are synthesizing modules that have IO insertion turned on or IP
cores that are a black-box in the top level synthesis, but have IO
buffers included.

Ed McGettigan
--
Xilinx Inc.


Article: 146892
Subject: Re: FMC Boards ?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 31 Mar 2010 10:04:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote:
> Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 ?
>
> HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD
> HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD
>
> Buying Xilinx products now means going through Avnet, which is a
> nightmare and HUGE lead times ...
>
> Thanks,
> rudi

While the XM104 is listed with a 8 week lead time on the Avnet site, I
know that we have these available in inventory and they will ship
promptly after the order is placed.  The XM105 is listed with a 2 week
lead time.

There are a number of other companies releasing FMC cards, just be
sure that the cards support a VADJ of 2.5V and there shouldn't be a
problem.

4DSP recently announced a FMC family
http://www.przoom.com/news/66794/

Curtiss-Wright also has a number of boards.
http://www.cwcembedded.com/0/62/651.html

And Xilinx has a number of other boards in pipeline to be released
next quarter.
http://www.xilinx.com/fmc

Ed McGettigan
--
Xilinx Inc.


Article: 146893
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: Bill Valores <bill.valores@gmail.com>
Date: Wed, 31 Mar 2010 10:53:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi again,

Impatient as I am, I went for testing the variable phase shifter on
the existing board. I ran on a xc3s1600e-4 stepping 0, which is not
what I'll have in the end, but the results were so encouraging, that I
feel pretty safe to jump to another device with no further checks.

I wrote a small Verilog module (the "state machine" below), which
sends shift commands in order to reach a certain position, which I set
through some register interface. Given that I wrote the module right
(which it seems like I did), I could arbitrarily jump to any position
I liked, just by changing the register. I had the shifted clock and a
reference clock wired to a testpoint, and I also had a signal going
high whenever my state machine was between PSEN and PSDONE (that is,
waiting). The latter turned out very interesting.

So I fed the DCM with a 5 MHz clock (minimal frequency) and started
playing around. Things went very smooth as long as I remained within
the per-spec =B11970 steps boundary. In my case I got around 22.75ps per
step (measured by jumping 1000 steps or so) consistently. I thought
this number was absurd, but it turned out to be true: The chip allows
=B139.4 ns of delay. That's a useful rail of nearly 80 ns. Pretty
impressive.

But I didn't stop there. I went for larger shifts until things started
to break. =B14000 was OK. When I tried 4500 in either direction, hell
broke lose. The most interesting thing was that the state machine was
waiting for PSDONE. I didn't look deeply into how much time each PSEN-
PSDONE cycle took, but it appeared long, random, and sometimes
completely stuck. In one occasion, the state machine waited for quite
a while, and then suddenly the "waiting" line went low again. On the
scope I saw a 2.5 MHz clock on the DCM's output (the original
frequency divided by two).

This random behavior appears suspiciously similar to reports I've read
from people who said that the PSDONE came much later than expected.
Which makes me think (or hope?) that their problem was in their own
logic, which accidentally pushed the phase shifter beyond its limit.

Another interesting thing about this result, is that the region of
4000-4500 steps is where the extra delay gets close to half a clock
cycle. On the scope, it was pretty evident that things started to go
wrong when the shifted clock got close to a 180 degree shift. And this
might explain the rule allowing 10 steps (0.4 ps at most) for each ns
of cycle period on the shifted clock. As for those extra 3ns, I
suppose there's a reason as well.

I tried this again with a 33.3 MHz input clock. The behavior was the
same. Hell broke lose when the shifting reached half a clock cycle.

In short, all this starts to make sense to me. This looks like "follow
the spec and everything will be all right". The bottom line is that
the datasheet was right, and the user guide was confusing.

Thanks again for your answers. You really were helpful.
Bill.

Article: 146894
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: Patrick Maupin <pmaupin@gmail.com>
Date: Wed, 31 Mar 2010 11:55:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 12:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote:

> I wrote a small Verilog module (the "state machine" below), which
> sends shift commands in order to reach a certain position, which I set
> through some register interface.

It sounds very much like what I built.

> This random behavior appears suspiciously similar to reports I've read
> from people who said that the PSDONE came much later than expected.
> Which makes me think (or hope?) that their problem was in their own
> logic, which accidentally pushed the phase shifter beyond its limit.

I didn't try to stress it to breaking, but I never saw any problems,
and we did lots of lab work over a couple of months.

> In short, all this starts to make sense to me. This looks like "follow
> the spec and everything will be all right". The bottom line is that
> the datasheet was right, and the user guide was confusing.

I think the user guide may have too much leftover S3 DCM info (which
is way different than S3E DCM).

> Thanks again for your answers. You really were helpful.

Glad to hear it!  Thanks for letting me know you're up and running.

Regards,
Pat

Article: 146895
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 31 Mar 2010 12:13:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 1:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote:
>
> The most interesting thing was that the state machine was
> waiting for PSDONE. I didn't look deeply into how much time each PSEN-
> PSDONE cycle took, but it appeared long, random, and sometimes
> completely stuck. In one occasion, the state machine waited for quite
> a while, and then suddenly the "waiting" line went low again. On the
> scope I saw a 2.5 MHz clock on the DCM's output (the original
> frequency divided by two).
>
> This random behavior appears suspiciously similar to reports I've read
> from people who said that the PSDONE came much later than expected.
> Which makes me think (or hope?) that their problem was in their own
> logic, which accidentally pushed the phase shifter beyond its limit.

You stated earlier that "I understand that clock jitter has been a
primary suspect where problems have arisen."

That jolted a couple brain cells loose.  Jitter on the 50 MHz
reference clock was the problem in our system prototype across the
country (a problem we never had locally with a different front-end
transmitter).  When the problem was isolated further down, the clock
quality was identified as a strong issue.  A couple changes were made
on the board providing the 50 MHz reference clock (and three
communications links tied to it) to make it a much cleaner version of
its earlier self and the problems with PSDONE coming in late (or
never) went away.  I'm certain the PSDONE detection logic was fine (it
was even reworked a few times to try to figure things out) and the
limits of the phase shift were not at issue.

When I did have the poor quality clock and the PSDONE response was
persnickety, I set up a BlockRAM counter to enumerate the number of
instances of the PSDONE taking N cycles to report, N being from 1 to
512.  I recall the trend being logarithmic.  When I plotted the data I
used a log scale to deal with the wide range of counts.  The plot was
roughly a staircase with a linear (on the log graph) trend.  Several
delay times would be approximately the same count of instances, then
markedly fewer for several more similar counts, and so on down the
logarithmic staircase.  With the jitter problem fixed, the response
from the PSDONE was fixed as well.

Happy shifting!

Article: 146896
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: Patrick Maupin <pmaupin@gmail.com>
Date: Wed, 31 Mar 2010 13:36:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 2:13=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Mar 31, 1:53=A0pm, Bill Valores <bill.valo...@gmail.com> wrote:
>
>
>
> > The most interesting thing was that the state machine was
> > waiting for PSDONE. I didn't look deeply into how much time each PSEN-
> > PSDONE cycle took, but it appeared long, random, and sometimes
> > completely stuck. In one occasion, the state machine waited for quite
> > a while, and then suddenly the "waiting" line went low again. On the
> > scope I saw a 2.5 MHz clock on the DCM's output (the original
> > frequency divided by two).
>
> > This random behavior appears suspiciously similar to reports I've read
> > from people who said that the PSDONE came much later than expected.
> > Which makes me think (or hope?) that their problem was in their own
> > logic, which accidentally pushed the phase shifter beyond its limit.
>
> You stated earlier that "I understand that clock jitter has been a
> primary suspect where problems have arisen."
>
> That jolted a couple brain cells loose. =A0Jitter on the 50 MHz
> reference clock was the problem in our system prototype across the
> country (a problem we never had locally with a different front-end
> transmitter). =A0When the problem was isolated further down, the clock
> quality was identified as a strong issue. =A0A couple changes were made
> on the board providing the 50 MHz reference clock (and three
> communications links tied to it) to make it a much cleaner version of
> its earlier self and the problems with PSDONE coming in late (or
> never) went away. =A0I'm certain the PSDONE detection logic was fine (it
> was even reworked a few times to try to figure things out) and the
> limits of the phase shift were not at issue.
>
> When I did have the poor quality clock and the PSDONE response was
> persnickety, I set up a BlockRAM counter to enumerate the number of
> instances of the PSDONE taking N cycles to report, N being from 1 to
> 512. =A0I recall the trend being logarithmic. =A0When I plotted the data =
I
> used a log scale to deal with the wide range of counts. =A0The plot was
> roughly a staircase with a linear (on the log graph) trend. =A0Several
> delay times would be approximately the same count of instances, then
> markedly fewer for several more similar counts, and so on down the
> logarithmic staircase. =A0With the jitter problem fixed, the response
> from the PSDONE was fixed as well.
>
> Happy shifting!

yeah, whether you're using dynamic phase shift or not, experience has
shown me that Xilinx DLLs and DCMs can be exceptionally unhappy if you
are not giving them a clean clock.  If the 1ns max jitter figure
bandied about in another thread is any indication, this may still be
true even with the new PLL-based architecture.  For clocks of unknown
provenance, I usually use a PLL in front of the FPGA to clean the
clock, and use some separate FPGA logic on a local oscillator to
monitor the DCM locked indicator and reset the DCM if there are
issues.  In the past, I have used Cypress RoboClocks and InstaClocks
for pre-FPGA jitter cleanup.  On my last design, I actually used one
of my own company's (different division's) parts (the ZL30132) which
was, admittedly, overkill for what I needed, but was effectively free
for me (and it seems to work quite well, to boot).

Regards,
Pat

Article: 146897
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: -jg <jim.granville@gmail.com>
Date: Wed, 31 Mar 2010 14:19:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 5:53=A0am, Bill Valores <bill.valo...@gmail.com> wrote:
> So I fed the DCM with a 5 MHz clock (minimal frequency) and started
> playing around. Things went very smooth as long as I remained within
> the per-spec =B11970 steps boundary. In my case I got around 22.75ps per
> step (measured by jumping 1000 steps or so) consistently. I thought
> this number was absurd, but it turned out to be true: The chip allows
> =B139.4 ns of delay. That's a useful rail of nearly 80 ns. Pretty
> impressive.
>
> But I didn't stop there. I went for larger shifts until things started
> to break. =B14000 was OK. When I tried 4500 in either direction, hell
> broke lose. The most interesting thing was that the state machine was
> waiting for PSDONE.

Going outside the limits can be very useful.
* It confirms the limit is correctly understood
* it gives useful insight, into failure modes, and thus
  a place to look, should issues appear later.
* Knowing what something cannot do, often gives more
insight, than knowing what it can do :)

Vendors should do more of this, and providing a piece of test/example/
exercise code like you have done, is something they should all be
encouraged to do.

-jg

Article: 146898
Subject: Re: Any advice on which is the best book on CMOS digital circuit
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 31 Mar 2010 16:14:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 30, 8:30=A0pm, pallav <pallavgu...@gmail.com> wrote:
> Some good CMOS references:
>
> 1. Principles of CMOS VLSI Design by Weste/Harris
> 2. Digital Integrated Circuit Design: From VLSI Architectures to CMOS
> Fabrication by Hubert Kaselin
> 3. CMOS Digital Integrated Circuits: Analysis and Design S.M. Kang and
> Y. Leblebici
> 4. Low power design by Chandrakasan/Brodersen.
> 5. You can also look at books by John P. Uyemura but they might be
> quite old.
>
> Hope this helps.

Hi Pallav,
Thank you.

I have bought Principles of CMOS VLSI Design, second edition, by
Weste, I am very happy to have the 2nd edition.

Harris later appended some chapters to the 3rd edition to make it the
4th edition.

I think it may be enough for me to have the 2nd edition. Because I
need only the basic knowledge about CMOS.

I am interested in logic design and computer architecture. With CMOS
knowledge it may help get faster designs.

Weng


Article: 146899
Subject: Re: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
From: Patrick Maupin <pmaupin@gmail.com>
Date: Wed, 31 Mar 2010 16:47:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 4:19=A0pm, -jg <jim.granvi...@gmail.com> wrote:

> Going outside the limits can be very useful.
> * It confirms the limit is correctly understood
> * it gives useful insight, into failure modes, and thus
> =A0 a place to look, should issues appear later.
> * Knowing what something cannot do, often gives more
> insight, than knowing what it can do :)

Absolutely agreed; "play time" is when most learning occurs.

> Vendors should do more of this, and providing a piece of test/example/
> exercise code like you have done, is something they should all be
> encouraged to do.

Xilinx sometimes is reluctant to disclose how or why things work, so
good luck with your campaign of getting them to disclose how or why
things DON'T work.   A big company finds it easy to find the downside
in a disclosure ("Altera will figure out our weaknesses and explain
them to customers; patent trolls will notice that we are infringing
their putative IP.") often without noticing the simple upside that an
informed customer is a happy customer.

Pat



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