EDK : FSL macros defined by Xilinx are wrong

[Engine]

I think I can find way to avoid the existed bugs, but I do not know whether
there are any other bugs existed in step 2.
So thank you share your exp on SX55 with me.

Thanks,
Engine



"Ray Andraka" wrote:

Engine wrote:

A friend send me a document link.
http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf

He suggest we do not select Virtex4 in our projects.

I am not sure the real meaning of this document.

Does it mean that there are three bugs in the step 1 Virtex4 LX/SX?
Why do not call the Step 2 LX/SX as the mass production LX/SX?
Are there still bugs in step 2 LX/SX?
Whether step 3 LX/SX will be relased later?
Why FX is in step 0 now, what's the defination of step 0?

Please help me!

If it is ture, I would like to use the old VirtexII or Stratix on my
projects.

Thanks,
Engine






Think of the stepping number as service packs for the silicon. The higher
stepping numbers generally reflect silicon revisions to correct
deficiencies in earlier silicon. There aren't really any show-stopper
bugs in the V4 silicon, so I wouldn't discard a V4 solution jsut because
someone suggested you didn't use the parts.

Step 0 is the first silicon, which is/was sold as the engineering samples.

The NBTI problem mentioned in the link you posted turns out to be a
non-problem for real world designs. It does degrade DCM performance if
the DCMs are not operated according to the constraints listed, but the DCM
is so much faster than what is required to support the fabric, that the
degradation does not slow them enough to affect real-world designs. IMHO,
Xilinx did the right thing with regards to disseminating info about the
NBTI problem so that customers could work with all the info known at the
time rather than leaving the customer to potentially discovering a problem
on their own later (unlike the handling of the FIFO16 issue).

The Virtex4 does have significant advantages over the earlier families. As
with most silicon rollouts of this complexity, there are some fairly minor
bugs in the design that will be worked out over time. The only one I am
aware of that is a show stopper is the MGT's in the FX line. If that
doesn't affect your design plans, there is no reason I can see to avoid
the V4 line. I've got a couple major V4SX55 designs working satisfactorly
in the lab now, and overall I am happy with the device.

 

[Peter Alfke]

Bob wrote:

We did a board that had a "double-pulse" problem on a 1MHz JTAG test port
(one TCK buffer output driving multiple JTAG ports). Now, we distribute TCK
like any other clock, and source terminate each buffer output.

Source termination is great if you have one source driving a single

destination. Just put a series-terminating resistor right at the
driver, and let the isgnal bounce up to full amplitude at the openended
destination. But never (never!) use source termination when you are
drving multiple detinations along a clock trace. The half-amplitude
signal travelling along the line will cause you lots of grief.
Peter Alfke

 

[Peter Alfke]

Bob wrote:

We did a board that had a "double-pulse" problem on a 1MHz JTAG test port
(one TCK buffer output driving multiple JTAG ports). Now, we distribute TCK
like any other clock, and source terminate each buffer output.

Source termination is great if you have one source driving a single

destination. Just put a series-terminating resistor right at the
driver, and let the isgnal bounce up to full amplitude at the openended
destination. But never (never!) use source termination when you are
drving multiple detinations along a clock trace. The half-amplitude
signal travelling along the line will cause you lots of grief.
Peter Alfke

 

[Symon]

Hi Bob,
The answer is to do as Austin says and simulate the thing. No 'ahshits' or
bodged on caps needed. The Mentor marketing hype is pretty close when it
says that the tool pays for itself in just 1 or 2 PCB respins because the SI
is bad first time.
It also makes sure that your design isn't marginal. Two 'ahshits' may have
got your design working, but will it survive the next rev. of the silicon
because it only just worked?
BTW, another misconception is that buffering always fixes the problem. Most
buffers are very good at driving lines with faster rise times than the
original driver. This makes the problem even worse.
Best, Syms.
p.s. I chuckled at Brad's "I would suggest doing whatever they (Xilinx)
say."! I'd suggest maybe using their designs as a start, then think about
your own application. Remember, Xilinx has to suggest things that will work
for a multitude of designs. This may not be the most efficient for your
design. In fact I'd question whether a 'one size fits all' is even possible
at all for some situations.


