Yes some means will be provided for·SMT adverse people. As for features, we're keeping that stuff under wraps (for now at least), suffice to say if we are able to do everything we want to do,·most people will be very plesantly suprised if not blown away.
I think the 80286 was available in a 64 pin DIP package... I do know I saw a huge dip chip on a 286 motherboard once.
Remember that is 64 I/O pins. Now add Xtal (2), 1.8v (maybe 4), 3.3v (again maybe 4) and Ground (4?) /BOE and /RST; this totals enough to maybe use a 84 pin SMD package. Myself I'd like to see this available in a J-leaded 84-pin package as there are 84-pin J-lead with pins on 0.1" spacing (forgot what the package designation is) to through hold adapter sockets. This makes it easy for the hobbyist.
But in any case, this Gen#2 Propeller is going to be a fantastic beast. IMHO.
Just discovered the Propeller yesterday. Amazing design. A few thoughts:
Number of cogs: 16 cogs definitely seems to be more in line with the overall design
philosophy, particularly if unused cogs can be kept from wasting resources (hub
bandwidth, power, etc.).
Hub bandwidth: I think an (optionally) configurable bandwidth scheme would be
desirable if designing it doesn't get too messy. If it doesn't work in practice, people
can just not use it. Regarding resource allocation, I'd consider this a compile-time
problem that can be properly investigated once the silicon is available.
Hub bandwidth again: I know some will find this idea blasphemous, but how about
a "best-effort" access for otherwise unused cycles ? E.g., if more than one cog is
configured to access a given slot, the lowest-numbered cog that has a pending
operation would get the slot. Or, use one more bit for hub operations, to indicate
if the cog is willing to get any unused slot (with some sort of arbitration). Quite
often, there are applications with "soft real-time" requirements that are fine with
a bit of jitter.
IP protection et al.: would a PROM (OTP) for the boot loader be feasible ? If yes,
people could simply program their "trusted" loader, and use that instead of the
ROM default. If the "use PROM" fuse is not programmed, the present ROM would
be used. Also, once the "use PROM" fuse is programmed, no further writes to the
PROM should be allowed. For R&D, there should also be some protection against
accidentally programming the PROM, or at least an override to fall back to the ROM
(tricky).
Cog memory: how about an optional Harvard mode ? This would allow the memory
to be doubled, without requiring major changes to the instruction set. The JMPRET
family of instructions and MOVD/I/S would affect code space, while the rest would
only affect data space. MOVD/I/S could use WC to switch to data space. We'd also
need a MOV to program space. Harvard mode could be activated by a COGINIT
variant. Not having programmed the chip yet, I don't know how well this would fit
current programming style.
Voltage regulator: the BOM for just getting a Propeller to work does seem to be a
bit large. So an on-chip 1.8V regulator would be nice to have. I wonder if it would be
possible to have one that can supply the chip under low-performance conditions
(enforced either by limiting clock speed of the LDO is active or through some cycle
budget counter that causes some sort of exception if exceeded). That way,
applications that don't need all the processing power all the time could choose
this more compact option, similar to being able to use the fast RC if no crystal is
needed.
BOM reduction again: analog capabilities need resistors and capacitors. I wonder
if it would be feasible to have on-chip variants that would be of any practical use,
e.g., configurable pull up/down resistors and capacitors attached to all pins, with a
switchable bottom plate.
Packaging: the QFN package seems to be the "vertical sidewall" type. There are
also QFN packages with a "ramp". The latter tend to be much easier to solder
manually, particularly if there is no requirements to solder the center pad.
(Not a big deal with a toaster oven, but some may not like to use that.)
Packaging again: I wonder why people don't like SMT in this case. Is it for the
perceived difficulty of working with SMT components (0.8mm and 0.65mm QFP is
quite simple to do manually, 0.5mm probably as well) or is it because it's hard to
recycle chips from prototypes ?
So switchable (as in "configurable", not to be confused with switched capacitors.) R/C would have to
include a series resistor as well.
Regarding 1.8V vs. 3.3V, I wonder if it would be really all that hard to allow for variable I/O voltage.
This seems to be pretty much the state of the art for a lot of chips, and they don't seem to have
unreasonable leakage issues because of this.
If the package has lots of pins/pads, perhaps even a separate rail for the A and B ports might be
worth thinking about. This would also allow to properly bias the clamp diodes in a 1.8V design using
LEDs, without having to worry about sneak current paths.
A PROM (for a boot loader) is very wasteful of chip area. I think Chip was thinking of a few bits when he mentioned fusible links, not a memory area.
I don't think the chip process being used is suitable for mixed analog/digital. In any event, the chip area required for a regulator is large and the heat load is potentially large compared to other areas of the chip.
On-chip resistors are notoriously inaccurate unless individually laser trimmed. Resistance ratios are well matched. On-chip capacitors are limited in values and also inaccurate. They also consume lots of chip area.
I don't think a Harvard mode would get you that much. There's already some work that's been done on a "Large Memory Model" using a sort of interpreter with low overhead where instructions from hub memory are moved into a small portion of cog memory for execution and jump instructions are handled specially. Most of the cog memory is available for data storage.
The motivation for a PROM would be that customers could choose the boot/protection mechanism
they need, e.g., with a reference implementation from Parallax. This would allow for different
design goals (e.g., some may not need any protection, but would want to have the chip start
doing something as soon as possible, while still loading the bulk of the data) and would also
allow to defer the final design of the protection mechanism.
On-chip resistor accuracy: since they mainly determine the frequency of low-pass filters, perhaps
choosing conservative values would be good enough. More demanding designs could always use
more precise external components. Laser trimming would be prohibitively expensive, I agree.
A Harvard mode would, in the best case, roughly double the usable space (*), probably allowing
more data to be kept in cog memory. LMM looks like an interesting idea, but it also comes with
a significant performance penalty. Besides, it would also benefit from having more cog space.
(*) The special registers only need to exist in data space, so the best-case space increase would
even be 103%.
By the way, if hub latency (in terms of cog cycles) increases in the new design, perhaps a block
RDLONG could be useful for LMM-like things. It could latch N longs from the shared RAM (which
would have to have a wider organization in this case) and then transfer them at cog speed to
cog memory. Even with the current ratio, this would accelerate unrolled interpreter loops.
I'm not sure the performance penalty will be all that high. The programmer will have choices in that LPASM (Large prop assembly) code would not have to be used for everything, unlike kicking the machine into some other mode. High compute tasks can exist in a cog where they really need peak speed. Having the deterministic timing and symmetry among COGs means being able to implement sub-tasks in a way that looks essentially like hardware to the main program, which could be SPIN or LPASM. This gets rid of a lot of overhead, normally associated with non-multiprocessor systems. This is the big differentiator. It takes some work to get something running on a COG, but once done, it just runs, out of sight and out of mind, leaving the developer to focus at another level.
Building a solution this way ends up dividing the problem into nice discrete tasks, with a fairly high potential for reuse where sub-tasks are concerned.
Having more than one Propeller mode would divide the code base, and impact the evolution of really solid multi-processor code. IMHO, growing that solution set, in terms of library code and techniques, is really where the gains are. Having a larger body of those things will make using the Propeller easier as time goes on. It's already showing now. People are building nice objects, that depend on the symmetry and deterministic timing, to interact fairly easily. Breaking that would be a net loss, IMHO.
Running in harvard mode would also impose a penalty in that there still would be no interrupts. So that means checking on things, which costs a lot. That's why we have interrupts in the first place. Going this route really changes the propeller into something that's not a propeller, IMHO.
The deterministic nature of the chip is where the power is. If things like burst modes & such were to be implemented, the symmetry would go away and likely introduce problems that are not there right now. IMHO, that would increase the complexity of the design considerably, to insure all cases are correctly handled. It would also then make exact timings of things more difficult. There are counters and such, so maybe that would not be the end of the world, but I think the gain would not be all that significant for a fairly large number of target applications, given the overall complexity increase.
Hub latency will increase, but so will overall clock speed. This is likely to end up being a net gain as well.
BTW: using more than one COG to access HUB memory will make more sense, given a higher overall number of COGs. We've seen a few being used for more complex tasks, making the 8 seem a bit cramped. Going to 16, plus the overall speed increase, will significantly increase the scope of well indicated tasks possible on the Propeller. Having more COGs will mean being able to really use the HUB, with plenty of power remaining for the main program. That's where the net gain in overall clock speed will largely negate increased HUB latency, IMHO.
Werner, It's good to see your·interest in our chip. Potatohead hit the nail on the head, determinisim is a key consideration with the Propeller. Many of your suggestions would make the Propeller indeterminate, which is a road we aren't going to travel. That said there are advancements in the works, that if they pan out will maintain the Propeller's absolute deterministic nature while overcoming some of the limitations of the current architecture.
Harvard architecture wouldn't work, the instruction set is vonNeuman, which means we would have to redesign the entire thing and loose all compatibilty with the current chip.
Internal regulators would heat the die and lead to performance degradation.
The QFN package is for commercial production which has no issues with vertical side wall (theres also the bottom plate that needs to be grounded which requires a hot air pencil if done by hand). The QFP package is the one intended for use in hand population surface mount.
I will add my few table spoons of water to this sea:
Better debugging designed from the ground up. It would use at the very least reuse the two serial pins used for the Prop programming and allow common microcontroller debugging features in the Parallax made IDE. It would be necessary for the mechanism to access the private ram spaces of all the cogs.
A few fuses for a security key that can be read only by the Prop itself. I talked about that in the past in the IP protection thread.
TransistorToaster said...
I will add my few table spoons of water to this sea:
Better debugging designed from the ground up. It would use at the very least reuse the two serial pins used for the Prop programming and allow common microcontroller debugging features in the Parallax made IDE. It would be necessary for the mechanism to access the private ram spaces of all the cogs.
A few fuses for a security key that can be read only by the Prop itself. I talked about that in the past in the IP protection thread.
Frank
From someone who has been around since 8-bitters (and do some Hw hacking and reverse engineerig during years).. A few prpgrammed fuses would not do a **** on security.. As long as Propeller code is loaded from outside chip it can be recorded and altered. I know there is one potentially-secure (that is, I don't *know* any hacks) way of doing this, as it's been implemented on high end Xilinx FPGA chips (encrypted code, key only on battery backed FPGA-sram, but I don't consider it 100% .. (see www.xilinx.com/publications/xcellonline/xcell_47/xc_pdf/xc_secure47.pdf
and direct.xilinx.com/bvdocs/whitepapers/wp261.pdf for reference)
See game consoles as a reference.. If Sony, Microsoft or Nintendo can't make things Unhackable with their Megacoporation budgets, then... Ok, I do admit that Chip is a guaranteed genius, but what you people are askin is awfull lot...
I know this will disappoint you guys (and gals), but we wont be providing any more sneak peaks into what we have planned for the next chip. Suffice to say nearly everyone will pleased with the results.
Paul Baker (Parallax) said...
Suffice to say nearly everyone will pleased with the results.
Cool. I can hardly wait. Considering where I'm up to with my current Propeller based design!
Problem is that I probably wont need to do a design based on the new Propeller for a couple of years. · I might have to think up a new product once the new chip comes out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
The Harvard mode I suggested wouldn't be very different from the current Von Neumann mode, even
though the Propeller makes quite heavy use of self-modifying code. In fact, the (extended) instruction
set would be the same. The main difference would be in where variables are allocated. If this is left to
the assembler, the source would be identical for both modes.
I don't quite understand the remark about interrupts. There are none now, and there wouldn't have to
be any in Harvard mode, so nothing changes.
But it seems that the general consensus is that the present cog memory is already plenty, in which
case I'd indeed be trying to solve a non-problem
QFN: I agree that it would make little sense to change packages for existing products. However, if an
easier to handle QFN package could be used for future chips, everybody would win, no ? QFP is quite
large, 209% the footprint of QFN. Also hobbyists want to build small stuff
Security fuses: if there are only fuses for some sort of key, the protection mechanism must be
implemented by a trusted entity in the chip, e.g., code in ROM, and would thus be hard to
change/adapt.
No more sneak previews: damn But thanks for the insights so far !
It would be nice to have more cog memory but the instruction set doesn't support more than 9 bits for register addressing (as Im sure you are aware), switching to a harvard architecture is too much like banks which is something we're very hesitant to do. Also harvard would disallow self-modifying, to perform indirect addressing would require implementing another mode, and again there are no free bits to indicate such a mode and in a 32-bit architecture an extension set doesn't make sense (to further complicate things all opcodes are reserved so there isn't even a opcode to use as an extension indicator). Another thing to also consider, the majority of real-estate of each cog is used on the RAM, with a 16 cog version this would be a 4 fold increase in real-estate size. This would necessarily exclude many of the other goodies we are contimplating because there simply wouldn't be enough room.
The next chip will likely not have a QFN option, with 64-I/O we would likely choose a BGA package for the commercial applications, but this hasn't been determined yet.
Paul, if the self-modifying code needs arithmetic or bitops on the target instruction, then there's indeed no way.
If MOV* and RDLONG are sufficient, however, we could use the C bit as a switch in ZCRI for all but MOV, and there
one could use the R bit (the effect of MOV .... NR could be obtained with ABS ... NR). There's also JMPRET, which
could be used to store the return address in data space. There, also C of ZCRI is available.
Ibsen said...
How much more expensive will the new Propeller be ?
We will not know until the design is nearly complete and we know the die size and package type. We can confidently say,·for the size of the silicon it will be inexpensive.
Werner said...
But perhaps this is getting too messy ...
Yeah, one of the things we were trying to minimize with the chip is all the contorted methods of accomplishing something that many microcontrollers resort to.
The next chip will likely not have a QFN option, with 64-I/O we would likely choose a BGA package for the commercial applications, but this hasn't been determined yet.
Does that mean you'll still have the LQFP option?
LQFP is quite easy to solder by hand.
QFN is more difficult - I use a hot air blower with·success on·accelerometers that come in only a QFN package. It's still difficult, and sometimes the chips get really hot. I sometimes have to do them a second or even third time (about 30% rework required). At least they're only 16 pins.
BGA is impossible by hand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
Comments
What about new features ?
How about a Video/Keyboard/Mouse/Serial driver in ROM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 5/24/2007 8:54:43 PM GMT
Remember that is 64 I/O pins. Now add Xtal (2), 1.8v (maybe 4), 3.3v (again maybe 4) and Ground (4?) /BOE and /RST; this totals enough to maybe use a 84 pin SMD package. Myself I'd like to see this available in a J-leaded 84-pin package as there are 84-pin J-lead with pins on 0.1" spacing (forgot what the package designation is) to through hold adapter sockets. This makes it easy for the hobbyist.
But in any case, this Gen#2 Propeller is going to be a fantastic beast. IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Number of cogs: 16 cogs definitely seems to be more in line with the overall design
philosophy, particularly if unused cogs can be kept from wasting resources (hub
bandwidth, power, etc.).
Hub bandwidth: I think an (optionally) configurable bandwidth scheme would be
desirable if designing it doesn't get too messy. If it doesn't work in practice, people
can just not use it. Regarding resource allocation, I'd consider this a compile-time
problem that can be properly investigated once the silicon is available.
Hub bandwidth again: I know some will find this idea blasphemous, but how about
a "best-effort" access for otherwise unused cycles ? E.g., if more than one cog is
configured to access a given slot, the lowest-numbered cog that has a pending
operation would get the slot. Or, use one more bit for hub operations, to indicate
if the cog is willing to get any unused slot (with some sort of arbitration). Quite
often, there are applications with "soft real-time" requirements that are fine with
a bit of jitter.
IP protection et al.: would a PROM (OTP) for the boot loader be feasible ? If yes,
people could simply program their "trusted" loader, and use that instead of the
ROM default. If the "use PROM" fuse is not programmed, the present ROM would
be used. Also, once the "use PROM" fuse is programmed, no further writes to the
PROM should be allowed. For R&D, there should also be some protection against
accidentally programming the PROM, or at least an override to fall back to the ROM
(tricky).
Cog memory: how about an optional Harvard mode ? This would allow the memory
to be doubled, without requiring major changes to the instruction set. The JMPRET
family of instructions and MOVD/I/S would affect code space, while the rest would
only affect data space. MOVD/I/S could use WC to switch to data space. We'd also
need a MOV to program space. Harvard mode could be activated by a COGINIT
variant. Not having programmed the chip yet, I don't know how well this would fit
current programming style.
Voltage regulator: the BOM for just getting a Propeller to work does seem to be a
bit large. So an on-chip 1.8V regulator would be nice to have. I wonder if it would be
possible to have one that can supply the chip under low-performance conditions
(enforced either by limiting clock speed of the LDO is active or through some cycle
budget counter that causes some sort of exception if exceeded). That way,
applications that don't need all the processing power all the time could choose
this more compact option, similar to being able to use the fast RC if no crystal is
needed.
BOM reduction again: analog capabilities need resistors and capacitors. I wonder
if it would be feasible to have on-chip variants that would be of any practical use,
e.g., configurable pull up/down resistors and capacitors attached to all pins, with a
switchable bottom plate.
Packaging: the QFN package seems to be the "vertical sidewall" type. There are
also QFN packages with a "ramp". The latter tend to be much easier to solder
manually, particularly if there is no requirements to solder the center pad.
(Not a big deal with a toaster oven, but some may not like to use that.)
Packaging again: I wonder why people don't like SMT in this case. Is it for the
perceived difficulty of working with SMT components (0.8mm and 0.65mm QFP is
quite simple to do manually, 0.5mm probably as well) or is it because it's hard to
recycle chips from prototypes ?
- Werner
So switchable (as in "configurable", not to be confused with switched capacitors.) R/C would have to
include a series resistor as well.
Regarding 1.8V vs. 3.3V, I wonder if it would be really all that hard to allow for variable I/O voltage.
This seems to be pretty much the state of the art for a lot of chips, and they don't seem to have
unreasonable leakage issues because of this.
If the package has lots of pins/pads, perhaps even a separate rail for the A and B ports might be
worth thinking about. This would also allow to properly bias the clamp diodes in a 1.8V design using
LEDs, without having to worry about sneak current paths.
- Werner
A PROM (for a boot loader) is very wasteful of chip area. I think Chip was thinking of a few bits when he mentioned fusible links, not a memory area.
I don't think the chip process being used is suitable for mixed analog/digital. In any event, the chip area required for a regulator is large and the heat load is potentially large compared to other areas of the chip.
On-chip resistors are notoriously inaccurate unless individually laser trimmed. Resistance ratios are well matched. On-chip capacitors are limited in values and also inaccurate. They also consume lots of chip area.
I don't think a Harvard mode would get you that much. There's already some work that's been done on a "Large Memory Model" using a sort of interpreter with low overhead where instructions from hub memory are moved into a small portion of cog memory for execution and jump instructions are handled specially. Most of the cog memory is available for data storage.
they need, e.g., with a reference implementation from Parallax. This would allow for different
design goals (e.g., some may not need any protection, but would want to have the chip start
doing something as soon as possible, while still loading the bulk of the data) and would also
allow to defer the final design of the protection mechanism.
On-chip resistor accuracy: since they mainly determine the frequency of low-pass filters, perhaps
choosing conservative values would be good enough. More demanding designs could always use
more precise external components. Laser trimming would be prohibitively expensive, I agree.
A Harvard mode would, in the best case, roughly double the usable space (*), probably allowing
more data to be kept in cog memory. LMM looks like an interesting idea, but it also comes with
a significant performance penalty. Besides, it would also benefit from having more cog space.
(*) The special registers only need to exist in data space, so the best-case space increase would
even be 103%.
By the way, if hub latency (in terms of cog cycles) increases in the new design, perhaps a block
RDLONG could be useful for LMM-like things. It could latch N longs from the shared RAM (which
would have to have a wider organization in this case) and then transfer them at cog speed to
cog memory. Even with the current ratio, this would accelerate unrolled interpreter loops.
- Werner
Building a solution this way ends up dividing the problem into nice discrete tasks, with a fairly high potential for reuse where sub-tasks are concerned.
Having more than one Propeller mode would divide the code base, and impact the evolution of really solid multi-processor code. IMHO, growing that solution set, in terms of library code and techniques, is really where the gains are. Having a larger body of those things will make using the Propeller easier as time goes on. It's already showing now. People are building nice objects, that depend on the symmetry and deterministic timing, to interact fairly easily. Breaking that would be a net loss, IMHO.
Running in harvard mode would also impose a penalty in that there still would be no interrupts. So that means checking on things, which costs a lot. That's why we have interrupts in the first place. Going this route really changes the propeller into something that's not a propeller, IMHO.
The deterministic nature of the chip is where the power is. If things like burst modes & such were to be implemented, the symmetry would go away and likely introduce problems that are not there right now. IMHO, that would increase the complexity of the design considerably, to insure all cases are correctly handled. It would also then make exact timings of things more difficult. There are counters and such, so maybe that would not be the end of the world, but I think the gain would not be all that significant for a fairly large number of target applications, given the overall complexity increase.
Hub latency will increase, but so will overall clock speed. This is likely to end up being a net gain as well.
BTW: using more than one COG to access HUB memory will make more sense, given a higher overall number of COGs. We've seen a few being used for more complex tasks, making the 8 seem a bit cramped. Going to 16, plus the overall speed increase, will significantly increase the scope of well indicated tasks possible on the Propeller. Having more COGs will mean being able to really use the HUB, with plenty of power remaining for the main program. That's where the net gain in overall clock speed will largely negate increased HUB latency, IMHO.
I do agree a quicker start would be nice.
Harvard architecture wouldn't work, the instruction set is vonNeuman, which means we would have to redesign the entire thing and loose all compatibilty with the current chip.
Internal regulators would heat the die and lead to performance degradation.
The QFN package is for commercial production which has no issues with vertical side wall (theres also the bottom plate that needs to be grounded which requires a hot air pencil if done by hand). The QFP package is the one intended for use in hand population surface mount.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 6/19/2007 6:35:07 PM GMT
Better debugging designed from the ground up. It would use at the very least reuse the two serial pins used for the Prop programming and allow common microcontroller debugging features in the Parallax made IDE. It would be necessary for the mechanism to access the private ram spaces of all the cogs.
A few fuses for a security key that can be read only by the Prop itself. I talked about that in the past in the IP protection thread.
Frank
From someone who has been around since 8-bitters (and do some Hw hacking and reverse engineerig during years).. A few prpgrammed fuses would not do a **** on security.. As long as Propeller code is loaded from outside chip it can be recorded and altered. I know there is one potentially-secure (that is, I don't *know* any hacks) way of doing this, as it's been implemented on high end Xilinx FPGA chips (encrypted code, key only on battery backed FPGA-sram, but I don't consider it 100% .. (see www.xilinx.com/publications/xcellonline/xcell_47/xc_pdf/xc_secure47.pdf
and direct.xilinx.com/bvdocs/whitepapers/wp261.pdf for reference)
See game consoles as a reference.. If Sony, Microsoft or Nintendo can't make things Unhackable with their Megacoporation budgets, then... Ok, I do admit that Chip is a guaranteed genius, but what you people are askin is awfull lot...
(edit, add some links to Xilinx system...)
Post Edited (JoannaK) : 6/19/2007 10:29:44 PM GMT
And would it be possible to have a couple of good solid objects in the ROM ?
Objects: Serial, Keyboard, Mouse, Video, I2C, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Problem is that I probably wont need to do a design based on the new Propeller for a couple of years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
though the Propeller makes quite heavy use of self-modifying code. In fact, the (extended) instruction
set would be the same. The main difference would be in where variables are allocated. If this is left to
the assembler, the source would be identical for both modes.
I don't quite understand the remark about interrupts. There are none now, and there wouldn't have to
be any in Harvard mode, so nothing changes.
But it seems that the general consensus is that the present cog memory is already plenty, in which
case I'd indeed be trying to solve a non-problem
QFN: I agree that it would make little sense to change packages for existing products. However, if an
easier to handle QFN package could be used for future chips, everybody would win, no ? QFP is quite
large, 209% the footprint of QFN. Also hobbyists want to build small stuff
Security fuses: if there are only fuses for some sort of key, the protection mechanism must be
implemented by a trusted entity in the chip, e.g., code in ROM, and would thus be hard to
change/adapt.
No more sneak previews: damn
- Werner
The next chip will likely not have a QFN option, with 64-I/O we would likely choose a BGA package for the commercial applications, but this hasn't been determined yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 6/19/2007 11:49:54 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My computer, http://forums.parallax.com/showthread.php?p=630466
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
If MOV* and RDLONG are sufficient, however, we could use the C bit as a switch in ZCRI for all but MOV, and there
one could use the R bit (the effect of MOV .... NR could be obtained with ABS ... NR). There's also JMPRET, which
could be used to store the return address in data space. There, also C of ZCRI is available.
But perhaps this is getting too messy ...
- Werner
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 6/20/2007 12:26:46 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
LQFP is quite easy to solder by hand.
QFN is more difficult - I use a hot air blower with·success on·accelerometers that come in only a QFN package. It's still difficult, and sometimes the chips get really hot. I sometimes have to do them a second or even third time (about 30% rework required). At least they're only 16 pins.
BGA is impossible by hand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
If the balls are not that close, say 1mm or 1.27
And you use a land of vias
And there is not that many balls (that would require a 4 layer board) ...
?