That's my understanding, too. I think jmg was thinking about some intra-cycle abort mechanism. It seems to me that the triangle PWM, as it stands, is all we need.
Yes, deadband is natural from Triangle Wave, but Triangle Wave PWM still drives MOSFETS and MOSFETS can still need protection in such systems.
I'm pretty confident that doesn't matter. The two measurements run independently, and asynchronously to the signal, and give a separate result each. The two results are both as accurate as can be achieved respectively. One is more precise than the other depending on the pulse rate vs sample period.
?? I'm not sure what you are reading.
Reciprocal Counting is simple:
You measure some whole number of cycles, and time how long that whole number of cycles takes.
Frequency = wCycles/wTime
Those two measurements are certainly not independently, nor are they asynchronously to the signal , so both your assertions are incorrect.
It is very important they run concurrently, otherwise you have no idea how many cycles wTime relates to, and they also must be Captures done synchronously to the signal, in order to know you have whole cycles.
Plus, you need care to be sure the same edge is used, and at high frequencies SW alone is not enough to do that. HW support can be as simple as a FlipFlop, but something is needed & aperture effects need attention.
Try some numbers on 'independent, and asynchronous' captures, and see how that goes.
They are parallel circuits, measuring the same signal source, but still independent of each other and there is no choice but to be asynchronous to the signal. The signal has no clock of it's own. It's just another variant of oversampling really (That probably pre-dates the coining of digital sampling).
Parallel flip-flops, one for each method of measure, is fine for capturing the same edge in parallel. If the edge rate is faster than the system clock then aliasing occurs and neither system works.
There is always potential for a particular edge to fall on either side of the system clock sampling but that noise accumulates out over time. It doesn't matter if one circuit see it one way and the other circuit see it the other way for a particular sample. That's all within the normal sampling noise limits.
They are parallel circuits, measuring the same signal source, but still independent of each other and there is no choice but to be asynchronous to the signal. It's just another variant of oversampling really.
Parallel flip-flops, one for each method of measure, is fine for capturing the same edge in parallel. If the edge rate is faster than the system clock then aliasing occurs and neither system works.
Dual paths should ideally be avoided when crossing clock domains.
However, I think this will not be an issue, as I expect all Smart pins have a Sampling FF per pin.
(Some MCUs have two in series, that helps noise filtering, but does lower the change-rate)
That means there is a single path across the clock domains, for a single pin.
Chip may be able to confirm Pin sampling FF details ?
(This FF is separate from the Capture trigger FF I mention.)
There is no clock in the signal so there is no domain crossing.
And even if there was a clock, like with ADC bitstreams, it is only an optional feature for power efficient/easy transfer. The signal is still analogue in nature so can be happily up-sampled.
There is no clock in the signal so there is no domain crossing.
In the teaching I had, going from ASYNC to SYNC, certainly counts as clock domain crossing.
Any time the edges are not same-clock aligned, you need care, a second clock wire is not a prerequisite to need that care, all it needs is for the edge to be derived from another clock, (or subject to uncertain delays).
UARTs are a different beast, there the individual bits are required 100%, it is not an analogue signal. A detail, presumably due to it being a digital data transfer, a UART is in fact trying to find a synchronous signal between the stop and start bits even though it has no embedded clock.
When a smart pin completes some task, it signifies by raising its IN signal and updating its 32-bit result value which can be read by the PINREAD instruction. The result value is conveyed four bits per clock and the system counter's three LSBs are used to mux the eight nibbles as they go out. The bug is that IN signals right away, while the result value starts coming up to 7 clocks later, while the cog needs to begin inputting on a certain 8th system counter value. This causes old values to be read right after IN goes high.
To fix this, I'm going to add a fifth bit to the return value mechanism, so that the smart pin can signal right away when a new value is coming. This will save a net 28 flops in each smart pin and get result values back to cogs deterministically from IN rise, as the system counter won't be needed, anymore, to coordinate the messaging.
I still love mono green. My first PC was a IBM compatible Commodore PC 10 with one floppy drive (before color, affordable Hard Drives etc) with a green Mono screen. Yea, back in the good old days
So we have a net of 28 flops in each smart pin available . What feature can we add now ? LOL
Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.
Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.
The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"
I still love mono green. My first PC was a IBM compatible Commodore PC 10 with one floppy drive (before color, affordable Hard Drives etc) with a green Mono screen. Yea, back in the good old days
So we have a net of 28 flops in each smart pin available . What feature can we add now ? LOL
My old Parallax friend/cofounder Lance told this story once, about budgeting:
"I wanted to get a new TV, so a decided I'd spend $100. I got to the store and saw a really nice TV for $500. I realized that was too expensive, but I found another pretty good one for only $300. So, I bought that one and SAVED $200."
Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.
Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.
The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"
I learned the same way, but on an Apple ][ that my dad would bring home from work on the weekends. Boy, everything was so new and engrossing back then. There are still new frontiers, but it seems like it takes a long hike to get to them.
Okay. I've got the smart pin reading problem solved by making those changes. It's rock-solid now and the smart pins shrunk by about 10 ALM's. This is a much better approach than using the system counter to coordinate transfers, since messages can now start on any clock, coincident with INA rising. This simplified both the smart pin side and the cog side.
In order to keep the cog from hanging on potential continuously-overlapping new messages, since they now start asynchronously, the message sender in the smart pin skips any new message when the current message hasn't shifted out all the way at least once. This could have been a problem if you were measuring states that were occurring faster than the message sending, which takes 8 clocks. Meanwhile, the smart pin keeps resending the current message, so that the cog can get it whenever it's ready to. A new message can occur at any time and the smart pin just sets that 5th bit that signifies start-of-message, for one clock, in order to tell the cog to reset its nibble counter, so it will tack the current nibble onto the incoming 7, in order to get the whole 32-bit value. In case a smart pin is not configured and you try to read it, you will just get $00000000, because 8 clocks will elapse without getting that 5th-bit pulse, and the smart pin clears its nibble output when disabled.
I don't know why I didn't anticipate this message/IN phase problem the first time around, but it's nailed now.
For what it's worth, here is the Verilog in the smart pin than sends out messages:
// message output
reg [36:0] msg;
wire msgr = msg[34:32] == 3'b111 && m_smart; // restart-of-message flag with cancel
wire [3:0] msgi = {msg[35], 3'b0} | msg[34:32] + 3'b001; // message-sent flag and nibble counter
wire [31:0] msgd = {msg[3:0], msg[31:8], msg[7:4] & {4{m_smart}}}; // data shifter with cancel
always @(posedge clk)
if (m_smart || msg[36] || (|msg[3:0])) // update if smart pin mode or outputs not 0
msg <= msgi[3] && signal_ ? {1'b1, 4'b0, result_} // start new message if current message sent
: {msgr, msgi, msgd}; // update flags and shift data
assign pin_msg = {msg[36], msg[3:0]}; // output start flag and message nibble
m_smart = smart pin mode active
signal_ = capture result_ for message output and raise IN to alert cog(s)
result_ = 32-bit data to be captured and sent as message (repeatedly, until a new signal_ event)
Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.
Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.
The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"
Ha! For me, it was the Kaypro II, which we always just referred to as "the luggable." It was turbo pascal that really got me started. This brings back an old memory...
My dad had brought the luggable along when we were visiting family for Christmas (I'm guessing I was about 10 at the time). While we were there, I wrote my first real program, which simply output an increasing frequency on the speaker until you pressed the space bar. It would then print out the frequency. The idea was to press the space bar when you couldn't hear the sound any more. The entire family, young and old, took turns seeing what their hearing range was.
All right. Now that the messaging problem is fixed, I was able to finish testing the measurement modes. What is left to test is the custom configurable modes and the serial modes.
One thing that has me kind of wishing for a better way are the mnemonics and operand conventions for these smart pin instructions.
All right. Now that the messaging problem is fixed, I was able to finish testing the measurement modes. What is left to test is the custom configurable modes and the serial modes.
One thing that has me kind of wishing for a better way are the mnemonics and operand conventions for these smart pin instructions.
#14 should be some meaningful constant in most cases instead of an immediate value which will make the alignment look totally different!
In my mind, your second group works for all except 'pinread'. It each instruction, the D field should be the pin# because the pin is the destination of the MODE, SETX, SETY and ACK.
For 'pinread #14,pinval' it is anomalous like wrbyte/wrword/wrlong. So it can be made analogous to them. It becomes
wrpin #14,pinval
where you are writing the value of the pin to memory sort of like you are writing from COG to HUB with the wrxxxx instructions.
#14 should be some meaningful constant in most cases instead of an immediate value which will make the alignment look totally different!
In my mind, your second group works for all except 'pinread'. It each instruction, the D field should be the pin# because the pin is the destination of the MODE, SETX, SETY and ACK.
For 'pinread #14,pinval' it is anomalous like wrbyte/wrword/wrlong. So it can be made analogous to them. It becomes
wrpin #14,pinval
where you are writing the value of the pin to memory sort of like you are writing from COG to HUB with the wrxxxx instructions.
That would be a good way to do it, but a little tricky on the brain.
I agree that is makes more sense that the pin number be the destination register, but I get the sense from Chip's original comment that a reversal of the fields wouldn't be at the bit-encoding level, just in the PASM instructions. If that's the case, I think it should be left as it is to stay consistent with the rest of the PASM instruction set. Other languages are free to do what they want.
That makes sense, but you should list all pin access opcodes, and have them consistent across all that apply to pins.
D & S have less meaning when not registers, and PIN is first in the name.
They all start with PIN, which seems sensible and makes them easy to find.
In fact, all Pin-access mnemonics could follow that rule, for clarity.
That just leaves the suffix part, of mode, setx, sety,read,ack
Of those, mode,read,ack seem self-explaining, which only leaves setx, sety sounding like Graphics/pixel commands ?
What would be clearer for those 2 ?
I'm a 68k kind of gal, myself, so D on the right for all instructions would suit me just fine. :P ... Seriously, though, I'm with Searith and Spud on reasoning. Consistency is more important than what is really only a perceived untidiness.
I'm a 68k kind of gal, myself, so D on the right for all instructions would suit me just fine. :P ... Seriously, though, I'm with Searith and Spud on reasoning. Consistency is more important than what is really only a perceived untidiness.
I agree and the D,S. It should stay the same. Maybe the mnemonics could improve, though.
I found a few things to fix and tune up along the way, and it seems to all be in order now.
Hopefully, I will get new FPGA files out tomorrow.
Over the next few days, I will be working on the smart pin documentation. I'm anxious to see what you guys think of smart pins. At this early point, I see they can do a lot of things, but I don't have the usage experience, yet, to know quite how this reshapes the programming mindset that we are used to. It's a new frontier, of sorts.
Comments
Reciprocal Counting is simple:
You measure some whole number of cycles, and time how long that whole number of cycles takes.
Frequency = wCycles/wTime
Those two measurements are certainly not independently, nor are they asynchronously to the signal , so both your assertions are incorrect.
It is very important they run concurrently, otherwise you have no idea how many cycles wTime relates to, and they also must be Captures done synchronously to the signal, in order to know you have whole cycles.
Plus, you need care to be sure the same edge is used, and at high frequencies SW alone is not enough to do that. HW support can be as simple as a FlipFlop, but something is needed & aperture effects need attention.
Try some numbers on 'independent, and asynchronous' captures, and see how that goes.
Parallel flip-flops, one for each method of measure, is fine for capturing the same edge in parallel. If the edge rate is faster than the system clock then aliasing occurs and neither system works.
There is always potential for a particular edge to fall on either side of the system clock sampling but that noise accumulates out over time. It doesn't matter if one circuit see it one way and the other circuit see it the other way for a particular sample. That's all within the normal sampling noise limits.
However, I think this will not be an issue, as I expect all Smart pins have a Sampling FF per pin.
(Some MCUs have two in series, that helps noise filtering, but does lower the change-rate)
That means there is a single path across the clock domains, for a single pin.
Chip may be able to confirm Pin sampling FF details ?
(This FF is separate from the Capture trigger FF I mention.)
And even if there was a clock, like with ADC bitstreams, it is only an optional feature for power efficient/easy transfer. The signal is still analogue in nature so can be happily up-sampled.
In the teaching I had, going from ASYNC to SYNC, certainly counts as clock domain crossing.
Any time the edges are not same-clock aligned, you need care, a second clock wire is not a prerequisite to need that care, all it needs is for the edge to be derived from another clock, (or subject to uncertain delays).
When a smart pin completes some task, it signifies by raising its IN signal and updating its 32-bit result value which can be read by the PINREAD instruction. The result value is conveyed four bits per clock and the system counter's three LSBs are used to mux the eight nibbles as they go out. The bug is that IN signals right away, while the result value starts coming up to 7 clocks later, while the cog needs to begin inputting on a certain 8th system counter value. This causes old values to be read right after IN goes high.
To fix this, I'm going to add a fifth bit to the return value mechanism, so that the smart pin can signal right away when a new value is coming. This will save a net 28 flops in each smart pin and get result values back to cogs deterministically from IN rise, as the system counter won't be needed, anymore, to coordinate the messaging.
Tubular, you were rather young in the Osborne days, weren't you?
I still love mono green. My first PC was a IBM compatible Commodore PC 10 with one floppy drive (before color, affordable Hard Drives etc) with a green Mono screen. Yea, back in the good old days
So we have a net of 28 flops in each smart pin available . What feature can we add now ? LOL
Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.
The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"
My old Parallax friend/cofounder Lance told this story once, about budgeting:
"I wanted to get a new TV, so a decided I'd spend $100. I got to the store and saw a really nice TV for $500. I realized that was too expensive, but I found another pretty good one for only $300. So, I bought that one and SAVED $200."
I learned the same way, but on an Apple ][ that my dad would bring home from work on the weekends. Boy, everything was so new and engrossing back then. There are still new frontiers, but it seems like it takes a long hike to get to them.
In order to keep the cog from hanging on potential continuously-overlapping new messages, since they now start asynchronously, the message sender in the smart pin skips any new message when the current message hasn't shifted out all the way at least once. This could have been a problem if you were measuring states that were occurring faster than the message sending, which takes 8 clocks. Meanwhile, the smart pin keeps resending the current message, so that the cog can get it whenever it's ready to. A new message can occur at any time and the smart pin just sets that 5th bit that signifies start-of-message, for one clock, in order to tell the cog to reset its nibble counter, so it will tack the current nibble onto the incoming 7, in order to get the whole 32-bit value. In case a smart pin is not configured and you try to read it, you will just get $00000000, because 8 clocks will elapse without getting that 5th-bit pulse, and the smart pin clears its nibble output when disabled.
I don't know why I didn't anticipate this message/IN phase problem the first time around, but it's nailed now.
For what it's worth, here is the Verilog in the smart pin than sends out messages:
// message output reg [36:0] msg; wire msgr = msg[34:32] == 3'b111 && m_smart; // restart-of-message flag with cancel wire [3:0] msgi = {msg[35], 3'b0} | msg[34:32] + 3'b001; // message-sent flag and nibble counter wire [31:0] msgd = {msg[3:0], msg[31:8], msg[7:4] & {4{m_smart}}}; // data shifter with cancel always @(posedge clk) if (m_smart || msg[36] || (|msg[3:0])) // update if smart pin mode or outputs not 0 msg <= msgi[3] && signal_ ? {1'b1, 4'b0, result_} // start new message if current message sent : {msgr, msgi, msgd}; // update flags and shift data assign pin_msg = {msg[36], msg[3:0]}; // output start flag and message nibblem_smart = smart pin mode active
signal_ = capture result_ for message output and raise IN to alert cog(s)
result_ = 32-bit data to be captured and sent as message (repeatedly, until a new signal_ event)
Ha!
My dad had brought the luggable along when we were visiting family for Christmas (I'm guessing I was about 10 at the time). While we were there, I wrote my first real program, which simply output an increasing frequency on the speaker until you pressed the space bar. It would then print out the frequency. The idea was to press the space bar when you couldn't hear the sound any more. The entire family, young and old, took turns seeing what their hearing range was.
One thing that has me kind of wishing for a better way are the mnemonics and operand conventions for these smart pin instructions.
Here is what we have:
Simple enough, but it's too bad that the pin number winds up all over the place, horizontally.
It makes me think that swapping D and S, as far as source code goes, might be a good idea:
That would be kind of confusing, though, for development tool makers and also the PINREAD instruction, as D-to-be-written would be on the right.
Maybe the mnemonics could improve, too.
This may not be too much of an concern if constants are used instead of literals:
But don't ask for new mnemonics! You should know by now that there will be days (weeks?) of debate and no consensus!
In my mind, your second group works for all except 'pinread'. It each instruction, the D field should be the pin# because the pin is the destination of the MODE, SETX, SETY and ACK.
For 'pinread #14,pinval' it is anomalous like wrbyte/wrword/wrlong. So it can be made analogous to them. It becomes
wrpin #14,pinval
where you are writing the value of the pin to memory sort of like you are writing from COG to HUB with the wrxxxx instructions.
That would be a good way to do it, but a little tricky on the brain.
Now, you were joking about the alignment, right?
This winding up problem I simply solve this way:
Reversing D seems unwise.
To me this is best... except the pinread... to be consistent with all other reads... it should be
That makes sense, but you should list all pin access opcodes, and have them consistent across all that apply to pins.
D & S have less meaning when not registers, and PIN is first in the name.
They all start with PIN, which seems sensible and makes them easy to find.
In fact, all Pin-access mnemonics could follow that rule, for clarity.
That just leaves the suffix part, of mode, setx, sety,read,ack
Of those, mode,read,ack seem self-explaining, which only leaves setx, sety sounding like Graphics/pixel commands ?
What would be clearer for those 2 ?
I agree and the D,S. It should stay the same. Maybe the mnemonics could improve, though.
I found a few things to fix and tune up along the way, and it seems to all be in order now.
Hopefully, I will get new FPGA files out tomorrow.
Over the next few days, I will be working on the smart pin documentation. I'm anxious to see what you guys think of smart pins. At this early point, I see they can do a lot of things, but I don't have the usage experience, yet, to know quite how this reshapes the programming mindset that we are used to. It's a new frontier, of sorts.