"Bob" <nimby1_notspamm_@earthlink.net> wrote in message
news:7Bpsf.3534$R84.1704@newsread2.news.pas.earthlink.net...

Yep, that's a common misconception that it's the frequency that causes
reflections.

We did a board that had a "double-pulse" problem on a 1MHz JTAG test port
(one TCK buffer output driving multiple JTAG ports). Now, we distribute
TCK like any other clock, and source terminate each buffer output.

It all seems so easy, now, but it's taken a couple of 'ahshits' to get
there.

 

[Antti Lukats]

<wtxwtx@gmail.com> schrieb im Newsbeitrag
news:1135784033.195372.48850@z14g2000cwz.googlegroups.com...

Hi Antti,
What does 'EDK' stand for?

Weng

Embedded Development Kit - a bundle of program for Xilinx SoC design


Antti

 

[Neil Glenn Jacobson]

Nitesh,

There is nothing wrong with your bitstream or bitstream settings. The
download is not even getting that far, anyway. I suggest that you
follow the recommendations in the error message to begin:

1. Check that the cable, scan chain, and power connections are intact
Is you cable powered?
Is your board?
Are TCK, TMS, TDI and TDO of the cable correctly connected to the board?
2. That the power supply is adequate and delivering the correct voltage.
Is you power supply set correctly and delivering the required current?

You should also run iMPACT in interactive GUI mode and build the chain
manually. Try to read the IDCODE from any device. That should give
additional diagnostic information.

Nitesh wrote:

Hello,
I seem to have a problem while downloading the design on ML300 trough
the JTAG cable. I searched it over the net but found no solution. I
can download the design using the compact flash but with JTAG it gives
a problem.

impact -batch etc/download.cmd
PM_SPEC -- Xilinx path component is <C:/EDK
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setCable -port auto
AutoDetecting cable. Please wait.
Connecting to cable (USB Port).
Cable connection failed.
Connecting to cable (Parallel Port - LPT1).
Checking cable driver.
Driver windrvr6.sys version = 6.2.2.2. LPT base address = 0378h.
ECP base address = FFFFFFFFh.
Cable connection established.
// *** BATCH CMD : identify
Identifying chain contents ....done.
ERROR:iMPACT:585 - A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual
hardware, and
that the power supply is adequate and delivering the correct
voltage.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM
Elapsed time = 0 sec.
ERROR:iMPACT:589 - No devices on chain, can't assign file
make: *** [download] Error 1
Done.


The following is y bitgen.ut file
-g ConfigRate:4
-g CclkPinULLUP
-g TdoPinULLNONE
-g M1PinULLDOWN
-g DonePinULLUP
-g DriveDone:No
-g StartUpClk:JtagCLK
-g DONE_cycle:4
-g GTS_cycle:5
-g M0PinULLUP
-g M2PinULLUP
-g ProgPinULLUP
-g TckPinULLUP
-g TdiPinULLUP
-g TmsPinULLUP
-g DonePipe:No
-g GWE_cycle:6
-g LCK_cycle:NoWait
-g Security:NONE
-m
-g Persist:No

 

[Brad Smallridge]

Judging by the voltage swings I would say that the termination resistors are
not there.
That would explain why the steady DVAL does not show up. I have a case put
in at
Xilinx to find out how to turn them on.

"Rob" <robnstef@frontiernet.net> wrote in message
news8osf.2155$OU3.2038@news01.roc.ny...

I've never needed to pull-up LVDS signals that were being driven. I've
driven as far as 10feet, too. Remember, the voltage genereated is a
result of the current passing through the termination resistor.

 

[Sean Durkin]

Brad Smallridge wrote:

Judging by the voltage swings I would say that the termination resistors are
not there.
That would explain why the steady DVAL does not show up. I have a case put
in at
Xilinx to find out how to turn them on.
You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code

