<larsc>
lekernel: do you have something generic in migen which does data width conversion between two data streams. E.g. lets say you have a 64bit DMA bus which is connected to a core which internally works with 16bit samples.
<lekernel>
there's limited support for that in the dataflow libs
<larsc>
ok, cause that's something I often see when streaming data is processed. But most of the time the width on both sides is hardcoded. So the core only works with a very specific upstream data source.
<lekernel>
well, I didn't code all possible cases
<lekernel>
pull requests accepted
<larsc>
hehe
<larsc>
Would I'd like to see is something that just does the right thing. Give it two datastreams and it will insert a small fifo and take care of up and down conversion of the bus width.
<larsc>
and if the bus width's are equal it should turn into a noop
<lekernel>
it should be quite straightforward to do that with migen...
<lekernel>
dealing with various control signaling issues at both ends can be a bit messy though
<lekernel>
but you can do a simple core that has just stb+ack, then other cores would hook that up to bus signals possibly with some glue logic
<larsc>
ok, thanks
<larsc>
I want to see if I can use migen to implement some simple audio cores
xiangfu has quit [Ping timeout: 260 seconds]
xiangfu has joined #milkymist
<larsc>
what does the 'specials' API do?
<lekernel>
it's for supporting features that cannot be expressed with 0/1 combinatorial and synchronous statements: tristates, block RAMs, instances
<larsc>
ok
balrog has joined #milkymist
<balrog>
xiangfu: I just found out about fpgatools; pretty nice :)
<balrog>
I recently found that someone posted debit back on github after it was gone from the internet for a while... https://code.google.com/p/debit/
<lekernel>
is there anything that debit has and fpgatools doesn't?
<balrog>
at this point I'm not sure... I just learned about fpgatools
<balrog>
how much do different size fpgas within a series differ?
<Fallenou>
FYI Milkymist RTEMS drivers have been quoted/used in latest issue of "Open Silicium" French hack magazine by Pierre Ficheux
<Fallenou>
for a mini2440 arm bsp
<lekernel>
Fallenou, interesting - what did he say?
<Fallenou>
well he just said "look, there is a nice example of GPIO/led driver in Milkymist BSP, let's take it and use it for our BSP"
<lekernel>
yay, let's port stuff from MM to ARM :)
<Fallenou>
;)
<Fallenou>
he put milkymist website and such in the credit area
<Fallenou>
like a gentleman
<Fallenou>
I met him a few weeks ago at Paris Embedded #2
<Fallenou>
and he told me "oh I used your driver for some mini2440 stuff !"
<Fallenou>
I was kind of surprised :p
<Fallenou>
it was nice to meet him (for the first time) anyway
<lekernel>
we should get more articles into OS
<Fallenou>
the same day I met Christophe Blaess :)
<Fallenou>
for the first time as well
<Fallenou>
yep
xiangfu has quit [Remote host closed the connection]
<Fallenou>
there is an article about OpenRISC in latest OS
<lekernel>
the editor in chief is actually a bit desperate about receiving too many raspberry pi type of things, haha
<Fallenou>
oh, Denis did himself the article writting about OpenRISC
<Fallenou>
I thought it would have been at least an OpenRISC dev guy
<lekernel>
well if someone wants to translate the migen tuto into French... I'm quite sure it would work
<Fallenou>
wow, there is also an article about Raspberry Pi ... by Yann Guidon o_o
<Fallenou>
wtf
<lekernel>
I know... I have already sent him my comments :)
<Fallenou>
oh my, 2 articles about RPI actually
<Fallenou>
When NetBSD will boot on the M1 I will send Denis an article :)
<lekernel>
rpi is also what most of the berlin startupers call "hardware"
<lekernel>
there is <1% interesting people in this community - eg at last hackathon, two women put together a Michelson interferometer. it didn't make it into the top5 most liked projects among the websites and iOS apps, though.
<Fallenou>
...
<Fallenou>
so sad
<balrog>
:(
<larsc>
lekernel: and 'serious hardware hacking' is making a LED blink on the rpi?
<balrog>
lekernel: is this where most talk about "serious hardware hacking" takes place? or are there other channels around here for that? :)
<balrog>
(I mean with regards to people like you)
<Fallenou>
there is qi-hardware , homecmos and such
<azonenberg>
need another dozen jtag cables before the rest of the nodes will be usable though :p
<lekernel>
azonenberg, what is that supposed to do in the end?
<Fallenou>
a cluster of what kind of board ?
<azonenberg>
Fallenou: very heterogeneous
<azonenberg>
everything from an XC3S50A on a homemade board to the Atlys
<azonenberg>
Two of them in fact
<azonenberg>
I'm using it for unit tests of my thesis research and libjtaghal
<Fallenou>
it's running your "network" kind of SoC ?
<lekernel>
balrog, #opencores too, maybe
<azonenberg>
Fallenou: The bigger boards are being used as testbeds for that, yes
<azonenberg>
the smaller ones are for one-off prototyping and libjtaghal regression testing
<azonenberg>
and just for good measure as long as i was bringing up a batch scheduler i set up distributed builds
<azonenberg>
i can't make one P&R run go any faster, but a lot of cores will trivially speed up building ten bitstreams at once
<lekernel>
azonenberg, well you can, thanks to wolfspraul's fpgatools and some coding ;)
<azonenberg>
lekernel: I dont think it's mature enough for that
<lekernel>
is there a timing model btw?
<azonenberg>
the CPLD boards, however, are being used for active development of my CPLD toolchain
<azonenberg>
For his or mine?
<lekernel>
either
<balrog>
I've also bee wondering a bit if anyone has been doing any research on altera chips
<azonenberg>
I intend to do full timing analysis on mine
<azonenberg>
not yet implemented
<balrog>
most of the free tools so far target xilinx
<azonenberg>
I'm still working at the bitstream level
<azonenberg>
balrog: how many others are there?
<azonenberg>
besides my CPLD stuff and fpgatools
<balrog>
debit, the stuff in lekernel's presentation from 2011
<azonenberg>
debit was mostly RE focused though right?>
<azonenberg>
not aiming at synthesis
<lekernel>
well neither is completed... fpgatools is the best tool you can have today imo
<balrog>
yeah... I'm mostly interested in RE but synthesis is useful too
<balrog>
and there are at least four major FPGA companies; xilinx, altera, actel, and lattice
<azonenberg>
I want both
<azonenberg>
fpgatools is your best hope, ye
<azonenberg>
yes*
<azonenberg>
my CPLD stuff is mostly a side project that i think is small enough compared to fpgatools that it can become production-ready relatively quickly
<azonenberg>
whereas fpgatools needs a LOT of work still
<balrog>
CPLDs are much simpler too
<azonenberg>
That was the point
<azonenberg>
it's tractable for one person to do in a few months
<balrog>
any of you played with PALs? :)
<azonenberg>
Another week or so of effort should be enough to get the full bitstream format worked out
<lekernel>
azonenberg, what are the next major obstacles, except the timing model?
<azonenberg>
then the place-and-route for a CPLD is pretty easy since the netlists are so small
<balrog>
which CPLD series?
<azonenberg>
coolrunner-II
<lekernel>
for fpgatools
<azonenberg>
oh
<azonenberg>
I havent been following him too closely
<azonenberg>
been playing my own game here
<balrog>
the XC9500XL series seems useful
<azonenberg>
there is no shared code since the architectures are so different
<azonenberg>
balrog: i'm focusing on cr-ii because of one crucial detail
<azonenberg>
the .jed files generated by the xilinx compilers include comments
<azonenberg>
describing most of the bitstream format
<balrog>
aaah hah
<azonenberg>
i suspect someone left _DEBUG defined
<azonenberg>
by accident
<balrog>
LOL
<balrog>
XC9500XL is still xilinx
<azonenberg>
But i'm not gonna look a gift horse in the mouth
<balrog>
and the jed files for those don't include comments?
<azonenberg>
Correct
<balrog>
:/
<azonenberg>
from what i understand cr-ii was based on another company xilinx acquired
<azonenberg>
this may be their code
<lekernel>
what are fun things to do with CPLDs?
<balrog>
there's no way to tweak things to leave _DEBUG defined?
<balrog>
lekernel: FPGA type but smaller. you don't have to load microcode either
<azonenberg>
If it's done at the preprocessor level, no
<azonenberg>
lekernel: mainly 74xx replacement
<balrog>
PAL replacement too
<azonenberg>
they're nonovolatile, small, and cheap
<balrog>
yep
<azonenberg>
i'd rather throw an xc2c32a on a board than two or three 74HC's
<azonenberg>
one 74HC i might do but even then i might prefer the cpld for flexibility
<balrog>
for that small you might be better off with PALs; too bad only Atmel still makes them
<lekernel>
sure, but what full project can you do, in practice?
<azonenberg>
lekernel: Maybe a SERDES for a microcontroller?
<lekernel>
Autoconf and automake have a config file which is built out of macros. Two of those macros are AC_CONFIG_HEADERS and AM_CONFIG_HEADERS. Now, here's the fun part. To use autoconf, you need to use the former. To use automake, you need to use the later. Either tool will barf processing the config file if the other is present
<Fallenou>
:)
<Fallenou>
solution : update your am and ac
<Fallenou>
to use labels like 1b / 1f (meaning first backward encountered 1: label / first forward encountered 1: label) on the same line as the branch instruction, I need to use "1b", right?
<Fallenou>
like:
<Fallenou>
1: bne r0, r1, 1b
<Fallenou>
(this is GNU AS specific I guess)
<larsc>
1b should be correct
<larsc>
you could also write 'bne r0, r1 .' I guess
<Fallenou>
hum I guess yes
<Fallenou>
thanks
<larsc>
lekernel: I want to invert a signal, should 'a.eq(not b)' work?
<larsc>
ah
<larsc>
a.eq(~b)
<Fallenou>
./lm32/lock.h: Assembler messages:
<Fallenou>
./lm32/lock.h:87: Error: unrecognized keyword/register name `be r0,(r11+0),1f'
<Fallenou>
GNU AS is unhappy about 1f I guess :)
<larsc>
you can only compare registers
<Fallenou>
super strange since two lines after that I have "1:"
<Fallenou>
oh right, indeed
<Fallenou>
gcc generated wrong code
<Fallenou>
I put be r0,%1,1f
<larsc>
you need the "r" constraint
<Fallenou>
yep I put "=m" I just replaced by m
<Fallenou>
err by "r"
<Fallenou>
great, locking is OK
lekernel has quit [Ping timeout: 248 seconds]
<Fallenou>
thanks larsc :)
<larsc>
meh, now that I have some questions lekernel is gone
<larsc>
as if knew ;)
<Fallenou>
hehe
<Fallenou>
larsc: is the adv linux driver release we talked about delayed?
<GitHub155>
[migen] sbourdeauducq pushed 12 new commits to master: http://git.io/uQUnyw
<GitHub155>
migen/master 2b8dc52 Sebastien Bourdeauducq: Use common definition for FinalizeError
<larsc>
yea, I still need to write the documentation
<larsc>
so much stuff going on atm
<larsc>
super busy
<Fallenou>
I can understand ;)
<Fallenou>
oh, so it's a Xilinx demand, the driver ?
<larsc>
Xilinx needs it for one of their designs, but other customers have asked for it as well
<GitHub57>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/C4B3OA
<GitHub57>
milkymist-ng/master a9b7235 Sebastien Bourdeauducq: Use new module, autoreg and eventmanager Migen APIs
<larsc>
not related to the adv, but to being super busy. It takes 1-2 years to develop a new IC, but they only realize two weeks before shipping it that they need a Linux driver as well
lekernel has joined #milkymist
<Fallenou>
larsc: that's a pitty =(
<Fallenou>
anyway, thanks for the link, I will forward this to our kernel team so that they can compare their driver with your :)
<Fallenou>
I hope this will apply easily, since we are using 2.6.35 kernel tree