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

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 125925

Article: 125925
Subject: Xilinx Parallel Cable IV, API spec
From: kgll8ss@yahoo.com
Date: Thu, 08 Nov 2007 21:09:55 -0800
Links: << >>  << T >>  << A >>
Is the hardware API for "Xilinx Parallel Cable IV Model DLC7"
published or does one have to figure that out by traditional
engineering methods ..?
(I want to know how to talk to the programmer cable by setting bits at
port 0x378..)


Article: 125926
Subject: Re: not totally repulsive
From: "Tim Williams" <tmoranwms@gmail.com>
Date: Thu, 8 Nov 2007 23:14:35 -0600
Links: << >>  << T >>  << A >>
The point is current spreading.  Because they aren't intended for handling
large forward currents, their junctions aren't designed to handle the
thermal effects.  Like an SCR's dI/dt rating, local heating can cause
failure not expected for that current level.

Tim

--
Deep Fryer: A very philosophical monk.
Website @ http://webpages.charter.net/dawill/tmoranwms

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:kh37j3lf5dcvpidvm7rl1403mb56ik05og@4ax.com...
> >The diode circuit cannot be designed correctly (because it is being
> >operated outside its specifications).
>
> What a bizarre thing to say. I'm an electrical engineer, and I do
> stuff like this all the time. The behavior of forward-biased PN
> junctions is fairly well known by now. And as Austin pointed out, the
> actual operating range of Vccaux is huge.
>
> >
> >If you are saying it is easier to "get it working" for a diode circuit
> >than an LDO, you may be correct, under the right conditions (which
> >generally disappear the moment the product is shipped).
> >
> >As mentioned earlier, continuously forward biasing a diode designed to
> >operate reverse-biased may cause long term problems.
>
> Why would it do that? What would be the failure mechanism? What would
> be the failure mode?
>
> Incidentally, zeners are use in the forward direction all the time,
> like in bidirectional clippers and transzorbs.
>
> John
>
>



Article: 125927
Subject: Re: not totally repulsive
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 08 Nov 2007 21:23:30 -0800
Links: << >>  << T >>  << A >>
On Thu, 8 Nov 2007 23:14:35 -0600, "Tim Williams"
<tmoranwms@gmail.com> wrote:

>The point is current spreading.  Because they aren't intended for handling
>large forward currents, their junctions aren't designed to handle the
>thermal effects.  Like an SCR's dI/dt rating, local heating can cause
>failure not expected for that current level.
>
>Tim

I'm not all that concerned about dissipating 40 milliwatts in a 1-watt
zener.

John


Article: 125928
Subject: Re: Xilinx Parallel Cable IV, API spec
From: kgll8ss@yahoo.com
Date: Thu, 08 Nov 2007 21:27:00 -0800
Links: << >>  << T >>  << A >>
Maybe Xilinx Parallel Cable IV is backwards compatible with Paralllel
Cable III ..?? which is supported by xilprg-0.5 it seems.


Article: 125929
Subject: MANIK LwIP port
From: "Ju, Jian" <eejju@polyu.edu.hk>
Date: Fri, 9 Nov 2007 14:27:40 +0800
Links: << >>  << T >>  << A >>
Hi all,

I'm evaluating the MANIK mircoprocess from niktech (www.niktech.com). 
Following the GettingStarteedGuide, the first two examples (banner and 
ttest) can run happily. But I meet some problem when I compile the LwIP port 
for MANIK. I downloaded the code from the website and extract it to 
harddisk, them make. Here's the error messages:

$ make
Makefile:90: .depend: No such file or directory
Makefile:98: *** multiple target patterns. Stop.

Any suggestions? Thank you.

JJ 



