Small, fast, resource-rich processor

Xilinx published info on how to do this at one time. I don't have a link. It may have used the SRL or some other proprietary feature of their parts and may not apply generally to other brands.

Not much. The 387 shipped two years after the 386, and had several times as many transistors as the 287. It was also about three times as fast per clock as the 287, and clocked nearly three times faster to boot. It also had a 32 bit interface to the 386 (at least the DX versions). In practical terms it was about 8-9 times as fast as a

Oh, I see, you want to make a something like an FPGA evaluation board, rather than products built around FPGA's. I think there are already evaluation boards from the FPGA vendors, though they never have quite the right stuff on them.

Well, the gadgets that I mentioned are things I've been interested in and would possibly buy. I probably wouldn't use an evaluation board without FOSS tools, unless someone was paying me.

So we agree, the closed-source FPGA tool regime is preventing good ideas from being implemented.

Unfortunately probably true.

Well the "you don't need the data we do not want to give you" is not a very viable kind of excuse, you know.

I certainly do not believe they have ever made it possible to put something into the FPGA which would be able to alter (and thus preload over a user defined link) the logic put inside via their "offical" (and encrypted IIRC) interface.

Isn't that what is already happening with, for example, the Zynq devices? Dual core ARMs, memory interfaces, all sorts of i/o interfaces from

I'd rather bet on the XMOS devices to "cross the chasm". Their programming model is more familiar and they have financial backing, and you can buy their boards and chips from digikey.

Don't put words in my mouth. You can't implement your idea because the idea is to not use the tools. You can skin the real cat in other ways which you choose to ignore.

So are you ready yet to learn about FPGAs and get some real work done?

I don't see this as anything remotely like a paradigm change. They are just integrating some hard cores onto the die that are already used outside the die. I'm saying that the nature of the FPGA fabric will change from simple LUTs with *tons* of interconnect to something fundamentally different. Xilinx used to say we sell you the routing and give you the logic for free because even with the XC4000 the routing was a larger percentage of the chip than the logic.

There is nearly nothing special about the XMOS device that makes it remotely a replacement for an FPGA. It is a multiprocessor and a very limited one at that. From what I have heard about it, you can't expect it to ever scale to more than 16 or maybe 32 processors.

The GA144 has numerous warts but the basis is of value. Make the cores very small with just a small amount of memory on each one, not so much different from a LUT in concept, but much more powerful. More work needs to be done with the interconnect and *tons* of work needs to be done with the software.

Ok, stick your head in the sand... Doesn't matter to me.

The bitstream is not encrypted unless you want it to be.

I'm not talking about the FPGA vendors, I'm talking about the idea of putting an FPGA compiler into an embedded system. Not at all realistic or practical. So yes, I guess I am saying this app does not justify a need for FOSS tools for FPGAs.

None of this matters. FOSS won't happen with FPGAs until the vendors support it. There is no significant market asking for FOSS tools so they won't spend time and money to support it.

It ain't gonna happen, why worry yourself with it?

I answered your question. If you want to change the question, that's fine, but it would be considerate to do it explicitly.

That depends solely on one definition of why you might want/need to use an FPGA. Clearly there are others

Horses for courses.

All (multi)prcessors are limited. So are FPGAs.

They've already got 32 cores. They aren't going to scale to thousands, but so what.

The GA144 is in a different ecological niche. Whether that is a useful niche is currently undecided.

I didn't ask a question... but you did. Reread the above.

The GA144 is not too far from being a processor equivalent to an FPGA. The XMOS is nothing remotely like that. What is your problem? I'm just trying to discuss a topic. If you don't want to discuss this, fine.

That precludes it from being like an FPGA. That *is* the point I was making that you seemed to be responding to. Maybe not. Are you on a different topic?

Different from what? I don't know what you are talking about.

At least two people have learned something in the same Usenet thread - that's rare indeed!

The "least" types are not really very useful, unless you are writing code that has to be portable across architectures with different minimum data sizes (typically awkward DSP chips). For all other modern architectures, the "least" types are the same as the "intX_t" types.

