EDK : FSL macros defined by Xilinx are wrong

[Peter Alfke]

Wallstreet consensus is that the programmable (i.e. FPGA+CPLD) market
will grow faster than the aggregate semiconductor or IC market
(expressed in percentage revenue growth per year). Yes, only two
vigorouly competing giants plus a small group of also-runs. But the
same can be said of many other maturing markets.
Peter Alfke

 

[J Silverman]

Hi Peter,

I realized after doing some searching of these chips that they are ancient, but would be perfect for the project I'm building. I do not need anything more complicated than these. I'd really like to use them somehow instead of just throwing them away. Do you know of any other third party software that would support these chips? All I need is a way to create the configuration bitstream from some VHDL so I can program a flash chip with it.

Thanks, J Silverman

 

[Peter Alfke]

Unless you have some sentimental attachment, there is no reason to even
think of using such obsolete parts for a new project.
Would you start a music library on 8-tracks?
Would you go on vacation with a super-8 movie camera ?
Would you buy a car with an SU carburator and drum brakes( except for
reasons of nostalgia)?
You are lacking not "just software": software is the most crucial
ingredient.
The smallest and cheapest Spartan3 chip runs circles around the 3042.
If you need even less, use CoolRunner CPLDs, they are great and work
with microamps...
Peter Alfke, Xilinx Applictions from home

 

[Peter Alfke]

I can only repeat: you will be much happier with a low-cost evaluation
bord, where you can concentrate on the uniquness of your design,
instead of being bogged down by software issues and soldering mishaps.
For real simple circuits, look at CoolRunner CPLDs.
Peter Alfke

 

austin wrote:

Retire?

Wow.

That is a very strange thought.

Both Peter and I are "retire-adverse."

We are having far too much fun watching and helping Xilinx grow.

And I think I am more than young enough to be Peter's child, not his peer.

Amusing post,

Austin

Sorry ... I would have swore I remember a post where you claimed at
least the number of years in the industry as I.

 

[Peter Alfke]

Jim, pretty unlikely.
It would only make sense on the really big devices. Smaller devices do
not need such a crutch.
At the high end, we now have 80 million configuration bits, each of
them responsible for one tiny aspect of the functionality. Tough job to
keep track of that. And how can the user work around it ? When the
chip is simple, it does not buy you anything. When it is really big,
the work-around methodology chokes on its complexity.
Our production testing is always go/no-go, which means we do not even
try to identify the failure, it's just either perfect or scrap. Even
the EasyPath testing is that way; but after a more restricted test that
gives much improved yield. (Such a clever concept!)
Very regular structures (like memories) can use self-repairing
non-volatile fixes. Altera's earlier FPGAs (called CPLDs) had a regular
interconnect structure that allowed such redundant repair, and most big
memories do it. So selling parts with non-functional circuitry on it is
neither new nor unusual (nor unreliable).
But most FPGA structures are too complex and irrgular to allow that,
IMHO.
Wherever the IC manufacturer can really make the repair transparent to
the user, it will obviously be done.
Peter Alfke

 

[Ralf Hildebrandt]

dotnetters@gmail.com wrote:

We are newbies to FPGAs and VHDL.
....
We modified the VHDL code to
want to it to work this way: get an opcode, get two operands and return
the sum or difference based on the opcode. Something kind of this:
if(opcode == )
return a+b;
else
return a * b;
But its not working.

This sounds to me to be a pure VHDL problem. -> comp.lang.vhdl

You seek for a pure combinational solution (add, mul, mux) and post a
code of a state machine, which is sequential. What do you want? ;-)

Do your try to get something running by modifying examples so that it
fits your requirements? I would not recommend this. Use examples as
ideas and guidelines, but write your own code.

Wouldn't it be a good idea to post a _minimal example_ of your problem?

Ralf

 

[Leow Yuan Yeow]

Hi, I was doing that before but I found that each + that I use generates a
32-bit adder under the synthesis report which increases the LUT usage by
quite a fraction. After that I tried to multiplex them to a addsub component
and the LUT usage went down from 90+% to 80+% (I'm using the old RC100 board
with spartan II so I have limited resources ).
I was wondering if there are any other components that I can instantiate for
comparators as well?

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
news:1142607625.918465.315430@e56g2000cwe.googlegroups.com...

