<kristianpaul>
argh, all day all wrong because a missing wire !
<kristianpaul>
fortunatly sinthesis time is now 13~ minutes :-)
<wolfspraul>
why did it come down?
<kristianpaul>
well, i just disable the cores i dont need from milkymist
<kristianpaul>
nothing special :-)
<wolfspraul>
which ones did you disable?
<wolfspraul>
and then the synthesis time came down from how many minutes to 13 minutes?
<wolfspraul>
just curious to better understand the whole thing... synthesis time is quite important in effective fpga development work, from what I can tell so far :-)
<kristianpaul>
disable usb, tmu, fmlmeter, videoin, midi, dmx and ir
<kristianpaul>
before was 35 Minutes aprox
<kristianpaul>
is the only way so far to reduce, as i dont know how to hack/enable partial reconfiguration tecniques in this spartan-6, that also may allow effective development
<wolfspraul>
from what I understand so far, partial reconfiguration will send you into development hell
<kristianpaul>
surelly
<wolfspraul>
it's this thing that the fpga industry talks about for 10 years, but I think that never really works well enough to be usable in real life, or maybe slowly it is, on some models, with some tools, etc.
<wolfspraul>
not for Spartan-6, I think :-)
<kristianpaul>
well, i dint hear lekernel complaing about it yet ;-)
<kristianpaul>
indeed
<wolfspraul>
he stays away from it because like I said, I think it's an area where the tools are just too bad
<wolfspraul>
it exists 80% in marketing, 20% in technical reality :-)
<wolfspraul>
maybe the technical reality will catch up one day, maybe with the latest chips. For s-6, we should keep our hopes low.
<roh>
its said to be one of the nicest devices for 'making elektronic music' due to its flexibility. there was some talk about building a new one, but so far it hasnt gotten of the ground again. old ones around are traded for good money and the community is still alive.
<roh>
maybe one could talk to them and see of teaming up to promote open source
<kristianpaul>
hey, good way of doing parties on datacenters ;-)
<kristianpaul>
s/on/at
<wolfspraul>
roh: excellent link, thank you very much !
<wolfspraul>
no I did not know about Chameleon before
<wolfspraul>
that marketing page is a mess, basically I'm just collecting all sorts of leads for now
<roh>
wolfspraul: well.. its not open hw and completely open source sw, but the most important parts for the users are
<roh>
maybe its possible to write code enabling people using a mm1 to apply their sound skins
<wolfspraul>
it's a nice link, very very good. Of course I don't expect people to just go crazy if they see m1, but if there is overlap, it is worthwhile to try to connect.
<wolfspraul>
and from just looking at their homepage for 2 minutes, I can definitely see overlap
<wolfspraul>
someone on the qi list pointed me to www.toplap.org, man, I had no idea something like that existed :-)
<wolfspraul>
Live Art Programming, urgh :-) I am sympathetic to their goals, but it sounds pretty exotic to me :-)
<roh>
i dunno so much about dsp(s) (yet) .. but maybe its possible to load a dsp next to the lm32
<wolfspraul>
I couldn't immediately figure out whether Live Art Programming was still alive or not, most dates seems to be around 2002-2007 or so
<wolfspraul>
maybe a short art movement :-)
<wolfspraul>
their mailing list archives are only for subscribers, that's when I gave up...
<wolfspraul>
Chameleon sounds like closer to m1 even
<kristianpaul>
(dsp) of course! mm1 spartan6 have some slices for that, check DSP48A1
<roh>
kristianpaul: is there free (open source) code for that?
<kristianpaul>
and if' i'm not bad ac97 core implemented some FIR i think
<kristianpaul>
roh: as open as the xilinx sinthesizer is ;)
<roh>
kristianpaul: because maybe one doesnt need to be binary compatible to that motorola madness to port all these filters (they are called skins)
<roh>
kristianpaul: well.. cores can be fixed and other codecs can be soldered ;)
<kristianpaul>
so about the dsp, you can implement is as xilinx library, or with a bit more of work i guess do the modeling for the accumulators and multipliers
<kristianpaul>
i guess
<kristianpaul>
(fix) i agree with first one
<wolfspraul>
roh: you are thinking about how to run some of the Chameleon stuff on m1?
<roh>
wolfspraul: exactly. what it would take to make the platform useable for people who wrote code for the chameleon before
<roh>
as in 'have real world experience with users on the resulting device/platform'
<roh>
from a first glimpse: some of the dsp code is or can be written in that specific asm
<roh>
and they provide you with an sdk to compile code for the dsp as well as libs to load the dsp with binaries from rtems (via header-includes etc)
<roh>
so porting somethint would mean removing the panel code (well.. there are 3 buttons and leds on mm1) and adding either compat layers to replicate the platform or rewriting that code portions. ah.. and redoing the asm code and or find a way to reuse it.
<roh>
s/hint/hing/g
<wpwrak>
(partial reconfig) i wonder why that would have to be so hard. could one not partition the resources in an fpga and treat partitions like independent chips ? (globally shared items would have to be characterized by the "core partition" and would be inputs to the synthesis of the other partition(s))
<wpwrak>
this would at least allow the equivalent of separate compilation.
<lekernel>
what about global clock networks and long wires that go across a partially reconfigured region?
<wpwrak>
as long as you can characterize the clock, it would be just an input to the synthesis. just like an external clock. long wires would have to avoid the reserved partitions.
<wpwrak>
and of course, you would have to set aside enough room for making the necessary connections. maybe define some handover points.
<wpwrak>
that may be crude but it would be a start. you can always add a smarter method later :)
<roh>
lekernel: hey. i sent gismo your phone number. he is/was in paris and will be in france this week
<roh>
wanted to find out which hackerspaces to visit and who to ask