Article: 125930
Subject: Re: Maximum current drive according to datasheet ?!
From: jidan1@hotmail.com
Date: Thu, 08 Nov 2007 23:49:53 -0800
Links: << >>  << T >>  << A >>
On 8 Nov., 17:36, austin <aus...@xilinx.com> wrote:
> JJ,
>
> You do not need to protect against momentary shorts to ground, or Vcco
> (as long as you are within our abs max limits -- which you may well be
> for a LVCMOS 23.5V 12 mA output as mentioned in the previous post).
>
> What will KILL any CMOS part, is a momentary short to a negative
> voltage, which causes currents in excess of 200 mA to flow (in telecom,
> with -48 battery everywhere, this is a real concern, as it is instant
> death to short to -48V!!!!).
>
> Next, Xilinx abs max specs are perhaps different from some of our
> competition:  they are the limits at which there is no damage, or
> reliability concerns (ie at these extremes, less than 0.1% of the parts
> will fail after 20 years under these conditions).
>
> Often, manufacturers use the "abs max" as where the damage exceeds the
> 0.1%/year at end of life, as it looks so much better (it makes their
> parts appear more robust, when they are not that robust at all -- we all
> use a standard foundry process, and all use similar design rules, so we
> all have really the similar behavior when it comes to overstress,
> reliability and failure).
>
> TANSTAFL
>
> Austin


@Austin

The problem is that the shorts may not be momentary.


@John_H


	     |	        |
(FPGA) pin A |--------->| pin B (DUT)
	     |	        |
	     |	        |


The shorts cases on the Device-under-Test(DUT) are:

1) pin B is shorted to GND
2) pin B is shorted to VCC



If pin B on the DUT is an input pin, and I try to measure the state of
that pin, the FPGA will read it unexactly as either high or low, since
pin B is floating.
If I enabled a pull-up resistor on pin A on the FPGA, I can check if
pin B is shorted to GND, but If pin B is shorted to VCC, I wont know
if its because of the pull-up resistor on the FPGA pin or because of
an error. Please correct me if I am wrong.

So IMHO, an effective solution is a series resistor. But since the
fastest signals I will be getting through the FPGA is 100 MHz, I don't
know if this is ok or not. I checked the IBIS model, there one can
find the rise and fall time with a 50Ohm resistor, but I want the data
for 100 Ohm.

JJ



Article: 125931
Subject: Re: Maximum current drive according to datasheet ?!
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 09 Nov 2007 21:42:38 +1300
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> On 8 Nov., 17:36, austin <aus...@xilinx.com> wrote:
> 
>>JJ,
>>
>>You do not need to protect against momentary shorts to ground, or Vcco
>>(as long as you are within our abs max limits -- which you may well be
>>for a LVCMOS 23.5V 12 mA output as mentioned in the previous post).
>>
>>What will KILL any CMOS part, is a momentary short to a negative
>>voltage, which causes currents in excess of 200 mA to flow (in telecom,
>>with -48 battery everywhere, this is a real concern, as it is instant
>>death to short to -48V!!!!).
>>
>>Next, Xilinx abs max specs are perhaps different from some of our
>>competition:  they are the limits at which there is no damage, or
>>reliability concerns (ie at these extremes, less than 0.1% of the parts
>>will fail after 20 years under these conditions).
>>
>>Often, manufacturers use the "abs max" as where the damage exceeds the
>>0.1%/year at end of life, as it looks so much better (it makes their
>>parts appear more robust, when they are not that robust at all -- we all
>>use a standard foundry process, and all use similar design rules, so we
>>all have really the similar behavior when it comes to overstress,
>>reliability and failure).
>>
>>TANSTAFL
>>
>>Austin
> 
> 
> 
> @Austin
> 
> The problem is that the shorts may not be momentary.
> 
> 
> @John_H
> 
> 
> 	     |	        |
> (FPGA) pin A |--------->| pin B (DUT)
> 	     |	        |
> 	     |	        |
> 
> 
> The shorts cases on the Device-under-Test(DUT) are:
> 
> 1) pin B is shorted to GND
> 2) pin B is shorted to VCC
> 
> 
> 
> If pin B on the DUT is an input pin, and I try to measure the state of
> that pin, the FPGA will read it unexactly as either high or low, since
> pin B is floating.
> If I enabled a pull-up resistor on pin A on the FPGA, I can check if
> pin B is shorted to GND, but If pin B is shorted to VCC, I wont know
> if its because of the pull-up resistor on the FPGA pin or because of
> an error. Please correct me if I am wrong.
> 
> So IMHO, an effective solution is a series resistor. But since the
> fastest signals I will be getting through the FPGA is 100 MHz, I don't
> know if this is ok or not. I checked the IBIS model, there one can
> find the rise and fall time with a 50Ohm resistor, but I want the data
> for 100 Ohm.
> 
> JJ

