Constraints from python

[Jason Morgan]

Hi,

I can't find any examples of adding delays and constraints from python. 

I've found that there is a getEdgeList() member function for a clock object, this means you can use


e1=clk.getEdgeList()[5] 

to get the 5th edge of the clock



I tried using

n=5
e1=clk.getEdgeList()[n]
e2=td.addEdge(cmdOut,(n * t1, (n * t1)+jitter, "test")
tsu=td.addUserConstraint("tsetup",tsu_min,tsu_typ,tsu_max,"tsu")
td.addConstraint(tsu,e1,e2)

But no constraint appears.

I also notice that the bus object has an addEdge method, but this does not return an edge object - surely this is not correct?

e2=cmdOut.addEdge(time,value) 

would be far more OO.

I'll keep playing, but do you have any examples?

Cheers,
Jason.

[dan_fabrizio]

Hi Jason,

There are some examples in the script directory. Look at dff.py, it
shows how to work with delays and get each edge.

clk.getEdgeList()[5] probably returns null.

1) you can use a for loop like the one in the example to get the edge
you want.
2) you can use clk_edge_list.get(5) which I think should work too.

Look at draw_diagram.py for an example of adding edges to signals and
buses.

I agree signal.addEdge() is more OO like. Most of the script
functions are commands that can use undo and redo, that is why they
need methods of
the TimingDiagram class. .. td.addEdge(signal, edge_time,
value).

I hope this helps. Check out all the examples in the scripts
directory.
Dan

[Jason Morgan]

Hi Dan,

clk.getEdgeList()[0]
definately returns an edge object, see attached.


Another qustions:
A bus has a rise time and a fall time, which draws nicely.

However, when you do Value->'Z' or 'Z'->Value the risetime and falltime are disobayed. I agree electrically this can often be different, but there appears to be no Toz and Toa, is this an oversight or am I driving it wrong?

See attached for an idea of the problem, you can see bus states overlap.  (This one is a show stopper for me BTW)



Anyway,

Some more bugs to add to your list:

--
If the
td.setEndTime()
method sets a time less than the last edge time (or any other object methinks) then the display goes mad.

--
The location of constraints often overlap, I know you can use setOffsetY() to correct it, but it might be more sensible if there was a setLocation(ABOVE|BELOW) to help
sort them, rather than specifying a distance which might need to change depending on waveform size.

Perhaps take a leaf from WX, where you can give hints rather than explicits.  It might even be possible to have them auto-arrange that way.

--
After you do addConstraint, the GUI has the graphical object in a selected state, this makes the Python CLI unresponsive until you do CTRL-C.

--
Multi-line text fails on bus values, "Row A\nCol B" results in " "

--
See the attached, it causes java to crash big time with some overlapping error, some sort of race condition.
I'll try adding time.sleep() delays to workround.



Also some more enhancement suggestions:

--
Add a measurement object,  i.e. like a constraint, but instead just a graphical <---name/time---> attached to two edges that follows it but does not drive it.

--
The use of text to define electrical bus states is IMO not a good idea, you should have a bus state method, e.g. Driven, Undriven, HiZ, etc.  Otherwise some text values are impossible.

 

----- Original Message -----

From: dan_fabrizio

Sent: 01/07/11 03:14 AM

To: TimingAnalyzer

Subject: Re: Constraints from python

[Jason Morgan]

Hi,

Another bug, clock accuracy.


If I generate a list of edges based on the clock period

fc=533.333e6
tc=1/fc
tc2=tc/2

n=range(10)
edges=[x*tc2 for x in n]


clk= td.addDigitalClock("Clk",fc,"H")
clk.setRiseTime(50e-12)
clk.setFallTime(50e-12)
clk_list=clk.getEdgeList()

clk_edges=[x.getPt1Min() for x in clk_list]

and compare the edge times from the clock with that from the first list

diff=map(lambda a,b:a-b,edges,clk_edges)

print diff
I should get a list of identical values, instead I get an incrementing (or decrementing) list depending on which edge time pt(1,2,3)(Max,Min) I use.

It is as though the clock frequency is out by some rounding error, in the order of 100ps per cycle

This makes measurements over several cycles inaccurate compared to the actual clock.

[dan_fabrizio]

Hi Jason,

I have a list of known bugs I will publish on the website so you check
there before reporting any you find. But, I will look at each one
you reported and let you know if there is a workaround or a fix
coming. There hasn't been a lot of feedback from script users so I'm
very interested in your findings.

The clock accuracy issue you mentioned below is known and on the top
of fix list. I noticed this after adding the TimeWarp feature.

