Hi, I do not know anything. Last time I worked with a schematic, transistors were one to a package! But I have some recent interests in "softcores"? from a "trusting trust" and general computer security point of view. (I do have a masters in software engineering, so I might have some experience with software.) Aside from the thought that the verilog code is "visible" to me during installation, I am amused by the possibility that every computer could have a set of op codes that are sort of unique in action or at least not known to the random internet malware author. (I like to compile my code.) And it looks to me that there a couple of order of magnitude more fpga manufacturers to chose from than cpu manufacturers. So I thought I would play. It does not really seem to cost much.

I have in the past in software noted that being dumb as you approach a project learning curve generates pointers to interesting doc issues. Figure that on one hand if I am dumb enough, I might come up with questions whose answers are not in the doc, but everyone else just knows the answer. And since if I were very successful in this project, a lot of people might find it useful to do a bit of fpgaing, it is good if I document the questions and answers I come across.

So I intend to do some doc. Any results will amuse some of you. I suppose the first substantive parts would be my comments on some books I just ordered that deal with openrisc. Keeping the tech simple, I thought I would just post to this thread. So here I create it. If there is something interesting in this thread a year from now, then we can all be a bit pleased. And if there is nothing useful here, then this thread is nevertheless not a great imposition on the site.

So here is my project plan so far:

read some books (amazon titles that come up on openrisc search)
set up a linux box and download the tools (ubutnu of some specified version?)
get a fpga (looks like a sparta 3A dev kit from avnet for $189USD)
install minisoc project on the fpga
get it to boot something
end of first phase

Silly me. This looks like pretty much like a system admin job. Hey, we got some cables to plug in, we need to install some unixy software and do some scripts. What could go wrong! Giggle.

Sounds like fun.

You may want to consider keeping a log of your experiences as you do this and then post it when (and if) you succeed. You are the ideal candidate that opencores is trying to serve and such feedback is invaluable.

I also want to see if you install the new openrisc tool chain. I still haven't figured that one out myself.

John Eaton

Thanks for the encouragement. On the other hand, my attention is just do the log here in this thread, unless I get explicit discourgement.

First entry:

The acronyms are all going to have to be looked up. So on the avenet ordering page we have:

NCRN: easy to figure out no cancel no return
RoHS: a EU hazardouss materials regulatory system
ECCN: US export controls systems coding

The last is fun. If you deal with encryption software, you know not to bother to try to export from the US. It comes to life as a controlled munition and why bother. In an OSS world, mostly you cannot even work on encryption software. No ones wants to bother. So, if you lawyer up, and think the government is a trustworthy partner, maybe.

Fun, looking at hardware, you not only have to lawyer up, but hire really techie lawyers, and this is just for bare-bones hardware, god forbid it has some sort of interesting end-user functionality. So, give up now on any exporting of anything. Hah, did you know that solar cells, the greenie stuff, is some sort of potential weapons system component, and if it is the really good stuff, you have export issues?

Insert political rant.

I think you can also get the spartan 3E starter board from digilent (www.digilent.com). They build that board along with a line of product targeted to the education/development market

John Eaton

Thank your for the suggestion. However, I had ordered already from avnet. Got the kit in six days and I am surprised to see so much hardware. And the board happens to be made by the company you cited. I did not expect the lcd and all the connectors I can see through the anti-static wrapping. Which brings up a real question, rather than a musing: It reminds me of a motherboard. The last time I spent time handling motherboards, they were big-time cmosy and I felt obliged to wear a anti-static grounded wrist band. So, do I really need to do that here too?

As far as the two board kits, I am incapable of doing a useful comparison between the two items at this time. I suppose I will be able to do so eventually, when I am more knowledgeable. I do note that the firm you cited to has an academic pricing and I understand that if you order on their web site, the ordering process picks up your claimed bonifides. These are then checked and approved or disapproved. I suppose that would take some time.

Thank you for your consideration.

http://www.intel.com/Assets/PDF/pkginfo/ch_06.pdf

Useful about static (ESD). So the higher the logic density, the worse the problem, so I figure as compared to 20 years ago, the problem is worse. And, great, it is not just that you screw up and the device is all the sudden junk, but instead you can have intermittent failure modes in the future. So I guess a strap and a pad are needed. As far as straps, I figure one ending in an alligator clip and with no metal pad on the strap, meaning the strap is itself conductive. Put the clip on a ground. I figure a nearby plugged in computer case.

Hey, I got the amazon books I ordered. Two books, say under 40 pages each, maybe 50 cents US each page. Pretty pricy. Looks like they are print on demand and from wikipedia. So what I have is a list of soft processors with wikipedia text. Since the processors are not famous brands, I figure it is useful to me. On the other hand, I will just list the names here and the next guy can just goggle around.

Nios II
Microblaze
Openrisc 1200 (hey, our goal)
picoblaze
latticemico8
latticemico32
Nios embedded processor
ARM architecture
Transmeta Crusoe
Geode
Via C3
Leon
Via C7
Snapdragon
Ensilica
Tensilica
Openrisc
Vortex86

I expect most can be licensed. And I expect many will have a license tied to using a particular brand of fpga. And I supposed development might involve closed software. So, aside from money issues, closed software and limited choices in fpga are strong negatives. The mini soc advertises itself as workable on many different fpga, although I would expect to suffer if I tried to actually test this.

Realize I like paranoia, and I suppose there are several reasons the NSA has its own fab, But if I could implement a single design on diverse fpga, then I can fuzz them exhaustively and see that they all behave the same. Hmm, reference David A. Wheeler, as applied to compilers. But I have no clue of how a manufacturer would be able to mousetrap a fpga.

