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 113525

Article: 113525
Subject: Re: How does FPGA tools infer FIFO
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 15 Dec 2006 15:25:15 +0100
Links: << >>  << T >>  << A >>
KJ schrieb:
> "John_H" <newsgroup@johnhandwork.com> wrote in message 

> After all, there are many ways to code just a flip flop and the tools can 
> recognize all of those as well so you could rightly ask the same question 
> about how the tools detect a flip flop.
Hmm. How about the naive way to code a flip-flop with enable in vhdl:
if rising_edge(clk) and enable='1' then
 q <= d;
end if;

Does not work on any tool that I have seen.

There was a paper on a GI workshop recently that greatly inproved what
can be synthesized by doing VHDL->VHDL transformations by XML and XSLTs.
But the VHDL compiler vendors apparently do not care.

Kolja Sulimma
cronologic

Article: 113526
Subject: Re: electrical interface problem LVPECL - LVDS multi-inputs
From: "Gabor" <gabor@alacron.com>
Date: 15 Dec 2006 06:38:12 -0800
Links: << >>  << T >>  << A >>

Andy wrote:
> Those clock inputs cannot be configured as LVPECL? I know general
> purpose differential inputs can be LVPECL. You have to terminate on
> board though.
>

My understanding of LVDS inputs is that you have a differential
receiver that switches at the signal crossing point within the
specified timing as long as your common mode voltage is
within the databook spec.  I haven't used Virtex-4 yet, but
at least in earlier Xilinx parts the LVDS input common mode
range was broad enough to support LVPECL.  This will most
likely depend on the VCCio for that bank.  The datasheet
seems to imply that you have the full GND to VCCio range
for signal swing.  Common mode range would be less.


Article: 113527
Subject: Re: IQ multiplier
From: Jerry Avins <jya@ieee.org>
Date: Fri, 15 Dec 2006 10:12:29 -0500
Links: << >>  << T >>  << A >>
Howard Long wrote:

   ...

> I think what the OP is alluding to when saying that s/he's "multiplying it 
> with I and Q signals" is that the input signal's being mixed by a 50MHz 
> quadrature oscillator.

That was also my guess, but I wanted it from him for two reasons; to be 
sure, so we don't go round in circles using different assumptions, and 
also to see if he knew enough about the system he wants to understand to 
be able to fill in the blocks in his block diagram. It's OK to treat 
those blocks as magic boxes until you have to implement them. Then not.

> Rick Lyons' excellent treatise on the subject is here: 
> http://www.dspguru.com/info/tutor/QuadSignals.pdf. For me, this was one of 
> those articles you read where the penny miraculously drops.

Yes. Rick has the gift of clarity.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 113528
Subject: Re: How does FPGA tools infer FIFO
From: "Hans" <hans64@ht-lab.com>
Date: Fri, 15 Dec 2006 15:20:18 GMT
Links: << >>  << T >>  << A >>

"Kolja Sulimma" <news@sulimma.de> wrote in message 
news:4582b04f$0$30323$9b4e6d93@newsspool1.arcor-online.net...
> KJ schrieb:
>> "John_H" <newsgroup@johnhandwork.com> wrote in message
>
>> After all, there are many ways to code just a flip flop and the tools can
>> recognize all of those as well so you could rightly ask the same question
>> about how the tools detect a flip flop.
> Hmm. How about the naive way to code a flip-flop with enable in vhdl:
> if rising_edge(clk) and enable='1' then
> q <= d;
> end if;
>
> Does not work on any tool that I have seen.

Gated clocks are well understood and supported by high-end synthesis tools 
like Precision and Synplify. If you synthesis the above circuit the enable 
gets connected to the FF CE input.

Hans
www.ht-lab.com




>
> There was a paper on a GI workshop recently that greatly inproved what
> can be synthesized by doing VHDL->VHDL transformations by XML and XSLTs.
> But the VHDL compiler vendors apparently do not care.
>
> Kolja Sulimma
> cronologic 



Article: 113529
Subject: Re: electrical level conversion
From: "Richard Henry" <pomerado@hotmail.com>
Date: 15 Dec 2006 08:35:00 -0800
Links: << >>  << T >>  << A >>

