Small, fast, resource-rich processor

The internal structure of CPLDs and FPGAs is, of course, antithetical since they are based on different architectural principles. With CPLDs there is very little latitude over where things are placed and what the timings are - that's a principal advantage of a CPLD over an FPGA: predictability.

Hence I don't think your experience can be translated to FPGAs.

(And if it was, the routing algorithms are highly non-trivial except where the device is mostly unused)

Reply to
Tom Gardner
Loading thread data ...

So, IOW, there is still no movement towards open specification FPGAs at all (not even from, say, a manufacturer moving into the FPGA market for the first time). I suspected as much, but thanks for the confirmation.

What do you mean by "open" in this context ?

For me, a open source FPGA board would be one in which you could (1) create your design, (2) compile the design into something the board can run and (3) load your design into the board itself all using tools which you could compile from source.

IOW, the same as you can do with traditional toolchains where you can (for example) compile gcc, binutils and OpenOCD all from source because the traditional manufacturers (mostly) make the required information for their MCUs freely available.

BTW, do you have any examples of the boards you are thinking of please as I would like to take a look.

Thanks,

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

I have no direct knowledge; my statement is based on intuition. If there's a solid reason my intuition is wrong, I'd be curious to know.

But frankly, who cares if the boards are open source? (Any more than anybody cares whether PC motherboards are open source).

I don't mean anything. See the definition provided by each *board* manufacturer.

Use google, and have a look at papillo, pipistrello, xula, mojo

Reply to
Tom Gardner

True for measurements, not true for floating point. 2.0 * 2.0 produces

*exactly* 4.0 in floating point on every machine I've ever worked with. So it is not *always* approximate. I assume you are stating this in contrast to integers where you should keep the range of data within bounds of the integer yielding exact results. But of course that is the problem, because of the limited range integers become very limited in use. Then there is fixed point which can be calculated with integer operations, but in fixed point it is not uncommon to truncate multiply results making the answers *approximate*.

So I fail to see your point really.

The only problem with integers is they just won't do for many calculations.

