<kristianpaul>
but cant answer your question with certainly as i never tried emacs on mm1
<kristianpaul>
if thats what you mean :-)
<primary>
kristianpaul: Your name sounds familiar, are you with the FSF?
<primary>
FSFLA or otherwise.
<kristianpaul>
yes, i know some people from fsfla
<kristianpaul>
ha, !! catched and results of my own changes
<kristianpaul>
that last change that adds 1 bit to  CSR is the cause that avoid addressing at 0xf0000000 and beyond
<wolfspraul>
primary: what takes you to Milkymist?
<wolfspraul>
(good morning/afternoon/evening first of all :-))
<kristianpaul>
evening.. 21:22 here :-)
<wolfspraul>
bright sunshine 10.22 AM here
<primary>
wolfspraul: Open hardware that does not require non-free software to run it.
<kristianpaul>
(addresing issues) so that explain why i mess the uart when writing from that addr.
<kristianpaul>
moving gps rec core just before sdram
<wolfspraul>
primary: ok that's a start. What more? What do you want to do with it?
<wolfspraul>
how important is mobility? connectivity?
<wolfspraul>
do you understand what we do with the video synthesizer, and where it could lead?
<wolfspraul>
is the video synthesizer something you can use today?
<kristianpaul>
primary: but no, i'm not part of fsf* that i can speak in name of. Just another other guy in the free software wild ;-)
<primary>
wolfspraul: A video synthesizer is something I could use, but not something I'm that interested in.
<primary>
wolfspraul: I understand to some extent, but not as deep as the thesis paper.
<primary>
Where it could lead? Hopefully it is just a start to open general purpose computing.
<primary>
But not having an MMU sounds blah. But I don't know much about hardware.
<primary>
Mobility isn't anything I care about. Connectivity looks stellar with ethernet, rs232(but I hear that is only for debugging), and gpio and VGA even.
<kristianpaul>
You can add another uart port not for debugging of course :-)
<primary>
Running my daily computing life on an open platform, that is something that is attractive. I'm only a bit more demanding of my machine capability-wise than say RMS.
<primary>
kristianpaul: Unfortunately I'm not a hardware hacker.
<wolfspraul>
ok great, I understand much better now.
<wolfspraul>
yes the MMU is missing, but since it's software it's just a missing feature
<primary>
But I'll wait and see as usual, I'm sure the EDK will progress further and we'll see neat things like there has been on the Ben Nanonote.
<wolfspraul>
there has been some serious thought on how to implement one, in fact _maybe_ some of those guys are already doing this now, not sure
<wolfspraul>
the MMU is not needed for a video synthesizer, so it's not the focus of Sebastien
<primary>
Yeah. I'm fairly conservative with my wallet(since it contains nothing right now), so I will wait things out until it progresses past the 'appliance phase' you might say.
<wolfspraul>
from a pure freedom perspective (just to get it all on the table), even the 'open source' status of the Mico32 core can be questioned
<wolfspraul>
oh totally, relax. I don't want to talk you into buying anything now.
<wolfspraul>
in fact I sold the last m1 I have on the weekend.
<kristianpaul>
;-))
<wolfspraul>
let me explain about Mico32 quick, because that probably interests you
<wolfspraul>
it has been released as 'open source' from Lattice in 2006, but unfortunately not in the cleanest way
<primary>
wolfspraul: Better than the status of the x86 cross-patent duopoly.
<wolfspraul>
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
<wolfspraul>
oh of course
<wolfspraul>
and better than ARM, and better than MIPS
<wolfspraul>
I'm just doing full disclosure
<primary>
Which I like, and thank you for.
<primary>
Hasn't that been discussed on the mailing lists?
<wolfspraul>
I think the 'open sourceness' of Mico32 is just fine, but the details are very unfortunate
<wolfspraul>
Lattice chose to write their own license, rather than reuse an existing one
<wolfspraul>
the open source code is the output generated from a proprietary software tool
<wolfspraul>
that proprietary software tool can only be downloaded after registration, and you only have a 'personal' license to use it
<wolfspraul>
one could come up with all sorts of small legal issues with all this
<wolfspraul>
if Lattice would hire a McBride tomorrow, we should be worried and switch fast :-)
<wolfspraul>
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.
<primary>
Yeah, I read about that, some quote
<wolfspraul>
but on the big picture, this is by far not my #1 priority
<primary>
"Since free software has to run on non-free hardware, then it is only fair that free hardware has to use non-free software ;-)"
<primary>
Sure
<wolfspraul>
maybe you can help with lobbying gcc for better lm32 support
<wolfspraul>
even just a reminder about this target once in a while can help
<wolfspraul>
from 4.5 to 4.6 there were some regressions, and pretty much nobody cared
<wolfspraul>
more regressions are to be expected
<primary>
have you thought about llvm?
<wolfspraul>
Sebastien did, yes
<kristianpaul>
are you from FSF? :-)
<kristianpaul>
just wondering.. :-)
<wolfspraul>
he wouldn't write 'llvm' if he were :-)
<primary>
kristianpaul: Oh no, I don't like being on lists or have known memberships.
<kristianpaul>
primary: good
<primary>
Heh, why?
<kristianpaul>
primary: (llvm) better something smaller and cleaner than gcc
<kristianpaul>
primary: nothing especial, just wondering why poeple like llvm
<primary>
If you just did C, (and I'm not sure about how your toolchain looks), then PCC looks pretty
<primary>
kristianpaul: Well if politics get in the way with GCC and GNU stuff, it is usually easier to fork or use something else
<primary>
see eglibc
<wolfspraul>
no politics here I think
<wolfspraul>
just bad code quality, if I understand things correctly
<kristianpaul>
no politics, indeed
<kristianpaul>
wolfspraul: FYI fidelio is faster than my computer in sinthesizes, thats good :-)
<wolfspraul>
great
<Martoni>
Hello
<lekernel>
hi
<lekernel>
primary: to clarify things, I'm not doing a netbook or anything. I'm developing a product for VJs (who love it) which, as an embedded platform, is open for people who want to hack on it.
<lekernel>
and people seem to make a fixation on the MMU, which is in fact a lot less troublesome than the slowness of the FPGA when it comes to raw software execution speed
<lekernel>
the only way to compete in the computer market is to make ASICs, not use a FPGA
<lekernel>
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") ...
<scrts`>
I wonder how much does it cost to produce altera hardcopy devices :)
<scrts`>
oh new series... recently moved to altera and don't fallow xilinx :)
<kristianpaul>
me either just did a quick search on his webpage, wondering for a similar product ;-)
<Martoni>
hi kristianpaul
<lekernel>
we're getting an article in etn.se soon ...
<kristianpaul>
good
<scrts`>
lekernel: if You could provide a full abstract or something like ad with available features I could contribute that on our forum
<scrts`>
there is a page djscene.lt
<scrts`>
very popular in my country
<scrts`>
I will be available later
<primary>
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
<primary>
know about other people.
<lekernel>
they aren't out of the question, they only have to make economic sense
<primary>
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.
<primary>
But again, that was asic.
<primary>
lekernel: Sorry about that figure of speech, it correctly conveyed what I wanted to say about the feasibility
<primary>
*INcorrectly
<primary>
just woke up
<primary>
Not infeasible technically, but in economic terms. We live in reality.
<lekernel>
well I believe it's definitely possible to make an open source ASIC, but not right now for this application (or even worse, netbooks)
<lestat>
don't speak about OpenCores to Martoni ^^
<primary>
What is wrong with it to Martoni's eyes?
<lekernel>
Martoni: this does not mean it is the right thing to do. especially given the derelict technical state of most opencores IP.
<lekernel>
by the way, there was LEON3 and OpenSPARC before that, none of them triggered a "revolution" on their own :-)
<lestat>
erf i meant lekernel not Martoni
<primary>
Erg, caffeine time.
<Martoni>
lestat: opencores is a taboo subject here ?
<lekernel>
no, it's not
<kristianpaul>
;-))
<lestat>
Martoni: halfly kidding, it's just that lekernel has a very low opinion about this project afaik
<primary>
lekernel: Just to prove my whining wrong, I'm going to make a purchase within the next 3 months!
<Martoni>
ok
<primary>
oop, the OGD1 was an FGPA
<wpwrak>
(asic) i think there's quite a lot of untapped potential in fpgas in the context of free sw/hw, so i think it's nice to have an fpga at the core. also, a "slow" chip teaches discipline ;-)
<wpwrak>
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 ?
<kristianpaul>
yup, in the tmu2 i remenber
<kristianpaul>
ther are logs in case  lekernel want to read those
<lekernel>
for some reason, there is no log for the 12th
<lekernel>
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
<kristianpaul>
i knew you will give an answer like that..
<lekernel>
it's a lot of typing, but otoh the record types are nice too
<kristianpaul>
wpwrak: programed in ada?
<kristianpaul>
or still :D
<wpwrak>
kristianpaul: me ? ada ? no, thanks :)
<methril_work>
wpwrak, what`s wrong with ada?
<wpwrak>
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
<wpwrak>
this approach allows you to develop a more idiomatic programming style, similar to a living spoken language. the algol approach is more like using latin.
<wpwrak>
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 ?
<lekernel>
first this is for simulation, not synthesis
<wpwrak>
lekernel: alright, but they go hand in hand, no ?
<lekernel>
not here, this whole delta delay thing is only about simulation
<wpwrak>
hmm. so these semantics don't exist in the real chip ? that would be weird.
<lekernel>
hmm... unfortunately I cannot find good explanatory material on delta delays
<lekernel>
no they don't exist on the real chip
<lekernel>
or well, not in that form
<wpwrak>
why does the simulation introduce them then in the first place ? ;-)
<lekernel>
for non blocking assignments to work
<wpwrak>
but blocking vs. non-blocking also yield different semantics in the real chip, right ?
<lekernel>
usually yes
<lekernel>
actually, delta delays is something poorly documented and poorly understood, and you sometimes see strange workarounds in code
<lekernel>
like the latest release of LM32 from lattice, for example, which adds physical delays on all assignments ...
<wpwrak>
to me, all this looks like barriers in traditional programming languages, which blocking assignments ought to solve.
<kristianpaul>
wpwrak: well, real world hace some constrainst (hardware talking)
<kristianpaul>
have*
<wpwrak>
perhaps the root of the problem is that the simulations don't represent concurrency too well
<lekernel>
there are tons of things in *HDL which are nasty ...
<lekernel>
wpwrak: delta delays (in VHDL, since verilog megafailed there) are also here to make concurrent system simulations deterministic
<wpwrak>
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
<lekernel>
oh, there are tons of things that could be done to improve logic synthesis techniques :-)
<lekernel>
roll your own HDL if you wish :)
<kristianpaul>
lekernel: btw are you going to  frikk festival, may be other place to perform with mm1?
<wpwrak>
i'm not sure it's a problem of the HDL. perhaps more a problem of people expecting it to do things it isn't designed to so ;-)
<lekernel>
kristianpaul: when is that?
<kristianpaul>
we dont think concurrently, or at least not awaring that
<kristianpaul>
8th till the 17th of august
<kristianpaul>
If you want i can re-sent you the mail>
<kristianpaul>
?
<kristianpaul>
resend*
<lekernel>
ah, august 8th
<kristianpaul>
camp?
<lekernel>
in Bethanien :-)
<wpwrak>
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
<lekernel>
well, maybe
<wpwrak>
that's where "volatile" comes into play :) (it's admittedly a crude mechanism and with poorly specified semantics)
<lekernel>
Bethanien is a nice place to hang out, but they're squatters who seldom buy stuff :-) so not the best place to promote M1
<lekernel>
maybe i'll give it a go a bit, just for fun...
<wpwrak>
lekernel: ah, a sub-division of simulation time. interesting. if you have a hierarchy anyway, you shouldn't need two times :) but i can see where it could be convenient, if treacherous