EDK : FSL macros defined by Xilinx are wrong

[Sudhir Shetty]

Hi ,
Thanks for the reply.
But when i use .vm file to do a simulation , i will need those
parameters in the .vm file .right ?

Thanks,
Sudhir

mk wrote:

On 22 Jan 2006 08:03:53 -0800, "Sudhir Shetty"
sudhirshettyk@gmail.com> wrote:

Hi ,
I create a instance of DCM as follows :

DCM i_DCM (...
...
...
) /* synthesis xc_props ="DLL_FREQUENCY_MODE =
LOW,DUTY_CYCLE_CORRECTION = TRUE, <more parameters > */; //note this
directive is on a single line without line-breaks


But I see that in the post-synthesis .vm file there is no defparams
added for these attributes.

That's normal as there is no tool which would need those parameters at
that point. What's important is whether those parameters get written
to the EDF file which goes into the PAR correctly and whether the
Xilinx toolset uses the properly.

 

[hutzelbutz]

For me, the problem with the extremely slow GUI is still there.
Funny enough, the version 7 of ISE was running fine on RedHat Linux
2.4.21. Now that we upgraded to 8.1, it takes ISE 3 Minutes (!) to
start beyond the splash screen. All interaction is extremely slow but
the commandline tools are very fast.

Is there anything I am missing? Do I need a newer version of Java / Qt
/ whatever?

I would be thankful for any suggestions.
Cheers, Joachim

 

[Frank Schreiber]

Hi Peter
It's nice that you mentioned. But truely that I don't know much, so I
provided a little bit informations.
But I think other informations are not so important: LVDS are standard, and
it does the same way in different boards. The most important thing that I
don't know is how it works. Antti said that it needs a clock....
Many thanks
Frank.
"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1137958167.597749.115710@g49g2000cwa.googlegroups.com...

Frank, be serious:
You do not tell us which FPGA family and which board. You don't report
that you have tried a different output standard. You mention little
about your design and environment.
How can you possibly expect any meaningful help?
It's like calling a doctor: "What should I do, it hurts!"
Peter Alfke

 

[Antti Lukats]

"Frank Schreiber" <frankschr@googlemail.com> schrieb im Newsbeitrag
news:dr25fb$ii6$1@anderson.hrz.tu-chemnitz.de...

Hi Peter
It's nice that you mentioned. But truely that I don't know much, so I
provided a little bit informations.
But I think other informations are not so important: LVDS are standard,
and
it does the same way in different boards. The most important thing that I
don't know is how it works. Antti said that it needs a clock....
Many thanks

think of LVDS that you use 2 wires an not 1 for 1 signal

for LVDS its irrelevant if the signal is clock or data or whatever

what I said is that if you have DAC chip that uses LVDS standard then this
DAC chip does need a LVDS clock to latch the data, but its only my guess,
you really did not provide enough info.


--
Antti Lukats
http://www.xilant.com

 

[Symon]

Frank,
From your IP address I guess you're a Physics student at university. I'd
suggest you go down the corridor to the EE department and ask someone there
who will be able to help you face to face. Even if they can't answer your
question, they could probably tell you what to post here to get an answer.
HTH and good luck, Syms.
"Frank Schreiber" <frankschr@googlemail.com> wrote in message
news:dr0fec$kvu$1@anderson.hrz.tu-chemnitz.de...

Dear all
I'm starting with LVDS.
My task is sending 8-bits signal to LVDS Transmitter port on my board.
I declared a 8 bits vector, assigned pins, and changed values in 8-bits
signal, but nothing happended in my oscilloscope. Assume that pins-out are
right assigned, all wires and DAC are working perfectly.
Can anyone advise me, how to make it works.
Many thanks
Frank

 

[Robin Bruce]

Brian Davis wrote:

Symon wrote:

As penance, I'll still get the dessert AND write a little article about it
for the FAQ. (The fpga-org.com FAQ that is!)

Probably a bit OT for comp.arch.fpga; might I suggest instead the
FAQ at schwarzwaldkirschtortemitschlagsahne.org

Brian

For the hard of German, I make that "Black Forest Cherry Cake with
Whipped Cream".
Incredibly, the domain has not yet been snapped up...

Robin

 

[Antti Lukats]

"John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag
newsine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU...

Is your library for the CRC generation available to others.

JOhn

http://help.xilant.com/Xilinx:Configuration:CRC

the code snippet that does calc the CRC is at the above link,
bitpatch utility with the ability to inject fixed CRC is scheduled for
release as well

--
Antti Lukats
http://www.xilant.com

 

Robin Bruce wrote:

I am compelled to agree with Peter here.

unless any forum is moderated, this abuse will happen, creating
more threads to complain about it is just more polution ... unless
the group wishes to moderate, and has people willing to do it,
complaining is senseless.

The post is undoubtedly irrelevant, arguably stupid - certainly
ignorant. There are xenophobic generalisations, and by about the 80th
post I was convinced it was racist. I go to comp.arch.fpga in the hope
of finding a thread that might aid me in my research, or educate me on
an area of FPGA design of which I'm ignorant. I do not expect to see
posts from people espousing racist anthropoligical theories.

