I love the chip-2-chip communication, but it should also support sending/receiving 8 and 16 bit values - which would allow it to be used for very easy, super-fast SPI to/from peripherals!
Yes, looks great - but you are right, it certainly needs a Length control (and also the usual CLKSPEED and Polarity controls.
Less clear is if this has annoying 'gaps' between sends (no mention of a fifo) ?
I've also often thought SPI ports with good baud rate register control, should have a simple flag for continual CLKOUT use.
Hey guys, please note the preliminary spec is vague about all the on board hardware devices on purpose. The documents goal is just to detail major features. As the P2 nears completion a more detailed image will appear. Until then enjoy thinking about the new features.
Each processor has 4 9-bit DACs. So, VGA potentially needs 5 pins.
Kye with reference to that article, can you please elaborate on whether you are aiming to implement the "basic" (includes phase information) or "optimised" (no phase information) variant?
With VGA now likely to only require 5 pins (down from 8), TV is possibly 1 (down from 3), this is going to release some pins.
I do sure hope the counters do provide a primitive method of reading serial streams. Even if just a couple of gates are provided to permit the existing logic to reverse the direction like the following diagram portrays...
I do sure hope the counters do provide a primitive method of reading serial streams. Even if just a couple of gates are provided to permit the existing logic to reverse the direction like the following diagram portrays...
Did you see this in the pdf ?
["Each cog now also features high-speed serial transfer and receive hardware for chip-to-chip communication. The hardware requires three I/O pins (SO, SI, CLK)."]
This SPI mode has 3 supporting opcodes.
Or do you want the counters to also be Serially Configurable - that adds a multiplexer to every flipflop, and will slow it down.
Depends how much 180MHz margin there is, as I'd not want the counters slower than the SYSCLK
@BigFoot - The new chip will feature the ability to read/write 16-bit or 32-bit data from any bank of the 96 I/O pins and transfer that data to the CLUT for video output or to main memory. This is simply a hardware assist for each cog that reads data (possibly every clock) into the chip or writes data (possibly every clock) out from the chip. The cog will still need to manage the data stream but at a higher address directing level instead of having to read or write the data manually.
@jmg - The serial input and output commands are for cog to cog comminucation. Unless they have been updated since this information was produced... they are not general purpose. As from my above post. Each cog is now so fast that sending data serially by bit banging should not be a problem. I understand the desire for dedicated serial input and output hardware. However, Chip choose not to persue that in the new design.
@Cluso99 - The counters will feature more functional modes, however, I do not know what they are.
@Tubular - Each I/O pin features a high speed (like over 160Mhz) sigma delta ADC built in to it locally which can generate a serial bit stream that is transfered to a cog's counter modules. This serial bit stream is then acculumated to respresent the voltage on the I/O pin digitally. The accumulation is then compared to a preset frequency and phase accumulation to get the power and phase of the frequency choosen on that I/O pin. I do not know exactly how this works but the goal is to have the SIN and COS accumulator registers store the power and phase of the Goertzel Transform in them. Simply... this allows you to pick a compare frequency and a compare phase for a I/O pin and see what the power and phase of that frequency of the signal on the I/O pin is. By doing a frequency sweep on the counter the frequency domain of a signal on any I/O pin can be gotten.
@jmg - The serial input and output commands are for cog to cog comminucation. Unless they have been updated since this information was produced... they are not general purpose. As from my above post. Each cog is now so fast that sending data serially by bit banging should not be a problem. I understand the desire for dedicated serial input and output hardware. However, Chip choose not to persue that in the new design.
Are you sure ?
The heading says
["Chip-To-Chip Communication"]
and more text says
["Sets up the serial port I/O pins to use for SO, SI, and CLK given D or “n (0-63)”."]
That sounds to me like it is chip to chip via physical pins ? If not, they need to rewrite that part of the data.
Cog to Cog has a different heading:
Cog-To-Cog Communication
Cogs now have the ability to communicate directly to each other using the internal I/O Port D, which connects each cog to every other cog.
Table 20: Cog-To-Cog Communication Instruction Machine Code Mnemonic Operand Operation
000011_zcn_1_cccc_nnnnnnnnn_011101000
SETXCH D/#n Reconfigure Port D I/O masks given D or n to select which cogs to listen to.
but this is vague on what happens next. Is this talking about virtual (buried) pins ?
jmg: This is for comms between prop chips and uses 3 pins.
What seems to be missing, and I did think it was going to be included, is some method to receive in a serial stream of bits. It does not have to be asynchronous etc, just the ability to shift in serially into a register (and the 32 bit register makes the most sense and would be the easiest). As can be seen, just a couple of gates per counter makes serial input easy. The counter could be configured with all the modes possible to clock it. Without this, we will not be able to do such things as USB without multiple cogs. This would be a real shame - just my opinion.
The D port is a buried 32bit port designed for fast comms between cogs.
jmg: This is for comms between prop chips and uses 3 pins.
What seems to be missing, and I did think it was going to be included, is some method to receive in a serial stream of bits. It does not have to be asynchronous etc, just the ability to shift in serially into a register.
I'm not sure I follow, The SPI shifter looks like it can Send and receive, what is missing ?
Do you need an external CLK signal (SPI Slave ?) - but if it does Chip-Chip, one must be a slave so that will be in there ?
(no detail on gaps, etc ) If there are spare opcode bits, they could set the Length (1..32) ?
The D port is a buried 32bit port designed for fast comms between cogs.
So is this like a peephole cross point R/W (no contention) where any pair (or more?) can communicate with no side effects ?
Or do all Cogs have to 'take turns' ?
So is this like a peephole cross point R/W (no contention) where any pair (or more?) can communicate with no side effects ?
Or do all Cogs have to 'take turns' ?
I am under the impression that "Port D" is in addition to the hub interaction, so I don't think they would have to take turns... but someone please correct me if I am wrong.
Hope this is not a stupid question but I couldn't tell from the PDF.... does anyone know if SPIN will be able to handle floating point or is it still going to require using a cog+library functions to handle a floating point value?
I suspect that port D works like any other Prop port.
Every cog gets it's own input/output/direction register for it.
Any cog can access it at any time, as they do for the Prop I port register.
Writes will be OR'ed together to get the final "output" on the pin that any cog can see with IN.
Only difference being there is no actual hardware pins coming from it.
Could be wrong but that seemed to be how the discussion was going about it a while back.
@jmg - Sorry, what I meant was that the serial communication commands send out 32 bit words through a fixed piece of RTL state machine logic. It isn't flexible so it will not be useful to much more than using it to talk between chips.
Port D is an internal set of 32 I/O pins. They can be read and written as if they were regular I/O pins. They just have no external connection.
@sariel - No floating point. This is common, however, for most microcontrollers. FP will be far easier with the new instruction set and hardware devices.
Also, the P2 will contain the ability to remap port A,B,C,D with each other. This allows you to write a program which always uses port A but with one command can move the bank of physical pins it talks to between 0-127. Only 0-95 are external, however. This must be aligned. So you can only remap to 0, 32, 64, 96 in the pin address space.
Oh well, hardware multiply and divide are nice all on thier own and i imagine they greatly simplify doing the FP in code. I just don't like haveing to burn a cog up to multiply or divide by 1.5 when needed but given the hurt I've been going through getting another micro to juggle several tasks at once It's a small price to pay. This looks like an awesome chip for a later upgrade to the robot brains I'm working on.
@jmg - Sorry, what I meant was that the serial communication commands send out 32 bit words through a fixed piece of RTL state machine logic. It isn't flexible so it will not be useful to much more than using it to talk between chips.
SPI is plenty smart enough for many tasks, and if there are 'no gaps' you can make useful PWM DACs out of it....
However, it really does need length control ability.
Can the phase accumulators be configured to run through the SIN or COS registers and then through the D/A converter to create a DDS running at the clock frequency? That would be awesome!
GCC or Catalina or ICC would be faster than Spin.
The former are compiled to native PASM instructions run via LMM or loaded directly into COG. Spin is compiled to byte codes which are then interpreted at run time which will alway be much slower (unless someone is up for creating a Spin to native compiler).
Spin will still have advantages as the byte code executables will alway be smaller than native code so more functionality can be acheived in Spin if the slower speed is acceptable.
Spin will still have advantages as the byte code executables will alway be smaller than native code so more functionality can be acheived in Spin if the slower speed is acceptable.
Wow, I have missed out on a lot of info. Do to my time line and the need to bitbang raw video at 120MHz with 16bpp it apears that I will have to use an ARM for the first generation of the MuAmi. I look forward to the Prop2.
Comments
Yes, looks great - but you are right, it certainly needs a Length control (and also the usual CLKSPEED and Polarity controls.
Less clear is if this has annoying 'gaps' between sends (no mention of a fifo) ?
I've also often thought SPI ports with good baud rate register control, should have a simple flag for continual CLKOUT use.
Each processor has 4 9-bit DACs. So, VGA potentially needs 5 pins.
The divide is is 32/32 -> 32R and 32Q.
The plan for the counter modules is to have them implement the Goertzel algorithm http://www.eetimes.com/design/embedded/4024443/The-Goertzel-Algorithm in hardware. That's what the SIN/COS stuff is for.
Unfortunately, there may not be hardware for incoming serial streams. It depends on what can make it into the design.
Please consider the new speed of the chip when thinking about device I/O.
Thanks,
is going to work ?
That sounds like a lot of silicon ?
I hope the simple, more widely used stuff like HW Capture on the counters is not overlooked ?
Kye with reference to that article, can you please elaborate on whether you are aiming to implement the "basic" (includes phase information) or "optimised" (no phase information) variant?
thanks
tubular
I do sure hope the counters do provide a primitive method of reading serial streams. Even if just a couple of gates are provided to permit the existing logic to reverse the direction like the following diagram portrays...
Did you see this in the pdf ?
["Each cog now also features high-speed serial transfer and receive hardware for chip-to-chip communication. The hardware requires three I/O pins (SO, SI, CLK)."]
This SPI mode has 3 supporting opcodes.
Or do you want the counters to also be Serially Configurable - that adds a multiplexer to every flipflop, and will slow it down.
Depends how much 180MHz margin there is, as I'd not want the counters slower than the SYSCLK
@jmg - The serial input and output commands are for cog to cog comminucation. Unless they have been updated since this information was produced... they are not general purpose. As from my above post. Each cog is now so fast that sending data serially by bit banging should not be a problem. I understand the desire for dedicated serial input and output hardware. However, Chip choose not to persue that in the new design.
@Cluso99 - The counters will feature more functional modes, however, I do not know what they are.
@Tubular - Each I/O pin features a high speed (like over 160Mhz) sigma delta ADC built in to it locally which can generate a serial bit stream that is transfered to a cog's counter modules. This serial bit stream is then acculumated to respresent the voltage on the I/O pin digitally. The accumulation is then compared to a preset frequency and phase accumulation to get the power and phase of the frequency choosen on that I/O pin. I do not know exactly how this works but the goal is to have the SIN and COS accumulator registers store the power and phase of the Goertzel Transform in them. Simply... this allows you to pick a compare frequency and a compare phase for a I/O pin and see what the power and phase of that frequency of the signal on the I/O pin is. By doing a frequency sweep on the counter the frequency domain of a signal on any I/O pin can be gotten.
Are you sure ?
The heading says
["Chip-To-Chip Communication"]
and more text says
["Sets up the serial port I/O pins to use for SO, SI, and CLK given D or “n (0-63)”."]
That sounds to me like it is chip to chip via physical pins ? If not, they need to rewrite that part of the data.
Cog to Cog has a different heading:
Cog-To-Cog Communication
Cogs now have the ability to communicate directly to each other using the internal I/O Port D, which connects each cog to every other cog.
Table 20: Cog-To-Cog Communication Instruction Machine Code Mnemonic Operand Operation
000011_zcn_1_cccc_nnnnnnnnn_011101000
SETXCH D/#n Reconfigure Port D I/O masks given D or n to select which cogs to listen to.
but this is vague on what happens next. Is this talking about virtual (buried) pins ?
What seems to be missing, and I did think it was going to be included, is some method to receive in a serial stream of bits. It does not have to be asynchronous etc, just the ability to shift in serially into a register (and the 32 bit register makes the most sense and would be the easiest). As can be seen, just a couple of gates per counter makes serial input easy. The counter could be configured with all the modes possible to clock it. Without this, we will not be able to do such things as USB without multiple cogs. This would be a real shame - just my opinion.
The D port is a buried 32bit port designed for fast comms between cogs.
I'm not sure I follow, The SPI shifter looks like it can Send and receive, what is missing ?
Do you need an external CLK signal (SPI Slave ?) - but if it does Chip-Chip, one must be a slave so that will be in there ?
(no detail on gaps, etc ) If there are spare opcode bits, they could set the Length (1..32) ?
So is this like a peephole cross point R/W (no contention) where any pair (or more?) can communicate with no side effects ?
Or do all Cogs have to 'take turns' ?
I am under the impression that "Port D" is in addition to the hub interaction, so I don't think they would have to take turns... but someone please correct me if I am wrong.
Every cog gets it's own input/output/direction register for it.
Any cog can access it at any time, as they do for the Prop I port register.
Writes will be OR'ed together to get the final "output" on the pin that any cog can see with IN.
Only difference being there is no actual hardware pins coming from it.
Could be wrong but that seemed to be how the discussion was going about it a while back.
Port D is an internal set of 32 I/O pins. They can be read and written as if they were regular I/O pins. They just have no external connection.
@sariel - No floating point. This is common, however, for most microcontrollers. FP will be far easier with the new instruction set and hardware devices.
Also, the P2 will contain the ability to remap port A,B,C,D with each other. This allows you to write a program which always uses port A but with one command can move the bank of physical pins it talks to between 0-127. Only 0-95 are external, however. This must be aligned. So you can only remap to 0, 32, 64, 96 in the pin address space.
Go GCC!
Also SPIN will be more than 8X faster so a software implementation will be possible.
SPI is plenty smart enough for many tasks, and if there are 'no gaps' you can make useful PWM DACs out of it....
However, it really does need length control ability.
Thanks, so it is as I originally thought - what I called virtual (buried) pins.
Ian
Will Spin be faster or GCC?
The former are compiled to native PASM instructions run via LMM or loaded directly into COG. Spin is compiled to byte codes which are then interpreted at run time which will alway be much slower (unless someone is up for creating a Spin to native compiler).
Spin will still have advantages as the byte code executables will alway be smaller than native code so more functionality can be acheived in Spin if the slower speed is acceptable.
Thanks. Good to know.