<kristianpaul>
azonenberg: indeed what happened witht the cmos.. you were're building some tools last time i heard
<kristianpaul>
homecmos*
<azonenberg>
kristianpaul: Yes, things are going slow because of school
<azonenberg>
i'm still working on the spin coater and CNC microscope stage
<wolfspra1l>
and because azonenberg is doing 20 things in parallel :-)
<wolfspra1l>
no
<wolfspra1l>
50
<kristianpaul>
;-)
<azonenberg>
wolfspra1l: I'm a bit of a barrel processor
<azonenberg>
I need lots of threads to get maximal utilization
<kristianpaul>
cde: in my enormous ignorance i think the kernel should be incharge of memory management anyway
<wolfspra1l>
I somehow think I must be days or maybe 1 week away from generating my first simple designs that can run in an slx9
<wolfspra1l>
then I will bug xiangfu about why they don't run, and/or ruin his chips :-)
<azonenberg>
wolfspra1l: :)
<wolfspra1l>
what's missing now is essentially to fill in more pieces everywhere, the architecture is all fine
<wolfspra1l>
better autotester
<azonenberg>
Nice
<wolfspra1l>
just lots of implementation details
<wolfspra1l>
more routing switches
<azonenberg>
I'm going to work on higher level tooling stuff for now
<wolfspra1l>
more inter-tile connections
<wolfspra1l>
auto-crc
<azonenberg>
and operate under the assumption that at some point your code will get mature enough that i can generate your native file format instead of XDL output from my tools
<wolfspra1l>
(maybe I can ask the chip to skip auto-crc checks for now)
<wolfspra1l>
that is fine, I continue and also very open about how far I am
<wolfspra1l>
at this point, the only bitstream I can generate is still "the empty bitstream"
<wolfspra1l>
:-)
<wolfspra1l>
I must have implemented the most inefficient way to generate an empty bitstream
<wolfspra1l>
there's about 100 switches in the routing switchbox that bug me right now
<wolfspra1l>
between the long (4-tile) wires
<wolfspra1l>
back to work...
rejon has joined #milkymist
xiangfu has joined #milkymist
<kristianpaul>
nice indeed :)
<kristianpaul>
cde: is a fair point this about trully free os, but we cant negate the comodity of having stuff like ELF.. but yeah the binary only thing seems a good excuse for mmu
rejon has quit [Ping timeout: 276 seconds]
rejon has joined #milkymist
rejon has quit [Quit: Leaving]
rejon has joined #milkymist
rejon has quit [Ping timeout: 240 seconds]
rejon has joined #milkymist
azonenberg has quit [Ping timeout: 245 seconds]
kilae has joined #milkymist
mumptai has joined #milkymist
lekernel_ is now known as lekernel
<lekernel>
kristianpaul: that's the "recent reimplementation" I mentioned
<cde>
thanks. was there a particular requirement for the slx9 as opposed to using the M1 as a testbed?
<cde>
I guess you can experiment more wildly with it, in particular wrt/ I/O since it would cost less if destroyed
<Fallenou>
slx9 is much more "simple" than M1
<Fallenou>
and fpga is smaller, simpler I guess
azonenberg has quit [Ping timeout: 245 seconds]
<Fallenou>
easier to do bitstream generation experiment on small fpga + small board
<wolfspra1l>
I agree with Sebastien that the llhdl and antares sources are not worth looking at, but a plain 404 is a little cheap imho and there should be some more helpful text for newbies. alas, milkymist was always tough for newbites. if you survive here you survive anywhere :-)
<wolfspra1l>
and no, fpgatools is not much better today, also just experimental
<wolfspra1l>
but I will never delete it for sure, worst case there will be a note in the README in case it goes nowhere
<wolfspra1l>
it's pouring cats and dogs in beijing right now, so tomorrow the roads will be flooded - yay! :-)
<wolfspra1l>
cde: if you have questions about fpgatools, please let me know as I need to collect some to write the FAQ...
<wolfspra1l>
that would be very helpful - thanks!
<lekernel>
wolfspra1l: reconsidered your "no documentation - read the source" line? :)
<wolfspra1l>
yes, of course
<wolfspra1l>
that was just at the beginning
<wolfspra1l>
making the start easy is my real passion
<wolfspra1l>
if it's not easy to get started, it doesn't work
<wolfspra1l>
but nothing works today, so no need to waste time looking at it except to ask questions maybe...
<cde>
wolfspra1l: oh, it's not so though. the IRC channel is quite helpful :) I'll be sure to ask here if I have questions
<cde>
*tough
<cde>
what are the major blocking points in fpgatools today, that is areas that need assistance?
mumptai_ has joined #milkymist
<wolfspra1l>
if you are a good C programmer, you can start playing with the code today
<wolfspra1l>
the next working items are more or less describe in the todo, as
<wolfspra1l>
more routing switches
<wolfspra1l>
more inter-tile connections
<wolfspra1l>
more iob and lut configurations
<wolfspra1l>
auto-crc
<wolfspra1l>
better autotester
<wolfspra1l>
all of this leading to the first simple 'design' (=bitstream) that can load and run in a physical slx9 successfully, something as simple as an AND gate or so
<wolfspra1l>
that's the next milestone
<wolfspra1l>
after that is reached - fix loose ends everywhere, start with clocks, dcm/pll
<wolfspra1l>
and then simple reusable design elements
<wolfspra1l>
then support for larger xc6 chips, maybe something with a ftg256 or fgg484 packaging
<cde>
hmm I don't have an slx9 at hand, however the slx45 should do I guess. has the bitstream format been reverse-engineered yet?
<wolfspra1l>
I will definitely want to try it myself
<wolfspra1l>
and/or switch to the xc7a100
<wolfspra1l>
that's all months out though, just describing the roadmap
<wolfspra1l>
no it won't "do", because there is a lot of work everywhere
<wolfspra1l>
like months full-time
<wolfspra1l>
you can join if you like but pretty much nothing works today or soon
<lekernel>
if that works, then it'll be better than DARPA-funded jbits :)
<wolfspra1l>
I will continue with the slx9 until at least let's say 10% of the features of that chip are really working well with fpgatools
<wolfspra1l>
better more
<wolfspra1l>
it makes no sense for me to jump to larger chips early on
<wolfspra1l>
only slows me down
<wpwrak>
and costs more money when you fry them :)
<wolfspra1l>
and the bigger ones don't come in qfp144 packaging, and and and
<cde>
how hard would it be to fry an fpga through incorrect configuration?
<wolfspra1l>
but even if the slx9 is working well, (well=10%), going to say the slx45 is at least another full-time month of work
<wolfspra1l>
the overall structure is the same, and a lot of stuff is reusable, but the whole thing needs to grow and there are many new/different corner cases, new features, etc.
aeris has quit [Ping timeout: 240 seconds]
<wolfspra1l>
and that wont' just magically appear by changing an integer somewhere from '9' to '45'
<wolfspra1l>
probably relatively easy to fry one
<wolfspra1l>
but I shall have more real-world data on that soon
<cde>
you seem very pessimistic! don't be :D
<wolfspra1l>
I would think that if you configure the routing bits badly, electrical overload may flow in all sorts of directions
<wolfspra1l>
I'm an enternal optimist, but I try to describe this in the most realistic way
<wolfspra1l>
you are very welcome to come in and help
<wolfspra1l>
from a 10% working slx9 to a 10% working slx45 is 1+ months full-time work
<wolfspra1l>
that is a fact
<wolfspra1l>
not pessimistic or optimistic
<wolfspra1l>
it's developing nicely btw
<wpwrak>
wolfgang is an optimist - by expecting the worst, he hopes for pleasant surprises :)
<wolfspra1l>
I learned an enormous amount already
<wolfspra1l>
yes
<wolfspra1l>
you can join today
<wolfspra1l>
I think you mainly need 2 things to make a significant contribution:
<wolfspra1l>
1) plenty of time
<wolfspra1l>
2) good C programming skills
<wolfspra1l>
that's all
<cde>
well I'm currently on vacation, for only for the rest of week. after that I'll have much less free time
<wolfspra1l>
I can supply you with cheap slx9 testing boards if we make it there in the next weeks hopefully, at cost
<wolfspra1l>
there you go :-)
<wolfspra1l>
so just wait, and ping me once in a while :-)
<wolfspra1l>
that's real life, perfectly fine
<Fallenou>
14:34 < wolfspra1l> you can join today < reminds me TV ads
<cde>
ok. I'll see what I can decipher of the source code in the meantime ;)
<wolfspra1l>
Fallenou: and look, the mmu fits as well
<wolfspra1l>
:-)
<Fallenou>
fits in what ?
<wolfspra1l>
I was playing on the TV ad
<wolfspra1l>
those knife ads
azonenberg has joined #milkymist
<Fallenou>
hehe
aeris has joined #milkymist
<cde>
I vaguely remember there is a working project for compiling bitstreams for the Spartan 3. or is my memory wrong?
<wolfspra1l>
sorry can't help
<wolfspra1l>
all I know is historic and I purged it from my mind
<Fallenou>
are you still drawning in paper sheets ?
<wolfspra1l>
getting better, more and more running in sw now :-)
<cde>
btw is there a trick for data transfer between clock domaine A and B where B is between 1 and 2 the frequency of A ?
<lekernel>
DQS is not used for reading of course, but according to the micron datasheet you only lose about 60ps of timing budget. it's a small price to pay to avoid 1) a big design mess 2) a good 2 cycles of additional read latency for using this imbecilic signal
<lekernel>
#1 of course encompasses the fact that the read latency becomes unpredictable, which adds to the difficulty of scheduling transfers
<lekernel>
I pity the Intel engineers :)
<lekernel>
cde: you need some phase alignment, and then sample the all data with sufficient setup/hold time.
<lekernel>
without phase alignment, you need double latching (sometimes included in a FIFO control system), which adds a lot of latency
<cde>
thanks
<lekernel>
and that latency varies, of course, depending on what phase the two clocks happen to have when data enters the FIFO
<lekernel>
in short - it's great that micron guarantees a tight clock-to-DQS skew for the parts we're using
<lekernel>
the point of phase alignment (and integer frequency ratios) is to avoid this technique, which adds latency and unpredictability
<cde>
doesn't the artix 7 have a built-in memory controller? that could be useful
<lekernel>
it has an undocumented "phaser", which handles some DQS- and read/write leveling-related gory details
<lekernel>
we won't need read/write leveling on the M3 since we are connecting individual chips to the FPGA (which also increases the page hit rate), at an expense of increased I/Os utilization
<lekernel>
and I hope to get rid of DQS problems in a similar way (still need to read some datasheets...)
<cde>
it looks like the phaser is primarily for meeting the very precise ddr2/3 timing requirements? other interfaces (hdmi, ...) will not require it
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 244 seconds]
<lekernel>
hdmi data rates per pin are the same or higher than ddr2/3
<lekernel>
the fundamental problems with ddr is that you have a lot more signals, and data can go both ways (eg DRAM component answers a read request that was transmitted from the fpga, as opposed to a unidirectional data flow in hdmi)
<cde>
lattice also has a DDR3 ip core, I guess it costs money like other vendors (and is not open-source)
kilae has joined #milkymist
kilae_ has quit [Ping timeout: 240 seconds]
<lekernel>
reading lattice paper p. 20
<lekernel>
interesting way of transferring from DQS to system clock
<lekernel>
it actually avoids that annoying FIFO...
<lekernel>
not usable on xilinx arch though (I'd even bet someone patented this...)
<lekernel>
this scores another point for lattice. too bad their software is so horrible.
Gurty has quit [*.net *.split]
mwalle has quit [*.net *.split]
Gurty has joined #milkymist
mwalle has joined #milkymist
mwalle has quit [Ping timeout: 244 seconds]
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 252 seconds]
jimmythehorn has quit [Quit: jimmythehorn]
mumptai has quit [Quit: Verlassend]
kilae has joined #milkymist
kilae_ has quit [Ping timeout: 252 seconds]
mwalle has joined #milkymist
hypermodern has joined #milkymist
kilae has quit [Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]]