Where in the pipeline would INA be sampled ?

Bean

Let's say I have the following PASM code:

  WAITPEQ signal,signal 
  MOV temp,INA 

 
signal LONG 1 

 
temp LONG 0

How much time would elapse between the signal ending the WAITPEQ, until the pins state is recorded in "temp" ?

I want to put gates on between the pins to get·more resolution by seeing how many gates the signal got through (propagation delay).

So I guess I'm asking what is minimum delay between the pin that ends the WAITPEQ to another pin that makes that pin still read as zero when the "MOV temp,INA" is executed ?

Bean


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Post Edited (Bean) : 7/7/2010 5:15:22 PM GMT

Phil Pilgrim (PhiPi)

ina is sampled five clocks after the condition for waitpeq is satisfied. Here's the program I used to test it:

[b]CON[/b]

  [b]_clkmode[/b]      = [b]xtal1[/b] + [b]pll16x[/b]
  [b]_xinfreq[/b]      = 5_000_000
  freq          = $0400_0000 

[b]PUB[/b] start

  [b]cognew[/b](@tester, 0)

[b]DAT[/b]

              [b]org[/b]       0
tester        [b]mov[/b]       [b]dira[/b],#7
              [b]mov[/b]       [b]ctra[/b],[b]ctra[/b]0
              [b]mov[/b]       [b]ctrb[/b],[b]ctrb[/b]0
              [b]mov[/b]       [b]frqa[/b],frq0
              [b]mov[/b]       [b]frqb[/b],frq0
              [b]mov[/b]       [b]phsb[/b],[b]phsb[/b]0
:loop         [b]waitpne[/b]   testp,testp
              [b]mov[/b]       [b]outa[/b],#0
              [b]waitpeq[/b]   testp,testp
              [b]test[/b]      testq,[b]ina[/b] [b]wz[/b]
        [b]if_nz[/b] [b]mov[/b]       [b]outa[/b],#%100
              [b]jmp[/b]       #:loop

[b]ctra[/b]0         [b]long[/b]      %00100 << 26 | 0
[b]ctrb[/b]0         [b]long[/b]      %00100 << 26 | 1
frq0          [b]long[/b]      freq
[b]phsb[/b]0         [b]long[/b]      freq << 3 - freq * 6 '<---- Change the muliplier to step the delay.
testp         [b]long[/b]      %001
testq         [b]long[/b]      %010
        

Here are the results, as displayed on my scope:





-Phil

Addendum: I should add that, the five-clock delay works here because the "inputs" are outputs from the same Prop and are thus synchronized to its clock. For unsynchronized inputs from an external source, the delay could range up to six clocks.

_

Post Edited (Phil Pilgrim (PhiPi)) : 7/7/2010 7:03:00 PM GMT

Bean

Phil,
Thanks for working that out for me.

I need to measure a 2KHz wave with as much resolution as I can muster.
Right now, I do:

WAITPEQ Signal,Signal 
MOV startCnt,CNT 
WAITPNE Signal,Signal 
WAITPEQ Signal,Signal 
MOV temp,CNT 
SUB temp,startCnt

This gives me 12.5nSec resolution. But if I do this:

Signal->Pin0->62.5nSecDelay->Pin1->3.125nSecDelay->Pin2->3.125nSecDelay->Pin3

And use:

WAITPEQ Signal,Signal 
MOV startCnt,CNT 
WAITPNE Signal,Signal 
WAITPEQ Signal,Signal 
MOV extra,INA 
MOV temp,CNT 
SUB temp,#4 ' subtract for instructions "MOV extra,INA" 
SUB temp,startCnt 
SHL temp,#2 ' * 4 
' If extra.1 = 1 then add 1 
' if extra.2 = 1 then add 1 
' if extra.3 = 1 then add 1

I should get 3.125nSec resolution.

