EDK : FSL macros defined by Xilinx are wrong

Hi Peter,

I swear there is nothing on my mind. It's just that I'm a little bit
confused and I'm trying to clear things up.

There is a lot of literature, books, publications and reports on
testing techniques and mechanisms and I'm trying to figure out how the
entire testing process is done from an industrial perspective.

I'm a 4rd year PhD student at University of Cincinnati, and FPGA
reliability is just one part of my PhD dissertation. So yes, there
seems to be an rough idea on my mind but just for acedemic purposes.
I'm still working on it and it all has to do predicting reliability for
FPGA devices. You can say a new prediction method. But I'm not yet sure
of its feasibility so I'm just trying to clear thinsg up. That's all.

I'm not trying by any means to pull information out of anybody by
asking indirect questions. Maybe my questions gave you that impression
but again there is no purpose to them at all and this is again my fault
:)

Thanks a lot.

Amr
 
see comments below

"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag
news:42e58544$1@clear.net.nz...
Antti Lukats wrote:

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag
news:42e540a2$0$8024$3b214f66@tunews.univie.ac.at...

Xilinx FPGA's are nice but all of them (after XC4K?) do not have any
more
access to the OnChipOscillator - it is not usually required also, but
in
some rare cases it may be useful to have some OnChip Clock available in
case
all external clock sources fail, or do have emergency Watchdog timer to
monitor some events also in the case of external clock circuitry
failures.
For this purpose we are developing OnChip Oscillator IP Cores.

http://gforge.openchip.org/frs/?group_id=32

Interesting - any data on Vcc and temp variations, and on other
frequencies ?
Click to expand...
the OnChip Oscillator is part of larger project and yes we do some
measurements, the vcc-temp variatans measurements are not done yet.

I only have measured some 5% frequency change in V4 when the
chips temp raises from ambient to normal working temp.

But the maximal variation can actually be indirectly be calculated
from Xilinx datasheets, from my estimate the frwquency should
not be off more than +-20% over full temp and vcc range or
xilinx datasheet values would not much - that comes from the
margin in timing specs in datasheets.

of course this applies for one given device-speed grade combination
and should be measured in the same CLB location

Power consumption ?
Seems to me, it would be better to create a clock as low as possible,
before driving the high-load clock buffers. - thus a cell that is
both OSC and Divider could be better ?

This cell is OSC and Divider by 2, the high speed signal path (about 440MHz)
Click to expand...
is kept completly inside the routing switch of an single CLB, ie it is not
driving
any short or long connections at all, only goes to swithcbox and back. The
only
load on this net is Divide by stage, what is the actual output of the OCO
Cell.

we are developing OCO cells with low clock output as well, more suitable
for things like watchdog, etc..

An advantage of on chip Osc, is they self-margin, so track Vcc and Temp.
If I've understood your results, they show quite close correlation
across the die.
Click to expand...
you understand correctly, the frequencies shown in the screenshot are
from different CLB locations accross the die, and the correlation is about
what was to be expected.

This would also be a good way to see if faster speed grades REALLY are
faster, or just stamped to match the market :)
Click to expand...
Yes, you are a mindreader - this is part of FPGA fine tuning project exactly
targetted for
timinig measurements of the FPGA internals.

Just looked at the sources - There are binary VHDL files. What does
this mean?

Martin


This means they can only be used by ISE tools. There should be no
problems
using those files with ISE 6.2 to 7.1, just add to your project and
synthesise as normal. If there are any problems let me know.

?! - do you mean you cannot save as ASCII source code, or use any other
editor ?
Surely this nonsense can be disabled ?

-jg
Click to expand...
Sure, ask for commercial licensing and you will get readable source code
instantly.
At the moment the sources are encrypted to prevent modification.

Antti
 
"praetorian" <Hua.Zheng@jpl.nasa.gov> schrieb im Newsbeitrag
news:dc3gfl$2ka$1@nntp1.jpl.nasa.gov...
Is there any contrainsts for the V2P to disallow routing in a certain
area?
Click to expand...