I'm testing a new version now which is mainly a bug fix version so I
can any fixes needed for issues you found using scripts. Also, the
files stored in the settings directory will be saved in the user home
directory under the .timinganalyzer directory, and hopefully you
will be start the program or use jython start_app.py from any place
now.

Also, I will probably start another google group for scripting topics

I will be touch with my findings,
Dan

[Dan Fabrizio]

Hi Jason,

I save 3 points for each edge.  

0% time of the transition.   Pt1
50%  time of the transition.   Pt2   (this point can be set by the user when adding the edge)
100% time of the transition.  Pt3

Use getPt2Min() to get the edge time value instead of getPt1Min() as shown below.

Rounding still occurs to next ps.   This will be changed to 1 fs or 1 x 10^-15. 

Thanks for your feedback,  Dan 

--
Dan Fabrizio
The TimingAnalyzer
www.timing-diagrams.com

[Dan Fabrizio]

Hi Jason,

I know we have talked in email but I want to respond to your questions here so others can see the answers which are below.

On Fri, Jul 1, 2011 at 5:35 AM, Jason Morgan <j.a.m...@gmx.co.uk> wrote:

Hi Dan,

clk.getEdgeList()[0]
definately returns an edge object, see attached.


Another qustions:
A bus has a rise time and a fall time, which draws nicely.

However, when you do Value->'Z' or 'Z'->Value the risetime and falltime are disobayed. I agree electrically this can often be different, but there appears to be no Toz and Toa, is this an oversight or am I driving it wrong?

See attached for an idea of the problem, you can see bus states overlap.  (This one is a show stopper for me BTW)

The rise and fall times for signals that change to or from Z occur in half the time specified for signal rise and fall time when adding the signal.   For example:  If you specify 2ns rise and fall time
when adding a bus,  then any signal states changes to or from a "Z" would occur in 1ns. 

I know you asked if this can be programmable.   I will look into this and let you know. 

I did modify your example and eliminated the Z transitions.   Try the modified version of your file that is attached.

Anyway,

Some more bugs to add to your list:

--
If the
td.setEndTime()
method sets a time less than the last edge time (or any other object methinks) then the display goes mad.

I will look into this one and let you know.

 

--
The location of constraints often overlap, I know you can use setOffsetY() to correct it, but it might be more sensible if there was a setLocation(ABOVE|BELOW) to help
sort them, rather than specifying a distance which might need to change depending on waveform size.

Perhaps take a leaf from WX, where you can give hints rather than explicits.  It might even be possible to have them auto-arrange that way.

cnstrnt.setLabelPos("LEFT"|"CENTER"|RIGHT)
 

--
After you do addConstraint, the GUI has the graphical object in a selected state, this makes the Python CLI unresponsive until you do CTRL-C.

I can't duplicate this issue.  Please provide example if you still can.

 

--
Multi-line text fails on bus values, "Row A\nCol B" results in " "

There is no multi-line text values at this time.  It is included in the todo list. 
 

--
See the attached, it causes java to crash big time with some overlapping error, some sort of race condition.
I'll try adding time.sleep() delays to workround.

I can't duplicate this issue.   Please provide example if you still can.
 

Also some more enhancement suggestions:

--
Add a measurement object,  i.e. like a constraint, but instead just a graphical <---name/time---> attached to two edges that follows it but does not drive it.

Yes,  I agree.   This is on the todo list.

 

--
The use of text to define electrical bus states is IMO not a good idea, you should have a bus state method, e.g. Driven, Undriven, HiZ, etc.  Otherwise some text values are impossible.

It is very hand to just to text labels instead of actual bin, hex, or decimals that always checked to be within the limits for a bus given the width.  
As you know,  I have put an "Issues List" page on the website so all users can see what is being fixed or if a workaround is known.  I will also add a "Todo List" page soon.

Thanks for your feedback,
Dan


 

 

----- Original Message -----

[Jason Morgan]

hi,

cnstrnt.setLabelPos("LEFT"|"CENTER"|RIGHT) seems not to work from Python for me, works in GUI.
Though I was aware of the method, in my original post I was speaking of text vertical positioning being better controlled rather than the horizontal
Currently I have to use arbitrary Y offsets which would easily break if text, gaps or trace size were changed.
In WX there is LEFT|CENTRE|RIGHT|TOP|MID|BOT, etc.

Thanks for the example you gave, but people like to see something like an eye diagram, this is why I need to insert the 'Z's between each bus transition.

e.g. See Micron DDR datasheets.

i.e.  <<<==>>><<<===>>> is preferred to  <><===><><===><>


Cheers,
Jason.

 

----- Original Message -----

From: Dan Fabrizio

Sent: 05/07/11 05:32 AM

To: timinga...@googlegroups.com