looking at the big picture, I fully agree to use it right now, but in the very long run, if you want 100% freedom happiness, someone has to probably replace it with a new core that is GPL licensed from day 1

I don't think Lattice will touch the license or clarify anything, because too many people in the industry are already using it. If they would change just a few things, many people would be worried about their intentions.

but in turn I'm not sure there would be enough hackers around to buy that free CPU just because it's free, and a cheap ASIC needs huge volumes - and you are already whining about the price point of Milkymist (VJs find it "cheap for what it does") ...

lekernel: I wasn't thinking it was a netbook. There is a lot of other talk of what it can do besides VJing, and I'm interested in what people hack it into otherwise. I made a passing mention of the MMU, but looking at uclinux it isn't so much of a big deal especially on a 'slow' FPGA(what you said). ASICs are out of the question, but I would be one to buy a free CPU based around that design - I don't

lekernel: And to be sure - I was not whining about the price. Just my wallet. The EDK is extremely reasonably priced, and is way cheaper than the 1k~ USD for a PCI VGA GPU put down for the open graphics project.

lekernel: by the way, on the day of the /. article, someone showed up and mentioned that there were some items that had not been converted from async to sync (or was it the other way around), which he said could confuse simulations. alas, you were nowhere to be found. did this information eventually reach you ?

but I guess he was talking about using blocking assignments for communication between synchronous "always" blocks, which is a problem that makes verilog suck badly and did not really want to spend more time working around

the whole algol language family is quite suckish. they're languages that try to constrain you. i like the C approach much better: anything goes, and there are tools (starting with the compiler itself) that tell you where you may have made a mistake

lekernel: (crown jewel) i find that article quite confusing. isn't this rather a case where you try to cram the effect of two clock edges into a single edge, and somehow expect your synthesis tool to figure out what to do ?

working with concurrency is something that's a standard problem in protocol design. there are simulation tools for that. e.g., the SPIN model checker, with takes models in the C-like Promela language, and checks properties you specify

e.g., in C, if you do a = 0; b = 1; the compiler is allowed to swap the two assignments. or if you do a = 0; a = 0; it will be more than happy to remove the second assignment. or maybe even both assignments. of course, all this causes trouble if a and b happen to be some i/o registers, i.e., if you these assignments have a side-effect