( Post 114 Item 1 ) --------------------------------------------------------
From: heather@wellfleet.com (Heather Achilles)
Subject: Should I Go to OVI and SNUG?
>Hi John,
>
>I found out yesterday that SNUG is on 3/24 and 3/25 in San Jose.
>I was wondering what your impression of previous user's groups
>meetings is? Is it worth taking 2-3 days to go to California to attend?
>
>I know this year's meeting backs up to OVI. Unfortunately,
>I don't think I can afford to take more than a couple or 3 days!
>
>Anyway, let me know what you think!
>
> Heather
[ Readers Please Note: This response is PURELY my own personal opinion. ]
Heather,
First let me point out a personal bias in my answering this question. I'm
very heavily involved with the OVI, SNUG, ESNUG, & Synopsys/customer political
situation because I'm speaking at OVI and usually making noise at SNUG. So,
quite naturally, I'm a big advocate to attending these conferences. So much
so that I'm paying out of my own pocket to attend.
Now to answer your question: if you want to know virtually all the dirt and
what's going on with Synopsys, Cadence, Mentor, Compass and what their customers
are saying instead of what their marketing departments are saying, attend. If
these issues really don't effect you or your project, you may wish to consider
staying in Boston and working. My inspiration for creating ESNUG came not from
anything Synopsys, Inc. did as much as what I learned from fellow Synopsys
users at the SNUG conference. In fact, there were a few times at SNUG when I
walked out of the occassional lame talk (like their discussion panel on <yawn>
"Is Synopsys High Level Design?" last year) to talk with other users in
the hallway. I can't stress this point too much. These conferences are great
not because users come to hear clowns like myself speak "wisdom" as much as to
discussing with each other what they're seeing using the software. I took this
essense and kept it going all year by creating ESNUG.
Another thing is that SNUG (not ESNUG), for the past two years, has failed
to get anyone willing to be on it's board of directors. (Remember in the last
two SNUGs there were those forms asking customers to write campaign statements
to be elected to the SNUG board? Well, it looked like no one stepped forward
except me and Kurt Baty from what I've heard.) This has resulted in Synopsys
employees being stuck deciding who's speaking and what's being presented at
SNUG. I've heard that this time around it looks like we may actually get
enough people interested in the board of SNUG. I'd like to get in on that
because I believe SNUG should be independent from the control of the Synopsys,
Inc. but funded by Synopsys, Inc. -- sorta like the Cadence User Group.
In addition, as the ESNUG Founder and Moderator, I have a number of issues I
have to discuss with Synopsys, Inc. concerning issues like getting: a complete
set of Synopsys Methodology Notes, a complete set of 3.0 manuals, being on the
customer mailing list and maybe even some funding to help defray the costs of
running ESNUG along with other issues. (You've got to understand that ESNUG
is *independent* of any control from Synopsys, Inc. - it's a grassroots voice
of 1500 customers that's free to say good things and bad things about what we
as customers are seeing using Synopsys, Verilog, VHDL, etc. I've got the
tricky task of trying to negotiate for this ESNUG support without really having
anything to offer in exchange other than I'll keep running ESNUG independent
of anyone's control (which ain't exactly a great barganing position).)
- John Cooley
ESNUG Moderator
( Post 114 Item 2 ) --------------------------------------------------------
Subject: (Post 113 Item 4) "Seeking Queuing Software"
>John - I am looking for some publicly available queuing software
>for running many Synopsys jobs in sequence, so I don't have to
>pay THEM more money. Does anyone in ESNUG have any utilities, or
>even just names of utilities??
>
> John Spillane, Data General Corp.
- - - - - - - - -
From: danw@wellfleet.com (Dan Westerberg)
Hi John,
This is in response to John Spillane's request for a queueing system. For
the past several years, I have been using the Multi-Device Queueing System,
or MDQS. It can be retrieved from : "gatekeeper.dec.com" as : "/net/ip
/applic/mdqs.2-16.tar.Z"
This system is quite powerful and very easy to configure. It also claims to
be fairly secure, but I really don't know.
Hope this helps,
Dan Westerberg
Wellfleet Communications, Bedford MA
- - - - - - - - -
From: deo@kurt.smos.com (Trevor Deosaran)
There is a program called queuer from comp.sources.unix (volume22) queuer
/part[01-03] -- Multi-system program queueing package.
archive-server note: You must prefix the filename with the volumenumber. E.g.
send volume1/cpp/part1 from comp.sources.unix
send volume9/elm2/part14 from comp.sources.unix
We intended to use this for Verilog but it's program indpendent.
Try it and post results on ESNUG! -- deo
( Post 114 Item 3 ) --------------------------------------------------------
From: Trevor <trevor@ncd.com>
Subject: "wait until" fatal bug in v3.0a
I have identified the following bug which will crash v3.0a of the synthesis
tool. (I don't know about v2.2b)
The code is of the type ....
..
for n in 0 to index generate
process
begin
wait until clock'event and clock = '1';
if Enable(n) then
Reg(n) <= input;
end if;
end process;
end generate;
..
Replacing the "wait until" with the "if clock'event ... " construct fixes
the problem.
It has been logged by Synopsys.
-- Trevor
( Post 114 Item 4 ) --------------------------------------------------------
From: [ Mystery Man ]
Subject: Multi-Cycle State Machine Synthesis
John, please make this anonymous.
I am concerned about Synopsys potentially using inputs to a state machine
while they are invalid even though the state machine description should cause
the inputs to be ignored while invalid.
For example, suppose I need to run on a 40ns clock. I have another chip I need
to talk to, but when I assert REQ it can take up to 65ns to receive the ACK
back. No problem, if I assert REQ in state S1, go unconditionally to state S2,
and then in state 3 evaluate the reply (ACK present or not?). But it seems
possible for Synopsys to reduce the next-state logic in such a way that the
transition from S1 to S2 depends on ACK and ACK* having opposite values.
(ACK* is the internal negation of ACK by the gate array). If Synopsys
does this, and if I have a fast chip that returns ACK around 40ns or so
after REQ is asserted, the hazard in the combinatorial circuitry while REQ
going from 0 -> 1 may cause ACK and ACK* to temporarily not have opposite
values; this would clobber the next-state logic.
I have a couple of questions for Synopsys users. Is this scenario even
possible? If so, are there ways to detect it and correct it?
|
|
