Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 18975

Article: 18975
Subject: Re: implementing TCP/IP on PLD
From: murray@pa.dec.com (Hal Murray)
Date: 23 Nov 1999 05:39:40 GMT
Links: << >>  << T >>  << A >>

> 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 traditionally implemented in software.  Go talk to some software
guys and get them to show you the code.

There are a lot of corners you can cut, but you have to understand
what you are doing before you can do that.

TCP/IP Illustrated, Volume 1 by Stevens is a good place to start.
It's 576 pages.

For a class project, I'd suggest something like a simple UDP server.
Somebody sends you a packet.  You grap some data, say the temperature,
and send it back.

If that's too easy, consider using TFTP to send or receive a file.
(File means a chunk of data that's too big to fit in a single packet.)

-- 
These are my opinions, not necessarily my employers.
Article: 18976
Subject: Re: VHDL vs. schematic entry
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Mon, 22 Nov 1999 22:14:36 -0800
Links: << >>  << T >>  << A >>
|
|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.
|


Hi,

I've done all my FPGA designs as schematics. The thing I like about
this form is...

1.  Suppose one of my engineers designs an FPGA, and asks for my help,
or even quits and leaves it up to me to finish the design. Or,
equivalently, we revisit something that was done a year ago and that
nobody really remembers. Well, I can look at a good schematic and
absorb it in seconds, and can often spot a bug in minutes. The
schematic is parallel and visual. Picking up someone else's code (C,
assembly, or, I suspect, HDL) is a much slower process.

2. I wouldn't dream of designing an FPGA without understanding the
underlying architecture. It's fairly easy to draw a schematic that
optimizes the design to the part architecture. If it's Xilinx, I'd
want to avoid, say, 6-input AND gates if I can, or put in pipeline
flops where I know they fit into the cell structure.

3. It seems to me that I see a lot of newsgroup posts that ask for
help getting the HDL to do what the user wants; say, to use the Xilinx
hard carry chain, or to put the flipflops in the right places. That's
seldom a problem for us using schematics. We spend very little time
fighting (or for that matter even learning) the tools.

4. A good schematic is VERY readable. Sheet 1 is the block diagram
with table of contents, sheet 2 is register map (if any), and the rest
is carefully labeled and commented. 

5. We don't simulate, so that aspect of HDL is not useful to us. We
just design carefully, compile, and test. After all, it IS an FPGA,
and not a piece of silicon that will take six weeks and $100K to
change. When we do find a problem, the cause is generally (almost
always) right in front of our faces on the schematic, so we fix it
quickly. 

6. Inner blocks are sometimes easier expressed as logic equations, so
the guts of, say, a decimal counter can be coded in a language. This
then becomes a defined schematic symbol which fits right in. That's
OK.

7. Coding standards are easy, even for beginners. I give them my
neatest schematic and say 'make it look like that'. And I can review
it in minutes.


I like schematics because they are so visual and parallel, and that
suits the way I see and think. Others, who have a more sequential or
verbal mentality, may well prefer logic expressed as text. But
schematic design is fast and efficient for us, and a six-month
learning curve for VHDL is time I would never recover.

John

you can see some of my designs at www.highlandtechnology.com


Article: 18977
Subject: Re: VHDL vs. schematic entry
From: Phil Hays <spampostmaster@sprynet.com>
Date: Mon, 22 Nov 1999 22:29:15 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Even working at the RTL level, you really should be designing to the
> architecture if you want good quality results.

A design aimed at an architecture will not be a stellar performer in a different
architecture, but it can be moved.  That might just be enough to avoid needing
to redo an older design.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 18978
Subject: Re: VHDL vs. schematic entry
From: Phil Hays <spampostmaster@sprynet.com>
Date: Mon, 22 Nov 1999 22:53:49 -0800
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> Thank you for you detailed response.  I absolutely agree that proper
> synchronous design practices are required.  This is true for FPGAs, no
> matter what design entry method is used.  My concern is how to enforce
> these design rules in VHDL.  In a schematic I can force a global buffer
> to be used for clock distribution.  How hard is it to do this in VHDL?