Really? That would be at a minimum (assuming you check the different fields separately, 2**n where n is the sum of bits in two mantissas. Were these very *small* floating point formats? Even 20 bit mantissas require a trillion tests to verify all possible mantissa combinations.

--

Rick
Reply to
rickman

There *are* open source HDL compilers for FPGAs. The problem is the complete toolchain requires a place and route tool as well as a tool to generate the exact bitstream output file. I think both of these require info on the chip the vendors do not share.

bbPlace and route is a very difficult task anyway and requires a lot of insight into how the device works and is intended to work.

The bitstream format is just plain proprietary to restrict use of their tools. I don't know why exactly. I expect they are all afraid of a level playing field, or more likely recognize the importance of good tools and feel losing control of their tools to open source might compromise their reputation from an *unlevel* playing field.

I do know that at least one vendor claim copyright on the bitstream and by using their tools you can only use it with their chips. I guess they want to try to lock in any direct bitstream to ASIC revenue. A startup company providing that service went under when they lost a lawsuit about this. So you have to recompile your source instead.

--

Rick
Reply to
rickman

I don't understand the problem with JTAG programming of the device from your board. This is a common feature used in many products and it does not require reverse engineering of the chip. It only requires the use of C code provided by the vendor. Why did you need special data? Does Xilinx not provide the example code to program coolrunner parts via JTAG? They (and everyone else) provide that for every part I have looked at.

--

Rick
Reply to
rickman

First time in the FPGA market? Uh, there *aren't* any. FPGAs is a market where the big guys have managed to patent up the technology and keep pretty much all newcomers out of the market. I think there is one new company working with Intel using their 22 nm fabs, but I don't recall the details. Seems they stick their heads up every now and again to make some announcement, but promptly go back underground. They are targeting the high end of the market anyway, so it doesn't impact me and likely not you either.

Open source tools sound great to an open source user, but not so much to anyone else. It just doesn't fit the business models of FPGA vendors now or in the future. Trust me, business models are the reason why you don't find FPGAs in easy to use packages and lower pin counts. The business plan is to target the large volume customers only and they don't need these combinations. They certainly don't need open source tools!

That may be what it means to you, but you will have to write the software. Open source hardware is just that, open source *hardware*. They give you all the info you need on the hardware... they aren't supplying software.

If you are going to get hung up on the FOSS thing, then just don't bother with FPGAs. It ain't happenin' any time soon... period!

MCUs are not FPGAs. MCUs have fairly simple instruction set compared to the data required to describe an FPGA. Further, the MCU FOSS tools are fairly mature and capable. FPGA vendors aren't interested in turning their reputations over to open source techies because of the FUD on

*their own* part.

I know there is an ORSOC open source FPGA board for running processor designs I've seen on the opencores.org site. Go to their store. It is intended to run the OpenRISC processor, but of course can run whatever you like.

There is also one on KickStarter, I don't recall the name. This one is minimal.

What features would you be looking for?

--

Rick
Reply to
rickman

Actually, it is a bit hard to *not* be open source, at least at the net list level. It is hard to use an FPGA without netlist info on the board. A schematic is often provided although usually in PDF form, not a CAD package form. You may not get Gerber files, but you can always clone an FPGA board unless it has some proprietary MCU or something on it with firmware. Many now use the USB/JTAG chips that are just plug and play, so not much to clone really.

I'm a bit surprised there isn't a web list of FPGA boards. Maybe this is worth a little effort.

--

Rick
Reply to
rickman

Uh, it takes 10 minutes to read the article if you include looking at the code. If you don't know anything about the article how can you possibly have an informed opinion of the tool?

Yes, that is my point. The above is *just* your opinion. Nothing more. Not even an informed opinion.

--

Rick
Reply to
rickman

Yes, but that's only part of a board's design, as I'm sure you're aware. And for those that aren't, give just the netlist to a novice PCB designer, and see if the result works reliably :)

Nowadays if I'm going to buy a board I like to see a definition of the nominal track impedance, track lengths (for differential i/o), and where gnd pin*s* are on the i/o connectors relative to the signals. Quite a few boards have, IMNSHO, connectors with far too few grounds.

(There's a low-cost logic fpga analyser out there that has an external clock arriving at a 4-pin header. There's *no*m gnd on that header)

There are several, easily googlable. How up-to-date they are is a different issue.

Reply to
Tom Gardner

You mean not informed like your opinion here? May be, may be not. Like I said it is up to the reader to find out.

Dimiter

Reply to
dp

Unless things have changed last few years they certainly do not provide the fusemap data saying which bit from the jedec file goes into which bit in the jtag stream, which jtag commands to issue to the chip etc. I thought meanwhile you would be aware of that? What C code, where is that C code supposed to go and what is it supposed to be doing, how many PC-s do you want the cpld user to have stitched to a single board/cpu system.

Dimiter

Reply to
dp

This is also amusing (and frightening).

formatting link

Those that claim something along the lines of "it is OK as long as you make sure you have a good algorithm" should read all of that before making such pronouncements.

Reply to
Tom Gardner

Surprisingly few, in my experience. It is usually just _easier_ to write (double) floating point code.

Do not neglect the fact that, with double floating point, you're throwing around 64 bits of data. 64 integer bits is a whole lot - more precision than a double (which I believe has already been stated).

--
Randy Yates 
Digital Signal Labs 
http://www.digitalsignallabs.com
Reply to
Randy Yates

Yes, I figured as much...

It's not so much the software which matters but the specifications which allow you to create that software yourself if you so desired.

Everytime I look at the FPGA world, I come away with the exact same impression. :-)

Nothing too fancy, at least to begin with. FPGAs are a new area for me, and it's something I would like to play with sometime. It's just that I would like to learn the technology rather than the tools driving the technology but at heart I do realise that isn't going to happen in FPGA land any time soon.

It doesn't stop me from looking, asking, and wishing however. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

Some of the FPGA bitstream formats have been reverse engineered: a web search should find some info. There are FOSS place and route tools but they don't generate bitstreams.

Reply to
Paul Rubin

Another thing to point out: the place and route tools used by Xilinx and Lattice were developed by NeoCAD- a company which reverse engineered the Xilinx format in ~1991, did a better job than Xilinx's own tools of the time (apr) and got bought by them.

--
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */ 
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) 
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p158?-79:0,q?!a[p+q*2 
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Reply to
Joseph H Allen

That's interesting; I didn't know that. Thanks for that.

I didn't know that as well.

That's one of the reasons I like open source; people are always been pushed to do better as you cannot sit on a closed source toolchain and then use your market position to stifle innovation.

Simon.

PS: I'm _not_ trying to start a closed/open source discussion here; I just didn't know about NeoCAD.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

Precision and range are two different things. There are times when more range is required than even 64 bits provides. That is actually the

*only* reason for using floating point, to get the extended range provided by the exponent, no?
--

Rick
Reply to
rickman

No, they provide a file output with JTAG commands. One form is called a JAM file. I haven't done the interface myself so I'm not familiar with the specifics, but I have looked at the support provided by the vendors and you don't have to invent any wheels yourself. Like I said, they even provide C code which you simply have to provide the low level routines to control the hardware pins, usually bit banged from an MCU.

What do you drive the JTAG interface with in a remote, embedded system? If you don't have an MCU what do you have?

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.