Hal Murray wrote:
> >I fully agree with John; get direct advice from someone versed in
> >transmission line effects. For the LVDS inputs from PECL drive, I am
> >surprised no-one from Xilinx has chipped in, but because I am
> >interested, I'll pull the datasheet for V4 later on and see what it says
> >about input range etc.
>
> The Xilinx people are probably on comp.arch.fpga

Hoping they will chime in, I have added caf.


Article: 113530
Subject: Re: electrical level conversion
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 15 Dec 2006 08:59:38 -0800
Links: << >>  << T >>  << A >>
All,

I have previously posted on the differential input circuit that we
(Xilinx) use.

I will repeat what I have said before:  the differential input circuit
is a full CMOS differential comparator.  It will operate (function) from
rail to rail on its inputs.  Its performance has only been characterized
for LVDS, and low voltage LVPECL common mode voltages and swings.

Now for the new part:  there are no configuration bits to select
anything.  The comparator is the comparator, and it is the same circuit
regardless of standard selected.  If it is differential, it is the same
circuit.

Hope this helps,

Austin

Article: 113531
Subject: Xilinx ISE 8.2.3 - Re-Creating Projects
From: "marc_ely" <marc_ely@yahoo.co.uk>
Date: 15 Dec 2006 09:11:10 -0800
Links: << >>  << T >>  << A >>
Hi

A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped
meeting my timings.  Since I moved I have had nothing but problems with
project files and their corruption.
I have finally settled on 8.2.3 as it appeared more stable than older
patched versions.  8.2.0 was dire.

The project file corruptions seem to occur randomly and will do various
things, such as remove all files from the project (and not let you add
them back), or not let you edit coregen parts, or a host of other
things.

Re-creating a project each time seems very laborious.  Does anyone have
any shortcuts to do this?  Is there a TCL script that can be run?
Archiving and Project Cleanup don't help.

The project is a mix of VHDL, verilog and coregen parts (xaw and xco).

Why can't they just implement project files as text files and let you
control them by hand?

Regards
Marc


Article: 113532
Subject: Xilins ISE Re-Creating Projects
From: "marc_ely" <marc_ely@yahoo.co.uk>
Date: 15 Dec 2006 09:13:10 -0800
Links: << >>  << T >>  << A >>
Hi

A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped
meeting my timings.  Since I moved I have had nothing but problems with
project files and their corruption.
I have finally settled on 8.2.3 as it appeared more stable than older
patched versions.  8.2.0 was dire.

The project file corruptions seem to occur randomly and will do various
things, such as remove all files from the project (and not let you add
them back), or not let you edit coregen parts, or a host of other
things.

Re-creating a project each time seems very laborious.  Does anyone have
any shortcuts to do this?  Is there a TCL script that can be run?
Archiving and Project Cleanup don't help.

The project is a mix of VHDL, verilog and coregen parts (xaw and xco).

Why can't they just implement project files as text files and let you
control them by hand?

Regards
Marc


Article: 113533
Subject: Re: Virtex-II Pro: Reading/Writing data with Compact Flash
From: "David" <dpmontminy@gmail.com>
Date: 15 Dec 2006 09:16:43 -0800
Links: << >>  << T >>  << A >>
Are you using any type of operating system to do the reading and
writing?


Article: 113534
Subject: Re: electrical level conversion
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 15 Dec 2006 17:32:58 -0000
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:eluk9r$fjj2@cnn.xsj.xilinx.com...
> All,
>
> I have previously posted on the differential input circuit that we
> (Xilinx) use.
>
> I will repeat what I have said before:  the differential input circuit
> is a full CMOS differential comparator.  It will operate (function) from
> rail to rail on its inputs.  Its performance has only been characterized
> for LVDS, and low voltage LVPECL common mode voltages and swings.
>
> Now for the new part:  there are no configuration bits to select
> anything.  The comparator is the comparator, and it is the same circuit
> regardless of standard selected.  If it is differential, it is the same
> circuit.
>
> Hope this helps,
>
> Austin

FWIW, I think the OP is talking about the MGT clock inputs. But the same 
applies, I guess.
Cheers, Syms. 