Couple of solutions: Look at universal programmers

They have parallel R (~1K) and small Cap (20-100pF region), so the edges 
are fast, but a stuck pin causes little grief. That also protects
against DC drive outside the rails.


Or you can add drive-check logic inside the FPGA, and read-back to check
if the Driven level, is ever <> Pin level, for some defined time limit.
If it is, you remoe the drive, and either flag it, or go into a 
power-save hiccup mode (see SMPS)

-jg


Article: 125932
Subject: Re: Xilinx Parallel Cable IV, API spec
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 09 Nov 2007 09:04:55 -0000
Links: << >>  << T >>  << A >>
On 9 Nov., 06:09, kgll...@yahoo.com wrote:
> Is the hardware API for "Xilinx Parallel Cable IV Model DLC7"
> published or does one have to figure that out by traditional
> engineering methods ..?
> (I want to know how to talk to the programmer cable by setting bits at
> port 0x378..)

it is SUPER SECRET :(

thats also the reason there are no 3rd party drivers
thats the reason why it works so bad - on most cases the Cable IV
works in Cable III fallback mode because of SUPERS**** windriver stuff
that just failes

the jedec file can however be readback, and i have jedec to vhdl
convertert that converts 98% correctly back to vhdl but have had no
time to fully RE the protocol

if somebody is interested i can release the jed2vhdl converter with
source codes, after little tweaking it should be able to produce VHDL
that can be compiled back to working cable IV CPLD

Antti










Article: 125933
Subject: is marked OBSOLETE????
From: xenix <lastval@gmail.com>
Date: Fri, 09 Nov 2007 09:58:10 -0000
Links: << >>  << T >>  << A >>
hello all,
i would like to ask if you can give me a hint on this problem
"ERROR:MDT - Ip ppc405 2.00.a is marked OBSOLETE"  in edk6.2 version.

thank you all:)


Article: 125934
Subject: Re: not totally repulsive
From: MikeShepherd564@btinternet.com
Date: Fri, 09 Nov 2007 13:31:37 +0000
Links: << >>  << T >>  << A >>
>The point is current spreading.  Because they aren't intended for handling
>large forward currents, their junctions aren't designed to handle the
>thermal effects.  Like an SCR's dI/dt rating, local heating can cause
>failure not expected for that current level.

Do you have a serious reference for this?

Article: 125935
Subject: Re: P160 Communication Module 3
From: ratemonotonic <niladri1979@gmail.com>
Date: Fri, 09 Nov 2007 13:40:19 -0000
Links: << >>  << T >>  << A >>
On Nov 9, 12:45 am, Bryan <bryan.fletc...@avnet.com> wrote:
> The documentation for the P160 Comm 3 is still posted on the Avnet DRC
> (www.em.avnet.com/drc), but the module is not for sale anymore.  You
> could try checking with your Avnet FAE or try finding a used one
> somewhere.
>
> The P160 Comm 2 is still available, but it has a PHY rather than MAC
> +PHY.
>
> Another alternative (but different hardware), is the Spartan-3 Mini-
> Module.  This has the same MAC+PHY as the P160 Comm 3.
>
> http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25724%2...
>
> Bryan
>
> Sean Durkin wrote:
> > ratemonotonic wrote:
> > > Oh no ! I Have done a preliminary system design with the assumption
> > > that a addon ethernet MAC/PHY Chip like P160 comms 3 module will be
> > > available, for my memec Spartan 3 LC devlopment kit. Is there any way
> > > out of this dilemma?
> > When I asked my FAE about a year ago, I got the following response:
>
> > Re: XILINX MEMEC Boards Future:
> > We have developed a new expansion standard called EXP.  All new boards
> > will use this format, and AvBus and P160/P240 will go away.  We have
> > created a EXP-to-P160 adaptor to allow P160 modules to connect to the
> > new EXP boards.  You can see more info on EXP atwww.em.avnet.com/exp
>
> > HTH,
> > Sean
>
> > --
> > My email address is only valid until the end of the month.
> > Try figuring out what the address is going to be after that...

