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 121400

Article: 121400
Subject: Re: Xilinx DCM Reset
From: PlayDough <pladow@gmail.com>
Date: Tue, 03 Jul 2007 19:20:44 -0000
Links: << >>  << T >>  << A >>
On Jul 3, 9:34 am, austin <aus...@xilinx.com> wrote:
> Use the Locked signal from the first DCM to release resetting the second
> DCM.
>
> Locked ---> invert -----> Reset

That is what we were doing.  However, the input clock, clk, and the
associated DCM may lock before GTS is released.  As such, the second
DCM may try to aquire before the feedback clock is present.

I guess the real question is:  "How long after GSR is GTS released?"
This really determines how long to wait until the reset on the second
DCM should released.


Article: 121401
Subject: USB full speed final project proposal
From: Pinhas <bknpk@hotmail.com>
Date: Tue, 03 Jul 2007 12:24:50 -0700
Links: << >>  << T >>  << A >>
I invite you to use free code of a USB full speed project as final
work for diploma.

The site includes some description of the functionality and main state
machines.

The code is based on some free cores 8051 and USB function. The PHY is
my own code.

Pinhas

bknpk@hotmail.com

http://bknpk.no-ip.biz


Article: 121402
Subject: Re: Hobbyist trying to decide which device to start with...
From: john.m.oyler@gmail.com
Date: Tue, 03 Jul 2007 19:28:20 -0000
Links: << >>  << T >>  << A >>
On Jul 3, 2:28 pm, "MM" <m...@yahoo.com> wrote:
> <john.m.oy...@gmail.com> wrote in message
>
> news:1183486887.598253.267900@w5g2000hsg.googlegroups.com...
>
>
>
> > How does one interface to TTL logic? Which devices can be used for
> > that, and what does it take to safely hook them up to something that
> > is 5v?
>
> What do you need TTL logic for if you have an FPGA?  What is it you are
> trying to build?

I'll start out with tutorial stuff, but my real goal is some type of
accelerator for an old home computer. The fpga board would plug into
the cpu socket, sitting between it and the cpu. Maybe implement some
of the unused opcodes, have hardware fpu stuff. Still undecided on the
specifics yet.

> If you really need to interface to 5V logic you could use some of the level
> translation techniques/devices... Just google on level translation and
> you'll find a bunch of ideas....

Thank you. The first few hits are all relevant. I have some learning
to do now.


Article: 121403
Subject: Re: Rocketio connection Virtex2pro-Virtex4
From: Patrick Dubois <prdubois@gmail.com>
Date: Tue, 03 Jul 2007 19:43:56 -0000
Links: << >>  << T >>  << A >>
On 19 juin, 09:23, "Jeremie" <nos...@here.com> wrote:
> Hi everyone,
>
> Could someone with experience or simulation tools provide information on the
> hardware requirements to interconnect Virtex2pro and Virtex4 with rocketio
> at 2.5Gb/s.
> The simpler the better, DC if possible and if not AC. I'd like to know the
> termination voltages and anything needed on the lines.
> v2pro<=>v2pro and V4<=>V4 works.
> I can't get the proper setup to run aberttest V4 to v2pro (v2pro to V4 is
> easier) so if you have a working setup I'd be glad if you could describe it.
>
> Thanks,
>
> Best regards,
>
> Jeremie
>
> PS: If someone feels like describing his V5 setup I'm sure that will be
> useful for many people.

A little late response but I'd be interested to know if you have made
progress on this issue. I unfortunately cannot provide help yet but we
will soon (in 2 weeks) have to connect a V4 to a V2Pro through
RocketIO (Aurora) in the lab.

Regarding the BERT core from the Chipscope serial IO toolkit, I read
the manual but I don't see how I could use this to test a V4-V2Pro
connection unfortunately. Actually, it seems limited to a single FPGA.
I don't see how to control two FPGAs from one Chipscope interface...

Patrick


Article: 121404
Subject: Re: Spartan-3e JTAG no device id
From: Alan Nishioka <alan@nishioka.com>
Date: Tue, 03 Jul 2007 12:48:14 -0700
Links: << >>  << T >>  << A >>
On Jul 3, 11:56 am, austin <aus...@xilinx.com> wrote:
> Antti,
>
> I even hate to bring this up, but how do we know it really is the part
> it is supposed to be?  We have seen counterfeit parts (some odd die,
> packaged, and marked as Xilinx) sold to unsuspecting people by "gray
> market" resellers...
>
> If it doesn't wake up, and say "I am the Xilinx FPGA you expect me to
> be" perhaps it isn't?
>
> I certainly hope this is a simple case of a mis-wired pcb, and not a
> case of bogus components sold to an unsuspecting buyer.
>
> Austin

