Call for Clarity from Chip or Beau
jazzed
Posts: 11,803
@Chip or @Beau,
These two questions need answers. Please address them.
2) Consider the example below. How many ns pass between setting the output at inst 3 and reading the input at inst 4?
These two questions need answers. Please address them.
-
1) What is the maximum rise and fall time for a Propeller pin as an output with a small capacitive load?
2) What is the time between setting the outputs and getting the inputs on two consecutive instructions?
2) Consider the example below. How many ns pass between setting the output at inst 3 and reading the input at inst 4?
con
_CLKMODE = XTAL1 + PLL16x
_XINFREQ = 5_000_000
pub start
cognew(@entry,0)
repeat
dat
entry org 0
or dira, #$ff ' inst 1
mov outa, #0 ' inst 2
mov outa, #$ff ' inst 3
mov data, ina ' inst 4
jmp #$
data res 1
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
BTW: The new avatar picture is cool. I've seen the story of it before.
Post Edited (jazzed) : 12/4/2009 5:46:04 PM GMT
http://www.rayslogic.com/propeller/Programming/RaysStuff/80MHz.JPG
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Gee, I've only ever used a 1GHz LeCroy at work and that was a GE Capital rental I'm sure [noparse]:)[/noparse]
How long is your ground wire/pin? The over-shoot does not appear nominal ....
From that, it looks like the fall time is around 2ns. Is there a test load?
This is very helpful, but of course does not replace a published specification from Parallax.
Thanks for your trouble.
There may be other factors (e.g. gate capacitance of the output drivers, which is not external-load-dependent) that could increase the rise and falls times, but this will give you a quick, back-of-the-envelope characterization.
-Phil
*I thought the output drives were supposed to be symmetrical, but apparently they're not quite.
Post Edited (Phil Pilgrim (PhiPi)) : 12/4/2009 8:01:41 PM GMT
This may be a step toward resolving question 1. Question 2 requires Chip's attention.
I imagine it would·look a lot better if there were a resistive load...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
-Phil
SRAM speed - is 10nS possible ???·· http://forums.parallax.com/showthread.php?p=860477
Question 2 needs further definition.·Below is the example code used...
con _CLKMODE = XTAL1 + PLL16x _XINFREQ = 5_000_000 pub start cognew(@entry,0) repeat dat entry org 0 or dira, #$ff ' inst 1 mov outa, #0 ' inst 2 mov outa, #$ff ' inst 3 mov data, ina ' inst 4 jmp #$ data res 1What I believe jazzed is really asking is... (I will make these questions 3, 4 & 5)
3. With reference to the beginning of the R clock for "inst 3", what is the time delay until 'outa' pins are stable?
4. What clock cycle are the ina pins sampled in "inst 4"? (Is·it·the "e"·or the "S" clock cycle?)
5. With reference to the beginning of the "e" or "S" cycle in 4 above. What is the time delay until 'ina' pins are sampled? What is the minimum setup time required before the 'ina' pins are sampled?
This will allow us to determine (in addition to taking circuit loading etc into account) what the fastest SRAM access can be. We can then determine if multiple cogs can help getting access faster, and the impact of overclocking.
Thanks in advance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Can you assume for the moment that sampling ina is the same as sampling phsx? Then consider this code fragment:
Now the value for frqa becomes active (i.e. is used 1st time) during S of the sample instruction (3). So in case sampling happens during e you'd expect 2 being stored in temp, which is exactly what happens. I did similar tests with a duty cycle counter and sampling ina, same result.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
1) What is the maximum rise and fall time for a Propeller pin as an output with a small capacitive load?
Given a careful design with limited number of loads (< 32pf total), 45 Ohm impedence, and 2.4V/3.3V at 72%, the rise/fall time for an output pin is close to 1.9ns.
2) What is the time between setting the outputs and getting the inputs on two consecutive instructions?
Approximately two clock cycles pass between setting to a register and getting from a register on back to back instructions. In the example 5MHz xtal1 and PLLx16, this translates to about 25ns.
I hope you have not taken my comments the wrong way - it is an externsion to your questions, not meant to hijack or criticise. There are great minds working on this and together we will all benefit once we understand the timing limitations within the prop.
The reason I asked the extra questions is we then can understand how we can use "other" methods to improve the access. Your Q2 does not give us that, but we can derive that from Q3, 4 & 5.
And yes, I would believe that our summation of 2) is that the minimum time would be 25nS, being the clock cycles of "S" & "D" in the 'ina' read instruction. We cannot include any time in either the "d" (which is the "R" cycle of the 'outa' instruction) or the "e" ('ina') instruction. The proviso here is that the "e" does not require setup time preceeding the clock and Chip will hopefully answer this.
As you can see, while memory speed helps, we can gain much more by overclocking than we can by increasing SRAM access. But every instruction we can save helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I would like simple answers to my simple questions though from the authority on the subjects at hand. I figured Parallax has more chips to characterize than any of us, so they are in a position to measure timing with respect to calculations on given loads. Having data match calculations over a large sample size would be best. We can infer all we like, but in the end it is Chip's responsibility to his customers to produce data that satisfies.
All the answers sought are especially meaningful when trying to project correct operation in the "worst case" scenarios where timing stacks up in a bad way which can lead to RMA inventory stack up (which no one wants) for high volume product (which everyone would like). Useless inventory is an evil expensive.
I think we are on the right track and the light at the end of the tunnel is getting bigger because there is an exit coming rather than another train. Fingers crossed [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I recall that the external pin transition occurs over ~.25ns, unloaded. Before the transition occurs, though, there is ~2ns of internal delay from the cogs (w/series OR gates) to the pin-driver MOSFETs.
The cog executes an instruction in four cycles:
1) Read Instruction N (ALU result N-1 settles during this cycle)
2) Write Result N-1
3) Read Source N
4) Read Destination N
Note that INA is read during the Read Source cycle. Results are written three cycles later. When doing back-to-back read-modify-write operations on DIRA/OUTA, you are dealing with an internal register, only, so there is no pin-load dependency. The tightest timing occurs from an OUTA/DIRA write to an INA read (XOR OUTA, MASK... TEST MASK, INA WZ), where the pin must transition and be read back within ONE clock cycle, minus internal propagation delays of perhaps ~4ns (another ~2ns of read-back delay).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 12/6/2009 5:22:30 AM GMT
So an OUTA/DIRA write to an INA read output to input window is what exactly? Is it "clock-6ns" or is it "clock-2ns" ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
*3··Time from start of "R" cycle to valid data out at the pins
For the purpose of working out a realistic value, I have added the .25ns for ideal rise/fall time and a further .25nS for possible loading, plus your internal gate delay of 2ns which gives ~2.5ns
*5a Time from start of "S" cycle to valid data read from the pins·(latched)
For the purpose of working out a realistic value, I have added the .25ns for ideal rise/fall time and a further .25nS for possible loading, plus your internal gate delay of 2ns which gives ~2.5ns
*5b Data setup time until pins are internally sampled (latched)
I presume from your comments, the setup time is included in *5a above and so will be the same ~2.5ns
*7 Minimum Access Time
Based on the above times, this will be 12.5ns - 2.5ns - 2.5ns = ~7.5ns
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
so cool I like it !
ca
re
DAT org 0 entry mov dira, #1 movi ctra, #%0_00110_000 movi frqa, #%0001_00000 movi phsa, #%1110_00000 mov outb, ina or outb, #%1000_0000 ' indicate result ready wrlong outb, par cogid frqa cogstop frqaPin 0 is the output of a duty cycle counter, preset to %01110. So the pulse is expected after 2 cycles (%01111, %10000). phsa gets written in R therefore the first increment can only happen during the S cycle of sampling ina, so in the setting above the pulse occurs during the D cycle. How is it then possible that I catch the pulse with the above code fragment (assuming it's sampled during S)?
Post Edited (kuroneko) : 12/5/2009 8:20:18 AM GMT
The pins are sampled on the Read Destination cycle, not on the Read Source cycle, as I first stated.
Though the Read Source cycle is used to read a possibly-required source register, the·Read Destination·cycle is used to multiplex in the final source value from either the source register that was just read, the PAR,· the CNT, the INA, the PHSA, the PHSB, or the literal value specified in the opcode. At the end of this cycle, both the source and destination values are ready to be·fed into the ALU.
Thanks for pointing this out, Kuroneko. I wasn't remembering how this worked, exactly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
kuroneko and I have been having a discussion offline to try and prove this and work out the timing (without a high speed cro). I suggested we bring it back online to enlist some other ideas as to why we are seeing·different results to those expected. Perhaps we are making some incorrect assumptions or just plain coding errors.
I will let kuroneko post his code test results. Basically, this is where we are up to...
Since we know that the output to the pins occurs somewhere in the "R" cycle (say 2.5ns after the "R" begins") we can use this as our reference? However, we can only assume it is valid sometime within the "R" cycle, not at the beginning of it.
Now, lets think about the reading. Chip said it is necessary for the pins to be fetched in the "S" cycle because it may be operated upon in the "e" cycle. This makes sense, now I think of it, because otherwise it would not be ready at the start of the "e" cycle, which it must be.
It is entirely possible that the "S" cycle only latches the input pins at the end of the cycle. If we presumed that, and the fact that the output pins were only stable sometime during the previous "R" cycle, how would we test for this??
Alternately, if the pins·were sampled in the "e" cycle, they must be ready for the ALU at the start of the "e" cycle meaning that allowing for internal gate time delays, the pins·would in reality be sampled in the previous cycle (i.e. the "D" cycle). How would we test for this??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Postedit: Thanks Chip. Middle ground. As you can see, I realised that the pins had to be ready for the ALU at the beginning of the "e" cycle.
Are they infact latched into the ALU? I presume they are otherwise a change during the ALU cycle could upset things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 12/6/2009 5:23:56 AM GMT
Edit: To comment on the test program Cluso99 mentioned. I started 2 cogs which synchronise on a given cnt value. The move cog will then set a number of mask bits from high to low. The read cog will execute a nop first (to cover the time taken by the mov) then sample ina. The whole process is done 4 times with the difference that the read cog will leave the waitcnt 0..3 clock earlier than the move cog.
Furthermore, a clock cycle is considered to start with low followed by high, the rising edge being responsible for sampling and/or latching. This may be an invalid assumption but should be valid to get my point accross. Only in the case for a delay of 3 can I see mask high being sampled.
Source Read cycle -
source register is read from cog RAM and value is latched on the rising clock edge
Destination Read cycle -
destination register is read from cog RAM and value is latched on the rising clock edge
source value is mux'd from source register, PAR, CNT, INA, PHSA, PHSB, or literal, and latched on the rising clock edge
Instruction Read cycle -
Next instruction is read from cog RAM and value is latched on the rising clock edge
source and destination values settle through ALU
Write Result cycle -
ALU result is written to cog ram on the rising clock edge.
So, in the case of INA, it can be changing up to the rising clock edge of the Read Destination cycle. Everything happens on rising clock edges. All timing can be considered from rising clock edge to rising clock edge.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
If you write PHSA, the new value gets mux'd into the PHSA flipflops' inputs, instead of the accumulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
in the Result cycle of the phsa movi (rising edge) phsa is set to #%1110_00000<<23. This means that the next rising edge (S of mov) brings the value up to %1111_00000<<23, the following rising edge (D of mov) causes an overflow which outputs the DUTY pulse.
You also said that ina is latched with the rising edge. My point is that it shouldn't be possible to sample the pulse with the rising edge of D when the rising edge (of D) generates the pulse in the first place. So only the rising edge of E could possibly sample that pulse (i.e. the phsa preset is chosen so that ina catches the value). The test program will report %1000_0001 to the caller when run with the given presets.
Code relisted for ease of use.
DAT org 0 entry mov dira, #1 movi ctra, #%0_00110_000 movi frqa, #%0001_00000 movi phsa, #%1110_00000 mov outb, ina or outb, #%1000_0000 ' indicate result ready wrlong outb, par cogid frqa cogstop frqaPost Edited (kuroneko) : 12/6/2009 6:25:32 AM GMT