Check out http://blog.ksplice.com/2010/10/hosting-backdoors-in-hardware/, but be sure to read the last paragraph to stay sane.

hmm, on why you might want your own cpu design,

An anonymous reader writes "A hidden (and hardware password protected, by means of required special values in processor registers) debug mode has been found in AMD processors, and documented by a reverse engineer called Czernobyl on the RCE Forums community today. It enables powerful hardware debugging features long longed for by reverse engineers, such as hardware data-aware conditional breakpoints, and direct hardware 'page guard'-style breakpoints. And the best part is, it's sitting right there in your processor already, just read the details and off you go with the debugging ninja powers!"
Read More... 37 comments

And the comments talk about the jtag interfaces sitting on most everything. And the comments talks about unexpected logic blocks on just about everything.

More usefully, I kindled Reconfigurable Computing: The Theory and Practice of FPGA-Based Computation (Systems on Silicon)

I thought it was the right trade off for me between really current publications (+100USD) and older material (+30USD). Happy with the book so far. I might know what a LUT is now.:-)

On anti-static pad and wrist straps, this stuff is really pretty cheap. It seems to me that when I last looked the pads were pretty expensive. Maybe a small pad is now about $25USD and a wrist strap $5USD, The wrist strap came in, but for some reason the pad has not showed up yet.

On the last book, mostly of low value for me, but still useful. There are several threads I will attempt to gloss.

History is that there were fpga in the 1970's, but very little in the open literature. By the mid 1990's, FPGA had enough capability to be an interesting product, commercially and academically. The book is at best circa 2003. Now the difference between a FPGA and ASIC blurs a lot by now, but figure the FPGA can be repeated reconfigured, but the ASIC is write-once. Also, where the reconfiguration capability takes up area (a major cost parameter), the ASIC "antifuse" (a fuse that when it is blown, it makes a connection) is very compact. Thus for any volume, ASIC is going to be cheaper. And faster. Significantly faster. Except remember all that research in the 1990's? The academics were interesting in dynamically changing the FPGA configuration during application execution! Think self-modifying code. And as compared to a commodity CPU, the FPGA/ASIC needs to be a couple of orders of magnitude faster, if speed is a requirement, to justify all the extra development effort. Now the way you get faster from slow hardware is to realize that these FPGA's allow massively parallel execution, if the problem space lets you get to parallel. Hah, so another pretty much unsolved problem to be overcome.

Now we think about the internals of the silicon. Suppose we view it as a collection of logic gates and programable connections. Figure 10 times as much silcon devoted to connections as to gates. So figure millions and millions of gates. So you need fancy software tools to be able to design at all quickly, or even possibly. So this has been a big area of research. Now as it happens, the basic unit is not the gate really, but the LUT: Lookup table. Think truth table. If 4 inputs, say 4-LUT. But you end up with all sorts of hetrogeneous structure built in to the silicon, up to multiple CPUS. (Recall that fixed stuff is a lot more area efficient than dynamic stuff.) Built-in memory to hold the LUT outputs, etc, is pretty much a requirement. Now for the fancy software to work with the particular FPGA, with all this hetrogeneous structure, the software has to know about stuff the manufacturer wants to treat as a trade secret. xilint or whatever in the 1990's put out some stuff that actually had documentation and so became the favorite of the academics, at least on limited products. Noter that the fancy software has to be really fancy to come even a little close to what a human could do on the various parameters such as speed and area.

I need to cross-check, but I note that building the RISC 1200 on the board I selected requires the use of a free, but I bet not open, software product.

So how does the FPGA get programmed? Compiler to "netlist" to "bitstream" and load the bitstream onto the board. Figure that every choice requires a bit in the bit stream, so maybe hundreds of megabits. Maybe the bitstream goes in SRAM and has to be reloaded on power on. Or maybe it goes into some sort of flash and stays around on power cycles.

Now if I am after "trusted", obviously closed software and such is not so friendly. Funny thing is that as best I know, everyone takes out their electron microscopes or whatever and reverse engineers everything anybody does anyway. On the other hand, if I am a OEM customer, then I want to keep my bitstream et al secret so the competition does not clone my product.

This book was essentially a collection of academic papers with some glue. Most of it was about software approaches to developing a system.

Here is an interesting point. So suppose you have a lot of silicon, And a lot of software for figuring out how to configure the silicon. If the software takes all day to compile, then even if the resulting hardware executes instantly, it still takes all day to get done, and for a one-off application, this is not usually so good. And the parallelism can get you only so far, because if only 90% of the application can be parallelized, then no matter what, the performance improvement is only 10 times. On the other hand, some sort of key based encryption application might only require reconfiguring the hardware that has to do with storing the key. So the problem space you are dealing in is a big deal.

So, with the development board there came a cdrom. Time to open that up.

Here is a different take on the David A. Wright approach. Suppose you had real specs on software and multiple implementations of the software. Then you might be able to have multiple implementations into hardware. The hardware is on the net. You send the same inputs to all the instances of the software and compare the results. Since the "software" is in the hardware, it might be difficult to change all the instances without physical access to all the locations of the instances. So of course this assume a lot of reliable encryption.

Here is something vaguely interesting to a software guy. There is the category of Hardware Description Language (HDL). The RISC 1200 is written in verilog, which is sort of C, and thus kind of sequential. The alternative, hmmm VHDL?, is a variation of Ada. So it deals with concurrency as part of the language design. Some say VHDL code is prettier that Verilog code. I like pretty.