I bought them from Avnet, so hopefully they are not counterfeit.
Xilinx thinks it is a software problem, but I am pretty sure it is a
hardware problem.
Again, it seems JTAG works, but the internals don't.  How is this
possible?

But I have run out of ideas to try.

Alan Nishioka


Article: 121405
Subject: Re: Spartan-3e JTAG no device id
From: Alan Nishioka <alan@nishioka.com>
Date: Tue, 03 Jul 2007 12:53:36 -0700
Links: << >>  << T >>  << A >>
On Jul 3, 11:59 am, austin <aus...@xilinx.com> wrote:
> Antti,
>
> Further, we have seen where old board test continuity systems apply
> voltages (and currents) that my damage the newer 90nm and smaller devices.
>
> I certainly hope no one exceeded the absolute maximum voltage stress
> limits, and has damaged the parts.
>
> Austin

No testing was done (this is a new board bring up)
The same micrel mic2204 power supplies were used successfully with a
virtex2p design (spartan-3e swapped in to lower cost;  slightly
different vint used).

Is there a reason spartan-3e would behave differently than virtex2p?

Could this be caused by the ramp up of vint?

Alan Nishioka


Article: 121406
Subject: Re: Spartan-3e JTAG no device id
From: "Tim (one of many)" <tim@nooospam.roockyloogic.com>
Date: Tue, 03 Jul 2007 20:57:29 +0100
Links: << >>  << T >>  << A >>
Alan Nishioka wrote:
> Again, it seems JTAG works, but the internals don't.  How is this
> possible?
> 
> But I have run out of ideas to try.

Can you restrap the mode pins and try slave serial mode? That might give 
you a clue.


Article: 121407
Subject: Re: Spartan-3e JTAG no device id
From: Alan Nishioka <alan@nishioka.com>
Date: Tue, 03 Jul 2007 13:09:01 -0700
Links: << >>  << T >>  << A >>
On Jul 3, 12:57 pm, "Tim (one of many)"
<t...@nooospam.roockyloogic.com> wrote:
> Alan Nishioka wrote:
> > Again, it seems JTAG works, but the internals don't.  How is this
> > possible?
>
> > But I have run out of ideas to try.
>
> Can you restrap the mode pins and try slave serial mode? That might give
> you a clue.

I have tried changing the mode pins (difficult because they are
connected directly to V33 and gnd) to no effect.  But JTAG should work
regardless of the mode pin settings, right?

Thanks,
Alan Nishioka


Article: 121408
Subject: Re: Xilinx DCM Reset
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 13:12:37 -0700
Links: << >>  << T >>  << A >>
PlayDough,

I don't see the issue:  If the DCM locks, that implies that everything 
is present in order for it to lock.

Austin

Article: 121409
Subject: Re: Spartan-3e JTAG no device id
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 13:14:51 -0700
Links: << >>  << T >>  << A >>
Alan,

No, this is not an issue of the ramp of any supplies....

I would look for something very simple, and basic, like an open, or a short.

Austin

Article: 121410
Subject: Re: Spartan-3e JTAG no device id
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 13:27:48 -0700
Links: << >>  << T >>  << A >>
Alan,

Mode pins have no effect on JTAG.

Austin

Article: 121411
Subject: Re: Spartan-3e JTAG no device id
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 13:40:59 -0700
Links: << >>  << T >>  << A >>
Alan,

http://direct.xilinx.com/bvdocs/userguides/ug332.pdf

On page 184, it details the settings for Vccaux 2.5 volt powering of the 
JTAG.  Perhaps, this being the only difference with V2 Pro, this may 
need to be looked into?

Also, the INIT should go low, and then once the device has cleaned out, 
and is ready to be configured, INIT will return high (requires a pull-up 
resistor).

Holding INIT low, continues the cleanout, and prevents any further 
operation (until it is released).

I am not sure, but it may be that as long as INIT is low, the JTAG state 
machine may not be operating (..?..).

