<wolfspraul>
short term goal is to be able to load very simple but running designs into a slx9 (for example, since that's on azonenberg's board)
<wolfspraul>
'very simple' is something like an inverter, from one pad to another pad
<wolfspraul>
then going up from there, a few more gates (slices), clocks, etc.
<wolfspraul>
the longer term goal is to be able to synthesize the milkymist soc into something that runs on the chip
<Fallenou>
what Xilinx tool would youreplace ?
<Fallenou>
Xst ?
<wolfspraul>
all
<wolfspraul>
no, all
<Fallenou>
oh :)
<wolfspraul>
in fact I'm not at the Xst level and won't be for a while
<wolfspraul>
hopefully there is something reusable in icarus verilog or elsewhere
<Fallenou>
so you parse verilog, synth, map, place , route, and then generate bitstream from netlist ?
<azonenberg>
wolfspraul: going to dumpster dive on campus for an hour or so
<azonenberg>
if nobody has further suggestions i'll send gerbers out to the fab tonight
<azonenberg>
should get 'em in ~3 weeks
<wpwrak>
will they do something with the order during the weekend ?
<wpwrak>
if not, perhaps wait until sunday, i case someone has further ideas
<wpwrak>
s/i /in/
<wolfspraul>
Fallenou: no, not at all
<wolfspraul>
that is all far too much and too diverse
<wolfspraul>
I work on the bitstream, and only that
<wolfspraul>
I have a chip, say the slx9, ok? now I want to load a running design into it. something super simple, hand-mapped into the primitives on the chip
<wolfspraul>
that's what I work on
<wolfspraul>
the goal is to keep that first level as small and clearly focused as possible
<Fallenou>
oh ok
<wolfspraul>
it must be 100% stable, bug-free, etc.
<wolfspraul>
(that's the goal)
<Fallenou>
so you want to connect a few LUT together
<wolfspraul>
not even that, at the beginning just an inverter between two pads
<Fallenou>
you generate the bitstream that does that
<wolfspraul>
but then a (one) slice, yes
<wolfspraul>
then two slices
<wolfspraul>
that already includes lots of routing
<wolfspraul>
the inverter would only go to the ILOGIC/OLOGIC, through some switch boxes, and out the other pad
<wolfspraul>
I start with that
<Fallenou>
you will soon be an expert of FPGA internals :)
<wolfspraul>
that's at least 50% of the value of the project for me
<wolfspraul>
after 1 month I already start to feel better, but there are many more things to understand
<wolfspraul>
let's see where it is in 2 months
<wolfspraul>
I'm optimistic
<wolfspraul>
'inverter' though, ok?
<wolfspraul>
milkymist soc is the longer term goal
<Fallenou>
I started the MMU project in mid january, and it's not finish, all of these things take time
<Fallenou>
speaking with "months" is the good granularity I think :)
<wpwrak>
small steps are good. it's much easier to stay motivated when each day ends with a little success than working on a project that will solve all the world's problems after a decade of work but that does nothing else before that. (and by the end of that decade you'll be thorough lost in in-thinking anyway :)
<Fallenou>
sure
<Fallenou>
definitely
<Fallenou>
is m1r4 still in the pipeline ? at least for a few samples ?
<Fallenou>
I can see a few adam's emails from time to time :)
<Fallenou>
which makes me think it's still in the pipe
<Fallenou>
which is great :)
<wolfspraul>
it won't take a decade
<wolfspraul>
out now for a few hours, saturday family obligations
<wolfspraul>
but, in good fallenou culture, my notebook goes with me and so go the s6 primitive schematics :-)
<wolfspraul>
I try to isolate the chip-specific knowledge in the smallest possible tool/code
<wolfspraul>
on top of that tool we are then dealing with very simple boolean logic and gates/structures etc. then I will think about how to translate higher-level logic abstractions into those structures, aka packing/routing
<wolfspraul>
but that problem can and should be addressed in a chip-agnostic way
<wolfspraul>
I talk about it more when something actually works, i.e. not now :-)
<wolfspraul>
if I have the inverter running on my desk in 2 months I'm happy
<wpwrak>
hmm, the vias under the FPGA will be hard for a DIY FPGA
<wpwrak>
s/DIY FPGA/DIY PCB/
<Fallenou>
good saturday wolfspraul :)
<wolfspraul>
is there a free tool for schematic entry of a chip?
<wolfspraul>
I started to do drawings in svg but it's too raw and wasting time
<wolfspraul>
maybe I use kicad
<wolfspraul>
the purpose is to document primitive or parts-of-primitives schematics
<wolfspraul>
vias under fpga?
<wolfspraul>
don't understand
<wolfspraul>
you mean azonenberg's board has some vias there? haven't checked yet
<wolfspraul>
one by one :-)
<wpwrak>
yes, he has vias under the fpga. this means that you have to make them VERY flat
<wpwrak>
not taller than 0.1 mm
<wolfspraul>
sure, or I modify the board, or I de-couple the diy-pcb and fpgatools a little and just fab it somewhere locally
<wolfspraul>
I can probably get this made in 2 days, in horrible sloppy quality then I can learn about testing and fixing pcbs :-)
<wpwrak>
yup. all viable options
<wpwrak>
;-))
<wolfspraul>
in the end it all comes around to knowledge and quickly picking what one really needs
<wpwrak>
sure. the only thing is that you don't learn how to make DIY-friendly layouts this way
<wpwrak>
but yes, everything has its price ;)
<Fallenou>
hum hum my first relocated calli seems to be OK
<Fallenou>
second one ok too
* Fallenou
checking if the calli instructions get patched correctly to change the "immediate" part of the opcode according to the new virtual address of the instruction
<Fallenou>
arg fucking moskito
<wpwrak>
gas 'em :)
<Fallenou>
it's dead
<Fallenou>
the shoe shoot
<wpwrak>
may its rotten soul burn in hell ;-)
<Fallenou>
amen !
<Fallenou>
nice !
<Fallenou>
relocating on-the-fly non-PIC code works :)
<Fallenou>
I have the void f(void) { puts("@"); } working
<Fallenou>
the code of f() contains 9 CALLI =)
<Fallenou>
puts got inlined
<Fallenou>
all 9 CALLI got rewritten on the fly when copied to their new physical locations, taking into account their virtual location to rewrite the "jump relative offset"
<Fallenou>
output is kind of messy because I don't think the puts/printf stuff are re-entrant :p
<Fallenou>
I mean the ITLB/DTLB exception handler is using printf and puts
<Fallenou>
so I guess bad things happen if puts or printf cause the DTLB/ITLB exception :)
<Fallenou>
a puts while putsing ...
<wpwrak>
hmm. use write() ?
<Fallenou>
yes I should use more low level stuff in exception handlers
<Fallenou>
untill now it didn't make any problem
<Fallenou>
so it was good enough :)
* Fallenou
uses crappy code, unless it makes real problems
km2 has quit [Ping timeout: 276 seconds]
<Fallenou>
ok awesome, it works really well (in ISim) if I comment puts/printf from DTLB/ITLB exception handlers
<Fallenou>
I can still see the exceptions happening because of a $display() in verilog code anyway :)
<lekernel>
(of course, you'll want to make sure that the rest of the code that may uses the interrupt is disabled. so do uart_force_sync() before)
<lekernel>
and you loop on that if you want to write a string
<lekernel>
speaking of interrupts, does it correctly store the virtual address for return when an interrupt occurs with the MMU enabled? that might be your problem
<lekernel>
but i'd start by getting it to work without any interrupt involved
rejon has quit [Ping timeout: 246 seconds]
<Fallenou>
lekernel: yes for both simulation and real fpga stuff I disactivate interrupts in the main()
<Fallenou>
but yes indeed I should not call libc stuff from exception handler and from my f() function running in virtual addressing
<Fallenou>
it's just painfull to directly use CSR_UART_RXTX
<Fallenou>
and even more if you want to have a printf() like functionnality :p
sh4rm4 has quit [Ping timeout: 276 seconds]
<Fallenou>
lekernel: about interrupts, it should be handled OK, I have not tested yet though. if the code is running in "user mode" when the irq happens, the mmu goes in "kernel mode" and irq handler is run, and when irq handler does "eret" mmu goes back into user mode and jumps to EA which contains PC_x of when irq happened, which is always a virtual address so it should be ok
<Fallenou>
it works for page faults
<Fallenou>
it should work the same for irq
<Fallenou>
but for now I disabled irq ^^
<Fallenou>
something I should implement is : is an exception happens while mmu is in kernel mode, when returning from the exception mmu should not put itself in usermode, but "back" at the previous state => means stay in kernel mode
<Fallenou>
I should just add a backup reg
<Fallenou>
if an exception*
<roh>
can exceptions happen in its handlers?
<Fallenou>
heh I am wondering the same thing
<Fallenou>
I think nested exceptions are allowed here
<roh>
maybe a stupid question.. but i am trying to understand ;)
<Fallenou>
so it will be a pain
<roh>
irgh. well.. fun!!1!
* Fallenou
opens lm32 datasheet
<Fallenou>
it's kind of blury
<Fallenou>
datasheet says "limitd nesting exception is possible"
<Fallenou>
limited*
<Fallenou>
it says that more advanced nesting needs software help
<Fallenou>
not very usefull
<Fallenou>
because if I'm in the *TLB handler (an exception handler), and I get an incomming IRQ (another exception) it could be bad
<Fallenou>
oh there is a paragraph about nested exceptions (another one)
<Fallenou>
if I do lazy mapping it prints "Mapping DONE" and hangs
sh4rm4 has joined #milkymist
sh4rm4 has quit [Ping timeout: 276 seconds]
sh4rm4 has joined #milkymist
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #milkymist
<wpwrak>
you should probably just disable interrupts in the ITLB handler. if handling the fault is more complex (e.g., reading a page from storage), then let software deal with the mess
<lekernel>
yeah
<wpwrak>
(apply) a nice instant portability barrier ;-)
<Fallenou>
hehe yes I agree
<Fallenou>
but a nice technical solution
<lekernel>
and software can re-enable interrupts from the ITLB handler if it needs to (that's actually how you can have nested interrupts on LM32: reenable interrupts in sw from the isr)
<Fallenou>
a nice geeky code
<Fallenou>
(disable irq during itlb handler) yes agreed
<wpwrak>
you should look at umlsim for doing nasty things ;-) the UML (User-Mode Linux) part no longer works because of changes in UML, but the rest of the system should still be fine
<wpwrak>
(mmu) we'll also need a way to enable the MMU while in kernel mode, for things like vmalloc
<lekernel>
huh? that would be messy... kernel mode == MMU disabled
<lekernel>
microblaze does it that way... so it's possible
<wpwrak>
you'd lose the functions that avoid trouble with memory fragmentation. you should be able to fall back to the non-MMU functions, though
<wpwrak>
ah, and how about kernel accessing user mode data ? can you selectively enable the MMU for, say, the next access ? or do these functions have to walk the page tables "manually" ?
<lekernel>
reading the page table from sw looks simpler
<Fallenou>
I agree with lekernel
<Fallenou>
kernel == user mode
<Fallenou>
and accessing user land memory is done by accessing physical address (doing the lookup in software)
<Fallenou>
wpwrak: why would the kernel need to allocate virtual memory if it's not for a processus context ?
* Fallenou
is not an expert of the linux kernel
<Fallenou>
could you elaborate about vmalloc ?
<Fallenou>
how does it work in x86 ? the kernel activates the MMU even in kernel land when it needs to access "kernel virtual memory" ?
<wpwrak>
yes. MMU and kernel mode are decoupled. so you can choose whether you want to have the MMU on or not.
<Fallenou>
oh
<Fallenou>
ok I didn't know that
<wpwrak>
vmalloc allocates large sections of memory by allocating individual pages (which can be scattered all over the memory pool) and then making a single linar mapping of them
<wpwrak>
linEar
<Fallenou>
on my x86 desktop computer mmu is ON while kernel is running a syscall ?
<wpwrak>
this avoids the problem of, say, having to find an unbroken chunk of 64 kB in the page pool. finding large chunks of contiguous memory gets harder as the uptime of your system increases, since you get fragmentation
<wpwrak>
but - as long as there is any memory left at all - you can always allocate a single page
<Fallenou>
yes ok
<Fallenou>
I understand it helps if you can use virtually contiguous memory
<wpwrak>
so defensively written kernel code allocates things > 4 kB either with vmalloc or has its own strategy to break the allocation down into smaller pieces
<wpwrak>
lemme check how the MMU is switched on x86 ...
* wpwrak
blows dust from a big old book
<Fallenou>
hehe :)
<Fallenou>
I wonder how openrisc does to manage mmu_on/off
* Fallenou
will have a look
<kristianpaul>
cant just be always on?
<Fallenou>
well I can do that, it's even easier for me :)
<Fallenou>
boots with mmu off, and you can manually (with asm instr) activate/disactivate it, and it never changes by itself
<Fallenou>
if this is OK I'm very happy =)
<Fallenou>
that would mean mapping exception vectors in the mmu but .... why not !
<Fallenou>
opencores website is down =(
<Fallenou>
when you need it ... !
<larsc>
as far as I can see microblaze on linux has support for virtual memory in kernel mode
<kristianpaul>
what this mean in mmu terms? (sorru mmu noob here trying yo understand)
<kristianpaul>
sorry*
<larsc>
that the mmu needs to be on
<kristianpaul>
always?
<Fallenou>
kristianpaul: I mean if mmu is always on, you need to map CPU exception vectors (divide by zero, interrupt, page fault) to virtual memory
<Fallenou>
since they will be accessed through virtual memory (because mmu is ALWAYS on)
<larsc>
Fallenou: you could have a memory region which has always a direct mapping
<larsc>
which is as far as I know what is usually done
<kristianpaul>
Fallenou: that sounds like more "safe" to me
<Fallenou>
yes that would mean redesigning the mmu :'
<kristianpaul>
wich is good i think
<wpwrak>
wormed my way through the old i386 stuff ... the magic is done with the x86 segments there. and it does seem that the MMU is always on. you achieve the protection by permission checks in the MMU/TLB, not by choosing whether you allow a page to be mapped.
<Fallenou>
I will have a look at Cortex A8 datasheet
<wpwrak>
the TLB is populated by hardware, so you only get an exception if a page is unmapped, but not just when it's missing in the TLB
<larsc>
wpwrak: I don't think you want to take the i386 as an example for anything ;) unless it's as a bad example
<Fallenou>
well yes there is the nice "hardware page walker" which allow to just give a pointer to CR3 reg and let the MMU do all the work for you
<wpwrak>
i.e., you set up your page tables in memory and tell the MMU where they start. then the hardware takes care of the rest.
<Fallenou>
yes sure
<Fallenou>
but I won't do such a thing
<wpwrak>
larsc: yeah, "protected mode" is phenomenally perverse ;-) i already tried to leave out the nasty bits in my summary
<larsc>
if you want to do fast context switches you also want to avoid having to flush the caches on a context switch
<Fallenou>
it's too much work and it will blow the cpu performance
<wpwrak>
you could simply have kernel/user mode bit in TLB entires. when trying to access a kernel page from user mode, you get an exception. everything else is allowed.
<Fallenou>
they have a special handler for vmalloc faults
<Fallenou>
but they specifically say "a page fault in the kernel is not normal we should OOPS"
<Fallenou>
it's ok with x86 because MMU have page tree walker, but here we only have a small TLB and access to a page which is not in the TLB will generate a page fault
<azonenberg>
note the dust, i used no-clean rosin flux and apparently didn't wash enough afterwards
<azonenberg>
so the thing is a dust magnet lol
<azonenberg>
i touched up one or two shorts (caused by too much paste) with an iron but it was otherwise all reflow
<wpwrak>
in theory, "no clean" should be just that ;-)
<azonenberg>
Lol well it means it wont short your board if you leave it on
<azonenberg>
i think it looks nicer gone
<wpwrak>
do you use a stencil ?
<azonenberg>
No
<azonenberg>
just the syringe and steel needle the paste was shipped in
<wpwrak>
yeah, no clean still leaves too much of a mess. i just use water soluble and leave the details to my ultrasound cleaner
<wpwrak>
hmm. do digi-key ship needles ? couldn't find one there whe i bought my solder paste some years ago, so i mistreated one from the pharmacy. doesn't apply things in the most clean way. i get lots of pads with issues and solder residues where they shouldn't be.
<azonenberg>
chipquik flux did have a single 20ga steel needle (blunt tip, not pointed)
<azonenberg>
and paste
<azonenberg>
i buy my needles from celeritous.com
<azonenberg>
i prefer 22ga blunt-tip because its slightly more precise
<wpwrak>
move C9 and C10 a bit more out of each other's hair ?
<wpwrak>
and i would really separate D12 and R20. if anything goes wrong in the reflow, you'll have a bitch of a time getting there with a soldering iron
<wpwrak>
also C15 and C27 are very close to the FPGA pins. again not rework-friendly
<azonenberg>
ok, give me a min to play with those
<azonenberg>
i'm personally used to tight work
<wpwrak>
C33 also seems a little close to the QFN
<wpwrak>
yeah, i do it too. that's why i'm concerned about the pitfalls ;-)
<wpwrak>
btw, why not move the text in the lower left corner to the upper right and shift the LED array all the way to the left. that way, you could have a 2x5 header with 8 I/Os and a bit more clearance to the JTAG connector as well
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 252 seconds]
<azonenberg>
re c15/27 they're decouplers, i want them close
<wpwrak>
why not give them as much room as you're giving the other decouplers ?
<wpwrak>
just a bit more
<azonenberg>
i guess
<azonenberg>
c15 cant move though
<azonenberg>
too much routing nearby
<azonenberg>
the jtag connector has plenty of clearance
<wpwrak>
(C15) c'mon ;-)
<azonenberg>
it fits completely inside that silk footprint
<azonenberg>
but hmm
<wpwrak>
(JTAG) i mean considering that you may want to hook scope probes and such directly to the the GPIO connector. it's nice to have a bit of room around such things
<azonenberg>
yeah
<azonenberg>
rerouting a bit
<wpwrak>
the QFN will suck if it needs any rework
<wpwrak>
not only is C33 blocking a corner, but there's also a lot of ground there
<azonenberg>
yeah, i'm moving the led bank
<azonenberg>
give me a few mins
<wpwrak>
perhaps add a zone exclusion around U1 to have the heat traps further away. and it seems that you didn't connect the center pad
<wpwrak>
the zone settings seem a but right anyway, with zone fill reaching in between center pad and pins.
<wpwrak>
that's asking for trouble :)
<wpwrak>
for a not too nasty board, i use 0.4 mm zone clearance and 0.2 mm minimum width. that keeps the zones from crawling into areas where they shouldn't be
<wpwrak>
for a board that's already quite nasty to solder (atusb, with RF and all that fun), i have 10 mil (0.254 mm) for both
<wpwrak>
you have 0.1524 mm. even tighter
<azonenberg>
i'm designing for 6/6 rules
<azonenberg>
and reflow
<wpwrak>
i would just keep the ground zones further away
<azonenberg>
i guess
<wpwrak>
and i've never seen anyone put a zone fill between a qfn center pad and the pins. that's just begging for trouble.
<azonenberg>
that was automatic
<azonenberg>
i'll fix that
<wpwrak>
yes, because your zones are too tight :)
<wpwrak>
the mounting holes ... what's supposed to go into them ? nothing with screws, i suppose ?
<azonenberg>
4-40 screws with small heads
<azonenberg>
why?
<wpwrak>
are the heads really *that* small ?
<wpwrak>
you have almost no room between hole and the edge of the copper ring
<azonenberg>
The holes arent grounded
<wpwrak>
so either the hole is very wide or the ring very small
<azonenberg>
The ring is very small
<azonenberg>
its not intended to be grounded
<azonenberg>
but this process mandates all holes be plated
<azonenberg>
i think i have 254um clearance to the ground fill now
<wpwrak>
ground is one thing. the other is shear force as your screw scrapes over the pcb, for example transferring the trace south of P2 to the afterlife
<azonenberg>
I moved it laready
<azonenberg>
screenshot is old
<wpwrak>
lemme generate a better one ...
<azonenberg>
i havent committed my most recent changes
<azonenberg>
give me a few mins
<azonenberg>
i'm used to working on 6/6 rules with tight registration
<wpwrak>
seems a bit excessive for this sort of circuit
<azonenberg>
thats what the fab i use does
<azonenberg>
and i'm used to working at those levels
<wpwrak>
just checked the footprints ... good, you restrained yourself to no smaller than 0402 ;-)
<azonenberg>
0402 is the smallest i routinely use
<azonenberg>
i go down smaller only if forced to by spatial constraints (rare)
<wpwrak>
0402 is already more by instinct than vision :) but yes, manual soldering works remarkably well for being that small
<azonenberg>
no, its vision
<azonenberg>
i do them by hand under a microscope
<azonenberg>
then reflow
<wpwrak>
(ambitious specs) i was thinking of this board being intended also for use by wolfgang. you don't know how good his pcb fab is. and he doesn't have a lot of DIY experience yet. so this may yield a board that may be very unpleasant to work with for him.
<azonenberg>
Hmm, true
<wpwrak>
ah yes, you have your fancy microscopes ;-)
<wpwrak>
i just have instinct :)
<azonenberg>
i guess i just assumed you guys are operating at this level
<azonenberg>
i take it the M1 prototypes arent hand assembled then?>
<wpwrak>
i do my pcbs in my kitchen :)
<azonenberg>
well i do mine in the living room
<wpwrak>
ah no, M1 is a bit different ;-)
<azonenberg>
that doesnt say much considering my living room
<wpwrak>
(pcbs) i mean the etching :) layout transfer in my office, with good old toner transfer
<azonenberg>
i do photolith in my living room and have gotten to 6/6 traces, though 8/8 gives better yields
<wpwrak>
yeah. i find 8/8 a good compromise for DIY. it's small enough for all the components you'd reasonably expect to work with and it's still large enough to forgive some mistakes
<azonenberg>
well, depends on what you define by "reasonably expect to work with"
<azonenberg>
i'm DIYing 256FTBGA in the living room (though on a professionally made PCB)
<azonenberg>
personally i consider that perfectly doable as a DIY project
<wpwrak>
the back is much cleaner :)
<azonenberg>
of the big one or the small one?
<wpwrak>
hmm, C39/C46 are the sort of think fabs frown upon ;-)
<wpwrak>
and C36 (?) fell off ?
<azonenberg>
didnt fall off
<azonenberg>
it was never placed
<wpwrak>
ah :)
<azonenberg>
the fab screwed up and masked off the pad
<azonenberg>
luckily it was a noncritical decoupler
<azonenberg>
the gerber is fine
<azonenberg>
C22 had the same defect
<wpwrak>
(masked off the pad) yeah, there are a few things in there that would be considered design violations
<azonenberg>
and C39/46 passed DRC and had good spacing
<azonenberg>
i just bridged them
<azonenberg>
but they were paralleled anyway
<wpwrak>
DRC doens't find everything
<azonenberg>
so i didnt care
<wpwrak>
adam also lectured me on clearances on atben. which also passed DRC with flying flags :)
<azonenberg>
lol
<azonenberg>
i also should have used 0201 for C39/46
<azonenberg>
since they did have to be that close
<azonenberg>
a smaller component would allow more clearance
<wpwrak>
well, the cleaned up design had 100% yield for some 120 or 130 units. so i guess the advice was sound :)
<azonenberg>
lol nice
<wpwrak>
with atusb we weren't so lucky. about 3/120 didn't work. i think 2 pick and place errors (component missing) and one bad solder joint. still not too evil.