Issues and improvements list

[Jason Morgan]

Yep I worked that out, I gave the example as a illustration of the timing error, the difference should be constant regardless of what point in the edge you measure from.

And thanks for the list, that saves me reporting stuff that you already know about.

I'll think about helping out.  I was looking for an open source timing designer and stumbled across yours.  It is by far the best in terms of how well thought out it is, its 'look and feel' and the fact that is scripts in Python (shame it's not written in Python, but no worries, the idea of the Python interface is very good).
I'm a 40 year old hardware engineer who is also reasonably good at programming, usually C and Python, but I've done some Java (but it was a while back)

Your current offering is not open source - I don't suppose you have plans to change that?  If it were, the decision to take part in the development would be a no brainer - the world is crying out for something like that!   If it were open source you could borrow from other open source initiatives, such as including a VHDL interpreter or WX interface.  You could always make a commercial closed source branch that added extra features.

I'm comparing your software with Timing Tool, a web based java app that I've used for years; and Timing Designer, a very expensive (and IMO not that good) tool that I've used when working for companies that can actually justify it.

You tool promises to be better than both of these.   I've almost drawn exactly what I want in less time than it would have taken using either of those other tools.  If you could find time to fix the two central issues (edges during open Z and the lack of a differential clock) then even if I don't get involved in the s/w long term I am sure that I will continue to help test stuff for you - especially the scripting.

Cheers,
Jason. 

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

From: Dan Fabrizio

Sent: 01/07/11 11:12 PM

To: timinga...@googlegroups.com

Subject: Re: Constraints from python

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 

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

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.

 

 

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

From: dan_fabrizio

Sent: 01/07/11 03:14 AM

To: TimingAnalyzer

Subject: Re: Constraints from python

 
 
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 


On Jun 30, 5:07 am, "Jason Morgan" <j.a.mor...@gmx.co.uk> wrote: 
> 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
The TimingAnalyzer
www.timing-diagrams.com

 

 

[Dan Fabrizio]

Hi Jason,

On Sat, Jul 2, 2011 at 5:11 AM, Jason Morgan <j.a.m...@gmx.co.uk> wrote:

Yep I worked that out, I gave the example as a illustration of the timing error, the difference should be constant regardless of what point in the edge you measure from.

And thanks for the list, that saves me reporting stuff that you already know about.

No problem.  I hope to get rid of most them

 

I'll think about helping out.  I was looking for an open source timing designer and stumbled across yours.  It is by far the best in terms of how well thought out it is, its 'look and feel' and the fact that is scripts in Python (shame it's not written in Python, but no worries, the idea of the Python interface is very good).
I'm a 40 year old hardware engineer who is also reasonably good at programming, usually C and Python, but I've done some Java (but it was a while back)

In the past,  I looked for programming help and wanted to convert to Python for the GUI and C for performance but didn't find a feel there was a good cross-platform solution.  I started a python library that is in the scripts directory to use as a way to convert over to Python in time.  I would like to do all of this someday.  I didn't know about Python when I started the program a long time ago.
What do you think?
 

Your current offering is not open source - I don't suppose you have plans to change that?  If it were, the decision to take part in the development would be a no brainer - the world is crying out for something like that!   If it were open source you could borrow from other open source initiatives, such as including a VHDL interpreter or WX interface.  You could always make a commercial closed source branch that added extra features.

Maybe some day.   I will think about it more.  I work for a large defense company and it is being used internally locally but I'm scheduled to give a presentation in the fall at a national conference.  I want to see what happens after that.  

I'm comparing your software with Timing Tool, a web based java app that I've used for years; and Timing Designer, a very expensive (and IMO not that good) tool that I've used when working for companies that can actually justify it.

You tool promises to be better than both of these.   I've almost drawn exactly what I want in less time than it would have taken using either of those other tools.  If you could find time to fix the two central issues (edges during open Z and the lack of a differential clock) then even if I don't get involved in the s/w long term I am sure that I will continue to help test stuff for you - especially the scripting.

Cheers,
Jason. 

No problem, I will do that and work on these 2 things.   As far as the Z times,  the transition time from Z to 1 or 0 should be one half the rise/fall time. I have to look into what your saying and check it.
Thanks,  Dan

 

[Jason Morgan]

Hi Dan,

The best cross platform GUI the best by a long shot is WXPython. (though WX works on many systems through many language wrappers)
WX is fast because as far as it can it simply wraps the native window libraries.

http://www.wxpython.org/
For proper vector/raster graphics you can use various wrappers for DirectX or just the GDI widgets in WX.
Visual Python might be a good idea, (it's 'effin fast) but the mapping of Visual onto
GUI is not that good at the current time. Visual is a 2D/3D interface to underlying 2D/3D graphics on the plaform.
http://www.vpython.org/contents/docs/visual/new_features.html
I believe somebody did a WX widget that allow a Visual panel but no idea how well it works.
I guess we'd have to prototype some panels with static data to see how well they work.

I did a step and repeat label printer in python, one time and it worked very well with 100's of barcodes on one page.

--

Ah so the rise fall time for OZ is 1/2, that is what I am seeing, would it be difficult to make that time programmable?

Take a look at the script I sent, that should show things quite well.

The scripts had some improvements, I can send them as well if that will help?

regs, j

 

 

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

From: Dan Fabrizio

Sent: 03/07/11 03:23 PM

To: timinga...@googlegroups.com

Subject: Re: Issues and improvements list