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 2017

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

Derek Roberts
AT&T Labs Cambridge

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

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/

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
> is carefully labeled and commented.
>

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

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

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

Both VHDL and Verilog code is freely availible for this application
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
-------------------------------------------------------------------

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

--------------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
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
> (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/

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