You could do a lot of things with programmable memories and a few gates. I used 2716's and a few counters/gates quite often to replace relay and vacuum tube controllers on old sample changers, build interfaces to replace victor listers and such with parallel or serial printers, and a variety of other things.
I'm very late to this discussion and may have mist a detail in the fracas. One of the counter features in the SX48 the didn't get ported into the Propeller is the ability to do set-and-forget PWM with control over both frequency and duty cycle. I realize this requires another counter register. Still, as things are changing with with the Propeller, I hope there's a variant that I can use for my simple motor control projects that doesn't require a cog to run the PWM for that motor at a specific duty cycle and frequency.
I'm very late to this discussion and may have mist a detail in the fracas. One of the counter features in the SX48 the didn't get ported into the Propeller is the ability to do set-and-forget PWM with control over both frequency and duty cycle. I realize this requires another counter register. Still, as things are changing with with the Propeller, I hope there's a variant that I can use for my simple motor control projects that doesn't require a cog to run the PWM for that motor at a specific duty cycle and frequency.
Yes, Chip is talking above about a Dual Counter Cell, that supports PWM, that has (32b) set points for Period, and Duty Cycle.
See #36, and final PWM mode eqn of
if X == 0 then X=frame_count and Y=on_time, else (X--, if Y<>0 then Y--, pin output = Y<>0) ]
A nice side effect of this structure, is you can cover 0..100% ( ie off and fully on) with just value changes.
32b Counters also can manage prescale by shifts, saving silicon & regs in the Pin Cell
I have run up some Verilog of such a 32b Dual Counter cell, that has Load/Up/Down/reset/Saturate & Capture,
and control signals can then configure that for
* Period and Duty Cycle PWM, perhaps with Fault-reset from adjacent pin.
* Quadrature Counter (adjacent pins, up to 3 with index-reset)
* Event Counter / capture
* Frequency Counter (atomic dual capture of Time and Cycles)
I also looked at include of the wide-adder from the P1 Counter, into the Pin Cell, which can be done with a size/speed penalty, however I think compatibility has those P1 Counters staying in the COG.
( If the wide adder mode is already in a COG, it probably does not need to be in the Pin Cell too.)
I've seen some mention of the DACs in other threads, but not much here - particularly how they intend to be interfaced to the cogs. Can someone give me the rundown of the proposed design?
Will there be differential serializer support? for Hypertransport, Ethernet over twisted pair, Serial Digital Interface, RS-422, RS-485, USB, Serial ATA, TMDS, FireWire, and HDMI etc.
And could it use ddr clocking?, as it's a simple state machine is it possible that it could handle a 400mhz bit-rate?
Will there be differential serializer support? for Hypertransport, Ethernet over twisted pair, Serial Digital Interface, RS-422, RS-485, USB, Serial ATA, TMDS, FireWire, and HDMI etc.
And could it use ddr clocking?, as it's a simple state machine is it possible that it could handle a 400mhz bit-rate?
That may be possible. Well, probably anything is possible if the pin smarts are complex enough.
This sounds really nice. Question about "settling time"... Will there be oscillations in the output during this settling time if I just want to smoothly go from one value (say 107) to the next (108)?
Sounds like it would, in which case an RC filter might be needed on the output...
This sounds really nice. Question about "settling time"... Will there be oscillations in the output during this settling time if I just want to smoothly go from one value (say 107) to the next (108)?
Sounds like it would, in which case an RC filter might be needed on the output...
Full-scale changes settle in 3ns. Adjacent steps settle in picoseconds and the noise is a fraction of a step.
Each pin has a 75-ohm 9-bit DAC with a settling time of about 3ns. They can be set, through the pin smarts, to at least 16-bit dithered values, or they can be written very quickly to 8-bit values through the video shifter.
The performance sounds good. Although my question was directed more towards the interconnects. I've seen it mentioned that for fast DAC operation, certain cogs would be tied to certain pins. Is that the case, or can full performance be obtained between any cog and any pin?
There will be four pins per COG that can be driven by the waitvid in combination with the lookup table. There are two modes, one intended for pixels, one intended for functions. The waitvid should also just drive pins digitally like a P1 waitvid can. Those are the functions Chip has told us so far.
Those four pins are dedicated. The reason for doing this is the amount of signal propagation logic is excessive in both terms of chip area and power / heat generated.
Any COG can write to a DAC pin as quickly as you can write a loop to update it.
Again, that's the functionality described to us so far.
Any COG can write to a DAC pin as quickly as you can write a loop to update it.
I'm not so sure about that. There is cog local DACs that the video engine can drive at full speed but the rest are only available over the config serial bus, afaik. Exactly how this bus is shared between all cogs and pins I don't really know but surely it must stall the instruction for the duration of the transaction.
Maybe so. I've not seen a statement from Chip on this since the initial smart pin discussion. Good catch. Agreed. We will know pretty soon anyway. This HUB business is core. Once it gets done, we can get an FPGA image and start to better understand the relationships between the pins and cogs.
There are no DACs in the cogs, DACs are only in the pins. The cogs just have the data lines to drive up to 4 DACs at a time.
True, but the DACs are allocated as 4 to a COG, as Chip removed the general DAC BUS.
That means a specific Cog number will be associated with each group of 4 pins.
Less clear is how parallel Video out will work, but presumably similar Pin-COG mapping is planned.
The DMA + FIFO can stream from HUB, thru a COG & via optional 8:32 LUT, to drive the DACs, at fSys/N generated by NCO.
Yeah, I said up to 4 DACs can be driven from the data lines from a given cog, and yeah they will be specific DACs per cog like on the old P2 design.
I wonder if MSGOUT could be used to set DAC values on a pin, then a cog could drive DAC values to all pins. It would be at a lower rate than the 4 direct drive ones, but still very usable for many applications.
Yeah, I said up to 4 DACs can be driven from the data lines from a given cog, and yeah they will be specific DACs per cog like on the old P2 design.
I wonder if MSGOUT could be used to set DAC values on a pin, then a cog could drive DAC values to all pins. It would be at a lower rate than the 4 direct drive ones, but still very usable for many applications.
MSGOUT can be used by any cog to set a pin to DAC mode, along with a static 16-bit value which will be dithered on the 9-bit DAC to get a ~16-bit-quality sample every 128 clocks.
MSGOUT will have a variable duration, right? Duration depends on usage by other Cogs and the time it takes to perform the instruction. That's what I was mainly asking.
MSGOUT will have a variable duration, right? Duration depends on usage by other Cogs and the time it takes to perform the instruction. That's what I was mainly asking.
Every cog has its own MSGOUT circuit, so nobody needs to wait for anyone. Of course, you would want to write your code so that two cogs don't MSGOUT the same pin(s) at the same time. That would cause some unintended consequences.
Uses a differential clock (unclear if that is CMOS, or LVDS) ~ 150MHz for DDR x 8 access
HW details are sparse, but it mentions a Read Data Strobe from Memory to Host, which will provide delay-correction, and allow better re-sync on the data streaming back.
If we assume the FIFO streaming can manage fSys/N. then a HyperBus collector would need just every 2nd slot (fSys/2) at 32w, to stream blocks at 75M Opcodes/sec into HUB
Besides fast code-swap and image updates, this also opens Execute in Place (XIP) where code is executed as it is read.
12 pins is a tolerable loading, and the indications are RAM parts will be coming on this BUS.
Streamed to hubRAM, sure, but not XIP. The hardware caching/prefetching would be a nightmare for XIP.
On a Prop XIP can mean many things.
For example, many LMM solutions will involve burst reading blocks, into a COG from HUB, which was loaded from Flash.
An XIP gain there, could be as simple as doing Flash -> COG, and of course XIP does not need to be COG speed.
XIP does not need to be as fancy as cache, it can be a simple state engine that detects (PCnext = PC+1) and issues 4 edges to the HyperBus for the next (in-line) opcode.
If (PCnext <> PC+1) then a more complex (SW or HW) clock sequence is needed, that re-sets read address, and then issues the 4 edges to the HyperBus for the next (jump) opcode.
This sort of stream management and jump-detect is also useful for LMM handling.
Comments
If I want an easy GUI I will use a Raspberry Pi for 30 dollars and Qt. Or something similar.
If I want tight real-time control I will use a Propeller.
EasyGUI seems to be somebody who wants to sell me software. That's OK but I have other ways.
Yes, Chip is talking above about a Dual Counter Cell, that supports PWM, that has (32b) set points for Period, and Duty Cycle.
See #36, and final PWM mode eqn of A nice side effect of this structure, is you can cover 0..100% ( ie off and fully on) with just value changes.
32b Counters also can manage prescale by shifts, saving silicon & regs in the Pin Cell
I have run up some Verilog of such a 32b Dual Counter cell, that has
Load/Up/Down/reset/Saturate & Capture,
and control signals can then configure that for
* Period and Duty Cycle PWM, perhaps with Fault-reset from adjacent pin.
* Quadrature Counter (adjacent pins, up to 3 with index-reset)
* Event Counter / capture
* Frequency Counter (atomic dual capture of Time and Cycles)
I also looked at include of the wide-adder from the P1 Counter, into the Pin Cell, which can be done with a size/speed penalty, however I think compatibility has those P1 Counters staying in the COG.
( If the wide adder mode is already in a COG, it probably does not need to be in the Pin Cell too.)
And could it use ddr clocking?, as it's a simple state machine is it possible that it could handle a 400mhz bit-rate?
That may be possible. Well, probably anything is possible if the pin smarts are complex enough.
Sounds like it would, in which case an RC filter might be needed on the output...
Full-scale changes settle in 3ns. Adjacent steps settle in picoseconds and the noise is a fraction of a step.
The performance sounds good. Although my question was directed more towards the interconnects. I've seen it mentioned that for fast DAC operation, certain cogs would be tied to certain pins. Is that the case, or can full performance be obtained between any cog and any pin?
Those four pins are dedicated. The reason for doing this is the amount of signal propagation logic is excessive in both terms of chip area and power / heat generated.
Any COG can write to a DAC pin as quickly as you can write a loop to update it.
Again, that's the functionality described to us so far.
I'm not so sure about that. There is cog local DACs that the video engine can drive at full speed but the rest are only available over the config serial bus, afaik. Exactly how this bus is shared between all cogs and pins I don't really know but surely it must stall the instruction for the duration of the transaction.
True, but the DACs are allocated as 4 to a COG, as Chip removed the general DAC BUS.
That means a specific Cog number will be associated with each group of 4 pins.
Less clear is how parallel Video out will work, but presumably similar Pin-COG mapping is planned.
The DMA + FIFO can stream from HUB, thru a COG & via optional 8:32 LUT, to drive the DACs, at fSys/N generated by NCO.
I wonder if MSGOUT could be used to set DAC values on a pin, then a cog could drive DAC values to all pins. It would be at a lower rate than the 4 direct drive ones, but still very usable for many applications.
MSGOUT can be used by any cog to set a pin to DAC mode, along with a static 16-bit value which will be dithered on the 9-bit DAC to get a ~16-bit-quality sample every 128 clocks.
Every cog has its own MSGOUT circuit, so nobody needs to wait for anyone. Of course, you would want to write your code so that two cogs don't MSGOUT the same pin(s) at the same time. That would cause some unintended consequences.
- an extension to QuadSPI -> QuadSPI-DDR and 2-wide QuadSPI-DDR is the new HyperBus
http://www.spansion.com/Brochures/Spansion-HyperFlash-Product-Brief.pdf
http://www.slideshare.net/Spansion/spansion-hyper-bus-interface
Uses a differential clock (unclear if that is CMOS, or LVDS) ~ 150MHz for DDR x 8 access
HW details are sparse, but it mentions a Read Data Strobe from Memory to Host, which will provide delay-correction, and allow better re-sync on the data streaming back.
If we assume the FIFO streaming can manage fSys/N. then a HyperBus collector would need just every 2nd slot (fSys/2) at 32w, to stream blocks at 75M Opcodes/sec into HUB
Besides fast code-swap and image updates, this also opens Execute in Place (XIP) where code is executed as it is read.
12 pins is a tolerable loading, and the indications are RAM parts will be coming on this BUS.
For example, many LMM solutions will involve burst reading blocks, into a COG from HUB, which was loaded from Flash.
An XIP gain there, could be as simple as doing Flash -> COG, and of course XIP does not need to be COG speed.
XIP does not need to be as fancy as cache, it can be a simple state engine that detects (PCnext = PC+1) and issues 4 edges to the HyperBus for the next (in-line) opcode.
If (PCnext <> PC+1) then a more complex (SW or HW) clock sequence is needed, that re-sets read address, and then issues the 4 edges to the HyperBus for the next (jump) opcode.
This sort of stream management and jump-detect is also useful for LMM handling.
Another Hyperbus link, to go with the ones above
http://core.spansion.com/article/spansion-hyperbus-interface-enables-breakneck-read-throughput-speeds#.U_-XeaMjAkI