absoulutly true ... but not the whole thread, or even vary many of the
authors in the thread ... the brash branding of the entire thread, even
if
dominated by a couple non-PC posters I take offensive, as one of the
posters in that thread.

It seems to me that Peter has earned his right to criticise this post
through the countless hours he has spent helping comp.arch.fpga to
become a respected resource to the FPGA community.

Sure he has the right, just as they do ... as do we to object about
creating
yet another thread to hash it out. Posting directly in the thread
asking for
some order might have been a LOT better.

 

Jeff Cunningham wrote:

Marketing? Heck I would call it outright fraud. The silliness with gate
counts is at least somewhat understandable since there is no really
meaningful conversion. But if a cookie manufacturer sold boxes of 27
cookies but stamped on the box that there are 30 inside, isn't that
considered a crime? They can't defend themselves by saying in the small
print that their cookies are 12% better than the competition, and they
count as 1.12 each.

The real scam in this, is not solidly disclaiming that you are very
likely to be unable to route a fully used part because it lacks routing
resources. AND that you are very likely to be unable to use all the
pins in many designs because you will exceed the maximum number of
toggles per I/O bank. AND that you are very likely to be unable to use
all of the LUT's and FF's concurrently as you can not get enough power
into the device if it's even close to mostly active as they assume a
very high percentage of idle or low speed logic. AND that if you do run
it close to max power, it may not be possible to keep it cool. All of
this comes out as you read application notes and use the online power
estimator, but little if any is visible from the data sheets or other
design materials that one would use up front for initial parts
selection.

So, if they want to take every advantage number wise to claim usable
gates, then they also need to very clearly at the same time explain
each of the cases that may force the number of REALLY USEABLE gates to
be significantly smaller.

Consider a reconfigurable computing application where you fill the
device with small very active computational cores that are very active
logic wise ... this drives the dynamic power requirements and heat load
thru the roof, forcing the part to be seriously derated. With
applications like this it's fairly easy to end up with applications
that might have toggle rates that are very very high as a percentage of
the device.

or just try and use it as a huge digital delay register with
programable taps ... Nearly every LUT and FF is part of a shift
register ... at any speed which is a significant percentage of rated
clock speed the power and heat will force the design to be seriously
derated. When you start to look at the current profile around clock
edges to deliver the total power requirements the power estimator gives
for these kind of applications, it's pretty clear that much power will
hit the power pins only a fraction of the clock duty cycle, even if
spreading the current with multi-phase clocks. They do not provide any
package level power models to simulate that die isn't seeing much
larger ripple than can be observed on the host pcb due to spiking
current profiles.

The extreme of this farse would be a vendor claiming six times the
logic resources, and 1/4 the price, but only offering routing to allow
1% of the resources to be used ... I'm sure the same vendor would be at
the front of the pack to set the record straight about requiring the
derating of the part due to resource limitations.

 

[rickman]

Austin Lesea wrote:

We provide programmable resources. The data sheets provide exact tables
for those who care as to the total numbers of everything.

Uhh, Austin, in case you did not read the initial posts, the misleading
data sheet numbers is what this thread is about. I searched the
Spartan 3 data sheet for LC and Logic Cell. The only mention I see of
the counts is on the first page in the table that has the "Equivalent"
count which is exactly what this thread is about.

If all you read is the top sheet, then you have just "scratched the
surface" are are subject to the 'promotional' side of the presentation:
all of the elements that we think are new and exciting, and different.

So where is the accurate information you are talking about?
"Equivalent" logic cell counts are clearly not "new", so are they
"exciting" or just "different"?

But that is not what our customers do: rather, we provide devices that
are programmed by them to solve problems. If the device chosen has too
few resources, then they can (and do) go to the next larger device. If
the device chosen gets too hot, they can (and do) use better heatsinks,
or change their design.

If that is the way your company looks at it, why don't they put the
*actual* logic cell counts into the data sheet table rather than the
marketing "Equivalent" counts?

It is called engineering.

But the way Xilinx does it, it's called marketing.

Austin

I have no beef with either you or Peter. But please don't insult our
intelligence by trying to defend marketing numbers in a data sheet.

 

[Austin Lesea]

Rick,

OK. So I download:

http://direct.xilinx.com/bvdocs/publications/ds099.pdf

And I see immediately when I search for LUT, the issue. Then, I continue.

And, I see no more references to LUT. OK, so S3 has not provided a
count? Yup. I get it.

But, they do have total CLB's, and the comment that has the dreaded
1.125 multiplier in it.

So, I take number of CLBs, and multiply by LUTs per CLB. That wasn't
too hard.

But I agree, it seems odd not to have the basic numbers there, without
multipliers for "effectiveness."

Before I finish, though, I go off to Virtex 4's data sheet:

http://direct.xilinx.com/bvdocs/publications/ds112.pdf

