EDK : FSL macros defined by Xilinx are wrong

[vssumesh]

The problem is i want that in a single chip. How can i link those huge
control signals out of FPGA.
But i am still wondering why the ISE is not working with my design. Ok
any way i am proceeding with 120 registers and will let all of you know
the results.
Thanks for all the advice and suggestions.

 

[Stephen Craven]

codejk,

How fast and precise does it have to be?

You could put a MicroBlaze on there with the single-precision
floating-point instructions enabled and do it in software.

Stephen

 

[Ed McGettigan]

Jecel wrote:

Ed McGettigan wrote:

We have improved the VGA quality on the upcoming ML405 and ML410 boards
that will be released early next year.


I have done the "tie all grounds together" mistake myself, so I know
how you feel.

But I am wondering why the ML401 uses a 50MHz DAC instead of a 140MHz
one like the other two boards. I can't imagine the difference in cost
is significant in a $500 product and being limited to 800x600 isn't
much fun. I am looking into adding a second video output using the
expansion connectors to get around this but the result will be a bit
awkward.

With every board that is designed you have to make some trade offs
between peripherals, performance, power and cost. The ML401/2/3
boards are loaded with features at a very reasonable price point
and in order to do that we had to make some compromises in certain
areas.

When we designed the VGA output on these boards the thought was that
it would make it easier for our FAEs to demo the Virtex-4 technology
by being able to plug it into a projector for a whole room instead
of having everyone crowd around a tiny LCD display. With this in mind
we opted for a lower performance solution as it would keep the cost
down and not add yet another clock source to the board. This was also
carried through to the ML403 (FX12) version that has a lower total IO
count (320 vs 448) and the bottom 3 bits of the RGB values are tied to
GND providing only 15-bit color instead of 24-bit color on the ML401/2.

As it turns out we have had more customer interest interest than we
expected in this feature and we have improved the VGA quality on
upcoming boards. In order to verify and optimize the new VGA layout
we built a protoboard for the XGI headers, so it is possible to do
this cleanly. We are not intending on releasing this board for sale,
but if there was interest in it we might (if you want to see this send
me an email).

Ed

 

[Ed McGettigan]

Antti Lukats wrote:

"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag

We have improved the VGA quality on the upcoming ML405 and ML410 boards
that will be released early next year.

Ed


Hi Ed,

your comment about 405 "to be released early next year" (2006) sounds like
firm indication that Xilinx has serious problems with 4FX? The ML405 was
announced no later than jan 2005 (maybe earlier), now you are saying that it
is coming sometime in 2006 ? Why announce products that are 'maybe' coming
more than a year later? I would have expect ML405 to be available by now.
Well if there is really an issue with 4FX that would explain why no FX
boards are available from Xilinx online shop. Just wondering.

Right now almost all of the FX20 silicon is being shipped to customers
on a priority basis. We do have fully functional ML405 and ML410 boards
in house that we are now making available to our processor specialist
FAEs and available on a limited loaner basis to customers and this will
increase over coming months.

It takes 3-4 months from this point before we can complete all of the
rest of the material in order to turn it from early access board that
requires a knowledgeable and trained person to use it into a general
availability product with full manufacturing tests, documentation,
reference designs and packaging. Also, our internal processes has
certain requirements that must be met before we place boards in the Xilinx
Online Store, this should happen 1-2 months after the boards are
available from our distributors.

We haven't formally announced the ML405 and ML410, but we have shown
them at trade shows and forums such as this as an upcoming development
vehicle for Virtex-4. We do this so that our customers and partners can
understand what our plans our for support collateral so that they can
develop their own product development and test roadmaps.

Ed

 

[Antti Lukats]

"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag
news:4342A6AA.6020500@xilinx.com...

Antti Lukats wrote:
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag

We have improved the VGA quality on the upcoming ML405 and ML410 boards
that will be released early next year.

Ed


Hi Ed,