Article: 113535
Subject: Re: FPGA : Async FIFO, Programmable full
From: Ray Andraka <ray@andraka.com>
Date: Fri, 15 Dec 2006 12:37:24 -0500
Links: << >>  << T >>  << A >>
Tommy Thorn wrote:
> Peter Alfke wrote:
> 
>>In an asynchronous FIFO, reading and writing is controlled by two
>>counters with independent clocks.
>>If you need to detect FULL or EMPTY, you compare the two counters for
>>identity.
>>If you do that with binary counters, you are vulnerable to strange
>>decoding glitches, while multiple binary bits change (almost, but not
>>quite, simultaneously). You never have that problem with Gray counters,
>>where only one bit changes, from one state to the next.
> 
> 
> How about a different way? Couldn't one simply maintain two views (one
> for each clock) of the state of the FIFO, always a conservative
> approximation to the "true" state, and use standard handshake
> techniques to communicate to the writer "since our last handshake, I've
> dequeued X words", and visa versa.
> 
> The advantage of this (besides simplicity) is that one can pipeline the
> handshake arbitrarily much, only at the expense of added latency
> between full->non-full and empty->non-empty transitions.
> 
> Isn't this a standard technique?
> 
> Tommy
> 

I've used similar techniques.  Basically, an alternative to using gray 
code is to maintain population counts that are separate from the read 
and write pointers, and then resynchronizing the write event for a read 
side population count and/or resynchronizing the read event for a write 
side population count.  The things to watch are 1: you need to make sure 
that read or write events can't overrun the flag in your system.  This 
can happen if, for example, you write twice between successive read 
clock edges.  So, yes, this is a viable alternative, it will sometimes 
save some logic, can result in higher speeds, but it also carries with 
it a responsibility for the user to make sure the event flags don't overrun.

Article: 113536
Subject: Re: electrical level conversion
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 15 Dec 2006 09:53:54 -0800
Links: << >>  << T >>  << A >>
Symon,

Thanks for pointing this out -- I was answering the wrong question!

Unfortunately, no, my previous post does not apply to the dedicated
clock inputs for the MGTs.

Those differential comparators are designed to their own specific
requirements.  However, I do believe they operate for LVDS or low
voltage PECL (2.5V).  I would have to go read the data sheet, and also
the MGT user's guide.

Austin

Article: 113537
Subject: Re: Spartan-3A launched
From: "oen_br" <oen_no_spam@yahoo.com.br>
Date: 15 Dec 2006 10:51:36 -0800
Links: << >>  << T >>  << A >>
Antti,

I think he wanted to ask for the prices for the Spartan-3A.
I also could not find any prices for it.

Luiz Carlos


Article: 113538
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 15 Dec 2006 10:54:15 -0800
Links: << >>  << T >>  << A >>
First to Peter, my comment was definitely not intended as a critism of
the Async FIFO in Virtex, but as an alternative to consider for the OP.

Ray Andraka wrote:
> I've used similar techniques.  Basically, an alternative to using gray
> code is to maintain population counts that are separate from the read
> and write pointers, and then resynchronizing the write event for a read
> side population count and/or resynchronizing the read event for a write
> side population count.

That was the idea, although I'm suggesting communicating deltas rather
than absolute values (ie, how many elements read / written
respectively). It may be the same, but it seems more intuitive.

I admit I have never done it so I was looking for the potential
pitfalls.

> The things to watch are 1: you need to make sure
> that read or write events can't overrun the flag in your system.  This
> can happen if, for example, you write twice between successive read
> clock edges.

I'm not sure I follow. As writing (like reading) follow a local,
synchronous, conservative approximation that would be updated for each
write, what would stop me from adding logic to drop the write if I deem
the FIFO full?

BTW, what were the other things to look out for? :-)

> So, yes, this is a viable alternative, it will sometimes
> save some logic, can result in higher speeds, but it also carries with
> it a responsibility for the user to make sure the event flags don't overrun.

Thanks,
Tommy


Article: 113539
Subject: uClinux bootloader on Spartan-3e Starter Kit
From: "jerzy.zielinski" <jerzy.zielinski@gmail.com>
Date: 15 Dec 2006 13:04:38 -0800
Links: << >>  << T >>  << A >>
Hi all,

   I was abble to compile working uClinux core for the Spartan-3e
Starter Kit. I was abble to program on board Flash Memory so the
system.bit starts by itself.

Can anyone help me with the bootloader, so the whole project may start
after power-on? I need to place the system.bit and linux core somewhere
on the board so it may boot by itself...