Hi,
Please do the following way:

LIBRARY ieee;
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;

signal A : unsigned(4 downto 0); -- example
signal B : unsigned(4 downto 0); -- example

In the code area,

-- they can be in process or between process area.
A <= A + 5;
B <= B - 7;

No need to instantiate any module.
In numeric.vhd liberary, all arithmatic operations are functions.

Weng

 

Ralf,
Sorry, we were right from the start doubtful whether this was the right
group to ask for clarification. But since we had problems with FSL,
which was more to the MicroBlaze side, we thought it would be fine to
do so.. And obviously, we were wrong..
Anyway, thanks.

Cheers, everyone..

-- DotNetters

 

Austin Lesea schreef:

Andy,

The only proof is in the orders, and the shipments, and what I was told.

That you, and others do not believe me is just fine. I didn't need your
approval to ship the parts.

Does anyone honestly think I am making this up? I have no time for
fantasies: I have real work to do. The announcement was made (and the
part briefly shown at the press conference) for 65 nm. Busy doesn't
really describe my shop right now. 'Frantic' is more accurate.

A very happy, and pleasing kind of frantic.

Austin
No, I do not think you make it up.

I think the FPGA could perhaps be used in the dashboard displays.
IIRC for example Toyota used one big LCD display, for all instuments

In such a case you need many many IO (to drive each segment),
and using FPGA could also make it possible to do speed / tacho
conversion,
temp sensor linearization, basically any sensor processing, either
digital
or analog, all in one chip on the back of that big LCD panel.
Now with mega cell FPGA, add the radio, GPS, and what not.
So, yes, and a couple of million cars sold.
But this is not for the reason you mentioned, but simply for the one I
just stated.
Does GM do something like that these days? Ford?
They will have to perhaps.

Posted from planet P

 

[Rob]

The DQS signal is usually associated with a group of data (DQ) pins; so where ever the DQS singal is you want the associated DQ pins located in close proximity. Also, some DDR2 I/O standards, like SSTL-18 class II, are only supported on two sides of the chip.

<v_mirgorodsky@yahoo.com> wrote in message news:1142694593.123202.188480@v46g2000cwv.googlegroups.com...

Hello group,

I have an issue with porting my high-speed DDR interface to Altera
Cyclone II device. As far as datasheet says, Altera Cyclone II device
does not have any dedicated circuitry to support DDR signaling in its
Input/Output blocks for DQ pins. The only thing present in hardware is
the clock delay circuitry on DQS pins. All other DDR logic is
implemented using LUT's and triggers from adjacent Logic Array
Blocks. So, it seams that we have only DQS pins location fixed,
whenever all other DDR pins may float within the selected IO bank. Is
that right? If yes, then what is the reason to denote certain pins on
the Altera Cyclone II package as dedicated pins for DQ input/outputs?

With best regards,
Vladimir S. Mirgorodsky

 

[Rob]

Again, I apologize if you found my posting objectionable. I do realize
that there are some (not implying you) that have absolutely no sense of
humor whatsoever, and for them, all I can say is: don't waste your time
reading my posts, you won't like them (as I do have a sense of humor, and
I do enjoy life and its challenges).

AMEN! A little humor, some sarcasim, and even a little pretention
(ambitious is a better word) can all make for interesting diaglogue.

Take care,
Rob


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

Rick,

If I have offended you, I apologize. In fact, if I have offended anyone,
I apologize. I intended to poke fun (gently) at Metal's posting.

I am an engineer, and I am not in marketing. If that means I am not
politically correct: I never pretended to be anything other than honest.

Again, I apologize if you found my posting objectionable. I do realize
that there are some (not implying you) that have absolutely no sense of
humor whatsoever, and for them, all I can say is: don't waste your time
reading my posts, you won't like them (as I do have a sense of humor, and
I do enjoy life and its challenges).

Austin



rickman wrote:

Austin Lesea wrote:

Metal,

Pessimists always claim they are just observing reality.

You must be working for one of those companies "circling the drain?"

Really hard to be positive about anything.


I see (our) business increasing (a lot), and I see margins that are
good, and getting better, and I see new opportunities popping up all
over the place. And I see the financials that support it.

You have told all of us how we will need food, shelter, and a few sticks
to burn here in the not so distant future.

Austin



