1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

# Messages from 19000

Article: 19000
Subject: Re: VHDL vs. schematic entry
From: Ray Andraka <randraka@ids.net>
Date: Tue, 23 Nov 1999 17:36:54 -0500
Links: << >>  << T >>  << A >>


Robert Sefton wrote:

> Just a couple of points to add to the discussion:
>
> > Has the move to VHDL reduced design entry time?
>
> On intial entry I'd give VHDL the edge. But when a module has to
> be ripped up to add something or make other changes I think VHDL
> is significantly faster. I always wanted my schematics to look
> pretty and it's much easier to re-format a text file than a
> multi-sheet schematic. Also, you can't beat the unlimited space
> for comments in a text file.
>
> > Is design maintenance easier?
>
> One major advantage of schematics over VHDL for FPGAs that I
> haven't seen mentioned is guided routes. I remember re-spinning
> designs through the old XACT tools (ppr) using the guided route
> option in a couple of minutes (vs. 2-3 hrs for a complete
> re-route) after a minor change. With the VHDL/synthesis path
> guided route is not an option. The only way to significantly
> reduce place and route times is to lock everything down, which is
> a pain in VHDL.

This is true.  Working with the floorplanner can be cryptic with a
synthesized design as well.

>
>
> On the other hand, source control programs like ClearCase work
> much better with text files than schematics. If you plan to use
> source control (vital for large projects) an HDL is the way to go.
>

Viewlogic files are ascii text files, so they can be put under source
control the same way.

> > Is design reuse easier?
>
> We built a large library of VHDL modules (counters, muxes, FIFO
> controllers, etc.) that is built around vendor (in this case
> Lucent) library elements. The modules are parameterized using
> generics and are built optimally for the target architecture. All
> the low-level grunt code of building these things is buried in the
> library. Great resource for a big project. I don't know how this
> could be done with schematics. Someone has to write the library,
> though.

I've done that to some degree in schematics by building a library of one
and two bit placed slices.  It's a lot faster to build a placed
arbitrary width widget out of these blocks than starting fresh each time
or hacking up a crowded page of primitives.  I rarely have to use FMAPs
in my day to day work even though much of what I do is placed in the
schematics because the FMAPs are in the slices.  This also gets a
significant design reuse.

>
>
> > Bottom line: Was it worth it?
>
> Yes. You may not have a choice eventually. I think the FPGA
> vendors would prefer to quit supporting schematic entry
> completely. Hopefully some day the HDL flow will be improved to
> the point that there is no reason to use schematics any more.
>

No reason in whose opinion.  Xilinx already tried that when they
introduced Virtex.  There is, and I think will likely continue to be a
place for both design entry methods.  I do use both, and like each for
different reasons.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19001
Subject: Re: How to use GSR-net in Virtex?
From: Ray Andraka <randraka@ids.net>
Date: Tue, 23 Nov 1999 17:40:54 -0500
Links: << >>  << T >>  << A >>


Dragon wrote:

> I had the impression that metastability only occurs at the D inputs. If the
> GSR deasserts and violates the flop's setup time, can the flop still go
> metastable?