your comment about 405 "to be released early next year" (2006) sounds
like
firm indication that Xilinx has serious problems with 4FX? The ML405 was
announced no later than jan 2005 (maybe earlier), now you are saying
that it
is coming sometime in 2006 ? Why announce products that are 'maybe'
coming
more than a year later? I would have expect ML405 to be available by
now.
Well if there is really an issue with 4FX that would explain why no FX
boards are available from Xilinx online shop. Just wondering.


Right now almost all of the FX20 silicon is being shipped to customers
on a priority basis. We do have fully functional ML405 and ML410 boards
in house that we are now making available to our processor specialist
FAEs and available on a limited loaner basis to customers and this will
increase over coming months.

It takes 3-4 months from this point before we can complete all of the
rest of the material in order to turn it from early access board that
requires a knowledgeable and trained person to use it into a general
availability product with full manufacturing tests, documentation,
reference designs and packaging. Also, our internal processes has
certain requirements that must be met before we place boards in the Xilinx
Online Store, this should happen 1-2 months after the boards are
available from our distributors.

We haven't formally announced the ML405 and ML410, but we have shown
them at trade shows and forums such as this as an upcoming development
vehicle for Virtex-4. We do this so that our customers and partners can
understand what our plans our for support collateral so that they can
develop their own product development and test roadmaps.

Ed

Ok that explains it a bit. I expected that Xilinx internally should have
ml405 boards. So the deal is that the boards are there, but are just not
going to be made available until someday in 2006.

I still dont see a point to have the ml405 being mentioned in Xilinx
publications in JAN 2005, and then ship sometime in 2006

Antti

 

[Andy Peters]

vssumesh wrote:

The problem is i want that in a single chip. How can i link those huge
control signals out of FPGA.
But i am still wondering why the ISE is not working with my design.

Probably because your expectations are not inline with the device
capability?

You're trying to create a huge combinatorial mux. It's not at all a
surprise that you're not meeting your timing requirements.

-a

 

[GMM50]

In the interrupt routine you need to clear the interrupt.
Check to see that you are doing that.

George

 

[Ben Twijnstra]

Hi Austin,

First of all, thanks for having been polite and courteous to everyone while
I was on paternity leave.

Second, to reiterate, I do _not_ work for Altera. I did, but I don't, and
haven't done so for several years. Thus, any reference to Altera with 'you'
when replying to my stuff is wrong.

By the way, if Altera doesn't use "faulty bits" why do you have:
...
9 Patents (plus) for them?

Yep, and for you too. Not sure whether you actually had to use Altera's
cross-licensed patents to make EasyPath see the light of day, but it surely
must have saved on attorney fees, and $DEITY knows all of us should avoid
feeding those critters.

Your use of laser frapped fuses to replace bad columns is identical to
EasyPath (we just avoid the defects, the same as you).

Those patent cross-licensing deals are good, aren't they?

To be honest, I always understood that EasyPath devices were carefully
selected defective parts where the defect happened not to interfere with
the specific user's design. Thanks for clarifying this. You just can't
trust Marketing people these days.

Meanwhile, 'EasyPath' remains easy, and now includes the standard option
of being able to change the logic (LUTs may be reprogrammed) or change
the IO (strength).

Just like with an FPGA... Ok, but now I'm thoroughly confused. Can you tell
me, on a hardware level, what is the difference between your standard
XC4Vxxx offering and its accompanying EasyPath device?

Every try to ECO an ASIC?

Yep, and it's something best avoided. I FIBbed a few dies. Not fun, and I
was a lucky bastard for getting two of the bloody things to work that way.
Then it was bow-in-shame time for requesting a new mask from the boss...

Best regards,



Ben

 

[Antonio Pasini]

We have improved the VGA quality on the upcoming ML405 and ML410 boards
that will be released early next year.

I have done the "tie all grounds together" mistake myself, so I know
how you feel.

Jecel, could you give me some advice on this ? Same application; maybe
using TI THS8133.

I feel I'm going to do the same mistake again

Splitting grounds didn't always give me the best results. But I'm not so
expert in high speed layout.

 

[John_H]

In verilog I'd try to use:
q <= (~sel | passthru ? A : 0) + (sel | passthru ? B : 0);

