<kristianpaul>
had you already wrote that setences to the mail list?
<kristianpaul>
perhaps sebastien knows, but he is not here right now
<kristianpaul>
s/perhaps sebastien/sebastien should
<Hawk777>
I haven't sent anything to the list, I hoped someone here would know.
<Hawk777>
I will though if that's more likely to get to the right people.
<kristianpaul>
sure! stay here
<Hawk777>
I will stay here as well
<Hawk777>
whichever place gets a faster answer
<wolfspraul>
can't we find out by looking at the code?
<wolfspraul>
let's see :-)
<Hawk777>
I tried, and I can't find anywhere they're implemented, but it's also my first time reading Verilog (I normally do VHDL) so I may have missed it.
<Hawk777>
It would make some sense that they not be implemented, since it might require more pipeline stages given the simple read-or-write I/O port interface on the edge of the core.
<wolfspraul>
oh I would definitely assume that comment on the navre side to be accurate
<Hawk777>
So they're not implemented?
<wolfspraul>
I don't know either, not more than you and you already looked at the sources which I am about to do...
<wolfspraul>
and I have even less hdl coding experience than you. but it's a good question and we 'should' be able to tell from the code, I would think. one sec.
xiangfu has joined #milkymist
Jia has joined #milkymist
<wolfspraul>
cores/softusb/navre_regress/test_opcodes lists even more as 'unsup'
<wolfspraul>
but including cbi/sbi
<Hawk777>
Ah, that wasn't in the download package.
<Hawk777>
I'm pretty sure the instructions aren't there, it just seemed weird because I thought GCC produced those instructions whenever you used a bitwise OR or AND of a single bit against an I/O register.
<wolfspraul>
oh I am looking at the Milkymist side
<Hawk777>
From that file it looks like the "unsup"s fall into four basic groups: SBI/CBI, SBIC/SBIS which are already stated not to work on the OC page, SLEEP/WDR which don't make sense given the context, and a bunch of stuff from the higher level CPU architectures which are also documented not to work (since it says only Classic Core instructions are implemented).
<wolfspraul>
well, like you guessed. looking at softusb_navre.v there is a big casex(pmem_d) to decode instructions, and the cbi/sbi are not in the list
<wolfspraul>
that's a regression test
<wolfspraul>
some 'unsup' may be inaccurate and it's more a case of 'don't hate test case yet'
<wolfspraul>
I just saw it, and it confirms that sbi/cbi are not there (if there would have been a test, we would have known...)
<Hawk777>
sure
<wolfspraul>
and neither can I see it in softusb_navre.v
<Hawk777>
though if there were an instruction implemented but not tested I might not want to use it anyway :)
<wolfspraul>
so, not there, my take
<kristianpaul>
neither me as well (softusb_navre.v)
<Hawk777>
but yeah, GCC definitely uses that instruction
<Hawk777>
which is a bit annoying :/
<wolfspraul>
is it hard to add them?
<Hawk777>
might not be
<wolfspraul>
without disrupting the whole pipeline/microarch etc...
<Hawk777>
I think adding the functionality inside the core would probably be hard because no other instruction simultaneously both reads and writes an I/O port
<wolfspraul>
Hawk777: btw, nice to see you here, seems you are new?
<wolfspraul>
welcome!
cladamw has joined #milkymist
<wolfspraul>
we have a group of about 5-10 people who are relatively active here and there in the milkymist universe
<wolfspraul>
if you have any questions, feel free to ask. don't hesitate about slightly off-topic things either, as long as it's related to hdl/digital design/high-performance open computing etc. we are trying to be nice and friendly :-)
<Hawk777>
But I think one could probably add some extra interface lines and do the actual CBI/SBI calculation in external logic outside the core
<Hawk777>
wolfspraul: thanks for the welcome, and yes, I got here recently :)
<wolfspraul>
do you want me to introduce a few people/nicks to you?
<Hawk777>
Sure!
<wolfspraul>
alright
<wolfspraul>
wolfspraul is me, ex-sw engineer got bored and wanted to learn about hw
<wolfspraul>
still learning
<wolfspraul>
I live in Beijing, so I just got up and sipping my morning coffee
<wolfspraul>
sebastien is the milkymist founder, nick lekernel or sb0
<wolfspraul>
he created the whole thing initially, in 2007, starting from IC design, rtems adaptation, bios, board design, flickernoise sw, etc.
<wolfspraul>
he lives in Berlin but currently traveling back from a trip to the US
<wolfspraul>
then kristianpaul :-)
* kristianpaul
hides
<Hawk777>
heh
<wolfspraul>
he lives in Buga/Colombia and hacks on various things but on the milkymist mostly a gps baseband
<wolfspraul>
and werner, nick wpwrak. living in the paris of the south aka buenos aires
<wolfspraul>
he fixed more difficult bugs on the m1 board than anyone else I think
<wolfspraul>
fallenou in Paris, currently working on adding a mmu to lm32
<wolfspraul>
mwalle somewhere in germany I think (?), also hacking on various parts, recently some really nice USB fixes and improvements
<kristianpaul>
he also ported rtems to the M1 (fallenou - Yann)
<wolfspraul>
adam wang (nick cladamw) in taipei, who is doing the production and testing of boards and products
<wolfspraul>
oh sure, I probably brutally cut short any 'credits' here, just trying to intro a few folks
<wolfspraul>
who else - roh in Berlin (raumfahrtagentur.org) who designed and manufactured the cases
<wolfspraul>
lars-peter clausen (nick larsc) who did some work on the Linux port a while back which is currently in hibernation, but maybe it comes back one day...
<wolfspraul>
and more, but that gives you a start
<Hawk777>
cool
<Hawk777>
sounds like a good number of people working on this project
<wolfspraul>
fairly global. europe, russia, china, south america
<wolfspraul>
actually I think north america is a but under-represented :-)
<Hawk777>
+1
<wolfspraul>
yes, a few people. like I said maybe 5-10 is fair to say
<wolfspraul>
but keep in mind that it's such a wide subject, so we are spread very thin and I'm always worried it will fragment and disappear to nowhere
<wolfspraul>
we have GCC compiler bugs that nobody finds the time to fix for years
<wolfspraul>
bugs here, bugs there
<wolfspraul>
it's tough
<Hawk777>
Myself, I'm in Vancouver, Canada. I found my way here from looking for a GCC-compatible microcontroller on Opencores that was small enough to fit in my FPGA.
<wolfspraul>
nice
<wolfspraul>
whichi fpga do you have?
<Hawk777>
Spartan 6 XC6SLX9
<wolfspraul>
beautiful little chip, I actually have one in front of me right now :-)
<wolfspraul>
(seriously)
<Hawk777>
Fairly small, but the largest in the family that's sanely hand-solderable.
<wolfspraul>
qfp package, bought it on the market the other day because I want to try to make my own home-pcb for it
<Hawk777>
AFAICT
<kristianpaul>
Hawk777: from avnet?
<Hawk777>
Digikey.
<wolfspraul>
Hawk777: *exactly* what I have in mind right now
<wolfspraul>
it's in front of me
<wolfspraul>
Hawk777: please keep us posted about your endeavor, and if at all possible, publish some sources and documentation
<wolfspraul>
and feel free to reuse *anything* from the milkymist project that may help you
<Hawk777>
We did a professionally-printed PCB followed by hand assembly with liquid flux and normal wire.
<wolfspraul>
the lm32 is also a small core, is navre even smaller?
<Hawk777>
Last year we used an external MCU along with an FPGA, but the board is a lot easier to route without that.
<wolfspraul>
how many resources do you currently need on your slx9, for which part?
<wolfspraul>
you have something synthesized and running already?
<Hawk777>
just starting out, really
<kristianpaul>
how do you program it?
<Hawk777>
we have code from last year but it was for a Spartan 3A, so given the different LUT structure it's not really clear what it'll end up looking like
<Hawk777>
kristianpaul: how do we program which?
<wolfspraul>
kristianpaul: do you know how many resources a navre core needs compared to a lm32 core?
<kristianpaul>
wolfspraul: dont know really, guess no more than 300 LUTS
<Hawk777>
The Opencores page says Navré is 1 kLUT, which for an SLX9 is a bit under 1/5 of the chip.
<kristianpaul>
oh
<kristianpaul>
and just lm32 is 2.5K.. i bet navre was smaller
<Hawk777>
But I'm happy to look at LM32 if it'll be smaller while still reliable (I *really* don't want to deal with compiler bugs; a large part of the reason I'm moving away from PICs is that SDCC is the only free Linux C compiler for PICs and I filed about a dozen bugs on it within a few months)
<kristianpaul>
oh please
<Hawk777>
Whereas avr-gcc also targets hard AVRs, so that's pretty well tested.
<wolfspraul>
kristianpaul: oh please?
<kristianpaul>
yup, i meant i used to work with PICs too
<Hawk777>
heh
<wolfspraul>
you share the same feeling?
<Hawk777>
I have no problem with the hardware, but SDCC…
<kristianpaul>
with those ones ueses SDCC yes
<kristianpaul>
s/ueses/uses
<wolfspraul>
ok sounds like navre is still smaller than lm32
<kristianpaul>
then i discover M1 and stop my self learning about PICs in general
<Hawk777>
huh, well, the good news is I copied the file into my project and XST didn't explode :D
<wolfspraul>
plus, we also have gcc compiler bugs on lm32, though I think mostly in C++, not C
<kristianpaul>
and learning about this milkymist soc written in verilog ;-)
<wolfspraul>
kristianpaul: and? far better, no? :-)
<wolfspraul>
I think it is, more potential to have a programmable cpu, as long as we get the compiler well working or even dedicated new compilers in the future (for experimental new cores).
<kristianpaul>
at least i have the HDL sources :)
<kristianpaul>
far better from sdcc yup :)
<wolfspraul>
yes
<wolfspraul>
Hawk777: will you or can you publish sources and documentation/posts about your project?
<wolfspraul>
please keep us posted, we are definitely interested in hearing from you, or at least I am :-)
* kristianpaul
too
<wolfspraul>
I plan to embark on a similar slx9-at-home project the next few weeks, which will mostly be talked about and documented in the #qi-hardware channel, and/or here
<wolfspraul>
my main goal is the fast pcb turnaround first of all, make a pcb in a few hours
<kristianpaul>
workshop :-)
<wolfspraul>
kristianpaul: you also wanna join? :-) I will start soon, document the process in the wiki etc. I think we may have most bits and pieces already or they are floating on the web. lots of people doing this, but it can come in handy in many situtations.
Jia has quit [Read error: Connection reset by peer]
<kristianpaul>
i'll join if i can do it at hoem too :)
<kristianpaul>
but for now i'll read your logs
<Hawk777>
Publishing information is something all the teams are encouraged to do, but we haven't really had time to organize. We keep talking about it though.
<Hawk777>
Source code, both software/firmware/VHDL, documentation, that sort of thing.
<wolfspraul>
just do it? :-) github or so probably your easiest way, no?
<kristianpaul>
s/if/when able/
<kristianpaul>
i mean manufacture
<wolfspraul>
sorry don't understand
<kristianpaul>
you plan made a SLX9 board at home no?
<kristianpaul>
s/made/make
<wolfspraul>
ah
<wolfspraul>
actually I haven't thought about the real target yet
<kristianpaul>
ah i see
<wolfspraul>
I just bought this slx9 because I saw a xilinx shop in the market who pretty much has all variants in stock
<wolfspraul>
so I just picked this one up for about 9 USD (ca. 15 USD on digikey)
<wolfspraul>
it's not worth for me to go around later to buy something for a few USD, so I tend to just buy "a few usd" items when I see them, without knowing exactly what I will end up using them for
<wolfspraul>
like Hawk777 said, it's xilinx most powerful qfp-packaged fpga right now
<wolfspraul>
altera has a few too I think, with 14k cells or so, but I feel more comfortable in the xilinx universe right now
<wolfspraul>
maybe I make a board that combines the slx9 with werner's atrf thing? I don't know yet
<wolfspraul>
my first step is the process, make it fast and cheap and well documented.
<kristianpaul>
I like those words, and even more coming fro you
<kristianpaul>
from*
<kristianpaul>
My rought plan, will be convice some friends build its own LX9 board, since M1 is not for their interest now
<wolfspraul>
ok I have to run now, but back later
<kristianpaul>
bye
<wolfspraul>
we can discuss in #qi-hw soon, maybe align some plans
<wolfspraul>
it's all about reusing and contributing back to the same ecosystem, for me
rejon_ has joined #milkymist
<Hawk777>
I just realized there's a ridiculously easy way to prevent GCC from using SBI/CBI instructions: put all the I/O ports from addresses 32 through 63 :D
<wolfspraul>
there you go, sounds good :-)
rejon_ has quit [Ping timeout: 260 seconds]
<wpwrak>
wolfspraul: i'd suggest to keep it as simple as you can for your first project. there's plenty of stuff to learn. better to not spoil it with too ambitious goals :)
rejon_ has joined #milkymist
Jia has joined #milkymist
rejon_ has quit [Ping timeout: 260 seconds]
<kristianpaul>
wpwrak: that is no ram/flash, no nothing more than the enought to make the boad load a bitstream from jtag
cladamw has quit [Quit: Ex-Chat]
cladamw has joined #milkymist
<lekernel_>
Hawk777: or use the rio8/wio8 macro like the softusb firmware does
<Hawk777>
ah, I could do that
lekernel_ is now known as lekernel
Jia has quit [Read error: Connection reset by peer]
Jia has joined #milkymist
rejon_ has joined #milkymist
fpgaminer has quit [Ping timeout: 250 seconds]
fpgaminer has joined #milkymist
cladamw has quit [Quit: Leaving]
* xiangfu
merged 'hid' branch to 'master' under milkymist
<lekernel>
we've always set the offset without problems. what is that fixing?
<xiangfu>
I added that set. then I found that is wrong. so I only revert that one line.
<lekernel>
ah, yes
<xiangfu>
I cannot find where they set the new offset.
Gurty` has joined #milkymist
xiangfu has quit [Remote host closed the connection]
fpgaminer has quit [Ping timeout: 244 seconds]
Guest55342 has quit [Ping timeout: 265 seconds]
fpgaminer has joined #milkymist
rejon has joined #milkymist
<wpwrak>
(slx9) hmm, QFN or QFP ? QFP is more beginner-friendly than QFN. the one i see on digi-key has a lot of pins, though. not sure you want to start with something so big.
<cladamw_>
wpwrak, this one is only J27 mounting hole hasn't been moved south 1.5 mm a bit. else are okay last one we reviewed.
<cladamw_>
wpwrak, if there's no big problems discovered, I'll tell house to start to route.
<wolfspraul>
cladamw_: hi good evening
<wolfspraul>
are the AD and kicad schematics 100% equal now?
<wolfspraul>
in other words - are the kicad schematics finished?
xiangfu has joined #milkymist
<cladamw_>
good evening
<xiangfu>
good evening.
<cladamw_>
KiCad m1r4 has edited done. wpwrak said he'll check item-by-item for comparisons.
<cladamw_>
more one person to double check it good idea.
<cladamw_>
s/it/is
<cladamw_>
so yes, i think KiCad m1r4 I finished, regards to if all 100% equally, need to check. :)
<wolfspraul>
good
<wolfspraul>
then the next step is to cover the entire bom in boom
<wolfspraul>
right/
<wolfspraul>
?
<cladamw_>
yes, after equalization.
<wolfspraul>
ok good
<cladamw_>
wpwrak, summaries: 1) U26, C178, C256 ~ C260 go to bottom, 2) C286 goes to east of DMX TX, 3) TP32, TP38 - TP41 go to top, and else small fix in design files
<cladamw_>
wpwrak, I'll see backlog tomorrow if you discover somethings, pls note here.
TachyonDev has joined #milkymist
cladamw_ has quit [Quit: Ex-Chat]
<wpwrak>
wolfspraul: depends on your definition of finished ;-) they still need the 1:1 check and there will be more changes (to parameters) as we boomify them
rejon_ has joined #milkymist
xiangfu has quit [Ping timeout: 272 seconds]
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
<wpwrak>
roh: do we have the exact mechanical specification of the spacers and screws of M1r3 ?
<wpwrak>
(i mean the dimensions. don't care about forces and such :)
voidcoder has quit [Read error: Connection reset by peer]
voidcoder_ has joined #milkymist
voidcoder_ has quit [Client Quit]
voidcoder has joined #milkymist
<roh>
wpwrak: dimensions... i think so. would need to look it up tho
<roh>
i think something like 5 and 30 mm long, m3, one inner outer (the short one) and one inner inner
<roh>
means the 'nut' is 5.5mm outside
<wpwrak>
cool. i measured the head right then :) now i need the thread and the tolerances
<wpwrak>
you'll what i'm after in my next post to the list. in a minute ...
elldekaa has quit [Ping timeout: 265 seconds]
azonenberg has quit [Remote host closed the connection]
voidcoder has quit [Quit: See you next time]
elldekaa has joined #milkymist
<kristianpaul>
ss
<kristianpaul>
damn
<wpwrak>
posting sent
<wpwrak>
roh: i hope it's decodable ;-) mixes information from quite a few sources
rejon_ has quit [Ping timeout: 272 seconds]
azonenberg has joined #milkymist
voidcoder has joined #milkymist
<roh>
wpwrak: the thread and the tolerances should be in the din norms for m3 etc ;)
sh4rm4 has quit [Ping timeout: 276 seconds]
<wpwrak>
hmm, let's see if wikipedia has all the data
<wpwrak>
now, the shape and size of the screw head and the hex spacers ...
<roh>
ah. hm.. well.. the spacers are 5.5mm from the parallel side to the other. so 'shortest path'
<roh>
so i dunno ig 6.1 is enough not to scratch a pcb trace when screwing in
<roh>
s/ig/if
<roh>
also there needs to be some horizontal tolerance, the holes are 3.2 or 3.5 or so, to get it all aligned
<wpwrak>
(5.5 mm) are you sure ? i think that's corner to corner. side to side should be 5.0-ish
<wpwrak>
(tolerance) yeah. see my mail :) i actually forgot a few factors of two, when using things that are radii, but i hope i've covered all the important parameters
<roh>
havent measure it. but for m3 nuts and spacers one usually uses a 5.5mm 'schluessel' or nut bit
<wpwrak>
of course, improvements welcome :)
<roh>
in case of doubt, keep the top layer clean a mm more diameter then needed ;)
<wpwrak>
maybe the 5.5 is the outer diameter then
<wpwrak>
yeah :)
<roh>
or just make the pad bigger, round (the gnd pad)
<wpwrak>
i just want to have a clear lower bound. since we need quite a bit of extra space. and adam like things a little cramped :) (well, i do the same when trying to squeeze a layout into a tight space)
<roh>
i'd keep 3.5mm minimum radius around the center of the hole clean. better 4.0mm radius
<roh>
or even simpler.. hole dia * 1.15 = keepout_radius
<wpwrak>
yeah, 3.5 mm sounds good to me. 4 mm may complicate placement, though
<roh>
the hole is 3.5
<roh>
as i said.. its neccessary for alignment on putting it together.. so the spacers can be off center to the max and thats normal
<wpwrak>
ah, that's narrower than i guesstimated. good.
<wpwrak>
sure. designing with zero tolerances is a good way to make sure what you do will never fit/work ;-)
<roh>
heh. i was wrong
<roh>
the nuts are really 5.0 flat to flat
<roh>
thats 5.5 to 5.6 worst case diagonal.
<roh>
so 3.5 radius is small but maybe fine
<roh>
make it 3.6 or 3.7 and we have some safety margin in production etc (who knows how precise they drill etc)
<wpwrak>
so this implies the spacers are thinner than the head of a nut would be
<wpwrak>
which kinda makes sense
<roh>
well.. yes and no.
<roh>
i think one can get the spacers also in 5.5mm
<roh>
seen those too. didnt specifically buy thin ones. didnt care. bought the cheaper, more reliable to get ones
<roh>
so i will not have problems in sourcing them again
<wpwrak>
;-)
<wpwrak>
i have some pseudo M3 at home. they almost fit but not quite. probably some imperial thingy. they're fat - about 6.5 mm on parallel hex sides
<wpwrak>
it may also make sense to have enough tolerance that people can use things they find at a hardware store. e.g., when they lose a screw
<GitHub13>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/yBJ_nQ
<GitHub13>
[milkymist-ng/master] bios: more DDR diagnostic functions - Sebastien Bourdeauducq
<wpwrak>
looking around a bit, i think it's fair to say that there are no standard sizes for anything but the thread itself ;-)
hypermodern has joined #milkymist
elldekaa has quit [Ping timeout: 250 seconds]
_whitelogger has joined #milkymist
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 272 seconds]
antgreen has joined #milkymist
hypermodern has left #milkymist [#milkymist]
TachyonDev has quit [Quit: Leaving.]
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
<kristianpaul>
wpwrak: big, because been LQFP and having more than 100 pins?
antgreen has quit [Read error: Connection reset by peer]
<wpwrak>
yeah, a LOT of pins
<wpwrak>
not the sort of thing i'd recommend for a first-time project
<kristianpaul>
but if you dont have I/O what is left to play... jtag?
<kristianpaul>
well not sayiing it will not, but wast in first place something easy to solder, even if you dont populate the BIG chip :)
<kristianpaul>
i think xilinx have form factor fgpa like those tiny IGLO with QFP either..
<kristianpaul>
let see
<kristianpaul>
TQG144 seems only smaller, well Hawk777 already told us that too..
<wpwrak>
kristianpaul: the thing is that the FPGA is a much more complex system. you need more parts, the system goes through several states just to boot, and so on. so if you make any mistakes building the board, then it's a lot harder to debug the thing.
<wpwrak>
compare this with an MCU: there, you get a basic functional test when you upload the code. few if any external components involved. the turn-around times for making code changes are very short. so you're quickly at the point where you can access simple peripherals. e.g., LEDs and buttons.
<wpwrak>
by avoiding complexity in the system, it's much easier to detect and solve manufacturing issues. and DIY tends to have such issues, particularly if you start without experience.
froggytoad has joined #milkymist
<wpwrak>
the fpga probably also needs an external clock source. MCUs usually have in internal RC clock. then that FPGA seems to need an 1.2 V supply. so you can't just feed it from, say, a Ben.
<wpwrak>
it's just way too complex for a "getting started with DIY PCBs" project. better to take things only a few steps at a time.
jesse_ has joined #milkymist
fpgaminer has quit [Read error: Connection reset by peer]