Potatohead, that is golden. I can easily imagine how that could flow. I'm going to do it that way. Thanks a lot for the elaboration. The way I've been approaching this has been more traditional and that just doesn't work these days. I will do and explain and ask questions as we go. This is kind of a life-saver. Thank you very much!
Sounds like the educators here have hit similar problems to those of Eric Mazur and potatohead may be adopting an approach similar to what Eric came up with.
Eric Mazur was teaching Physics to medical students at Haravard. Most of them were not interested in Physics and found it boring. A chore they had to go through to be able to go on with their medical studies. His students did pretty well in the examinations. But then after some years he discovered that whist they passed the exams they had not actually learned any principles of Physics. They had learned by wrote and could not apply what they learned.
To fix that Eric abandoned the traditional method of lecturing to a room full of students, them taking notes, possibly memorizing it and passing the exams.
In short, he turned his "lecture" periods into interactive discussions. Not between student and him but student to student. Seems students learn well from each other. Those that "get it" can explain it to others that don't far better than a lecturer can.
That discussion between students moves Physics from being boring maths to the curious and fascinating subject that it is. The ideas of Physics get soaked up, not just the equations.
I suspect anyone involved in education would be interested in some of Eric Mazurs talks on this. See below. Of course his style may not fit courses on CAD for engineers or Robotics for kids but there might be some useful ideas in there. They are fascinating talks anyway:
That IS GOING to work for teaching robotics to kids. That's simple and ingenious... Get those that understand to teach the others around them. Perfect. Actually, that's what we're bringing kids there for, already, but we'll get the Chinese kids in on it, too. Thanks!
I think it's a great idea. Get's the students engaged in the subject and with each other. Hopefully all of a sudden they have a social network in the class and don't need to check Facebook every 5 minutes!
In one of his talks Eric shows a video of a bunch of young girls around a table, in India I think, they are laughing and joking and you would think there was a party going on. Oh no, they are learning and explaining statistics to each other!
A key take away I got from Eric is that it can be easier for a student who just got the idea to explain it to another who did not. That student is new to it and knows the difficulty. The lecturer has been known his subject for so long he thinks it's obvious and forgets the million ways a newcomer can start thinking about things wrongly or miss the main point.
Personally I would have hated the collaborative style in school and uni. I was never very social that way. But I used to love listening to lecturers for an hour or so. I would be totally mesmerized by the train of argument in Maths, Physics etc. Mind you, that only worked for a few very good teachers/lectures. Perhaps the Mazur approach would have helped me for the others.
Potatohead, that is golden. I can easily imagine how that could flow. I'm going to do it that way. Thanks a lot for the elaboration. The way I've been approaching this has been more traditional and that just doesn't work these days. I will do and explain and ask questions as we go. This is kind of a life-saver. Thank you very much!
Please feel free to contact me to discuss. You know the number.
That training I just described? Can be up to 2K per day, and every single group calls me back. Good when I can get it. And it's intense. When it's done, I am completely drained. Left it all in the room. Fine, they paid.
Now, I will say a couple more things, because I should at this point. I'll share a few day class flow / experience.
You've all read me writing, "people don't need to know much to x", and this is why. The learning trends are clear, and too much state, too many required details per task just choke people. We are used to it, as that is the way we learned. It's not true today, and we aren't going back on all of that.
(which is why I love SPIN, and it's open, "wild" nature and hope we don't break it with too many features. Less is more. Seriously.)
One other advantage I find useful as a free lancer: (I don't work officially for the same people anymore, but they still contract this from me, because they just can't get it anywhere else.)
I can give all the class materials away. They get everything, brief notes, files, all of it. That's not the secret sauce anymore. Truth is, nobody needs me. If they get after it online, they can learn anything they want to. We all know this. I do have some light presentations. They are rules of thumb, voice of experience type things. All else is links to the software or other online documentation. (which is where they should learn to go anyway, might as well get that done right now)
What they need the most is that "voice of experience" and they need "football coach" to get them excited, put the stuff into context and to guide them toward success as they attempt things. Get excited about doing it, because the WHY behind doing it, and the value of doing it is very clear. Very important these days. No why, no value? They just won't do it, and won't care that they didn't do it, nor about you, who tried to make them do it.
They also need someone to recognize them. Nice work! Hey, that was clever, show me again... Every little bit of that will shape a career. No joke. It's worth a lot.
It is super important each atomic thing have a point to it, and it doesn't need to be much, just enough to support the concept. From there, if it's a flexible thing, say one that just drips with needing to be tinkered with? Pure gold, because a lot of them will do exactly that.
One, for assembly modeling, is a parametric box and lid. Change the box, the lid always fits! This is very simple model, but they can go to town on it! The exercise is idealized for success. But, advanced people? I challenge them to provide full detail, draft, fit features, etc... make a real part of it. Everyone has success, everyone gets a challenge, few are left out.
And guess what?
When they run into trouble?
That's the real learning right there, that's the thing they have the most trouble with on their own, online. The "debugging", and I put that into quotes as CAD shares a lot with programming and electronics, it's not quite the same in this sense. However, the concept is exactly the same.
How to recognize trouble, and what to do about it is what they pay for. The rest? It's either discovered in the moment, or learned from context. Monkey see, monkey do. The little details don't matter. What does is the philosophy, how to think, why to think that way, etc...
To that end, I do a controversial thing at times. I have some puzzles. They have multiple solutions. These puzzles build basic competency and teach how to think. I show them all the elements needed to build solutions, ask them to build solutions, and then inform them I will be leaving the room for 10-15 minutes. And then I do.
Get my drink, walk around a little, relax.
When I come back in, some will have solutions, many will have questions. Perfect! Now we are ready to learn. I then model a few possible solutions, then take a few minutes to work through partials for the ones that did not succeed.
Frankly, doing that eliminated a few hours of lecture to emphasize concepts they will get by working for it, and getting a little frustrated, ready to see the answer and value what they see.
It's about sharing that kind of thing to the max extent possible, while being playful and flexible. Failure is OK. Not communicating about it isn't. This is good career advice anyway. Might as well get that learned and set as a norm too. Happens on day one.
I will go to the mat to help you get it, but you gotta be working for it too, or I won't be successful. I make that extremely clear. Then have fun doing it. I get a new challenge nearly every class! People will just do stuff. Crazy stuff I would never have thought of. Fine, I'm better, and so are they.
Finally, there is one secondary advantage: Voice of authority. Often, I get asked about credentials prior to a session. I do not supply them. They can get references, if they want, but that's it. This is my deal, I thought it up, it works, and it's not the norm. There are no credentials to supply.
It's simple, I show up and do my thing. If there isn't success, 100 percent refund. No questions asked. Nobody has ever asked, and they won't ever ask, because I keep a map of the students in my head. I know damn well if they are gonna make it or not, and if someone isn't going to make it, I get that all communicated for followups, or a mentor, or something for them. They need to make it. Got families, etc... riding on all this, and I take it seriously.
For students, younger people, a lot of that can be left out. But for adults? It matters, and once they know you get it, they will value the time and likely succeed.
Each one is making progress. I know them, see where the gaps are, and often will include material targeting these gaps, and I'll often make that up during the lunch break, or free time period too. This is the advantage of the interactive technique. It's not hard to come up with stuff once one gets used to doing it.
The key to this is to own seeing their understanding. It need not be complete. But they do need basic competence and the right mindset. With those two things, they are off and running, able to grow. Things like they can find A solution vs finding THE or an optimal solution. Finding A solution is the start. Experience is the rest.
Think of it like being able to read. Once you have that, the door is open right? Same thing with how to solder, how to surface mount, how to write code. Once they get those, they can proceed to fail a lot, fail hard, and get where they want to be.
If I were you, and it's possible, at least one session on "scope as debugger, assistant, general tool" would be a pure gold session. Over the years, I've grown so damn much from the bits I got here. I use my scope, and it's an older 4 channel analog Tek, but it's fast. And I use it as my eyes, and that is sweet. I don't see that shown much. IMHO, it should be.
Anyway, take the discipline and break it into the necessary pieces. For CAD, as example, this is:
Geometry concepts, planes, coordinate systems
Bodies, sheets (surfaces), sheet bodies, curves, points, "what is an entity?"
Modeling, cut, join, intersect, history, non-history (direct)
Features, extrude, revolve, free form, loft, sweep
Parametrics, equations, units, conditionals (not often taught, but I do)
Assemblies
Constraints (how they can be used, three different philosophies)
And those are (no constraints, partial constraints, full constraints) Trade-offs, match strategy to problem.
Each of those gets broken down into some little exercises, delivered interactive, in a way people can follow along, create, do, test, explore.
After about three days, my students can generally model, assemble, make drawings, output derivative files. They can also match features to design requirements, parameterize when it makes sense, direct model when it makes sense, and troubleshoot a design.
The most important thing I make sure they can do is to draw without knowing much of anything. They either visualize the shape in their heads, or are drawing one they can see a picture of, or a real object. From that, visualize all the relationships, tangents, things that are centered, design intent. Boil that down, and most models require remarkably few givens, the rest is best practice or geometry actually holds the answer for them. Time spent reducing the problem, factoring out noise, identifying real, important givens, is time very well spent.
This is analogous to "coding on paper", something I learned here from you guys. It's worth it's weight in gold, IMHO.
Result: The only numbers I have go through their heads are the ones that need to come from their head. Every other thing is derived to the maximum extent possible. This makes for solid design work and a focus on what really matters, leaving all else to standards, best practice, or "doesn't matter, go minimum or maximum material condition, call it good."
This is analogous to focusing in on the core problem, working through that, then building out the other stuff surrounding the problem. Limit what you have to know, and that maximizes your ability to sort through choices and find solutions.
In CAD, number of unknowns are generally degrees of freedom. I have found ordinary people can process a handful of these no problem, but it's exponential. 20 is ugly. 50? You need skill. Hundreds? No hope, it's a mess. Refactor.
The test is free drawing time. Near the end, I ask they make something they can see in the room, assembly if they want to.
When that happens, they are on their way. When it doesn't, I got work to do with that one, and do that work.
That's kind of how I run it. An 8 hour day is roughly 6 hours of instruction, one hour free form, catch up time, the rest human breaks and chatter.
Overtime is for problem cases, or some edge case they get fixated on. I'll do those, add to library, and extend the class a little to weave it in. Usually, those are triggered by their particular job requirements and design scenario framework.
I don't have an analogy here for younger students. Maybe there isn't one.
Heater: That will work well. That guy nailed it. I'm now a fan.
I got there school of hard knocks style. These days I do classes for groups on demand. Sometimes there is a lot, other times I'll go a considerable time.
10 years ago, I was knocking out two a month. Built up those techniques based on a sort of "do what it takes" approach. I would talk with the students often, and in those conversations they would basically tell me what was going to work.
The most important thing was to listen and actually act on it. Was tough to buck the trend too. Took heat for it, but I've got a long record of happy, successful groups. Many of my peers, who do not embrace this stuff, see me follow up later.
Go Chip! Seems like you got the basics in this chatter. Run with it. Have fun. Smile, and share the fun, share that which drives you. They will draw energy from it, and share it, and that is infectious.
When you do it right, nobody wants the class to end.
By the way, my demographics today are:
I'm the old guy. Getting old sucks. I say that. Regularly. I also share my excitement for the ride they are about to embark on. Ride it for all it's worth! I did. I will share how I got to be in front of them and some of what that meant to me. It's an ice breaker, get to know sort of thing. I invite them to share their stories, expectations. I take notes during this time.
They share, at that nice, fun time, exactly what the goal of the class needs to be, and I meet that goal, regardless of any other agreement. Secret sauce here guys. Enjoy.
For a long time, students trended older, 40's and up. These days, they trend younger, 20's and up.
When I started, I was the kid. 20 something dishing it out to seasoned engineers 40 and up. Tough crowd. Definitely school of hard knocks for me. It's easier now for me. One case where some age helps.
Hopefully all of a sudden they have a social network in the class and don't need to check Facebook every 5 minutes!
Heater, that is the magic. When the class is social, they are comfortable, having fun, it competes with Facebook. And it wins. Almost every time.
One of the best ways is to celebrate failure. When I get caught on something?
Always the same:
"Nice work! You got me, now let's figure this dang thing out!" The whole class will jump in, and we do usually figure it out. I tell them that goes in to the next one. Thanks. I'll also frequently quip, "you see? This stuff is never dull." And that's an attempt to make exceptions and troubleshooting cool, fun and infectious.
Or,
"Nice catch!" I'm slipping. Let me back up a bit here and do this right for you guys, because this will happen to you...
Humility and humor are both powerful in this context. Laughing replaces angst and frustration. And that tends to lubricate the thinking machinery. Good stuff happens.
Bring more than you need. At first, you won't be able to do this. No library. So, you queue things and make the necessary goods at night in the hotel room. Sucks, but every time you do, it multiplies. Won't be long before you are looking for one to do as your body of material crosses the majority bell curve cases.
Then you can always make standard ones better.
Then, as the class progresses, use your judgement. Drop the material needed, when needed. Adjust dynamically. Don't share all that you brought. Set expectations reasonably low. Then you can raise them. The group dynamics help you understand when this makes sense.
Lowering expectations sucks. So don't do it.
Watch the students. They tell you what is needed by their actions, questions, inactions.
Less can be more. Basic competency trumps a broader set of skills presented, but lacking initial mastery or applicability by the students.
Heater, I just finished the first video. Well, almost. But, I paused it to share a couple thoughts:
First, this was great. He applied the scientific method here. Worked from the data and came to some very interesting conclusions, then validated them.
This mirrors my experience, sans a formal data collection. I happen to have an extremely good memory of people and conversations I've had. Can play them back in my mind even years later. Over time, I got similar data in a more coarse way.
I find the data regarding conceptual understanding vs what I'll call rule based, or computational understanding profound, and it mirrors my experiences perfectly. In my own internal frame of reference on these things, this is "how to think" and "philosophy" as in more or less why one would think that way, advantages, dynamics, nature as authority mandates it, etc... I realize that's coarse, but it's for me, so who cares?
For me personally? If I can't visualize it somehow, make a mental model, I really don't understand it, and it all really is monkey see, monkey do, as he says there with the Kirchoffs law example. That sucks. If I can visualize it, I own it conceptually and can often arrive at an intuitive answer quickly, which can be validated, or quantified by computation later on.
That's a big deal. His methodology is sublime. Love it.
Put into this context, when I came here many years ago, returning to this hobby, and my own hopes of returning semi-professionally, I had a lot of intuitive understanding, conceptual. What attracted me to Chip, Parallax, and this general community was how so many things get boiled down to first principles and then explained or extrapolated to a problem and or solution. The thinking here is remarkable in that way.
With the Propeller specifically, I found myself able to jump in with SPIN + PASM, and do things intuitively. The lean, not rigid nature of both, got me to solutions quickly. There was not too much to work with, and that made finding solutions easier, and what there was to work with was flexible, so I could improve on them, or collaborate with others to improve them, and it's all sort of fluid in a way I had not experienced much before.
Since that time, I've grown in both areas, though I'm consistently weak on computation, just because I don't do this stuff every day. Conceptually? I've learned a ton, and I love how we've got this library of great stuff one can grab, tinker with, understand in the moment, then bend to solve a problem, or just learn the dynamics of things fairly easily and without gross "let the smoke out" failure.
Applying these techniques, deriving from the thought here, should work very well with students, given this method.
For young people, and for electronics, some of what I put here isn't as applicable as it needs to be. And that's just my own experiences, tuning for my problem space in action. No worries.
This video does however get right to the dynamics of it all, and does so clearly and convincingly.
Gold. Nice reference, and thank you for putting it here.
There are some aspects of what I do that remain problematic. I see now that I've had the solution, which is to get the conceptual work done solid, but haven't always seen it that way. Can't wait to give that a go on a few difficult problem sets.
He doesn't go into "play", or I haven't seen it yet, but I suspect that's simply due to his level of education and student body.
For assembly problems, I'll literally provide the students with kids toys. Tinker Toys and legos. I'll have some real ones handy, for people who need to learn to simulate in their minds, but the real draw is the virtual ones. I make a nice set, and teach the mechanics interactively, then cut right to free time, no problem sets presented.
Goal: Take an hour and build cool stuff.
Some people take the real ones, model something, then model in the computer, then compare. Very good. They get robust, basic understanding. That's the minimum, and it's a win.
But, most often, they will go off into all sorts of places! Those questions, "how do I?" are amazing, and I still get new ones every single time. The number of possible paths on something like that appears near infinite, though the dynamics and software functions seem fairly finite. They still think up stuff that I've not seen, or will have to work through.
During the free form, "just build something" time, a ton of peer discussion happens, with the students often forming little groups to do something they think is cool. Or, it's one of those, "bet it can't do this" type scenarios. (that comes up with the Tinker Toys often as those present a much broader set of possibilities and complexities than the legos do.)
Lesson there: Even simple things can lead to significant complexity and or subtlety.
Anyway, thought I would share a few thoughts. Great reference for me personally. And I really appreciate this guy doing the science. Nice work.
I strongly recommend anyone doing education watch this material. He's on point, and has grasped the social dynamics and is able to present them in a compelling way.
Honestly, he should have applied those techniques to the group he is lecturing to. I'll bet the majority of "students" in that lecture hall, who are peers I assume, will leave with the ideas, but will lack the intuitive understanding they will need to have for success in the method. However, they will also get them via the school of hard knocks, so no real harm done.
...he should have applied those techniques to the group he is lecturing to...
That thought crossed my mind at some point.
Then I though it's just as well he did not. Would have made a mess of the presentation for YouTube. Can't do the interactive thing whist watching that. Just tell me the story from beginning to end.
Or can we.... You are watching the video and taking a break from it to discuss here. We are a microcosm of the class dynamics he's talking about!
Wow, ErNa, that's an interesting look at the history of "students teaching students"
I love this:
"Kids love to learn from other kids. First of all, it's often easier. The child teacher is closer than the adult to the students' difficulties, having gone through them somewhat more recently. The explanations are usually simpler, better. There's less pressure, less judgment. And there's a huge incentive to learn fast and well, to catch up with the mentor."
Basically what I tried to say above but better put. Replace "child" with "student", of any age, and I'm sure it is all still true.
Also this:
"Kids also love to teach. It gives them a sense of value, of accomplishment. More important, it helps them get a better handle on the material as they teach; they have to sort it out, get it straight. So they struggle with the material until it's crystal clear in their own heads, until it's clear enough for their pupils to understand."
Never mind "kids love to teach". So many times I have heard even aged university professors say they love to teach. Because when they have to think about the thing hard enough to explain it to someone else then they understand it better themselves. Or even start to see new things that can be done with it.
How did all this get forgotten in school, college and university?
@Heater, go to Youtube, look for 'Idiocracy', the first 15 minutes explain it very well, the rest of the movie is not as good as the beginning.
And yes, you are right, to understand something better it helps to explain it to somebody else, even if he/she has no clue about it. But thru the process of explaining you clarify it for yourself.
I'd have loved to have P2H to play with for a few years! I thought it should have been released, and people who needed low power could have lowered the frequency and perhaps had unused cogs wait.
BUT
the current P2 looks good too, hub exec, no penalty running code from LUT, smart pins, XBYTE, interrupts etc are something to look forward to.
Perhaps for the P3, take P2H and add current P2 design features to it? Keep it once cycle, add the new features, shrink to 45nm or so, multi-threading and accept the higher power envelope for the performance gain.
I skimmed that first page. Much could be critiqued about how things have gone. That was before smart pins and a bunch of other developments.
Looking back, we should have pushed through P2-Hot, just to have something completed. The one-clock-per-instuction with automatic pointers was really nice.
What we have now is very nice, too, and I believe is still much lower-power than P2-Hot would have been.
A new test chip will be underway soon. Then, we'll make a full chip - barring the advent of a global economic crash or world war.
Perhaps for the P3, take P2H and add current P2 design features to it? Keep it once cycle....]
One Cycle reads good on a marketing brochure, but it can compromise the overall performance.
ie if you meet opcode timing, the Counters/Timers end up running much slower than they could have.
Of course, another 'way around' that is to claim the Core is one cycle, and the peripherals are clock multiplied.
I'm seeing more MCUs do exactly this: where the peripheral clocks are increased relative to Core clock.
This gives full silicon performance on the peripherals, but the core runs slower.
In the case of P2, you could then claim WAIT opcodes give 'fractional cycle precision', & I guess users are used to that.
Once you have a PLL, there are often multiple clocks in a device, and IIRC the NXP parts start at 2x SysCLK on the VCO, in order to have 50% duty cycle clocks.
To avoid confusing users, that 2x value is not formally mentioned.
Existing P2 DOCs could easily do the same, reference everything to OpcCycles, and call the timers Clock doubled.
You really can't compete on performance with the P2. Before you say there are 16 CPUs, they are all bottlenecked by the hub performance, your program any larger than 2K can't run any faster than 80 MHz or 160 (was it dual ported?)
As for peripherals, with 100-200 MHz CPUs there is not much reason to run i2c, serial, CAN, most SPI or many other serial peripherals at that rate. They will all clock at much lower rates though often take the high rate clock to generate baud rates.
HubExec, in a straight line (Because of the FIFO), goes at full speed. Branching has a cost though.
And all 16 Cogs can, in parallel (Because of the "egg beater" crosspoint switch), do that unimpeded. That's why, on a number of occasions, I've highlighted the huge performance gap between the internal RAMs and what could be achieved with any external solutions.
When I say full speed, I mean the same two clocks per instruction that a Cog can do from its CogRAM. And all 16 Cogs doing that simultaneously can still only use 50% of available HubRAM bandwidth.
SETQ+RDLONG burst instruction could theoretically use 100%. Streamers could too.
That's why, on a number of occasions, I've highlighted the huge performance gap between the internal RAMs and what could be achieved with any external solutions.
Yup, and that performance gap is exactly why external memory 'needs all the help it can get', in the form of simple HW supports.
Such performance steps/knees are common across all processors, a general rule is the further away memory is, the slower it is to access.
Also, as you allocate fewer pins to such memory, the slower it gets as well.
Memory does not stand still, so today we see Latched/Mux'd RAM, and QuadSPI added bandwidth to good ol' SPI, and now DTR/DDR doubles that again, and HyperRAM uses octal bus.
Hubexec uses a FIFO buffer at each cog, so hub memory is still accessed round robin style, but the cog gets instructions from the FIFO at full speed (unless you branch).
Data access to hub is along side the FIFO, so it operates/performs the same as COG code accessing hub memory. It'll be slower than direct COG/LUT data access in most cases.
All cogs can access all hub memory. Hubexec can't execute in the first 4k (I think) of hub memory since the addresses overlap COG/LUT, so branches to those addresses execute the COG/LUT code
So if I understand the P2 architecture correctly, Hub Ram can now be accessed by all Cogs simultaneously.
Also can a Cog access all 512k of Hub Ram or are they limited to a specific memory range like 32k segments?
Also what is the performance hit by accessing code and data in Hub Ram as opposed to Cog Ram?
There are 16 memory banks, where the bank index is determined by the ADDR[3:0]. A cog can read/write hub RAM only when (COGID + CLK[3:0]) = BANKID . This means that every cog is guaranteed mutually-exclusive access to a bank. It also means that each cog accesses the banks in a round-robin style on each clock cycle, implying that a cog can encounter a 0-15 cycle delay before it has access to the referenced bank. Over every 16-cycle period, a cog has access all 512KB of hub ram.
Cog RAM is still faster to access than hub RAM. However, you can still get really good performance with hub ram if you time things right. Typically, this will involve using the streaming mechanism to read or write several contiguous hub bytes at clock speed (i.e. one byte per clock cycle).
So if I understand the P2 architecture correctly, Hub Ram can now be accessed by all Cogs simultaneously.
Close, it is almost simultaneously.
Each COG gets one turn at the RAM, so random access averages 1:16 clock cycles.
However, because the turns are address LSB based, you can BURST Linear data via FIFOs at one every clock.
Streamers and HUBEXC make use of this 'straight line' speed.
Also what is the performance hit by accessing code and data in Hub Ram as opposed to Cog Ram?
COG & LUT code is local, no waiting for anyone.
HUB code & Data is shared, so there can be a waiting time, but you can get more than one transaction, once that time slot opens.
How much speed hit, depends on code execution, which in turn depends on coding style.
jmp-togglepin-jmp-togglepin-jmp-togglepin-jmp-togglepin-jmp-togglepin
would be usually much slower than
togglepin-togglepin-togglepin-togglepin-togglepin
Jitter free, highest speed subroutines & interrupts would usually be placed in COG.LUT.
Other code that is not quite so speed paranoid, can go into HUB. (& maybe even off-chip, with an added delay)
I think this discussion about hub exec got off track. Wasn't the original question about XIP? I don't think every COG can stream instructions from external memory simultaneously. Can the streamer even feed the instruction decoder?
I don't think every COG can stream instructions from external memory simultaneously.
Not from the same memory, no.
Clearly there is a BUS over which the data must flow, and that has bandwidth constraints giving much less speed than internal paths.
However, Off chip memory is large and very cheap, and flexible, and likely some is already there effectively for Free in the Boot memory.
2017 Stocked memory has better bandwidth than older memory.
I don't think every COG can stream instructions from external memory simultaneously. Can the streamer even feed the instruction decoder?
It's just a data copy to/from HubRAM using a Streamer. The handling software would have to arrange for subsequent execution within the Prop2, as in overlays or some such method, ... that's on top of handling the interface control lines. The Streamers can only clock the data.
Trying to feed more than one Cog from a single external memory would be prone to thrashing and bottleneck issues. I wouldn't advise it but obviously, being under software management, it is possible. I'd recommend having one external memory for each Cog needing it.
Each cog could implement an instruction cache in hub RAM. This would limit the collisions with other cogs. They would only need to access external memory when there is a cache miss. In PropGCC on the P1 we use a cache size of 8K. A larger cache on the P2 would be even better. With relative jumps, the P2 code is position independent. So code could be executed directly out of a hub cache even though the code is loaded at a different address than the original location. However, the P2 would need to be able to interrupt if it tried to execute an instruction outside of a cache line. It currently doesn't have that capability. Maybe in the P3.
Comments
Eric Mazur was teaching Physics to medical students at Haravard. Most of them were not interested in Physics and found it boring. A chore they had to go through to be able to go on with their medical studies. His students did pretty well in the examinations. But then after some years he discovered that whist they passed the exams they had not actually learned any principles of Physics. They had learned by wrote and could not apply what they learned.
To fix that Eric abandoned the traditional method of lecturing to a room full of students, them taking notes, possibly memorizing it and passing the exams.
In short, he turned his "lecture" periods into interactive discussions. Not between student and him but student to student. Seems students learn well from each other. Those that "get it" can explain it to others that don't far better than a lecturer can.
That discussion between students moves Physics from being boring maths to the curious and fascinating subject that it is. The ideas of Physics get soaked up, not just the equations.
I suspect anyone involved in education would be interested in some of Eric Mazurs talks on this. See below. Of course his style may not fit courses on CAD for engineers or Robotics for kids but there might be some useful ideas in there. They are fascinating talks anyway:
Confessions of a Converted Lecturer: Eric Mazur:
Eric Mazur: The Tyranny of the Lecture:
In one of his talks Eric shows a video of a bunch of young girls around a table, in India I think, they are laughing and joking and you would think there was a party going on. Oh no, they are learning and explaining statistics to each other!
A key take away I got from Eric is that it can be easier for a student who just got the idea to explain it to another who did not. That student is new to it and knows the difficulty. The lecturer has been known his subject for so long he thinks it's obvious and forgets the million ways a newcomer can start thinking about things wrongly or miss the main point.
Personally I would have hated the collaborative style in school and uni. I was never very social that way. But I used to love listening to lecturers for an hour or so. I would be totally mesmerized by the train of argument in Maths, Physics etc. Mind you, that only worked for a few very good teachers/lectures. Perhaps the Mazur approach would have helped me for the others.
Please feel free to contact me to discuss. You know the number.
That training I just described? Can be up to 2K per day, and every single group calls me back. Good when I can get it.
Now, I will say a couple more things, because I should at this point. I'll share a few day class flow / experience.
You've all read me writing, "people don't need to know much to x", and this is why. The learning trends are clear, and too much state, too many required details per task just choke people. We are used to it, as that is the way we learned. It's not true today, and we aren't going back on all of that.
(which is why I love SPIN, and it's open, "wild" nature and hope we don't break it with too many features. Less is more. Seriously.)
One other advantage I find useful as a free lancer: (I don't work officially for the same people anymore, but they still contract this from me, because they just can't get it anywhere else.)
I can give all the class materials away. They get everything, brief notes, files, all of it. That's not the secret sauce anymore. Truth is, nobody needs me. If they get after it online, they can learn anything they want to. We all know this. I do have some light presentations. They are rules of thumb, voice of experience type things. All else is links to the software or other online documentation. (which is where they should learn to go anyway, might as well get that done right now)
What they need the most is that "voice of experience" and they need "football coach" to get them excited, put the stuff into context and to guide them toward success as they attempt things. Get excited about doing it, because the WHY behind doing it, and the value of doing it is very clear. Very important these days. No why, no value? They just won't do it, and won't care that they didn't do it, nor about you, who tried to make them do it.
They also need someone to recognize them. Nice work! Hey, that was clever, show me again... Every little bit of that will shape a career. No joke. It's worth a lot.
It is super important each atomic thing have a point to it, and it doesn't need to be much, just enough to support the concept. From there, if it's a flexible thing, say one that just drips with needing to be tinkered with? Pure gold, because a lot of them will do exactly that.
One, for assembly modeling, is a parametric box and lid. Change the box, the lid always fits! This is very simple model, but they can go to town on it! The exercise is idealized for success. But, advanced people? I challenge them to provide full detail, draft, fit features, etc... make a real part of it. Everyone has success, everyone gets a challenge, few are left out.
And guess what?
When they run into trouble?
That's the real learning right there, that's the thing they have the most trouble with on their own, online. The "debugging", and I put that into quotes as CAD shares a lot with programming and electronics, it's not quite the same in this sense. However, the concept is exactly the same.
How to recognize trouble, and what to do about it is what they pay for. The rest? It's either discovered in the moment, or learned from context. Monkey see, monkey do. The little details don't matter. What does is the philosophy, how to think, why to think that way, etc...
To that end, I do a controversial thing at times. I have some puzzles. They have multiple solutions. These puzzles build basic competency and teach how to think. I show them all the elements needed to build solutions, ask them to build solutions, and then inform them I will be leaving the room for 10-15 minutes. And then I do.
Get my drink, walk around a little, relax.
When I come back in, some will have solutions, many will have questions. Perfect! Now we are ready to learn. I then model a few possible solutions, then take a few minutes to work through partials for the ones that did not succeed.
Frankly, doing that eliminated a few hours of lecture to emphasize concepts they will get by working for it, and getting a little frustrated, ready to see the answer and value what they see.
It's about sharing that kind of thing to the max extent possible, while being playful and flexible. Failure is OK. Not communicating about it isn't. This is good career advice anyway. Might as well get that learned and set as a norm too. Happens on day one.
I will go to the mat to help you get it, but you gotta be working for it too, or I won't be successful. I make that extremely clear. Then have fun doing it. I get a new challenge nearly every class! People will just do stuff. Crazy stuff I would never have thought of. Fine, I'm better, and so are they.
Finally, there is one secondary advantage: Voice of authority. Often, I get asked about credentials prior to a session. I do not supply them. They can get references, if they want, but that's it. This is my deal, I thought it up, it works, and it's not the norm. There are no credentials to supply.
It's simple, I show up and do my thing. If there isn't success, 100 percent refund. No questions asked. Nobody has ever asked, and they won't ever ask, because I keep a map of the students in my head. I know damn well if they are gonna make it or not, and if someone isn't going to make it, I get that all communicated for followups, or a mentor, or something for them. They need to make it. Got families, etc... riding on all this, and I take it seriously.
For students, younger people, a lot of that can be left out. But for adults? It matters, and once they know you get it, they will value the time and likely succeed.
Each one is making progress. I know them, see where the gaps are, and often will include material targeting these gaps, and I'll often make that up during the lunch break, or free time period too. This is the advantage of the interactive technique. It's not hard to come up with stuff once one gets used to doing it.
The key to this is to own seeing their understanding. It need not be complete. But they do need basic competence and the right mindset. With those two things, they are off and running, able to grow. Things like they can find A solution vs finding THE or an optimal solution. Finding A solution is the start. Experience is the rest.
Think of it like being able to read. Once you have that, the door is open right? Same thing with how to solder, how to surface mount, how to write code. Once they get those, they can proceed to fail a lot, fail hard, and get where they want to be.
If I were you, and it's possible, at least one session on "scope as debugger, assistant, general tool" would be a pure gold session. Over the years, I've grown so damn much from the bits I got here. I use my scope, and it's an older 4 channel analog Tek, but it's fast. And I use it as my eyes, and that is sweet. I don't see that shown much. IMHO, it should be.
Anyway, take the discipline and break it into the necessary pieces. For CAD, as example, this is:
Geometry concepts, planes, coordinate systems
Bodies, sheets (surfaces), sheet bodies, curves, points, "what is an entity?"
Modeling, cut, join, intersect, history, non-history (direct)
Features, extrude, revolve, free form, loft, sweep
Parametrics, equations, units, conditionals (not often taught, but I do)
Assemblies
Constraints (how they can be used, three different philosophies)
And those are (no constraints, partial constraints, full constraints) Trade-offs, match strategy to problem.
Each of those gets broken down into some little exercises, delivered interactive, in a way people can follow along, create, do, test, explore.
After about three days, my students can generally model, assemble, make drawings, output derivative files. They can also match features to design requirements, parameterize when it makes sense, direct model when it makes sense, and troubleshoot a design.
The most important thing I make sure they can do is to draw without knowing much of anything. They either visualize the shape in their heads, or are drawing one they can see a picture of, or a real object. From that, visualize all the relationships, tangents, things that are centered, design intent. Boil that down, and most models require remarkably few givens, the rest is best practice or geometry actually holds the answer for them. Time spent reducing the problem, factoring out noise, identifying real, important givens, is time very well spent.
This is analogous to "coding on paper", something I learned here from you guys. It's worth it's weight in gold, IMHO.
Result: The only numbers I have go through their heads are the ones that need to come from their head. Every other thing is derived to the maximum extent possible. This makes for solid design work and a focus on what really matters, leaving all else to standards, best practice, or "doesn't matter, go minimum or maximum material condition, call it good."
This is analogous to focusing in on the core problem, working through that, then building out the other stuff surrounding the problem. Limit what you have to know, and that maximizes your ability to sort through choices and find solutions.
In CAD, number of unknowns are generally degrees of freedom. I have found ordinary people can process a handful of these no problem, but it's exponential. 20 is ugly. 50? You need skill. Hundreds? No hope, it's a mess. Refactor.
The test is free drawing time. Near the end, I ask they make something they can see in the room, assembly if they want to.
When that happens, they are on their way. When it doesn't, I got work to do with that one, and do that work.
That's kind of how I run it. An 8 hour day is roughly 6 hours of instruction, one hour free form, catch up time, the rest human breaks and chatter.
Overtime is for problem cases, or some edge case they get fixated on. I'll do those, add to library, and extend the class a little to weave it in. Usually, those are triggered by their particular job requirements and design scenario framework.
I don't have an analogy here for younger students. Maybe there isn't one.
I got there school of hard knocks style. These days I do classes for groups on demand. Sometimes there is a lot, other times I'll go a considerable time.
10 years ago, I was knocking out two a month. Built up those techniques based on a sort of "do what it takes" approach. I would talk with the students often, and in those conversations they would basically tell me what was going to work.
The most important thing was to listen and actually act on it. Was tough to buck the trend too. Took heat for it, but I've got a long record of happy, successful groups. Many of my peers, who do not embrace this stuff, see me follow up later.
Go Chip! Seems like you got the basics in this chatter. Run with it. Have fun. Smile, and share the fun, share that which drives you. They will draw energy from it, and share it, and that is infectious.
When you do it right, nobody wants the class to end.
By the way, my demographics today are:
I'm the old guy. Getting old sucks. I say that. Regularly. I also share my excitement for the ride they are about to embark on. Ride it for all it's worth! I did. I will share how I got to be in front of them and some of what that meant to me. It's an ice breaker, get to know sort of thing. I invite them to share their stories, expectations. I take notes during this time.
They share, at that nice, fun time, exactly what the goal of the class needs to be, and I meet that goal, regardless of any other agreement. Secret sauce here guys. Enjoy.
For a long time, students trended older, 40's and up. These days, they trend younger, 20's and up.
When I started, I was the kid. 20 something dishing it out to seasoned engineers 40 and up. Tough crowd. Definitely school of hard knocks for me. It's easier now for me. One case where some age helps.
Heater, that is the magic. When the class is social, they are comfortable, having fun, it competes with Facebook. And it wins. Almost every time.
One of the best ways is to celebrate failure. When I get caught on something?
Always the same:
"Nice work! You got me, now let's figure this dang thing out!" The whole class will jump in, and we do usually figure it out. I tell them that goes in to the next one. Thanks. I'll also frequently quip, "you see? This stuff is never dull." And that's an attempt to make exceptions and troubleshooting cool, fun and infectious.
Or,
"Nice catch!" I'm slipping. Let me back up a bit here and do this right for you guys, because this will happen to you...
Humility and humor are both powerful in this context. Laughing replaces angst and frustration. And that tends to lubricate the thinking machinery. Good stuff happens.
Bring more than you need. At first, you won't be able to do this. No library. So, you queue things and make the necessary goods at night in the hotel room. Sucks, but every time you do, it multiplies. Won't be long before you are looking for one to do as your body of material crosses the majority bell curve cases.
Then you can always make standard ones better.
Then, as the class progresses, use your judgement. Drop the material needed, when needed. Adjust dynamically. Don't share all that you brought. Set expectations reasonably low. Then you can raise them. The group dynamics help you understand when this makes sense.
Lowering expectations sucks. So don't do it.
Watch the students. They tell you what is needed by their actions, questions, inactions.
Less can be more. Basic competency trumps a broader set of skills presented, but lacking initial mastery or applicability by the students.
First, this was great. He applied the scientific method here. Worked from the data and came to some very interesting conclusions, then validated them.
This mirrors my experience, sans a formal data collection. I happen to have an extremely good memory of people and conversations I've had. Can play them back in my mind even years later. Over time, I got similar data in a more coarse way.
I find the data regarding conceptual understanding vs what I'll call rule based, or computational understanding profound, and it mirrors my experiences perfectly. In my own internal frame of reference on these things, this is "how to think" and "philosophy" as in more or less why one would think that way, advantages, dynamics, nature as authority mandates it, etc... I realize that's coarse, but it's for me, so who cares?
For me personally? If I can't visualize it somehow, make a mental model, I really don't understand it, and it all really is monkey see, monkey do, as he says there with the Kirchoffs law example. That sucks. If I can visualize it, I own it conceptually and can often arrive at an intuitive answer quickly, which can be validated, or quantified by computation later on.
That's a big deal. His methodology is sublime. Love it.
Put into this context, when I came here many years ago, returning to this hobby, and my own hopes of returning semi-professionally, I had a lot of intuitive understanding, conceptual. What attracted me to Chip, Parallax, and this general community was how so many things get boiled down to first principles and then explained or extrapolated to a problem and or solution. The thinking here is remarkable in that way.
With the Propeller specifically, I found myself able to jump in with SPIN + PASM, and do things intuitively. The lean, not rigid nature of both, got me to solutions quickly. There was not too much to work with, and that made finding solutions easier, and what there was to work with was flexible, so I could improve on them, or collaborate with others to improve them, and it's all sort of fluid in a way I had not experienced much before.
Since that time, I've grown in both areas, though I'm consistently weak on computation, just because I don't do this stuff every day. Conceptually? I've learned a ton, and I love how we've got this library of great stuff one can grab, tinker with, understand in the moment, then bend to solve a problem, or just learn the dynamics of things fairly easily and without gross "let the smoke out" failure.
Applying these techniques, deriving from the thought here, should work very well with students, given this method.
For young people, and for electronics, some of what I put here isn't as applicable as it needs to be. And that's just my own experiences, tuning for my problem space in action. No worries.
This video does however get right to the dynamics of it all, and does so clearly and convincingly.
Gold. Nice reference, and thank you for putting it here.
There are some aspects of what I do that remain problematic. I see now that I've had the solution, which is to get the conceptual work done solid, but haven't always seen it that way. Can't wait to give that a go on a few difficult problem sets.
He doesn't go into "play", or I haven't seen it yet, but I suspect that's simply due to his level of education and student body.
For assembly problems, I'll literally provide the students with kids toys. Tinker Toys and legos. I'll have some real ones handy, for people who need to learn to simulate in their minds, but the real draw is the virtual ones. I make a nice set, and teach the mechanics interactively, then cut right to free time, no problem sets presented.
Goal: Take an hour and build cool stuff.
Some people take the real ones, model something, then model in the computer, then compare. Very good. They get robust, basic understanding. That's the minimum, and it's a win.
But, most often, they will go off into all sorts of places! Those questions, "how do I?" are amazing, and I still get new ones every single time. The number of possible paths on something like that appears near infinite, though the dynamics and software functions seem fairly finite. They still think up stuff that I've not seen, or will have to work through.
During the free form, "just build something" time, a ton of peer discussion happens, with the students often forming little groups to do something they think is cool. Or, it's one of those, "bet it can't do this" type scenarios. (that comes up with the Tinker Toys often as those present a much broader set of possibilities and complexities than the legos do.)
Lesson there: Even simple things can lead to significant complexity and or subtlety.
Anyway, thought I would share a few thoughts. Great reference for me personally. And I really appreciate this guy doing the science. Nice work.
I strongly recommend anyone doing education watch this material. He's on point, and has grasped the social dynamics and is able to present them in a compelling way.
Honestly, he should have applied those techniques to the group he is lecturing to. I'll bet the majority of "students" in that lecture hall, who are peers I assume, will leave with the ideas, but will lack the intuitive understanding they will need to have for success in the method. However, they will also get them via the school of hard knocks, so no real harm done.
Otherwise, great session. Worth the watch.
Then I though it's just as well he did not. Would have made a mess of the presentation for YouTube. Can't do the interactive thing whist watching that. Just tell me the story from beginning to end.
Or can we.... You are watching the video and taking a break from it to discuss here. We are a microcosm of the class dynamics he's talking about!
Exactly.
I will have an opportunity to test this idea in the near future.
I love this:
"Kids love to learn from other kids. First of all, it's often easier. The child teacher is closer than the adult to the students' difficulties, having gone through them somewhat more recently. The explanations are usually simpler, better. There's less pressure, less judgment. And there's a huge incentive to learn fast and well, to catch up with the mentor."
Basically what I tried to say above but better put. Replace "child" with "student", of any age, and I'm sure it is all still true.
Also this:
"Kids also love to teach. It gives them a sense of value, of accomplishment. More important, it helps them get a better handle on the material as they teach; they have to sort it out, get it straight. So they struggle with the material until it's crystal clear in their own heads, until it's clear enough for their pupils to understand."
Never mind "kids love to teach". So many times I have heard even aged university professors say they love to teach. Because when they have to think about the thing hard enough to explain it to someone else then they understand it better themselves. Or even start to see new things that can be done with it.
How did all this get forgotten in school, college and university?
And yes, you are right, to understand something better it helps to explain it to somebody else, even if he/she has no clue about it. But thru the process of explaining you clarify it for yourself.
Enjoy!
Mike
I'd have loved to have P2H to play with for a few years! I thought it should have been released, and people who needed low power could have lowered the frequency and perhaps had unused cogs wait.
BUT
the current P2 looks good too, hub exec, no penalty running code from LUT, smart pins, XBYTE, interrupts etc are something to look forward to.
Perhaps for the P3, take P2H and add current P2 design features to it? Keep it once cycle, add the new features, shrink to 45nm or so, multi-threading and accept the higher power envelope for the performance gain.
ie if you meet opcode timing, the Counters/Timers end up running much slower than they could have.
Of course, another 'way around' that is to claim the Core is one cycle, and the peripherals are clock multiplied.
I'm seeing more MCUs do exactly this: where the peripheral clocks are increased relative to Core clock.
This gives full silicon performance on the peripherals, but the core runs slower.
In the case of P2, you could then claim WAIT opcodes give 'fractional cycle precision', & I guess users are used to that.
Once you have a PLL, there are often multiple clocks in a device, and IIRC the NXP parts start at 2x SysCLK on the VCO, in order to have 50% duty cycle clocks.
To avoid confusing users, that 2x value is not formally mentioned.
Existing P2 DOCs could easily do the same, reference everything to OpcCycles, and call the timers Clock doubled.
As for peripherals, with 100-200 MHz CPUs there is not much reason to run i2c, serial, CAN, most SPI or many other serial peripherals at that rate. They will all clock at much lower rates though often take the high rate clock to generate baud rates.
And all 16 Cogs can, in parallel (Because of the "egg beater" crosspoint switch), do that unimpeded. That's why, on a number of occasions, I've highlighted the huge performance gap between the internal RAMs and what could be achieved with any external solutions.
SETQ+RDLONG burst instruction could theoretically use 100%. Streamers could too.
Such performance steps/knees are common across all processors, a general rule is the further away memory is, the slower it is to access.
Also, as you allocate fewer pins to such memory, the slower it gets as well.
Memory does not stand still, so today we see Latched/Mux'd RAM, and QuadSPI added bandwidth to good ol' SPI, and now DTR/DDR doubles that again, and HyperRAM uses octal bus.
Also can a Cog access all 512k of Hub Ram or are they limited to a specific memory range like 32k segments?
Also what is the performance hit by accessing code and data in Hub Ram as opposed to Cog Ram?
Data access to hub is along side the FIFO, so it operates/performs the same as COG code accessing hub memory. It'll be slower than direct COG/LUT data access in most cases.
All cogs can access all hub memory. Hubexec can't execute in the first 4k (I think) of hub memory since the addresses overlap COG/LUT, so branches to those addresses execute the COG/LUT code
There are 16 memory banks, where the bank index is determined by the ADDR[3:0]. A cog can read/write hub RAM only when (COGID + CLK[3:0]) = BANKID . This means that every cog is guaranteed mutually-exclusive access to a bank. It also means that each cog accesses the banks in a round-robin style on each clock cycle, implying that a cog can encounter a 0-15 cycle delay before it has access to the referenced bank. Over every 16-cycle period, a cog has access all 512KB of hub ram.
Cog RAM is still faster to access than hub RAM. However, you can still get really good performance with hub ram if you time things right. Typically, this will involve using the streaming mechanism to read or write several contiguous hub bytes at clock speed (i.e. one byte per clock cycle).
Close, it is almost simultaneously.
Each COG gets one turn at the RAM, so random access averages 1:16 clock cycles.
However, because the turns are address LSB based, you can BURST Linear data via FIFOs at one every clock.
Streamers and HUBEXC make use of this 'straight line' speed.
yes.
COG & LUT code is local, no waiting for anyone.
HUB code & Data is shared, so there can be a waiting time, but you can get more than one transaction, once that time slot opens.
How much speed hit, depends on code execution, which in turn depends on coding style.
jmp-togglepin-jmp-togglepin-jmp-togglepin-jmp-togglepin-jmp-togglepin
would be usually much slower than
togglepin-togglepin-togglepin-togglepin-togglepin
Jitter free, highest speed subroutines & interrupts would usually be placed in COG.LUT.
Other code that is not quite so speed paranoid, can go into HUB. (& maybe even off-chip, with an added delay)
Not from the same memory, no.
Clearly there is a BUS over which the data must flow, and that has bandwidth constraints giving much less speed than internal paths.
However, Off chip memory is large and very cheap, and flexible, and likely some is already there effectively for Free in the Boot memory.
2017 Stocked memory has better bandwidth than older memory.
Good question.
Details like this come under the better hardware support for off-chip memory umbrella.
Trying to feed more than one Cog from a single external memory would be prone to thrashing and bottleneck issues. I wouldn't advise it but obviously, being under software management, it is possible. I'd recommend having one external memory for each Cog needing it.