Hi Brayan ,

Yes it looks good. I thinks I will buy this.

BR
Rate.


Article: 125936
Subject: Re: Maximum current drive according to datasheet ?!
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 09 Nov 2007 14:18:55 GMT
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> 
> @Austin
> 
> The problem is that the shorts may not be momentary.
> 
> 
> @John_H
> 
> 
> 	     |	        |
> (FPGA) pin A |--------->| pin B (DUT)
> 	     |	        |
> 	     |	        |
> 
> 
> The shorts cases on the Device-under-Test(DUT) are:
> 
> 1) pin B is shorted to GND
> 2) pin B is shorted to VCC
> 
> 
> 
> If pin B on the DUT is an input pin, and I try to measure the state of
> that pin, the FPGA will read it unexactly as either high or low, since
> pin B is floating.
> If I enabled a pull-up resistor on pin A on the FPGA, I can check if
> pin B is shorted to GND, but If pin B is shorted to VCC, I wont know
> if its because of the pull-up resistor on the FPGA pin or because of
> an error. Please correct me if I am wrong.
> 
> So IMHO, an effective solution is a series resistor. But since the
> fastest signals I will be getting through the FPGA is 100 MHz, I don't
> know if this is ok or not. I checked the IBIS model, there one can
> find the rise and fall time with a 50Ohm resistor, but I want the data
> for 100 Ohm.
> 
> JJ

If your DUT is shorted to ground (pin B) and you only ever drive ground, 
there's not a problem.  If the pin is shorted to VCC and you never drive 
anything but VCC, there's not a problem.  If the pin is shorted to 
another pin and the two outputs driving those pins are always the same 
state, there's not a problem.

If you drive an output that doesn't quickly settle to its expected logic 
state, you have a problem and can tristate that signal and raise a flag 
with no damage to the FPGA and no compromise on the communication speed 
or signal fidelity.

Series resistors will also work but will not flag the customer that 
there's a problem with the DUT.

All that having been said, if your DUT is an unterminated signal with a 
single load (rather than a daisy-chain of signals) you may do better 
with 33 ohm to 50 ohm series resistors depending on the board trace 
impedances.  The source termination will drive the signal to about half 
the expected logic level until the open is detected on the other end of 
the transmission line.  When the reflection from the open reflects back, 
rather than the current driving back into the output because of a 
reflected over-voltage, the reflected voltage will be correct and the 
output simply stop driving.  For these terminations, it's often best to 
be smaller than the characteristic impedance because the drive has an 
added effective impedance; the combination is what ideally matches the 
transmission line impedance.

- John_H

Article: 125937
Subject: Re: FIFO interface design
From: John Retta <jretta@rtc-inc.com>
Date: Fri, 09 Nov 2007 07:39:33 -0700
Links: << >>  << T >>  << A >>

> 
> If your MCU is running much slower than the FPGA, you can use the
> FPGA's internal clock to run the synchronous FIFO, and a little
> state logic to generate the necessary (single cycle) pulses for
> read and write from the MCU interface signals.

In this case, logic is simply an edge detect.

ie.

reg     read_level_q;
wire    fifo_read_trailing_edge_det = ~read_level & read_level_q;

always @ (posedge clk)
   begin
     read_level_q <= read_level;
   end


-- 

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

Article: 125938
Subject: EDK 9.2 install problem
From: Philip Potter <pgp@see.sig.invalid>
Date: Fri, 09 Nov 2007 14:50:48 +0000
Links: << >>  << T >>  << A >>
Hi there,

We just received EDK 9.2 but there seems to be an error in the install. 
I tried to install it and got the error message "F:\idata\drop28.zip.xz 
error in zipfile". The installer continued after this message, with the 
percentage progress bar continuing to rise, but at some point afterwards 
the windows closes and leaves me with a half-installed EDK install.