Most certainly.  In this case, the reset/set may go away close enough to a
clock edge when the D input is a '1'.  Presto, instant metastability.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19002
Subject: Re: Why not Lucent ORCA FGPAs?
From: Ray Andraka <randraka@ids.net>
Date: Tue, 23 Nov 1999 17:46:19 -0500
Links: << >>  << T >>  << A >>
I think EPIC is a piece of  %*&$compared with the old XDE as far as stability and user friendliness goes. Dragon wrote: > Amen! Its a shame EPIC doesn't feel more like the Floorplanner. When we > migrated to M1 I hoped for something like that. I must admit EPIC is worlds > better than the XACT editor, but still falls way short of user-friendly. BTW, > anyone know if Xilinx plans to upgrade the Floorplanner to include the > Virtex flow? Anyone see M2 yet? M2 has a floorplanner for Virtex. The inclusion of the floorplanner was a key piece I needed before I started recommending VIrtex to my customers. Before that, I generally recommended against Virtex unless you absolutely needed the block RAM. The Virtex tools are still not quite ready for prime time, but they are close enough. M2 has been out for quite a while now. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 19003 Subject: Re: How to use multiple resets? From: Ray Andraka <randraka@ids.net> Date: Tue, 23 Nov 1999 17:49:13 -0500 Links: << >> << T >> << A >>  Dragon wrote: > > > I believe Spartans are simply XC4000's without RAM capability. Outsideof > this, what holds true for XC4000's should hold true for Spartans. > No, they are without the async RAM capability. They still have the sync RAM. They also don't have the WANDs, and all the parallel configuration modes are gone. It is also I die shrink, and doesn't come in the higher power packages. Otherwise, the architecture is pretty much the same. For most designs, you won't notice the difference between spartan and 4KE devices. > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka  Article: 19004 Subject: Re: implementing TCP/IP on PLD From: gillies@cs.ubc.ca (Donald Gillies) Date: 23 Nov 1999 15:23:06 -0800 Links: << >> << T >> << A >> "Dirk Bruere" <artemis@kbnet.co.uk> writes: >Joseph C. Su <sujosep@sympatico.ca> wrote in message >news:cEo_3.62916$up3.99009@news21.bellglobal.com...
>> Do you think it is realistic for an undergraduate design project to
>> undertake the task of implementing TCP/IP on FPGA ( i dare not to use the
>> term "pld" anymore), given a team of three not very smart students?

TCP is an unrealistic thing to implement on an FPGA - no matter what
the time frame, no matter who is doing it.  A good TCP has some very
complex sub-algorithms.

Moreover, another problem is that a protocol such as TCP is extremely
hard to understand and define fully, and it is unlikely for some
undergraduates to even understand the problem fully in a 1-semester
time frame.

These two issues are a recipe for disaster.

Once upon a time, I wrote a software TCP on my own in 1 semester as
part of my MIT undergraduate thesis.  Because of the difficulty, the
TCP became the *entire* thesis - and in those days I used to win
programming contests for my speed at programming.  I had a working
single-process TCP already (PC/IP) and the "TCP Implementer's Guide"
which is part of RFC793.  I barely got it working and then I "de-tuned
it" so that it would work with slightly flakey other types of TCP's.
This was a very full one semester project, about 4 hours a day (the
whole afternoon) From Jan 1st through May 10th.