Thanks
Jerzy
jerz.zielinski@gmail.com


Article: 113540
Subject: 3.3V LVPECL into a LVPECL_25, VCCO-2.5V on a Virtex-4
From: "Dale" <dale.prather@gmail.com>
Date: 15 Dec 2006 13:24:14 -0800
Links: << >>  << T >>  << A >>
I want to drive a LVPECL_25 input on a bank with VCCO=2.5V with a 3.3V
LVPECL signal.  Xilinx has a nice app note on doing this with a Virtex
ii and a Spartan 3, but I can't find anything concrete about doing it
on a Virtex-4.  Would you agree that it's safe to implement the same
solution on a Virtex-4?

Here's the app note:
http://www.xilinx.com/bvdocs/appnotes/xapp696.pdf
See page 4.

It's just a voltage divider.  Are there any adverse effects to this?

Thanks,
Dale


Article: 113541
Subject: Xilinx WebPack 8.2.03i: can't make .bit file when memories used in design
From: tersono <ethel.thefrog@ntlworld.com>
Date: Fri, 15 Dec 2006 21:24:32 GMT
Links: << >>  << T >>  << A >>
I can:
-make (and use succesfully) .bit files under Xilinx WebPack 8.2.03i
*unless* the design contains RAM- whether I specify it in Verilog, or
use CoreGen to specify it.

I can:
-use Verilog-defined memories if I compile under Synplify Pro, bring
the resulting file into WebPack and place,route, and generate .bit
file there.

I can't:
-use memories under WebPack- place and route is OK, but   "Generate
Programming File" fails with no error messages. This happens under XP
Pro and WIn2000.

What am I doing wrong?
--
Per ardua ad nauseam

Article: 113542
Subject: Re: FPGA : Async FIFO, Programmable full
From: Ray Andraka <ray@andraka.com>
Date: Fri, 15 Dec 2006 16:26:26 -0500
Links: << >>  << T >>  << A >>
Tommy Thorn wrote:

> First to Peter, my comment was definitely not intended as a critism of
> the Async FIFO in Virtex, but as an alternative to consider for the OP.
> 
> Ray Andraka wrote:
> 
>>I've used similar techniques.  Basically, an alternative to using gray
>>code is to maintain population counts that are separate from the read
>>and write pointers, and then resynchronizing the write event for a read
>>side population count and/or resynchronizing the read event for a write
>>side population count.
> 
> 
> That was the idea. I admit I have never done it so I was looking for
> the potential pitfalls.
> 
> 
>>The things to watch are 1: you need to make sure
>>that read or write events can't overrun the flag in your system.  This
>>can happen if, for example, you write twice between successive read
>>clock edges.
> 
> 
> I'm afraid I don't follow. As writing (resp. reading) follow a local,
> synchronous, conservative approximation how could it overrun? The
> "flag" as I understand it is direct function of the local counter so it
> would be updated for each write.
> 
> BTW, what were the other things to look out for? :-)
> 
> 
>>So, yes, this is a viable alternative, it will sometimes
>>save some logic, can result in higher speeds, but it also carries with
>>it a responsibility for the user to make sure the event flags don't overrun.
> 
> 
> Thanks,
> Tommy
> 


OK, for example, if the write clock is at 10 MHz and the read clock is 
at 5 MHz, if you wrote on 2 consecutive write clocks, then synchronizing 
them to the read clock domain, you'd lose one or both of the write 
events.  In order for this set-up to work, you need to guarantee that 
whatever signal you send across the clock domain boundary to indicate a 
write event or events is infrequent enough to be reliably sensed in the 
other domain for every single event.  If there is a possibility of 
writing too frequently, then you need some sort of signaling scheme that 
can indicate a certain number of writes occurred and update the 
population count accordingly.  If the clocks for both sides are similar 
frequencies, you need at least one clock between events to get a clean 
crossing. This extra care to make sure you don't have events happen too 
quickly for reliable operation is the reason the shrink wrapped FIFO 
components use the gray code schemes.

Article: 113543
Subject: Re: electrical level conversion
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 15 Dec 2006 13:35:56 -0800
Links: << >>  << T >>  << A >>
On Fri, 15 Dec 2006 08:59:38 -0800, Austin Lesea <austin@xilinx.com>
wrote:

