Home > Archive > Tcl > January 2006 > using 2 clocks in a design
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
using 2 clocks in a design
|
|
|
| Hi friends.
how r u all doing,
well i have a doubt here. i have to write a tcl script to produce an
input from a file at a clock rate "clk1" and then capture the output of
the DUT at a diffrent clock rate say "clk2". now i have to give input
to DUT at a while loop and then capture at a diffrent loop. i'am facing
problem here/
any clues or ideas how to proceed..
plzz reply soon..
thanks
bye
| |
| Aric Bills 2006-01-25, 4:12 am |
| I can think of three approaches you could take to achieve the
concurrency you're looking for:
1. use events. Replace your loops with events that consult global or
namespace variables and reschedule themselves until the appropriate
conditions are met. See the man pages for [after] and [vwait] (maybe
also [fileevent]) and the following wiki pages:
http://wiki.tcl.tk/2567
http://wiki.tcl.tk/1527
http://wiki.tcl.tk/946
http://wiki.tcl.tk/1526
2. use threads. Recent ActiveTcl distributions come thread-enabled,
which makes this approach much easier. You'll need the tread package
if you want to go this route.
3. use seperate programs for input and output and make them communicate
via interprocess communication (sockets, DDE, [send], etc). This will
probably involve some event code somewhere, but maybe simpler stuff
than you'd need for option 1. This method works by letting the
operating system handle the messy details of concurrency. It's
probably not your best option, but here it is just in case.
Good luck,
Aric
| |
| Aric Bills 2006-01-25, 4:12 am |
| I can think of three approaches you could take to achieve the
concurrency you're looking for:
1. use events. Replace your loops with events that consult global or
namespace variables and reschedule themselves until the appropriate
conditions are met. See the man pages for [after] and [vwait] (maybe
also [fileevent]) and the following wiki pages:
http://wiki.tcl.tk/2567
http://wiki.tcl.tk/1527
http://wiki.tcl.tk/946
http://wiki.tcl.tk/1526
2. use threads. Recent ActiveTcl distributions come thread-enabled,
which makes this approach much easier. You'll need to use the tread
package if you want to go this route. Practical Programming in Tcl and
Tk has a chapter on this topic, available at Brent Welch's webpage:
http://beedub.com/book/4th/Threads.pdf
3. use seperate programs for input and output and make them communicate
via interprocess communication (sockets, DDE, [send], etc). This will
probably involve some event code somewhere, but maybe simpler stuff
than you'd need for option 1. This method works by letting the
operating system handle the messy details of concurrency. It's
probably not your best option, but here it is just in case.
Good luck,
Aric
| |
| Andreas Leitgeb 2006-01-25, 7:57 am |
| Abbs <abrar_ahmed_313@yahoo.co.in> wrote:
> well i have a doubt here. i have to write a tcl script to produce an
> input from a file at a clock rate "clk1"
There are altready two open questions in this first part:
"produce an input" ??? Do you mean to read from some channel?
or produce input for some other process?
"at a clock rate ..." ??? Does this mean e.g. read a line/byte
every n seconds ? How exact do you need this to be?
> and then capture the output of
> the DUT at a diffrent clock rate say "clk2".
What is a DUT ?
you mean regularly reading a byte/line, which is output by
some other "DUT" program ? How exact does the interval
need to be?
> now i have to give input
> to DUT at a while loop and then capture at a diffrent loop. i'am facing
> problem here/
No loops at all: use "fileevent" (or if this really needs to be
well timed, use "after"-events).
Re-ask, explain what you really need, and perhaps we can help further.
| |
|
| I ran into this same problem recently....
many quirks. Using after in the same while loop that used clock clicks and
clock seconds drove the clicks to different speeds and after was not
aftering. upon seperating stuff into event driven procs, after locked up the
whole loop of programs original "while". After 6 hrs I finally had clicks
and seconds in same while loop very nicely without after. After works once,
then pukes on every attempt when demanded from another loop or in one,
unless I issued a "break" in a bizarre place in another while loop and had
after script call itself again to keep going at expense of memory leak when
freewrapped. I'll figure out someday how to keep after scripts "aftering" on
a heavy demand......Never been able to without undocumented "break" issued
after the after script called itself again within its own delay set. It
worked , but flawed leak.
-good luck, would like to know how it is done myself....
"Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message
news:slrndten42.56k.avl@gamma.logic.tuwien.ac.at...
> Abbs <abrar_ahmed_313@yahoo.co.in> wrote:
> There are altready two open questions in this first part:
> "produce an input" ??? Do you mean to read from some channel?
> or produce input for some other process?
> "at a clock rate ..." ??? Does this mean e.g. read a line/byte
> every n seconds ? How exact do you need this to be?
>
>
> What is a DUT ?
> you mean regularly reading a byte/line, which is output by
> some other "DUT" program ? How exact does the interval
> need to be?
>
>
> No loops at all: use "fileevent" (or if this really needs to be
> well timed, use "after"-events).
>
> Re-ask, explain what you really need, and perhaps we can help further.
>
| |
| Andreas Leitgeb 2006-01-25, 7:15 pm |
| bgd <bgd73@verizon.net> wrote:
> Never been able to without undocumented "break" issued
> after the after script called itself again within its own delay set. It
> worked , but flawed leak.
> -good luck, would like to know how it is done myself....
If you had used "after" correctly, you probably wouldn't have
needed any loop at all. ("after" called at the end of the handler
procedure to re-schedule the procedure) would have done the looping).
So probably you had to add the "break" to destroy some explicit loop,
which shouldn't have been there in the first place.
Beyond that, we'd probably have to see the code to judge what went
wrong.
| |
| Uwe Klein 2006-01-25, 7:15 pm |
| Hi,
I have somewhere code ( tcl)
that syncronises clock [clicks -milliseconds] and [clock seconds ]
and allows timed execution.
I needed this to change datefiles inside a +-30ms boundary.
Would that be any help?
uwe
| |
| Gerald W. Lester 2006-01-25, 7:15 pm |
| There seems to be several misconceptions going on here.
1) clock clicks is at a system dependent resolution and value, it is not
ever guaranteed to "synch up" with clock seconds.
2) the after is "after at least this much time passes" not "exactly when
this much time passes"
Why a while loop is being used instead of queuing up events is beyond me.
The normal way is to have a proc like:
proc DoPeriodically {} {
set ::myAfterId [after $::myPeriod DoPeriodically]
## The rest of the code
}
Note -- even the above will "drift" slightly over time. The reality is that
unless one is working in a good real time OS and is having the OS generate
process/thread wakeup events at a fixed period it is very difficult to get
exactly the same interval every time. Even in a real time OS they only
guarantee the interval +/- some delta and that the average interval will be
the request interval +/- some small value.
Then again, it may be I missed entirely what you were attempting to say.
bgd wrote:
> I ran into this same problem recently....
> many quirks. Using after in the same while loop that used clock clicks and
> clock seconds drove the clicks to different speeds and after was not
> aftering. upon seperating stuff into event driven procs, after locked up the
> whole loop of programs original "while". After 6 hrs I finally had clicks
> and seconds in same while loop very nicely without after. After works once,
> then pukes on every attempt when demanded from another loop or in one,
> unless I issued a "break" in a bizarre place in another while loop and had
> after script call itself again to keep going at expense of memory leak when
> freewrapped. I'll figure out someday how to keep after scripts "aftering" on
> a heavy demand......Never been able to without undocumented "break" issued
> after the after script called itself again within its own delay set. It
> worked , but flawed leak.
> -good luck, would like to know how it is done myself....
>
> "Andreas Leitgeb" <avl@gamma.logic.tuwien.ac.at> wrote in message
> news:slrndten42.56k.avl@gamma.logic.tuwien.ac.at...
>
>
>
>
| |
| Don Porter 2006-01-25, 7:15 pm |
| Gerald W. Lester wrote:
> 1) clock clicks is at a system dependent resolution and value, it is not
> ever guaranteed to "synch up" with clock seconds.
Starting in Tcl 8.5, [clock milliseconds] and [clock microseconds] return
counts synchronized to the same epoch as [clock seconds].
[clock clicks -milliseconds] and [clock clicks -microseconds] are synonyms
to [clock milliseconds] and [clock microseconds] respectively.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|
| |
| Donal K. Fellows 2006-01-26, 7:59 am |
| Gerald W. Lester wrote:
> But what if neither -milliseconds or -microseconds are specified?
You get some random high-resolution thing that we don't (officially)
define. :-) On Unix, this is actually the return value from times(2),
and on Windows it's currently the same as [clock microseconds]. No
promises that these will remain that way though, of course.
Donal.
| |
| Donal K. Fellows 2006-01-26, 7:59 am |
| Uwe Klein wrote:
> the [job] command from scotty is very usefull for things like this
> but it has the same problem with creep as the repeat through after
> sollution.
You have to recompute the time delay each time from the number of times
you've already fired and the current time offset from when things
started. You can't just use a fixed delay between events or you're
guaranteed to have some drift, though the drift can be minimized by
setting up the next callback as the first thing in the script instead of
the last.
OTOH, if you're not too worried about drift, putting the rescheduling at
the end means that if you have a bug, you don't end up with quite such a
mess. It's much easier to debug. :-)
Donal.
|
|
|
|
|