I couldn't read the current with my meter but it looks like it is less than 100na although I should be able to use a very high resistance pulldown to work out what the current is. but that might need a 100M resistor!
This is a quick test in TAQOZ showing the pin going high a little while after I float it:
TAQOZ# 32 LOW 32 FLOAT BEGIN 32 PIN@ 1 AND . KEY UNTIL 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000001010101111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
I couldn't read the current with my meter but it looks like it is less than 100na although I should be able to use a very high resistance pulldown to work out what the current is. but that might need a 100M resistor!
This is a quick test in TAQOZ showing the pin going high a little while after I float it:
TAQOZ# 32 LOW 32 FLOAT BEGIN 32 PIN@ 1 AND . KEY UNTIL 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000001010101111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111
Well, that's not a bad thing. It means that the input inverter won't be biased around the midpoint, causing current draw.
Then there must be some slight leakage to VIO, probably in the nano amp range.
Does the boot loader exit with a light pullup as default on all pins, or do all pins float ?
The pins are floating.
Is that a good idea ?
It means floating during the whole boot time, so any critical pins will need PCB resistors added to define their states, something users might find out rather late in the design flow...
Maybe there is no way around this, if the pins float during RESET and reset exit ?
Reports seem to be P2 pins 'float' lightly high, but very lightly.... May just be all the VIO traces nearby ?
The pins all float during reset and then until they are configured to drive.
It seems to me that pulling either high or low during that time is making some possibly unwelcome assumptions about what people are doing with the chip.
There must be some very slight leakage in either the P clamp diodes or the PFET drivers.
Some interesting results with the pins when tri-state...
Using OUTA and DIRA with the streamer reading the pins (testing P8-15 on P2D2)
Before setting the pins, the streamer reads all pins as all 1's
When OUTA sets all 0's before tri-stating with DIRA, the streamer reads the pins as all 0's.
When OUTA sets all 1's before tri-stating with DIRA, the streamer reads the pins variously (often $43 or $47)
From reset,
DRVL pins 7 & 6 & 5, the streamer reads pins 7 & 6 & 5 as 0's AND 4 as 0 too. But pin 4 does not drive an LED attached, so it is effectively tri-state.
From this, I would say floating pins read as undefined, unlike the P1 where we can reliably say they read 0.
Some interesting results with the pins when tri-state...
Using OUTA and DIRA with the streamer reading the pins (testing P8-15 on P2D2)
Before setting the pins, the streamer reads all pins as all 1's
When OUTA sets all 0's before tri-stating with DIRA, the streamer reads the pins as all 0's.
When OUTA sets all 1's before tri-stating with DIRA, the streamer reads the pins variously (often $43 or $47)
From reset,
DRVL pins 7 & 6 & 5, the streamer reads pins 7 & 6 & 5 as 0's AND 4 as 0 too. But pin 4 does not drive an LED attached, so it is effectively tri-state.
From this, I would say floating pins read as undefined, unlike the P1 where we can reliably say they read 0.
When you tristate all those pins, OUT goes low before DIR in many cases, causing the pins to variously drive downward before floating. This is the problem we've been having with the boot pins. Given time, those pins may blow in the electrical field breeze or settle low or high. From what some have said, pins seems to float high over time.
In the short form
MODCZ/MODZ _SET/_CLR {WC/WZ/WCZ}
I see the WC/WZ is still required. Seemed to me that this is implied by the short form instruction and that the WC/WM modifier should not be required.
Perhaps an ever shorter form might be better
MODZSET, MODZCLR, MODCSET, MODCCLR ?
I made it so that you can always scan the outer right column and find the WC/WZ/WCZ effects to know quickly where the flags are being affected. The only exceptions are the return/resume-from-interrupt instructions.
Chip,
What do you think is the best way to replace the P1 REV instruction?
I am thinking in an automated conversion program where you don't know it's usage.
Chip,
What do you think is the best way to replace the P1 REV instruction?
I am thinking in an automated conversion program where you don't know it's usage.
Thanks Chip. I kept overthinking the S value in P1 as needing to be subtracted from 32
CALLD INx,IRETx
I have been thinking about the way interrupts work and other uses of the calls.
What was interesting is the use of INA/INB as write only (shadow) registers. Got me thinking...
Wouldn't the RETIx/RESIx instructions corrupt INA/INB when they are use as the Debug Registers ???
I am presuming that the write to INA/INB actually takes place when the RETIx/RESIix instructions (which are CALLD INB,IRETx instructions?
Tricks
So my trick that I expect will work is this...
For normal instructions that in reality work on a single operand, such as NEG, MOV, etc, can simulate the "NR" feature of the P1 and set Z & C flags.
The caveat is you cannot be using Debug Interrupts in this cog.
Wouldn't the RETIx/RESIx instructions corrupt INA/INB when they are use as the Debug Registers ???
I am presuming that the write to INA/INB actually takes place when the RETIx/RESIix instructions (which are CALLD INB,IRETx instructions?
During debug INA/INB become debug status registers.
The pin states can be switched in/out during interrupt using SETBRK
Ran some frequency tests across 2 boards, temperature points -40C and 25C
12-Nov-18
P2 OSC FREQ CHECKS AT DIFFERENT TEMPERATURES
34461A meter in freq mode, 10V range, >20Hz AC filter, 100ms gate time
/1000 P2 CODE (ie MHz becomes kHz,
BOARD# OSC FREQ AT -40C FREQ AT 25 C
1 RCSLOW 26700 20460
2 RCSLOW 26600 20555
1 RCFAST 23281000 23650000
2 RCFAST 23193000 23600000
Ran some frequency tests across 2 boards, temperature points -40C and 25C
12-Nov-18
P2 OSC FREQ CHECKS AT DIFFERENT TEMPERATURES
34461A meter in freq mode, 10V range, >20Hz AC filter, 100ms gate time
/1000 P2 CODE (ie MHz becomes kHz,
BOARD# OSC FREQ AT -40C FREQ AT 25 C
1 RCSLOW 26700 20460
2 RCSLOW 26600 20555
1 RCFAST 23281000 23650000
2 RCFAST 23193000 23600000
Here's some captures of some ADC bitstreams.
You can see the sequential configuration of the pin mode.
Three captures showing GIO,VIO and PinA 1x mode.
One thing I observed is as each ADC was enabled the current rises ~800uA @ 80 Mhz and ~1.2mA per pin @ 250 MHz. I will collect more data on this.
I'm not sure what I'm more excited about seeing; the bitstreams, or the tool that views them at 1 horizontal pixel per clock.
Great to have your P2 based logic analyzer working again
Yes, that is super useful.
I've been thinking about a logic-analyzer mode for the streamer that will only write on changes and store 16 pins with a 16-bit timestamp. If it times out at 2^16 clocks, it issues the same data with $0000 for time. If no changes were occurring, it would write one long every 2^16 clocks. At 250MHz, that's only 15KB per second.
At the present construction, is it imperative for the write pointer to keep advancing, even in cases were input data persists, sample after sample?
Because, if captured data persists, its value keeps the same as the last captured value, when the last change was observed.
This could free the sampling bits to further expand the "no new activity being perceived" counter, further reducing memory bandwidht needs.
Only a thought...
Yes!!! We could use the LSB of the time to indicate 'no change', in which case the timestamp is 31 bits. So, it would only take one long every 8.59 seconds. That could get pretty boring.
Comments
This is a quick test in TAQOZ showing the pin going high a little while after I float it:
Well, that's not a bad thing. It means that the input inverter won't be biased around the midpoint, causing current draw.
Is that a good idea ?
It means floating during the whole boot time, so any critical pins will need PCB resistors added to define their states, something users might find out rather late in the design flow...
Maybe there is no way around this, if the pins float during RESET and reset exit ?
Reports seem to be P2 pins 'float' lightly high, but very lightly.... May just be all the VIO traces nearby ?
It seems to me that pulling either high or low during that time is making some possibly unwelcome assumptions about what people are doing with the chip.
There must be some very slight leakage in either the P clamp diodes or the PFET drivers.
Using OUTA and DIRA with the streamer reading the pins (testing P8-15 on P2D2)
Before setting the pins, the streamer reads all pins as all 1's
When OUTA sets all 0's before tri-stating with DIRA, the streamer reads the pins as all 0's.
When OUTA sets all 1's before tri-stating with DIRA, the streamer reads the pins variously (often $43 or $47)
From reset,
DRVL pins 7 & 6 & 5, the streamer reads pins 7 & 6 & 5 as 0's AND 4 as 0 too. But pin 4 does not drive an LED attached, so it is effectively tri-state.
From this, I would say floating pins read as undefined, unlike the P1 where we can reliably say they read 0.
When you tristate all those pins, OUT goes low before DIR in many cases, causing the pins to variously drive downward before floating. This is the problem we've been having with the boot pins. Given time, those pins may blow in the electrical field breeze or settle low or high. From what some have said, pins seems to float high over time.
With 10K pullup on pin 30...
DRVL
WAITX 1us
FLTL or FLTH
At 20MHz, pin 30 pulls high within 1-2 clocks
At 200MHz, pin 30 takes an extra 15 clocks, so ~75ns to be pulled high
With 10K pulldown on pin 30...
DRVH
WAITX 1us
FLTL or FLTH
At 20MHz, pin 30 pulls low within 2-3 clocks
At 200MHz, pin 30 takes an extra 17 clocks, so ~85ns to be pulled low
Try some other pins. Due to the glitching, you should get faster pull-downs, combined with slower pull-ups, on some.
Not the silicon, but pnut compiler.
In the short form
MODCZ/MODZ _SET/_CLR {WC/WZ/WCZ}
I see the WC/WZ is still required. Seemed to me that this is implied by the short form instruction and that the WC/WM modifier should not be required.
Perhaps an ever shorter form might be better
MODZSET, MODZCLR, MODCSET, MODCCLR ?
But that's for another day
I agree.
What do you think is the best way to replace the P1 REV instruction?
I am thinking in an automated conversion program where you don't know it's usage.
You need to do a SHL+REV or a REV+SHR.
CALLD INx,IRETx
I have been thinking about the way interrupts work and other uses of the calls.
What was interesting is the use of INA/INB as write only (shadow) registers. Got me thinking...
Wouldn't the RETIx/RESIx instructions corrupt INA/INB when they are use as the Debug Registers ???
I am presuming that the write to INA/INB actually takes place when the RETIx/RESIix instructions (which are CALLD INB,IRETx instructions?
Tricks
So my trick that I expect will work is this...
For normal instructions that in reality work on a single operand, such as NEG, MOV, etc, can simulate the "NR" feature of the P1 and set Z & C flags.
The caveat is you cannot be using Debug Interrupts in this cog.
The pin states can be switched in/out during interrupt using SETBRK
%G: 1 = make INA/INB read pin states, not RAM
12-Nov-18
P2 OSC FREQ CHECKS AT DIFFERENT TEMPERATURES
34461A meter in freq mode, 10V range, >20Hz AC filter, 100ms gate time
/1000 P2 CODE (ie MHz becomes kHz,
BOARD# OSC FREQ AT -40C FREQ AT 25 C
1 RCSLOW 26700 20460
2 RCSLOW 26600 20555
1 RCFAST 23281000 23650000
2 RCFAST 23193000 23600000
I make that
SLOW tempco :
((26700/20460)-1)/(25+40) = -30.49% = -0.469 %/°C
((26600/20555)-1)/(25+40) = -29.41% = -0.452 %/°C
FAST tempco :
(1-23281000/ 23650000)/(25+40) = 1.560% = +240 ppm /°C
(1-23193000/23600000)/(25+40) = 1.724% = +265 ppm /°C
Sample to sample variation
FAST: 1-(23281000/23193000) = 0.379% Cold 1-23650000/23600000 = 0.212% Room temp
SLOW: 1-26700/26600 = 0.376% cold 1-20460/20555 = 0.462% Room temp
Not a large sample set, but looking quite good overall there.
You can see the sequential configuration of the pin mode.
Three captures showing GIO,VIO and PinA 1x mode.
One thing I observed is as each ADC was enabled the current rises ~800uA @ 80 Mhz and ~1.2mA per pin @ 250 MHz. I will collect more data on this.
Here's the code snippet to set 16 pins to ADc mode. Is there a reason why the bitstream time to start from config varies as shown in this capture.
That routine you've got there will become one or two instructions in the next rev of the silicon.
Ok + Cool
Great to have your P2 based logic analyzer working again
Yes, that is super useful.
I've been thinking about a logic-analyzer mode for the streamer that will only write on changes and store 16 pins with a 16-bit timestamp. If it times out at 2^16 clocks, it issues the same data with $0000 for time. If no changes were occurring, it would write one long every 2^16 clocks. At 250MHz, that's only 15KB per second.
Because, if captured data persists, its value keeps the same as the last captured value, when the last change was observed.
This could free the sampling bits to further expand the "no new activity being perceived" counter, further reducing memory bandwidht needs.
Only a thought...
Can you post your latest logic analyzer code? I am eager totry it out
Yes!!! We could use the LSB of the time to indicate 'no change', in which case the timestamp is 31 bits. So, it would only take one long every 8.59 seconds. That could get pretty boring.