If you are looking for a network protocol for hardware implementation,
why not look at XTP (express transfer protocol, designed by Greg
Chesson in the late 1980's).  This protocol would be much easier to
implement in hardware.  Also, you would have to add a lot of structure
to the problem ( such as decomposing the problem into correct sub
problems before giving it to the undergraduates ).

Don Gillies - t_dgilli.x@qualcomm.x.com - Planetwide Software, Inc.
(consultant) / Globalstar Satellite CDMA Project, Qualcomm Inc.,
6455 Lusk Blvd San Diego, California 92121 - phone: 619-651-2326.
http://www.ee.ubc.ca/home/staff/faculty/gillies/etc/www/index.html
(remove x's to reply by email)

Article: 19005
Subject: Re: VHDL vs. schematic entry
From: bob@nospam.thanks (Bob Perlman)
Date: Tue, 23 Nov 1999 23:38:02 GMT
Links: << >>  << T >>  << A >>
Hi -

>> > Bottom line: Was it worth it?
>>
>> Yes. You may not have a choice eventually. I think the FPGA
>> vendors would prefer to quit supporting schematic entry
>> completely. Hopefully some day the HDL flow will be improved to
>> the point that there is no reason to use schematics any more.
>>
>
>No reason in whose opinion.  Xilinx already tried that when they
>introduced Virtex.  There is, and I think will likely continue to be a
>place for both design entry methods.  I do use both, and like each for
>different reasons.

There's support, and then there's *support*.  Years ago I worked on a
project where we did Xilinx FPGA designs with the Cadence Concept
schematic capture tool, then used a Cadence/Xilinx-supplied netlister
to create XNF files (I say "Cadence/Xilinx" because ownership of the
tool bounced between the two companies for a while).  The netlister
was an absolute abomination; it never worked quite right, and updates
to accommodate new devices and features were always months behind

We also used Viewlogic to support one or two designs that were done in
Viewdraw.  On one occasion I got a maintenance agreement covering both
the Viewlogic and Cadence netlisters and, as these agreements often
do, it listed the serial numbers of each tool.  The Viewdraw netlister
serial number was around 1200, while the Cadence netlister was around
10.  And at that point an all-too-obvious lesson was driven home: make
sure that the tools you're depending on for product shipment are not
only supported, but are used by lots of other people who are going to
scream loudly when they don't work.  (But I'm willing to go out on a
limb and try something new, or something very old, as long as it's not
mission-critical.)

I've used both schematic entry and Verilog HDL for FPGA design.  Each
has its strengths and weaknesses, and I'd like to see both options
remain available indefinitely.  But I'm concerned that if there are X
people doing schematic capture and 50X doing HDL design, support for
schematic design may continue to exist in name only.

Another person who's sad to see useful tool chains disappearing,
Bob Perlman

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------

Article: 19006
Subject: Re: How to use GSR-net in Virtex?
From: murray@pa.dec.com (Hal Murray)
Date: 24 Nov 1999 00:52:17 GMT
Links: << >>  << T >>  << A >>

> I had the impression that metastability only occurs at the D inputs. If the
> GSR deasserts and violates the flop's setup time, can the flop still go
> metastable?

Yes.

If you open up the D ff and look inside at the gates or
transistors, it boils down to the same problem.

The key words are setup and hold.  Any signal described that
way on the data sheet will have metastability problems if you
don't meet the specs.

A clock qualifier is the other one I can think of right now.

Note that an asynchronous set/reset input doesn't have any
metastability problem on the going-active transition, only
when going inactive, and then only if the data on the D
input would cause a state change.  Synchronous inputs can
have troubles on both edges.

--
These are my opinions, not necessarily my employers.

Article: 19007
Subject: Re: VHDL vs. schematic entry
From: Jonathan Bromley <jonathan@oxfordbromley.u-net.com>
Date: Wed, 24 Nov 1999 01:24:05 +0000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> > On the other hand, source control programs like ClearCase work
> > much better with text files than schematics. If you plan to use
> > source control (vital for large projects) an HDL is the way to go.
>
> Viewlogic files are ascii text files, so they can be put under source
> control the same way.

A "diff" between successive versions of a Viewlogic schematic text file
is unlikely to be helpful, whereas a "diff" between two successive
versions of a piece of VHDL is likely to be quite informative :-)

Jonathan Bromley

Article: 19008
Subject: Re: VHDL vs. schematic entry
From: <malino@primenet.com>
Date: Tue, 23 Nov 1999 19:47:19 -0700
Links: << >>  << T >>  << A >>
Things change so do the way we design, either keep up with the industry or
become obsolite.  I have been doing digital designs for 30 years and find
that I must keep up with current design techniques of become unemployed.

Walt

