Shop Learn
Something rather strange in Pulse/Cycle Smartpin mode output - Page 3 — Parallax Forums

Something rather strange in Pulse/Cycle Smartpin mode output

13»

Comments

  • jmgjmg Posts: 14,820
    rogloh wrote: »
    jmg wrote:
    rogloh wrote: »
    If it is true that I don't have to drive RWDS low first before high after the address phase..
    If that means after the float time, you could always use a modest pull down, so the pin idles low, if that buys some sysclks ?
    Possibly helpful if the existing approach doesn't work out for some reason, though the Parallax board does not have this resistor - I guess it could be soldered on.

    Yanomani has suggested using the pin mode to select an internal pulldown, that should avoid PCB changes ?

  • jmgjmg Posts: 14,820
    rogloh wrote: »
    The only thing I can see that might be of concern is where the P2 enables its output beginning half way between clocks 3 and 4 as you can see where we come out of ti-state in the waveform below (yellow=RWDS, cyan=CLK). I can't easily delay this output further. If the HyperRAM has not shut off by then there will be contention.
    The octalRAM spec gives this from the 6th clock edge
    tDQSCK Clock transition to DQSM valid 2~7ns

    so looks like on a typical basis, you are just ok. Any contention will be timing-skew short, single digit ns ?


  • YanomaniYanomani Posts: 1,312
    edited 2020-02-20 03:57
    From the main memory aray access time standpoint, I believe it'll be ok doing some overclocking, but, from a DQ[7:0} and RWDS (if used as a write/no write discriminator) standpoint I believe some concerns will arrise.

    First, VccQ should be maintained at 3.0 V, as specc'd, and even taking that precaution, noise and crosstalk at the interface lines will start showing all its deleterious potential, and one should face the problem of having to switch to stripline-routing, abandomning the microstrip model. More GND planes, more layers, and cost.

    Can be done, but hardly at justifyable costs. Better increase the bus widht to 16, 24, or even 32 bits, with sound results in throughput, at manageable costs.

    P.S. With a 12-layered pcb, almost every P2 dream comes true, but the costs... Simply thrilling :cold_sweat:
  • evanhevanh Posts: 11,822
    edited 2020-02-20 04:08
    Yanomani wrote: »
    A cascade of fet switches (or level translators used as switches) can be used as a bucket-brigade, by feeding them with 3.3V, both sides, when they have dual power suplies.

    Each stage will introduce <300 pS of delay, but the numbers are not completelly deterministic, though stable within their opperational range.

    A simple 8-bit latch can bring a thermometer-alike control to the enable pins of the fet gates, so the ammount of delay can be dinamically managed and exercised.

    Following that line of thinking I decided to have a look for fast gates. The TinyLogic range fits. NC7SV34 looks good - https://www.onsemi.com/products/standard-logic/buffers/nc7sv34
    There is faster gates but I'm thinking 1.5 ns is right for Hyperbus v1.0.

    Put that on the accessory board for HR clock only. Then run all prop2 pins as registered.

  • But this one can reach 3.8 nS (-40°C to +85°C range; @3.3V); wouldn't it be too much for a 5nS/5nS, 100 MHz CK?
  • evanhevanh Posts: 11,822
    edited 2020-02-20 04:31
    Don't run it at 85 degC. And if you do, then don't use sysclock/1 data rate.

    PS: NC7SV125 is rated for 1.0 ns, if you think that's preferable - https://www.onsemi.com/products/standard-logic/buffers/nc7sv125

    PPS: I guess a small capacitor is about as good. I did try a 33 pF ceramic that was lying around, and it worked, although I have no idea the best value to use at this stage.

  • YanomaniYanomani Posts: 1,312
    edited 2020-02-20 04:51
    Trully better, including the fact it tops at 2.8 nS, same temp and voltage range as the other one.

    The low cost, tinny size and its minimum delay of 0.5 nS makes me wonder if it's not advisable to have at least 2 or even 3 of them, in a cascade.

    A solder jumper can be used to select how much delay is needed, to adjust for Hyper parts variations.

    Also, could leverage the use of an inverted CK, under software control at the smart pin level.

    Being able to adjust the phase of CK between 90° and 270° in respect to the start of the data bits can be a sure recipe to suceed in that kind of application.
  • jmg wrote: »
    rogloh wrote: »
    Possibly helpful if the existing approach doesn't work out for some reason, though the Parallax board does not have this resistor - I guess it could be soldered on.

    Yanomani has suggested using the pin mode to select an internal pulldown, that should avoid PCB changes ?
    Good call. I keep forgetting that the P2 can do internal pullups/pulldowns etc.

    There is a 10ohm resistor on the Parallax HyperRAM board that can help if there is transient contention. Also if we apply the same initial level based on the latency at the point when the signal comes on from the P2, we may avoid some of the actual contention as we will be driving close to the same output level as the HyperRAM did before it switches off, though this is a transient event too. Maybe we can use pullup/pulldown for high/low pin levels instead of full GPIO I/O power.
  • YanomaniYanomani Posts: 1,312
    edited 2020-02-20 05:10
    Both CK and RWDS parks at LOW level nicelly, so FLTL solves them. DQs can be wichever you choose. More options, more simplicity. :smile:

    P.S. On second thought, to avoid any possibility of undesired (though minimum) current flow at the Hypers DQ/RWDS I/O structure, IMHO, both should be parked at the same logic levels.
  • Yes the idle case for RWDS is good being low. Also if we use any pullups/pulldowns instead of full strength P2 pin outputs the transitions may not be fast enough for driving at the highest P2 clock rates unless they are rather low resistances and input capacitances. We don't want to introduce extra skew for the RWDS timing.
  • YanomaniYanomani Posts: 1,312
    edited 2020-02-20 05:28
    Any solution that can bring those 9 signals in unison, forward and backward, between the P2 and the Hypers can be considered a good one. P.S. (DQs + RWDS)...

    A rattle drum, knocking at anyone's door (ears) is the last thing a good (aka sound) interface needs to have.
  • evanhevanh Posts: 11,822
    edited 2020-02-22 05:18
    .Just done a few more tests of sysclock/1 using a couple more small capacitors. Results are pointing to some real gains to be made by designing a circuit board around a HyperRAM + Prop2 with low attenuation layout. ie: tightly arranged together.

    I'm able to, right now, at 3.3 Volts, consistently burst write data into the hyperram at up to 350 MT/s. That's exceeding even the 1.8 V rating!

    EDIT: I've reduced the capacitor value from 33 pF to 22 pF to get this fast. At 33 pF the sysclock limit was 230 MHz instead. But for 22 pF to work I also had to use an unregistered pin for the HR clock. Otherwise it wasn't enough phase shift on the clock signal.
  • evanhevanh Posts: 11,822
    edited 2020-02-22 05:31
    One question on my mind is the use of the capacitor for lagging the clock signal. When designing a circuit board, I don't have the confidence to say it's the best option - compared to one of those fast buffers say.

    There's no way I can measure the timings sadly. It would need an active probe and a faster scope than I have. Anyone else feel they've got the skills to characterise it further? I can help by cleaning up and documenting/explaining this testing code I've cobbled together. Err, scratch that, I don't have to be measuring it at 350 MT/s to see the lagging delay.
  • evanh wrote: »
    I'm able to, right now, at 3.3 Volts, consistently burst write data into the hyperram at up to 350 MT/s. That's exceeding even the 1.8 V rating!

    Wow that's pretty amazing. I am only doing sysclk/2 for writes in my driver right now and the clock is nicely centered in the middle of the data. Perhaps it could be done higher with a capacitor, though it does seem a bit board dependent. Something to think about later...
  • evanhevanh Posts: 11,822
    edited 2020-02-22 06:35
    rogloh wrote: »
    Something to think about later...
    Yes, aiming for it to have clear guidelines for board layout.

    It'll be the only reliable way. Notably, more so for reading data at speed. At the moment, reads at sysclock/1 have that crazy lagging slope that comes and goes at different frequencies.

  • evanhevanh Posts: 11,822
    edited 2020-02-22 11:59
    evanh wrote: »
    I don't have to be measuring it at 350 MT/s to see the lagging delay.
    Okay, got results:
    - Orange traces are hyper clock pin at the accessory header, P24
    - Blue traces are data bit#1 at the accessory header, P17

    Data and Clock pins both registered, no accessory board:
    dat-reg_clk-reg.PNG

    Data and Clock pins both registered, unmodified accessory board:
    dat-reg_clk-reg_0pF.PNG

    Data and Clock pins both registered, 22 pF capacitor attached to hyper clock at accessory header, P24:
    dat-reg_clk-reg_22pF.PNG

    Clock pin unregistered, no accessory board:
    dat-reg_clk-unreg.PNG

    Clock pin unregistered, unmodified accessory board:
    dat-reg_clk-unreg_0pF.PNG

    Clock pin unregistered, 22 pF capacitor attached to hyper clock at accessory header, P24:
    dat-reg_clk-unreg_22pF.PNG
    This last one has sufficient clock lag to provide the required data setup timing.

    640 x 480 - 8K
    640 x 480 - 8K
    640 x 480 - 8K
    640 x 480 - 8K
    640 x 480 - 8K
    640 x 480 - 8K
  • evanhevanh Posts: 11,822
    Ha, it's notable that the data trace has a natural slope shallower than the clock trace. It's particularly true once the accessory board is attached. And adding the capacitor brings the clock slope parallel to the data slope.

  • YanomaniYanomani Posts: 1,312
    edited 2020-02-22 14:06
    Hi evanh

    Since my 1990'ish, 40 MHz oscilloscope did perished long ago, flooded by Rio's moisty and salty atmosphere, every interface signal waveforms I can put my eyes on, acts like some refreshing eye drops. :wink:

    At the former images, are you showing us data bit#1 (at the accessory header, P17), and HyperCk waveforms for a first-byte-write, within some generic word write cycle?

    Am I understanding it right, or not?

    P.S. Also, in case of writes, the more one can bring HyperCK leading and trailing edges centered with respect to databits, the better.
  • jmgjmg Posts: 14,820
    evanh wrote: »
    .
    I'm able to, right now, at 3.3 Volts, consistently burst write data into the hyperram at up to 350 MT/s. That's exceeding even the 1.8 V rating!

    EDIT: I've reduced the capacitor value from 33 pF to 22 pF to get this fast. At 33 pF the sysclock limit was 230 MHz instead. But for 22 pF to work I also had to use an unregistered pin for the HR clock. Otherwise it wasn't enough phase shift on the clock signal.

    How stable is that over temperature ?

    rogloh wrote: »
    ... Perhaps it could be done higher with a capacitor, though it does seem a bit board dependent. Something to think about later...
    The new ISSI OctalRAMs have a pattern-read mode (ROM), which looks like it is intended to be used for PCB tuning, or driver-delay adjustments - a nice idea.

  • evanhevanh Posts: 11,822
    edited 2020-02-22 21:57
    Yanomani wrote: »
    At the former images, are you showing us data bit#1 (at the accessory header, P17), and HyperCk waveforms for a first-byte-write, within some generic word write cycle?

    Am I understanding it right, or not?
    For repeating signal (so the scope can reconstruct waveform), I ended up writing a custom program that simply drives the two pins toggling every sysclock in unison. It is a bit of a cut'n'paste.

    This is with both pins registered:
    		dirl	#ram_ck
    '		wrpin	##SPM_NCO_FREQ, #ram_ck				'HR clock pin, unregistered - helps with timing
    		wrpin	##SPM_NCO_FREQ | P_REGD, #ram_ck		'HR clock pin, registered
    '		wrpin	##SPM_NCO_FREQ | P_REGD | P_1K5R, #ram_ck	'HR clock pin, registered, 1.5 kiloOhm drive
    '		wrpin	##SPM_NCO_FREQ | P_REGD | P_1mA, #ram_ck	'HR clock pin, registered, 1.0 milliAmp drive
    '		wrpin	##SPM_NCO_FREQ | PM_DAC124 | ($f0<<8), #ram_ck	'HR clock pin, registered, 124 Ohm BIT_DAC (high=15, low=0)
    		wxpin	#dmadiv, #ram_ck				'HR clock step interval (DDR)
    		wypin	misc1, #ram_ck
    		dirh	#ram_ck
    
    		dirl	#hr_base+1
    		wrpin	##SPM_NCO_FREQ | P_REGD, #hr_base+1
    		wxpin	#dmadiv, #hr_base+1
    		wypin	misc1, #hr_base+1
    		waitx	#0
    		dirh	#hr_base+1
    
    		jmp	#$
    

    And this is with hyper clock pin unregistered:
    		dirl	#ram_ck
    		wrpin	##SPM_NCO_FREQ, #ram_ck				'HR clock pin, unregistered - helps with timing
    '		wrpin	##SPM_NCO_FREQ | P_REGD, #ram_ck		'HR clock pin, registered
    '		wrpin	##SPM_NCO_FREQ | P_REGD | P_1K5R, #ram_ck	'HR clock pin, registered, 1.5 kiloOhm drive
    '		wrpin	##SPM_NCO_FREQ | P_REGD | P_1mA, #ram_ck	'HR clock pin, registered, 1.0 milliAmp drive
    '		wrpin	##SPM_NCO_FREQ | PM_DAC124 | ($f0<<8), #ram_ck	'HR clock pin, registered, 124 Ohm BIT_DAC (high=15, low=0)
    		wxpin	#dmadiv, #ram_ck				'HR clock step interval (DDR)
    		wypin	misc1, #ram_ck
    		dirh	#ram_ck
    
    		dirl	#hr_base+1
    		wrpin	##SPM_NCO_FREQ | P_REGD, #hr_base+1
    		wxpin	#dmadiv, #hr_base+1
    		wypin	misc1, #hr_base+1
    		waitx	#1
    		dirh	#hr_base+1
    
    		jmp	#$
    
  • evanhevanh Posts: 11,822
    jmg wrote: »
    How stable is that over temperature ?
    Wasn't really my intent to make a capacitor the ultimate solution.

  • jmgjmg Posts: 14,820
    evanh wrote: »
    jmg wrote: »
    How stable is that over temperature ?
    Wasn't really my intent to make a capacitor the ultimate solution.
    Why not ?
    It may have less variation than other solutions, which have large max-min spreads.
    A cap ( and maybe some modest Series R) uses the P2 driver and PCB layout effects to move the edge.
  • evanh wrote: »
    For repeating signal (so the scope can reconstruct waveform), I ended up writing a custom program that simply drives the two pins toggling every sysclock in unison. It is a bit of a cut'n'paste.

    Ah, ok! Now I understand why old eyes of mine did complained; seasoned brain too...

    Even if the Hyper had a super-hyper PLL (wich it don't has), by closelly tracking HyperCK, it would be almost impossible for it to be able to deliver DQ just in time during Read cycles, as suggested by the images. So I've rulled out Read cycles.

    Else, if it was RWDS, paired with any DQ, well... Exccelent layout and decoupling could perhaps explain why they appear to track that close. But you stated that they were CK and one of DQs.

    Finally, even if it was a Write cycle, HyperCK would be wrong, due to absense of phase lag.

    Misunderstanding did generated the question. :smiley:

    Now, the exercise is clear to me. Thanks a lot!


  • @evanh, I noticed you had other pin drive options like 1.5k ohm, bitDAC etc in your test code. So did you find any benefits with enabling other output options on the shape/timing of the delayed clock waveform etc or are you still looking into it? It would be great to find something that is sort of "universally" useful to apply here, if there is such an option.
  • evanhevanh Posts: 11,822
    Yanomani wrote: »
    Now, the exercise is clear to me. Thanks a lot!
    Read data is crazy bad using the accessory board at sysclock/1. Brian did a great job of discovering sysclock/1 behaviour with the HyperRAM accessory board https://forums.parallax.com/discussion/comment/1482076/#Comment_1482076

    I'm hoping that'll improve a lot with close layout between the Prop2 and HyperRAM on one specialised circuit board.

  • evanhevanh Posts: 11,822
    rogloh wrote: »
    @evanh, I noticed you had other pin drive options like 1.5k ohm, bitDAC etc in your test code. So did you find any benefits with enabling other output options on the shape/timing of the delayed clock waveform etc or are you still looking into it? It would be great to find something that is sort of "universally" useful to apply here, if there is such an option.
    From months back. Those all were terrible outcomes but I've just left them there as reminders.

  • evanh wrote: »
    Yanomani wrote: »
    Now, the exercise is clear to me. Thanks a lot!
    Read data is crazy bad using the accessory board at sysclock/1. Brian did a great job of discovering sysclock/1 behaviour with the HyperRAM accessory board https://forums.parallax.com/discussion/comment/1482076/#Comment_1482076

    Those charts Brian made were very useful. It appears there are a couple of frequency ranges where the timing differences between registered vs non-registered IO behaviour don't overlap very much. Around 88-92MHz and 228-232MHz look tight and could be frequencies bands to avoid with HyperRAM if there is a choice. How constant these charts are over temp/voltage/layout etc I don't know. But the good thing is the range 228-280MHz will cover the 252MHz/270MHz TDMS operation and the next range up from 268-308MHz will cover the handy frequency of 297MHz, which are all useful for video. Another sweet spot for video at 200MHz looks good too.
Sign In or Register to comment.