<wolfspraul>
are there any similarities/overlaps/pros/cons?
<wolfspraul>
I recently learned about SHARC and now trying to understand what's special about those chips and how they compete with FPGAs or an SoC running on an FPGA...
<wolfspraul>
just curious, nothing urgent or important :-)
<wolfspraul>
the SHARCs are selling for 20-40 USD on digikey
<wpwrak>
hmm, seem to be very different beasts. main focus seems to be the DSP.
<stekern>
wolfspraul: take a look at the blackfins instead, that's SHARC's successor
<stekern>
you could probably do a milkymist using one of those, the implementation would be very different though
<stekern>
such a implementation would conterfeit the whole purpose of milkymist having a opensource soc
<wolfspraul>
wait one by one, too fast for me
<wolfspraul>
first you say Blackfin is the SHARC successor
<wolfspraul>
is that true? no more SHARC investments/improvements?
<wolfspraul>
what do you mean with "milkymist using a blackfin"?
<wolfspraul>
my thinking is - if there is a product that currently uses a SHARC (that was my initial question), can the SHARC be replaced with an FPGA, for example running Milkymist?
<wolfspraul>
and if not, which features would the SHARC (or Blackfin) offer that a Milkymist on FPGA could not compete with?
<stekern>
computing speed
<wolfspraul>
stekern: Blackfin is the SHARC successor? SHARC is discontinued?
<stekern>
I don't think sharc is discontinued
<wolfspraul>
then they must offer something Blackfin cannot offer
<wolfspraul>
stekern: please tell me more about "you could probably do a milkymist using one of those, the implementation would be very different though"
<wolfspraul>
what do you mean with "do a milkymist using one of those"
<wolfspraul>
Blackfin is not an fpga, cannot run Milkymist SoC. I don't get what you mean.
<stekern>
no, it cannot "run" the Milkymist SoC. I just meant that you could do a product doing what Milkymist does, but using that Blackfin DSP instead of the Milkymist SoC.
<wolfspraul>
ah ok
<wolfspraul>
slowly I re-read your sentence 10 times and maybe I get it
<wolfspraul>
:-)
<wolfspraul>
you throw together different meanings of Milkymist as "Milkymist One" (the video synthesizer), "Milkymist SoC" (the verilog programmed IC design)
<wolfspraul>
I'm not asking whether I could build a video synthesizer such as Milkymist One with a Blackfin or SHARC
<wolfspraul>
what I'm asking is the other way round
<wolfspraul>
say an existing product uses a SHARC (or Blackfin)
<wolfspraul>
can that product be implemented using an FPGA? (running Milkymist SoC for example)
<wolfspraul>
what are the performance features something like SHARC or Blackfin can offer that an FPGA cannot compete with, no matter whether it has great soft IC design running on it or not?
<stekern>
ok, gotcha. That depends heavily on what that product does.
<wolfspraul>
aren't SHARC or Blackfin competing with FPGAs?
<wolfspraul>
what will make you choose a SHARC or Blackfin over an FPGA?
<wolfspraul>
they are basically more specialized chips that can do certain dsp workloads at much higher performance than an fpga?
<wolfspraul>
at the expense of the flexibility (programmability) of an fpga?
<stekern>
when you need a general purpose CPU (or DSP) with alot of computing power
<wolfspraul>
what workload is it exactly SHARC (or Blackfin) can do that an FPGA could not?
<wolfspraul>
say I look at a product that uses a SHARC - how do I determine whether the workload can be handled by an FPGA as well?
<stekern>
I'm currently working on a project that have both a FPGA and a Blackfin on the board
<wolfspraul>
ah, great
<wolfspraul>
:-)
<wolfspraul>
so the Blackfin runs the CPU and OS?
<stekern>
yes, and the FPGA runs tasks that are suitable for an FPGA
<stekern>
for example, a uart that does hardware message handling
<stekern>
"runs" the CPU is maybe the wrong word...
<stekern>
it _is_ the CPU
<folkert>
hello
<wolfspraul>
stekern: ok that's a classical combination though
<wolfspraul>
CPU+FPGA, in your case Blackfin + fpga
<wolfspraul>
but what about a system that uses only a Blackfin, or only a SHARC
<wolfspraul>
the Blackfin CPU runs at 500-600 mhz
<wolfspraul>
so there's things you can do there that you cannot do on a Milkymist SoC running at 80mhz (let's not even look at missing features like mmu right now)
<wolfspraul>
stekern: in your system, why can't you drop the blackfin and run it all on the fpga?
<wolfspraul>
what fpga is it? the reason you want the cpu is because of the ready-to-use software stack it comes with?
<stekern>
blackfins don't have mmu neither
<stekern>
first, it's not "my" system, it's a commercial project I am involved with
<stekern>
so the design choices of the system isn't mine, so I can't answer for them
<stekern>
but doing what the software in that system does fast enough isn't just doable on a soft-cpu in a FPGA
<wolfspraul>
what fpga is it?
<stekern>
a cyclone III
<xiangfu>
folkert, Hi. your milkymist one back to normal? :)
<folkert>
yeah :) thanks
<folkert>
havent tested it much yet, so i still might have to do the soldering job
<folkert>
but first have to get a test dmx + midi setup going
<folkert>
any recommendations for a very cheap moving head? :D
<xiangfu>
folkert, (soldering jobs) yes.
<xiangfu>
folkert, I dont' have any dmx midi device :(, all I know about them is short then when do test :)
<folkert>
hehe i see :)
<folkert>
good to see there's some activity on the channel this time of day, i was a bit worried it'd all be CEST
<folkert>
(i'm based in HK)
<wolfspraul>
stekern: are you using any of the special Blackfin DSP features? could you replace the blackfin with a freescale chip (for example)?
<wolfspraul>
freescale ARM I mean
<wolfspraul>
or OMAP
<stekern>
nothing blackfin specific is used, it could be replaced with an ARM processor (or basically any processor, as long as there is enough computing power)
<kristianpaul>
blackfin have gcc support i remenber.. dunno how DSP is implemented but i guess people use LabView/Matlab to model their DSP blocks?
<kristianpaul>
(model)
<kristianpaul>
actually you can do same for FPGAs
<stekern>
why would you need to model anything?
<kristianpaul>
if
<kristianpaul>
required
<kristianpaul>
hi fpgaminer :)
<kristianpaul>
stekern: i mean model high level blocks..
<stekern>
I'm still not following
<kristianpaul>
in general how easy is for you develop for that blackfin + fpga platform? what software do you use?
<kristianpaul>
(that was my point behing my not very clear words..)
<stekern>
the DSP features of the blackfin is basically MACs, FPU and some image processing functions
<stekern>
kristianpaul: aah, ok. ADIs visualdsp++ is used in that project
<kristianpaul>
;-)
<stekern>
but yes, there are gcc for blackfin
<kristianpaul>
hum, doing a quick look at analog website it seems SHARC something more specialiced
<kristianpaul>
and blackfin suits better a DSP general porpuse SoC?
<wolfspraul>
stekern: ok got it, you just use it as a regular cpu
<wolfspraul>
so my initial question was about SHARC, what features SHARC has that couldn't be implemented by an fpga
<wolfspraul>
my naive understanding is that an fpga can implement dsp in the programmable fabric
<wolfspraul>
but that is less performant than dedicated dsp blocks
<kristianpaul>
fpga have dedicated dsp blocks
<wolfspraul>
so for a product that uses a SHARC, which performance (or features) of the SHARC can be implements in a s-6+milkymist soc, and which cannot
<stekern>
sharc and blackfin are pretty similar on the surface
<kristianpaul>
but some variants have more blocks than others
<stekern>
so all I've said goes for sharc as well...
<kristianpaul>
s/variants/families
<stekern>
sharcs don't have any "DSP blocks" that you can freely program to perform arbitrary operations (at least not to my knowledge)
<kristianpaul>
at least in spartan 3, dunno in s6
<stekern>
kristianpaul: yes some FPGAs have DSP blocks which in spartan6 is basically a bunch of hardware multpliers and adders
<stekern>
wolfspraul: to answer your question, the feature of SHARC that can't be implemented in FPGA: running a general purpose CPU at high speed
<wolfspraul>
kewl
<wolfspraul>
that doesn't sound scary to me :-)
<wolfspraul>
there must be more though, I would think. otherwise those SHARCs could not compete with freescale, omap, etc.
<stekern>
well as always, there are a lot of factors that play in when you choose a certain brand
<wolfspraul>
you really think there is nothing else special about them?
<wolfspraul>
no exceptional performance or feature anywhere?
<wolfspraul>
there must be
<stekern>
price, power consumption, availabiliy cost of development tools, support etc etc
<wolfspraul>
SHARCs are mostly 200-400 MHz
<wolfspraul>
yes I fully understand all those, but how to compete with ARM ?
<stekern>
ADI have their own ARM implementations, so they are really competing with themself in that case ;)
<wolfspraul>
hmm
<wolfspraul>
OK thanks a lot! I'm beginning to learn, and I think I shall learn more :-)
<stekern>
but sure, they are DSP's, that niches them away from more general purpose CPU's
<wolfspraul>
yes ok, but how does that translate to an fpga
<wolfspraul>
an fpga can do dsp, no?
<stekern>
there are alot of other DSP's out there that they have to compete with, like TI's DSP's
<wolfspraul>
how does 'dsp' relate to 'fpga'?
<wolfspraul>
you can program an fpga to do digital signal processing, no?
<wolfspraul>
so the dsp chip offers higher performance?
<wolfspraul>
a dedicated dsp chip I mean
<wolfspraul>
but then the programming tools may be very specialized and lack features
<stekern>
the word DSP is a bit confusing in this context, I know. blackfins/sharc & friends are often referred to as "DSP"s, in that context it simply means a "CPU with some DSP capabilities, like MAC, maybe some imaging/audio specific encoders/decoders etc"
<stekern>
in (some) FPGAs there are hardware DSP blocks, in the spartan6 those are hardware multiplier+adders.
<wolfspraul>
yes
<wolfspraul>
hey now the 'gpu' guys are moving in too and will messup naming even more :-)
<wolfspraul>
but please continue
<stekern>
but, you can program the FPGA to do whatever you like, for example some more specialized digital signal processing
<stekern>
so, one example where you could exchange an SHARC/blackfin with an FPGA would be if you are doing some specialised digital signal processing
<stekern>
and implement that algorithm straight in the FPGA instead of running it as a program in the SHARC
<wolfspraul>
I still have trouble seeing the future of SHARC/blackfin. It seems sales are mostly tied to existing customer investments, tools, software stack, integration with other chips from same manufacturer, etc.
<wolfspraul>
on one side you have general purpose CPUs, and the OMAP for example definitely has a lot of DSP/codec capabilities too so it might as well be a "DSP chip"
<wolfspraul>
on the other side you have fpgas which can be programmed with at least some sort of standardized programming languages and tools
<wolfspraul>
that's my understanding, please correct me if I'm wrong
<stekern>
sure, ARM is dominating the market, but that doesn't mean there isn't room for competitors
<wolfspraul>
yes, that's exactly my thinking [implement that algorithm straight in the fpga instead of running it as a program in the SHARC]
<stekern>
remember, lm32 isn't ARM
<wolfspraul>
I think if we want milkymist to succeed, we have to focus our energy on the software stack, tools, entry points, etc.
<wolfspraul>
there is nothing inherently wrong with the foundation (fpga) that would prevent it from being competitive in a number of application areas
<wolfspraul>
stekern: oh sure, totally agree.
<wolfspraul>
ARM innovation to me is mostly how they setup their business model, licensing, etc.
<wolfspraul>
they created an ecosystem with a lot of economic power
<wolfspraul>
but I'm looking at SHARC/blackfin as an outsider
<wolfspraul>
I have no existing products or investments, so I can pick freely.
<wolfspraul>
the incentives for jumping on that train seem limited
<wolfspraul>
the ARM ecosystem will continue to be able to come out with great high-performance low-power chips that I can easily buy in small or large quantities, for acceptable prices
<wolfspraul>
and fpgas seem like a standardized chip that is equally doing well with lots of investments
<wolfspraul>
between those, why pick a SHARC/blackfin for a new project/company (that is, without historical reasons)
<wolfspraul>
for example for your project now. if you could do it from scratch in a new company, would you pick the blackfin+cyclone-III, or some other combination?
<stekern>
there are other combinations used in that project
<stekern>
no ARM though
<wolfspraul>
yes but I tried to understand you, if _you_ could start from scratch, would you pick the blackfin?
<wolfspraul>
because you know it? because it's better?
<stekern>
Perhaps, it's a nice enough processor
<stekern>
but as I said, there are alot of factors that play in when you do design decisions
<wolfspraul>
yes. ok we made headway. thanks again!
<wolfspraul>
I need to learn more about more chips :-)
<stekern>
np ;)
<stekern>
I think a key thing though, there usually many ways to accomplish the same thing and often there isn't a clear "right way" to do it
<stekern>
missed a couple of "is" and "are" in that sentence... ;)
<stekern>
hard to type fast on the small keyboard of this phone...
<wolfspraul>
phone, wow
<wolfspraul>
which phone?
<wolfspraul>
yes there are many ways to accomplish the same thing, but to make money in technology, you want to be the first/best/cheapest or a combination thereof
<wolfspraul>
and then the different paths do lead to different results. some are slower, some are more expensive, some lead to uncompetitive performance.
<wolfspraul>
so I'm trying to become more clear where the Milkymist path could lead us, so it's the cheapest way to get to the most high-performance product first :-)
<stekern>
I'dd say the most interesting part of milkymist is the open source side of it
<stekern>
(phone) nokia n900
<wolfspraul>
what is interesting about open source per se?
<wolfspraul>
if it doesn't lead to a product, it's nothing I'd say ;-)
<wolfspraul>
bad poetry for sure. unreadable and boring.
<stekern>
open source sure can be interesting without a product
<stekern>
personally, I'm more interested in the source code of milkymist than of it as a product
<stekern>
I don't do VJing, but I do see potential in it as a platform for other stuff
<kristianpaul>
:-)
<stekern>
without it being open source, tweaking it to do "other stuff" wouldn't be possible
<stekern>
to me, M1 is basically just a FPGA devboard with some interesting peripherals on it
<stekern>
the price is competetive though, I wouldn't mind buying one if I wouldn't happen to have to have a very similar board already
<wolfspraul>
ah ok, so you like the open source part of it because it allows you to make a different/better product of some kind
<wolfspraul>
well that's perfect
<stekern>
I wouldn't say "product"
<wolfspraul>
something someone can use
<stekern>
play with it for my own purposes, id say ;)
<stekern>
otoh, if I'd be doing VJing, I probably would find a thing or two I'd like to change. open source allows me to do that. that's the benefit of open source in milkymist as a product
<wolfspraul>
but it's important what is easy to change, and what is hard to change. people have limited time. It may be far easier to change something towards a look you like by playing with a powerful VJ software running on a Mac, for example.
<wolfspraul>
so Milkymist One can only sell if it's the best at something, or makes something very easy. like for example sharing lots of good works over the Internet.
<wolfspraul>
that's my thinking
<stekern>
I think the point I tried to make was, you have found a potential buyer in me by keeping milkymist open source, if it would've been closed source it (the product) would be completely uninteresting to me
<wolfspraul>
ok good. now we need to find a way to push you over the line :-)
<wolfspraul>
if you compare form a 'dev board' perspective, that's very hard of course
<wolfspraul>
dev board is dev board
<wolfspraul>
we all know how that works. the pros and cons of them.
<wolfspraul>
pros: always have the latest chips, cheap (often subsidized as marketing), all peripherals/features of the main chip exposed
<wolfspraul>
cons: availability can be very spotty (when the next chip comes out dev boards of older chips go away), pcba only (no case), often with a lot of bugs in specific parts that will never be fixed because the next devboard will be done from scratch to highlight the next chip's features
<stekern>
yeah, I think it'd be hard to compete with the general purpose dev boards the big companies specialised in those things are pushing out
<wolfspraul>
oh sure that makes no sense at all
<wolfspraul>
it's not even 'compete' - those are 2 totally different things
<wolfspraul>
does a bicycle compete with a car?
<wolfspraul>
only in some rare cases
<wolfspraul>
I have pretty clear ideas what we need to do to make Milkymist One (the video synthesizer) a success. None of them have to do with catching up or competing with dev boards.
<wolfspraul>
I don't even think dev boards are better or cheaper, just a completely different thing.
<wolfspraul>
if someone thinks they can take a dev board and turn it into a video synthesizer, go try :-)
<wolfspraul>
I think most dev boards are sold to help jumpstart new designs, some to academia
<stekern>
some to hobbyist
<stekern>
s
<wolfspraul>
I think the majority is sold to help people (companies) with new designs.
<stekern>
I agree
<wolfspraul>
but I don't know numbers, it's a little market by itself
<wolfspraul>
anyway any serious company that has decided to make a product with chip A, will immediately after making that decision buy a couple dev boards of chip A for the engineering team
<wolfspraul>
simply to save time and jumpstart before the first run of its own board
<wolfspraul>
as soon as those first boards are made, the dev boards go into the drawer and will never re-emerge from there anymore :-)
<wolfspraul>
maybe once in a while to help tracking down a nasty bug on their own board
<stekern>
not until they got their real boards and start wondering "wtf, it worked on the devboard"
<stekern>
aah, you were faster ;)
<wolfspraul>
afaik most dev boards are only made in the hundreds actually, a few maybe in the (low) thousands
<stekern>
I think the really big ones probably sell a bit more than that
<wolfspraul>
they are unsupported and buggy too, you cannot typically buy 10K of them. yield issues are not sorted out, and nobody is interested in fixing them.
<stekern>
true
<wolfspraul>
stekern: not from what I've seen. but you can ask around, I'm always interested in learning more.
<wolfspraul>
the numbers are amazingly low
<wolfspraul>
often only 200 or so
<wolfspraul>
sometimes 500
<wolfspraul>
rarely a few thousand (beagleboard, if you consider that a devboard)
<wolfspraul>
maybe it's different for chips that are around for 5 or 10 years
<wolfspraul>
then maybe the devboard over time will sell a little more because more designs are using that chip
<stekern>
that's not even FPGA
<wolfspraul>
for the most part, dev boards are ugly quick hacks to get people to jumpstart new designs with the latest and greatest chip. focus is on exposing the new high-end features that the manufacturer believes will create demand for the new chip.
<wolfspraul>
supply for academia is a second concern, but already far behind that first one
<wolfspraul>
it's always good to get students hooked to your technology :-)
<wolfspraul>
hobbyists? don't know. I know too little about that market.
<wolfspraul>
i think from the perspective of most semiconductors the hobbyist market is just noise
<wolfspraul>
won't make them fed :-)
<stekern>
yeah, I don't consider it a market share in that sense
<wolfspraul>
so you can add those features to Milkymist the SoC :-)
<wolfspraul>
also that board boots from an SPI flash it seems. well, if you make milkymist portable to that board, that's a good thing.
<wolfspraul>
makes the milkymist platform stronger and more versatile/portable
<stekern>
are you referring to "me" with that "you" or just in general ;)
<wolfspraul>
to you
<stekern>
but sure, that's the plan (port it to that board)
<wolfspraul>
great
<wolfspraul>
let's make sure we work together and feed your improvements back to a unified mainline
<stekern>
now, if someone just went and invented the 48 hour day, I'd be done in no time :)
<wolfspraul>
good things take time
<wolfspraul>
that dev board will disappear from the market faster than Milkymist becoming a big success anyway :-)
<wolfspraul>
but I can definitely see a lot of good things you can do for yourself or for the Milkymist project in porting Milkymist to that dev board
<wolfspraul>
and feeding improvements back
<stekern>
I guess your right, maybe I'll buy the M2 as a replacement ;)
<wolfspraul>
we work on a video synthesizer
<wolfspraul>
different focus, different everything
<wolfspraul>
of course you can compare with whatever you want
<stekern>
yeah, sure, I'm just kidding
<wolfspraul>
but then the dev board may make more sense to you, of course. and you got it already.
<wolfspraul>
we are thinking about replacing the vga connector on milkymist one with a dvi-i connector
<wolfspraul>
and routing the digital signals into the fpga
<wolfspraul>
then it's "just a little software" to support dvi or hdmi output, which you can already start with today on your dev board :-)
<stekern>
If I'd be doing the purchase decision today, chances are I would have choosen M1 over it anyways
<wolfspraul>
haven't thought about hdmi input yet, the analog input is quite interesting and we can include a cheap but good ccd camera with the m1
<stekern>
the hdmi input/output chip on that board is basically just a buffer
<wolfspraul>
what is the buffer doing?
<stekern>
(feed improvements back) oh sure, I'm not planning to run away with them if I'll be having any
<wolfspraul>
the way I understood Sebastien's plan for adding digital video output (via a DVI-I connector) was to route the wires into the fpga directly, no other chip in between
<stekern>
yeah, that's basically what's done. The buffer in between is just to improve signal quality
<stekern>
I'd imagine at the resolutions in quiestion, it might not be needed
<wolfspraul>
still downloading atlys schematics & manual, this is faster...
<stekern>
np
<wolfspraul>
hmm. it seems the tmds141 allows for a 1m distance between connector and receiver
<wolfspraul>
but why? the board is not that big.
<wolfspraul>
the distance between connector and fpga is just a few cm, no?
<wolfspraul>
but they must have put it on for some reason
<wolfspraul>
hopefully not just as a side business to promote that chip as well :-) (which is quite possible on a dev board :-))
<wolfspraul>
the datasheet shows as an application a huge TV screen, where the distance from HDMI connector to receiver chip is long
<wolfspraul>
that makes sense
<wolfspraul>
but on the atlys board? or m1?
<wolfspraul>
not sure
<stekern>
(promote chip) that's feasible
<wolfspraul>
definitely. make a little money from TI as well :-)
<stekern>
;)
<wolfspraul>
that's all the stuff you 'buy' included when you buy a dev board...
<stekern>
but I think maybe that chip is more up to the task of driving the TMDS signals than the FPGA is
<wolfspraul>
but anyway I just try to understand the real need and function of this chip
<wolfspraul>
not saying it's useless
<wolfspraul>
what does 'up to the task' mean
<wolfspraul>
it's needed or not?
<wolfspraul>
a chip costs money and adds complexity
<wolfspraul>
Sebastien didn't mention the need in our (vague) digital video output planning so far. which may be because it's not needed, or because we don't know yet why it is needed.
<wolfspraul>
the 1m thing at least makes sense to me, and the datasheet drawing with a large TV...
<wolfspraul>
well, good that I found out about it now, will keep an eye on this
<stekern>
My guess is, it will help at higher resolutions
<wolfspraul>
maybe the spartan-6 has some shortcomings that will make an hdmi implementation hard/impossible without this chip
<wolfspraul>
probably, yes
<wolfspraul>
or they just added it to the dev board 'just in case'
<wolfspraul>
or because TI paid a little
<wolfspraul>
since dev boards are often about driving performance to the highest possible end quickly, so they may just throw this in there without even having those resolutions work practically today
<wolfspraul>
for m1 we'd probably do it the other way round. first route the wires into the s-6 directly (without this chip), then see how far we can get in terms of resolutions.
<wolfspraul>
unless that's a loosing proposition right from the start, of course
<wolfspraul>
stekern: interesting point and chip, thanks a lot!
<wolfspraul>
that is the first really helpful contribution you are making to Milkymist :-)
<wolfspraul>
and that chip is not cheap either. 5 USD in low volume, digikey only has it with an MOQ of 2500... (then 2.30 USD)
<wolfspraul>
I wouldn't add that to m1 unless I clearly understood the reason.
<stekern>
there is actually a hdmi-out port on the atlys board that doesn't have the chip
<stekern>
I had forgot about that
<wolfspraul>
well, I think we both know the reason the chip is there may also simply be payments from TI :-)
<wolfspraul>
that's how the dev board business works
<wolfspraul>
dev boards are marketing tools for chips
<stekern>
yep
<wolfspraul>
otherwise how can you ever hope to sell a new chip...
<wolfspraul>
in fact you see a number of nice large logos on the silkscreen of that board
<wolfspraul>
ever wonder why the company wouldn't choose a smaller (and thus cheaper) pcb instead? :-)
<stekern>
the logos wouldn't fit :)
<wolfspraul>
ah true
<wolfspraul>
I should send them a silhouette of myself for the next run
<stekern>
smaller pcb isn't equal to cheaper though
<wolfspraul>
all other things equal it is
<wolfspraul>
of course if the smaller pcb drives the layers up or other complexities (pcb antennae etc), then it isn't
<wolfspraul>
but the large logos stand out, I think it's clear that those companies are paying
<wolfspraul>
which is a good thing, it makes the dev boards cheap...
<wolfspraul>
they should throw more chips and logos on them, and make them even cheaper
<wolfspraul>
stekern: why do you say "smaller pcb isn't cheaper"?
<wolfspraul>
you mean increased routing difficulty etc?
<stekern>
yeah, I meant, necessarily cheaper
<wolfspraul>
I was just talking about 'dead' extra pcb space, say you add an inch of dead pcb on the side -> will make it more expensive and nothing else
<wolfspraul>
ah ok, yes of course fully agree then
<wolfspraul>
but those logos are large and the board is quite empty. looks like it could easily shrink a bit without the logos :-)
<wolfspraul>
you can probably pay them some money to put your logo on an extra inch of dead pcb space somewhere, which they will add just for you :-)
<stekern>
just buying a huge PCB without any traces contrary to a small one is of course more expensive :)
<wolfspraul>
it's like ad space you can buy into
<wolfspraul>
sure sorry, I'm coming from my CHina perspective here (living in China).
<wolfspraul>
every mm costs, even if just a fraction of a penny
<stekern>
but I think there is a movement into really small FPGA devboards
<stekern>
who uses them? the same people you listed ^ there a couple of lines ;)
<wolfspraul>
stekern: that's a cool little board indeed!
<wolfspraul>
but who would use it, and for what?
<stekern>
09:51 < stekern> who uses them? the same people you listed ^ there a couple of lines ;)
<wolfspraul>
there's this hardware/software boundary magic somewhere in there, which I'm still thinking about
<wolfspraul>
what use case exactly?
<wolfspraul>
so in software, you have ultimate flexibility, you can do 'everything'
<wolfspraul>
but in hardware, a new connector doesn't just grow out of your pcb
<wolfspraul>
you cannot 'apt-get' a connector
<wolfspraul>
so I think it's impossible to make hardware that is both focused and flexible at the same time, unlike in software
<stekern>
evaluate soft-cpu + ethernet is at least one-thing you can do with the altera board
<wolfspraul>
to do what?
<wolfspraul>
evaluation is the purpose? just play with tech for a bit?
<stekern>
hehe, be creative, there's a lot of applications for that
<stekern>
industrial ethernet is one example
<wolfspraul>
it seems it has no memory? so it needs to be configured from a computer?
<wolfspraul>
and powered over USB?
<stekern>
yep
<wolfspraul>
my point is more general right now. the thought process for deciding on hardware features.
<wolfspraul>
I think without having a specific use case in mind, you cannot decide about hardware features.
<wolfspraul>
you will always get it wrong in the details
<wolfspraul>
as you will find out later
<wolfspraul>
in software you can update, but in hardware you cannot
<wolfspraul>
I would like to see the thought process that led to this micro board
<wolfspraul>
maybe just "let's try"
<wolfspraul>
"maybe something will happen"
<wolfspraul>
"don't think about details"
<wolfspraul>
:-)
<stekern>
I think it's mostly about demonstrating the usage of their NiosII processor and development tools surrounding that
<wolfspraul>
but then how do they decide about the details that are still there? ethernet: yes or no? do they have local memory, local flash? what drove the decision?
<wolfspraul>
and they can arrive from "we need to demonstrate the NiosII and tools" to this board, and answer all questions in between?
<wolfspraul>
I'm wondering how this works
<stekern>
ethernet: do we have a sponsor? yes, put it in! memory: do we have a sponsor? no, leave it out! ;)
<wolfspraul>
:-)
<wolfspraul>
I'm seriously just wondering how it works, I don't want to trashtalk this board at all.
<wolfspraul>
you know they have to answer hundreds of detailed questions in the design process of this board
<wolfspraul>
along which guidelines?
<wolfspraul>
don't get it
<wolfspraul>
it's cheap, that's good
<wolfspraul>
small, good
<stekern>
yeah, I'm as confused about that process as you are
<wolfspraul>
cheap and small are always good, but WHAT FOR? :-)
<wolfspraul>
I can make it even smaller :-)
<wolfspraul>
at least I think I do understand the dev boards that are exposing all peripherals of a chip
<wolfspraul>
phew
<wolfspraul>
:-)
<wolfspraul>
they have a point, I know how they are made and who they are good for
<wolfspraul>
I will watch that little thingie, let's see what happened in 1 year :-)
<wolfspraul>
there's a lot of companies that are trying in vein to replicate the arduino and beagleboard successes
<wolfspraul>
where I would even question whether beagleboard and later models are a success, given that the entire OMAP doesn't really work well for TI
<wolfspraul>
but Arduino is, in itself, I doubt the sales volume matters for Atmel either...
<wolfspraul>
it's good that a lot of folks try a lot of different thinks
<wolfspraul>
so does Milkymist :-)
<stekern>
I've never understood the big success of arduino myself
<stekern>
I guess it's just simple to get started with
<stekern>
I saw this "shield" with video output, that thing was FPGA based and a whole lot powerful and interesting than the arduino itself
<stekern>
+more
<stekern>
but people stand around it and cheers "arduino sure is cool!"
<wolfspraul>
arduino satisfies a need for people to control interactivity with computers
<wolfspraul>
I can understand it, I think
<wolfspraul>
simple interactivity, but our life is full of them
<wolfspraul>
like - someone throws a letter in your mailbox, and a led at your desk lights up :-)
<wolfspraul>
yes, it's painful maybe, but it gives people an access to a world of controlling computers and interacting with them and feeling good doing so
<wolfspraul>
you can also use it for all sorts of funny/interesting installations
<stekern>
yeah, I don't mind people playing with arduinos, I just don't see the huge benefit of it compared to a plain avr and good'ol C
<wolfspraul>
sure there is none. but you can get the boards, cheap, from a lot of sources.
<wolfspraul>
you can get books, training seminars, an active community
<wolfspraul>
lots of code snippets you can copy/paste trying this or that, a nice IDE, etc.
<wolfspraul>
that's why they like it
<wolfspraul>
will this ever turn into a serious innovative effort, an ArduPhone. I highly doubt it. So what. How many people that casually run Ubuntu on their notebooks will turn into active kernel contributors?
<wolfspraul>
almost nobody - so what
<wolfspraul>
I like the passion and energy in the Arduino community. I have no use for the typical Arduino application though.
<wolfspraul>
I don't want a blinking light on my desk when someone throws a mail into my mailbox :-)
<stekern>
hehe, me neither
<wolfspraul>
here in China they have some public sculptures, for example a mushroom (maybe 50cm high, not too big)
<wolfspraul>
and when you get closer, they talk to you or play music
<wolfspraul>
quite cool
<stekern>
but I guess you're right about the ubuntu/kernel contributors analogy
<wolfspraul>
those kinds of little things can be done with Arduinos, why not
<wolfspraul>
does the speaker quality matter? nah
<wolfspraul>
does anything matter? does it matter if the mushroom stops talking one day? nah
<wolfspraul>
:-)
<wolfspraul>
I still like them (the talking mushrooms).
<folkert>
wolfspraul: where are you located?
<stekern>
people just want to get something working, with as little effort of learning anything as possible
<wolfspraul>
sure, that's not bad I think
<wolfspraul>
we are the same in most areas of life
<wolfspraul>
say my wash machine. trust me I just want the damned thing to wash. I do _NOT_ want to learn anything about it :-)
<wolfspraul>
folkert: Beijing
<folkert>
ah nice :)
<stekern>
perhaps not, it just clashes with my reason for spending free time on this kind of stuff
<stekern>
(washing machine) sure, but that's still a bit different. You could probably buy a ready device that blinks leds on your desktop when mail arrives, but people wants to build it themselfs, without actually putting any effort into building it
<stekern>
that's not what I don't really get
<stekern>
-ot
<stekern>
aargh...
<wolfspraul>
but it's a hobby
<wolfspraul>
you cannot rationalize why people go to the movies
<wolfspraul>
or fishing
<wolfspraul>
or hiking
<wolfspraul>
or another thousand things people do
<wolfspraul>
they just like it, it makes them feel good. that's the only reason.
<wolfspraul>
and we all know there's some bizarre stuff going on :-)
<stekern>
yep, and I said, I don't mind it
<stekern>
I don't get people having fishing as a hobby neither though ;)
<wolfspraul>
yep
<wolfspraul>
but our hobbies probably look as strange to them as theirs to us
<wolfspraul>
which is all fine, imho
<stekern>
sure is
<Fallenou>
ahah Ralf is really a pain in the ass, just whining about adding a multilib variant for the main users of the cpu is just pointless