And I immediately see two different numbers: 178,176 LUTs in the LX200,
and 200,448 "Logic Cells." No footnote. But there are 89,088 slices,
so I multiply by 2 LUTs/Slice, and I get 178,176. OK, so far so good.

So, at least S3 had a footnote to explain the "magic," wheras V4 did not
even have that. But V4 did have the basic count up front (for the
largest part) to help with decoding...

Is this really such an issue?

Perhaps since I know LUT/slice slice/CLB for each family (at least I can
always look it up), it isn't as if this is an ordeal to keep track of.

Would I rather that Marketing was not responsible for the data sheet?
Heavens No! My paycheck depends on their abilities!

So, the tables do have exact numbers, they just require some
investigation to remove the "effectiveness factor" for those who like to
count.

By the way, I love to count. In fact, my father was from Transylvania,
and as you all know, a role model for two generations now for all
Transylvanians has been Sesame Street's 'The Count'.

"Ah Ha Ha! One, Two, Three.... I Love to Count..."

So, for anyone confused, and unable to count, just drop me an email, and
I will be happy to provide any details.

And, I will continue to work with Marketing so that the numbers are at
least there in some form in the tables.

Austin

 

[luigi]

Thanks Antti

This was a very helpful hint.
Since I know that this is a Xilinx fault, I can live with. Important is
to know, that we don't have a hardware error.
We need "master serial mode" and want change constantly the resistors,
so we erase the flash.

Luigi

 

[Austin Lesea]

Jim,

Marketing has always had responsibility for putting the data sheet
together. That is nothing new.

Peter and I have decided to work our how to do this better. We'll see
how successful we are...

Austin

 

[Ray Andraka]

Jim Granville wrote:

Radical Idea: Give Marketing the front page(s) of the data sheets, and
let engineering control the rest, and label the pages accordingly.
Then _everyone_ knows what they are reading...

Better yet, leave the brochure to marketing and the data sheet to
engineering. The data sheet shouldn't be the sales tool any more than
the slick marketing brochure is an engineering document.

It is ridiculous having to mine the data sheets for such basic important
information as the LUT count. Nobody using these devices gives a flying
fig about the number of "marketing gates" or "equivalent LUTs". Those
figures simply have no meaning to an engineer, and have no place on a
data sheet.

 

[Rob]

Are you trying to implement the transmitter within the FPGA?

"Frank Schreiber" <frankschr@googlemail.com> wrote in message
news:dr0fec$kvu$1@anderson.hrz.tu-chemnitz.de...

Dear all
I'm starting with LVDS.
My task is sending 8-bits signal to LVDS Transmitter port on my board.
I declared a 8 bits vector, assigned pins, and changed values in 8-bits
signal, but nothing happended in my oscilloscope. Assume that pins-out are
right assigned, all wires and DAC are working perfectly.
Can anyone advise me, how to make it works.
Many thanks
Frank

 

[Austin Lesea]

Ray,

OK, OK. We have heard you.

As I said, Peter and I will do our best to influence "truth in counting."

Austin

 

[Jim Granville]

Austin Lesea wrote:

Jim,

Marketing has always had responsibility for putting the data sheet
together. That is nothing new.

Peter and I have decided to work our how to do this better. We'll see
how successful we are...

Austin

Good luck

These details DO matter, as they affect the credibility of the whole
document. If they are allowed to creep one dimension because it
"sounds better", what's next - marketing nanoseconds ?

-jg

 

[Austin Lesea]

Rick,

I have said (this will be the third time) that Peter and I agreed to
'try' to do this differently going forward.

Wish us luck.

Austin

 

[Austin Lesea]

John,

Thanks.

I understand that posts come from many places, through many portals...

Austin

John_H wrote:

"Austin Lesea" <austin@xilinx.com> wrote in message
news:dr3ml3$igc3@xco-news.xilinx.com...

Rick,

I have said (this will be the third time) that Peter and I agreed to 'try'
to do this differently going forward.

Wish us luck.

Austin



Austin,

I'm glad to see this attitude taking shape. Thrilled, actually, at the
thought of your MarComm group presenting data in datasheets.

As far as repeating yourself, consider that different newsgroup readers (or
settings) present the posts in different orders. The first (or second)
response should be sufficient since the thread takes different branches;
please don't take it personally that there are still a few posts that come
in in the hours after you first post the good news.

Thanks for the effort on our behalf,
- John_H

 

[Jim Granville]

Ray Andraka wrote:

Jim Granville wrote:


Radical Idea: Give Marketing the front page(s) of the data sheets, and
let engineering control the rest, and label the pages accordingly.
Then _everyone_ knows what they are reading...


Better yet, leave the brochure to marketing and the data sheet to
engineering. The data sheet shouldn't be the sales tool any more than
the slick marketing brochure is an engineering document.

It is ridiculous having to mine the data sheets for such basic important
information as the LUT count. Nobody using these devices gives a flying
fig about the number of "marketing gates" or "equivalent LUTs". Those
figures simply have no meaning to an engineer, and have no place on a
data sheet.

I fully agree - I was just looking for an incremental change,
that those in marketing might not notice...
-jg