As an experiment, I can do the 3.125nSec with a length of wire (36.9"). Not sure how to do the 62.5nSec delay...That would be a long wire...

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Phil Pilgrim (PhiPi)

If it's a clean signal, why not just count the number of transitions in one second or longer? You can use a counter to do this (in mode %01010). Or, if you need a quicker result, measure the time between 10 positive edges, multiply by 12.5ns, and divide by 10. This will give you a precision of 1.25ns.

-Phil

Bean

Phil,
I need to measure every cycle (the system measures variations in the pulse width).

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Phil Pilgrim (PhiPi)

Bean,

In your example above with the delays, you'd still have a 12.5ns uncertainty in the start count. But maybe you could read ina there, too, to get the delayed values at the start.

'Sounds like an interesting project. Is this for work?

-Phil

Addendum: BTW, you can buy high-speed active delay lines from DigiKey. The DS1004, for example has five taps separated by 3ns apiece.

An alternative would be to insert your signal into a SIPO shift register driven by a high-speed (e.g. 320MHz) clock, whose outputs you can read from the Prop.

Post Edited (Phil Pilgrim (PhiPi)) : 7/7/2010 9:53:07 PM GMT

Bean

Phil,
Yeah, the code really uses the last "temp" as the start for the next cycle.

Here is a video of the first working system (it's alot more advanced now) http://www.youtube.com/watch?v=fkYL7fluv5E

Of course in the video we are seeing the frequency move because of the extreme temperature change.

When we use the system for real we sweep the temperature very slowly (2°C / minute), and look for "micro jumps" in the frequency by comparing one reading to the next.
Any jumps over 8ppB and the unit is rejected.
If you watch closely in the video you can see a couple places where there are big steps in the curve. These are the micro jumps that we are looking for.

It is interesting sometimes we get jumps where the frequency changes abruptly and stays there, sometimes it changes for a very short period of time then jumps back.

All the readings get logged to a PC for later.

P.S. Thanks for the tip on the DS1004. I didn't know that them. I've never really used delay lines before.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Post Edited (Bean) : 7/7/2010 10:44:58 PM GMT

Cluso99

Bean: This thread discusses this in more detail http://forums.parallax.com/showthread.php?p=862211

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

pjv

Hi Bean;

Years ago I was messing with some fast sampling things in the prop, and on noticing a slight variation in sample times, Chip piped up and said that the delay through each cog gate set was (IIRC) about 2 nano seconds. And that was from cog 0 to 3 and cog 7 to 4 (or was it the reverse of that.

If all your cogs are available, you might be able to concoct some scheme to use that as a delay line....... sample all cogs at a synchronized time and see who tripped.

I believe this is also true of the outputs, and I have wondered if that feature could be used to drive Ethernet's fast pulse requirements directly.

So much to do, so little time.

Cheers,

Peter (pjv)

jazzed

While Phil's waveforms are beautiful. INA is not sampled at the same time OUTA is set.

The thread Cluso refers to traces a nice story about INA/OUTA ... read it beginning to end.
http://forums.parallax.com/showthread.php?p=861676

Kuroneko was a real hero in helping us understand the whole truth about INA.
I sit thankful and modest only in his shadow.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Phil Pilgrim (PhiPi)

jazzed said...
While Phil's waveforms are beautiful. INA is not sampled at the same time OUTA is set.

Nor was I implying that it is. In both images, ina is read five clocks after the rising edge of the top (yellow) trace. The magenta trace is from the write to outa (or not) that simply indicates what state was read at that 5-clock point. The 5-clock and 6-clock delays in the second (cyan) trace comprise the demarcation between catching the second trace still in the low state and not catching it.

-Phil

jazzed

Phil your implication was not immediately clear.
Regardless, I wasn't trying to joust or be critical.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

kuroneko

Bean said...
Not sure how to do the 62.5nSec delay...That would be a long wire...

FWIW, you could use the counter feedback outputs to have input A delayed (and inverted) by about 1 clock cycle. If you don't mind that the final signal is inverted (2n + 1 stages) then this should do the trick.

Bean

kuroneko,
Wouldn't the counter feedback output be syncronized with the propeller clock ?

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

kuroneko

Bean said...
Wouldn't the counter feedback output be syncronized with the propeller clock ?

Yes, it would. Probably not what you want then [noparse]:([/noparse]

Bean

pjv,
So you are saying that all cogs do not see the inputs change at the same instant ?
Hmmm, that would be interesting to experiment with...

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

Cluso99

Bean: All cogs executing a waitpxx would see the change on the same clock cycle except for perhaps granularity of say ~0.5ns between cogs due to internal trace differences between pins and cogs. However, a mov xxx,ina would not necessarily be seen by all cogs at the same time because they may be out of step (remember 4 clocks per instruction).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Bean

Cluso99,
I think pjv is talking about some kind of propagation delay between the cogs.
I "think" he is saying that if all the cogs read INA at the same clock, there will be a couple nanosecond delay between what they sense.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

pjv

Hi Bean;

I believe that what you said is the case, and you are correct on the propagation delay from port logic through to the next bit and so on, as being the source of that. It's so long ago now, but at the time Chip also clarified that there were two sets of paths, the direction I can't recall. One was for bit0 propagating to bit15, and the other bit31 propagating to bit 16. The directions may be the reverse of what I wrote.

So this means that if one asynchronous signal were to be wired into all inputs and read in by an INA, then at some time some inputs will read high and some low, depending on the propagation through the chain at the instant of the clock. I would expect that there would not be a random pattern to this, but more orderly. Of ourse not all bits will have identical delays, so there could be a bit of a variation.

Now exactly how to use this to yopur advantage would need some thought..... perhaps it is of no advantage.

Cheers,

Peter (pjv)

Bean

Peter,
I got a setup that gave different pin states from the different cogs, but it is VERY temperature dependent.
It seem the delay gets longer as the chip gets hotter. Just the touch of my finger was able to change the states from all on, to all off. But I could see it progressing through the different cogs.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

pjv

Hi Bean;

Yesterday evening my response spoke of different cogs. That was incorrect... I should have said different pins, and that was what I said this morning.

Now you say different cogs?.... Do you have multiple cogs synced to read the pins? What do you get in reading all pins with a single cog?

Cheers,

Peter (pjv)

Bean

Peter,
My setup is 1 cog controls, 7 cogs read the same pin. I used different lengths of wire to create a delay.
This is VERY touchy, but I can get a stable set of data, and it seems different cogs do see the signal at slightly different times.
By touchy I mean about 1 inch of wire makes the difference if a certain cog reads as high or low.

So you say different PINS have different delays ???? I haven't tried that yet.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

pjv

Hi Bean;

It is understandable that each cog could react slightly differently to the clock signal, but they still sample all in parallel. But the I/O logic circuitry is all chained from one to the next in series (as explained before, two banks of 16 in series). So there would be a predictable -or at least consistent- accumulated propagation delay through the chains.

The signal would travel through the wires at nearly 1 foot per nano second, so an inch or so would be a very short time. As far as I can recall, the propagation delay through each stage in the chain is one or two nano seconds. So I expect you coud possibly resolve a sample to 2 nSec within a range of 14 nSec.

Sounds like some experimentation required here.

Cheers,

Peter (pjv)

Cluso99

The input pins would not be via stages, but merely a tap on a length of track (internal on the chip). Obviously pins on two extremities will have different propagation, as will the location of the cog (which cog). However, these are going to be minimal and will be <<1ns. With the INA Chip stated what the delay was. Obviously there is a slight variation due to internal routing. IIRC there was a total delay of ~2.5ns. We are not talking much here.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

pjv

Well, I'll be.........

Cluse, I think you are right.

Now that I again look at the Prop block diagram, it is the OUTPUTS rather than the inputs that are chained through the cogs. Interestingly, it does not indicate the to chains, and I am adamant I remember that part correctly --- at least I think. So perhaps the drawings are only representative and not totally correct for clarity's sake.

Serves me right for speaking wwithout confirming what my memory tells me. As I get to be more of a "senior" I seem to remember things that never happened!

Sorry about that all, I apologize for this error, and I'll try to do better next time.

Cheers,

Peter (pjv)