Greg Neff <gregneff@my-deja.com> wrote in message
news:81cjav$opg$1@nnrp1.deja.com...
> In article <38398D1C.A7B9E445@ids.net>,
>   Ray Andraka <randraka@ids.net> wrote:
> > Don Husby wrote:
> >
> (snip)
> > >
> > > I agree that schematics are still the best way to enter a design.
> I just
> > > thought I would beat my head against the VHDL wall one more time
> before
> > > going back to schematics.
> >
> > I've been using, no beating my head against the wall, with VHDL
> lately too.
> > I'm doing it for two reasons: First I have some customers who bought
> the VHDL
> > thing hook, line, and sinker (try to convince them they're wrong!),
> and for my
> > own stuff because it allows me to parameterize functions pretty
> easily.  I'm
> > beginning to wonder if I'll ever see the return on the design
> investment for
> > those parameterized thingies though.
> >
> (snip)
>
> I having been using schematic entry for FPGAs, probably because I have
> been drawing schematics since before the days of PALs, let alone
> FPGAs.  I am now considering taking the leap to VHDL entry, but I am
> not convinced that there will be a benefit in either time to design or
> design quality.  The above comments seem to be indicative of those like
> myself, who are highly skilled at schematic entry for FPGAs.
>
> I'm not talking about a situation where a team of engineers is
> designing a mega-gate FPGA.  I am more interested in small to mid-range
> (say, up to 100K gate) designs that are being entered and maintained by
> one person.
>
> I would be interested to hear from those people that have gone through
> the VHDL learning curve.
>
> Has the move to VHDL reduced design entry time?
> Has the design quality improved (fewer problems)?
> Is design debugging easier?
> Is design maintenance easier?
> Is design reuse easier?
> Did you get to the point where VHDL is more efficient than schematics?
> If so, how long did it take to get to this point?
> Bottom line: Was it worth it?
>
> I would like to hear from Don and Ray, to see if they consider
> themselves to be still on the learning curve, or if they truly think
> that VHDL is not worth the hassle.
>
> --
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com
>
>
> Sent via Deja.com http://www.deja.com/


Article: 19009
Subject: Re: VHDL vs. schematic entry
From: steve (Steve Rencontre)
Date: Wed, 24 Nov 1999 03:00 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <81cqsb$pb$1@news.fsr.net>, pladow@gocougs.wsu.edu () wrote:

[Most snipped]

Agreed, particularly:

> On a final note, I'm not saying that schematic entry is worthless.  In
> fact,
> I use it often.  For low-level design, we do VHDL entry.  We then
> generate
> symbols and link them to the VHDL.  Using schematic entry, we connect
> all
> the designs together in the top level.  We then simulate the top-level
> with
> all the blocks together.
>
> Also, schematics serve as a visual que to data-flow.  I like to see data
> enter on the left-hand block, progress through the pipelines, and come
> out of
> the right-hand block.  It also makes it easy to document what parts of
> the
> design are in different stages of completion.  But in this role, the
> top level
> is nothing more than a glorified block-diagram.  But I will admit,
> hooking
> up the top level in schematic form is much easier than in VHDL!  But,
> if I
> needed to changed the top level layout later, I'd rather do it in VHDL.

I take exactly the same approach. Top level block diagrams are much easier
to understand than text, but when things start getting detailed,
schematics are not my choice.

This may be a question of background. I've been writing software as long
as I've been doing electronics (>25 years, man and boy), and I find an
exactly parallel situation there. Flowcharts, UML, visual programming,
etc, are all good tools for design, and you can do a lot by pushing icons
around, but at the end of the day, you need C++ or assembler or whatever
to get the real work done.

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk

Article: 19010
Subject: Re: Anybody using Lucent OR3TP12?
From: Bryan Williams <bkwilli_@at_smart.net>
Date: Wed, 24 Nov 1999 03:22:14 -0500
Links: << >>  << T >>  << A >>
email address is altered to prevent spam.
I'd recommend the part only if you hate yourself and are looking for a
reason to end it all ;)

Jokes aside, we've been trying to use this part, and there's a lot of pain
Lucent parts brings up many of these points.  Have you found a proto-board
based on this part? If so, I'd like
to hear about it, but I don't think it exists because I've spent mucho time
looking through all the lists at optimagic
and other sites to no avail.  Like someone else pointed out, Xilinx & Altera
make FPGA's and hardly anything else. Lucent makes so
many types of products it would be nearly impossible for one list them all.
Who's gonna try harder?

