<wolfspraul>
I was wondering what rough priorities you have now about Milkymist, going forward
<wolfspraul>
new year thinking
<wolfspraul>
we saw the big migen stuff, that looks very promising
<wolfspraul>
any timeline in mind? how will this evolve? what to expect? how can anybody help?
<wolfspraul>
on the manufacturing side, I will focus on rc4 next few months
<wolfspraul>
and as we make rc3 better and better, more aggressive and systematic rc3 sales and marketing efforts
<wolfspraul>
would it help anybody if m1 switched to the slx75 variant? for example let's assume the slx45 and slx75 would cost the same.
<cocoadaemon_>
ah oui pardon register
<wpwrak>
slx75 seems to have a lot more gates. are they really so close in price ? of course, the more gates, the merrier, in general
<wolfspraul>
that's why I ask
<wolfspraul>
I just try to understand the decision making process better, or rather document it
<wolfspraul>
the smaller variants are not an option, I'm sure
<wolfspraul>
slx25
<wolfspraul>
because I think even today, the milkymist bitstreams would hardly fit into an slx25, and there would be no room for development/experiments
<wolfspraul>
then on the other side there are the slx75, slx100 and slx150
<wolfspraul>
the problem with the slx100 and slx150 is that the free ISE will not synthesize for them, so you either need to pay big bucks, find an academic license somewhere, or just use pirate software as Xilinx's FAEs are happily handing out to their customers in China... :-)
<wolfspraul>
I actually expect more closedness on the tools side gradually, but let's make decisions one by one as they suit us
<wolfspraul>
so I think for reasons of easy and free synthesizability today, we should stay away from slx100 or slx150 on m1
<wolfspraul>
that means we're down to slx45 or slx75
<wolfspraul>
would it be hard to support both? I guess the slx75 would need a different bitstream? I don't know
<wolfspraul>
that's why I'm asking, hypothetically - *if* the slx75 would cost the same as the slx45, is it then something one might want in m1? or even then it's rather NO...
<wolfspraul>
I assume it's a little more expensive, yes. maybe 5 USD? I don't know. I'm not saying we should switch or anything, I just try to understand what the reasons in slx45 vs slx75 could be if they would cost the same...
<wpwrak>
how much do you pay for the 45 ?
<wolfspraul>
for example I personally would not want the slx100 because it would force us to email cracks around...
<wolfspraul>
I pay 39 USD
<wpwrak>
yeah, tools are essential
<wolfspraul>
yes but we are at the mercy of the big guys here, they decide
<wolfspraul>
so the slx45 costs 35-50 USD maybe
<wolfspraul>
the one we have
<wolfspraul>
-2 speed grade, commercial
<wolfspraul>
at digikey maybe 60 USD
<wpwrak>
extrapolating from digi-key pricing, a ~75 would cost you around usd 65 then.
<Fallenou>
wolfspraul: yes different fpga => different bitstream
<wpwrak>
68.76 at digi-key. the other 113.25-119.63
<wolfspraul>
I think the gates & pricing is pretty linear
<wolfspraul>
the slx45 costs me ca. 40 USD, the slx150 ca. 120 USD
<wolfspraul>
yes yes, sure
<wpwrak>
(the cheaper one is the ~T. not sure if they're interchangeable)
<wolfspraul>
but I didn't want to ask about prices
<wolfspraul>
those I know alraedy :-)
<wolfspraul>
I was asking about bitstream compatibility - Fallenou just answered that - thanks!
<wolfspraul>
so if m1 rc4 would have an slx75, that would create some effort to support in software update, if we want to support all our m1 customers well, with updates
<wolfspraul>
that alone is a reason to not want it, even if it costs the same as slx45
<wolfspraul>
let's see whether sebastien sees any upside for milkymist in more cells
<wolfspraul>
I think the slx45 today is only ca. 50% used
<wolfspraul>
or so
<wolfspraul>
but then I sometimes here this or that feature would 'take up too many resources'
<wolfspraul>
so I don't know, just asking
<wpwrak>
i still think it's merely a question of time until we need different bitstreams.
<wpwrak>
so i wouldn't consider this a blocker
<wpwrak>
or red flag
<wolfspraul>
sure sure, I don't disagree but it's all work
<wpwrak>
even less free tools would be, though
<wolfspraul>
I am wondering whether Sebastien sees any value in more free fpga resources
<wolfspraul>
anyway, small question
<wolfspraul>
the more important ones I had was to understand sebastien's bigger planning for the next months, what he's excited about, how we can help
<wolfspraul>
migen
<wolfspraul>
all that
<lekernel>
wolfspraul: FAEs aren't handing out software only in China
<lekernel>
lx75 isn't bitstream compatible
<lekernel>
plus
<lekernel>
there's about half the current chip available
<lekernel>
and it's not like everyone's trying to do stuff on our FPGA, most people do not care and buy a digilent atlys because it's cheap
<lekernel>
or even papillio lol
<lekernel>
if you want an easy and meaningful FPGA replacement, use the -3N variant
<lekernel>
same price as the -2, faster, but without that memory controller we do not need
<lekernel>
(-3N wasn't available when I designed the original M1 schematics, that's why we do not use it...)
<lekernel>
but it's a drop-in replacement
<lekernel>
(in theory, at least)
<wpwrak>
how much faster ?
<lekernel>
20-30% more MHz
<wpwrak>
for core and memory ? or just core ? or just memory ?
<lekernel>
it's just faster silicon...
<lekernel>
so, everything is faster
<wpwrak>
kewl. sounds like a winner :)
<lekernel>
then the software has to detect -3N and reprogram the clock generator to increase the system freq
<lekernel>
so the bitstream stays compatible with -2 boards
<wpwrak>
so there's nothing else in the circuit that would have to change ? routing, caps, ... ?
<GitHub45>
[liboscparse] sbourdeauducq pushed 1 new commit to master: http://git.io/6rWFIA
<lekernel>
it's just a chip with smaller internal delays
<lekernel>
now we can, of course, experience unexpected murphic effects when trying -3N :)
<wpwrak>
excellent. sounds like a quite desirable change. also for making the point that we don't need that memory controller :)
<wpwrak>
no risk, no fun :)
<lekernel>
wpwrak: btw, the "severly dysfunctional compiler" bug is gone since your last round of changes
<wpwrak>
whee ! good riddance, whatever it was :)
<wpwrak>
btw, fragment->bind_mode == FPVM_BIND_NONE never seems to happen, not now and not in the future, right ?
<lekernel>
not afaik... but it used to
<wpwrak>
(i'm looking into better tracking of when and how a variable is used. might move register assignment into FN, too. that way, we could have a proper symbol table there.)
<wpwrak>
(register assignment) at the FPVM level
<wolfspraul>
lekernel: understood about -3N, I shall investigate :-)
<wolfspraul>
so you wouldn't want the SLX75 even if it were same price?
<wolfspraul>
the main argument being that we have 'enough' free resources on the slx45 as it is
<wolfspraul>
that is fine by me, I just try to understand...
<lekernel>
yes, and switching to SLX75 will definitely break bitstream compatibility
<lekernel>
(even if you can find a pin-compatible package)
<wolfspraul>
if you don't like it, it won't happen anyway (slx75)
<wolfspraul>
the argument is "we haev enough free resources, let's use those first", which is perfect
<wolfspraul>
I will look into -3N though
<wolfspraul>
-N3 rather
<wolfspraul>
how about my other questions?
<wolfspraul>
can you give us some update on your thinking now? where is migen going?
<wolfspraul>
how can others help?
<wolfspraul>
I will focus on rc4 next months and I feel there is a lot of good valuable stuff to do, which will help us in the short and long run
<wpwrak>
wolfspraul: how are things on the DVI front ? how will this be tackled ? is there anything that can be prototyped without a new PCB ? if not, what are the preconditions for that PCB run ?
<wolfspraul>
DVI front. Sebastien's mail is the last stop.
<wolfspraul>
I think the consensus is that dual-link provides little or no value, so probably no need to take the hassle
<wolfspraul>
let's focus on making single-link work fast and well
<wolfspraul>
no rerouting of existing pins
<wolfspraul>
can things be prototyped, hmm
<wpwrak>
(sebastien's mail) from october ? ("DVI notes")
<wolfspraul>
theoretically always, but is there a need?
<wolfspraul>
it's a lot of work, I mean maybe one could make an expansion board/wiring today and make this work?
<wolfspraul>
I rather just go the direct route, that is layout house, review, make pcbs
<lekernel>
I don't think so, we aren't exposing the right FPGA pins and the tracks do not have the appropriate dimensions
<wolfspraul>
alright then
<wpwrak>
okay, then the path seems clear :)
<lekernel>
regarding migen, it's more long term stuff. headed for a major redesign of the soc ...
<lekernel>
which we will need to properly support memories like DDR3 (in the future, but the current DDR will benefit as well) and more complex GPU acceleration
<wpwrak>
(migen) but it's still a prerequisite for more bits per pixel ? or are you thinking of implementing this the "old way" for now ?
<lekernel>
no, I'm not thinking about implementing stuff the old way... and do everything at the same time
<lekernel>
more memory bandwidth
<lekernel>
higher bpp
<lekernel>
new design flow
<wolfspraul>
any way to help? what's a realistic timeline?
<wpwrak>
wait .. did the negation apply to doing everything at the same time too ? :)
<wolfspraul>
1. ways to help 2. realistic timeline ?
<wpwrak>
wouldn't call migen "long term stuff" then, though. that always sounds like "blue sky research" ;-)
<lekernel>
#1 most of the migen work require precise knowledge of HDL and low-level architecture, and unfortunately we do not have many contributors here with these skills. I'm trying to "recruit" though, by asking if some other FPGA people would like to use it for their projects.
<wolfspraul>
I am hoping at some point that the fun-to-use m1 will become a platform people enjoy as a starting point
<wolfspraul>
I could never understand how someone can be motivated on a random devel board - everything will end with the most difficult bugs unfixed etc. well. maybe thesis & grade is done, and then forget it :-)
<wolfspraul>
sooner or later we will get that rolling on m1
<wpwrak>
yeah. it's a pity so many spend time porting fragments of our stuff to devel boards
<lekernel>
well, Migen hopefully will address that as well, by making SoC design easier than messing with bus wires manually in verilog
<wolfspraul>
yeah well
<wolfspraul>
so you are very determined on migen it sounds
<lekernel>
of course, I'm sure the first thing I'll see will be a limited migen soc for some other FPGA board. well...
<wolfspraul>
I'm always a bit worried you feel the m1 progress is too slow, even though a lot of people actually work very hard, and I believe we make substantial and valuable progress
<wolfspraul>
but it doesn't show yet in results, admittedly
<wolfspraul>
community, sales, reach
<wolfspraul>
what is a realistic timeline for migen?
<lekernel>
assuming no one contributes to the core of it, it'll take some time
<lekernel>
and I'll have to redesign an out-of-order and frequency-doubling DRAM controller to work with the new bus system, which can potentially provide a ~4x increase in bandwidth, but may be hard to get to work
<lekernel>
months, definitely
<lekernel>
wpwrak: migen isn't blue skies research. there are already practical results, like being able to semi-automatically integrate the SoC with code such as https://github.com/milkymist/milkymist-ng/blob/master/top.py instead of messy manual verilog coding
<lekernel>
and this stuff does work on the real hw
<lekernel>
there will, indeed, be some blue skies research in some areas of migen flow, but those areas aren't absolutely necessary to get things to work
<wpwrak>
lekernel: oh, i understand it isn't blue sky research. just "long term" has that sound to it. well, blue sky or old school communism with central planning for the next decade ;-)
<wpwrak>
lekernel: so when you write "long term", i can see wolfgang flinch :)
<lekernel>
he, for the shorter term stuff, we might have Peter helping with the doc. this has a quite some potential for helping the project imo.
<wpwrak>
oh yes, better doc is great. i didn't comment your mail, but all that sounds very good
<lekernel>
and that doc may actually be read :)
<wpwrak>
your is being read too, but ... :) (speaking of the FN manual)
<wpwrak>
s/your/yours/
<wolfspraul>
lekernel: sounds great [migen] how can we make you happy throughout the process?
<wolfspraul>
so you feel some pride and success in Milkymist and it's fun to hack on migen :-)
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wpwrak>
*hmm* massive cleanup in RTEMS ? just did an update and there's a gazillion of changes
<wpwrak>
and of course, it doesn't compile anymore. oh, joy ...
<wpwrak>
time for pinning ...
<wpwrak>
just .. to what ? :-(
<wpwrak>
the rtems git isn't in operation yet, is it ?
<lekernel>
in theory, it is
<wpwrak>
oh, cool. let's see if i have more luck there
<wpwrak>
git has the problems, too: undefined reference to `rtems_shell_init_env'. and also rtems_shell_main_mv, bootp_strdup_realloc
<lekernel>
yes
<wpwrak>
cvs date 2011/12/01 seems to be okay, though
Technicus [Technicus!~Technicus@DSLPool-net208-2.wctc.net] has joined #milkymist
<lekernel>
[florian]: happy birthday!
<wolfspraul>
lekernel: would you have a problem with us transferring the m1 schematics and layout into kicad?
<wpwrak>
wolfspraul: perhaps some background would help (besides the general long-term goal of moving to free and open tools)
<wpwrak>
i.e., that the idea is to better automate sourcing with boom. boom is aligned with kicad. plus, it would be kinda inconvenient if i couldn't generate "real" boms for testing :)
<wpwrak>
wolfspraul: and i think "transferring" may mean a dual approach, with the layout possibly still in altium. or have you dropped that possibility ?
<wolfspraul>
no, not
<wpwrak>
(layout in altium) so that would mean parallel schematics. similar to what we have for the ben.
<wolfspraul>
yes maybe the schematics first, I haven't thought it through in detail
<wpwrak>
and, if the layout is still to be done with altium, then only the altium schematics would be used for the layout. while the kicad schematics would be used for the bom.
<wpwrak>
(and possibly other things, like schematics diffs)
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
Gurty [Gurty!~princess@ALyon-256-1-118-233.w90-14.abo.wanadoo.fr] has joined #milkymist