I don't fully understand how the 'smart' pins will work...but I am guessing??? that they can/could be used to bring back color modulation and one line composite video?
We can do composite video in software just fine with the VGA and DACS. Eric Ball showed us the way on that, actually a couple different methods.
We have enough execute speed to get this done easily. P1 actually does a fine job, and it does not have DAC output. On this new chip, signal quality should be much improved.
When we gat an FPGA image, this can be worked on. I plan to take the nice code Eric wrote for us and port it. Maybe pester him for a little maximizing it all once it is working.
You can see that in the Nyan Cat program I did for fun. That is one method, NTSC only. The other one is part of a sprite demo he did, and that is the better path IMHO, because it will result in much better color definition and resolution.
Since we have 4 DACS, it might makes sense to do S-video too, separate out color and luma for people who want higher resolution monochrome display.
I'm mostly lurking here in the three (!?) ring circus. I'm fascinated by these smart pins. Just as I am by the Prop 1 COG counters. I can't speak for Phil, but like him, I'd hate to lose the fun of playing the two counters against one another. The logic modes for one thing. Differential modes, for feeding a differential BTL audio amplifier for example. Assigning multiple counters to one single pin, a lot can be done with that. It may be that I've missed something, and those functions won't be lost at all. In any case, it's pretty exciting.
I hope the pins are smart enough to allow open-drain serial out? And also weak (50k) and strong (5k) pull-up/down?
Chip has said that the P2 pin design will be used so they should have all the pull up/down and also the 75 serial impedance for video dacs. I have understood so.
... it might makes sense to do S-video too, separate out color and luma for people who want higher resolution monochrome display.
If you can do S-Video then you should do also composite. Isn't the s-video to composite (rca) converter cables (eg the ones with some laptops) just a resistive adder of luminance and chrominance signals?
Okay. I've got the new instruction set arranged. It's not final, but it tells what the cog does:
ZCDS (for D column: W=write, M=modify, R=read, L=read/immediate)
----------------------------------------------------------------------------------------------------------------------
ZCWS 1001100 ZC I CCCC DDDDDDDDD SSSSSSSSS MSGINA D,S/# (waits up to 64 clocks to receive %010_data32 message on INA, C=timeout)
ZCWS 1001101 ZC I CCCC DDDDDDDDD SSSSSSSSS MSGINB D,S/# (waits up to 64 clocks to receive %010_data32 message on INB, C=timeout)
Is the message sent to pins to configure them as I understood. It starts with 010 header and the data32 is the configuration bits to select the operating mode.
The 010 sould differentiate the configuration message from the normal changes driven by the program, because the program can't drive so quickly ... Chip has said
The analog circuit of the Prop2 had a comparator per pin, that allows to compare the voltage at a pin with a referene voltage from a 8bit DAC or with the voltage at a second pin. Because the new chip uses the same analog blocks, I hope these all is still possible. But only Chip can say it for sure.
If you can do S-Video then you should do also composite. Isn't the s-video to composite (rca) converter cables (eg the ones with some laptops) just a resistive adder of luminance and chrominance signals?
As far as I know, that is true. I've done it that way in the past. Either way, we can get nice composite on this design. It will just take a bit of work.
There are some uses of the timers like generating a clock for fast SPI that require very tight integration with the COG for timing purposes.
There are likely some other uses that benefit from tight coupling with the COG.
It would be good to identify such uses and make sure we have workarounds in place on the new design.
C.W.
Imagine that the pin smarts have an NCO mode that is gated and triggered by the OUT signal. You configure the pin by sending a message, then you reset/gate the NCO via the OUT pin. Remember that DIR will be held high to keep the pin in its special mode, and this means the OUT signal gets out to the pin, too. When OUT is low, the NCO will be held in reset, as soon as OUT goes high, it releases and begins counting. Aside from NCO's, we can have clock dividers, pulses every Nth clock, etc. This is a huge playground for development.
The pins will have all the drive modes that have been planned.
I would post that table, like I have done before, but my newer Windows 8 box that doesn't do internet doesn't have Paint.exe, so I can't get a screenshot from there onto my memory stick to be able to get it onto this computer to post it. Maybe someone knows where that image is on the forum.
No Verilog work has been done for these circuits yet. You are way ahead of me.
I focused on the inner Cell, with Boolean and Data Paths needed for all operations. Two of these 32b cells are needed.
I recoded the Verilog to move the ClockEnable to a more explicit node, and the tools did better.
This splits the logic, so Clock enable does not widen the Data Path, but has its own logic tree.
Might play with the RST line next, as I think a DFFCER register would code the smallest.
Report improved, less Slices and faster Clock reported
Number of SLICEs: 77 out of 4864 (2%)
Number of Clock Enables: 1
Net QC_CE: 24 loads, 24 LSLICEs
Number of ripple logic: 16 (32 LUT4s)
I wonder the same things, too, but Phil Pilgrim is absolutely adamant that we must keep them. I wish he would elaborate on why he feels this way. Phil?
The issues I can see are
a) Backward compatibility
b) Access Bandwidth - I have some reservations on the Bandwidth of the COG <-> Pin Cell path.
The NCO form is larger and a little slower, so I would suggest support that in the COG-Ctr, as now and leave NCO off the Pin-Ctr, if space or speed gets tight.
The pins will have all the drive modes that have been planned.
I would post that table, like I have done before, but my newer Windows 8 box that doesn't do internet doesn't have Paint.exe, so I can't get a screenshot from there onto my memory stick to be able to get it onto this computer to post it. Maybe someone knows where that image is on the forum.
Do I have this right? You would have to send a message to a pin just to make it high or low? What would the latency be?
-Phil
I'm sure one of the modes would be "straight through".
It might get interesting where trying to do a 1 pin sigma delta style thing, swapping back and forth between output and input modes, but then again there will be better ways to do this using pad smarts now
I don't see a open-drain mode, if you bit bang a pin you use dir to do it but if any type of digital serial out only have push-pull mode is not good.
The HHH and LLL are the configurations for the upper and lower legs of the output drivers. They can be configured independently and include current sourcing / sinking modes
For open drain just set the high side driver HHH to "float", and the low side driver LLL to "fast" or "slow" depending on the application
> HHH and LLL are the configurations for the upper and lower legs of the output driving (totem pole like) drivers
Oh cool, gives some many options that it's mind boggling.
My understanding is that the DIRA/OUTA/INA stuff (and the B variants) will work the same as before unless you do one of the xxxMSG commands to put the pin into a "special" mode, and then things change as Chip has described a bit.
As a side effect, if the pin is not in a special mode, and you do the OUTMSG command then it'll toggle the pin with the message instead of feeding the message to the special mode stuff.
So you should still be able to set or read pins just as you always have with the P1, but now you can also turn on special modes to do even more cool stuff!
> HHH and LLL are the configurations for the upper and lower legs of the output driving (totem pole like) drivers
Oh cool, gives some many options that it's mind boggling.
Yes, exciting isn't it. That table takes a bit of interpreting and its certainly not all obvious at first glance. I remember drawing out a kind of circuit diagram with some of the useful combos. There were ideas around how the resistor combinations could be switched to 'measure' a single external resistor at bootup, to select different operating modes or boot devices. While we possibly don't need that now, the use case remains for other applications.
We'll need to do that a bit with the Next Propeller. There's some really neat powerful stuff but it'll need to be spelt out clearly in the documentation. No having to hunt down AN001 "Counters" doc to reveal prop1 can in fact do analog input of sorts.
Do I have this right? You would have to send a message to a pin just to make it high or low? What would the latency be?
No, the normal direct IO paths remain. Any SW bit-banging is unchanged.
This gives a Cell at the pin, that can be optionally enabled.
When enabled, the direct-booleans of OUT can be used as an enable/trigger of a setup module.
The Bandiwidth limit is on the serial path to config, and read the captured values.
Do I have this right? You would have to send a message to a pin just to make it high or low? What would the latency be?
-Phil
Criminy! NO!!! You're expecting the worst.
The pin is normal until it gets a configuration command on DIR, then IN/OUT/DIR might take on new roles. You can put the pin back in normal mode by sending it another command via DIR, using that fast %010 transition that only MSGDIRA/MSGDIRB can generate. Normal software can't do it accidentally. And the CTR's only affect the OUT pins, so there's no possibility of things going haywire.
And where will MSGINx store this 36-bit value to? Or the 32 data bits? In which case, why does the user need to know about the remaining 3+1 bits?
The user doesn't know about the preamble bits. They are generate and received quietly.
When a pin is in some special modes, it streams 32-bit messages, separated by 32 or more clocks, so when you do a MSGINA/MSGINB, the cog waits for the dead space and then receives the next message. If it never gets a message in time, it returns C=1. Messages are always coming via INA/INB for pins configured to modes where messaging is needed.
If configuring a pin for 100k pull-up / strong low output, there would be no ongoing messaging from INA because the pin would just need to behave logically as a normal I/O.
Comments
There are likely some other uses that benefit from tight coupling with the COG.
It would be good to identify such uses and make sure we have workarounds in place on the new design.
C.W.
We have enough execute speed to get this done easily. P1 actually does a fine job, and it does not have DAC output. On this new chip, signal quality should be much improved.
When we gat an FPGA image, this can be worked on. I plan to take the nice code Eric wrote for us and port it. Maybe pester him for a little maximizing it all once it is working.
You can see that in the Nyan Cat program I did for fun. That is one method, NTSC only. The other one is part of a sprite demo he did, and that is the better path IMHO, because it will result in much better color definition and resolution.
Since we have 4 DACS, it might makes sense to do S-video too, separate out color and luma for people who want higher resolution monochrome display.
Chip has said that the P2 pin design will be used so they should have all the pull up/down and also the 75 serial impedance for video dacs. I have understood so.
If you can do S-Video then you should do also composite. Isn't the s-video to composite (rca) converter cables (eg the ones with some laptops) just a resistive adder of luminance and chrominance signals?
What is "%010_data32"?
The 010 sould differentiate the configuration message from the normal changes driven by the program, because the program can't drive so quickly ... Chip has said
Is something similar already built in pins? The goal is to not have to continuously read an analog channel and compare it with a given threshold thus having a quicker reaction and saving power. Analog comparators are built-in in many uC.
The analog circuit of the Prop2 had a comparator per pin, that allows to compare the voltage at a pin with a referene voltage from a 8bit DAC or with the voltage at a second pin. Because the new chip uses the same analog blocks, I hope these all is still possible. But only Chip can say it for sure.
Andy
It would be nice if the comparator output can also be part of the cogs's output OR so it can directly drive external circuitry.
As far as I know, that is true. I've done it that way in the past. Either way, we can get nice composite on this design. It will just take a bit of work.
Imagine that the pin smarts have an NCO mode that is gated and triggered by the OUT signal. You configure the pin by sending a message, then you reset/gate the NCO via the OUT pin. Remember that DIR will be held high to keep the pin in its special mode, and this means the OUT signal gets out to the pin, too. When OUT is low, the NCO will be held in reset, as soon as OUT goes high, it releases and begins counting. Aside from NCO's, we can have clock dividers, pulses every Nth clock, etc. This is a huge playground for development.
%010dddddddddddddddddddddddddddddddd0, where d is 32 bits of data. the final state of the message is 0.
I would post that table, like I have done before, but my newer Windows 8 box that doesn't do internet doesn't have Paint.exe, so I can't get a screenshot from there onto my memory stick to be able to get it onto this computer to post it. Maybe someone knows where that image is on the forum.
I focused on the inner Cell, with Boolean and Data Paths needed for all operations. Two of these 32b cells are needed.
I recoded the Verilog to move the ClockEnable to a more explicit node, and the tools did better.
This splits the logic, so Clock enable does not widen the Data Path, but has its own logic tree.
Might play with the RST line next, as I think a DFFCER register would code the smallest.
Report improved, less Slices and faster Clock reported
Number of SLICEs: 77 out of 4864 (2%)
Number of Clock Enables: 1
Net QC_CE: 24 loads, 24 LSLICEs
Number of ripple logic: 16 (32 LUT4s)
Sounds ok. What die area impact does that have on COGs now - ie how much area is Timer ?.
The issues I can see are
a) Backward compatibility
b) Access Bandwidth - I have some reservations on the Bandwidth of the COG <-> Pin Cell path.
The NCO form is larger and a little slower, so I would suggest support that in the COG-Ctr, as now and leave NCO off the Pin-Ctr, if space or speed gets tight.
-Phil
This is the table from the preliminary P2 pdf:
And where will MSGINx store this 36-bit value to? Or the 32 data bits? In which case, why does the user need to know about the remaining 3+1 bits?
I don't see a open-drain mode, if you bit bang a pin you use dir to do it but if any type of digital serial out only have push-pull mode is not good.
I'm sure one of the modes would be "straight through".
It might get interesting where trying to do a 1 pin sigma delta style thing, swapping back and forth between output and input modes, but then again there will be better ways to do this using pad smarts now
The HHH and LLL are the configurations for the upper and lower legs of the output drivers. They can be configured independently and include current sourcing / sinking modes
For open drain just set the high side driver HHH to "float", and the low side driver LLL to "fast" or "slow" depending on the application
Oh cool, gives some many options that it's mind boggling.
As a side effect, if the pin is not in a special mode, and you do the OUTMSG command then it'll toggle the pin with the message instead of feeding the message to the special mode stuff.
So you should still be able to set or read pins just as you always have with the P1, but now you can also turn on special modes to do even more cool stuff!
Yes, exciting isn't it. That table takes a bit of interpreting and its certainly not all obvious at first glance. I remember drawing out a kind of circuit diagram with some of the useful combos. There were ideas around how the resistor combinations could be switched to 'measure' a single external resistor at bootup, to select different operating modes or boot devices. While we possibly don't need that now, the use case remains for other applications.
We'll need to do that a bit with the Next Propeller. There's some really neat powerful stuff but it'll need to be spelt out clearly in the documentation. No having to hunt down AN001 "Counters" doc to reveal prop1 can in fact do analog input of sorts.
No, the normal direct IO paths remain. Any SW bit-banging is unchanged.
This gives a Cell at the pin, that can be optionally enabled.
When enabled, the direct-booleans of OUT can be used as an enable/trigger of a setup module.
The Bandiwidth limit is on the serial path to config, and read the captured values.
Criminy! NO!!! You're expecting the worst.
The pin is normal until it gets a configuration command on DIR, then IN/OUT/DIR might take on new roles. You can put the pin back in normal mode by sending it another command via DIR, using that fast %010 transition that only MSGDIRA/MSGDIRB can generate. Normal software can't do it accidentally. And the CTR's only affect the OUT pins, so there's no possibility of things going haywire.
The user doesn't know about the preamble bits. They are generate and received quietly.
When a pin is in some special modes, it streams 32-bit messages, separated by 32 or more clocks, so when you do a MSGINA/MSGINB, the cog waits for the dead space and then receives the next message. If it never gets a message in time, it returns C=1. Messages are always coming via INA/INB for pins configured to modes where messaging is needed.
If configuring a pin for 100k pull-up / strong low output, there would be no ongoing messaging from INA because the pin would just need to behave logically as a normal I/O.