Depends somewhat on the target family.  Synthesis tools will almost always use a
global buffer for clock.  I've seen one case that they didn't, and the solution
as to instantiate a global buffer primitive.  Also, high fanout logic signals
sometimes need global buffers for speed (can't do this in all targets).


> Also, for synchronizing registers I can define a special timing
> constraint that will guarantee the extra setup time margin needed
> between synchronizing registers, to reduce the probability of
> metastability.  How hard is it do this in VHDL?

I've done this with Xilinx.  The path I followed was to put a timing constraint
between the registers in question in the Xilinx ".ucf" file, which is fairly
easy to do.  A warning: Xilinx tools will duplicate registers in an attempt to
improve speed and/or routing.  There is a switch (to map or par) you had best
set.  I also did some floorplanning to make sure that this didn't happen again.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 18979
Subject: Re: VHDL vs. schematic entry
From: rk <stellare@NOSPAM.erols.com>
Date: Tue, 23 Nov 1999 02:20:15 -0500
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> 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'm in a similar boat, but let's say from 1 to 3 people.

------------------------------

> I would be interested to hear from those people that have gone through
> the VHDL learning curve.

me too.

------------------------------

> Has the move to VHDL reduced design entry time?

for certain types of problems.  i don't know how many times i've had to
draw muxes for reading out a number of different quantities, putting
together items of different lengths to pack them into a word, etc., etc.,
etc.  vhdl is far superior for that.  complex state machines are much
faster in vhdl, too, although one has to be careful about the unused state
problem, which vhdl is poor at (note that synplicity is working on this
with their "safe" mode).  there are other situations where there is
redundancy that you don't want the tool to eliminate and you have to ensure
that the tool does what you think you are telling it to do.

another factor with vhdl is that the tools are constantly changing and the
output that you get with one version is not necessarily the same as within
another.  while with schematics you can only share reasonable with someone
who has a compatible tool (i happen to use viewlogic), which is a pain,
vhdl can be "shared" with anyone who happens to have notepad or an old
version of wordstar.  however, the design (the actual gates) is less
portable since your pal reviewing it or adding to it can not see the same
output that you get.  you have to e-mail him a structural netlist to toss
into the simulator.  that doesn't provide insight into the design, just a
simulatable model.  for example, it's easy in vhdl to generate a poor
circuit in hardware although it looks fine at the vhdl level.

-------------------------------

> Has the design quality improved (fewer problems)?

don't think it matters that much, if one discounts unfamiliarity with the
language (and tools) while ramping up on the "learning curve."  of course,
one can't really discount that.  vhdl makes it harder to see the flow of
signals and their relationships so in some cases it would hurt (pipelined
designs, circuits with feedback).  for certain state machines, it makes it
easier to see.

--------------------------------

> Is design debugging easier?

i'd say harder, since you can't see (easily and clearly) the design that is
generated in hardware.  as an example, take the output of some vhdl and put
it into your favorite schematic generator.  using schematic entry, where
each signal and instance is labelled, it's trivial to talk to the chip (for
probe) or the tools (for analysis).

--------------------------------

> Is design maintenance easier?

again, depends on the circuit.  for a lot of systems the flow of a well
drawn schematic wins easily.  for modifying a complicated state machine
with a bunch of different cases when a system engineer CHANGES HIS MIND
AGAIN is easier in vhdl.

--------------------------------

> Is design reuse easier?

it can be in two ways.  one, it's easier to parameterize the design.  and
two, i can write my own software that algorithmically generates a design.
that's easy since the design entry is ascii text.  writing software to
generate schematics is more difficult; i haven't tried the interface to
viewlogic for that yet.

--------------------------------

> Did you get to the point where VHDL is more efficient than schematics?

again, depends on the design i'm doing.  for certain areas yes.

--------------------------------

> If so, how long did it take to get to this point?

variable.  for certain designs, a few months.  since i've had some critical
projects (day job) my phase-in of vhdl was longer than it might otherwise
have been.  it is not a simple learning curve, although that may also be a
factor of my age and the length of time using schematics.

---------------------------------

> Bottom line: Was it worth it?

yes.  while the above concentrated on design for synthesis, vhdl for
writing test benches is a powerful tool, too, that has some nice advantages
in certain cases.

rk

Article: 18980
Subject: VHDL Simili from Symphony EDA adds support for Xilinx libraries
From: "Haneef D. Mohammed" <haneef@mindspring.com>
Date: Mon, 22 Nov 1999 23:51:11 -0800
Links: << >>  << T >>  << A >>
Symphony EDA is pleased to announce support for the Xilinx
UniSim and SimPrim libraries in "VHDL Simili". We are proud
to add these Xilinx libraries to our list of supported vendor
libraries (Altera, Cypress, etc.) with more to come.

"VHDL Simili" is a VHDL Compiler/Simulator environment with
the following features.

    -- VERY FAST Compiler and Simulator
    -- VHDL 93
    -- Vital/SDF support
    -- Tested with Programmable Logic Vendor Libraries
    -- Designed for the serious VHDL professional
    -- Optimized for easy internet downloads
    -- Much much more ...