Austin, it is hard to believe that no one at Xilinx has ever reigned
you in. Often your posts are useful and technically sound. But
concepts of customer interaction and company representation seem to be
lost on you. I was not even involved in this thread and I find your
post to be insulting as well as totally inappropriate. Your "ad
hominem" attacks seem to occur anytime someone makes a technical
argument that might be hard to dispute.

To be honest, my impression of Xilinx has changed a lot over the last
few years, partly due to your postings here. Initially I did not pay a
lot of attention to your comments to me or others until I realized that
you are actually fairly influential in the company. Now I realize that
Xilinx as a whole is not a lot different than the image you present and
it bothers me. It bothers me enough that I now have a strong
preference for any other FPGA manufacturer.

I think the fact that no one at Xilinx seems to have a problem with
your posts like this one says a lot about the company.

 

Peter is being diplomatic. He has to. (I liked the comment about SU
carbs.)

If it's not supported in a recent web-pak, don't use it.

$.02

 

[Mike Treseler]

Josh Rosen wrote:

The tools that you are looking for never existed. The only thing that was
available at the time were crude schematic entry tools which ran on DOS or
maybe Windows 3.1, I don't remember which.

I think XACT 5 was dos and 6 was windows.
It was a cruel tool.
Ran for days if you were lucky.

I wrote my own synthesis tools
in Gnu Lisp which converted ABEL (a now dead language for PALs) into XNF
format (the old Xilinx Netlist Format), rather then use the schematic
tools.

Wow. Sounds like XACT was at least good as a muse.

Take Peter's advice and get a modern development board.

Yes J.,
either that, or take this break
in the action to learn to code and sim your
design in an HDL. That way you can
check the form, fit and function with
your next device before you buy it.

-- Mike Treseler

 

[austin]

Rick,

I have apologized to you.

As for Xilinx management, I am often called before my boss, my boss'
boss, and so on, and occasionally talk to Wim.

For any number of reasons.

I have been advised, admonished, counselled, re-trained, instructed, and
so on.

I have also been congratulated, celebrated, awarded, and recognized by
others for my help and advice.

I have no issues or problems with my management, and I value their
opinions, and advice. We have vey open communications at Xilinx.

As Peter said, Xilinx is not a dictatorship.

If you feel I am doing something wrong, then email my boss and make him
aware of your concerns.

The newsgroup is read by many internally, and I post knowing full well
that Wim may be reading it. Fortunate for me, he also has a sense of humor.

There are unpardonable sins (for which you are dismissed), and it is
very clear what those are. And those all relate to issues that are
either ones where you break the law, or are giving away Xilinx IP and
secrets. As a member of Xilinx' patent committee (I read every single
disclosure) I am extremely sensitive to those issues, and help police
our IP.

There are also guidelines, and one of my favorites is the customer is
number one, top of the list. I created the Xilinx fast action response
team procedures for acting on unsolved customer issues, and was the
first "Fire Chief."

I have been in rooms with CEOs, CTOs, CFOs, and so on.

I don't take any disrespect, and I tell the truth.

So, just because the customer is number one, doesn't mean I accept
disrespect, or abuse. When that occurs, I am not afraid to stop the
discussion right there, call "foul", and attempt to get things back on
track.

And, I do have my own personality, my own sense of humor, and my own way
of communicating (and writing). I accept that it may drive some nuts.

Again, my apologies.

Austin

 

[Peter Alfke]

Yes, Eric, testing is expensive.
But the most important savings for EasyPath are not the reduced test
times, but rather the much higher yield.
The math is really simple: If the "perfect" yield for a specific very
large chip is 50%, then if half of the resources are unused and thus
need not be tested, the yield will be 75%. If 90% of the resources are
unused (happens quite often) and untested, the yield will be 95%.
Always assuming random fault distribution.
This also shows that EasyPath makes little sense when the fundamental
yield is already 80% or higher. Of course there are other cost factors,
like packaging, marking, selling etc. But the fundamental idea is
really clever. I wish I had thought of it...
Peter Alfke, from home

 

[Ray Andraka]

fpga_toys@yahoo.com wrote:

Good points Ray.

John,

It appears to me that perhaps you are assuming the yeild is high, more
than 50% anyway. What happens to your assumption if the yield is more
like, say, 10-20%. It seems to me that the lower the yield, the more
attractive easypath becomes, especially if, as Austin indicated, most
yield fallout is only one defect.

