EDK : FSL macros defined by Xilinx are wrong

[BobW]

"austin" <austin@xilinx.com> wrote in message
news:fvvgqu$oe22@cnn.xsj.xilinx.com...

jon,

Unauthorized distributors are likely to have slower parts re-marked as
faster parts so they can gouge you for more money....

-6 is the slowest, so maybe you won't have that problem.

Or, devices that look like our parts, but are empty inside, or just
remarked garbage (non-functional).

This is the most common results we have seen when we have looked into
these "sources."

I am also concerned that we made a gift of Virtex E to Universities a
long time ago.

These devices were "not suitable for commercial use" ...

Caveat Emptor!

Austin

Ahhh. So you've been to Latin America, Austin?

Bob
--
== NOTE: I automatically delete all Google Group posts due to uncontrolled
SPAM ==

 

[BobW]

"austin" <austin@xilinx.com> wrote in message
news:fvvgqu$oe22@cnn.xsj.xilinx.com...

jon,

Unauthorized distributors are likely to have slower parts re-marked as
faster parts so they can gouge you for more money....

-6 is the slowest, so maybe you won't have that problem.

Or, devices that look like our parts, but are empty inside, or just
remarked garbage (non-functional).

This is the most common results we have seen when we have looked into
these "sources."

I am also concerned that we made a gift of Virtex E to Universities a
long time ago.

These devices were "not suitable for commercial use" ...

Caveat Emptor!

Austin

Ahhh. So you've been to Latin America, Austin?

Bob
--
== NOTE: I automatically delete all Google Group posts due to uncontrolled
SPAM ==

 

Clemens <Clemens@hotmail.com> wrote:

Hi

I have intended an upgrade to Xilinx 9.2 or higher from version 7.1.
With this newer versions my programming cable is no longer supported.

What kind of programming cable do you have .. ?

 

Clemens <Clemens@hotmail.com> wrote:

Hi

I have intended an upgrade to Xilinx 9.2 or higher from version 7.1.
With this newer versions my programming cable is no longer supported.

What kind of programming cable do you have .. ?

 

[David Spencer]

"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message
news:0d885ecd-0839-416b-98fd-1ff4f1835806@34g2000hsh.googlegroups.com...

On 9 Mai, 14:23, Brian Drummond <brian_drumm...@btconnect.com> wrote:
My preference would be for
series termination, i.e. place the resistive divider at the oscillator
end, assuming the clk trace is a simple trace

Do both:
One resistor in series at the source, one resistor to ground at the
destination.
You get a transmission line that is terminated at both ends. A
reflection caused
by a mismatch at the destination is dampened at the source.

This provides essentially the best signal quality you can get. The
only disadvantage
is the reduced swing at the destination. But this is exactly what the
OP wants.

Kolja Sulimma

A better solution would be to feed the clock through a 3.3V buffer that is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.

 

[David Spencer]

"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message
news:0d885ecd-0839-416b-98fd-1ff4f1835806@34g2000hsh.googlegroups.com...

On 9 Mai, 14:23, Brian Drummond <brian_drumm...@btconnect.com> wrote:
My preference would be for
series termination, i.e. place the resistive divider at the oscillator
end, assuming the clk trace is a simple trace

Do both:
One resistor in series at the source, one resistor to ground at the
destination.
You get a transmission line that is terminated at both ends. A
reflection caused
by a mismatch at the destination is dampened at the source.

This provides essentially the best signal quality you can get. The
only disadvantage
is the reduced swing at the destination. But this is exactly what the
OP wants.

Kolja Sulimma

A better solution would be to feed the clock through a 3.3V buffer that is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.

 

[David Spencer]

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...

On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:


A better solution would be to feed the clock through a 3.3V buffer that
is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.- Hide quoted text -


By what measure would an IC be a "better solution" than two resistors?

KJ

Static drive current.

Assuming the divider is matched to the impedance of the trace, as originally
suggested, the oscillator would need to source and sink around 100 mA.

 

[David Spencer]

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...

On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:


A better solution would be to feed the clock through a 3.3V buffer that
is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.- Hide quoted text -


By what measure would an IC be a "better solution" than two resistors?

KJ

Static drive current.

Assuming the divider is matched to the impedance of the trace, as originally
suggested, the oscillator would need to source and sink around 100 mA.

 