(instead of just IBUFDS) or attach the IOSTANDARD-attribute to your
IBUFs, with the value LVDS25_DT. The _DT switches on the differential
termination.

See here:

http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/lib/lib0210_196.html

cu,
Sean

 

[Sean Durkin]

Sean Durkin wrote:

You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code
(instead of just IBUFDS) or attach the IOSTANDARD-attribute to your
IBUFs, with the value LVDS25_DT. The _DT switches on the differential
termination.
Sorry, my mistake: it either must be a IBUFDS_LVDS_25_DT in the HDL or

the attribute value LVDS_25_DT. The link I posted earlier doesn't
mention V4, but it should be the same for that.

And I just read that there's a new attribute "DIFF_TERM" for V4, that
should work as well. You'd have to check the Xilinx Constraint Guide in
the ISE Documentation for that. I suppose you need to set it to "TRUE"
or something.

cu,
Sean

 

[shogmic]

Peter Alfke wrote:

Source termination is great if you have one source driving a single
destination. Just put a series-terminating resistor right at the
driver, and let the isgnal bounce up to full amplitude at the openended
destination. But never (never!) use source termination when you are
drving multiple detinations along a clock trace. The half-amplitude
signal travelling along the line will cause you lots of grief.
Peter Alfke

Hey guys,

Thanks a lot for your posts... Frequency does not matter - I did not
know that. Thanks for the lesson.

Still no easy answer to the Master or Slave configuration flexibility,
but maybe I will just have to choose one or the other right now in
order to terminate CCLK properly. I may also throw on the parallel
termination on both ends and only populate one set, depending on which
configuration mode I choose.

It is only 1 Virtex-4 SX FPGA being configured, but I will have a PROM
and another FPGA (Spartan-III) attached to the CCLK line. Most likely,
the Spartan or the PROM will drive the CCLK, but I definitely do want
the ability for either one to drive it. Sounds like parallel
termination, then, near the Virtex-4 would be my best bet.. I assume
that source termination at both the PROM and the Spartan is out of the
question since one will act like an additional destination when the
other is driving CCLK?

Thanks,
mike.

 

[Brad Smallridge]

Are you running 8.1?

I still have 7.1 and PACE tells me I have thes LVDS options:
LVDS_25
LVDS_25_DCI
LVDSEXT_25
LVDSEXT_25_DCI

Brad


"Sean Durkin" <smd@despammed.com> wrote in message
news:41gfgfF1dt07oU1@individual.net...

Sean Durkin wrote:
You either need to instantiate IBUFDS_LVDS25_DT in your HDL-Code
(instead of just IBUFDS) or attach the IOSTANDARD-attribute to your
IBUFs, with the value LVDS25_DT. The _DT switches on the differential
termination.
Sorry, my mistake: it either must be a IBUFDS_LVDS_25_DT in the HDL or
the attribute value LVDS_25_DT. The link I posted earlier doesn't
mention V4, but it should be the same for that.

And I just read that there's a new attribute "DIFF_TERM" for V4, that
should work as well. You'd have to check the Xilinx Constraint Guide in
the ISE Documentation for that. I suppose you need to set it to "TRUE"
or something.

cu,
Sean

 

[Brad Smallridge]

Well after all that what I needed
to do was to add some of these to the UCF file:

INST my_xn_ibufd_instantiation DIFF_TERM = TRUE;

That will turn on the differential resistor inside the chip.

What was confusing was how much signal got through
without the termination.

That UCF constraint has to be added to IBUFDs only.
I tried to add it to a wizard generated dcm with external
differential inputs and got an error. I wonder if Xilinx
knows about this. But you can run the xclk into an
IBUFD, and run that output into an internal single-ended
dcm clock input, no problem. Probably cleaner that way
because it's broken down into primitives.

Thanks to Rob, Sean, and Avishay for helping me piece
the problem together.

Brad Smallridge
aivision.com



"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11r0jedsghr3me0@corp.supernews.com...

Hello,

Having trouble with some LVDS signals coming from a Camera Link interface.
I expect to see from steady signals coming from this line camera. DVAL=1.
But it's not there. And the LVAL, line valid, only comes on for maybe one
clock, and I expect it to come on for 2K clocks.