>All,
>
>I have previously posted on the differential input circuit that we
>(Xilinx) use.
>
>I will repeat what I have said before:  the differential input circuit
>is a full CMOS differential comparator.  It will operate (function) from
>rail to rail on its inputs.  Its performance has only been characterized
>for LVDS, and low voltage LVPECL common mode voltages and swings.
>
>Now for the new part:  there are no configuration bits to select
>anything.  The comparator is the comparator, and it is the same circuit
>regardless of standard selected.  If it is differential, it is the same
>circuit.
>
>Hope this helps,
>
>Austin


It is, incidentally, a *very good* comparator!

John


Article: 113544
Subject: Re: 3.3V LVPECL into a LVPECL_25, VCCO-2.5V on a Virtex-4
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 15 Dec 2006 13:37:48 -0800
Links: << >>  << T >>  << A >>
Dale,

This will work.

Some care is required to keep everything short (try not to create stubs
that cause reflections).  Figure 4 is the DC divider, or Figure 6 is the
AC coupling solution (both will work).  AC coupling may be an issue if
the signals are not balanced (more 0's than 1's or more 1's than 0's).

Works for S3, S3E, S3A, V4 and V5.

Austin
(Xilinx ICDES)

> I want to drive a LVPECL_25 input on a bank with VCCO=2.5V with a 3.3V
> LVPECL signal.  Xilinx has a nice app note on doing this with a Virtex
> ii and a Spartan 3, but I can't find anything concrete about doing it
> on a Virtex-4.  Would you agree that it's safe to implement the same
> solution on a Virtex-4?
> 
> Here's the app note:
> http://www.xilinx.com/bvdocs/appnotes/xapp696.pdf
> See page 4.
> 
> It's just a voltage divider.  Are there any adverse effects to this?
> 
> Thanks,
> Dale
> 

Article: 113545
Subject: Xilinx PMCD+DCM reset question...
From: "johnp" <johnp3+nospam@probo.com>
Date: 15 Dec 2006 13:51:20 -0800
Links: << >>  << T >>  << A >>
In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a
simple
connection from the DCM to the PMCD.  They don't show the clocking for
the
reset signal going into the PMCD even though the Xilinx doc says that
the
reset should be released synchronously to with the clock.

If the DCM and the PMCD both get the same reset signal, I assume that
since the
DCM output clocks should be stopped while reset is asserted, inherently
the
release of reset will be synchronous to the clock since the clock won't
be running
at the time.

Does this match other people's understanding?

Thanks!

John Providenza


Article: 113546
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 15 Dec 2006 13:56:13 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> OK, for example, if the write clock is at 10 MHz and the read clock is
> at 5 MHz, if you wrote on 2 consecutive write clocks, then synchronizing
> them to the read clock domain, you'd lose one or both of the write
> events.

Thanks Ray. I'm sorry to persist, but I still can't agree.

When the writer writes the first item we can have one of several
situations, including:

- The reader has yet to acknowledge some messages prior to this write.
No update will be sent until it does. The writes writes another item
and updates its local count. Once the reader finally acknowledges the
original message, the writer sends a "2 written" message.

- The writer wasn't waiting and goes ahead with a "1 written" message.
The reader updates it's local count and acknowledges that it saw "1
written" message. The writer writes again etc.

- The writer wasn't waiting and goes ahead with a "1 written" message.
The reader doesn't pick up the message in time before the writer writes
to the FIFO again. No worries. Once the reader finally acknowledges the
"1 written", the writer can issue a new message to the reader with the
delta between the writers current count and the writers count at the
time of the last message, thus including the write that just happend.



> In order for this set-up to work, you need to guarantee that
> whatever signal you send across the clock domain boundary to indicate a
> write event or events is infrequent enough to be reliably sensed in the
> other domain for every single event.

IMHO, any scheme depending on such an assumption is broken (it's too
easy to forget this assumption when the design is revised a year
later). I make no assumption on the relative speed of writers and
readers. I do assume that no messages will be dropped/missed, but that
assumption can also be removed with more work.


> If there is a possibility of
> writing too frequently, then you need some sort of signaling scheme that
> can indicate a certain number of writes occurred and update the
> population count accordingly.

I beleive that's what I suggested.


Thanks
Tommy