[KJ]

"David Spencer" <davidmspencer@verizon.net> wrote in message
news:WO2Vj.1895$Uz2.1141@trnddc06...

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:cf46e434-c521-4155-ab4a-efcd7587c41f@27g2000hsf.googlegroups.com...
On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:


A better solution would be to feed the clock through a 3.3V buffer that
is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.- Hide quoted text -


By what measure would an IC be a "better solution" than two resistors?

KJ

Static drive current.

Assuming the divider is matched to the impedance of the trace, as
originally suggested, the oscillator would need to source and sink around
100 mA.

Oscillator outputs typically can't drive PCB trace impedance types of values
(i.e. 50-100 ohm) anyway so you wouldn't terminate it with that low of a
resistor value. Instead you would use something quite a bit higher so that
you would get the edge quality that you need and the divider to limit the
input voltage to the part.

The 5<-> 3.3V ICs are nice when you have a bunch of signals that need
translating (like a bus) but if it's just a single net (or a small handful)
the resistors work nicely....of course it begs the question of why not use a
3.3V oscillator in the first place.

KJ

 

[KJ]

"maverick" <sheikh.m.farhan@gmail.com> wrote in message
news:867bdf28-6f10-4dd4-a00b-dc5f9cae4de7@m44g2000hsc.googlegroups.com...

Hi,
I am using a Spartan3 xc3s1000-4 fg456 FPGA. I have an oscillator
which gives clk output at 5V p-p swing. I am using the FPGA in LVTTL
mode which works on 3.3 V signaling. Is it OK to feed the 5V clock to
one of the GCLK pins of the Spartan 3 FPGA? Should I put a current
limiting resistor in the clock path before I feed it to the GCLK pin?
Any issues with that?

Any reason why you wouldn't just use an oscillator that has a 3.3V swing to
begin with?

KJ

 

[KJ]

"Jon Elson" <elson@wustl.edu> wrote in message
news:4824C322.9000505@wustl.edu...

KJ wrote:
On May 9, 11:53 am, "David Spencer" <davidmspen...@verizon.net> wrote:


A better solution would be to feed the clock through a 3.3V buffer that
is
5V tolerant. An AHC family device would do the job I think. In fact, a
74AHC1G04 would be perfect - it's a single inverter in a tiny five-pin
package.- Hide quoted text -



By what measure would an IC be a "better solution" than two resistors?

You don't want slow clock transitions, and high drive impedances at
the receiving end. Now, the right choice of resistors probably won't
cause such trouble, but it at least needs to be considered.

I was answering within the context of what info the original poster provided
which was that he has a 5V signal going into a 3.3V tolerant input. No
mention of any other similar signals that might also be problems, or that
the clock is a long distance away or anything, just looking for a way to use
(for some unknown reason) a 5V osc into a 3.3V tolerant part.

A long clock trace (bad idea, anyway) fed with a series resistor is
essentially a lumped-constant low-pass filter. I'm not sure how fast
Spartan III is, but if the Tr got slowed to tens of nS it would be really
dangerous.

The same can happen with any driver. An electrically long net will need to
be terminated

KJ

 

[Fred]

Hi Greg, Kevin,

Many thanks for your reply. In essence I want to take a completed design,
with critical timing constraints, and import it as an IP_Core into EDK where
the added logic has very lax timing constraints.

I would like to take the component placement for the fitted critical part
and lock these down. I want to use this new UCF file with all the placement
information in EDK with a hope that timing may be achieved which it doesn't
at present.

I will certainly look at Floorplanner to see how this can help.

Many thanks again.

Fred


"SoyAnarchisto" <greg.daughtry@gmail.com> wrote in message
news:35098c3c-3117-4083-899e-5c4226f15239@a23g2000hsc.googlegroups.com...

Fred,

ngd does not have placement information, I think you are referring to
ncd. Beginning w/ ISE 10.1 PlanAhead is shipped with all versions of
ISE, including the webpack (free) version. Prior to that PlanAhead
was a separate optional tool, but evaluation licenses are readily
available for the asking:

http://www.xilinx.com/ise/optional_prod/planahead.htm

PlanAhead is a fairly straightforward tool to use. At a high level,
to do what you are asking:

1) download and install planAhead
2) create a project by importing an edif/ngc netlist and optionally
ucf constraints (and pick a target device if ngc).
3) File->Import Placement and browse to your placed and/or routed ncd
file

This will import placement from an ncd file and convert them to LOC
and BEL constraints.

At this point you have tons of options, depending on what you are
trying to accomplish. You can go to File->Export Floorplan to write
out all these loc/bels into a ucf file, but a huge file of locs is of
limited use, for floorplanning, timing closure, ip reuse flows.

Take a look at the PlanAhead tutorial and methodology guides, as a
starting point. More questions will doubtlessly follow...

'Greg

On May 9, 11:14 am, Kevin Neilson
kevin_neil...@removethiscomcast.net> wrote:
Fred wrote:
Is there any NGD reader which can extract placement information?

I know I can use FPGA editor and go through all the primitives, one by
one, but this would be a mamoth task! Any ideas?

Are you trying to floorplan or trying to figure out how PAR performed
placement? If the former, PlanAhead is a very nice tool for
floorplanning. -Kevin

 

[Fred]

Hi Greg, Kevin,

Many thanks for your reply. In essence I want to take a completed design,
with critical timing constraints, and import it as an IP_Core into EDK where
the added logic has very lax timing constraints.

I would like to take the component placement for the fitted critical part
and lock these down. I want to use this new UCF file with all the placement
information in EDK with a hope that timing may be achieved which it doesn't
at present.

I will certainly look at Floorplanner to see how this can help.

Many thanks again.

Fred


"SoyAnarchisto" <greg.daughtry@gmail.com> wrote in message
news:35098c3c-3117-4083-899e-5c4226f15239@a23g2000hsc.googlegroups.com...

Fred,

ngd does not have placement information, I think you are referring to
ncd. Beginning w/ ISE 10.1 PlanAhead is shipped with all versions of
ISE, including the webpack (free) version. Prior to that PlanAhead
was a separate optional tool, but evaluation licenses are readily
available for the asking:

http://www.xilinx.com/ise/optional_prod/planahead.htm

PlanAhead is a fairly straightforward tool to use. At a high level,
to do what you are asking:

1) download and install planAhead
2) create a project by importing an edif/ngc netlist and optionally
ucf constraints (and pick a target device if ngc).
3) File->Import Placement and browse to your placed and/or routed ncd
file

This will import placement from an ncd file and convert them to LOC
and BEL constraints.

At this point you have tons of options, depending on what you are
trying to accomplish. You can go to File->Export Floorplan to write
out all these loc/bels into a ucf file, but a huge file of locs is of
limited use, for floorplanning, timing closure, ip reuse flows.

Take a look at the PlanAhead tutorial and methodology guides, as a
starting point. More questions will doubtlessly follow...

'Greg

On May 9, 11:14 am, Kevin Neilson
kevin_neil...@removethiscomcast.net> wrote:
Fred wrote:
Is there any NGD reader which can extract placement information?

I know I can use FPGA editor and go through all the primitives, one by
one, but this would be a mamoth task! Any ideas?

Are you trying to floorplan or trying to figure out how PAR performed
placement? If the former, PlanAhead is a very nice tool for
floorplanning. -Kevin

 

[KJ]

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
news:48255f20@clear.net.nz...

Peter Alfke wrote:

So let's reduce the series resistor at the source to 25 Ohm, and keep
the parallel termination at the destination at 50 Ohm.
That puts 2/3 of Vcc on the cable and the FPGA input = 3.3 V. The 25
Ohm includes the drive impedance, which might mean no external series
resistor at all...
Peter

Yes, that would work, However....

# You are no longer doing strict series-impedance-match termination
# One can tell you are used to high-power FPGAs

Oscillators typically can't drive 50 ohms impedances either so impedance
matching to the PCB would not be relevant....the optimal solution would be a
series resistor of ~1.75x - 2x, parallel to ground of 3x where 'x' needs to
be determined based on the spec'ed drive capability of the oscillator. An
IBIS or Spice model would determine 'x'. Assuming the osc to be 50MHz or
less, a PCB impedance of ~50 ohms, I'd suspect that x ~ 50-75 would give
good signal quality and meet Vih requirements at the FPGA.

- as this sugestion adds a cost of 33mA in power budget (@50% clk duty
cycle).

