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 67100

Article: 67100
Subject: Re: How do I fix this type of errors?
From: Markus <markus.rullmann@gmx.de>
Date: Fri, 5 Mar 2004 06:16:21 -0800
Links: << >>  << T >>  << A >>
Sean and Kelvin,

I had the same problem (Fatal Errors due to logic0/logic1 on 
signals). The logic0/logic1 doesn't seem the problem itself but it leads in the 
right direction. 

In my case, the error was mostly caused by unconstraint top level logic.If the 
logic was moved into a module, the final par was successful. However, I still 
have trouble setting constant '0' and '1' on the bus macro inputs, which also 
causes your problem even if no real logic is involved. What puzzles me is that 
it works for the tutorial (xapp290). 

Please correct me if I am wrong. 

Markus 


Article: 67101
Subject: A newbie question
From: ouadid@iquebec.com
Date: Fri, 5 Mar 2004 15:51:08 GMT
Links: << >>  << T >>  << A >>
	Hello,
	Maybe it is a newbie question but i try to learn and because i'm not very
	fluent in english i want to know what this sentence mean.
   "parts need to be reballed"
            Thanks for the help

Article: 67102
Subject: Modelsim glitches
From: salman sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Fri, 05 Mar 2004 11:24:49 -0500
Links: << >>  << T >>  << A >>
Hello,