VHDL Simili is FREE with no gimmicks/strings attached and
without any limits on the number/size of your VHDL files,
simulation run time, etc.

Please visit us at

    http://www.symphonyeda.com

to find out more and download the software (3.2MB).


Haneef D. Mohammed
Symphony EDA
haneef@symphonyeda.com


Article: 18981
Subject: Re: Altera JAM
From: deroberts@my-deja.com
Date: Tue, 23 Nov 1999 08:58:36 GMT
Links: << >>  << T >>  << A >>
In article <gDXZ3.34919$YI2.1673968@typ11.nn.bcandid.com>,
  "Erich Wagner" <ewagner@pdq.net> wrote:
> Is anyone actively using Altera's JAM technology? What are your
experiences?

We too have used it most successfully over the last 9 months. We have a
PCI-based board with a 10k50E on it. The board uses a proprietary
PCI-local bus bridge so we don't have a bootstrap problem. We use a
MAX7128 to act as a local bus target, providing three memory locations
whose bits match those of a byteblaster.  We ported the Altera jam
player to Linux/Alpha (not totally trivial, as there are numerous 32-bit
long assumptions). It now forms a routine part of a device driver since
it takes less than 2s to download the flex code.

Derek Roberts
AT&T Labs Cambridge


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18982
Subject: Re: Trouble with ATMEL's AT40K20
From: "Filip S. Balan" <balan@uni-mb.si>
Date: Tue, 23 Nov 1999 10:17:58 +0100
Links: << >>  << T >>  << A >>
>>**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)

Filip S. Balan
balan@uni-mb.si



Article: 18983
Subject: Re: VHDL vs. schematic entry
From: Ray Andraka <randraka@ids.net>
Date: Tue, 23 Nov 1999 07:46:42 -0500
Links: << >>  << T >>  << A >>


John Larkin wrote:

All good comments, well except for this one:

> |5. We don't simulate, so that aspect of HDL is not useful to us. We
> just design carefully, compile, and test. After all, it IS an FPGA,
> and not a piece of silicon that will take six weeks and $100K to
> change. When we do find a problem, the cause is generally (almost
> always) right in front of our faces on the schematic, so we fix it
> quickly.

I wouldn't dream of sending a design to a customer without first simulating
it.  I intensely dislike the politics of being in the Lab.  Some time spent
in simulation makes sure that the design works the first time, and more
importantly that you have an opportunity to check all the boundary
conditions.  How long do you spend in the lab debugging?

--
-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: 18984
Subject: Re: Trouble with ATMEL's AT40K20
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Tue, 23 Nov 1999 10:03:39 -0700
Links: << >>  << T >>  << A >>
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?


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

"Creation Science" is oxymoronic.



Article: 18985
Subject: Anybody using Lucent OR3TP12?
From: Edward Wallington <edward.wallington@crsltd.com>
Date: Tue, 23 Nov 1999 17:06:48 -0000
Links: << >>  << T >>  << A >>
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: 18986
Subject: Hyperstones RiscDSP Eva Kit seems buggy
From: Jens Lauer <jens.lauer@e-technik.tu-chemnitz.de>
Date: Tue, 23 Nov 1999 18:10:42 +0100
Links: << >>  << T >>  << A >>
Hi there,

nearly half a year before I bought an Hyperstone Eva Kit (E32) with
CODEC Board and from this time on I had trouble with. The whole system
seems to fool me. After request at hyperstone.de I got some new software
(dsp-library, header files new compiler) piece by piece  but the whole
thing isn't working yet. It's a pity because the Hyperstone concept is
good and documentation well done (not always at conformity with the
sample application).
 

The main drawback is that there is no place to look in working
application software other than the little stuff I got included with the
kit. 

Has somebody bought it too an has further experince with - any help is
welcome


--jens
Article: 18987
Subject: Re: VHDL vs. schematic entry
From: Robert Sefton <rsefton@home.com>
Date: Tue, 23 Nov 1999 17:20:06 GMT
Links: << >>  << T >>  << A >>
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.

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.

> 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.

> 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.

RJS
Article: 18988
Subject: Re: How to use multiple resets?
From: Dragon <hyarbr01@NoSpam.harris.com>
Date: Tue, 23 Nov 1999 12:34:50 -0500
Links: << >>  << T >>  << A >>


Utku Ozcan wrote:

> I have a question which close to this discussion:
>
> We are using Spartan-XL and we intend to use TWO individual resets
> in the chip.....