We're in the process of getting Xilinx's PCI design kit. One thing I like
about it is the ability to target anything from a cheap Spartan
(is there really any FPGA competition for Spartan's market?) to the biggest
Virtex. I'll know more when it's in hand.

Lucent's tools are now behind the times. Xilinx bought Neocad, old news, but
the Lucent back-end tools haven't changed a lot since then.
A bit rough around the edges.  I'm not sure how Lucent explains their
think they took the existing codebase and found new programmers to take over
the code and go in their own direction, but I'm speculating.

A problem you'll immediately find is that so far as I can tell the OR3TP12
is EXCLUSIVELY FOR VHDL/Verilog.  That's the way the
core parameters are passed and it's your only option.  The core setup tool
is a pain too since you can't save your settings to revise them later.
It fleshes out a VHDL/Verilog template and you can't go back to the GUI to
tweak settings later. Write them down ! We're using Synplify for the
VHDL, FYI.

There's a lot of nifty things the hardwired core allows you to do, but
there's also the drawback of it being considerably more effort for them to
roll
out new chips. Your only option right now is the pared-down OR3C/T55 -sized
device (sans about 4 rows for the PCI core) with other parts "coming soon
now"
for quite some time now. Our local apps engineer went back to the plant to
"help roll out the next device" or something, which left us without
good support. The hardwired core has many bugs, and the downside of these
bugs is that it's not a simple fix being hardwired and all.

The core setup software had a bug we were stuck with for quite some time
before receiving an update -- the BYTES were OUT OF ORDER in the 32-bit
words.
How the hell do you miss something like that in testing? Luckily, it WAS
software.

My guess is that if you go with the part you will feel very alone with
whatever problems you come across. We sure do.

One good way to judge your FPGA vendor: go see how many application notes
they have. Lucent's got maybe 10 or 20 total on the web. Xilinx has probably
a thousand
or more scattered across the Xcell Journal and general app notes. I like
that.

The Xilinx PCI design kit comes with a board based on the core and a
reference design. PCI is complicated as hell and that reference can save
MONTHS.
BW

Edward Wallington wrote:

> Hi,
> has anyone put a design into production using the OR3TP12 on a card in a
> PC?
> (this is Lucent's part FPGA, part hardwired ASIC PCI core)
>
> Which synthesis route / tools did you use?
> Any gotcha's ? Did it work perfectly?
>
> Thanks
>
> Ed.
>
> --
> Edward Wallington - Chief Hardware Engineer
> Cambridge Research Systems Ltd.
> Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719
> http://www.crsltd.com


Article: 19011
Subject: Re: Trouble with ATMEL's AT40K20
From: "Filip S. Balan" <balan@uni-mb.si>
Date: Wed, 24 Nov 1999 09:39:20 +0100
Links: << >>  << T >>  << A >>
Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>...
>Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>...
>>>>**Symplify (simulates the HDL design fine all the time)
>>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>I missed 1 SW:
>>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time)
>
>
>Did you use timing constraints and are they being met?
>

Think it is not important. The input of the shift register is at one input
pin
and the output of the shift register (last bit) at another (output) pin. A
logic
"1" should after some time (Tclk * N+eventual timing problems) cause a logic
"1" and a "0"  a "0".
I used this simple TEST design just for this insensibility (if the delay is
not important to me).
But the output is sometimes (in dependence of cell positions) stuck at "0"
or "1" (it does not change)!

__________________________________________________________________________
Filip S. Balan

Faculty of Electrical Engineering and Computer Science
Institute of Electronics
Smetanova 17
SI-2000 Maribor
Slovenia

Phone:  +386 62 220 7202
Fax:  +386 62 211-178
E-mail: balan@uni-mb.si
__________________________________________________________________________


Article: 19012
Subject: Non-dedicated clock
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Wed, 24 Nov 1999 01:07:21 -0800
Links: << >>  << T >>  << A >>
Dear friend,
Yesterday  I have got following message from Xilinx Alliance design
manager

WARNING:Timing:33 - Clock nets using non dedicated resources were found
in this
design. Clock skew on these resources will not be automatically
during path analysis. To create a timing report that analyzes clock
skew for
these paths, run trce with the '-skew' option.

But I'm sure to use only dedicated clock resources. And place all my
clock nets on bufg or bufgp.
1. How can I find out which net exactly or in which component Xilinx
means.
2. I have never started trce manualy. Is it any say to Design manager
to run trce with -skew option.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


Article: 19013
Subject: Re: How to use multiple resets?
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Wed, 24 Nov 1999 10:30:20 GMT
Links: << >>  << T >>  << A >>
On Tue, 23 Nov 1999 17:49:13 -0500, Ray Andraka <randraka@ids.net>
wrote:

>
>
>Dragon wrote:
>
>>
>>
>> I believe Spartans are simply XC4000's without RAM capability. Outsideof
>> this, what holds true for XC4000's should hold true for Spartans.
>>
>
>No, they are without the async RAM capability.  They still have the sync RAM.
>They also don't have the WANDs, and all the parallel configuration modes are
>gone.  It is also I die shrink, and doesn't come in the higher power packages.
>Otherwise, the architecture is pretty much the same.  For most designs, you won't
>notice the difference between spartan and 4KE devices.

I recall that there was a post in this news group some time ago that
Spartan part, and it had functioned exactly like the 4000e part.

Makes sense when you think about it - a significant amount of Xilinx's
(or any other vendors') overheads will come from the costs of
developing software, so they can save a lot of money and get to market
quicker if they make the costdown parts exactly equivalent to the
originals, at least for the initial rev of silicon.

Earlier today a Xilinx rep told me that they already have support for
the Spartan-2 parts in their current software (even though they won't
even announce the family until next year).  This implies to me that
the Spartan-2 will be bitstream compatible with Virtex.

I may be wrong of course.

Allan.

Article: 19014
Subject: MACH445 - parallel port programming cable
From: Guido Pohl <pohl@fokus.gmd.de>
Date: Wed, 24 Nov 1999 13:38:38 +0100
Links: << >>  << T >>  << A >>
Hello and a good day out there,

I'am searching for the pin-out of a programming cable used for a MACH445, i.e.
to program it from a PC parallel port ...
I couldn't find any information to this topic - is it a secret 8-?

I know that AMD's MACH is nowadays a M4-128/64 from Lattice.

Thank you for any hint to my request.

Sincerely, Guido

Article: 19015
Subject: Re: MACH445 - parallel port programming cable
From: Guido Pohl <pohl@fokus.gmd.de>
Date: Wed, 24 Nov 1999 13:42:29 +0100
Links: << >>  << T >>  << A >>
Hello again, (sorry)

I forget to say that I intend to use the old AMD MACHXL2.1 software to download
the jedec file ...

Thanks, Guido

Article: 19016
Subject: Re: Hierarchical Scan Insertion
From: Ravi Chandra Anantha <arc-ssgNOarSPAM@myw.ltindia.com.invalid>
Date: Wed, 24 Nov 1999 05:37:12 -0800
Links: << >>  << T >>  << A >>
Hi,
As I see from the Question, Design is about 80K, i want to
know gate count of Sequential elements( No. of Flops),
If it is possible Group the all the flops in to new
Heireachy, then do scan insertion for new module.
Grouping can be done with reference to cell name,
If All sequential elements are at one place, hope
routing is easy.

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful

Article: 19017
Subject: Re: VHDL vs. schematic entry
From: Greg Neff <gregneff@my-deja.com>
Date: Wed, 24 Nov 1999 15:11:57 GMT
Links: << >>  << T >>  << A >>
In article <hAo7OGCUqVpuedBjHwKsQ44FTFG5@4ax.com>,
John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote:
(snip)
> We actually don't spend much time debugging uP code or FPGAs because
of our
> philosophy: design carefully, document and comment thoroughly, check
it before
> you fire it up, and keep it beautiful at all times. I dislike
habitual use of
> simulation because it tends to lead designers toward a hack-and-test
mode, and
> one can never really test quality into anything. So far, we've had
zero
> hardware/software/FPGA bugs in the products we've shipped that have
FPGAs.
>
> Anyway, we do fairly hairy FPGA designs using schematics, and the
stuff comes
> out fast and relatively easy. I just thought *somebody* ought to
express that
> opinion.
>
(snip)

I think that Ray was commenting on those engineers that use the "burn
and learn" approach to design, which is very risky and unpredictable.
If I understand your comment correctly, you are trying to avoid a
similar "simulate and learn" approach.  Although neither is a good
design methodology, I would imagine that it would still be better to
learn at the simulate stage, as opposed to the hardware stage.

The "correct by design" approach (which is what I think you are
promoting) still requires some sort of method to validate and
verify "correctness".  Complete specifications, careful and well
documented designs, and design reviews are obvious requirements to
implement a correct by design methodology.  Still, I find it hard to
believe that simulations are not faster and more reliable than manual
analysis when it comes to validating a design.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Sent via Deja.com http://www.deja.com/

Article: 19018
Subject: Obselete processor substitutes
From: "log" <internet1@microsense.co.uk>
Date: Wed, 24 Nov 1999 15:14:17 -0000
Links: << >>  << T >>  << A >>
This might not be strictly an FPGA question, but does anyone know if it is
currently possible to get obselete microprocessors emulated on fpgas or
other platforms.  I need a seamless cross over from an old one time 8749 to
something which looks electronically the same when in circuit.

Any suggestions or ideas gratfully received.

Mark        email pleydellm@microsense.co.uk


Article: 19019
Subject: Re: Trouble with ATMEL's AT40K20
From: Werner Dreher <dreher@informatik.uni-tuebingen.de>
Date: Wed, 24 Nov 1999 16:28:06 +0100
Links: << >>  << T >>  << A >>
Filip S. Balan wrote:
>
[...]

> Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>...
> >
> >Did you use timing constraints and are they being met?
> >
>
> Think it is not important. The input of the shift register is at one input
> pin
> and the output of the shift register (last bit) at another (output) pin. A
> logic
> "1" should after some time (Tclk * N+eventual timing problems) cause a logic
> "1" and a "0"  a "0".
> I used this simple TEST design just for this insensibility (if the delay is
> not important to me).
> But the output is sometimes (in dependence of cell positions) stuck at "0"
> or "1" (it does not change)!

Hello Filip,

I'm not familiar with the Atmel parts, but an idea:
do you use a dedicated clock net, or normal routing resources for the
clock? By using normal routing recources, it's possible that the clock
delay from flipflop n to flipflop n+1 ist greater than the data delay.
In this case, at the active clock edge flipflop n+1 will not take the
"old" value of flipflop n, but the new.

Greetings
Werner

Article: 19020
Subject: Re: VHDL vs. schematic entry
From: "David G. Koontz" <koontz@ariolimax.com>
Date: Wed, 24 Nov 1999 08:18:20 -0800
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
>
> Ray Andraka wrote:
> > > On the other hand, source control programs like ClearCase work
> > > much better with text files than schematics. If you plan to use
> > > source control (vital for large projects) an HDL is the way to go.
> >
> > Viewlogic files are ascii text files, so they can be put under source
> > control the same way.
>
> A "diff" between successive versions of a Viewlogic schematic text file
> is unlikely to be helpful, whereas a "diff" between two successive
> versions of a piece of VHDL is likely to be quite informative :-)
>

Viewlogic files are not cannonized, the order of elements output
into one is dependent on the state of a database image (which
also depends on the order it is read in from text sources).  Without
recourse to a program for ordering the file,  you can treat them
the same way you would a binary file, every check adds the current
file to its archive.

Way back when, we used to have a program for cannonizing gem
files.  (A 2D editor used for chip layout/design, and schematic
entry written by Gary Tarolli).  There is no pressing need for
cannonization for viewlogic files - disk space is relatively cheap.
and you'd be hard pressed to generate schematics bigger than
Now what would be interesting would be visual differences.  The
same could be said about HDLs, it would be nice to be able to
view them in the abstract, including differences.

--

Article: 19021
Subject: Re: Trouble with ATMEL's AT40K20
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 24 Nov 1999 09:27:41 -0700
Links: << >>  << T >>  << A >>
Filip S. Balan wrote in message <81g8ar$h47$1@strelovod.uni-mb.si>...
>Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>...
>>Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>...
>>>>>**Symplify (simulates the HDL design fine all the time)
>>>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>I missed 1 SW:
>>>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time)
>>
>>
>>Did you use timing constraints and are they being met?
>>
>
>
>Think it is not important. The input of the shift register is at one input
>pin
>and the output of the shift register (last bit) at another (output) pin. A
>logic
>"1" should after some time (Tclk * N+eventual timing problems) cause a
logic
>"1" and a "0"  a "0".
>I used this simple TEST design just for this insensibility (if the delay is
>not important to me).
>But the output is sometimes (in dependence of cell positions) stuck at "0"
>or "1" (it does not change)!