Austin

Article: 121412
Subject: Re: Coding style of verilog for FPGA synthesis
From: ghelbig@lycos.com
Date: Tue, 03 Jul 2007 20:41:00 -0000
Links: << >>  << T >>  << A >>
On Jun 29, 4:50 am, Allen <lphp...@gmail.com> wrote:
> Hi guys,
>
> Thanks for your replies first.
> I forget to say that function of this design is correct by using
> Design Vision and the testbench for that and this are the same.
>
> I check description of testbench.
> Timescale directive was includeded on the top of testbench and the
> custom design ( `timescale 1ns/10ps).
>
> The clock speed is 5 MHz ( #100 clock = ~ clock) and the design still
> doesn't work properly.
>
> The input singals are as what I described in the testbench.
>
> I still have no idea about how to debug or modify the design?
>
> Thanks again.
>
> Regards,
>
> Allen

Have you added the clock net to a waveform and actually looked at it?
You may have forgotten to initialize the net.

In verilog, ~X === X.

G.


Article: 121413
Subject: Re: DIFF_TERM Question
From: motty <mottoblatto@yahoo.com>
Date: Tue, 03 Jul 2007 13:47:15 -0700
Links: << >>  << T >>  << A >>
The bank voltage is 2.5.  I am using LVDS_25.  I instantiate the
buffer by hand and pass the attribute in there.  The ISE has
instantiation templates for most things.  It doesn't have one for the
IBUFDS_DIFF_OUT, but you can easily figure things out.

I'm just saying the tools give a warning and that is why I removed the
attribute.


Article: 121414
Subject: Re: Spartan-3e JTAG no device id
From: "Tim (one of many)" <tim@nooospam.roockyloogic.com>
Date: Tue, 03 Jul 2007 21:54:38 +0100
Links: << >>  << T >>  << A >>
Alan Nishioka wrote:
> I have tried changing the mode pins (difficult because they are
> connected directly to V33 and gnd) to no effect.  But JTAG should work
> regardless of the mode pin settings, right?

Yes, JTAG works in all modes. And maybe you have the mode pins set to 
salve serial. Or even floating, which means that the default pullups 
pull them to slave serial, depending on the HSWAP pin.

What I was suggesting is that you try programming the part in slave 
serial mode. That could show up any one of a host of problems. If slave 
serial works and JTAG doesn't...

Good luck.

Article: 121415
Subject: Re: Hobbyist trying to decide which device to start with...
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 03 Jul 2007 13:55:43 -0700
Links: << >>  << T >>  << A >>
3.3V I/O can drive TTL, no questions asked, for 5-V TTL's Vih min is
2.4 V
The difficult issue is 5-V TTL driving the 3.3 V CMOS input.
Most 5-V TTL only drives up to two diode drops below the rail, which
nominally means 3.6 V. (But 5-V CMOS devices drive all the way to the
rail, which poses a problem for you).
There are worst-case assumption of the 5 V supply being high, while
the 3.3 V supply is low, where things get less benign (5.5 - 1.4 =
4.1, which is 1.1 V above 3.0 V.)
Just to give you some facts.
Peter Alfke

On Jul 3, 12:28 pm, john.m.oy...@gmail.com wrote:
> On Jul 3, 2:28 pm, "MM" <m...@yahoo.com> wrote:
>
> > <john.m.oy...@gmail.com> wrote in message
>
> >news:1183486887.598253.267900@w5g2000hsg.googlegroups.com...
>
> > > How does one interface to TTL logic? Which devices can be used for
> > > that, and what does it take to safely hook them up to something that
> > > is 5v?
>
> > What do you need TTL logic for if you have an FPGA?  What is it you are
> > trying to build?
>
> I'll start out with tutorial stuff, but my real goal is some type of
> accelerator for an old home computer. The fpga board would plug into
> the cpu socket, sitting between it and the cpu. Maybe implement some
> of the unused opcodes, have hardware fpu stuff. Still undecided on the
> specifics yet.
>
> > If you really need to interface to 5V logic you could use some of the level
> > translation techniques/devices... Just google on level translation and
> > you'll find a bunch of ideas....
>
> Thank you. The first few hits are all relevant. I have some learning
> to do now.



Article: 121416
Subject: Re: Xilinx DCM Reset
From: PlayDough <pladow@gmail.com>
Date: Tue, 03 Jul 2007 21:02:53 -0000
Links: << >>  << T >>  << A >>
On Jul 3, 1:12 pm, austin <aus...@xilinx.com> wrote:
> I don't see the issue:  If the DCM locks, that implies that everything
> is present in order for it to lock.

That's precisely the problem:  everything is not necessarily there for
it lock, i.e. the feedback clock.

I am using external feedback.  That is, the sdram clock is output to
the SDRAM, then fed back into the FPGA and finally to the DCM.  Since
the sdram clock is an output, it is not driven until GTS is released.
If GTS is released during the DCM aquisition, then it can lock
incorrectly.

>From UG331, p.102:

"Why is this extra reset pulse required? For an optimum locking
process, a DCM configured with external feedback requires both the
CLKIN and either the CLK0 or CLK2X signals to be present and stable
when the DCM begins to lock. During the configuration process, the
external feedback, CLKFB, is not available because the FPGA's I/O
buffers are not yet active.

At the end of configuration, the DCM begins the capture process once
the device enters the startup sequence. Because the FPGA's global 3-
state signal (GTS) still is asserted at this time, any output pins
remain in a 3-state (high-impedance, floating) condition.
Consequently, the CLKFB signal is in an unknown logic state.
When CLKFB eventually appears after the GTS is deasserted, the DCM
proceeds to capture. However, without the reset pulse, the DCM might
not lock at the optimal point, which potentially introduces slightly
more jitter and greater clock cycle latency through the DCM.

Without the reset, another possible issue might occur if the CLKFB
signal, while in the 3-state condition, cross-couples with another
signal on the board due to a printed-circuit board signal integrity
problem. The DCM might sense this invalid cross-coupled signal as
CLKFB and use it to proceed with a lock. This possibly prevents the
DCM from properly locking once the GTS signal deasserts and the true
CLKFB signal appears."


Article: 121417
Subject: Re: Spartan-3e JTAG no device id
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 14:03:49 -0700
Links: << >>  << T >>  << A >>
Alan,

INIT is not the signal that holds the JTAG block in reset, it is the 
PROG signal, or the power ON reset.

So, if the core voltage AND the Vccaux AND the IO bank which has the 
config pins on it are all powered ON, AND if the PROG_b is not being 
intentionally held low, THEN the JTAG state machine should be released, 
and should operate.  Basically, when INIT goes high, the mode pins are 
sampled, and then based on the mode pins, the configuration state 
machine goes to whatever mode is specified, and proceeds with configuration.

If JTAG is specified by the mode pins, then the part waits to be 
configured through the JTAG port.

JTAG device ID can be read out prior to configuring (by any mode).

Amazing what digging through the schematics reveals.

Austin

Article: 121418
Subject: Re: Xilinx DCM Reset
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 14:42:07 -0700
Links: << >>  << T >>  << A >>
PlayDough,

Yes, external source of CLKFB requires that you tell the (first) DCM 
when to LOCK.

You need to provide a reset signal, that informs the DCM when the CLKFB 
signal is present, and valid.

If you do this with a counter, or SRL, you need to be sure your counter 
is long enough, or SRL's are long enough, or clocks are slow enough to 
account for the time required.

The configuration is not smart enough to know when an external signal is 
'good'.

Austin

Article: 121419
Subject: Re: A strange error during PAR process in EDK, could anyone in xilinx help me?
From: morphiend <morphiend@gmail.com>
Date: Tue, 03 Jul 2007 21:51:39 -0000
Links: << >>  << T >>  << A >>
On Jun 29, 1:24 am, "MM" <m...@yahoo.com> wrote:
> "Perry" <lipeng....@gmail.com> wrote in message
>
> news:1182928882.882676.134330@e9g2000prf.googlegroups.com...
>
>
>
> > DeleteInterpProc called with active evals
>
> Apparently this problem is a known issue:http://tinyurl.com/yof2hf
>
> /Mikhail

Mikhail,

I have/had the same problem with multiple designs. Here are the
problems/solutions that I have received from Xilinx about it:

1) Problem: The V4FX60 is a large part, therefore it requires more
memory usage. Under Windows, it can run out of memory and crash.
    Solution: If you have a Linux development environment, you can try
running the linux version of the tools and it should get past the
problem. It did for me, but my design failed timing horribly (>
1,000,000 timing score).

>From my experience:

1) Problem: If the system design has flaws (I was using EDK), i.e. un-
connected necessary signals, missing constraints, etc. it can crash
during PAR.
    Solution: Ensure the design is setup correctly.

BTW, the windows memory problem was supposedly fixed with ISE 9.2, but
I don't have that in-house for testing yet.

HTH,
-- Mike


Article: 121420
Subject: Re: Xilinx DCM Reset
From: PlayDough <pladow@gmail.com>
Date: Tue, 03 Jul 2007 22:04:45 -0000
Links: << >>  << T >>  << A >>
On Jul 3, 2:42 pm, austin <aus...@xilinx.com> wrote:
> If you do this with a counter, or SRL, you need to be sure your counter
> is long enough, or SRL's are long enough, or clocks are slow enough to
> account for the time required.

And how long is that (ignoring any issues external to the FPGA)?  How
long is it from when configuration is complete until GTS is released?
Given my clock frequency I can derive how long to hold the DCMs in
reset after configuration.  I just can't find a spec anywhere on the
Xilinx website that says how long after configuration that GTS is
released.

The problem is that the documentation seems to think that 16 clock
cycles is enough.  But without reference to frequency, I don't know
how long that actually is.  In fact, I found reference to this in
Xilinx Answer Record #14425 (see
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14425),
and this hints at 4 clocks.  But when running at, say, 200 MHz, this
is only 20ns!  What clock frequency are they assuming when the say
that 4 clocks is enough?

> The configuration is not smart enough to know when an external signal is
> 'good'.

Absolutely.  However, Xilinx should be able to specify how long after
configuration the GTS is released.  Take this number, add some pad to
account for the delay before the feedback clock has a chance to
stablize, and keep the DCMs reset until this occurs.


Article: 121421
Subject: Re: high voltage input on SPARTAN-3 FPGAs: MTBF reduction?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 04 Jul 2007 10:36:17 +1200
Links: << >>  << T >>  << A >>
AugustoEinsfeldt wrote:
> Thanks for all responses. Because the time zone I was unable to reply
> earlier.
> The device will do a lot of slow timings (1 second to 10 minutes),
> read 6 serial interface ADC converters (with 2.5MHz SCLK) and talk to
> a CPLD (used as port expander and watchdog) at 10Mbps data rate. It is
> a 3S200 and may have up to 70% of resources used.
> 
> I may stick to the pull-down resistor idea because the system MTBF.
> Resistors cause less impact here.
> System has a XPLA3 CPLD and other circuits at 3V3  (that is supplied
> by a TDK's DC-DC converter) and I think the excess of current will
> sink easily. But I will calculate it again. TDK's never answered about
> sink capability of their DC-DC modules and I'd like to avoid using a
> 3V6 zener to do not waste energy in some temperature conditions.
> The signal's rise/fall time are around 50us (worst case). I know it is
> very slow for this device and I will have some extra current in the
> pin's input circuitry but the cycle time of each signal is in the
> range of several minutes. So the impact of slow signal transition may
> not be important for the system. Only 2 to 5 signals of 56 may change
> at same time and since they came from mechanical feedback it is very
> unlikely they will really change precisely together.

If you are chasing high operational MTBF, I would be wary of feeding
slow edges into a device running a lot of other logic.
I have seen very strange effects, caused by input theshold oscillations
on Digital devices without hysteresis. High series R makes this effect 
worse.
[I think Xilinx fpga's may have small Hyst, you'll need to check ]

> The design did use schmitt-trigger devices for the inputs in the past
> but the MTBF did fall because other added circuits and I thought I
> could work out the bounce and slow edges with some sample/timing logic
> in the FPGA.
> 
> Each of these input signals has a transient suppressor and another
> 100ohm resistor to the input connector. Those are to protect against
> huge ESD strikes and EMC/EMI.
> 
> Exercising a bit longer in this subject, in case I can sink externally
> (to the FPGA) the excess of current (56mA) and since each clamp diode
> for this device can handle 100mA (according DS099), which leads a good
> current injection handling, the single input resistor (no pull-down)
> could work. I am in the limit of system MTBF and it is why I still
> thinking to avoid any other component... The main question remains:
> would the FPGA's MTBF be reduced because this current flowing in the
> clamp diodes?
> 
> System cost is not a big issue but I'd like to avoid high reliability
> resistors because availability and lead times. While writing this text
> I am having second thoughts about avoiding these resistors... but your
> opinion would help in the FPGA's MTBF.

What about 4-Pack resistors ?. That slashes the component count, so 
should improve your MTBF.

Another design approach, would be to hold the IP pins low, most of the 
time, and tristate for narrow window, and read the Pin status at the end 
of that time.
Result is no significant clamp energy, and faster slews - as you now 
effectively sense a CURRENT level, not a voltage level.
[ eg at 1mA and 10pF I get 20ns for 0-2V slew]

-jg


Article: 121422
Subject: Re: Xilinx DCM Reset
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 15:46:15 -0700
Links: << >>  << T >>  << A >>
PlayDough ,

page 234,

http://www.xilinx.com/bvdocs/userguides/ug332.pdf

details the start up sequence.  If you use the default, and you must not 
wait for DCM to LOCK (as they won't), then you need to know the CCLK 
rate, and you will see the delay from GTS.  Table 12-7.  The state 
machine for the start up progresses as shown.  Using bitgen options, you 
may re-arrange the start up sequence, if for some reason you wish one 
even to happen before another (should have a really good reason, 
however, as the default sequence is the easiest to debug and understand 
because it is the default).

Inputs are active before GTS is released (GTS affects outputs).

If the feedback is from an output of the device, back to an input, then 
you also need to know how long it takes from GTS is released, and the 
output is toggling, until the feedback comes back into the input.  Is 
there an external buffer, PLL, or other component in series with the 
feedback path?

Essentially, once GTS is released, one may assume that the output is 
immediately active.

Page 235 details the source of the startup clock (CCLK is the default).

Austin

Article: 121423
Subject: Re: Xilinx DCM Reset
From: austin <austin@xilinx.com>
Date: Tue, 03 Jul 2007 16:01:41 -0700
Links: << >>  << T >>  << A >>
As you may see,

Even delaying a few clocks after GTS is released should be completely 
adequate for the feedback signal to get back into the device, unless an 
external PLL or other component is in series.  Speed of light on pcb 
wires is pretty fast...

Hence the reason why the SRL16 solution is considered "bulletproof" for 
just about every design requiring any delay at all.

Austin

Article: 121424
Subject: Re: How to choose FPGA for a huge computation?
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Tue, 3 Jul 2007 23:22:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
First of all, you're coming at this from a software point of view.  If you 
looked at the situation from a hardware based prospective, the FPGA would 
be far easier to program because the structures used are more familiar.  
Secondly, many designs don't have to worry about the implementation details 
of the mapping of HDL to FPGA, least of all timing closure.  All they do 
is let the tools do their thing and make sure the clock frequency is less 
than the reported Fmax.

Xilinx is smart not to sink all of its resources into a market it coule NEVER 
hold a decent share of.  Video cards will always be much faster than FPGAs. 
 Look at it now, ohhh The fastest DSP blocks can go 500MHz while video cards 
push 1GHz.  It's not going to change.  Tools can only do so much, they aren't 
magic.  Xilinx is much better served at using resources in making there existing 
toolset better as they still need to mature, lest they lose market share 
in areas that they dominate.


---Matthew Hicks


> On Jul 2, 7:47 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> 
>> By the way, the programming model for the cell is by far worse
>> than anything I've seen on an FPGA, and the programming model for
>> video cards
>> in the user domain isn't much better, but it's getting there as
>> Nvidia prioritizes
>> it higher.
> As a programming model, having to design circuits around an array of
> DSP and bRAM slices is BY FAR MUCH MORE OF A HORRIBLE PROGRAMMING
> MODEL ... and a LOT more effort when you also have to fight timing
> closure, placement, layout, etc.
> 
> That array of DSP slices exists exactly to exploit this same
> market ... and lacking competitive system level solutions (packaged
> hardware and software) the volumes for these parts will ultimately be
> lacking, and with it a self fulfilling promise that the tools will
> never mature behind them either.
> Nvidia is simply doing with GPUs, what Xilinx should have done (or
> allowed to be done) to get their chips out front as a easy to use
> gigaflop/teraflop systems level product to drive embedded comodity
> volume sales.
> 
> I personally still believe FPGAs offer greater promise, but only if
> there is a systems level vision behind the product to allow it to
> mature before becoming obsolete.
> 





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