<wolfspraul>
sh4rm4: in which way? what is your expectation?
<wolfspraul>
good morning btw :-)
<sh4rm4>
moin
<sh4rm4>
well, it was 40+ a while ago
<wolfspraul>
I joined ##fpga recently and after seeing an average of 1 'shit' per line I realized that is not for me and left :-)
<wolfspraul>
I will also become more picky on which channels I am in and what I consider quality etc...
<wolfspraul>
what more can and should we expect from milkymist?
<wolfspraul>
afaik there is no roadmap or planned releases right now, with some date or so - I think...
<sh4rm4>
*shrug* it looks as if the activity got quite low here
<sh4rm4>
lekernel talks rarely
<sh4rm4>
and ppl leave
<wolfspraul>
yes sure, that's why I am asking about your expectation :-)
<wolfspraul>
mine is pretty close to zero, so I'm not disappointed :-)
<wolfspraul>
I don't think we see another milkymist-obsolete update
<wolfspraul>
or should expect one
<wolfspraul>
and I am not sure about the path of -ng, if there is one
<wolfspraul>
what is your expectation?
<sh4rm4>
you think the the -ng caused a split ?
<sh4rm4>
*that the
<wolfspraul>
hard to say
<wolfspraul>
there hasn't been an -ng release afaik
<wolfspraul>
it seems the project reached a ceiling and it's difficult to advance, in any direction
<sh4rm4>
hmm
<wolfspraul>
lekernel needs to set that direction and lead, if he wants to
xiangfu has quit [Ping timeout: 246 seconds]
<wolfspraul>
I think it's tough now. the path to higher memory bandwidth is very difficult on m1 or a new board
<sh4rm4>
the milkymist-ng works looks pretty promising though
<wolfspraul>
new board = many new difficulties
<wolfspraul>
yes sure :-)
<wolfspraul>
PROMISING
<wolfspraul>
prayers are typically quiet, no? :-)
<sh4rm4>
:)
<wolfspraul>
so let's quietly continue praying :-)
<sh4rm4>
yeah...
<wolfspraul>
I think if you (or anybody) would clearly write what more they expect from milkymist, that would help
<wolfspraul>
unfortunately I cannot contribute that much really helpful stuff there, because I expect very little :-) I know how difficult it is to advance in the different directions...
<sh4rm4>
i am only a spectator here, so my opinion is not important...
<wolfspraul>
maybe I'm not the only one and pretty much nobody expects anything
<wolfspraul>
oh, very important
<wolfspraul>
because eventually the number of 'spectators' goes down, until it reaches 0
<wolfspraul>
right?
<wolfspraul>
you are at least one human being...
<wolfspraul>
alive :-)
<wolfspraul>
and there's maybe 20 here? less actually reading?
<sh4rm4>
but yes, i would expect some more discussion, and lekernel being around more often
<wolfspraul>
lekernel can override me, but I think milkymist has reached a ceiling of technical difficulties
<wolfspraul>
so you can pick out some pieces and advance them, but maybe others will fall behind then
<wolfspraul>
(other pieces)
<wolfspraul>
I think it's maxed out, and it has achieved a lot imho
<wolfspraul>
the next attempt, in whatever direction it goes, will most likely only continue with some part of the last rounds
<sh4rm4>
ah. so you think it's at a dead point now ?
<wolfspraul>
no
<wolfspraul>
but what's the goal?
<wolfspraul>
the old goal was to replace everything, the entire digital center/hub/cpu of a 'computer'
<wolfspraul>
and there were releases and they went to a certain point
<wolfspraul>
now how to continue?
<wolfspraul>
there are few people left so pretty much lekernel will set that direction
<wolfspraul>
I am continuing on a fpga tool but it's only very loosely if at all connected to milkymist
Gurty has joined #milkymist
<wolfspraul>
do you have an m1? what's the next thing you want to do with milkymist?
<wolfspraul>
why are you 'spectating' here? :-)
<sh4rm4>
i dont have one, now
<sh4rm4>
*no
<wolfspraul>
I think I will build a new experimental case for mine soon
<sh4rm4>
maybe i would have bought one if the price was about 200-250 usd
<wolfspraul>
what would you have done with it then?
<sh4rm4>
i did buy a C-one some time ago, for 300 eur just to see that it doesnt work with my screen and to shelf it subsequently....
<sh4rm4>
to experiment around with lm32 cpu and embedded system software
<wolfspraul>
what is the C-one ?
<sh4rm4>
commodore one reconfigurable pc
<wolfspraul>
I think > 50% of the m1 ended up in an experience similar to yours :-)
<wolfspraul>
at least not a single buyer asked to return his unit, which is very generous as they all understand the huge effort we took to pull off the project in the first place
<sh4rm4>
*nod*
<wolfspraul>
I think we will see some remix of milkymist tech in some shape or form
<wolfspraul>
but when and where I have no idea
<sh4rm4>
however i think with the price tag you lost a huge market of hackers
<wolfspraul>
I think it will be a much more focused subset of functionality
<wolfspraul>
oh m1 almost sold out, I only have a few units left and the price will stay there until a m1 lover comes along
<sh4rm4>
software ppl get beagle boards, r-pi's and similar stuff to mess around now
<wolfspraul>
the price could also be 4999 USD
<wolfspraul>
sure, why not
<wolfspraul>
lego sold about 2 billion USD of toys last year, I think
<wolfspraul>
that must be several hundred times more than all beagles and raspberries and arduinos combined
<wolfspraul>
and I mean this in a good way, those are all good projects
<wolfspraul>
I couldn't find much in a beagle or raspberry, but that's just me. I also wouldn't buy that c-one, but checking the tech now :-)
<wolfspraul>
I bought a bunch of tp-link wr703n and they are great
xiangfu has joined #milkymist
<wolfspraul>
<20usd little wifi computers/dongles
<wolfspraul>
oh nice that c-one project seems a really long-time thing
<wolfspraul>
impressive
<sh4rm4>
yeah it has all kinds of cpu cores, can emulate c64, amiga, zx ...
<sh4rm4>
unfortunately only with a multisync screen
<sh4rm4>
15 KHz oslt
<wolfspraul>
which fpga is on the fpga extender?
<sh4rm4>
one of the faster altera's iirc
<sh4rm4>
virtex or so
<wolfspraul>
virtex is a xilinx brand name I think
<sh4rm4>
possible
<wolfspraul>
I read quartus somewhere on their site, must be an altera chip
<wolfspraul>
and you bought one of these - nice! congratulations
<wolfspraul>
even though you couldn't find much use, it's good that you support a pioneering effort such as that one :-)
<wolfspraul>
in my opinion...
<wolfspraul>
so let's wait if/when/what lekernel cooks up the next big thing, huh? :-)
<wolfspraul>
milkymist has some nice things that deserve to move forward
<wolfspraul>
wow, nice pic
<wolfspraul>
yes that board looks like A LOT of trouble and work waiting :-)
<wolfspraul>
I wouldn't touch something like that anymore
<wolfspraul>
it looks as if they are re-creating an old pc-style motherboard but with 2 fpgas
<wolfspraul>
how did this project fare overall?
<wolfspraul>
let's see what wikipedia says :-)
<sh4rm4>
:)
<wolfspraul>
nice stuff
<wolfspraul>
oh I think one thing milkymist could do is some totally new angle of interaction
<wolfspraul>
something with rf or analog processing
<wolfspraul>
pick one problem and make a really compelling solution
<wolfspraul>
I think it has the power to do that, if someone picks something like that and pulls it off
<sh4rm4>
hrrmm
<sh4rm4>
i think milkymist's nice is more about open source enthusiasts
<sh4rm4>
*niche
utzig has joined #milkymist
utzig has left #milkymist [#milkymist]
<wolfspraul>
ok but what's the next big thing then?
<wolfspraul>
a random toy for a lonely weekend?
<sh4rm4>
well, the milkymist-ng concept makes that really easy
<wolfspraul>
great ;-)
<wolfspraul>
sebastien will be happy to hear that :-)
<sh4rm4>
one could even imagine a gui where you can en/disable components by toggling a checkbox...
<wolfspraul>
components?
<sh4rm4>
and produce a custom bitstream
<sh4rm4>
like ethernet support
<sh4rm4>
or usb
<wolfspraul>
what for?
<wolfspraul>
you just want a box to play with and learn stuff?
<sh4rm4>
and ease usage of fpga related tech
<wolfspraul>
I don't see fpgas as that one totally amazing/different tech. they are just another type of chip like dozens/hundreds of other types.
<wolfspraul>
so the main question is still what you build in the end, imho
<sh4rm4>
it's programmable, and thus interesting to software folks
<wolfspraul>
for fpgas there is a constant stream of devel boards that try to expose the more interesting functionalities of new chips
<wolfspraul>
but in the end most people don't want to keep learning forever, and spend their entire life learning, but instead they learn something and then eventually start to do some real stuff :-)
<wolfspraul>
that's why you see them playing (learning) with something for a while, and then they go away, because they learned enough and either switch to something else, or use what they learned in some productive way
<sh4rm4>
dealing with fpga devel boards is hard without a hw background, migen could lower that barrier considerably
<sh4rm4>
and then there's the open source aspect as well
<wolfspraul>
migen is a fantastic tool I'm sure, but I highly doubt it will lower any needed background
<wolfspraul>
in fact I think the opposite - you will most likely be able to make good use of migen if you already have excellent background knowledge about logic design, fpgas, etc.
<wolfspraul>
then it will make you even more powerful/productive
<wolfspraul>
but those steep first steps, I think they remain
<wolfspraul>
just look - the project is out now for how long? and how many people have found an entry to anything with it since then?
<wolfspraul>
zero, afaik
<wolfspraul>
that doesnt' look like it makes the first step to anything easier, which I also think you should not expect
<wolfspraul>
it gives you more power if you are already good with fpgas
<wolfspraul>
and logic design
<wolfspraul>
sh4rm4: have you started playing with migen?
<sh4rm4>
no
<wolfspraul>
why not?
<sh4rm4>
1) i am busy with my linux distro
<sh4rm4>
2) dont know python
<wolfspraul>
you say "migen could lower the barrier to fpga considerably". what unlocks the 'could'?
<sh4rm4>
3) don't understand migen properly
<wolfspraul>
you wait for a release? better docs?
<wolfspraul>
I know fpgas a little now, due to my fpgatools work
<sh4rm4>
if migen would be used under the hood
<wolfspraul>
let's say 10% of what sebastien knows
<wolfspraul>
and knowing those 10%, I am telling you "don't expect migen to lower your barriers"
<wolfspraul>
let's see what I think when I know 50% in a few years :-)
<wolfspraul>
under the hood of what?
<sh4rm4>
i.e. i could supply a config file: build lm32 with mmu, plus ram controller, plus ethernet
<sh4rm4>
and migen does all the gory routing stuff etc in the bg
<wolfspraul>
I think I understand what you mean, but I also think you should not wait for/expect that
<wolfspraul>
it just won't happen and work the way you think it should - ever
<wolfspraul>
many more people need to join and make incremental improvements to a lot of tools. and then collectively maybe they can advance things towards what you have in mind.
<wolfspraul>
I do think that is happening, but it's slow and spread across a lot of tools
<wolfspraul>
for example I want to learn more about some ic tools, magic/toped/qucs/etc
<wolfspraul>
but that will take years...
<sh4rm4>
:)
<wolfspraul>
what do you mean with "under the hood"?
<wolfspraul>
that config file example?
<sh4rm4>
yes
<wolfspraul>
ok
<wolfspraul>
I think you should not expect this for some years
<wolfspraul>
not just because it's "hard" "difficult" or so, but simply because it may not make that much sense
<wolfspraul>
only my opinion here... my famous 2c
<sh4rm4>
ok
<wolfspraul>
I'm sure tomorrow we see a big release that will make all this as easy as a swipe on your phone...
<sh4rm4>
i'm pretty sure it'll go into that direction, because it's more efficient and saves time and money
<wolfspraul>
we should work on a milkymist-obsolete release that includes the mmu
<wolfspraul>
either that or an -ng release with mmu, not sure what is the best path to make the mmu more accessible
<wolfspraul>
that's a 'should' as in "I hope"...
<sh4rm4>
is the mmu usable at this point ?
<wolfspraul>
not as in "I will do"
<wolfspraul>
it probably gets closer, sure
<wolfspraul>
chicken & egg
<wolfspraul>
if nobody starts using it and finds more bugs and helps bring the whole thing up, then it will just be there and everybody wonders "is it working?"
<wolfspraul>
btw quick fpgatools update
<wolfspraul>
in case anyone cares. i ran into big delays
<wolfspraul>
one month ago I set a deadline of "1 month" to go from the unclocked AND design to a clocked counter
<wolfspraul>
that time has almost passed
<wolfspraul>
but... codes increased by 5000 lines or more yet there is still tons more missing until all the clocking stuff is working
<wolfspraul>
and that's without dcm or pll, just plain gclk inputs and bufg etc.
<wolfspraul>
so I think I need another month for the clocked counter
<wolfspraul>
extending my dealine to +1 month :-)
<wolfspraul>
end of update
<wolfspraul>
s/dealine/deadline/
elldekaa has joined #milkymist
xiangfu has quit [Quit: Leaving]
wolfspraul has quit [Ping timeout: 268 seconds]
mumptai has joined #milkymist
elldekaa has quit [Ping timeout: 265 seconds]
wolfspraul has joined #milkymist
<wpwrak>
(c-one) funny they didn't include any usb, considering that they don't seem to be shy about having tons of interfaces
<wpwrak>
(migen) i agree with wolfgang. i don't see it as a tool to lower the entrance barrier. i see it more as a tool that makes building complex things less of a hassle. but when you're at the point where you actually need such a tool, then you're probably quite good at the basics already.
<larsc>
wolfspraul: luckily for us you wont get fired if you miss a deadline
<wpwrak>
kinda like a power drill. makes it easy to put holes into things but you still need to know where to put the holes.
<larsc>
and which size you want
<wpwrak>
larsc: a nominal one month deadline means four years anyway :) (add one, multiply by two, then convert to the next higher unit)
<larsc>
hehe
<wpwrak>
just think of all these "oh, i can do that in a weekend" projects that invariably end up consuming something like a month full-time :)
<larsc>
or even years
<wpwrak>
yeah, once you get in the habit of missing deadlines, eternity is the limit :)
<wpwrak>
wolfspraul: a clocked counter with enough logic to drive a 7 segment display may be nice to show things.
<larsc>
you keep pushing your expectations, a few weeks ago you just wanted a blinking LED. Have you ever though about a carerr in management? ;)
<larsc>
But I really just meant like a real life manager. Comes to you one week wants feature set X, you implement it, present it and he complains that feature set Y and Z are not yet implemented
<wpwrak>
ah, the complaining type. they're not fun. better to just let your underlings feel your poorly masked disappointment that they haven't exceeded expectations without you pushing.
<wolfspraul>
larsc: come on, shed a tear for the poor managers. maybe you misunderstood the importance (or existance) or features X Y and Z in the first place
<wolfspraul>
that can happen much more easily than one thinks - are you *sure* you really listen all the time, listen well? or you just pick out the things you want to hear or expect to hear from the stream of words reaching your eyes (or characters reaching your eyes)
<wolfspraul>
over time maybe you will recognize that as a skill in and of itself
<wolfspraul>
some people are just freaking good listeners, and others are not :-)
<wolfspraul>
welcome to the real world...
<wolfspraul>
I meant: reaching your ears (the words) :-)
<wolfspraul>
my deadline slipped, but ok. yes I set it myself, just for fun
<wolfspraul>
in fact now that I missed it anyway, I will go back and work on some more wires first ;-)
<wpwrak>
you still have a week. you can make it :)
<larsc>
luckily my managers don't care what I do, as long as I do it ;) at least kind of
<larsc>
wolfspraul: btw. fpga tools is just for writing bitstreams or can it also load bitstreams?
<wolfspraul>
both, but...
<wolfspraul>
reading a bitstream is a separate problem, if it should be meaningful
<wolfspraul>
because there are ambiguities and the more meaning you try to extract from the bits the more code and logic you need just for that
<wolfspraul>
and I will not work on those things
<wolfspraul>
so I can read and write both textual and binary bitstreams, but the reading of binary bitstreams is only for the purpose of roundtrip testing in the autotester
<wolfspraul>
not for the purpose of going from a binary bitstream to verilog (for example), in the end
<larsc>
ah ok. Where did you find all the information on the bitstream format?
<wolfspraul>
but on the writing side, I do want to and have to add higher and higher level means to write stuff, including verilog backend (one day)
<wolfspraul>
there is tons of documentation available, just putting pieces together and trying to verify a complete model which helps focus the whole thing
<wolfspraul>
if 2+2 does not come out as 4, something is wrong
<wpwrak>
sounds easy ;-)
<wolfspraul>
and the math that says that 2+2 is/must be 4 is there (in the form of documentation and sources)
<larsc>
ok
mumptai has quit [Read error: Connection reset by peer]
xiangfu has joined #milkymist
kilae has joined #milkymist
elldekaa has joined #milkymist
<Fallenou>
hey wolfspraul :)
<Fallenou>
how are you? what's up ?
kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0.1/20121010144125]]
<wolfspraul>
hacking on fpgatools :-)
<wolfspraul>
today actually I took a break
<wolfspraul>
but other than that, next is... not sure. :-) maybe more east-west directional wires :-)
* Fallenou
reading the backlogs
<wolfspraul>
musings about the next great milkymist :-)
<Fallenou>
hehe I just read that
<Fallenou>
I am making progresses on the MMU, in the direction of "full feature" state (which does not mean "full debuged" state)
<Fallenou>
But there seem to be some modification that must be done on already working things
<Fallenou>
for exceptions in the cpu
<Fallenou>
but to answer sh4rm4 question, mmu is working today, at least the virtual to physical translations and the tlb miss features
<Fallenou>
I modified Milkymist BIOS to be able to handle the mmu, map pages and use them etc
<Fallenou>
with exception/tlb miss handlers
<Fallenou>
like a mini OS
<Fallenou>
and it runs
<Fallenou>
it does not mean that there is no bug in some corner cases
<Fallenou>
but my tests pass :)
<larsc>
nice
<Fallenou>
so indeed as wolfspraul said it could be nice to try to use it somehow and then give a feedback on bugs which I could fix etc
<Fallenou>
I should update and provide a better documentation
<Fallenou>
because you would have to either be in my head or read my code to understand how to use it
<Fallenou>
but the good news is that there is already a software using the mmu as an example :) the modified bios
<Fallenou>
so it can very well be used as an example on how to use the mmu
<Fallenou>
I don't know if a parallel mmu-lm32-linux work is something that someone would be interested in
<Fallenou>
that could be a motivating booster :)
<mwalle>
Fallenou: there might be some complications with the exceptions in the m stage
<Fallenou>
yes I read you about that :/
<Fallenou>
indeed if by nature exceptions in m stage are "imprecise" as stated in the lm32 datasheet ... it might be hard to implement DTLB miss and permission faults :/
<Fallenou>
so far I didn't encounter any trouble with it, but maybe it will come ...
<mwalle>
well looking at the code, i'm not really sure if the m stage or the wb data bus error causes the imprecisement
<Fallenou>
I guess there might be some troubles depending on if there is a jump/branch or interlock while there is an exception in m stage
<Fallenou>
I really don't know yet what they have in mind when they state "imprecisions"
<mwalle>
and of course there might be an exception in the x and in the m stage at the same time
<Fallenou>
well in that case there is a priority to set up
<Fallenou>
I would say priority to the m stage exception
<mwalle>
you have to make sure every instrucion after the one causing the exception is executed and every instruction before (and the one which caused the exception) is killed
<mwalle>
= precise exceptions
<mwalle>
there is already such a priority in the lm32 code and that is the reason why i dont know where the imprecise databuserror exeception comes from..
<Fallenou>
and the pipeline stall/kill signaling is quite messy
<Fallenou>
reading the code really gives headaches
<mwalle>
maybe it has something to do the the shifter/divider/multiplier which is multistaged
<Fallenou>
oh, maybe
<mwalle>
looking at the block diagram in the manual the x stage and the w stage is the only common stage for all pipes
<Fallenou>
what do you mean by "common stage"?
<mwalle>
btw i think we should figure this out before any serious programs are running, eg. find defects, write tests etc
<mwalle>
Fallenou: eg the shift pipe has no m stage
<Fallenou>
well it goes in the m stage anyway but does nothing in it, right ?
<Fallenou>
every instruction passes through every pipeline stage afaik
<mwalle>
but only one is active :)
<mwalle>
for a given instructon
<Fallenou>
not sure I understand what you mean by all this
<mwalle>
have a look at figure 3 in the refman
<Fallenou>
yes I'm on it
<Fallenou>
only load and store instructions do something in m stage afaik
<Fallenou>
but even an add X,Y,Z would lose 1 cycle in m stage I think
<mwalle>
yes
<mwalle>
but a shift uses both the X and M cycle
<mwalle>
imho you could call it S1 and S2 then
<Fallenou>
oh you mean the shift uses the M cycle to compute things, but not for writting/reading main memory ?
<mwalle>
yes
<Fallenou>
like an extended X stage
<Fallenou>
X stage spans over M stage ?
<Fallenou>
I never thought about that !
<mwalle>
if i read that block diagram correctly shift uses two cycles
<Fallenou>
I thought that if an instruction would need 2 cycles to execute, it would stay in X stage for those 2 cycles and "stall" the pipeline
<Fallenou>
but maybe then I'm wrong :)
<Fallenou>
the diagram seems to tell I'm wrong
<mwalle>
the pipe should only be stalled for RAW hazards
<Fallenou>
well it's stalled for cache misses as well
<Fallenou>
during wishbone accesses
<mwalle>
(well there is some other multiply unit in the lm32 code, which might stall the pipe)
<Fallenou>
pipelined divide and multiply should stall the pipeline as well I think
<mwalle>
ok and cache misses and mispredicted branches :)
<Fallenou>
mispredict branches I'm not quite sure, it just kills instruction fetched and changes the address stage
<Fallenou>
the pipeline implementation is really not easy to read ...
<Fallenou>
usually I prefer experimenting and looking at wires and pc_a pc_f pc_d pc_x pc_m pc_w values
<Fallenou>
in the simulator
<mwalle>
Fallenou: but actually all signals are named accorind to the stage they are used in :)
<Fallenou>
yes it's a good thing!
<Fallenou>
it helps a lot
<mwalle>
eg the adder gets input *_x and output is result_x, eg its combinatorial
<mwalle>
the shifter has *_x inputs and _m result
<Fallenou>
yes, but the difficult part is understanding the kill/stall things
<mwalle>
so the shifter uses the x and the m stage
<Fallenou>
for a few it's understandable, but for some of these signals it's like an entire page of || and &&
<mwalle>
yeah and the ifdefs makes it even worse ;)
<wpwrak>
i lost a bit track of the issue you're discussing ... is it that DTLB faults in M while ITLB faults in F ?
<Fallenou>
well the main issue is to make sure exceptions in M stage are "accurate"
<Fallenou>
which the LM32 datasheet says "it is not"
<Fallenou>
I don't exactly know what it means ... but we generate DTLB miss/faults at m stage so it's bad luck :(
<mwalle>
wpwrak: the lm32 commit point seems to be in the x stage
<wpwrak>
ah, so you're trying to determine under what conditions whey wouldn't be inaccurate ?
<Fallenou>
yes
<Fallenou>
for now, with my examples, it seem to work, but indeed I don't do multiply/divide or complex jump/branch combinaisons in my samples
* mwalle
is asking himself why they haven't put it into the m stage
<mwalle>
Fallenou: and of course interrupts :)
<wpwrak>
mwalle: perhaps because most things get detected at D or X ?
<mwalle>
wpwrak: yeah which is bad for us ;)
<mwalle>
and maybe the right way would be to move it to the m stage.. but i fear we mess up the whole processor ;)
<Fallenou>
the only exception we know which is firing at M stage is data bus error exception
<mwalle>
because we dont have any test benches for it
<Fallenou>
but is it really working correctly ? ...
<wpwrak>
what causes a DataBusError ? misalignment, what else ?
<mwalle>
Fallenou: well and that exception is described as imprecise and lattice doesnt care about because its handled like a fatal error, eg. there should _never_ be such an exception
<Fallenou>
wpwrak: any wishbone error
<Fallenou>
wait a sec
<Fallenou>
if ((D_ERR_I == `TRUE) && (D_CYC_O == `TRUE))
<Fallenou>
data_bus_error_seen <= `TRUE;
<Fallenou>
in an always (posedge clk)
<wpwrak>
so what are D_ERR_I and D_CYC_O ? :)
<Fallenou>
it's the wishbone wires
<mwalle>
Fallenou: thats btw the code which could delay the exception, because this only sets the seen flag
<mwalle>
+ is
<Fallenou>
I am not a wishbone expert but I think cyc_o asserted means "a transaction is active"
<Fallenou>
and err_i means the slave asserts an error line and says to the master "stoooop the transaction, i'm in a bad state !"
<Fallenou>
mwalle: yes but then assign data_bus_error_exception = data_bus_error_seen == `TRUE;
<mwalle>
or there is no target which the address belongs
<Fallenou>
so it does not seem to be delayed
<wpwrak>
what i mean is basically: could the "imprecise" come from the detection being "late" ? then it may not be a problem in the case of the TLB, assuming that the TLB has a constant response time
<Fallenou>
it fires right away
<mwalle>
Fallenou: there is some stall_x check iirc
<Fallenou>
the exception fires right away, but then it is not taken right away, there are a few checks
<Fallenou>
wpwrak: oh ok maybe they mean it depends on when the slave asserts the err line ?
<mwalle>
wpwrak: imprecise doesn't only mean one or more instructions too late, but also that all instruction before are killed and all later are executed
<wpwrak>
yup
<wpwrak>
mwalle: should be easy to test if there's a problem with that
<mwalle>
and i fear we may violate that in some circumstances
<mwalle>
wpwrak: yeah of course, but then you have to actually understand the pipe :)
<mwalle>
to write the test cases :)
<Fallenou>
I don't know what could be my next step ... I am thinking about: doing a few simulations on a non-modified (non-mmu) lm32 core and see how exceptions work in the different stages (f/x/m)
<mwalle>
and when you understand the pipe, you could just say its plain wrong what we are doing ;)
<mwalle>
Fallenou: simulate branches right before/after an exception
<Fallenou>
understanding the whole pipeline signaling stuff is really a nightmare
<mwalle>
simulate a break, simulate interrupts
<mwalle>
simulate shifts
<Fallenou>
you just filled my monthly calendar :p
<mwalle>
glad to hear ;)
<wpwrak>
set register N to zero, addi rN, rN, 1; addi rN, rN, 2; addi rN, rN, 4; <code that triggers an exception>; addi rN, rN, 8; ...
<wpwrak>
then see what you got
<mwalle>
wpwrak: but thats only a (basic) test
<mwalle>
and i guess Fallenou already did sth like that
<mwalle>
Fallenou: another idea is to actually move the exception into the x stage
<mwalle>
but then you would have to have every signal ready in that stage
<mwalle>
and i guess the adder is used to compute sth like sw (r1+10), r2
<mwalle>
but maybe we can duplicate that in the F stage...
<mwalle>
i dunno
<Fallenou>
15:41 < mwalle> Fallenou: another idea is to actually move the exception into the x stage < But how? for DTLB stuff we only know that there will be a miss in M stage unfortunately :/
<mwalle>
Fallenou: how do you know when there will be a miss?
<Fallenou>
I know that there is a miss in parallel of the cache lookup in M stage
<mwalle>
looking at the address?
<Fallenou>
because I do the TLB lookup in parallel of the cache lookup
<mwalle>
Fallenou: and can this be done a stage earlier? what signals would you need?
<mwalle>
eg. if you would only need the address, and the address is a result of the x stage, we could look if we can get the address already in the f stage
<mwalle>
erm
<mwalle>
decode stage
<Fallenou>
in theory we get everything we need in the decode stage
<Fallenou>
we just need the virtual address being accessed, and if it's a write
<mwalle>
mhhh.. but the address is r1+IMM, and we only have IMM in the decode stage..
<Fallenou>
oh right
<Fallenou>
we need to tkae the displacement into account
<Fallenou>
:(
<mwalle>
to get r1 we would have to (at least) extend bypass network..
<Fallenou>
that seems pretty intrusive change
<mwalle>
yeah
<Fallenou>
to touch the register file ...
<mwalle>
mhh
<mwalle>
well, do we need this in the D or X stage?!
<Fallenou>
if we want to do the tlb lookup earlier, we need the virtual address earlier, at least at D stage, so that when can do the lookup in X stage and fire the exception earlier
<mwalle>
which isn't feasible
<mwalle>
Fallenou: btw what happens in case of an exception? all previous stages are killed, the M and W stage is allowed to be completed
<wpwrak>
you could precalculate all possible outcomes and just pick the one that matches. 32 registers, so for each an offset corrector and a vector with 16 possible results. hmm, fpga space may get small with that
<mwalle>
and the current instructions seems to be replaced with sth like mvi ea, EBA+EID
<mwalle>
wpwrak: there is also another problem, we only have all register values ready at the beginning of the X stage, so if you want to decide whether there will be an exception in the X stage, this would have be a combinatorial path
<wpwrak>
you mean from the previous operation ? hmm yes, that would complicate things
<Fallenou>
it's very very easier to fire the exception wire at M stage :/
<Fallenou>
I suggest we test if it causes problems
<wpwrak>
let's see what could go wrong if the exception in M is handled just like in X ... competing of preceding instructions shouldn't be an issue
<wpwrak>
compLeting
<Fallenou>
let see what goes wrong and if we can fix that
<wpwrak>
something could crawl in to W that shouldn't go there. that would be the faulting memory operation. so there would have to be a test for that. should also be easy to write a test case of it.
<wpwrak>
then you could get a DTLB miss together with an ITLB miss. i suppose that's something that could happen even if the DTLB exception was in X. should be safe to simply ignore the ITLB miss in this case - it'll come back when retrying after exception handling.
<Fallenou>
yes, I think we should just give more priority to DTLB exceptions
<Fallenou>
it makes no sens to serve the ITLB, if we are not sure that it will really need to be fetched anyway
<Fallenou>
if for instance the dtlb exception leads to a change in the program low (seg fault?)
<Fallenou>
program flow*
<wpwrak>
yup
<mwalle>
so what youre beasically trying to archive is to move the commit point to the M stage :)
<Fallenou>
the commit point ?
<mwalle>
the point where you know that nothing can change anymore
<mwalle>
wpwrak: what happens if someone kills the M stage?
<wpwrak>
how would someone kill the M stage ?
<mwalle>
because theres a branch?
xiangfu has quit [Quit: Leaving]
<mwalle>
Fallenou: do you understand that kill_* and valid_* and q_* logic?
<mwalle>
branch_flushX_m is nice ;)
<mwalle>
(the comb logic)=
<mwalle>
not the signal name
<mwalle>
wpwrak: Fallenou: do you know gem5?
<wpwrak>
first time i hear of it
<wpwrak>
isn't the M stage already too late to kill anything ?
<Fallenou>
gem5? no, what is it?
<Fallenou>
mwalle: about kill_*/valid_* q_* I just understand that "kill" means the instruction in the stage will do nothing, valid it must be something similar, and q_ is to "qualify" a signal, to add an extra layer of verification
<Fallenou>
so I just have a very basic understanding
<Fallenou>
usually I just follow the lines of code to see what signal conditions what action
<Fallenou>
usually it's a mix of kill == false and valid == true and q == true
<wpwrak>
maybe try to convert that code into a drawing. looking at it from a different angle often helps to understand things.
<wpwrak>
plus, it'll also give the rest of us some insights ;-)
<Fallenou>
hum hum ok
<Fallenou>
I will try to do a drawing with the result of simulation
<Fallenou>
sounds nice gem5
<mwalle>
wpwrak: i guess the store is done at the end of the stage, eg the x stage can still kill sth in m
<mwalle>
Fallenou: unfortunately it doesnt support lm32 ;)
<mwalle>
Fallenou: you use some proprietary simulation tool, right?
<mwalle>
btw maybe someone will try rtlvision pro on lm32 ;)
<mwalle>
bbk
<mwalle>
bbl
<Fallenou>
mwalle: I am using ISim which is free to use (there is a maximum number of lines of verilog, fortunately lm32 is small enough)
Alain_ has joined #milkymist
Alain_ is now known as Alarm
<Fallenou>
it's non open source, but it's free (they do not charge you) to use, it comes with ISE Webpack :)
<Fallenou>
I have a git repository all set up for anyone who would want to simulate lm32 with ISim btw
<Fallenou>
you just git clone, you source ISE settings.sh, you type "make" and there you go, it runs the simulation (with console for $display() and waveforms)
<Fallenou>
but then indeed you would need to compile some code, so have the toolchain etc etc
<Fallenou>
or I could provide you with a binary file
<mwalle>
Fallenou: is there a console version?
<GitHub74>
[milkymist-mmu-simulation] fallen pushed 2 new commits to master: http://git.io/7Jv5PA
<GitHub74>
[milkymist-mmu-simulation/master] Synchronise the simulation repository with the mmu-lm32 repository - Yann Sionneau
<GitHub74>
[milkymist-mmu-simulation/master] fixes in ITLB - Yann Sionneau
<Fallenou>
maybe ISim can run in console
<Fallenou>
but there is not much things to click on in ISim :) Just a "start" button !
<Fallenou>
oh yes I think there is a console mode
<Fallenou>
instead of doing ./soc -gui you just do ./soc :)
<Fallenou>
and then you type run
<Fallenou>
it seems ISim can generate .vcd file (to be viewed on gtkwave)
<Fallenou>
I don't get how you can enable the console output (for $displays) while in ISim console
<Fallenou>
ok you run ./soc and then do "restart" "init" and finally "run all" and it will run the simulation and print console output :)
<Fallenou>
no gui needed !
<Fallenou>
you can add breakpoints, show value of signals, set values (overwrite them)
<Fallenou>
it's debugger commands that works using the milkymist jtag cable ?
<mwalle>
Fallenou: why do you import the sources for the processor in the simulation repo? can't they be outside?
<mwalle>
Fallenou: yep :)
Gurty has joined #milkymist
<Fallenou>
well yes they could ^^
<Fallenou>
I should do a git submodule
<Fallenou>
it's not the best organization ever, I agree
<Fallenou>
the best would be to specify your lm32 folder in the simulation repository to be imported
<mwalle>
with the binary which should be executed :)
<mwalle>
soc.v emulates the WB?
<Fallenou>
I yes and uart and uses sram as wishbone slave to hold code
<Fallenou>
it's just a "dummy" toplevel, instanciating lm32/wishbone/sram/fake uart based on $displays
<mwalle>
i c
<Fallenou>
19:36 < mwalle> with the binary which should be executed :) < I modify the binary a lot while simulating, so I often recompile the bios and then copy it to simulation folder and relaunch the simulation
<mwalle>
iverilog didnt work, right?
<Fallenou>
I remember having tried a few simulators and the best solution I found so far was ISim
<Fallenou>
iverilog was my first try, I don't remember why I stopped using it
<Fallenou>
I can only remember an issue with log2 function
<Fallenou>
do you want a bios.bin with an itlb test ?
<Fallenou>
(or directly a ram.data)
<mwalle>
Fallenou: i'm planning to begin with some basic instructions
<mwalle>
using the original lm32 core
<Fallenou>
ok :)
<Fallenou>
you can compile a simple .S file, then take the binary, name it "bios.bin" and move it in the simulation repo, use the h2g tool to generate ram.data (or just do make ram.data)
<mwalle>
wpwrak: yeah the first kill is likely the decode stage
<mwalle>
but it'll move forward in the pipe
<mwalle>
Fallenou: ah you actually modified the sources, didnt see that
<wpwrak>
ah, you mean a "zombie" walking through the pipeline. okay, but that one won't cause us grief - especially no DTLB miss.
<Fallenou>
mwalle: yes I took that liberty :p
<mwalle>
wpwrak: maybe, what i tried to say is, we should now put some thoughts into the exception handling, figure out what can happen, why lattice chose the x stage for exceptions, what happens if the exception is raised in the m stage, etc
<mwalle>
but for that we really have to understand the pipe
<mwalle>
so the first question for me is, how an exception actually works
<mwalle>
somehow the PC ends up in EA, and a jump is done
<Fallenou>
to get that, the best I think is to simulate lm32 and look at the wires
<mwalle>
i guess a pipeline visualizer would be handy too ;)
<Fallenou>
basically you assert exception_x, and when exception_m == TRUE you can be sure that the exception will actually happen and you can deassert exception_x
<wpwrak>
mwalle: yeah, a visualization of the pipeline would be good. that's what i suggested to Fallenou.
<mwalle>
Fallenou: what instruction causes the writeback to EA?
<mwalle>
the one causing the exception?
<Fallenou>
I don't know
<Fallenou>
maybe the one in X stage, dunno
<Fallenou>
(the one which was in X stage I mean)
<Fallenou>
but I really don't know
<wpwrak>
Fallenou: not sure if signals are the right level of abstraction, though. i'd think more of a list of conditions at each stage, followed by either the content of the next stage(s) or arrows indicating an immediate effect
<mwalle>
wpwrak: i was never good at painting ;)
<Fallenou>
neither do I :p
<mwalle>
wpwrak: but you may extract the needed informations from the signals
<wpwrak>
e.g., D = shift would be followed by a two stages long block for X and M. F = ITLB miss would be followed by a flush and then exception, etc.
<wpwrak>
sure, the signals have it all. but i think they're still too low-level. they basically tell you how it's done, but not why.
<Fallenou>
and they are too numerous to have all the conditions in head
<wpwrak>
i;m basically looking for the "pipeline designer's view"
<Fallenou>
at least I cannot get verything in my head
<wpwrak>
that's why i'm suggesting a drawing :)
<Fallenou>
yes it's a good idea but it may take a while to implement such a visualizer
<wpwrak>
if it gets too complex, draw it. that forces you to make things consistent. each time you find something that doesn't fit or that you can't explain, you've discovered a hole in your knowledge you may not have been aware of before.
<wpwrak>
no no, not a visualizer. just a diagram :)
<Fallenou>
well to be honest I draw a few complete sheets of pipelines :p
<mwalle>
so if we get sth like that _automatically_ from a simulation output
<Fallenou>
that would be cool :)
<wpwrak>
mwalle: that's a good start. now add the things connecting the little boxes, and the different possible outcomes :)
<Fallenou>
to add a bit of code to lm32 to just generate data about pipeline, and then process the data with a graphic tool
<wpwrak>
the simulation output isn't what defines how things work. the source is.
<mwalle>
wpwrak: like page 12?
<wpwrak>
oh, there are multiple pages ;-) checking ...
<mwalle>
wpwrak: well its a first step to understand the pipeline
<wpwrak>
page 12 is basically figure 3 from the lm32 archman
<mwalle>
because you can easily write some small program and visualize that
<mwalle>
well its a classical 5 stage pipe ;)
<wpwrak>
pages 21-29 are better, but probably have too much detail
<mwalle>
wpwrak: all pages are missing the control logic
<wpwrak>
yup. i'm more thinking of something like page 1 but with control logic and different choices.
<wpwrak>
so, not visualization of a single run but the design for all runs. or, if it gets too complex, one drawing per major case.
<Fallenou>
I think the first step would be to visualize which instruction is in which stage, maybe with a few important wire values. Just as a first step
<Fallenou>
and then maybe show a lot more condition value
<mwalle>
have to go to bed now ;)
<Fallenou>
at least showing all kill/valid/q values for each stage
<Fallenou>
the same for me!
<mwalle>
gn8
<Fallenou>
very nice to have this brainstorming with you guys :)
<Fallenou>
thanks !
<Fallenou>
see you!
<wpwrak>
pipelined dreams ! :)
<Fallenou>
wpwrak: so not a visualization of a particular run with a particular program running ?
<Fallenou>
(pipelined dream) ahah :)
<Fallenou>
so a static image ? not an animation ?
<wpwrak>
yeah, static. something you can pin on the wall and look at when you get lost.
<wpwrak>
if you don't trust your code analysis you can still pick things from the simulation. but you probably don't need a visualizer just for checking.
<Fallenou>
I have trouble visualizing in my head the page 1 with control logic
<Fallenou>
and even if there is no program running :o
<Fallenou>
even more*
<Fallenou>
how can you do a drawing like page 1 but in a "generic" way, without any actual assembly instructions
<Fallenou>
?
<wpwrak>
(i'm thinking here of my experience with the linux (network) traffic control infrastructure. that one seemed impenetrably complex. i spent something like two months trying to figure it out. eventually, i succeeded to the point of being able to write non-trivial code for it. then i wrote a paper, which helped me to find more inconsistencies in my understanding. a few weeks later, suddenly extensions from other people started to pop up ;-)
<Fallenou>
I guess network stack of linux is a bit of a mess like a cpu pipeline :)
<Fallenou>
I really agree that a drawing would help a lot not being lost
<Fallenou>
I just have troubles picturing what you have in head
<wpwrak>
you could have multiple choices per stage. e.g., "memory read", "memory write", "shift", "multiply", "anything else". so just stack them vertically. you basically get a tree.
<Fallenou>
by control logic, you mean kill_*/valid_*/q_* ?
<Fallenou>
yes I remember having this kind of problems
<Fallenou>
I wanted a specific layout with subgraphs ...
<Fallenou>
I ended up using invisible arrows to have the layout I wanted ...
<wpwrak>
maybe consider inkscape. you may need it anyway for "polishing" things
<wpwrak>
i remember that, a long time ago, tgif looked promising as well. it still seems to be around. may be a bit more compatible with modern taste than xfig.
<Fallenou>
ok
<wpwrak>
what's nice about xfig is that the text format is fairly simple. so you can write nice post-processors. e.g., for drawings with conditional elements.
<wpwrak>
not the xml madness that's all the rage nowadays
sh4rm4 has quit [Ping timeout: 276 seconds]
<Fallenou>
ah good!
<Fallenou>
time for me to go have pipelined dreams as well!
<wpwrak>
stall-free pipelining then ! :)
<Fallenou>
héhé thanks, interruption-free dreams!
sh4rm4 has joined #milkymist
elldekaa has quit [Remote host closed the connection]