perhaps if you post your code...

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

The secret of Slurm is on a need-to-know basis.


Article: 19022
Subject: Re: implementing TCP/IP on PLD
From: Armin Mueller <armin.mueller@stud.uni-karlsruhe.de>
Date: Wed, 24 Nov 1999 17:42:42 +0100
Links: << >>  << T >>  << A >>
"Joseph C. Su" wrote:
>
> Do you think it is realistic for an undergraduate design project to
> undertake the task of implementing TCP/IP on FPGA ( i dare not to use the
> term "pld" anymore), given a team of three not very smart students?

That's cool! How about designing a floating point unit in a FPGA with
three novice math students?

Or a nuclear bomb with some undergraduate physics students?

Or...

Armin     :-)

Article: 19023
Subject: Re: Trouble with ATMEL's AT40K20
From: "Filip S. Balan" <balan@uni-mb.si>
Date: Wed, 24 Nov 1999 18:34:30 +0100
Links: << >>  << T >>  << A >>
Werner Dreher wrote in message
<383C0406.3E4D@informatik.uni-tuebingen.de>...
>[...]
>
>Hello Filip,
>
>I'm not familiar with the Atmel parts, but an idea:
>do you use a dedicated clock net, or normal routing resources for the
>clock? By using normal routing recources, it's possible that the clock
>delay from flipflop n to flipflop n+1 ist greater than the data delay.
>In this case, at the active clock edge flipflop n+1 will not take the
>"old" value of flipflop n, but the new.
>
>Greetings
>Werner