> If the clocks for both sides are similar
> frequencies, you need at least one clock between events to get a clean
> crossing. This extra care to make sure you don't have events happen too
> quickly for reliable operation is the reason the shrink wrapped FIFO
> components use the gray code schemes.


Article: 113547
Subject: Re: Xilinx PMCD+DCM reset question...
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 15 Dec 2006 14:18:52 -0800
Links: << >>  << T >>  << A >>
John,

Yes.

The PMCD is simply some D type flip flops, with a delay matched path for
the 1X output.  If the phases of the divided clocks are important, then
reset of the PMCD is useful.  If the phases are not important, don't
even bother with the reset of the PMCD.  When the PCM input clock is
driven by the DCM, one should not worry about the reset, as you say, the
DCM will not do anything 'bad' to the PMCD while reset is asserted.

Austin

johnp wrote:
> In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a
> simple
> connection from the DCM to the PMCD.  They don't show the clocking for
> the
> reset signal going into the PMCD even though the Xilinx doc says that
> the
> reset should be released synchronously to with the clock.
> 
> If the DCM and the PMCD both get the same reset signal, I assume that
> since the
> DCM output clocks should be stopped while reset is asserted, inherently
> the
> release of reset will be synchronous to the clock since the clock won't
> be running
> at the time.
> 
> Does this match other people's understanding?
> 
> Thanks!
> 
> John Providenza
> 

Article: 113548
Subject: Re: Xilins ISE Re-Creating Projects
From: "Gabor" <gabor@alacron.com>
Date: 15 Dec 2006 14:44:49 -0800
Links: << >>  << T >>  << A >>

marc_ely wrote:
> Hi
>
> A couple of months ago I had to move up to ISE 8.2 once 7.1 stopped
> meeting my timings.  Since I moved I have had nothing but problems with
> project files and their corruption.
> I have finally settled on 8.2.3 as it appeared more stable than older
> patched versions.  8.2.0 was dire.
>
> The project file corruptions seem to occur randomly and will do various
> things, such as remove all files from the project (and not let you add
> them back), or not let you edit coregen parts, or a host of other
> things.
>
> Re-creating a project each time seems very laborious.  Does anyone have
> any shortcuts to do this?  Is there a TCL script that can be run?
> Archiving and Project Cleanup don't help.
>
> The project is a mix of VHDL, verilog and coregen parts (xaw and xco).
>
> Why can't they just implement project files as text files and let you
> control them by hand?
>
> Regards
> Marc

The 8.2 project navigator can still read the old text style .npl files.
 If you
have a copy of 6.3 or older ISE you can see how these project files
look.
There is a caveat.  When you open a .npl file from 8.2, ISE not only
converts the project to the new format and creates an .ise file, but
it also trashes the .npl file.  So always keep another copy for
re-building
the project after a crash.

HTH,
Gabor


Article: 113549
Subject: Re: Xilinx PMCD+DCM reset question...
From: "johnp" <johnp3+nospam@probo.com>
Date: 15 Dec 2006 16:03:42 -0800
Links: << >>  << T >>  << A >>
Austin -

Thanks for the clarification.

John Providenza

Austin Lesea wrote:
> John,
>
> Yes.
>
> The PMCD is simply some D type flip flops, with a delay matched path for
> the 1X output.  If the phases of the divided clocks are important, then
> reset of the PMCD is useful.  If the phases are not important, don't
> even bother with the reset of the PMCD.  When the PCM input clock is
> driven by the DCM, one should not worry about the reset, as you say, the
> DCM will not do anything 'bad' to the PMCD while reset is asserted.
>
> Austin
>
> johnp wrote:
> > In looking at the Virtex-4 documentation for the PMCD, Xilinx shows a
> > simple
> > connection from the DCM to the PMCD.  They don't show the clocking for
> > the
> > reset signal going into the PMCD even though the Xilinx doc says that
> > the
> > reset should be released synchronously to with the clock.
> >
> > If the DCM and the PMCD both get the same reset signal, I assume that
> > since the
> > DCM output clocks should be stopped while reset is asserted, inherently
> > the
> > release of reset will be synchronous to the clock since the clock won't
> > be running
> > at the time.
> >
> > Does this match other people's understanding?
> > 
> > Thanks!
> > 
> > John Providenza
> >




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