The "fast" types are more useful (though not necessarily more /used/ - most people stick to the fixed size types), as they will often change between different architectures.

mvh.,

David

Yes, and the reason it's impossible to not use the Xilinx tools is because of the secret formats. Fix that, and the problem goes away.

This guy makes the case for FOSS tools better than I do:

I don't claim he represents a huge part of the FPGA market, but he is making real products with them.

He mentions that the no-fee version of the Xilinx tools connects to a Xilinx server and uploads your designs. I'd want to avoid using anything like that. So if I were to use Xilinx tools at all, I'd have to look into the paid versions, which sound expensive (I'd be interested to know).

Here's a presentation (url from a comment on the above) about some guys trying to make FOSS tools by reverse engineering the formats:

I think that approach may get more difficult as more hard cells (ARM cores etc) find their way onto FPGA's, though.

I do real work every day, and get paid for it. I hope you can say the same ;-). FPGA's are one of many outside interests that I like to be a bit informed about, but that I don't have time to get heavily involved in.

The Elphel 393 camera (when it comes out, if it's affordable) might tempt me to want to program it, but it sounds like I'd have to use the paid Xilinx tools, which is a pretty significant disincentive. It's described in earlier posts on the blog linked above.

What problem? I don't have a problem.

I didn't see much of a case. It is all just his opinion with no real facts that don't relate to a Soviet Union analog.

That is an extreme exaggeration. The tools work just as well disconnected from the internet. From the Xilinx web page on this...

Can I use WebPACK software on a machine that is not connected to the internet? Yes. WebTalk does not prevent design compilation on a machine that is not connected to the internet.

So you can simply disconnect from the Internet when you run the Xilinx tool.

Personally I find this level of snooping to be insane from a business perspective. I'm sure there are any number of users who will strongly object to it. Great reason to never use another Xilinx part again regardless of FOSS.

I don't really care. They are trying to solve a problem I don't have.

Obviously not with FPGAs.

No, it should be supported by the free tools. He said that in the blog.

Other people do have a problem with that, though.

I remember quite well a thread from some 5 or 10 years ago on comp.arch.fpga based on people having caught the xilinx tools do as alleged.

Nor does it store the details for subsequent transfer over the net? Ah, but you don't know that. Me again asking silly questions.

Dimiter

_Assuming_ this is a accurate description of the situation, then that's just _totally_ killed my interest in Xilinx.

What I don't understand is why people tolerate this. Is it because it's not made clear to them what's going on, or is it simply because they have no choice ?

Could you imagine the outrage if it turned out that, say, Microchip's free toolchains uploaded a user's project to Microchip and that the only way you could work around it was to use their tools while disconnected from the Internet ?

If Microchip did something that daft, it would kill the use of their tools stone dead.

Simon.

My memory on that is vague, what I remember is that xilinx had been denying the issue first, then claimed the data were "immaterial" or something in that line and eventually I think deleted the caught feedback thing.

Even if todays tools work on a non-netowrked PC (where "work" may turn out to be more than "compile" - which is what they state) this still means the added cost of a dedicated PC. Then copying to/from that PC should never be done under any form if one wants to guarantee the data won't go out, no flash sticks, nothing. So much about the "free".

No idea, I suppose most of them just don't care. I have no issue with much of my designs going out either, not so long ago I did use a xilinx (ABEL) tool to program a CPLD; the jedec file is even available on the net (not directly but as a file on an installable DPS disk image).

But there *are* things I would not let into public domain, e.g. the spectrometry DSP conversion algorithms. And an FPGA being large enough can contain some of the things I would not leave out. Then while I did compromise with ABEL once - for a simple 128 cell CPLD - I am still completely independent on other software in my design process, that is if all wintel etc. machines disappear I can still go on as usual. Minor headaches because of that yes, I do use a PC as a .pdf reader and as a browser, but nothing major. I might still use an fpga on their terms, e.g. there is just

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------