OK Xilinx users, it's time I was let in on the joke...

If you're using makefiles, you might want to investigate xflow, which is the 
xilinx flow manager.  It takes a text file which has all the options for all 
the backend tools, runs the tools in order, checking the status of the 
previous step before running the next step.  It's similar to a makefile flow 
but more flexible I'd say.

Outside of some vendor training classes I've never actually run the ISE gui.

I do however use the synplify GUI, both for synthesis and to drive P&R. 
That's how I found out about xflow.

--steve

"Oscar Almer" <o.almer@gmail.com> wrote in message 
news:20091106130119.19849884@hummingbird...
:
: I, at least, gave up on the ise wrapper about a year and a half ago -
: it just didn't do it, anymore. Instead I drive the flow (xst, map, par,
: etc) from a single makefile, and a short one at that - maybe 20 lines.
:

On Mon, 9 Nov 2009 13:28:12 -0600
"Steve Ravet" <steve.ravet@arm.com> wrote:

> If you're using makefiles, you might want to investigate xflow, which
> is the xilinx flow manager.  It takes a text file which has all the
> options for all the backend tools, runs the tools in order, checking
> the status of the previous step before running the next step.  It's
> similar to a makefile flow but more flexible I'd say.
>=20
> Outside of some vendor training classes I've never actually run the
> ISE gui.
>=20

=46rom your description, the other thread on here, and a quick read on
Xilinx's site, it seems like it's a bit of a domain-specific
reimplementation of make with particular quirks. I suppose the upside
is that it's supported under windows as well, where you don't usually
get make without a bit of effort.=20

I am somewhat surprised about the assertion that it's more flexible
than make, as the entire point of make is to be as generic and
flexible as possible.=20

Thanks for pointing it out, as I was previously unaware of it, and it
might come in handy one day.=20

//Oscar

On Nov 10, 5:17=A0am, Curt Johnson <curt.john...@dicombox.net> wrote:
> malcolm wrote:
> > Err, but a random-deleted net is actually easy to find, as you usually
> > have more than one copy (as in, in the SCH, or even in a copy of the
> > PCB ) ?
>
> > Which Mentor flows/versions are you using ?
>
> If I have plots from an earlier revision, I compare them with the new
> revision one page at a time on a light box. Every difference has to be
> traced to ensure that it is an intended change.
>
> On a 10 layer PCB with 4 BGAs, about a dozen smaller packages and a
> couple of hundred discretes, it takes me two or three days.
>
> Not difficult, but extremely tedious.

yes, that I can believe...

 However, PADS does allow an ASCII compare, which will do that
comparison in seconds ?.

 You can also safely re-import a netlist at any time,
and it simply skips existing pin pairs, and will add any missing ones,
which will stand out as unrouted.

ASCII export/import also checks your database integrity, as it
rebuilds the design. DXF does the same.

 You can also generate reports that count pin pairs/nets etc..

Or, if you want a more modern lightbox, we use GerbView:

http://www.softwarecompanions.com/gbupdate.html

This will export layered PDFs, and import multiple gerbers, and is is
low cost. Works well with PADS.


>
> Viewdraw & Pads. I'm using Viewdraw (or DxDesigner I think they call it
> now) version 2006.1. I havn't been able to get the 2007 release to read
> in any of our current projects.
>
> The random net deleting feature has been in place since before I started
> here in 1993; but before BGAs, we could always rework the boards.

Is it Viewdraw, or Pads that drops the info ?
Is this a whole net, or a pin-pair ?

-jg

-jg wrote:
> 
>  You can also generate reports that count pin pairs/nets etc..

That's an excellent idea. Matching net reports across revisions might 
save some time. Thank you.

>  You can also safely re-import a netlist at any time,
> and it simply skips existing pin pairs, and will add any missing ones,
> which will stand out as unrouted.
> 
> Is it Viewdraw, or Pads that drops the info ?
> Is this a whole net, or a pin-pair ?
> 
Re-importing the netlist seems to be the issue.
Entire nets disappear and the previously routed tracks are ripped up and 
discarded. I can't say for sure that there is no indication that 
anything is wrong, since another engineer is responsible for the PADS 
side, but if there is, it isn't obvious enough for her, nor her 
predecessors, to notice.