I am using IBUFDS as inputs. The UCF file loc the pins but that is all.
Do I need something more to drop the 100 ohm termination resitance?

Brad Smallridge
aivision.com

 

[Peter Alfke]

Bevan Weiss wrote:

Well it is the frequency that's important, it's just not the fundamental
frequency so much as the harmonics.
With decreasing rise and fall times the amplitudes of the harmonics
become more pronounced, and there are more of them which contribute to
the overall waveshape. This means that any distortion of these
harmonics will result in a much degraded waveshape.
This is why termination effects are more important as the fundamental
frequency increases, because the harmonics are situated at higher
frequencies also and more likely to be interfered with by the impedance
mismatches.

Bevan, your description is not totally wrong, but it is misleading.
Obviously, any given repetitive event can be correctly described either
in the time domain or in the frequency domain. You prefer the frequency
domain, bur I say that the time domain is more meaningful in this case.
The user has control over the repetition rate (the fundamental
frequency) but not over the rise and fall times. And these two
phenomena are really not ineterrelated. If you change the fundamental
frequency, the rise and fall times do not change, and neither does the
damage caused by these rise and fall times. It is thus misleading to
describe them as harmonics (although technically they are). If you
change the fundamental frequency by an order of magnitude, the problems
caused by the sharp transition times do not change at all. That's why
we say: The problem is the transition time, not the fundamental
frequency.
Peter Alfke

 

[Austin Lesea]

Symon,

I also prefer to look at it as rise and fall times causing problems.

Obviously, anything that happens in the time domain is also happening in
the frequency domain, and the opposite as well. We are just observers
trying to understand what happened. The clock pulse itself exists in
both domains simultaneously.

It is like the physics student who asked the professor "is light a
particle or a wave?" The answer, of course, is 'yes.' Sometimes
modeling it as a particle gives you insight into what happened, and
sometimes modeling it as a wave tells you something useful.

So it is with reflections. If the rising edge gets a kink in it due to
a reflection, it is easier to explain it as fast rising edges hitting a
discontinuity and reflecting in the time domain. Is it 'wrong' to say
that the clock frequency is the cause of the problem (even though we
both know that frequency and time are two ways of describing the physics
of the system)? I think so, the frequency model is the wrong approach
to understand what is happening (to a pulse on a wire).

If I am trying to explain a clock pulse on a wire, I think the time
domain is the best choice.

Austin


Symon wrote:

"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1135825838.800221.321020@g47g2000cwa.googlegroups.com...

If you change the fundamental
frequency, the rise and fall times do not change, and neither does the
damage caused by these rise and fall times.


Hi Peter,
Here's a time-domain counter-example to your premise.
A fast rising edge arrives at a badly terminated node. The signals reflect
back and forth causing (say) a ringing effect. Luckily, the amplitude of
this ringing is not enough to change the state of the receiver input, so all
works well. After a while the ringing dies down. After the ringing has died
down the falling edge arrives and there's no problem.
OK, now the same thing but with a faster fundamental:-
A fast rising edge arrives at a badly terminated node. The signals reflect
back and forth causing (say) a ringing effect. Luckily, the amplitude of
this ringing is not enough to change the state of the receiver, so all works
well, until the falling edge arrives while the line is still ringing. The
combination of the falling edge and the ringing causes the receiver to see a
rising edge. Not good.
In this case, the fundamental frequency DOES affect the circuit.

On a separate point, it's as well to remember that digital ICs inputs aren't
a simple hi-impedance open circuit. They have some amount of capacitance.
(See Symon vs. Austin vs. Brian in CAF passim!) This means that low
frequencies see the input as an open, but very high frequencies see them as
a short. For a Xilinx FPGA, the 50 ohm impedance point is at about 300MHz.
Ish. I do know at least one bloke whose brain apparently has a hard-wired
Smith chart in it. Mine doesn't have this feature so I simulate, or, if
we're down the pub, ask my mate!
Cheers, Syms.

 