I took a screenshot of the error message here:
http://www.doc.ic.ac.uk/~pgp/edk9.2error.png

Has anyone had a similar problem? Is it just a corrupt file on the 
install medium?

Phil

PS I would have opened a WebCase rather than reporting it here, but 
unfortunately it seems students aren't allowed WebCase access.

-- 
Philip Potter pgp <at> doc.ic.ac.uk

Article: 125939
Subject: ROM (altsyncram) corruption
From: cs_posting@hotmail.com
Date: Fri, 09 Nov 2007 07:19:52 -0800
Links: << >>  << T >>  << A >>
Anyone ever seen the contents of an FPGA "rom" (made up of several
Stratix M4k rams with one read only port) corrupted?

I have a design where the 80 mhz system clock is coming via the sample
clock in-out path of a high performance ADC from an external low phase
noise generator.  If the clock glitches, cuts out, etc, the contents
of some, but not all, of my FIR coefficient ROMs get scrambled.

The read ports of these ROMs are run from this clock, but it shouldn't
be possible to write to them.  I also have a RAM that is writeable,
and it similarly gets scrambled.

I don't really want to use the clock PLLs, since my output registers
need to be synchronized to the low phase noise source, which an FPGA
PLL is not.  I did some preliminary experiments with clocking most of
the logic from a PLL and keeping only the input and output registers
on the raw clock input, but I don't like working around a problem that
in my opinion really shouldn't be happening.

Any ideas why clock glitches could corrupt the ROMs?  Only theory I
can come up with is that maybe a bunch of faster than usual edges
kerchunk all the logic, overtaxing the instantaneous power supply.

Anyone seen something similar?


Article: 125940
Subject: Re: is marked OBSOLETE????
From: Jon Beniston <jon@beniston.com>
Date: Fri, 09 Nov 2007 08:14:47 -0800
Links: << >>  << T >>  << A >>
On 9 Nov, 09:58, xenix <last...@gmail.com> wrote:
> hello all,
> i would like to ask if you can give me a hint on this problem
> "ERROR:MDT - Ip ppc405 2.00.a is marked OBSOLETE"  in edk6.2 version.
>
> thank you all:)

My guess is that version of the PPC core is obsolete.



Article: 125941
Subject: Re: not totally repulsive
From: Andy <jonesandy@comcast.net>
Date: Fri, 09 Nov 2007 08:17:00 -0800
Links: << >>  << T >>  << A >>
On Nov 8, 4:42 pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesa...@comcast.net>
> >The diode circuit cannot be designed correctly (because it is being
> >operated outside its specifications).
>
> What a bizarre thing to say. I'm an electrical engineer, and I do
> stuff like this all the time. The behavior of forward-biased PN
> junctions is fairly well known by now.

You have a degree in Electrical Engineering. So do I.

When you design electronics that has to work right every time or the
wrong people will die, you learn to do it right.

The forward biased behavior of PN junctions designed to be operated
primarily (albeit not exclusively) in the negative biased mode is not
nearly so simple. I'm not an expert on forward biased zener diodes,
and I wouldn't use it that way unless I was. Apparently, from other
posts on this, there are potential problems that you and I are not
fully aware of. I won't design a product that way. I may design an
experiment that way, but I will specify additional analysis,
screening, and source control measures to ensure that, once proven to
be effective over the entire operating range, a product will continue
to operate correctly over its entire range of operating conditions,
over the duration of its production and useful life. Anything less is
hacking, not engineering. And the cost of those additional measures
nearly always exceeds the cost of doing it right in the first place.

Andy



Article: 125942
Subject: Re: not totally repulsive
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 09 Nov 2007 08:47:44 -0800
Links: << >>  << T >>  << A >>
On Fri, 09 Nov 2007 08:17:00 -0800, Andy <jonesandy@comcast.net>
wrote:

>On Nov 8, 4:42 pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesa...@comcast.net>
>> >The diode circuit cannot be designed correctly (because it is being
>> >operated outside its specifications).
>>
>> What a bizarre thing to say. I'm an electrical engineer, and I do
>> stuff like this all the time. The behavior of forward-biased PN
>> junctions is fairly well known by now.
>
>You have a degree in Electrical Engineering. So do I.
>
>When you design electronics that has to work right every time or the
>wrong people will die, you learn to do it right.
>
>The forward biased behavior of PN junctions designed to be operated
>primarily (albeit not exclusively) in the negative biased mode is not
>nearly so simple. I'm not an expert on forward biased zener diodes,
>and I wouldn't use it that way unless I was. Apparently, from other
>posts on this, there are potential problems that you and I are not
>fully aware of. I won't design a product that way. I may design an
>experiment that way, but I will specify additional analysis,
>screening, and source control measures to ensure that, once proven to
>be effective over the entire operating range, a product will continue
>to operate correctly over its entire range of operating conditions,
>over the duration of its production and useful life. Anything less is
>hacking, not engineering. And the cost of those additional measures
>nearly always exceeds the cost of doing it right in the first place.
>
>Andy
>

I didn't design the diode in originally; it was a hack to fix a
problem on these boards. People who are "not an expert on forward
biased zener diodes" are conjecturing problems without suggesting what
they might actually be, except prissy comments about "not the intended
use", as if the silicon cares.

All rectifier diodes are zener diodes, and they seem to work in the
forward direction for a long time. 

The only thing remotely like this that I've ever heard of is the fact
that longterm zenering of a transistor b-e junction can reduce beta.
I've never heard that forward biasing a diode can damage its
forward-bias performance. [1]

Hell, I'll probably use the diode next rev, too. I'm starting to like
it.

John

[1] except for GaAs tunnel diodes.

Article: 125943
Subject: What the 'c2p' and 'c2o' stand for?
From: ZHI <threeinchnail@gmail.com>
Date: Fri, 09 Nov 2007 11:42:51 -0800
Links: << >>  << T >>  << A >>
There is a timing diagram comparison between using DCM and not using
DCM in http://www.xilinx.com/products/design_resources/highspeed_design/hsd_clockmanagement.htm

I don't know what the 'c2p' and 'c2o' mean here. The result I found
is  'c2p' stands for Military DC-DC Power Supplies and 'c2o' is 1.8,
2.5, 3.3, 5.0 volt CMOS Oscillator. It looks not good. Does anybody
know the meaning of them exactly good for explaining in the diagram.
Many thanks.


Article: 125944
Subject: Re: ROM (altsyncram) corruption
From: MikeShepherd564@btinternet.com
Date: Fri, 09 Nov 2007 19:58:33 +0000
Links: << >>  << T >>  << A >>
From "Cyclone II Device Handbook", volume 1, (Altera Corporation,
Februrary 2007), page 2-28:

"Violating the setup or hold time on the memory block address
registers could corrupt memory contents. This applies to both
read and write operations".

Probably you should check the Stratix handbook for your case.


>Anyone ever seen the contents of an FPGA "rom" (made up of several
>Stratix M4k rams with one read only port) corrupted?
>
>I have a design where the 80 mhz system clock is coming via the sample
>clock in-out path of a high performance ADC from an external low phase
>noise generator.  If the clock glitches, cuts out, etc, the contents
>of some, but not all, of my FIR coefficient ROMs get scrambled.
>
>The read ports of these ROMs are run from this clock, but it shouldn't
>be possible to write to them.  I also have a RAM that is writeable,
>and it similarly gets scrambled.
>
>I don't really want to use the clock PLLs, since my output registers
>need to be synchronized to the low phase noise source, which an FPGA
>PLL is not.  I did some preliminary experiments with clocking most of
>the logic from a PLL and keeping only the input and output registers
>on the raw clock input, but I don't like working around a problem that
>in my opinion really shouldn't be happening.
>
>Any ideas why clock glitches could corrupt the ROMs?  Only theory I
>can come up with is that maybe a bunch of faster than usual edges
>kerchunk all the logic, overtaxing the instantaneous power supply.
>
>Anyone seen something similar?

