Slashdot Mirror

It's not a book, but this book chapter is more-or-less compulsory reading for someone planning to get into HDL programming:

A structured VHDL design method

http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=338&Itemid=231

"The LEON4 pipeline uses 64-bit internal load/store data paths, with an AMBA AHB interface of either 64- or 128-bit. Branch prediction, 1-cycle load latency and a 32x32 multiplier results in a performance of 1.7 DMIPS/MHz, or 2.1 CoreMark/MHz."

there's an excellent overview from 2009 of the LEON4 architecture, even if it's just the abstract of a paper, try googling this:

Next Generation Multi-Purpose Microprocessor
  Abstract for Presentation at MPSA, 4th of November 2009

hope that helps.

What's the problem, there are open source SEU tolerant CPUs you can use out there

http://www.gaisler.com/cms/index.php?option=com_content&task=section&id=4&Itemid=33

Leon FT, space grade, VHDL IP cores available.

It doesn't really matter whether you choose VHDL or Verilog as long as you know what your synthesis tools are doing. Both languages are very different from C or other compiled languages in that C allows you to assume that statements will occur sequentially (and yes I know that statements may be re-ordered behind the scenes such that they don't break dependencies) whereas neither HDL will give you that guarantee. In fact, unless explicitly stated, HDL statements will all execute concurrently (and certainly won't wait for something like a clock edge).

Now here comes the important part. You can write VHDL or Verilog such that your design will simulate perfectly (even without using simulation-only constraints like after statements in VHDL) but fail miserably when synthesized for an FPGA. In my experiences, this has almost always resulted from latches being inferred by the synthesis tools. This is where you need to know a little information specific to FPGAs; namely, code using latches offers no benefits over code using flip-flops when dealing with FPGAs. Much of the time, synthesis tools will just set up a combinational loop in the hopes that such latches will act as a they should (they usually won't) because most of the basic blocks that comprise an FPGA utilize flip-flops, not latches.

If you're interested in a good source describing how to write VHDL for FPGAs, I'd suggest looking at Jiri Gaisler's method: http://www.gaisler.com/doc/vhdl2proc.pdf

Also, avoid statements like: if clk'event and clk = '1' then .... end if; when statements like: if rising_edge(clk) then .... end if; work just fine (and are more readable).

This doesn't sounds so extremely new to me. You can even download the vhdl to a rad hard Leon3 (SPARC V8 instruction set) at gaisler here. This chip covers SEU (Single Event Upsets) typical of those caused by cosmic rays.

This doesn't sounds so extremely new to me. You can even download the vhdl to a rad hard Leon3 (SPARC V8 instruction set) at gaisler here. This chip covers SEU (Single Event Upsets) typical of those caused by cosmic rays.

Then you need $2000+ PCBs to fit those FPGAs, $100k in software licenses (PCB design, FPGA design, etc.) and over $1M in lab equipment to test/debug the setup.

People like to take shots at the x86, but it is hard to deny that there are brilliant people working on it, really making implementations that fly. Intel's development team has a long proud history (they pretty much single-handedly turned the perception of CISC/RISC around with the Pentium Pro after all), and the AMD K8 team looked suspiciously much like the Alpha team at one point.

That is not to say that the POWER4 and derivatives are not impressive, they are, but the performance of chips like the AMD K8 really proves that if you have a competent team small details like the ISA don't matter all that much. I see no easy way for IBM to sneak into China, and it is actually a good thing; We are all better off with:

- The x86, which has more healthy competition going on with several high-profile implementations well suited for desktop use.
- MIPS/ARM, widely licensed and implemented architectures. The architectures are even cleaner than the PPC and SPARC.
- The SPARC, completely open and royalty-free, lots of implementations. This includes a series of LGPL/GPL VHDL implementations from Gaisler Research.

In summary, having some PPC around is nice, but having it take over a market would be a bad thing at this point.

I once read in an older post on /. (sorry can't find it) that the European Space Agency has implemented a hardened Sparc implementation based on the standard. Sad that the article fails to mention it completely. Here is an interesting link though. I heard those puppies can work under radiation levels that would fry a normal UltraSparc. If anyone has more information that would be very nice.

[rant]And what's more sad is that we are getting to the point where the x86 has become almost a monoculture, which is way very bad. Apparently there are lots of folks who think that the only processors around are named "pentiums". [/rant]

The SPARC V8 spec is open, there's also an open source implementation: the Leon and it's supported by Linux.

But isn't SPARC (the standardized part) only an instruction set?

Nope. The whole chip is available. Sun used to have a PDF of it available for download, but that may have gone the way of the "Free Solaris Source" program.

MIPS is also an architecture that is commonly licensed by third parties. It's used everywhere from set-top boxes, to video game machines, all the way up to SGI IRIX machines. In fact, the many incarnations of MIPS probably made MIPS the *most* successful processor in history.

History of MIPS
History of SPARC
LEON2, an LGPL processor based on SPARC technology

Sun should licence their processor design (at low or no cost) to create competion to create a SPARC-comaptible marketplace. If they really have been converted to open source they will soon realise that they cannot make money from selling software.

Here you go:

The LEON2 processor is a synthesisable VHDL model of a 32-bit processor compliant with the SPARC V8 acrhitecture. The model is highly configurable, and particularly suitable for system-on-a-chip (SOC) designs. The full source code is available under the GNU LGPL license, allowing free and unlimited use in both research and commercial applications.

Having been involved with space work a bit the software aspect of the Beagle lander is quite interesting - the reason I know about it is we used the same compiler on the Galileo signal generator project.

ADA is still very popular amongst the European space companies and agencies (for a good reason I think) and particularly the ADA95 Ravenscar profile which gives a miniscule runtime the actual runtime is only about 4-5k which is pretty good considering that contains everything you need to execute the ADA code including tasking.

There is another opensource attempt at a ravenscar compiler called openravenscar funded by ESA here - for Sparc and Intel platforms . Ravenscar is basically a profile that removes the more complex features of the ADA languages to give a mathetmatically provable scheduling - so you can always cater for your worst case scenario. Such small executives are neccessary due to the prohibitive cost of rad hard EEPROMs as most missions have some sort of inflight reprogramming requirements. I think they are using the ERC32 processor which again, is an open source processor, along with its replacement LEON, you can even download the vhdl for the Sparc based leon here

Heres hoping Beagle makes it through the Martian atmosphere and takes some pictures of little green men.

Sorry, I didn't see the later link about the Leon processor. That does indeed appear to be open source. Simply linking to SPARC, however, doesn't provide much information about the available open source implementations of SPARC.

Have open-source cores been available to implement those specs been available for a LONG time?

For quite awhile, as I understand. The Leon chip is an example of this. Other areas such as Fujitsu's processors and set top devices have been based on Sparc.

I'm not saying that OpenCores is a bad thing. I'm just refuting this "we were here first" bullshit.

This is indeed a good step for the Opencores project, but the subject itself is misleading.

The LGPL'd SPARC-compatible processor Leon was put to silicon a long while ago.

Give credit where credit is due, the Leon tracked over this territory years before OpenRISC.

I think that someone else has been there and done that already using this sparc compatible core. The sparc core can be used to create either an ASIC or FPGA.

I did not finished this project, but I'm sure there's other somewhere like me who tried and maybe a couple succeeded.

The European Space Agency has made available VHDL for a CPU that implements the SPARC V8 instruction set. The VHDL is available under the GNU LGPL license. Granted, implementations of LEON are slow (25 MHz?) but it's totally freely available. You may need to buy a $99 license from SPARC International to actually sell any CPUs you make, but that's pretty cheap.

The SPARC instruction set is pretty simple. I don't imagine that a similar effort for x86 CPUs would be as simple or as quick.

anyone who has anything to do with a standards body nowadays know's that people try and hijack standards so their tech/patent gets into it

this way if you implement the standard you have to pay

you can't have an opensource MPEG 4 without paying 3million bucks when you distribute it and they call that a standard

ok real hardware and software

in terms of a kernel their is in My Humble Opinion

Linux

Open BSD

netbsd for every arch under the sun (joke included)

then we have the problem of hardware

Opencores provides some of the effort BUT my favorate is

LEON-1 VHDL model
- Functional SPARC compatible processor core integer unit. Runs on Altera, Mietec, Temic MG2, Xilinx. Developed for space missions. Implemented as a highly configurable, synthesisable GPL VHDL model.

Altera 10K200E FPGA or Xilinx XCV300 enable this you can also get a LCD and keyboard AMBA devices from www.gaisler.com

what I would like is a machine that you could say that the whole thing is opensource

regards

john jones

Seems pretty open source to me, they even have a shot of the sim running on KDE.... pity I use GNOME

A direct quote from the article:

"LEON was initially developed by Jiri Gaisler while working for ESA, and Gaisler Research is now working under ESA contract to maintain and further enhance the model."

The processor was developed under open-source methods by an independant company for the ESA.

The LEON model also exists in a fault-tolerant
version, capable of detecting and correcting
single-event upset (SEU) errors in any register
or RAM element. This is done completely in
hardware without any software intervention.
The area overhead for the fault-tolerance
functions is approximately 30% while the timing
penalty is around 5%. The fault-tolerant features
makes it possible to use LEON in the severe
space environment without having to develop specific SEU-hardened cell libraries. The LEON
fault-tolerant VHDL model can under some conditions be licensed from ESA -