Hi,
1. I2C IP is so simple that it will never fail, in my opinion.

2. You are a newbie in this respect, the chance you make a mistake is
beyond 99%.

3. If I2C controller contained in the IP doesn't send the acknowledge
bit, your design is fundamentally wrong.

Can you imagine an IP fails to response with an acknowledge bit?

You may post your code and I will help you ID the first error, not all
errors.

Weng

 

[Tim Wescott]

bjzhangwn wrote:

If I want to know how the cpu work more detail,or if I want to know the
internal archetecture in the risc cpu,what material should i read?Can
some give me some advice!

If you're talking about a specific chip then read that chip's data

sheet, user's guide, etc. If you want to better understand computer
architecture go to Amazon.com or Powell's technical books
(http://www.powells.com) and search on "Computer Architecture".

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Hans]

Look for a company that builds ExpressCards and see if they are willing to
sponsor your project. This is also a good opportunity to show your
capabilities and perhaps end up with a job (worked for me when I was a
student

Hans.
www.ht-lab.com

"bjzhangwn" <bjzhangwn@126.com> wrote in message
news:1135954545.288345.115490@g43g2000cwa.googlegroups.com...

I know,but I am astudent,and how can i get it freely?

 

[jerzy.gbur@gmail.com]

Hello

feedback loop. CLK0 -> BUFG -> CLKFB.
Is that necessary?

Yes, it is.
To CLKFB you can connect signals from BUFG or IBUFG.

Do I have to use an IBUFG for the CLKIN of a DCM if nothing else is
connected to that CLK signal?

Yes, you have.

Why? - it's good question for homework.

If you looking for advice here, be more specific:
- What tool you use?
- What chip-device, you want to configure?

good luck.

Jerzy Gbur

 

[John Adair]

One problem you have is that in Virtex-4 only half of the slices can support
lut used as memory. In V2 all slices could be used. We have seen similar
things in Spartan-3 particularly if you have used elements such as 32x1 ram.
Alternative you may have tried to use a memory type lut where there isn't
one due to using a RPM or constraint that simply isn't valid.

John Adair
Enterpoint Ltd. - Home of MINI-CAN. The Spartan-3 CAN Bus Development Board.
http://www.enterpoint.co.uk


"Lars" <larthe@gmail.com> wrote in message
news:1136376416.676830.143490@g49g2000cwa.googlegroups.com...

Anyone done any "what-if" remapping of Virtex-II designs to Virtex-4? I
wanted to do this to see how the new technology performed, mainly to
see if it was worth the trouble to upgrade some existing designs. We
did this quite successfully some years back, stepping from Virtex-E to
Virtex-II. The main obstacle then was the new size Block RAM going from
4kbit to 18 kbit apiece. If we left our Unisim and CoreLib components
untouched we wasted 3/4 of the RAM, but if the number of Block RAMs in
the chip was sufficient, all we had to do was to update the
LOC-constraints for pins and DCM's in the .ucf-file. ISE even managed
to re-target the Virtex-E DLLs to Virtex-II DCMs. Brilliant!

So I hoped it would be even better this time, since the Block RAMs are
the same size, but there seems to be more to this than meets the eye. I
commented out all the LOC-constraints in the ucf and had a go, after
resynthesizing to XC4VLX instead of XC2V. But alas, I get a fatal error
in MAP, complaining about SLICEL and SLICEM types of components. I
suspect that this has to do with some of our CoreLib components, since
they are the only place where there might be RLOC constraints in the
EDIF, but before I go and re-generate all these I am curious to know if
there is an easier way.

I am not out to squeeze the full performance out of the XC4VLX right
now, but would like a "ball-park" figure of what might be expected in
terms of utilization and speed, before we go ahead and commit to a
full-scale conversion. That is why I don't want to spend too much time.

Regards,
/Lars

 

[Lars]

Aha! I knew that, but the access to that particular memory cell in my
decaying brain was not operating at the time. That would make it hard
to re-target CoreLib components I suppose...

Thank's for setting me straight!
/Lars