Article: 125945
Subject: Re: What the 'c2p' and 'c2o' stand for?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Fri, 9 Nov 2007 12:08:09 -0800
Links: << >>  << T >>  << A >>
"ZHI" <threeinchnail@gmail.com> wrote in message 
news:1194637371.064656.155460@50g2000hsm.googlegroups.com...
> There is a timing diagram comparison between using DCM and not using
> DCM in 
> http://www.xilinx.com/products/design_resources/highspeed_design/hsd_clockmanagement.htm
>
> I don't know what the 'c2p' and 'c2o' mean here. The result I found
> is  'c2p' stands for Military DC-DC Power Supplies and 'c2o' is 1.8,
> 2.5, 3.3, 5.0 volt CMOS Oscillator. It looks not good. Does anybody
> know the meaning of them exactly good for explaining in the diagram.
> Many thanks.

Interpret them as "Clock to Pad" where the reference is to the external 
clock and "Clock to Output" where the reference is to the internal clock. 
This is not an "industry standard" notation of any kind because, frankly, 
there are no industry standards for this kind of stuff.  The author probably 
took a little more liberty in the diagrams than most would.

- John_H 



Article: 125946
Subject: Bitslip function in the V5 GTP Transmitter
From: cpandya@yahoo.com
Date: Fri, 09 Nov 2007 12:21:46 -0800
Links: << >>  << T >>  << A >>
Is there a bit slip function in the V5 GTP transmitter?  Normaly this
function is supported in the deserializer devices for alignment
purposes.

Thanks.

CP


Article: 125947
Subject: Re: ROM (altsyncram) corruption
From: cs_posting@hotmail.com
Date: Fri, 09 Nov 2007 12:32:53 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 2:58 pm, MikeShepherd...@btinternet.com wrote:
> From "Cyclone II Device Handbook", volume 1, (Altera Corporation,
> Februrary 2007), page 2-28:
>
> "Violating the setup or hold time on the memory block address
> registers could corrupt memory contents. This applies to both
> read and write operations".

Interesting idea, as one discovery I made is that if I hold my logic
in user reset while abusing the clock, it seems to survive, provided I
bring it out of reset only under conditions of a clean clock.

Reset does nothing to the memory itself, but it does mean that the
address register isn't changing.

Still, even if an explanation, this seems like it would be pretty
spotty behavior for a "ROM" !


Article: 125948
Subject: Re: FPGA Clock signal
From: John LeVieux <jlavie@yahoo.com>
Date: Fri, 09 Nov 2007 20:42:12 -0000
Links: << >>  << T >>  << A >>
On Nov 8, 8:41 pm, raull...@hotmail.com wrote:
> On Nov 7, 10:02 pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > raull...@hotmail.com wrote:
> > > i would like to ask how can i capture the FPGA master clock signal in
> > > the oscilloscope? Bcos in the data sheet, it indicates that the master
> > > clock is located at pin N9 which is not accessible externally. please
> > > help. thanks a million
>
> > Are you *sure* this signal is not externally accessible?  Typically the
> > BGA package has a matrix of pads and vias.  The via for the clock signal
> > should be exposed on the back of the board, ready for a steady hand to
> > probe the clock right there "at" the package ball.
>
> i am using the XEM3010 board. really have no idea how to tap the
> signal. please help..

Is there a schematic available in the XEM3010 documentation? If so, it
should be possible to find another pin somewhere else on the board
where the same clock signal can be probed with your oscilloscope.

John LeVieux


Article: 125949
Subject: Re: ROM (altsyncram) corruption
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 9 Nov 2007 14:37:36 -0800
Links: << >>  << T >>  << A >>
<cs_posting@hotmail.com> wrote in message 
news:1194640373.390273.6770@19g2000hsx.googlegroups.com...
> On Nov 9, 2:58 pm, MikeShepherd...@btinternet.com wrote:
>> From "Cyclone II Device Handbook", volume 1, (Altera Corporation,
>> Februrary 2007), page 2-28:
>>
>> "Violating the setup or hold time on the memory block address
>> registers could corrupt memory contents. This applies to both
>> read and write operations".
>
>
> Still, even if an explanation, this seems like it would be pretty
> spotty behavior for a "ROM" !
>
FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.
http://www.xilinx.com/support/answers/21870.htm
HTH., Syms. 





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

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