> From 2, I understand that it is possible to use two resets and one
> reset can be asserted to GSR routing and the other one must be used then
> in normal routing. But 2 is correct only for XC4000 devices, since
> the item is "Startup Block for XC4000 and XC5200", there is not the
> word "Spartan" at the header title of the item.
>

I believe Spartans are simply XC4000's without RAM capability. Outsideof
this, what holds true for XC4000's should hold true for Spartans.

> If Xilinx is true, then I conclude that when I want to use more than
> one reset in Spartan or XC4000, then routing will be worse, since
> I mustn't use GSR usage for a correct operation and the resets will
> use normal routing resources. That will make the routing more difficult.
>

You can still connect the local reset net to a global buffer (not GSR)
andpossibly improve routing. You will likely have to do this by instantiating
a
BUFG component in your HDL code. I doubt Synplify will have the
insight to do this automatically. Be careful you don't run out of global
buffers though. You can only use 4 globally!

> If Synplify is true, then I conclude that when I want to use more
> than one reset in XC4000 and XC5200, and when I want to assign one
> of the two reset signals to the GSR routing, then routing will be
> used efficiently.
>

Yes. However the GSR net will set or reset ALL flops in the FPGA.

> Which is correct?
>
> Utku



Article: 18989
Subject: Re: How to use GSR-net in Virtex?
From: Dragon <hyarbr01@NoSpam.harris.com>
Date: Tue, 23 Nov 1999 12:49:25 -0500
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?

        - Craig

Hal Murray wrote:

> Speaking of GSR being slow, that brings up the whole Metastability mess
> again.  This probably isn't statistically important since GSR doesn't
> change very often.
>
> Note that even if you have plenty of time, you can't use GSR to reset
> the whole chip if you have two or more asynchronous clocks.  At
> least you can't do it cleanly.  Even if you only have one clock,
> you also have to make sure that the signal connected to GSR is
> clocked by that clock rather than a junk IO from a microprocessor
> that's running on a different clock.
>
> --
> These are my opinions, not necessarily my employers.



Article: 18990
Subject: Re: VHDL vs. schematic entry
From: Greg Neff <gregneff@my-deja.com>
Date: Tue, 23 Nov 1999 17:54:33 GMT
Links: << >>  << T >>  << A >>
In article <383A8CB2.2A97473F@ids.net>,
  Ray Andraka <randraka@ids.net> wrote:
>
>
> John Larkin wrote:
>
> All good comments, well except for this one:
>
> > |5. We don't simulate, so that aspect of HDL is not useful to us. We
> > just design carefully, compile, and test. After all, it IS an FPGA,
> > and not a piece of silicon that will take six weeks and $100K to
> > change. When we do find a problem, the cause is generally (almost
> > always) right in front of our faces on the schematic, so we fix it
> > quickly.
>
> I wouldn't dream of sending a design to a customer without first
simulating
> it.  I intensely dislike the politics of being in the Lab.  Some time
spent
> in simulation makes sure that the design works the first time, and
more
> importantly that you have an opportunity to check all the boundary
> conditions.  How long do you spend in the lab debugging?
>
> --
> -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
>
>

Politics notwithstanding, I have to agree with Ray on this one.
Typical lab testing may only cover three quarters of the logic.  As Ray
pointed out, boundary conditions may or may not be encountered during
testing.  Also, error recovery logic will not be exercised under
nominal conditions.  Simulation is the fastest way to find out how the
logic will respond to low probability events, or conditions that are
hard to produce in the lab.  In the lab, can you force a state machine
to an illegal state to make sure that it recovers?  It can be damn hard
to figure out what is going on inside an FPGA, because you can't poke
around the logic with a scope or logic analyzer.  I have never
regretted the time to build and run a good simulation.

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


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18991
Subject: Re: Why not Lucent ORCA FGPAs?
From: Dragon <hyarbr01@NoSpam.harris.com>
Date: Tue, 23 Nov 1999 13:02:26 -0500
Links: << >>  << T >>  << A >>
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?

        - Craig

Ray Andraka wrote:

> EPIC is _NOT_ a floorplanner.  It is an editor, and a PITA at that.  I'd take the
> old  the Xact 6.0 XDE and floorplanner over the current tools any day if they
> would support the current 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: 18992
Subject: Re: VHDL vs. schematic entry
From: Mike Treseler <tres@tc.fluke.com>
Date: Tue, 23 Nov 1999 10:12:26 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:

> Hi,
> 
> I've done all my FPGA designs as schematics. The thing I like about
> this form is...
> 
> 1.  Suppose one of my engineers designs an FPGA, and asks for my help,
> or even quits and leaves it up to me to finish the design. Or,
> equivalently, we revisit something that was done a year ago and that
> nobody really remembers. Well, I can look at a good schematic and
> absorb it in seconds, and can often spot a bug in minutes. The
> schematic is parallel and visual. Picking up someone else's code (C,
> assembly, or, I suspect, HDL) is a much slower process.

> 4. A good schematic is VERY readable. Sheet 1 is the block diagram
> with table of contents, sheet 2 is register map (if any), and the rest
> is carefully labeled and commented.
> 

I might agree up to ten sheets.
At 100 sheets it might take me over 10,000 seconds
to absorb the design intent.

> 2. I wouldn't dream of designing an FPGA without understanding the
> underlying architecture. It's fairly easy to draw a schematic that
> optimizes the design to the part architecture. If it's Xilinx, I'd
> want to avoid, say, 6-input AND gates if I can, or put in pipeline
> flops where I know they fit into the cell structure.

I agree if speed or gate packing is the main concern.
However you might be surprised how smart the best synthesizers
are getting and how cheap fpga gates are getting.
 
> 3. It seems to me that I see a lot of newsgroup posts that ask for
> help getting the HDL to do what the user wants; say, to use the Xilinx
> hard carry chain, or to put the flipflops in the right places. That's
> seldom a problem for us using schematics. We spend very little time
> fighting (or for that matter even learning) the tools.

For every such trouble post there are probably 100 happier 
but unreported instances where a more capable synthesizer 
inferred the the structure just fine.

> 5. We don't simulate, so that aspect of HDL is not useful to us. We
> just design carefully, compile, and test. After all, it IS an FPGA,
> and not a piece of silicon that will take six weeks and $100K to
> change. When we do find a problem, the cause is generally (almost
> always) right in front of our faces on the schematic, so we fix it
> quickly.

I do simulate because I really hate connecting those little
logic analyzer clips to to 32 bit buses.

> 6. Inner blocks are sometimes easier expressed as logic equations, so
> the guts of, say, a decimal counter can be coded in a language. This
> then becomes a defined schematic symbol which fits right in. That's
> OK.

I agree. Once you start down this slope you might discover
that the function in the block is growing toward the IO pins.

> 7. Coding standards are easy, even for beginners. I give them my
> neatest schematic and say 'make it look like that'. And I can review
> it in minutes.

I might give them a code example and do the same thing.

> I like schematics because they are so visual and parallel, and that
> suits the way I see and think. Others, who have a more sequential or
> verbal mentality, may well prefer logic expressed as text. But
> schematic design is fast and efficient for us, and a six-month
> learning curve for VHDL is time I would never recover.

I used to agree with you. Now I draw the boxes and circles in my
notebook and get on with hacking and sim'ing code.

           -Mike Treseler
Article: 18993
Subject: Re: VHDL vs. schematic entry
From: rk <stellare@NOSPAM.erols.com>
Date: Tue, 23 Nov 1999 13:26:21 -0500
Links: << >>  << T >>  << A >>
Greg Neff wrote:

> In article <383A8CB2.2A97473F@ids.net>,
>   Ray Andraka <randraka@ids.net> wrote:
> >
> >
> > John Larkin wrote:
> >
> > All good comments, well except for this one:
> >
> > > |5. We don't simulate, so that aspect of HDL is not useful to us. We
> > > just design carefully, compile, and test. After all, it IS an FPGA,
> > > and not a piece of silicon that will take six weeks and $100K to
> > > change. When we do find a problem, the cause is generally (almost
> > > always) right in front of our faces on the schematic, so we fix it
> > > quickly.
> >
> > I wouldn't dream of sending a design to a customer without first
> simulating
> > it.

i guess i could dream it, but for other than trivial designs it would be a
nightmare.

-------------------------------------------------------------------------------------

> > I intensely dislike the politics of being in the Lab.  Some time spent
> > in simulation makes sure that the design works the first time, and more
> > importantly that you have an opportunity to check all the boundary
> > conditions.  How long do you spend in the lab debugging?

i do sort of enjoy lab work ... but often in a lab, when things don't work,
the fingers usually start pointing and right at the fpga, typically.  it
pays to have the thing designed correctly and working out of the box.
normally, this is what happens.  you wind up getting dragged into the lab
anyways, it seems, but that's another story.  it's just best to have the
stuff work and spend no time debugging, just verifying.

-------------------------------------------------------------------------------------