That aside, coming up with an end user test to find and isolate the
faults is not as trivial as it may seem. Remember, the LUTs and other
assets on the FPGA are only a very small percentage of the total
circuit. The lion's share of the chip is dedicated to routing
resources, which are a bit harder to test and isolate than the luts are
for a time constrained test vector suite. The good news is that it is
quite rare for an FPGA that tests 100% good to fail internally in the
field, so once defects are mapped, the map should be good from then on.
still, developing a set of configurations to test every route, every
routing switch box, etc in a device is a daunting task by itself. It is
several times harder if you then have to isolate the exact failure.
Maybe if you have enough spare cycles in your RC system, you can do that
in the background and hope you don't hit a defect in operational builds
before the defect map for the system is completed.

The current tools make this even harder since the user has little
control over the what routing resources are used (there's directed
route, but it is tedious to use and is a largely manual effort), and
even less control over what routing resources can't be used. Granted,
this is a tools issue more than anything else, but the fact remains that
with the current state of the tools, I don't see this as feasible
right now. Yeah, I know, this supports your contention that the tools
should be open.

Look at it from Xilinx's point of view though. What is in it for them?
More software that would need development and testing, more user
support, devices with defects out on the market that could wind up in
the hands of people thinking they have zero defect devices, not to
mention their increased testing and administration cost to even
partially map the defects, or even determine to what degree the part
fails. I can see where the cost of doing it could exceed the potential
benefit. If it were profitable for them to do it, I'm sure they would
be pursuing it. In any event, it is a business decision on their part;
one they have every right to make.

Anyway, it still seems to me that the amount of extra work to manage
parts with defects would cost more than the cost savings in the part
prices not just for XIlinx, but also for the end user.

 

[Hal Murray]

Conversely, what really happens to the devices not originally allocated
to easypath which have single errors. Are they crushed and returned to
the sandbox? Or do they get a second chance at proving their worth, on
the easypath tester?

Why does it matter to this discussion?

Xilinx isn't stupid. They will retest or recycle, whichever is
less expensive (more profitable) overall.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Thomas Entner]

Hello Vladimir,

DQS/DQ/DM-placement is important. The DDR interface requires correct
placement of the LEs and routing to the IOB. Quartus does this only for the
DQ-pins specified in the datasheet (even it would maybe be possible for
other pins as well by the hardware, but the software does not support this).
In my design I had mixed up some DM and DQ-pins (I believed that are handled
equally when I made the layout, but this is not the case) -> 3 of my 32 DQ
pins are not recognized as DQ pins and the design does not compile. (I found
a workaround for the prototypes, but require a layout-change for
mass-production...)

Regards,

Thomas

www.entner-electronics.com

<v_mirgorodsky@yahoo.com> schrieb im Newsbeitrag
news:1142694593.123202.188480@v46g2000cwv.googlegroups.com...

Hello group,

I have an issue with porting my high-speed DDR interface to Altera
Cyclone II device. As far as datasheet says, Altera Cyclone II device
does not have any dedicated circuitry to support DDR signaling in its
Input/Output blocks for DQ pins. The only thing present in hardware is
the clock delay circuitry on DQS pins. All other DDR logic is
implemented using LUT's and triggers from adjacent Logic Array
Blocks. So, it seams that we have only DQS pins location fixed,
whenever all other DDR pins may float within the selected IO bank. Is
that right? If yes, then what is the reason to denote certain pins on
the Altera Cyclone II package as dedicated pins for DQ input/outputs?

With best regards,
Vladimir S. Mirgorodsky

 

[radarman]

Check out Digilent's CPLD boards. Yes, they are some of the smaller
versions, but they are still better than a 3042 - and you can use the
webpack to program them. (they have a standard Parallel 3 style JTAG
port)

http://www.digilentinc.com/Products/Detail.cfm?Prod=CMOD&Nav1=Products&Nav2=Accessory

Note, these boards are in a 40-pin DIP package - so you can breadboard
them, and then socket them later in a PCB. At $18/each you almost can't
go wrong.

I haven't used one myself, as I was able to snag a Spartan 3e sample
pack - but the specs on these chips are not bad. I'm seriously toying
with one since I need voltage translation anyway, and I could throw
some logic in as a bonus