The trouble is the MULT_AND doesn't like the OR functions for the "enable."
If the sel and passthru are redefined to the control terms above, the single
layer of logic for A and B would work. If you need sel, passthru, A, and B
to all be single levels of logic, you can't do it because the MULT_AND wants
two inputs: one of your vectors and one control term.

q <= (useA ? A : 0) + (useB ? B : 0); // 1 level



"Sylvain Munaut" <com.246tNt@tnt> wrote in message
news:4342e651$0$25209$ba620e4c@news.skynet.be...

Hello,

Here is my problem :

I want to have a combinatorial block with 4 inputs :
- 2 vectors A and B
- 2 control signal 'passthru' & 'sel'

that produces either A+B (if passthru=0),
A (if sel=0) or B (if sel=1). And all that in a
signle layer of logic.


In VHDL:

process(a,b,passthru,sel)
begin
if passthru = '0' then
q <= a + b;
else
if sel = '0' then
q <= a;
else
q <= b;
end if;
end if;
end process;

I know it's possible :
- using a, b, not passthru, sel as F1 F2 F3 F4
- using MULT_AND to stop carry propagation

and I could do it for just mux(A, A+B) by describing it as

bp <= b when passthru='0' else (others=>'0');
q <= a + bp;

(and that must be a + bp, when putting bp + a that doesnt work, it
produces two level!)


Does any one know the good 'template' to use ?


Sylvain

 

[Sylvain Munaut]

John_H wrote:

In verilog I'd try to use:
q <= (~sel | passthru ? A : 0) + (sel | passthru ? B : 0);

The trouble is the MULT_AND doesn't like the OR functions for the "enable."
If the sel and passthru are redefined to the control terms above, the single
layer of logic for A and B would work. If you need sel, passthru, A, and B
to all be single levels of logic, you can't do it because the MULT_AND wants
two inputs: one of your vectors and one control term.

q <= (useA ? A : 0) + (useB ? B : 0); // 1 level

Actually, I don't see how to fit your representation (useA useB) into a
single level ...


What I wanted the tool to do is : (pt_n is not passthru)

.. cout
.. _|_
.. ,--/___\ CYMUX
.. | | |
.. ______ | | |
.. a(b) ---------| | | | | ____ XORCY
.. b ------x--| LUT4 |-x----------\\ \_____
.. pt_n ---x--|--| | | x----//___/
.. sel ---|--|--|______| | |
.. | | / |
.. | | __ / |
.. | '------| \ _/ cin
.. '---------|__/
.. MULT_AND


Sylvain

 

[rhnlogic@yahoo.com]

Peter Alfke wrote:

"Metastability" is a popular word to scare inexperienced designers.

If you run a 1.8 MHz clock (even with a similar asynchronous data
rate), your chance of having a 3 ns extra metastable delay is once
per billion years (at 24 MHz it would be only 5 million years).
For every additional ns of acceptable settling time, the
mean-time-between-failure increases at least a million times.

This certainly depends on the logic family, which the OP didn't
specify. I have seen IO equipment, constructed with older slower
logic families, fail due to improper synchronization at clock rates
of much less than 24 MHz. Even today, with fast submicron CMOS,
you can still create reliability problems with worse case register
placements or interconnect routing.


IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M

 

[Adam Megacz]

Austin Lesea <austin@xilinx.com> writes:

To be honest, I always understood that EasyPath devices were carefully
selected defective parts where the defect happened not to interfere with
the specific user's design.

This was my understanding as well. I think most people who take the
time to read about it come to this conclusion.

Who at Xilinx every represented EasyPath as any other than what you
described above?

Well, to be honest, going from the marketing materials alone, I wasn't
quite sure if it was a new flavor of peanut butter or a boiled cabbage
accelerator. But Xilinx's marketing department isn't really any worse
than any other silicon valley company in that regard.

I understand Altera tells everyone EasyPath are "defective" parts.
They also fail to mention that ALL of their parts use redundancy to
repair defective portions of their FPGAs.

Interesting, I didn't know that.