> Politics notwithstanding, I have to agree with Ray on this one.
> Typical lab testing may only cover three quarters of the logic.  As Ray
> pointed out, boundary conditions may or may not be encountered during
> testing.  Also, error recovery logic will not be exercised under
> nominal conditions.  Simulation is the fastest way to find out how the
> logic will respond to low probability events, or conditions that are
> hard to produce in the lab.  In the lab, can you force a state machine
> to an illegal state to make sure that it recovers?  It can be damn hard
> to figure out what is going on inside an FPGA, because you can't poke
> around the logic with a scope or logic analyzer.  I have never
> regretted the time to build and run a good simulation.

i generally agree with this ... it's very easy in simulation, for example,
to have an input arrive during all states of your state machine.  actually,
vhdl test benches make this task relatively easy and clean.  in the lab, it
is far more difficult.  it's just easier to work, for certain problems, in
the simulator.  for some others, it's easier in the hardware (such as very
long sequences, like working on large format, 2-D detectors).

however, you can poke around in at least some fpgas.  because of the apps i
have, i most often use the actel devices which allow you to address, in
real-time, any two arbitrary points.  this can be used equivalently to a
scope on a circuit board, where i would like to probe each signal during
operation (both for good logic levels and transitions and waveforms).  now
you just hook up the scope probes and dial them in from the console.  stu
(haven't seem him much around lately) had some nice things to say about the
orca system, where it could shoot wires very quickly, bringing out internal
points.  of course, this is easy to do when you design with schematics.
with vhdl, things are hidden quite a bit, making it tougher to walk through
the design.  that's a bit scary ... i had one guy walk into my office (day
job) did a whole chip in vhdl, it didn't work, and wanted to probe inside,
it was a pain.

anyways, especially with vhdl, i think rigorous simulations will gain in
importance.

------------------------------------------------------------------------
rk                                 The world of space holds vast promise
stellar engineering, ltd.          for the service of man, and it is a
stellare@erols.com.NOSPAM          world we ahve only begun to explore.
Hi-Rel Digital Systems Design      -- James E. Webb, 1968

Article: 18994
Subject: Re: VHDL vs. schematic entry
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Tue, 23 Nov 1999 18:42:53 GMT
Links: << >>  << T >>  << A >>
On Mon, 22 Nov 1999 23:59:25 GMT, Greg Neff <gregneff@my-deja.com> wrote:

>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.
>
>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.

I moved away from schematic entry a few years back, not quite on purpose.
But it wasn't all at once.  :-]

At first, using viewlogic for Xilinx 4k designs, I found Xabel to really
speed up the design process:  I put control logic in Xabel source files,
and instantiated them in my schematics.  I could tweak the low-level code
without changing my schematic (until it required I/O changes.)  Where I
needed to control timing/logic levels, I wrote my code to control which
signals went through only 1 logic level; the tool was dumb (smart?) enough
to follow the partitioning of the logic as it was written, when I broke up
equations into multiple parts.

Printing the schematic was a pain, and for the one Xilinx 3k design I had,
the Xilinx tools required unique instantiations in my hierarchy--so I had
eight "unique" sets of hierarchical elements.   Maintaining the schematics
was definitely a major pain with the 3k series, just an annoyance for the
4k.