Suppose the target was a Zero power CPLD ?
The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz.
[OP did not mention speed, but 5V sources are << 100Mhz ]

The clock-terminator is consuming far more power than the CPLD !

If power consumption was even remotely close to the case that the OP was has
in mind he wouldn't bother with any of this...he would've replaced the 5V
osc with a 3.3V one. Presumably there is some reason for even wanting to
have a 5V osc on the board in the first place, but minimizing power
consumption is not the reason.

Kevin Jennings

 

[KJ]

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
news:48255f20@clear.net.nz...

Peter Alfke wrote:

So let's reduce the series resistor at the source to 25 Ohm, and keep
the parallel termination at the destination at 50 Ohm.
That puts 2/3 of Vcc on the cable and the FPGA input = 3.3 V. The 25
Ohm includes the drive impedance, which might mean no external series
resistor at all...
Peter

Yes, that would work, However....

# You are no longer doing strict series-impedance-match termination
# One can tell you are used to high-power FPGAs

Oscillators typically can't drive 50 ohms impedances either so impedance
matching to the PCB would not be relevant....the optimal solution would be a
series resistor of ~1.75x - 2x, parallel to ground of 3x where 'x' needs to
be determined based on the spec'ed drive capability of the oscillator. An
IBIS or Spice model would determine 'x'. Assuming the osc to be 50MHz or
less, a PCB impedance of ~50 ohms, I'd suspect that x ~ 50-75 would give
good signal quality and meet Vih requirements at the FPGA.

- as this sugestion adds a cost of 33mA in power budget (@50% clk duty
cycle).

Suppose the target was a Zero power CPLD ?
The whole device Icc might be 14.6mA at 200Mhz - 7.5mA @ 100MHz.
[OP did not mention speed, but 5V sources are << 100Mhz ]

The clock-terminator is consuming far more power than the CPLD !

If power consumption was even remotely close to the case that the OP was has
in mind he wouldn't bother with any of this...he would've replaced the 5V
osc with a 3.3V one. Presumably there is some reason for even wanting to
have a 5V osc on the board in the first place, but minimizing power
consumption is not the reason.

Kevin Jennings

 

[KJ]

Correction to previous post. I'd suspect 'x' to be ~25-40, not 50-75.

KJ

 

[KJ]

Correction to previous post. I'd suspect 'x' to be ~25-40, not 50-75.

KJ

 

[Marty Ryba]

"Pratap" <pratap.iisc@gmail.com> wrote in message
news:3e857ede-ca9d-458d-a548-047d2d7cb743@w34g2000prm.googlegroups.com...

These are the methods I tried....
option 1: I used a clock for Chipscope pro which has a period of 10
seconds....But in this case it tkes a huge time to get the
data...around 600 sec for getting 16 samples...even though the values
make sence
Option 2: I am using the system clock iteslf for chipscope clock, and
once in 1 seconds I generate a high pulse of width of 1 period of sys.
clock and trigger data with that...but it takes all the data points
after the trigger condition and hence I effectively get 1 data
point.It's fast but doesn't help much

The ILA works like a logic analyzer; there is a "trigger" and then on each
clock the data is sampled until the buffer is full. My guess is that in
constructing the ILA core, 16 samples is the minimum buffer length (I've
generally used many more). I think you would need to use some form of
register I/O off the board to instead sample the data yourself to do any
better.

Good Luck,
Marty

 

[David Spencer]

"kislo" <kislo02@student.sdu.dk> wrote in message
news:bbc75873-123f-4c0e-815b-ddcadae59385@b1g2000hsg.googlegroups.com...

In the IBIS model i can find the package parasitics R_pkg, L_pkg and
C_pkg ... but what does these values represent? is it the total
parasitics of the entire pins of the package? is it for single pins of
the package?

http://vhdl.org/pub/ibis/ver4.2/ver4_2.pdf

 

[David Spencer]

"kislo" <kislo02@student.sdu.dk> wrote in message
news:bbc75873-123f-4c0e-815b-ddcadae59385@b1g2000hsg.googlegroups.com...

In the IBIS model i can find the package parasitics R_pkg, L_pkg and
C_pkg ... but what does these values represent? is it the total
parasitics of the entire pins of the package? is it for single pins of
the package?

http://vhdl.org/pub/ibis/ver4.2/ver4_2.pdf