A colleague of mine is simulating a post-routed with back-annotated FPGA 
design for an Actel chip on Modelsim. He is getting a number (1000's) of 
glitch warnings related to what seems to be combinatorial logic that is 
part of a counter and or muxes which is registered on the outputs 
anyway.  None of the glitches are visible on the input or outputs but is 
on the internal nets.  Can we safely ignore these warnings or better yet 
turn them off with -no_glitch option?

Thanks in advance.

Salman

Article: 67103
Subject: Re: Global reset question?
From: PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca>
Date: Fri, 05 Mar 2004 16:46:05 GMT
Links: << >>  << T >>  << A >>
   According to the Virtex-II datasheet, if your SRL16 is configured as 
a simple 16-bit shift register, you have direct access to the 
"shift-out" bit of the register, so it would seem you don't need to 
worry about the LUT inputs.  I believe this essentially bypasses the LUT 
address mux, although I could be wrong.

Ray Andraka wrote:
> The configuration holds the LUTs contents which defines the combinatorial
> function of the LUT, but that does not describe the LUT's output value.  You
> cross couple two luts, but I don't see how you force a particular initial value
> from initialization.  This is much different than an SRL16, where the
> configuration bits are the SRL16 state, or even a flip-flop where the state is
> part of the initialization.  What am I missing here?
> 
> Peter Alfke wrote:
> 
> 
>>The LUT content is defined in the bitstream. That defines the original state
>>of the latch. Same for SRL16.
>>Peter Alfke
>>
>>
> 
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
> 
> 

-- 
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --


Article: 67104
Subject: Re: A newbie question
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Fri, 5 Mar 2004 08:47:55 -0800
Links: << >>  << T >>  << A >>
"Reballing" is required to re-use parts in BGA packages that were once
soldered onto a board.  "Reballing" is a way to reclaim these BGA parts.

-- SKK

<ouadid@iquebec.com> wrote in message
news:xn12c.18959$qA2.1251023@news20.bellglobal.com...
> Hello,
> Maybe it is a newbie question but i try to learn and because i'm not very
> fluent in english i want to know what this sentence mean.
>    "parts need to be reballed"
>             Thanks for the help



Article: 67105
Subject: Re: CASCADING DCM
From: symon_brewer@hotmail.com (Symon)
Date: 5 Mar 2004 09:24:33 -0800
Links: << >>  << T >>  << A >>
Hi Peter,
CLKIN doesn't need to be free running when the DCM is locked, unless
you're using CLKFX or CLKFX180. Here's a quote from the user guide.
<quote>
Input Clock Changes
Changing the period of the input clock beyond the maximum input period
jitter specification requires a manual reset of the DCM. Failure to
reset the DCM produces an unreliable lock signal and output clock.
While the DCM is in the locking process, no input clock edge can be
missing. Once locked, it is possible to temporarily stop the input
clock with little impact to the de-skew circuit, as long as CLKFX or
CLKFX180 is not used.
</quote>
Complicated things, those DCMs!
Cheers, Syms.

Peter Alfke <peter@xilinx.com> wrote in message news:<4044CEE5.15179D88@xilinx.com>...
> Basic functionality:
> In its simplest use, the DCM  eliminates the clock delay between the
> incoming clock signal and the low-skew global clock distribution. With
> the appropriate feedback to its CLKFB input the DCM  inserts the right
> amount of delay so that CLKIN and CLKO signals occur simultaneously
> (within a very small fraction of a nanosecond). Physically, CLKO is
> delayed by exactly one clock period, and this obviously requires a
> free-running, constant-frequency CLKIN.
> I hope this long posting is helpful.
> Peter Alfke, Xilinx Applications

Article: 67106
Subject: Re: Global reset question?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Mar 2004 12:49:28 -0500
Links: << >>  << T >>  << A >>
I'm not sure what that has to do with my statement, but you are correct, for VirtexII
the SRL16 has a cascade out that is permanently connected to the last 'register' in
the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
looking at the normal output.  The cascade output was a new feature for virtexII.

What Peter was saying is that you can create a latch out of cross-coupled LUTs that
will not be affected by global reset (which is true), however he also seemed to
indicate that you could have that latch come up in a known state on reconfiguration.
My statement simply says that for a LUT, the configuration sets the combinatorial
function of the LUT, but does not determine its output value (the output is
determined by the values of the inputs and the ccombinatorial function assigned to
the LUT).  Therefore, the latch created from cross coupled LUTs cannot be directly
assigned  an initial value by configuration.  To get it to a known state, one of the
set/reset inputs must be asserted, which requires something external to the latch and
explicitly designed in the user logic to accomplish.  The SRL16 is different than a
LUT in that it has internal storage accessible to the user circuit.  The SRL16 can be
viewed as a LUT whose program can be altered by shifting new bits into it.  If held
with the WE='0', it behaves exactly as a LUT, with the output being the value of the
program bit selected by the inputs.

PO Laprise wrote:

>    According to the Virtex-II datasheet, if your SRL16 is configured as
> a simple 16-bit shift register, you have direct access to the
> "shift-out" bit of the register, so it would seem you don't need to
> worry about the LUT inputs.  I believe this essentially bypasses the LUT
> address mux, although I could be wrong.

--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

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



Article: 67107
Subject: Re: A newbie question
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 05 Mar 2004 11:08:38 -0800
Links: << >>  << T >>  << A >>
"Balls", as in Ball-Grid-Array describe the many small half-spheres of
solder on the bottom of modern BGA packages,  from a few hundred to over a
thousand of them.
In board assembly, these balls are heated up and collapse onto the pc-board
"pad" and form a perfect solder joint.
When, for any reason, a package has been removed from the pc-board, the
balls are left behind or damaged or deformed, so the device package must be
refurbished with new balls, and that step in re-manufacturing is called
"re-balling".
Peter Alfke  

> From: ouadid@iquebec.com
> Organization: Bell Sympatico
> Newsgroups: comp.arch.fpga
> Date: Fri, 5 Mar 2004 15:51:08 GMT
> Subject: A newbie question
> 
> Hello,
> Maybe it is a newbie question but i try to learn and because i'm not very
> fluent in english i want to know what this sentence mean.
> "parts need to be reballed"
> Thanks for the help


Article: 67108
Subject: Re: Jitter in DLLs vs PLLs
From: gregs@altera.com (Greg Steinke)
Date: 5 Mar 2004 12:03:42 -0800
Links: << >>  << T >>  << A >>
"Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>...
> Just wondering if anyone can point me to some articals or papers that analyse
> the characteristics of xilinx DLLs vs altera PLLs.
> 
> Thanks.

Michael,
Altera has published a document comparing PLLs to DLLs, specifically
looking at jitter.
http://www.altera.com/literature/tb/tb70.pdf

We also publish specs for PLL jitter in the appropriate device
datasheet, so you can take a look at those as well.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

Article: 67109
Subject: Re: mersenne twister
From: Sander Vesik <sander@haldjas.folklore.ee>
Date: Fri, 5 Mar 2004 20:07:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
Max <mtj2@btopenworld.com> wrote:
> On Fri, 5 Mar 2004 23:01:01 +1300, Bevan Weiss wrote:
> 
> >I was really just looking for something slightly removed from mainstream...
> >Just like a bit of challenge I guess.
> >I'll have a look at the common algorithms too, I think they be sufficient
> >for the requirements also.
> 
> An interesting project might be to implement Rijndael/AES in an FPGA.
> It's pretty efficient for a block cypher algorithm, and about as
> secure as you can get:
> http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
> 

There is a core on opencores.org that is probably suitable for a prng
(its slightly lacking for my taste as a general crypto core)

-- 
	Sander

+++ Out of cheese error +++

Article: 67110
Subject: Re: Global reset question?
From: PO Laprise <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca>
Date: Fri, 05 Mar 2004 20:08:35 GMT
Links: << >>  << T >>  << A >>
  Sorry, my bad.  I thought you were referring to his statement on the 
use of the SRL16.  However, the OP implied that his global clear was 
post-power-up.  Couldn't there be a way to initialize the latch at 
power-up, after which the value would be kept across global clears?  I 
haven't thought out the details, but it doesn't seem too complicated 
(famous last words ;)...  I was under the impression that there was a 
way of differentitating power-up reset and subsequent global clears...

Ray Andraka wrote:

> I'm not sure what that has to do with my statement, but you are correct, for VirtexII
> the SRL16 has a cascade out that is permanently connected to the last 'register' in
> the SRL16, which in effect is the same as forcing '1111' on the LUT inputs and
> looking at the normal output.  The cascade output was a new feature for virtexII.
> 
> What Peter was saying is that you can create a latch out of cross-coupled LUTs that
> will not be affected by global reset (which is true), however he also seemed to
> indicate that you could have that latch come up in a known state on reconfiguration.
> My statement simply says that for a LUT, the configuration sets the combinatorial
> function of the LUT, but does not determine its output value (the output is
> determined by the values of the inputs and the ccombinatorial function assigned to
> the LUT).  Therefore, the latch created from cross coupled LUTs cannot be directly
> assigned  an initial value by configuration.  To get it to a known state, one of the
> set/reset inputs must be asserted, which requires something external to the latch and
> explicitly designed in the user logic to accomplish.  The SRL16 is different than a
> LUT in that it has internal storage accessible to the user circuit.  The SRL16 can be
> viewed as a LUT whose program can be altered by shifting new bits into it.  If held
> with the WE='0', it behaves exactly as a LUT, with the output being the value of the
> program bit selected by the inputs.
> 
> PO Laprise wrote:
> 
> 
>>   According to the Virtex-II datasheet, if your SRL16 is configured as
>>a simple 16-bit shift register, you have direct access to the
>>"shift-out" bit of the register, so it would seem you don't need to
>>worry about the LUT inputs.  I believe this essentially bypasses the LUT
>>address mux, although I could be wrong.
> 
> 
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
> 
> 

-- 
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --


Article: 67111
Subject: Re: TRST Pin in Altera FPGAs
From: gregs@altera.com (Greg Steinke)
Date: 5 Mar 2004 12:24:47 -0800
Links: << >>  << T >>  << A >>
erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch> wrote in message news:<c29ac5$ovb$1@sunnews.cern.ch>...
> rickman wrote:
> 
> > TRST puts the state machine in a defined state.  Most devices also reset
> > the state machine on power up.  In addition, if you hold the TMS line
> > high and clock TCK it will return the state machine to the starting
> > state after 5 clock cycles, IIRC.  Of course, depending on the
> > implementation, the mechanism that operates the state machine can get
> > fouled up by power glitches or other anomalies.  Then the machine may
> > get into a state that operating the TCK line may not control the state. 
> > Then you will need a power on or a TRST type reset.  I don't know that
> > this is common, but in theory it is possible.  
> 
> Thank you for the description. This is exactly that I also found. I do not
> use the TRST pin but I have never seen a case when the JTAG State Machine
> did not return to RESET state after 5 clocks. I use the JTAG chain for 
> regular check of the FPGA input pins, not only for programming.
> 
> The original question was the open TRST pin, but due to the standard 
> internal pullup - I hope this is the case in Altera FPGAs too, but this 
> was not yet confirmed by anybody - the open input must not be the reason 
> for incorrect behavior.
> 
> Janos Ero

Hi Janos,
Altera devices that have a TRST pin have a weak internal pull-up on
them. The literature is not very clear on this, so we'll update this.
However, not all Altera devices have TRST as it is optional. The EPC8
is one of those without TSRT. It's possible that a floating TRST on
some other non-Altera device in the chain would cause such a problem,
but I imagine that most JTAG devices would have a weak pull-up on
TRST.

Another thing to check would be the TCK on the devices in the chain.
If one of the devices is getting double-clocked then this would foul
up the data passing through the JTAG chain. The tricky part is that a
double-clock on any device could cause a problem, not just on the
EPC8.

Sincerely,
Greg Steinke
gregs@altera.com
Altera Corporation

Article: 67112
Subject: Re: Global reset question?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Fri, 5 Mar 2004 20:57:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <7752c.112739$2g.74392@charlie.risq.qc.ca>,
PO Laprise  <pl_N0SP4M_apri@cim._N0SP4M_mcgill.ca> wrote:
>  Sorry, my bad.  I thought you were referring to his statement on the 
>use of the SRL16.  However, the OP implied that his global clear was 
>post-power-up.  Couldn't there be a way to initialize the latch at 
>power-up, after which the value would be kept across global clears?  I 
>haven't thought out the details, but it doesn't seem too complicated 
>(famous last words ;)...  I was under the impression that there was a 
>way of differentitating power-up reset and subsequent global clears...

There is.  SRL16, initialized to 0x0001, arbitrary delay lenght, with
the input as a 0.  The first cycle on startup it will be a 1, but
every cycle thereafter, even after global reset, it will be a 0.  If
you want a longer "start high" you can make the initial chain of 1s be
longer.  Or use logic to drive a LUT-as-ram which you then set to 0
after enough startup time has passed.

Basically, you observe that LUT-as-RAM, SRL, BlockRAM contents are
preserved across global reset, but start on initialization in a
defined state.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 67113
Subject: Testing a Verilog design after synthesis in Xilinx ISE
From: srkumar26@hotmail.com (kumar)
Date: 5 Mar 2004 13:15:26 -0800
Links: << >>  << T >>  << A >>
Hello everyone,

I have a verilog design that is tested and works properly with
ModelSim simulator. I have synthesized it with Xilinx Project
Navigator tool using XST. I want to verify if the design works
properly(after synthesis) before I can go on with downloading the BIT
stream onto a Xilinx FPGA board.
I could not find a way to do this. Could anyone please help me in this
matter.
Thanks a lot,
Kumar

Article: 67114
Subject: Re: A newbie question
From: ouadid@iquebec.com
Date: Fri, 5 Mar 2004 21:20:57 GMT
Links: << >>  << T >>  << A >>
        Thanks a lot for the explanations, it's well understood now what
       means reballing. I guess it must be a special process that you can't
       do in your home...

         

Article: 67115
Subject: Re: Testing a Verilog design after synthesis in Xilinx ISE
From: salman sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Fri, 05 Mar 2004 16:22:45 -0500
Links: << >>  << T >>  << A >>
kumar wrote:
> Hello everyone,
> 
> I have a verilog design that is tested and works properly with
> ModelSim simulator. I have synthesized it with Xilinx Project
> Navigator tool using XST. I want to verify if the design works
> properly(after synthesis) before I can go on with downloading the BIT
> stream onto a Xilinx FPGA board.
> I could not find a way to do this. Could anyone please help me in this
> matter.
> Thanks a lot,
> Kumar

Just simulate it with the same testbench you used to test the verilog 
design (i.e. use the post place and routed generated verilog file with 
back-annotated timing file (sdf file) with your testbench and you should 
then now how good it really works.

Salman

Article: 67116
Subject: Software for synthesis
From: ouadid@iquebec.com
Date: Fri, 5 Mar 2004 21:24:56 GMT
Links: << >>  << T >>  << A >>
    Hi every body,
    I tried to make a P&R with ISE 5.2 and i saw that there is no XC4000
    target possible. Is there a library i have to download or do i have to
    look for an old version of Xilinx tools. If so what is the last version
    and tool that will be capable of making P&R for and XC4003A and an
    XC3020A
    Thanks

Article: 67117
Subject: Testing a verilog design after synthesis in Xilinx ISE
From: srkumar26@hotmail.com (kumar)
Date: 5 Mar 2004 13:30:43 -0800
Links: << >>  << T >>  << A >>
Hello everyone,
I have a verilog design that is tested with ModelSim simulator and it
works properly. I have synthesized it with Xilinx ISE Tool using XST
and I want to test it(after synthesis) before I can go on with
downloading the BIT file onto a Xilinx FPGA board.
I could not find a way to do it. Can anyone please help me in this
matter?

Thanks a lot,
Kumar

Article: 67118
Subject: Re: Testing a Verilog design after synthesis in Xilinx ISE
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 05 Mar 2004 16:50:18 -0500
Links: << >>  << T >>  << A >>
On Fri, 05 Mar 2004 16:22:45 -0500, salman sheikh wrote:

> kumar wrote:
>> Hello everyone,
>> 
>> I have a verilog design that is tested and works properly with
>> ModelSim simulator. I have synthesized it with Xilinx Project
>> Navigator tool using XST. I want to verify if the design works
>> properly(after synthesis) before I can go on with downloading the BIT
>> stream onto a Xilinx FPGA board.
>> I could not find a way to do this. Could anyone please help me in this
>> matter.
>> Thanks a lot,
>> Kumar
> 
> Just simulate it with the same testbench you used to test the verilog 
> design (i.e. use the post place and routed generated verilog file with 
> back-annotated timing file (sdf file) with your testbench and you should 
> then now how good it really works.
> 
> Salman

ngd2ver converts an ngd file back to verilog, you can plug the gate level
verilog file back into your testbench. Simulating a gate level netlist is
painfully slow especially with a slow simulator like ModelSim. Unless you
suspect that you've had a synthesis error there is no reason to do a gate
level simulation. Even if you suspect a synthesis problem you are better
off trying to narrow it down using ChipScope then trying to do a gate
level simulation.


Article: 67119
Subject: Re: TRST Pin in Altera FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 05 Mar 2004 17:05:41 -0500
Links: << >>  << T >>  << A >>
erojr wrote:
> 
> rickman wrote:
> 
> > TRST puts the state machine in a defined state.  Most devices also reset
> > the state machine on power up.  In addition, if you hold the TMS line
> > high and clock TCK it will return the state machine to the starting
> > state after 5 clock cycles, IIRC.  Of course, depending on the
> > implementation, the mechanism that operates the state machine can get
> > fouled up by power glitches or other anomalies.  Then the machine may
> > get into a state that operating the TCK line may not control the state.
> > Then you will need a power on or a TRST type reset.  I don't know that
> > this is common, but in theory it is possible.
> 
> Thank you for the description. This is exactly that I also found. I do not
> use the TRST pin but I have never seen a case when the JTAG State Machine
> did not return to RESET state after 5 clocks. I use the JTAG chain for
> regular check of the FPGA input pins, not only for programming.
> 
> The original question was the open TRST pin, but due to the standard
> internal pullup - I hope this is the case in Altera FPGAs too, but this
> was not yet confirmed by anybody - the open input must not be the reason
> for incorrect behavior.

I don't know about Altera, but I read that TI uses just the opposite
convention on their chips.  They require a *pulldown* on the board and
the JTAG emulator has to have an active pullup to assert the TRST.  I
assume the TI TRST inputs have no pullup or down.  

Why not put a TRST pullup on the board to be safe?  10K should do the
job and not get in the way.  

-- 

Rick "rickman" Collins

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

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

Article: 67120
Subject: Re: Jitter in DLLs vs PLLs
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 05 Mar 2004 14:12:37 -0800
Links: << >>  << T >>  << A >>
Greg,

Two things:  first, the spec is not peak to peak, but cycle to cycle, so 
we do not "exceed" our spec as you erroneously state, and second, the 
jitter from the DLL is decidely non-gaussian so any statistical 
estimates are wrong.  Can't "multiply by 6" or any other shortcut.

The peak to peak jitter is entirely random, but not a normal 
distribution as the taps are discrete, and the selection of the taps is 
from a digital control system.

The intrinsic jitter is not very interesting, as the "when busy" jitter 
of our part is 1/3 of yours under the same conditions.

Choosing the 2X output is also not entirely honest, as the 1X outputs 
have half the jitter (something you fail to mention, but we freely 
advise our customers of).

Other than that, we also have LeCroy equipment, and use it often.  The 
+/- 6 ps intrinsic measurement capability for jitter is selling you 
short, however, as the Wavecrest with its +/- 3 ps peak to peak worst 
case intrinsic jitter would make the PLL look better.

Austin

Greg Steinke wrote:
> "Michael Chan" <m.chan1@uq.edu.au> wrote in message news:<c261a1$atj$1@bunyip.cc.uq.edu.au>...
> 
>>Just wondering if anyone can point me to some articals or papers that analyse
>>the characteristics of xilinx DLLs vs altera PLLs.
>>
>>Thanks.
> 
> 
> Michael,
> Altera has published a document comparing PLLs to DLLs, specifically
> looking at jitter.
> http://www.altera.com/literature/tb/tb70.pdf
> 
> We also publish specs for PLL jitter in the appropriate device
> datasheet, so you can take a look at those as well.
> 
> Sincerely,
> Greg Steinke
> gregs@altera.com
> Altera Corporation

Article: 67121
Subject: FPGA hangs
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 5 Mar 2004 14:17:52 -0800
Links: << >>  << T >>  << A >>
Hi all,
I have two boards with the exactly same fpga (spartanIIE) and same
code inside them. One of the boards hangs 2~10 minute after power on.
I want to find out the reason. Is it due to power problem on one of
the boards? grouding or ...?
please let me know your ideas.
regards.

Article: 67122
Subject: PWM, PLD programming ,(up/down ramp frequency)
From: stewart1r1@hotmail.com (Stewart Smith)
Date: 5 Mar 2004 14:22:00 -0800
Links: << >>  << T >>  << A >>
Hi 
I have a query for those of you whish to help 
My Problem
Variable frequency output via a PLD control of a Switched reluctance
motor.

(Overview)
The system should be capable of driving a three phase Switched
Reluctance motor open-loop (no current or position feedback), no-load,
at a minimum speed of 10 r.p.m.
The system should include a soft start (frequency ramp) facility and
the ability to operate in either direction.
Any suitable power electronic devices may be used.
The control electronics must be isolated from the power electronics.
The control electronics should comprise of PLD technology.

So my part is the softstart (thanks guys)

I have only cupl available and a Lattice Gal20v8 device.
my max frequency output would be 200Hz my minimum requirement is 2 Hz.
from this I would like to try and make the input frequency to say
around 400Hz.Then somehow cut this frequency by use of a counter type
flip-flop array in the Gal, but would also like to take the outputs
from the said (4 bit) counter to use as my ramp. Thus Giving a
possible 16 frequency outputs.
Is it possible to have the counter and then have a state machine use
the outputs of the counter to generate a ramping frequency effect on 1
single output pin of the GAL?
My knowledge of cupl is to say, at best is limited, I have seen
programs in VHDL (of which my knowledge is even less), which claim to
be able to achieve this.
I am a student undertaking an assignment so I am not looking for
answers (I want to learn) only pointers on how to get there.

Very best regards
Stewart

Article: 67123
Subject: Re: FPGA hangs
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 05 Mar 2004 14:55:08 -0800
Links: << >>  << T >>  << A >>
First:
check that both boards really operate with the same input signals. Swap the
boards and check where the failure moves.
Next:
Vary ambient temperature and also (separately) Vcc, and note their impact on
the behavior.

These two simple test should give you some clues.
"Minutes" almost always points to a temperature effect, unless you have
extremely long counters in the chip.
It could also be caused by hanging undriven pins that very slowly drift High
or Low.
Hope this helps.
Peter Alfke

> From: naderimisc@yahoo.com (Masoud Naderi)
> Organization: http://groups.google.com
> Newsgroups: comp.arch.fpga
> Date: 5 Mar 2004 14:17:52 -0800
> Subject: FPGA hangs
> 
> Hi all,
> I have two boards with the exactly same fpga (spartanIIE) and same
> code inside them. One of the boards hangs 2~10 minute after power on.
> I want to find out the reason. Is it due to power problem on one of
> the boards? grouding or ...?
> please let me know your ideas.
> regards.


Article: 67124
Subject: Re: TRST Pin in Altera FPGAs
From: rk <stellare@NOSPAMPLEASE.erols.com>
Date: 05 Mar 2004 23:49:30 GMT
Links: << >>  << T >>  << A >>
rickman wrote:

> erojr wrote:
>> 
>> rickman wrote:
>> 
>> > TRST puts the state machine in a defined state.  Most devices also reset
>> > the state machine on power up.  In addition, if you hold the TMS line
>> > high and clock TCK it will return the state machine to the starting
>> > state after 5 clock cycles, IIRC.  Of course, depending on the
>> > implementation, the mechanism that operates the state machine can get
>> > fouled up by power glitches or other anomalies.  Then the machine may
>> > get into a state that operating the TCK line may not control the state.
>> > Then you will need a power on or a TRST type reset.  I don't know that
>> > this is common, but in theory it is possible. 
>> 
>> Thank you for the description. This is exactly that I also found. I do not
>> use the TRST pin but I have never seen a case when the JTAG State Machine
>> did not return to RESET state after 5 clocks. I use the JTAG chain for
>> regular check of the FPGA input pins, not only for programming.
>> 
>> The original question was the open TRST pin, but due to the standard
>> internal pullup - I hope this is the case in Altera FPGAs too, but this
>> was not yet confirmed by anybody - the open input must not be the reason
>> for incorrect behavior. 
> 
> I don't know about Altera, but I read that TI uses just the opposite
> convention on their chips.  They require a *pulldown* on the board and
> the JTAG emulator has to have an active pullup to assert the TRST.  I
> assume the TI TRST inputs have no pullup or down.  
> 
> Why not put a TRST pullup on the board to be safe?  10K should do the
> job and not get in the way.  

The idea is to hard ground it (0 ohms) to ensure that the part does stay in 
the operating mode (TEST-LOGIC-RESET).  TRST* is asserted low.

There have been cases observed where a part that has left the TEST-LOGIC-RESET 
state and dumped garbage into the command register (the holding register is a 
don't care) has not recovered with the 5 TCK's with TMS=1.  Two causes that I 
have seen.  One, the TCK is shared with a pin in the device that has decided 
to drive out, low, clamping the system clock to a '0'.  The other was putting 
junk into the command register which sort of took the whole system down.

-- 
rk, Just an OldEngineer
"For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled."
-- R. Feynman, Appendix F.



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