Then I learned verilog, and unfortunately didn't have (or know how to use?)
a schematic front end.  So the top level of my design was in hdl, and it
took a while for me to get used to it.
>
>Has the move to VHDL reduced design entry time?
I think so.  I stumble over syntax errors, I make typos, etc.  With
experience some of these decrease, and at least I become more adept at
finding them.   But more significant would be the reduction in time for
design changes.  And being able to compare, automatically, current and past
iterations with a simple file compare.  (This, of course, assumes you
haven't overwritten your previous version(s).)
>Has the design quality improved (fewer problems)?
WYSIWYG was somewhat the rule for shematic-based designs:  you use a
5-input NAND gate, that is what you get.  (Assuming it maps nicely to your
target technology.)  With HDLs (Xabel, verilog, VHDL, ...), the synthesis
tool goes through some optimization algorithms, which may or may not do
things the way you would like.  Some of them have even been known to
optimize out global buffers that have been instantiated (or even use
incorrect elements, such as a latch without an enable instead of one with.)
So you have to learn the synthesis tool and work around its limitations.
>Is design debugging easier?
I think so; at least if you can get quick feedback from your simulator.
>Is design maintenance easier?
Much.
>Is design reuse easier?
Others have made good points.  I haven't done any designs > 100k gates, and
I haven't developed my own procedures or generics.  But I find that it is
really easy to use an 8-bit shift register as a serial-to-parallel
converter, and also as a parallel-to-serial converter.  Oh, I need a clock
enable this design?  A short time later, module done and simulated.  Need a
different size?  The right way is to use paramaters/generics, but it is
quick and easy to also just copy the module and change the indices.  I.e.,
you don't need to be an expert to leverage an old design to create a new
one that is similar in structure.
>Did you get to the point where VHDL is more efficient than schematics?
I believe so.
>If so, how long did it take to get to this point?
Well, in regards to leaf nodes of the design, it is almost no time.  Other
than that, it takes a little getting used to--but so did the idea of
hierarchical schematic design.
>Bottom line: Was it worth it?
Yes.
>
>--
>Greg Neff
>VP Engineering
>*Microsym* Computers Inc.
>greg@guesswhichwordgoeshere.com
>

Jason T. Wright
Senior Engineer
CG Technologies
Ericsson
Article: 18995
Subject: Re: Virtex FIFO w/ Block RAM
From: Brian Philofsky <brianp@xilinx.com>
Date: Tue, 23 Nov 1999 10:48:51 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------07282AF9ACBFC3713783D9E7
Content-Type: multipart/alternative;
 boundary="------------94805CE7C6302745D2EADB38"


--------------94805CE7C6302745D2EADB38
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Both VHDL and Verilog code is freely availible for this application
note.  Just download,
ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip for both
versions of the code.


--  Brian



Michael G Wrighton wrote:

> Hi,
> We're in need of a FIFO implemented with the Virtex's Block RAM. I've
> found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block
> SelectRAM+" available from the cores page. This is precisely what we
> need except for that it is written in Verilog and our environment is
> VHDL. I'd be willing to try this co-simulation trick to integrate the
> two languages, but I wonder if anyone knows of a VHDL version of this
> freely available. Also, I've heard the mixing VHDL and Verilog can
> result in some pretty hairy problems. Any comments on that front?
>
> Thanks,
> MGW

--
-------------------------------------------------------------------
 / 7\'7 Brian Philofsky   (brian.philofsky@xilinx.com)
 \ \ `  Xilinx Design Engineer                   hotline@xilinx.com
 / /    2100 Logic Drive                         1-800-255-7778
 \_\/.\ San Jose, California 95124-3450          1-408-879-5199
-------------------------------------------------------------------



--------------94805CE7C6302745D2EADB38
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Both VHDL and Verilog code is freely availible for this application
note.&nbsp; Just download, <A HREF="ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip">ftp://ftp.xilinx.com\/pub/applications/xapp/xapp131h.zip</A>
for both versions of the code.
<br>&nbsp;
<p>--&nbsp; Brian
<br>&nbsp;
<br>&nbsp;
<p>Michael G Wrighton wrote:
<blockquote TYPE=CITE>Hi,
<br>We're in need of a FIFO implemented with the Virtex's Block RAM. I've
<br>found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block
<br>SelectRAM+" available from the cores page. This is precisely what we
<br>need except for that it is written in Verilog and our environment is
<br>VHDL. I'd be willing to try this co-simulation trick to integrate the
<br>two languages, but I wonder if anyone knows of a VHDL version of this
<br>freely available. Also, I've heard the mixing VHDL and Verilog can
<br>result in some pretty hairy problems. Any comments on that front?
<p>Thanks,
<br>MGW</blockquote>

<pre>--&nbsp;
-------------------------------------------------------------------
&nbsp;/ 7\'7 Brian Philofsky&nbsp;&nbsp; (brian.philofsky@xilinx.com)
&nbsp;\ \ `&nbsp; Xilinx Design Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hotline@xilinx.com
&nbsp;/ /&nbsp;&nbsp;&nbsp; 2100 Logic Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-800-255-7778&nbsp;
&nbsp;\_\/.\ San Jose, California 95124-3450&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-408-879-5199&nbsp;
-------------------------------------------------------------------</pre>
&nbsp;</html>

--------------94805CE7C6302745D2EADB38--

--------------07282AF9ACBFC3713783D9E7
Content-Type: text/x-vcard; charset=us-ascii;
 name="brianp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brianp.vcf"

begin:vcard 
n:Philofsky;Brian
tel;fax:(408) 879-4442
tel;work:1-800-255-7778
x-mozilla-html:TRUE
org:<BR><H1 ALIGN="CENTER"><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx" ALIGN="CENTER">  Design Center
version:2.1
email;internet:brianp@xilinx.com
title:<H3 ALIGN="CENTER"><img src="http://bennyhills.fortunecity.com/deadparrot/108/homer.gif" alt="Homer" align="center"> Design Engineer 
adr;quoted-printable:;;2100 Logic Drive=0D=0ADept. 2510;San Jose;CA;95124-3450;USA
x-mozilla-cpt:;25776
fn:<H3 ALIGN="CENTER">Brian Philofsky
end:vcard

--------------07282AF9ACBFC3713783D9E7--

Article: 18996
Subject: Re: Programming Virtex device via JTAG
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Tue, 23 Nov 1999 13:05:23 -0600
Links: << >>  << T >>  << A >>
Michael,
Thanks for the advice.  I'm still having problems.  We didn't design the board
which is one of the problems.  One thing I noticed is that you guys put the
config pins on "000" for configuration.  We put them on 101 for "JTAG mode"  I
thought that is what it had to be on to config through the JTAG port.  Again,
the JTAG programmer software says that the device is programmed, but it is like
the device never goes through it's startup sequence.  DONE never goes high.
When I have access to the board again, I'll try configuring with the pins on
"000".

The other thing I noticed is that you mention the program pin.  We don't
manipulate this pin.  Should we???  You mention that it is for PROM
configuration.  Again, we are trying to program via JTAG.  Should we have to
pull the PROGRAM pin low and then let it go high to program via JTAG???
Tom


>
>
> Hi Tom,
>
> We'v done JTAG configuration of virtex
> XCV300 with  XChecker and also with a
> selfmade interface for parallelport
> (Application Note Xilinx). There were no
> problems. I think the pullup on init is
> ok (we have the same).
> I will tell you the other configuration
> pins for orientation:
>
>

Article: 18997
Subject: Re: Virtex FIFO w/ Block RAM
From: kulak@my-deja.com
Date: Tue, 23 Nov 1999 21:09:46 GMT
Links: << >>  << T >>  << A >>
Xilinx has an appnote xapp131h.zip that seems to have both. I have not
used it yet.




In article <3839CF63.2544310F@arl.wustl.edu>,
  Michael G Wrighton <mgw1@arl.wustl.edu> wrote:
> Hi,
> We're in need of a FIFO implemented with the Virtex's Block RAM. I've
> found the Xilinx appnote titled "170 MHz FIFOs Using the Virtex Block
> SelectRAM+" available from the cores page. This is precisely what we
> need except for that it is written in Verilog and our environment is
> VHDL. I'd be willing to try this co-simulation trick to integrate the
> two languages, but I wonder if anyone knows of a VHDL version of this
> freely available. Also, I've heard the mixing VHDL and Verilog can
> result in some pretty hairy problems. Any comments on that front?
>
> Thanks,
> MGW
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18998
Subject: Re: implementing TCP/IP on PLD
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 23 Nov 1999 21:45:29 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <randraka@ids.net> writes:

>parts.  It's kind of a cross between an RCA 1802 (anyone remember those things?)

I remember them, though I never used one.

THere are also come CDP1802's somewhere near jupiter right now.

Maybe someone from JPL who reads this will fill in the details.

-- glen
Article: 18999
Subject: Re: VHDL vs. schematic entry
From: John Larkin <jjlarkin@highlandtechnologySnipThis.com>
Date: Tue, 23 Nov 1999 14:01:22 -0800
Links: << >>  << T >>  << A >>
On Tue, 23 Nov 1999 07:46:42 -0500, Ray Andraka <randraka@ids.net> wrote:

>
>
>John Larkin wrote:
>
>All good comments, well except for this one:
>
>> |5. We don't simulate, so that aspect of HDL is not useful to us. We
>> just design carefully, compile, and test. After all, it IS an FPGA,
>> and not a piece of silicon that will take six weeks and $100K to
>> change. When we do find a problem, the cause is generally (almost
>> always) right in front of our faces on the schematic, so we fix it
>> quickly.
>
>I wouldn't dream of sending a design to a customer without first simulating
>it.  I intensely dislike the politics of being in the Lab.  Some time spent
>in simulation makes sure that the design works the first time, and more
>importantly that you have an opportunity to check all the boundary
>conditions.  How long do you spend in the lab debugging?


Ray,

Since you deliver designs, you need to know that they are correct. If you mess
up, your customer gets hurt and that's obviously bad for your business. Our
situation is different, in that, around here, one or at most two engineers do
an entire design, and the customer sees only the finished product. And the lab
is just down the hall and is politics-free. Testing and debug are in fact often
social occasions... everybody wants to see how the latest widget is coming
along, and everybody has ideas when there's a problem.

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.

John



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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