read cgd.pdf - but I think no. you can only disable some CLBs to used but
not prohibit the routing fabric areas from being used.

Antti
 
Antti Lukats wrote:
"Jedi" <me@aol.com> schrieb im Newsbeitrag
news:i74Fe.125$Sg3.58@read3.inet.fi...

Jedi wrote:

Moro

Back from a successful trip in .ch I have to change
my contact details at Altera and they provide
an email address for doing this:

csecom@altera.com

which just leads into nirvana and bounces back
with "user unknown"...

Any other address to use? Or why is it not allowed to
change address online?

I guess nobody at Altera discovered this or don't care?


rick


they dont care
Click to expand...
And all Altera guys seem to be on vacation for several weeks now...
as well as their webmasternot knowning that csecom@altera.com
results in "unknown user"...

Looks like I have to fly to Finland from Switzerland every time a new
NIOS/Quartus upgarde is out (o;


rick
 
I've used it for synthesising rather large designs on XP. It is fine as
long as you install some patch that fixes a windows issue with the 2GB
limit. I've done it a while ago now, but can't remember what exactly
this patch is.
Click to expand...
I guess you're refering to the AR 14932: http://tinyurl.com/9xl4w

HTH,
Jim
 
Sarath,

In my humble opinion, a good ASIC RTL design is always going to become a
good FPGA RTL design almost at no cost.
I mostly did FPGA2ASIC, never done ASIC2FPGA, but I have no doubt about
that.

Moving on...
You need to think of replacing memories, if they are instantiated as HDL
macros, also any PLLs, I/O (if there are any), etc.
but the datapath processing should remain the same.

If you can give more details what are you facing, it would be easier to
point to the tools, which usually are just a few good engineers.

Vladislav


"sarath" <sarath1111@gmail.com> wrote in message
news:1122444179.117553.257740@f14g2000cwb.googlegroups.com...
Hi all,
Can any one list me out the various steps that need to be carried
out to convert ASIC RTL Code to FPGA RTL Code. In what way the ASIC RTL
Code differs from FPGA RTL Code. Can you also list me the various tools
that are available to perform them.
Thanks in Advance,
Sarath
Click to expand...
 
There is a pin error in the footprint of the EP2C8F256.
The F5, LVDS13p is alone, there is no LVDS13n,
which has to be for a true LVDS channel.

Can anyone confirm this ? It basically means there
is no LVDS13.
Click to expand...
Hi Rene,

My answer was somewhat cryptive, the die pad LVDS13n is simply not
available on this package. So it is available on the die, and in the
Q208 package, but not in the F256 package. There it is replaced by some
dedicated pins for config.
 
"Antti Lukats" <antti@openchip.org> wrote in message
news:dc5g2c$5dq$03$1@news.t-online.com...
"uxello" <uxello@free.fr> schrieb im Newsbeitrag
news:42e64094$0$20177$626a14ce@news.free.fr...

The first WebCase
we opened - the response from Xilixn was: - well there has been not much
interest in XCFxxP IEEE1532 BSDL files, so we have not made them. They are
scheduled for 2006. You have to wait.
Click to expand...
They seem to be available unless I am missing something:
ftp://ftp.xilinx.com/pub/swhelp/bsdl/xcf.zip


/Mikhail
 
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag
news:3kpl5hFvlb6mU1@individual.net...
"Antti Lukats" <antti@openchip.org> wrote in message
news:dc5g2c$5dq$03$1@news.t-online.com...
"uxello" <uxello@free.fr> schrieb im Newsbeitrag
news:42e64094$0$20177$626a14ce@news.free.fr...

The first WebCase
we opened - the response from Xilixn was: - well there has been not much
interest in XCFxxP IEEE1532 BSDL files, so we have not made them. They
are
scheduled for 2006. You have to wait.

They seem to be available unless I am missing something:
ftp://ftp.xilinx.com/pub/swhelp/bsdl/xcf.zip


/Mikhail


they are NOT, available are only IEEE1532 files for XCFxxS not for XCFxxP !!
Click to expand...

Antti
 
file what & where ?
Ah, support request ? That is this personal login stuff ?
A black hole, IMO.
Click to expand...
Not necessarily: I have got two bugs fixed that way, one with the next
service-pack, for one I even got a patch within a few days. However, I have
to admit that I also had that feeling ("black hole") in the past. It depends
on who handles your request, and you need some patience. But I think it has
improved during the last year...

I think a SR is the right thing for your question as I suppost that noone
here can tell you more than you can guess yourself (just use another LVDS
pair that has p and n ;-)...

Thomas
 
"Jack" <JEmoderatz@yahoo.com> writes:

hi

I need to measure "number of clock cycles" or "execution time", after
mapping the VHDL code into Vertex II pro.

In Modelsim simulation, it took 350 cycles with 20 MHz clock frequency.
I hope the performance after the mapping will be same as the
performance in simulation.
Click to expand...
Your hopes should be well founded. Assuming your design is
fully-synchronous, and the timing analyser says it meets your 20MHz
clock spec, the design will work as it does in simulation.

In ISE 6.3 (or EDK 6.3) , how can we measure the amount of clock
cycles?
Click to expand...
You don't need to.
<snip>
Cheers,
Martin


--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
 
Pablo,

Powering ON is a simple, yet tough thing to do well.

We simulate ramps, and ramps with dips, and other things, and we test
with ramps, but we can't and don't simulate for every possible power
supply made.

Thus, the typical power ON specification wants to see a "monotonic"
rise.

In the strictest sense, this means that the slope is always the same
sign (never stops rising).

Will it work if there is a plateau? Will it work with a slight dip?

Generally, yes. But if you call, and say it does not work with your
ABC power supply, and that supply is not monotonic, we can say "sorry,
but we warned you that it doesn't work with every possible power supply
in the universe."

If you use a power supply that does not comply (for example, all of our
listed power partners DO comply), then it is up to you to characterize
your board, and be sure it will work with all possible variations of
your powering solution.

Austin

Pablo Alvarez Sanchez wrote:
Hi,

If you read the specs of the XCFxxP PROMs, you find:

http://www.xilinx.com/bvdocs/publications/ds123.pdf (page 22 of 42)

"At power up, the device requires the VCCINT power supply

to monotonically rise to the nominal operating voltage within

the specified VCCINT rise time."



Is monotonicity in VCCINT so important for the XCFxxP PROMs? Why? (I
understand monotonicity= positive slope) ,

or the only important thing is that the oe/reset line is released once
VCCINT is stable?

Cheers



Pablo Alvarez
Click to expand...
 
Peter Alfke wrote:
[...]
And all of this with crystal-frequency accuracy.
Click to expand...
Peter (and Austin),

Speaking of crystal-frequency accuracy, you reminded me of a question
I've had for a little while.

How much can the CLKIN input to a DCM vary before you have to worry
about it losing lock? Assume the output drive a GBUF, which feeds
directly back to the CLKFB. I know Austin answered this type of
question at least once before
(http://groups.google.com/groups?q=ppm+dcm+input), but I don't see in
the V2Pro, V4, or S3 datasheets where the 100 ppm is spec'ed. Is the
spec still the same for the above parts?

Thank you,

Marc
 
Hi Rick,

The correct email for address changes is mysupport_cs@altera.com.

Regards,

Vaughn
Altera
[v b e t z (at) altera.com]

"Jedi" <me@aol.com> wrote in message news:f6vFe.264$%U5.258@read3.inet.fi...
Antti Lukats wrote:
"Jedi" <me@aol.com> schrieb im Newsbeitrag
news:i74Fe.125$Sg3.58@read3.inet.fi...

Jedi wrote:

Moro

Back from a successful trip in .ch I have to change
my contact details at Altera and they provide
an email address for doing this:

csecom@altera.com

which just leads into nirvana and bounces back
with "user unknown"...

Any other address to use? Or why is it not allowed to
change address online?

I guess nobody at Altera discovered this or don't care?


rick


they dont care


And all Altera guys seem to be on vacation for several weeks now...
as well as their webmasternot knowning that csecom@altera.com
results in "unknown user"...

Looks like I have to fly to Finland from Switzerland every time a new
NIOS/Quartus upgarde is out (o;


rick
Click to expand...
 
Duane Clark wrote:
Tommy Thorn wrote:


My sram memory interface works, but I've had to insert an idle cycle
to make the read data settle.

Reading the spec for the IDT71V416S10 it claims both tAA and tRC to be
10ns, with a tOH hold time of 4ns min hold time. I thus expected
something like this to work:

always @(posedge clk100MHz) begin
sram_a <= <new addr>;
latched_data <= sram_d;
end

where latched_data is from the previous address obviously. It worked
fine under simulation against the idt71v416s10.v model from IDT, but
on the board it wasn't reliable.

I didn't supply any timing constraints for the FPGA pins connected to
the SRAM and I suspect that to be the problem, but I'm a bit unsure
what should I give as constaints. Suggestions?


The problem is that you generate an address, it takes some finite time
to actually get out to the pins, then more time to get to the SRAM, then
the 10nS to get valid data, then more time to get back to the FPGA, and
then a setup time to acquire latched_data. All of which adds up to more
than the 10nS cycle time of your clock. But because the tAA is a worst
case number, it looks like the actual times are adding up to very close
to 10nS, and hence unreliable data.
Click to expand...
Thanks, but I think you're missing my point. I want to use the SRAM in
a pipeline manner, capturing the data from the previous read in the same
cycle that I present new data. Assuming the delay of getting my address
to the SRAM is roughly equivalent to the delay getting the data back I
should only have to worry about the tOH (data hold time) of the SRAM
being large enough. At 4 ns I'm assuming it is.

And in fact, at 50MHz I can kind of do it. Here's a snippet of my state
machine:

S_READ: begin
if (data_latched != data_expected)
state <= S_FAILED;
else if (sram_a == N)
state <= S_SUCCEED;
else begin
sram_a <= addr;
data_latched <= sram_d;
data_expected <= lfsr[31:0];

addr <= addr + 18'd1;
lfsr <= lfsr_next;

state <= WITH_READ_WAIT ? S_READ_WAIT : S_READ;
end
end

The read cycle of 20ns should be *ample*, but for reasons I still don't
fully understand(*), the lower-order byte on the shared
Flash-Ethernet-SRAM bus on the Altera Nios Development Kit is slower
than the rest. Still the basic idea appears to be valid.

All that to say that I still don't understand how to use the timing
constraints for external pins. Does *anyone* use them? I haven't been
able to find any examples.

Thanks,
Tommy
(*): Only the lower order byte is shared with the flash ram with is a
clue, but the flash and ethernet is fully disabled. Sigh.
 
Hi Vaughn,

The Quartus error message is correct.
Click to expand...
Yep. A remark saying something like "(1) Pin only supports single-ended I/O
standards in F256 and T144 packages" would be helpful in rev 1.4.

Updated my SR accordingly to clarify.

Best regards,



Ben
 
On 27 Jul 2005 16:45:51 -0700, ckpun1978@gmail.com wrote:

Is there a way to pass parameter to "do file" in the command line in
vsim?
Intuitively, it will be something like this
usr@host>vsim tb_dm -c -do mysim.do 1144
(the 1144 is the parameter to be passed into mysim.do)
but it doesn't work...
Click to expand...
It doesn't work because Tcl treats "mysim.do" and "1144" as
two completely separate arguments to the [vsim] command. So
"mysim.do" is treated as the value of the "-do" option, and
"1144" is an orphan.

I can't remember the exact behaviour of the -do option,
but you could make it work a slightly different way.
The "-do" can be given either the name of a script, or
a complete command. So this will be OK:

vsim tb_dm -c -do "do mysim.do 1144"

Note that the command goes in quotes. Tcl programmers
might expect to use curly brackets instead, but if you're
using Windows the OS command shell will smash it up into
separate words. The double-quotes protect the Tcl
command from processing by the shell.

HTH
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Hi Austin,

Thanks for your help,

Now it is clear that Xilinx devices do not tolerate dips. I would also have
liked to understand why it is the case. Altera's devices have a similar
level of complexity but I have not seen such constrains on their power-on
specs.

Cheers,

Pablo


"austin" <austin@xilinx.com> wrote in message
news:1122489508.841246.175190@g14g2000cwa.googlegroups.com...
Pablo,

Powering ON is a simple, yet tough thing to do well.

We simulate ramps, and ramps with dips, and other things, and we test
with ramps, but we can't and don't simulate for every possible power
supply made.

Thus, the typical power ON specification wants to see a "monotonic"
rise.

In the strictest sense, this means that the slope is always the same
sign (never stops rising).

Will it work if there is a plateau? Will it work with a slight dip?

Generally, yes. But if you call, and say it does not work with your
ABC power supply, and that supply is not monotonic, we can say "sorry,
but we warned you that it doesn't work with every possible power supply
in the universe."

If you use a power supply that does not comply (for example, all of our
listed power partners DO comply), then it is up to you to characterize
your board, and be sure it will work with all possible variations of
your powering solution.

Austin

Pablo Alvarez Sanchez wrote:
Hi,

If you read the specs of the XCFxxP PROMs, you find:

http://www.xilinx.com/bvdocs/publications/ds123.pdf (page 22 of 42)

"At power up, the device requires the VCCINT power supply

to monotonically rise to the nominal operating voltage within

the specified VCCINT rise time."



Is monotonicity in VCCINT so important for the XCFxxP PROMs? Why? (I
understand monotonicity= positive slope) ,

or the only important thing is that the oe/reset line is released once
VCCINT is stable?

Cheers



Pablo Alvarez
Click to expand...
 
Marc,

It turns out that if you are going only to the DFS, and you do not move
the frequency very fast, you can sweep from min to max input (output)
frequency before losing lock.

The DLL is fussier, as it chooses to arrange its six delay lines based
on what options, range, and where it locks. So in the DLL, if you
start sweeping the frequency, you may get an overflow or underflow on
one of the delay lines, and lose lock.

We typically spec +/- 100 ppm, because just about any trashy crystal
can do that. In reality, +/- .01 is probably safe.

Austin
 
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag
news:3kspnkFvdd0qU1@individual.net...
"Antti Lukats" <antti@openchip.org> wrote in message
news:dc87bd$knm$03$1@news.t-online.com...

they are NOT, available are only IEEE1532 files for XCFxxS not for
XCFxxP
!!

OK, I see now what you mean. I assumed there was only one BSDL standard.
Can
you please explain what this IEEE1532 is all about compared to "regular"
bsd
files?


Thanks,
/Mikhail
Click to expand...
there is one VERY BIG difference.

the IEEE1532 BSDL contains ALL the programming algorithm information needed
to program the device using IEEE1532 compatible Software. A plain BSDL file
does not contain this information. So if a company, (Xilinx as example) does
not publish some programming algorithm, but DOES publish the IEEE1532
compliant BSDL files for the device in question then you can either extract
the programming algorithm from IEEE1532 BSDL file or use IEEE1532 software
to programm the device in question. So that makes the difference very
important.

Xilinx promised the XCFxxP IEEE1532 BSDL files to be made available in 2006,
but to all my best knowledge the current (non-ES! ) XCFxxP silicon has
features that makes the XCFxxP not programmable in true plain IEEE1532
software, so Xilinx would not be able to deliver the XCFxxP IEEE1532 BSDL
files in 2006 unless they fix the silicon or the IEEE1532 standard. And even
if they fix the silicon by 2006, it still would not help me to program the
XCF08P today. Our client is waiting for solution. And will defenetly not
wait til 2006!!!

I am still waiting for the WebCases solutions, but so far nothing helpful. I
was promises of some sort of reply by monday. Lets see.

Antti
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top