<wpwrak>
the french version of "World of Warcraft" ?
<Fallenou>
hehe
<Fallenou>
I would say it's approximatively : "fuck"
<Fallenou>
gn8!
<wolfspraul>
n8
<wolfspraul>
:-)
voidcoder has joined #milkymist
voidcoder has joined #milkymist
voidcoder has joined #milkymist
Gurty` has joined #milkymist
lekernel_ has joined #milkymist
voidcoder has joined #milkymist
voidcoder has joined #milkymist
<Fallenou>
I am trying to modify my simulation bios to match real world example, like putting my ram at address 0x44000000, I created a boot_code section in linker script which is used for the crt0.S
<Fallenou>
is this something like I am trying to to branch immediate with a giant offset ?
<Fallenou>
I told gcc to put isr() function in boot_code with a gnu-style attribute, but it still complains about it
<Fallenou>
hum ok I put "boot_code" instead of ".boot_code" in the gcc attribute, so it's OK now for isr()
<Fallenou>
it still complains about main(), I guess about the too big offset ... I need to find a way to do a "long jump"
<Fallenou>
oh, using b instead of bi
<Fallenou>
ok it linked :)
<Fallenou>
bios.bin is now 1.1 GB \o/
<kristianpaul>
0_o
<Fallenou>
yes I have exception handler vectors and setup code at address 0 and all the remaining code at 0x44000000
<Fallenou>
and a lot of padding :)
<Fallenou>
so the flat binary is kind of big
<Fallenou>
bbl
elldekaa has joined #milkymist
elldekaa has joined #milkymist
<Fallenou>
ISim does not like 2.4 GB ram.data files :)
<Fallenou>
it does not like it at all
<Fallenou>
I should split address space in two mem files
voidcoder has joined #milkymist
voidcoder has joined #milkymist
voidcoder has joined #milkymist
azonenberg1 has joined #milkymist
azonenberg has joined #milkymist
lekernel has joined #milkymist
elldekaa has joined #milkymist
<wpwrak>
Fallenou: do you even need stuff at low addresses ? e.g., couldn't you just disable interrupts and reset the PC to where your code really lives ? (in the simulation)
<Fallenou>
oh you think I can make the lm32 boot at 0x4400000 address instead of 0x0 ?
<Fallenou>
that would be nice
<wpwrak>
it can't be difficult :)
<lekernel>
you can even map the interrupts to 0x44000000
<Fallenou>
I am using two sram , one for boot_ram.data file containing crt0.S and one for program_ram.data file containing all the remaining code (main.c / dtlb_load_test.c)
<Fallenou>
now I can test the exact same mapping which is failing on the M1
<Fallenou>
OK I did as you suggested, everything is at address 0x44***** and lm32 is booting from 0x44000000
<Fallenou>
bad news is ISim seems to show mmu is behaving correctly
<Fallenou>
translating all the 0x44002xxx accesses to 0x44001xxx ones
<lekernel>
maybe you need to add some memory latency?
<lekernel>
eg use $random on the ack signal :) this may tickle those hiding bugs...
<Fallenou>
hum ok !
<Fallenou>
I even get my printf() outputs in Isim console now :)
<lekernel>
great!
<Fallenou>
printf() just write chars to an unused memory address, which gets handlede with a $write() in soc.v :)
voidcoder has joined #milkymist
* Fallenou
pushed his changes
<Fallenou>
like putting #$random() ack <= something; ?
<Fallenou>
in soc.v
<Fallenou>
hum compiler does not like
<Fallenou>
if you want to test the simulation in case you can spot something I didn't , you just have to do make in software/mmu-bios and cp the bios.bin in the simulation directory and do make clean && make and there you go
<Fallenou>
(but you would need the modified lm32-binutils which is on my github too :x)
<Fallenou>
going to eat bbl
Zboggum has joined #milkymist
<lekernel>
Fallenou: no, but at each cycle you can mask out the ack signal randomly
<Fallenou>
oh like if ($random() %2) ack <= value; else ack <= 0
<lekernel>
yes
<Fallenou>
ok the stores are done randomly multiple times
<Fallenou>
so printf() output has a lot of multiple caracters
<Fallenou>
random latency seems to be working
<Fallenou>
all tests are still passing
<Fallenou>
will do it again a few times
<Fallenou>
21:18 < Fallenou> so printf() output has a lot of multiple caracters < a lot of duplicate characters
<lekernel>
well, the store should still happen once
<lekernel>
only when the CPU gets the ack
<Fallenou>
oh
<Fallenou>
since the beginning stores were done twice
<Fallenou>
and now that ack is random, it gets stored a random number of time
<lekernel>
so it's a bug
<Fallenou>
it's more a soc.v bug than a lm32 bug I think
<lekernel>
or maybe just your misunderstanding of wishbone :) the store signals should be kept constant until the ack
<lekernel>
but that's only one store, even if it spans multiple cycles
<Fallenou>
I'm just saying that the frag_we[] stays asserted during two cycles
<Fallenou>
for each write
<Fallenou>
so the mem[] gets written twice in a row with the same value
<Fallenou>
but it should not cause any problem
<Fallenou>
but in the cpu there is only one store "event"
<Fallenou>
and one store transaction (in term of wishbone transaction)
km2 has joined #milkymist
dvdk has joined #milkymist
<whitequark>
hm, I just thought about it. Is there a way to adjust ISE simulator so that propagation delay would be visible on the waveform diagram?
<whitequark>
sometimes I really want to know which transition was earlier
<dvdk>
whitequark: do a post-synthesis simulation :)
<wpwrak>
Fallenou: what ? two stores ? writes to NOR or memory-mapped I/O aren't idempotent !
<Fallenou>
I don't think I write to NOR
<wpwrak>
i kinda wonder if it would make sense to feed verilog into spin. spin is a model checker that can verify a lot of properties.
<wpwrak>
Fallenou: what i mean is that, if the memory controller does duplicate writes in real life, that would be a problem
<Fallenou>
I just noticed that with my current simulation, using migen generated soc.v , when lm32 writes to sram through wishbone, sram gets written twice
<Fallenou>
I mean, during two clock cycles
<Fallenou>
I don't know if this is the case in the real SoC
<Fallenou>
I just noticed this with soc.v from migen
<wpwrak>
where's a super-fast logic analyzer when you need one ? :)
<Fallenou>
hehe
<Fallenou>
it does not seem to be a problem though (writting twice) in my situation here
<Fallenou>
it just tells us that something somewhere is not totally optimized
<Fallenou>
maybe it's just that frag_we stays asserted for one cycle and that's all
<Fallenou>
now I have a real printf() which is not printf(char *s) { puts(s); } (copy pasted from milkymist bios)
<wpwrak>
the TTOOO... is because of the multiple writes ?
<Fallenou>
yes
<Fallenou>
which happens all the time because of the if ($random() % 2) ack <= 1 else ack <= 0
<Fallenou>
if I remove this randomization stuff, I get TTOOTTAALL :: etc, only two times each letter
<wpwrak>
heh :)
<wpwrak>
in any case, it's not what should go out to the bus. at least if this is on a CK edge each. (maybe check if this is the case and that your printf sample clock isn't faster)
<Fallenou>
I don't sample the bus data to check the writes
<Fallenou>
I check each system clock
<Fallenou>
well yes I sample the bus, but at the system clock :p
<Fallenou>
wpwrak: the problem is not what goes from lm32 to wishbone, the problem is what goes out from wishbone to sram module
<Fallenou>
sram is seeing "write enable" asserted for two consecutive system clock cycles
<wpwrak>
but how many memory clock cycles are that ?
<Fallenou>
btw I just wrote a filter to filter off consecutive writes for the "uart" address in order to have a clean uart output in ISim :)
<wpwrak>
don't do that :) yo
<Fallenou>
wpwrak: sram clock is the system clock
<wpwrak>
u're hiding the problem instead of solving it
<Fallenou>
I just have $display() for each system cycle with frag_we asserted don't worry
<wpwrak>
(same clock) ok
<Fallenou>
I am still seeing consecutive writes
<Fallenou>
but the uart output is clean :)
<Fallenou>
TOTAL : 15/15 successes | 0/15 failures
<wpwrak>
does all this also happen on the original M1/LM32, without MMU ?
<Fallenou>
I would say I think that this happens at least on the particular migen+milkymist-ng combo I am using
<Fallenou>
I think it comes from the wishbone implementation of milkymist-ng
<wpwrak>
okay. let's see then what lekernel thinks about it. he would have to see it too, no ?
<Fallenou>
I think yes
<Fallenou>
maybe it's fixed now and I am still on an old version
<Fallenou>
maybe it comes from my particular setup (two masters - one slave)
<wolfspraul>
good morning everybody
<Fallenou>
hello :)
<Fallenou>
time to go to sleep for me !
<wolfspraul>
something popped up in the computer section of my dreams: why can't m1 support so-dimm seated memory?
<wolfspraul>
Fallenou: he :-) and my coffee is cooking now... how's it going? some weekend hacking? :-)
<Fallenou>
yes some week-end mmu hacking
<Fallenou>
it has been a busy week
<Fallenou>
but now it's 1 AM here and I have to get up early to go to work tomorrow :"
<wpwrak>
don't they use a wider bus ?
<Fallenou>
wpwrak: the good point here is that my simulation is starting to look more and more like the "real setup"
<Fallenou>
the code execute is really close, the verilog code is exactly the same
<Fallenou>
executed*
<Fallenou>
ram addresses are really alike
<wpwrak>
Fallenou: that sounds good. nothing worse than changing bugs that only exist in a flawed simulation
<Fallenou>
hop pushed
<wolfspraul>
yeah sounds nice
<wolfspraul>
sleep well
<wolfspraul>
wpwrak: I don't know, I was curious to find out the reasons pro/con supporting them
<wolfspraul>
(so-dimms)
<wolfspraul>
so yeah, maybe too many pins?
<wpwrak>
yeha, seems they're all 64 bits wide
<wpwrak>
not sure if they would be any more troublesome when it comes to the electrical domain. probably yes.
<wolfspraul>
you could plug a lot of memories in it which would be both good and bad. bad because we 'have to' support all sorts of stuff and good because it allows for exactly that type of development, if someone is interested
<wolfspraul>
there must be a cost of the standard, for sure
<wpwrak>
hmm. there might be some reluctance to optimize and generalize the memory controller timing :)
<wolfspraul>
and that is perfectly fine
<wpwrak>
we could of course select memories we trust. but then you have the problem that modules may change without you even being told
<wolfspraul>
has the so-dimm connector been the same throughout the entire ddr1/2/3 path?