I also think sub-critical accelerator-driven systems (ADS) are a good way forward, since we have so much darned nuclear waste. Right now, the power level required for economical ADS is still a bit out of reach.
A former landlady told me something similar. Her daughter was being harassed at school, and the administration would do nothing. So she tells her daughter to fight back. Pushes the assailant down some stairs (!) and after a brief hue and cry, everyone lives happily ever after.
I've been reading Hacker News, but the moderation is pretty strict (basically no fun allowed). A lot of the discussion is annoying and there is no easy way to "browse at 4-5".
>in the past i've had to deal with license servers, multi-thousand dollar licenses, I've never had a problem with the Webpack edition not activating.
>being locked into windows Apparently most serious folks run the tools on Linux these days. Works fine on RH.
>having to reverse engineer internal formats because the tools wouldn't work for me Hasn't happened to me, knock on wood. Hopefully they've worked out more corner cases since your time.
>having day-long synthesis/test cycles because their routing was so abysmal, etc I think this is a given once you get above x% utilization. Newer FPGAs have more interconnect, though.
By keeping it Spartan (heh) they at least avoid the stupidity in the Zynq tools. What good is a "critical warning" that you're supposed to ignore, Xilinx?
I'm going to have to disagree with you. If somebody already has a RPi or BB, then this board makes a whole lot of sense: it just stacks on top of your existing unit, both physically and logically. In Zynqland it'd take quite some effort to construct the abstraction layers that they seem to be building into this project; you have to do things like rebuild the FSBL and binfile and it gets to be a pain. There's a community of sorts but it's small peanuts compared to the RPi juggernaut.
I agree that the bandwidth between the PS/PL is really awesome and blows away the separate-chip solution. But lets get real: beginners don't need that kind of performance. It's better for them to have something that's encapsulated and somewhat friendly-fied so they can get their feet wet, rather than drowning them in arcana right out the gate.
I also don't think the MicroZed is a good idea for hobbyists, unless playing with Linux is all you're after. Most of the IO is on the high-density Bergstak connectors, which means that you either buy the official (limited) carrier board, or roll your own custom carrier. And since the main attraction of SoC/FPGAs like this is fast I/O and tight coupling, unless you're doing something relatively high-performance and willing to spend money on the requisite hardware development, it doesn't make sense to adopt this platform. I see MicroZed as a vehicle to speed up project development; not so ideal for the hobbyist.
The Minty MP3 was also a big 'wow' for me. I don't think I've built any Lady(ada)fruit projects, but I've certainly studied a bunch of them over the years.
Software drivers are a challenge, and we will work on providing some level of drivers, with the hopes that the community takes them up and pushes them to new levels and provides problem reports to us.
I assume the #9 is not nearly as complex as a modern-day GPU, but this sentence really concerns me. As a hardware guy myself, I'd want some more experienced hands on board for the software side. And a Linux driver needs to be part of the deliverables at least.
Also, what's the resource utilization? If this thing only runs in large Virtex-class chips then it's not terribly useful to the open-source community.
It would be really cool to have a graphics core of this level open-sourced, but I think the audience for this project is kind of small. You could build yourself a PCI graphics card for kicks, I guess, but you'd still need a PCI motherboard. Where it gets more interesting is with the "generic interface" option. Then for example you could use a Xilinx Zynq (which is an FPGA+ARM), implement the GPU in the FPGA, and talk to it on-chip over AXI. However I have a feeling they won't get to the $600000 level needed to make this possible.
Bunnie has described this project as a "bespoke oscilloscope", so it's probably going to cost thousands of dollars. If that horrifies you even more, you're probably not the target audience.
All this hype about "the golden age of OSHW" is nonsense though.
"Boards ship" sounds fine to me, but I'm a hardware guy.
The more serious problem is that EOMA-68 doesn't appear to have anything to with the Vivaldi hardware. I mean, does a tablet with a removable CPU card make any sense whatsoever?
The Beaglebone has (had) this weird procedure where you plug it into USB, then "eject" it to activate a different mode. The first time I installed Beaglebone drivers is the only time it went smoothly. Later on different machines, all sorts of odd devices came up. In the end it was just easier to interact with it over SSH, so I can understand the decision to remove the USB-serial interface.
Having lived most of my life in the Bay Area, including six years in Berkeley, I would agree with your assessment. The City Council attracts some strange characters, and there is a slew of "committees" on topics that range from bleeding heart liberal issues to just plain weirdness. I consider myself fairly left/liberal but sometimes the Berkeley/SF councils seem like they're in a contest for craziness.
You don't want to pick up new interests unless they directly support your life/sanity as a PhD student. Things like learning to cook or getting into fitness, yes. Things like learning Haskell for a great good, picking up Arduino, not so much. Learning R, okay maybe that'll save you time down the road. You only have so many spare cycles for technical stuff, I've found, and any half-started projects will only linger around frustratingly.
If you have a qualifying exam in your program, find out what's on it and get an idea of how difficult it will be. Start studying; it doesn't have to be every day, but it'll do wonders to go into it with confidence.
As long as we're comparing mysterious numbers*, let's take a closer look. Future Chip: 38 GFLOPS / 2.7W = ~14 GFLOPS/W Tesla K20x: 3950 GFLOPS / 235W = ~16.8 GFLOPS/W Radeon 7970: 3790 GFLOPS / 280W = ~13.5 GFLOPS/W
So I'm not seeing a power advantage here. More questions: does the chip do double precision, and what's the rate? What's the memory bandwidth? Is there support for ECC/scrubbing, which is essential for Big Deal calculations? (The 7970 doesn't support ECC. The Tesla does, and it had better given the amount of money you pay for it.) I'd imagine the Future Chip would be a cheaper solution, but you're starting from scratch with the compilers when everyone else has a major head start.
So while I think a FSF Principles chip is a good idea, pitching it for scientific computing is a stretch.
*Future Chip numbers probably do not include memory power consumption, and are likely a optimistic extrapolation from the dual-core silicon. Radeon result is the unholy combination of AMD's published single-point FLOPS and the max power consumption from Anandtech's review. Tesla numbers are marketing numbers combined with TDP.
Thanks for the tip about Energia. My old robotics club bought a bunch of MSP430 Launchpads when they came out, but the software side of the equation was definitely lacking, especially for cross-platform development.
I'm also excited about the Stellaris Launchpad and hope that an open source command-line workflow will be developed. Should be fun.
To be fair, the Stellaris Launchpad is obviously a loss leader. The earlier MSP430 Launchpad never really gained a foothold in the hobbyist community despite its low price, so it remains to be seen how TI will manage this time around. Perhaps they don't care.
I thought the bit about intersections was hilarious -- "someone's going to own the intersection, so we defer to property rights and all problems are solved!"
Slashdot Mirror
I also think sub-critical accelerator-driven systems (ADS) are a good way forward, since we have so much darned nuclear waste. Right now, the power level required for economical ADS is still a bit out of reach.
Yeah, I would find it hard to give up the print edition. A physical subscription includes access to the digital archive, which is nice.
A former landlady told me something similar. Her daughter was being harassed at school, and the administration would do nothing. So she tells her daughter to fight back. Pushes the assailant down some stairs (!) and after a brief hue and cry, everyone lives happily ever after.
I've been reading Hacker News, but the moderation is pretty strict (basically no fun allowed). A lot of the discussion is annoying and there is no easy way to "browse at 4-5".
We might just need to build our own /.
>in the past i've had to deal with license servers, multi-thousand dollar licenses,
I've never had a problem with the Webpack edition not activating.
>being locked into windows
Apparently most serious folks run the tools on Linux these days. Works fine on RH.
>having to reverse engineer internal formats because the tools wouldn't work for me
Hasn't happened to me, knock on wood. Hopefully they've worked out more corner cases since your time.
>having day-long synthesis/test cycles because their routing was so abysmal, etc
I think this is a given once you get above x% utilization. Newer FPGAs have more interconnect, though.
By keeping it Spartan (heh) they at least avoid the stupidity in the Zynq tools. What good is a "critical warning" that you're supposed to ignore, Xilinx?
I'm going to have to disagree with you. If somebody already has a RPi or BB, then this board makes a whole lot of sense: it just stacks on top of your existing unit, both physically and logically. In Zynqland it'd take quite some effort to construct the abstraction layers that they seem to be building into this project; you have to do things like rebuild the FSBL and binfile and it gets to be a pain. There's a community of sorts but it's small peanuts compared to the RPi juggernaut.
I agree that the bandwidth between the PS/PL is really awesome and blows away the separate-chip solution. But lets get real: beginners don't need that kind of performance. It's better for them to have something that's encapsulated and somewhat friendly-fied so they can get their feet wet, rather than drowning them in arcana right out the gate.
I also don't think the MicroZed is a good idea for hobbyists, unless playing with Linux is all you're after. Most of the IO is on the high-density Bergstak connectors, which means that you either buy the official (limited) carrier board, or roll your own custom carrier. And since the main attraction of SoC/FPGAs like this is fast I/O and tight coupling, unless you're doing something relatively high-performance and willing to spend money on the requisite hardware development, it doesn't make sense to adopt this platform. I see MicroZed as a vehicle to speed up project development; not so ideal for the hobbyist.
You seem to be pushing an awful lot of signals across the PCMCIA connector, with hardly any ground pins. Is signal integrity okay?
The Minty MP3 was also a big 'wow' for me. I don't think I've built any Lady(ada)fruit projects, but I've certainly studied a bunch of them over the years.
Well, I stand corrected. Thanks for the link.
Our city has LED traffic lights and even moderately strong FM stations disappear completely at intersections.
I very much doubt that LED lights produce output in the 90 - 110 MHz band. Switching supplies are generally 0.1-2 MHz.
But hey, call the FCC. They don't mess around when it comes to interfering devices.
Software drivers are a challenge, and we will work on providing some level of drivers, with the hopes that the community takes them up and pushes them to new levels and provides problem reports to us.
I assume the #9 is not nearly as complex as a modern-day GPU, but this sentence really concerns me. As a hardware guy myself, I'd want some more experienced hands on board for the software side. And a Linux driver needs to be part of the deliverables at least.
Also, what's the resource utilization? If this thing only runs in large Virtex-class chips then it's not terribly useful to the open-source community.
It would be really cool to have a graphics core of this level open-sourced, but I think the audience for this project is kind of small. You could build yourself a PCI graphics card for kicks, I guess, but you'd still need a PCI motherboard. Where it gets more interesting is with the "generic interface" option. Then for example you could use a Xilinx Zynq (which is an FPGA+ARM), implement the GPU in the FPGA, and talk to it on-chip over AXI. However I have a feeling they won't get to the $600000 level needed to make this possible.
Bunnie has described this project as a "bespoke oscilloscope", so it's probably going to cost thousands of dollars. If that horrifies you even more, you're probably not the target audience.
All this hype about "the golden age of OSHW" is nonsense though.
"Boards ship" sounds fine to me, but I'm a hardware guy.
The more serious problem is that EOMA-68 doesn't appear to have anything to with the Vivaldi hardware. I mean, does a tablet with a removable CPU card make any sense whatsoever?
I've tried entering a Google Voice number in that space, but FB wouldn't take it. It's easy to ignore that screen though.
Those dedicated to the doing
How transcendentally awful. Adding lines to a sonnet and not respecting the structure. Was it too much effort to do it in iambic pentameter?
The Beaglebone has (had) this weird procedure where you plug it into USB, then "eject" it to activate a different mode. The first time I installed Beaglebone drivers is the only time it went smoothly. Later on different machines, all sorts of odd devices came up. In the end it was just easier to interact with it over SSH, so I can understand the decision to remove the USB-serial interface.
Having lived most of my life in the Bay Area, including six years in Berkeley, I would agree with your assessment. The City Council attracts some strange characters, and there is a slew of "committees" on topics that range from bleeding heart liberal issues to just plain weirdness. I consider myself fairly left/liberal but sometimes the Berkeley/SF councils seem like they're in a contest for craziness.
You don't want to pick up new interests unless they directly support your life/sanity as a PhD student. Things like learning to cook or getting into fitness, yes. Things like learning Haskell for a great good, picking up Arduino, not so much. Learning R, okay maybe that'll save you time down the road. You only have so many spare cycles for technical stuff, I've found, and any half-started projects will only linger around frustratingly.
If you have a qualifying exam in your program, find out what's on it and get an idea of how difficult it will be. Start studying; it doesn't have to be every day, but it'll do wonders to go into it with confidence.
Ouch. Yeah, wishful thinking doesn't make for a viable product.
As long as we're comparing mysterious numbers*, let's take a closer look.
Future Chip:
38 GFLOPS / 2.7W = ~14 GFLOPS/W
Tesla K20x:
3950 GFLOPS / 235W = ~16.8 GFLOPS/W
Radeon 7970:
3790 GFLOPS / 280W = ~13.5 GFLOPS/W
So I'm not seeing a power advantage here. More questions: does the chip do double precision, and what's the rate? What's the memory bandwidth? Is there support for ECC/scrubbing, which is essential for Big Deal calculations? (The 7970 doesn't support ECC. The Tesla does, and it had better given the amount of money you pay for it.) I'd imagine the Future Chip would be a cheaper solution, but you're starting from scratch with the compilers when everyone else has a major head start.
So while I think a FSF Principles chip is a good idea, pitching it for scientific computing is a stretch.
*Future Chip numbers probably do not include memory power consumption, and are likely a optimistic extrapolation from the dual-core silicon. Radeon result is the unholy combination of AMD's published single-point FLOPS and the max power consumption from Anandtech's review. Tesla numbers are marketing numbers combined with TDP.
It's an OmniVision part, but yes, it seems to be all closed as usual. I've never understood why image sensor documentation is so locked down.
Thanks for the tip about Energia. My old robotics club bought a bunch of MSP430 Launchpads when they came out, but the software side of the equation was definitely lacking, especially for cross-platform development.
I'm also excited about the Stellaris Launchpad and hope that an open source command-line workflow will be developed. Should be fun.
Which is probably a capacitor problem, because both transformer-DC and switching wall warts rely on large filtering caps.
To be fair, the Stellaris Launchpad is obviously a loss leader. The earlier MSP430 Launchpad never really gained a foothold in the hobbyist community despite its low price, so it remains to be seen how TI will manage this time around. Perhaps they don't care.
I thought the bit about intersections was hilarious -- "someone's going to own the intersection, so we defer to property rights and all problems are solved!"