Curt

My mistake.  It's nothing like make and is not more flexible than make, 
although it is simpler than make.  I meant to say it is more flexible than a 
batch file implementation.

--steve

"Oscar Almer" <o.almer@gmail..com> wrote in message 
news:20091111111327.632100c8@hummingbird...

I am somewhat surprised about the assertion that it's more flexible
than make, as the entire point of make is to be as generic and
flexible as possible.

Thanks for pointing it out, as I was previously unaware of it, and it
might come in handy one day.

//Oscar

On Nov 12, 9:21=A0am, Curt Johnson <curt.john...@dicombox.net> wrote:
> -jg wrote:
>
> > =A0You can also generate reports that count pin pairs/nets etc..
>
> That's an excellent idea. Matching net reports across revisions might
> save some time. Thank you.
>
> > =A0You can also safely re-import a netlist at any time,
> > and it simply skips existing pin pairs, and will add any missing ones,
> > which will stand out as unrouted.
>
> > Is it Viewdraw, or Pads that drops the info ?
> > Is this a whole net, or a pin-pair ?
>
> Re-importing the netlist seems to be the issue.
> Entire nets disappear and the previously routed tracks are ripped up and
> discarded. I can't say for sure that there is no indication that
> anything is wrong, since another engineer is responsible for the PADS
> side, but if there is, it isn't obvious enough for her, nor her
> predecessors, to notice.

 The humble netlist is a very good audit-check, and the supposedly
smarter direct linkages may be quicker, but they can also sometimes be
riskier....

 So, if the changes are simple, I'd suggest using net-import-merge
(that does NOT rip up any traces, but it does need some manual
groundwork)
 If the changes are more complex, then use direct-linkages, but
_follow_ that with a netlist import/compare check.

 ie The old "trust, but verify"  :)

-jg

On Nov 6, 1:13=A0am, Antti <antti.luk...@googlemail.com> wrote:
> On Nov 6, 8:14=A0am, Mark McDougall <ma...@vl.com.au> wrote:
>
>
>
> > I've had it up to the eyeballs with Xilinx tools now. I'm seriously rea=
dy
> > to go postal in the lobby of Xilinx HQ. I don't expect perfection but t=
his
> > really is beyond a joke.
>
> > Can someone please put me out of my misery, and finally admit that you
> > have _all_ been having me on for the past few years now! :O ...that it =
has
> > all been an elaborate hoax instigated by someone I offended in a past
> > life. ...that a team of engineers has been working for years to produce=
 an
> > IDE that crashes randomly, and steadfastly refuses to launch tools on
> > Tuesday mornings and Friday afternoons? ...working for years on a
> > synthesizer that removes random bits of logic, or sits spinning in an
> > infinite loop on an entity that works in another project? ...that corru=
pts
> > my project file bi-monthly.
>
> > And worst of all - _you_ lot, telling me that Xilinx actually works, an=
d
> > that you _can_ use it for more than flashing LEDs on the Spartan starte=
r
> > kit. And I was gullible enough to believe you! :O :(
>
> > I've seen the light. You _cannot_ convince me that it is possible to
> > produce a commercial product in silicon using these tools. Period.
>
> > Regards,
>
> > --
> > Mark McDougall, Engineer
> > Virtual Logic Pty Ltd, <http://www.vl.com.au>
> > 21-25 King St, Rockdale, 2216
> > Ph: +612-9599-3255 Fax: +612-9599-3266
>
> Mark,
>
> you are taking it one level higher than I, I think i have said in
> public
> years ago that Xilinx has totally lost control over its software
> development
> and that their tools would come "completly unuseable" by the time 40nm
> FPGA's come out to the market (unless they FIX their software
> development flow!)
>
> well Xilinx 40nm FPGA's are not yet on stock at digikey, so based on
> that
> and on my prediction Xilinx has still time to reach the complete
> useless
> status with their software
>
> Antti

That sounds bad for the X-sw team.  I think that's the area they may
want to check out first.  Yup, they- themselves have bugs to de-bug