Maybe for each passing hour, the forthcoming update will be more detailed/specific/certain and otherwise juicy. Well, not juicy in the sense of features, as we pretty much already know what to expect feature-wise (and are all salivating). Incidentally, there doesn't seem to have been any real feature creep with the current design; it just takes time to nail down the details. And even if the FPGA image were ready to go now (no idea about that), one can imagine that it's still challenging to prognosticate about the schedule to final silicon. Still, it will be great to learn whatever they can tell us.
When Ken said he would post an update by Wednesday (yesterday) at the latest I believe he was just referring to a status update and not an FPGA image. At this point I would be happy just to get some details on where the project is. I am a bit disappointed in Parallax for stating that they would do something and then not deliver on it. To me this shows that Parallax is either unorganized or they value their customers at a lower level than everything else that occupied their time yesterday. It may be that Ken had an emergency yesterday that occupied all of his time, and he didn't have 5 minutes to post a status update. Maybe he'll have 5 minutes today to give us an update.
No, there's no emergency unless you consider being willing to let Chip sleep the last couple of days. Please don't mistake the lack of an update for being unorganized or valuing customers at a lower level than everything else. The reason we're late is because the last few days brought a few surprises I had to manage: 30 engineering students visiting Parallax next week from Germany; a TV broadcast running from our office next Wednesday; some changes in our distribution network; and a few personnel issues that were important to our staff, and therefore the company too.
I was referring to a status update, not an FPGA image. We're working towards it now.
No, there's no emergency unless you consider being willing to let Chip sleep the last couple of days. Please don't mistake the lack of an update for being unorganized or valuing customers at a lower level than everything else. The reason we're late is because the last few days brought a few surprises I had to manage: 30 engineering students visiting Parallax next week from Germany; a TV broadcast running from our office next Wednesday; some changes in our distribution network; and a few personnel issues that were important to our staff, and therefore the company too.
I was referring to a status update, not an FPGA image. We're working towards it now.
Ken Gracey
Good luck with the students. I hope they leave with a lot of enthusiasm for Parallax and the Propeller!
TV broadcast? Be sure to let us know if it's something we can tune into.
You're most welcome. Chip is well into the design groove right now and I'm certain he'll surface at the right time for us to provide more details than I did.
Ken, great update thanks, as to what we want to hear, it's all in Chip's capable hands, and he's on it, is all we need to know, as I said in my earlier post, it'll be ready when it's ready.
We all have the upmost faith in Chip creating an awesome chip, with pretty much zero errors, and as perfection takes time, then it will take time, and in the mean time, we still have the P1 FPGA source to play with as I've yet to play with it, I can't wait to!
Hehe, impossible is a strong word. Any spec in particular?
I can think of Hubexec I guess. It needs an instruction cache, assuming that gets sorted to Chips liking then Bob's your uncle. SDRAM execute-in-place should easily flow from Hubexec.
I can think of Hubexec I guess. It needs an instruction cache, assuming that gets sorted to Chips liking then Bob's your uncle. SDRAM execute-in-place should easily flow from Hubexec.
Hub exec was working on the earlier P2, so that proves it is not impossible.
Hub exec is important enough to take some effort to implement.
Execute in place from SDRAM will be nice, I would add XIP from QuadSPI FLASH and maybe even XIP over the new Spansion HyperBus, which will have FLASH and SRAM devices (eventually).
That all depends on hardware support for the interfaces. I only mentioned the SDRAM because it's listed in the spec. I guess it comes back to feature creep again.
Execute in place from SDRAM .... That all depends on hardware support for the interfaces. I only mentioned the SDRAM because it's listed in the spec. I guess it comes back to feature creep again.
The most important advantages of the prop 1 are deterministic execution, and low chip cost COUNT. (sorry I meant low chip count) And the timers are great.
Things like the video are not relevant on most applications (so far) and the apps the were written to use the video did not take off (at least in my narrow experience).
Something like "making the prop into an arm" would render the prop irrelevant, since the arm arlread exists and is doing it job just fine.
Since feature creep was mentioned, I would like to refresh the notion that deterministic execution and timers is the only thing we really NEED in a new chip. More cog, memory and pins (and anything else) are only advantagous if deterministic execution, timers, and low chip count are maintained as the first priority.
Execute in place from SDRAM worries me that there is a risk "low chip count" is being replaced by "making the prop into an arm"
Maybe true 10 years ago, but embedded processors are now commodities, with ARMs less than 50 cents in single quantities. I expect to see them for less than 20 cents next year.
Am I suggesting Parallax should build a cheap or mid range or any kind of ARM, heck no that would be about as stupid. But I would like to see Parallax make use of some of those commodity parts that were designed in this century not the last one.
prop 1 are deterministic execution, and low chip cost
-- Prof Brano
Any examples in particular?
Basically any ARM to update the BASIC Stamp (2K Flash and 32 whole bytes of RAM, really, it WAS great in its day, but that was 25 years ago), let me check my email on my Win95 machine...
And the Prop, done in a process technology of 1995.
Yes the educational community doesn't much care, there are probably still people out there using Apple2's, and the hobbyist community doesn't care as much. But really, in the days of RasbPi, now the Intel Edison for embedded with video, WiFi boards <$30 with dual ARMs, other ARM boards <$20, and who knows what else might come out in the next 2 years, I don't get it.
Yes playing with an open source CPU on an FPGA might be fun, even education, but it's not going to sell lots of units.
But really, in the days of RasbPi, now the Intel Edison for embedded with video, WiFi boards <$30 with dual ARMs, other ARM boards <$20, and who knows what else might come out in the next 2 years, I don't get it.
You don't get deterministic execution or programmable I/O interfaces with the RaspPi but if you really want to go the way of the Pi then get that and Bill Henning's RoboPi and get the best of both worlds!
Basically any ARM to update the BASIC Stamp (2K Flash and 32 whole bytes of RAM, really, it WAS great in its day, but that was 25 years ago), let me check my email on my Win95 machine...
And the Prop, done in a process technology of 1995.
Yes the educational community doesn't much care, there are probably still people out there using Apple2's, and the hobbyist community doesn't care as much. But really, in the days of RasbPi, now the Intel Edison for embedded with video, WiFi boards <$30 with dual ARMs, other ARM boards <$20, and who knows what else might come out in the next 2 years, I don't get it.
Yes playing with an open source CPU on an FPGA might be fun, even education, but it's not going to sell lots of units.
Which uC is used in a class depends a lot on the type of class being taught. My feeling is that a class teaching FPGA programming may be better suited to a EE class. The son of a friend is going to U of I for a CS degree and was taking a class in uC programming class. While the course didn't specify which uC they were to use for the class the options available in the lab were Arduino and rpi. I gave him a parallax activity board and a parts kit for the PEK and he LOVED it! After showing it to fellow students in his class they loved it as well and enough of them bought the board and PEK parts kit that the school is considering adding a supply to the boards available for checkout in the lab.
Comments
Are there any updates to post guys? we're turning blue here holding our ever eager over excited breath
I was referring to a status update, not an FPGA image. We're working towards it now.
Ken Gracey
TV broadcast? Be sure to let us know if it's something we can tune into.
As for the update, there's no rush, it'll be ready when it's ready, we all know you can't rush creation, nor can you rush perfection.
Chip, rest well my good man, for you have earned it, besides, your health is far more important to us than any prop!
It may not say what you want it to say, but it's where we are in the process after much communication with Chip.
Your comments and input are welcome, of course.
Thanks,
Ken Gracey
Thanks, David. A third bullet has been added to the description:
- Cogs can execute code from both cog memory and hub memory
BTW, check your e-mail and reply to me about your C code for the DefCon22 badge.Thanks,
Ken Gracey
You're most welcome. Chip is well into the design groove right now and I'm certain he'll surface at the right time for us to provide more details than I did.
Ken Gracey
We all have the upmost faith in Chip creating an awesome chip, with pretty much zero errors, and as perfection takes time, then it will take time, and in the mean time, we still have the P1 FPGA source to play with
The specs just seem impossible.
Not difficult... impossible.
I think that is why the guys want an FPGA image ... it just seems... so... impossible.
Rich
I can think of Hubexec I guess. It needs an instruction cache, assuming that gets sorted to Chips liking then Bob's your uncle. SDRAM execute-in-place should easily flow from Hubexec.
This is the smartest scheduling statement I've seen from a company concerning new development.
This is the second smartest statement I've seen from a company concerning new development.
I think that is an excellent and realistic roadmap.
Hub exec was working on the earlier P2, so that proves it is not impossible.
Hub exec is important enough to take some effort to implement.
Execute in place from SDRAM will be nice, I would add XIP from QuadSPI FLASH and maybe even XIP over the new Spansion HyperBus, which will have FLASH and SRAM devices (eventually).
It may be that HyperBus verilog can be proven on P1V ?
The most important advantages of the prop 1 are deterministic execution, and low chip cost COUNT. (sorry I meant low chip count) And the timers are great.
Things like the video are not relevant on most applications (so far) and the apps the were written to use the video did not take off (at least in my narrow experience).
Something like "making the prop into an arm" would render the prop irrelevant, since the arm arlread exists and is doing it job just fine.
Since feature creep was mentioned, I would like to refresh the notion that deterministic execution and timers is the only thing we really NEED in a new chip. More cog, memory and pins (and anything else) are only advantagous if deterministic execution, timers, and low chip count are maintained as the first priority.
Execute in place from SDRAM worries me that there is a risk "low chip count" is being replaced by "making the prop into an arm"
Maybe true 10 years ago, but embedded processors are now commodities, with ARMs less than 50 cents in single quantities. I expect to see them for less than 20 cents next year.
Am I suggesting Parallax should build a cheap or mid range or any kind of ARM, heck no that would be about as stupid. But I would like to see Parallax make use of some of those commodity parts that were designed in this century not the last one.
Who is that in reply to?
Any examples in particular?
Basically any ARM to update the BASIC Stamp (2K Flash and 32 whole bytes of RAM, really, it WAS great in its day, but that was 25 years ago), let me check my email on my Win95 machine...
And the Prop, done in a process technology of 1995.
Yes the educational community doesn't much care, there are probably still people out there using Apple2's, and the hobbyist community doesn't care as much. But really, in the days of RasbPi, now the Intel Edison for embedded with video, WiFi boards <$30 with dual ARMs, other ARM boards <$20, and who knows what else might come out in the next 2 years, I don't get it.
Yes playing with an open source CPU on an FPGA might be fun, even education, but it's not going to sell lots of units.
Which uC is used in a class depends a lot on the type of class being taught. My feeling is that a class teaching FPGA programming may be better suited to a EE class. The son of a friend is going to U of I for a CS degree and was taking a class in uC programming class. While the course didn't specify which uC they were to use for the class the options available in the lab were Arduino and rpi. I gave him a parallax activity board and a parts kit for the PEK and he LOVED it! After showing it to fellow students in his class they loved it as well and enough of them bought the board and PEK parts kit that the school is considering adding a supply to the boards available for checkout in the lab.