At least our non-EasyPath FPGAs really have no defects whatsoever.

Er, really? I thought you had to pay extra for the 100% tested ones.
Does Xilinx really test every net on every chip for (say) stuck-at
faults before shipping?

- a

--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

 

[Ben Twijnstra]

Hi Austin,

Who at Xilinx every represented EasyPath as any other than what you
described above?

I unfortunately don't get to talk to Xilinx people very often nowadays,
which is a bit of a pity because I used to get along well with the whole
Xilinx FAE team in Belgium - including Marc Defossez.

I understand Altera tells everyone EasyPath are "defective" parts.

Well, they were presented to me as 'possibly partially defective parts, but
happening to work OK with the specific customer design'.

They also fail to mention that ALL of their parts
use redundancy to repair defective portions of their FPGAs.

Not quite true. When the EP20K1500E and its slightly less bulky brethren
came out Altera quite proudly presented the redundancy as a yield
improvement technique. The redundancy 'feature' was also present in Stratix
customer presentations. I don't remember about Stratix II presentations
though.

At least our non-EasyPath FPGAs really have no defects whatsoever.

Oh, once Altera's repair department is done with a die, so does a Stratix
(II), which is 100% tested as well.

EasyPath is tested to the customer's pattern, and represents an
extremely high test coverage for their specific application.

So, can I then summarize that EasyPath is basically a standard Virtex II/4
but with less time on the testbed (only the cells and routing used by the
customer are tested) in order to reduce cost?

Best regards,


Ben

 

[Austin Lesea]

Adam,

The "stuck at fault" testing is extremely high: we carefully examine
test patterns for their IC design shcematic coverage.

Even the generic FPGA flow test coverage is much better than an ASIC.

Austin

Er, really? I thought you had to pay extra for the 100% tested ones.
Does Xilinx really test every net on every chip for (say) stuck-at
faults before shipping?

- a

 

[Austin Lesea]

Ben,

-snip-

So, can I then summarize that EasyPath is basically a standard Virtex II/4
but with less time on the testbed (only the cells and routing used by the
customer are tested) in order to reduce cost?

There is a basic 1's, 0's, shorts, leakage, etc test done to all parts,
EasyPath or no.

And then, for EasyPath, only those features used by the customer are
tested (with the addition of any LUT pattern for the CLBs they use, and
any IO strength for th IOB standard they use, which allows for the two
most common ECO requests we got after we shipped). The difference in
test time between as close as we can get to 100% testing for any
possible use, and as close as we can get to 100% testing for one use is
SIGNIFICANT.

As well, the test yield to one test program is also SIGNIFICANTLY HIGHER
than for many thousands of test programs (which is potentially what it
takes to have an acceptable AQL).

Better Yield + Shorter Time = Lower Cost to Xilinx, which means Lower
Prices to customer.

Austin

 

[Jecel]

Antonio Pasini wrote:

I have done the "tie all grounds together" mistake myself, so I know
how you feel.

Jecel, could you give me some advice on this ? Same application; maybe
using TI THS8133.

This was a long time ago using the original ARM chipset. The video was
only 24MHz, so it was hardly high speed by today's standards. Though I
knew that the analog part should have separate power and ground I was
busy with other things and didn't correct the layout guy when he failed
to do this. The running programs generate a very visible pattern on the
display and even in the speaker. At least this made debugging a little
easier ;-)

If you use all 10 bits available in the THS8133 instead of just 8
(24bpp) then I imagine it is even more important to get rid of the
noise or else you might as well use the cheaper THS8134B instead.

-- Jecel

 

[rk]

Perhaps of some interest (subset of this presentation)

"The NSEU Response of Static Latch Based FPGAs"

original title on abstract: "The Continuing Impact of Design and Process
Hardening on the NSEU Sensitivity of Advanced CMOS PLD Technologies"

Joseph J Fabula and Austin Lesea, Xilinx
2005 MAPLD International Conference
September 7-9, 2005, Washington, D.C.

