How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Hi Chip.
I se You made nice progress on new chip architecture.
And many good decisions so I think it is not so much time before we can play with it.
I should have FPGA images before much longer. Eventually, we will open-source the Verilog, but I want to make sure that our first source release is bug-free and in good, proven order.
I'm glad you're still around, as well as everyone else!
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
Yes, CALLR is ok, - the objective here is to have the primary outcome clear to a casual ASM source reader.Users coming from other modern assemblers and MCUs need to follow as easily as possible.
Might CALLD be even better, since it implies the D register is getting used as the stack?
cgracey said:
How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
Yeah, I meant derive the timer IRQ from the counters in the Smartpins rather than actual physical pins. I should have been a little more verbose in original comment.
I thought of a way that pin interrupts could be no trouble, at all:
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
I thought of a way that pin interrupts could be no trouble, at all:
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
Sounds great.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
cgracey said:
How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
Yeah, I meant derive the timer IRQ from the counters in the Smartpins rather than actual physical pins. I should have been a little more verbose in original comment.
I understood what you were saying, but the problem was that the smart pins feed back through the same INA/INB bits, which could be spurious if not in smart mode. Problem solved with hold-off timer, though.
I thought of a way that pin interrupts could be no trouble, at all:
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
Sounds great.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
Thinking about the contents of Q, writen by the execution of SETQ instruction, and sequences that must be protected from being interrupted:
Due to the many ways it was intended to be used, are SETQ operations subjected to the same restrictions of ALTDS, AUGS and AUGD, and, of course, there must be a warning to position the SETQ instruction just before the one that will use the loaded Q value?
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
So that means most delays will be one opcode (system completes the current opcode)
but on some other (rare?) cases it can rake 2 or 3 opcodes, giving a spread of 2 instructions in 1~3 ?
Thinking about the contents of Q, writen by the execution of SETQ instruction, and sequences that must be protected from being interrupted:
Due to the many ways it was intended to be used, are SETQ operations subjected to the same restrictions of ALTDS, AUGS and AUGS and, of course, there must be a warning to position the SETQ instruction just before the one that will use the loaded Q value?
Yanomani
Yes, this is an issue. I am trying to figure out what to call the instruction(s) that block/allow the interrupt.
If you were going to do something with Q in your mainline code and Q was being used in the interrupt code, you would want to execute an instruction to block the interrupt in your mainline code until you finished using Q, after which you would unblock the interrupt. Practically, though, I don't think there's much occasion for using Q within your interrupt code.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
So that means most delays will be one opcode (system completes the current opcode)
but on some other (rare?) cases it can rake 2 or 3 opcodes, giving a spread of 2 instructions in 1~3 ?
(no pipelines to refill ? )
Yeah. Imagine there are AUGS and AUGD instructions that must satisfy some next instruction that must be waited for. Maybe 5 clocks in that case, because the instructions are on two-clock boundaries, while the interrupt event can occur in either phase of the instruction.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Wouldn't that type of housekeeping usually be done with flags/semaphores.That way the INT can fire but skip part of code if the Data is not yet updated.- ie some portions of INT may be needed to always run, others less often.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Wouldn't that type of housekeeping usually be done with flags/semaphores.That way the INT can fire but skip part of code if the Data is not yet updated.- ie some portions of INT may be needed to always run, others less often.
Yeah, it could be. I was thinking of minimizing what the interrupt code must make sense of.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Other than data protection, I can see more general use for Enable/Disable INT.
A coarse disable would be possible via reloading the buried register with a very large value, but there is a just-need-a-litte-more-time use case, where main loop code could request to complete, before INT and provided that was inside 2 INT delays-INT action time, you would not lose INT cadence.
Obviously there is added jitter, but code like RTC would run with no lost ticks, up to just under 2 int delays.
Another disable INT use, would be to to allow swap-in of a different INT routine.
Comments
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
JMP D uses LINK INA,D, where INA (read only) receives the unwanted return address, to no effect.
There's no need to differentiate mnemonics for the similar branches, because all constant addresses can fit in those JMP/CALL/CALLA/CALLB/LINK instructions at the end of the list, and the others just use D.
Hi Chip.
I se You made nice progress on new chip architecture.
And many good decisions so I think it is not so much time before we can play with it.
I should have FPGA images before much longer. Eventually, we will open-source the Verilog, but I want to make sure that our first source release is bug-free and in good, proven order.
I'm glad you're still around, as well as everyone else!
We have CALL, which uses a hardware stack, plus CALLA and CALLB which use PTRA and PTRB to call using hub RAM as stack. Maybe CALLR for register?
Yes, CALLR is ok, - the objective here is to have the primary outcome clear to a casual ASM source reader.Users coming from other modern assemblers and MCUs need to follow as easily as possible.
Might CALLD be even better, since it implies the D register is getting used as the stack?
cgracey said:
How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
Yeah, I meant derive the timer IRQ from the counters in the Smartpins rather than actual physical pins. I should have been a little more verbose in original comment.
cgracey said:
Might CALLD be even better, since it implies the D register is getting used as the stack?
D definitely. R is already used for reverse register order.
Might CALLD be even better, since it implies the D register is getting used as the stack?
Yup. Next question is the ASM operand order ... ?
CALL Address
CALLD Address,RegD
which probably leads to a matching mnemonic of
RETD RegD
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
Sounds great.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
cgracey said:
How about tying the IRQ to Smartpins instead of a dedicated timer.
Once you have a pulse-triggered logic working, it is relatively easy to clip in other sources (as Chip has done for initial testing !)However, I'd get it all working first with a (buried) Timer, and then look at other triggers later.The option of Trigger from a visible timer is an easy next step.
Do COGS still have local timers ? Or did that hop into a smart pin ?
No more generic CTRs in the cogs. Smart pins can do ADC/DAC/PWM/DUTY/etc now.
There is a transfer block that commutes data between pins, a LUT, and hub memory via fast reads and writes. It's sort of like a CTR, but only streams data. One-off functions will now be handled by smart pins.
Yeah, I meant derive the timer IRQ from the counters in the Smartpins rather than actual physical pins. I should have been a little more verbose in original comment.
I understood what you were saying, but the problem was that the smart pins feed back through the same INA/INB bits, which could be spurious if not in smart mode. Problem solved with hold-off timer, though.
Employ a hold-off count that limits how soon they can trigger again.
This solves the spurious retrigger problem and gets around all the normal interrupt-masking issues. Pin interrupts would be made as benign as timer interrupts. The programmer should know how often that pin might validly trigger, so he just sets the hold-off value to something a little below that. For example, if you were wanting to capture 1M baud serial and you were running at 160MHz, set the hold-off to 150 clocks. That way, your interrupt routine could time-stamp the transition and figure out what data is coming in, before some errant re-trigger is allowed to occur. Meanwhile, for serial output, you just do that in mainline code, waiting for time markers to pass to output your bits - serial receive interrupts are happening in the background the whole time. Then, you have 1MB serial running in the background.
INTPX D/# - interrupt on any edge of pin D/#, Q gets captured for hold-off countINTPR D/# - interrupt on rising edge of pin D/#, Q gets captured for hold-off countINTPF D/# - interrupt on falling edge of pin D/#, Q gets captured for hold-off count
As soon as any of those instructions are executed, an initial hold-off period ensues, after which the selected transition will trigger an interrupt. As soon as the event occurs, the hold-off period starts again. This, way, no train wrecks are possible, given the interrupt code finishes before the hold-off period.
Sounds great.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
Thinking about the contents of Q, writen by the execution of SETQ instruction, and sequences that must be protected from being interrupted:
Due to the many ways it was intended to be used, are SETQ operations subjected to the same restrictions of ALTDS, AUGS and AUGD, and, of course, there must be a warning to position the SETQ instruction just before the one that will use the loaded Q value?
Yanomani
My new board should be here any day. Checked the mail thee times today:)
Finally decided to leave the mailbox door open so that I would know when the mailman had been here.
Soooo happy.
Thanks
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
So that means most delays will be one opcode (system completes the current opcode)
but on some other (rare?) cases it can rake 2 or 3 opcodes, giving a spread of 2 instructions in 1~3 ?
(no pipelines to refill ? )
Thinking about the contents of Q, writen by the execution of SETQ instruction, and sequences that must be protected from being interrupted:
Due to the many ways it was intended to be used, are SETQ operations subjected to the same restrictions of ALTDS, AUGS and AUGS and, of course, there must be a warning to position the SETQ instruction just before the one that will use the loaded Q value?
Yanomani
Yes, this is an issue. I am trying to figure out what to call the instruction(s) that block/allow the interrupt.
If you were going to do something with Q in your mainline code and Q was being used in the interrupt code, you would want to execute an instruction to block the interrupt in your mainline code until you finished using Q, after which you would unblock the interrupt. Practically, though, I don't think there's much occasion for using Q within your interrupt code.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
They get captured into local cog registers, so there's no problem.
When you say
"That way, your interrupt routine could time-stamp the transition"
does that mean there is no jitter in the interrupt path ? (REP excluded)
There would be some jitter, but without REP or hub exec, it would be on the order of only two clocks, maybe. Wait, it would be two instructions. Make that four clocks. At 160Mhz, that's 25ns.
So that means most delays will be one opcode (system completes the current opcode)
but on some other (rare?) cases it can rake 2 or 3 opcodes, giving a spread of 2 instructions in 1~3 ?
(no pipelines to refill ? )
Yeah. Imagine there are AUGS and AUGD instructions that must satisfy some next instruction that must be waited for. Maybe 5 clocks in that case, because the instructions are on two-clock boundaries, while the interrupt event can occur in either phase of the instruction.
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Wouldn't that type of housekeeping usually be done with flags/semaphores.That way the INT can fire but skip part of code if the Data is not yet updated.- ie some portions of INT may be needed to always run, others less often.
That is in the sweet spot for short and memorable!
TIE
Can you also think of two names, one for enable and one for disable?
I like 2 instructions. Easy to understand
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Wouldn't that type of housekeeping usually be done with flags/semaphores.That way the INT can fire but skip part of code if the Data is not yet updated.- ie some portions of INT may be needed to always run, others less often.
Yeah, it could be. I was thinking of minimizing what the interrupt code must make sense of.
CZL- 1101011 000 CCCC 000000000 000110000 TIE (toggle interrupt enable, enable initially set by INTRO..INTPFCZL- 1101011 000 CCCC 000000000 000110001 INTOFF (disable interrupt)CZL- 1101011 000 CCCC 000000000 000110010 INTRO (enable interrupt on transfer rollover, allows background Goertzel)CZL- 1101011 000 CCCC 000000000 000110011 INTBW (enable interrupt on block wrap, allows background FBLOCK adjustments)CZL- 1101011 00L CCCC 000000000 000110100 INTX D/# (enable interrupt on every D/# clocks)CZL- 1101011 00L CCCC 000000000 000110101 INTPX D/# (enable any-edge interrupt on pin D/#, Q captured for hold-off count)CZL- 1101011 00L CCCC 000000000 000110110 INTPR D/# (enable pos-edge interrupt on pin D/#, Q captured for hold-off count)CZL- 1101011 00L CCCC 000000000 000110111 INTPF D/# (enable neg-edge interrupt on pin D/#, Q captured for hold-off count)
And a FIFO one!
Block/allow instructions would be more needed for data structures that you don't want the interrupt code to see in intermediate states.
I'm kind of leaning towards one instruction which toggles the interrupt blocking, but it's hard to think of a name for.
Other than data protection, I can see more general use for Enable/Disable INT.
A coarse disable would be possible via reloading the buried register with a very large value, but there is a just-need-a-litte-more-time use case, where main loop code could request to complete, before INT and provided that was inside 2 INT delays-INT action time, you would not lose INT cadence.
Obviously there is added jitter, but code like RTC would run with no lost ticks, up to just under 2 int delays.
Another disable INT use, would be to to allow swap-in of a different INT routine.