andn dira, #smartmask 'disable smartpins
wrpin ##(1<<24 | %01_11100_0), #tpin 'sync serial mode, Bin = tpin+1
wrpin #%01_00101_0, #tpin+1 'transion mode, used for sync clock
wrpin ##(1<<16 | 1<<7), #tpin+2 'OTHER inverted, used for comparing clocked I/O
wxpin #7, #tpin '8 bits for serial output
wxpin #10, #tpin+1 '1 MHz serial clock on 20 MHz sysclock
or dira, #smartmask 'enable smartpins
.loop
wypin #$55, #tpin 'regular toggling of the serial pin
wypin #4, #tpin+1 '4 transitions: 2 bits shifted out on serial pin
waitx #100 'give hardware some time to action
jmp #.loop 'repeat, refilling the serial buffer if empty
The reaffirming issue here is that with the latest v33i FPGA at 80 MHz it still leaps another clock the same way as my much older measurements using software and GETCT.
What exactly does 'it still leaps another clock' mean ?
Do you mean the delay varies and jitters, or that it is a fixed delay, but with an unexpected added sysclk ?
I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.
I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.
Did Clock gating make the cut in the revisions ?
What about ClkOut = SysCLK option, for the streamer ?
I talked to Wendy at ON Semi today and we discussed establishing timing constraints for all of the asynchronous input and output signals. We intend to bind their timing together so that the pins all behave very similarly. We'll make them go as fast as possible, of course.
Did Clock gating make the cut in the revisions ?
What about ClkOut = SysCLK option, for the streamer ?
Last I heard from Wendy, almost 2,000 clock gates had been synthesized into the design. This should result in a huge power savings. The current silicon has no clock gates.
I don't think we are going to get a full-speed clock output, unless the occasion arises for resynthesis. In getting everything else together, I did not incorporate this feature into the current verilog. If we need to resynthesize, there will be opportunity, but things are pushing fast now towards completion. At the moment, I'm simulating the PLL to discover what can be done to improve it.
.... At the moment, I'm simulating the PLL to discover what can be done to improve it.
Did you simulate yet, the XIN to PFD path delays, with varying Xtal amplitudes ?
Measurements show ten+ ns of temperature dependent skew occurring between external clock and final PLL.
That's bad for a couple of reasons :
a) It means external master clock designs will not hold phase, which users will expect.
b) It means the PFD sense point, can sweep across a sysclk boundary in some temperature zones.
That boundary crossing will certainly worsen jitter, and it fits the symptoms observed of jitter being temperature zone related.
Ideally, the Counter to PFD and Xtal to PFD paths should match in delays, and delay variations. That reduces phase walking to well under a Sysclk.
Xtal paths may be somewhat Xtal amplitude dependent, and a schmitt buffer may make that delay more controlled and fixed.
Chip & others,
I am seeing what appears to be multiple powerup restarts when plugging in to USB for power.
Can you (or others) possibly check this on a scope by looking at the pullup sampling on a scope to confirm this please?
There is no brownout protection on the P2. Maybe we need some form of powerup delay in either hardware or ROM software delay to prevent this ???
On P2-Eval there are 2 Reset generators, joined to the P2 Reset via the OD DIPSw.
I think the next P2D2 was getting reset managed by the EFM8 MCU, not sure how that works around 1V ramping ?
It's certainly doing a merry dance here on Win10, when you first plug in !!
Here is Silabs CP2102N and FTDI FT231X on other boards....
Interesting they both have 6 hi pulses, but the P2 board shows some tristate action in there, due to different pullups/loads.
Appears pullup is always strong, but pulldown can sometime be weaker, as the driver shuffles about ?
Takes ~4.3 seconds to finally settle, not much a ROM can do about that.
Maybe there is a means to kill that dance ?
Ahh, seems to settle down, if I dig deep enough...
FTDI Advanced Driver Options AN_107 Application Note AN_107 Version 2.53
"Note that if the "Serial Enumerator" option in the property page is selected, then the enumeration sequence causes the modem control signals to change at startup.
So if it is necessary to select "Disable Modem Ctrl At Startup", then it is likely that "Serial Enumerator" should be unchecked in the property page."
Yes, that 3v3 is not good. I haven't looked closely, but wasn't there an alternative non-switcher 3v3 on the P2-EVAL? If so, is this any better?
At least I now know why I am seeing the multiple reboots which was causing me concern with the SD driver.
I have another question. Could you scope for me the following please?
How long it takes for a pullup test with 5K, 10K and 15K to return high after being pulsed low. (or 4K7, 10K, 14K7 or 15K)
How long it takes for a pulldown test with 5K, 10K and 15K to return low after being pulsed high.
Don't set a crystal frequency - ie use rcfast.
Here is sample code
Background: I had left a 4K7 pulldown on P58 and discovered it was interfering with my SD read reply. Forgot I had a resistor left on this pin from some testing and I went looking for an SD boot bug. It is obviously slowing the response and I wanted to see how much it slows the prop. Of course it's the SD cards DO pin driving the line.
Thanks.
I have another question. Could you scope for me the following please?
How long it takes for a pullup test with 5K, 10K and 15K to return high after being pulsed low. (or 4K7, 10K, 14K7 or 15K)
How long it takes for a pulldown test with 5K, 10K and 15K to return low after being pulsed high.
Don't set a crystal frequency - ie use rcfast.
Here is sample code
Background: I had left a 4K7 pulldown on P58 and discovered it was interfering with my SD read reply. Forgot I had a resistor left on this pin from some testing and I went looking for an SD boot bug. It is obviously slowing the response and I wanted to see how much it slows the prop. Of course it's the SD cards DO pin driving the line.
Just be careful here because the Pin number might matter - when we did previously scope caps of this the pins that were also used for Onsemi JTAG checking seemed to have additional loading. These were low pins less than P15 from memory, with a few gaps in amongst them
@jmg
Are you able to scope pins with 4K7 or 5K ,10K and 14.7K or 15K pullup and pulldown please. P56 & P57 would be nice but not mandatory. I need to know how long it takes for the pin to return to the pulled up or down state.
I noticed a problem when P58 (SD DO) had a 4K7 pulldown.
Ah, just adding the scope probes on doubles the software measurements!
EDIT: Okay, I'm seeing a negative glitch on the pulldown when doing a DIRL tristate after DRVH+WAITX. Discharge curve starts at about 2.5 volts instead of 3.3. EDIT2: Doesn't seem to have a great impact on the measurement though.
I am really interested to see the results graphed on either P2D2 or P2-EVAL because I was getting errors when reading the SD card when there was a 4K7 pulldown on P58 (the DO output from the SD card) which I had forgotten I had added a while ago. Everything was fine on the ROM SD code, but not when I loaded it manually (slight timing difference in old code).
Never-the-less, I wanted to see the effects on this on a scope to ensure that everything is within parameters for the ROM code.
wrpin ##1<<16, tpin 'turn off any smartpin mode and enable clocked I/O
drvl #tpin 'lower the pull up
waitx sec 'set for 1 microsecond
setse1 #(1<<6 | tpin) 'event set to rising edge of tpin
dirl #tpin 'tristate
getct tickstart 'start measuring
waitse1
getct pa 'stop measuring
sub pa, tickstart
call #itod 'report
They're pretty ordinary except for the tiny glitch on the two pull-down snaps.
EDIT: I guess the oddity is that, because of the glitch, the down curve crosses 1.65 volts in half the time of the up curve but this doesn't show up in the software measurement.
Comments
What exactly does 'it still leaps another clock' mean ?
Do you mean the delay varies and jitters, or that it is a fixed delay, but with an unexpected added sysclk ?
Did Clock gating make the cut in the revisions ?
What about ClkOut = SysCLK option, for the streamer ?
Last I heard from Wendy, almost 2,000 clock gates had been synthesized into the design. This should result in a huge power savings. The current silicon has no clock gates.
I don't think we are going to get a full-speed clock output, unless the occasion arises for resynthesis. In getting everything else together, I did not incorporate this feature into the current verilog. If we need to resynthesize, there will be opportunity, but things are pushing fast now towards completion. At the moment, I'm simulating the PLL to discover what can be done to improve it.
Did you simulate yet, the XIN to PFD path delays, with varying Xtal amplitudes ?
Measurements show ten+ ns of temperature dependent skew occurring between external clock and final PLL.
That's bad for a couple of reasons :
a) It means external master clock designs will not hold phase, which users will expect.
b) It means the PFD sense point, can sweep across a sysclk boundary in some temperature zones.
That boundary crossing will certainly worsen jitter, and it fits the symptoms observed of jitter being temperature zone related.
Ideally, the Counter to PFD and Xtal to PFD paths should match in delays, and delay variations. That reduces phase walking to well under a Sysclk.
Xtal paths may be somewhat Xtal amplitude dependent, and a schmitt buffer may make that delay more controlled and fixed.
I am seeing what appears to be multiple powerup restarts when plugging in to USB for power.
Can you (or others) possibly check this on a scope by looking at the pullup sampling on a scope to confirm this please?
There is no brownout protection on the P2. Maybe we need some form of powerup delay in either hardware or ROM software delay to prevent this ???
On P2-Eval there are 2 Reset generators, joined to the P2 Reset via the OD DIPSw.
I think the next P2D2 was getting reset managed by the EFM8 MCU, not sure how that works around 1V ramping ?
It's certainly doing a merry dance here on Win10, when you first plug in !!
Here is Silabs CP2102N and FTDI FT231X on other boards....
Interesting they both have 6 hi pulses, but the P2 board shows some tristate action in there, due to different pullups/loads.
Appears pullup is always strong, but pulldown can sometime be weaker, as the driver shuffles about ?
Takes ~4.3 seconds to finally settle, not much a ROM can do about that.
Maybe there is a means to kill that dance ?
FTDI Advanced Driver Options AN_107 Application Note AN_107 Version 2.53
"Note that if the "Serial Enumerator" option in the property page is selected, then the enumeration sequence causes the modem control signals to change at startup.
So if it is necessary to select "Disable Modem Ctrl At Startup", then it is likely that "Serial Enumerator" should be unchecked in the property page."
This is showing what I am seeing with the LED flashing program being booted from SD.
Are you able to do the same test with DTR disconnected, or just have power connected?
This is the Power Up captures, using the other USB connector. (so no DTR applied, just voltages)
Interesting, the 3v3 struggles and is not monotonic, which would make a reset generator quite important.
1V8 has no such issues ?
Yes, that 3v3 is not good. I haven't looked closely, but wasn't there an alternative non-switcher 3v3 on the P2-EVAL? If so, is this any better?
At least I now know why I am seeing the multiple reboots which was causing me concern with the SD driver.
I have another question. Could you scope for me the following please?
How long it takes for a pullup test with 5K, 10K and 15K to return high after being pulsed low. (or 4K7, 10K, 14K7 or 15K)
How long it takes for a pulldown test with 5K, 10K and 15K to return low after being pulsed high.
Don't set a crystal frequency - ie use rcfast.
Here is sample code
orgh 0 org 0 drvl #0 ' P0 with pullup drvh #1 ' P1 with pulldown waitx #30 ' ~1us fltl #0 flth #1 jmp #$Background: I had left a 4K7 pulldown on P58 and discovered it was interfering with my SD read reply. Forgot I had a resistor left on this pin from some testing and I went looking for an SD boot bug. It is obviously slowing the response and I wanted to see how much it slows the prop. Of course it's the SD cards DO pin driving the line.
Yes, that's the plot label ending with 3v3LDO, powering the PLL pins in this case.
I updated my previous post with some more questions. Could you take a look please?
Just be careful here because the Pin number might matter - when we did previously scope caps of this the pins that were also used for Onsemi JTAG checking seemed to have additional loading. These were low pins less than P15 from memory, with a few gaps in amongst them
Are you able to scope pins with 4K7 or 5K ,10K and 14.7K or 15K pullup and pulldown please. P56 & P57 would be nice but not mandatory. I need to know how long it takes for the pin to return to the pulled up or down state.
I noticed a problem when P58 (SD DO) had a 4K7 pulldown.
PS: Pins 55 to 57 don't work though, they are held high by something. Possibly Chip hasn't got everything configured right for the 33i FPGA files.
I think those pins, 55 through 57, read three of the push buttons.
EDIT: Okay, I'm seeing a negative glitch on the pulldown when doing a DIRL tristate after DRVH+WAITX. Discharge curve starts at about 2.5 volts instead of 3.3. EDIT2: Doesn't seem to have a great impact on the measurement though.
Never-the-less, I wanted to see the effects on this on a scope to ensure that everything is within parameters for the ROM code.
i am interested is seeing the graph.
I can do the pin reading and ive done it before.
EDIT: I guess the oddity is that, because of the glitch, the down curve crosses 1.65 volts in half the time of the up curve but this doesn't show up in the software measurement.