Abstract: http://klabs.org/mapld05/abstracts/175_fabula_a_.html
Presentation: http://klabs.org/mapld05/presento/175_fabula_p.pdf

-- rk


Austin Lesea wrote:

(Real) Bob,

Thanks for sending to me directly.

There is an aerospace/defense FAE who will contact you shortly to
provide you with what you need (if we have what you need).

I know we had Coolrunner II in the LANSCE facility in May of this year,
as it was my group that set it up, and was there for the testing.

(surreal) Austin

Bob wrote:

Sorry I don't use (real) info on newsgroups to keep spam to a minimum.
I will email you with my (real) contact info.
However I have tried before and was told that there was no info on the
CoolRunner 2 as it is not intended for radiation and there are other
parts that are designed for radiation. However that was last year.
I have also searched on the NASA and ERRIC web sites and was
unsuccessful in finding data.


On Tue, 04 Oct 2005 11:55:47 -0700, Austin Lesea <austin@xilinx.com
wrote:


(Not Real) 'Bob',

If you want an answer to this, why haven't you already contacted our
Xilinx Aerospace/Defense Field Applications Engineers?

We have plenty of data that we are willing to share with (Real)
'customers'.

If you need a contact, I can send their name to you once you email me
your (Real) 'Bob' email address (and real affiliation).

It is Xilinx' interest to be sure that any aerospace/defense application
(as well as any other) of our products uses all of the best information
that we can provide.

Austin



Bob wrote:


Hi I know that the CoolRunner2 CPLD TQ144, XC2C256-7TQ144I is not
designed to be radiation tollerent, but...

I would be interested if anyone reading this has ever radiated a CPLD
or know of some CPLD radiation data on the web.
I have google searched but found very little.
Most ics like 74hc04 parts can take about 10,000 or more rads of total
dose (Co60).
I hope to do some total dose testing this month.
Also as it has a reprogramable memory, it will be suseptible to SEU.
I wont be able to test for that.

--
rk, Just an OldEngineer
"These are highly complicated pieces of equipment almost as complicated as
living organisms. In some cases, they've been designed by other computers. We
don't know exactly how they work."
-- Scientist in Michael Crichton's 1973 movie, Westworld

 

[Peter Alfke]

Bob, I agree with everything you wrote, but the original posting
mentioned 1.8 MHz and 24 MHz. I did not make that up. It sure is not a
typical modern design...
I think we would agree that such a slow design will, almost inevitably,
have a few ns slack to accomodate a possible metastable delay.
If you use a 500 Mhz clock to synchronize a 400 MHz asynchronous data
stream, the problem is much more real.
I am so happy that we went to the trouble of measuring the delays on
real (V2Pro) silicon, same as we had done with XC4000 years before.
That gives us quantitative data. Less arm-waving.

The rule still is: If you have reason to worry about metastability,
give the flip-flop in question maximum slack to settle, and have it
drive only one near-by synchronizing flip-flop. Without that
precaution, you might get into trouble...
Peter Alfke

 

[Zara]

On Tue, 04 Oct 2005 19:16:46 -0500,
mvetromille@gmail-dot-com.no-spam.invalid (Melissa Vetromille) wrote:

Hello!

I have a system implemented in hardware and I prototyped it in
VIrtex-II Pro platform with a testbench. I analyzed the signals using
chipscope and it worked the same as in simulation. After this, I
created a project in EDK and substituted the testbench by a
Microblaze processor. The project stopped working. Now, I need to
debug the harwdare in order to find the problem, ut I don't know how
to do this. I'm trying to use ModelSim.
In fact, I generated the simulation files and created the testbench
file to stimulate my system. However, this testbench just generates
the clock and reset, so I need instanciate my software in order to
generate the other stimulus. Is it possible? What do I have to do in
order to incorporate my software in simulation? Does anyone can help
me?

Thank you!

Melissa

For me, the best way to debug hardware with a microblaze inside is to
instantiate a ChipSocpe icon and ila inside the design, connected to
the secondary bscan port of an opb_mdm connected to the microblaze.
This way, you may debug hardware or software (not simultaneously)
easily.