This is all true, but...
in this case the overall delay from input to output pin would be even
smaller.
If the clock period (tried down to 10MHz ) would be shorter then the data
delay, then the overall delay from input to output pin would raise (let's
say cca. 2x).

Would any of this circumstances stuck my output ??

Filip S. Balan

Faculty of Electrical Engineering and Computer Science
Institute of Electronics
Smetanova 17
SI-2000 Maribor
Slovenia


Article: 19024
Subject: Re: VHDL vs. schematic entry
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 24 Nov 1999 15:23:28 -0500
Links: << >>  << T >>  << A >>
"David G. Koontz" wrote:
...snip...
> Way back when, we used to have a program for cannonizing gem
> files.  (A 2D editor used for chip layout/design, and schematic
> entry written by Gary Tarolli).  There is no pressing need for
> cannonization for viewlogic files - disk space is relatively cheap.
> and you'd be hard pressed to generate schematics bigger than
> Now what would be interesting would be visual differences.  The
> same could be said about HDLs, it would be nice to be able to
> view them in the abstract, including differences.

This would be a very useful tool indeed for people using schematic
capture as a front end. But it is unlikely that anyone will ever create
such a tool. The problem as I see it is that even though there are a
large number of people still using schematics in full or in part to
design FPGAs, there is a prevailing attitude among the tool vendors that
schematic capture is going the way of the dodo bird. As a result, the
tools largely stagnate as the vendors work harder and harder on HDL
front ends. In the end, this becomes a self fulfilling prophesy since
you can't buy what they don't sell.

I have already been told by two FPGA vendors that they will not be
supporting schematic capture at some point in the future. To me this is
a bit like Microsoft saying they will stop supporting assembly language
programming in the future. If they want to do it there is nothing we can
do about it except to learn C++. Then they were right to do it.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com