Schematic simulation and then FPGA programming?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Hello people,

I am strictly a schematic user, please don't turn this thread
into a "but HDLs are really better!!".
I'd like to get a new hobby, i.e. to design some (simple for
now, but then also complex) devices on a SpartanII 300E board.
The kind of devices I'd like to design range from TTL style at
the begin, till, someday, complete CPUs and simple multimedia
devices (e.g. graphic chips as seen in the '80s home computers).

I downloaded and installed Webpack, but I've been very
disappointed. It looks totally HDL oriented to me.. maybe
I'm wrong, but I couldn't see there what I'm looking for.

What I'm looking for (pardon the redundancy) is a simple
but yet powerful editor that will let me enter a schematic
(NAND gates, Flip-Flops, etc..); will also let me make new
devices from schematics (i.e. macros!); then *possibly*
simulate all of that; and then finally burn it into my
SpartanIIE chip, letting me also setup various features
of the FPGA (e.g. how to load the initial contents of
block RAM, etc..).

I have some money to invest, eventually, if the software
is not free.. but I'd like to know all the options before.

Please.. can anybody shed some light? I'm very confused
and lost..


Re: Schematic simulation and then FPGA programming?
Hi, <p>I'm not HDL fan either, but I know there's an ECS tool in Webpack that
allows you to do schematic (never use Webpack, I have ISE 5.1)   <p>To simulate
the design you may need a free ModelSim starter license. There's one thing I
like to add: this combination sofwares (ECS and Modelsim Starter)is very
limited. I had bad time when switching from Xilinx Foundation to ISE.  <p>I hate
to say this but that's true for me: If you are a Schematic Designer use
Foundation for all the devices it supports (at this time Spartan3, Virtex2Pro,
Coolrunner?... not in the list)   <p>May be I'm a slow learner, or I missed
something here, would like to hear other opinions. <p>Regards,

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

I know you don't want to hear this, but I'll try to give a reasoned
arguement rather than a blanket statement.

As fpgas get bigger and bigger, there is no doubt that most designers are
using hdls rather than schematics (or sometimes a mixture).  For big
systems, there are few that are made using pure schematics.  This means that
tool designers will put far more effort into the HDL support for their tools
than schematic support.  I haven't tried doing schematic design for an fpga,
so I can't comment directly, but I have heard complaints on this newsgroup
about the quality of the schematic tools for some fpgas.  It also means that
if you are learning about fpgas, there is a lot to be said for looking at
using HDLs - you are going to get better tool support, better online
tutorials and introductions, and end up with a more useful skill.

If you really want to use schematics, it may be that the best route is to do
the design using your current schematic design software and then use edif
netlists to import it into the fpga toolkit - I'm sure there are others in
this group who could give you ideas there.

Quoted text here. Click to load it

Re: Schematic simulation and then FPGA programming?
Hi, John!

Quoted text here. Click to load it

Take a look at IDaSS: /

Schematic entry with interactive simulation and a seamless
interface to the FPGA you're using through WebPACK...

Have fun,

Ad Verschueren

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

If I were required to do schematics, I would use Altera Quartus.
It meets your requirements except for the device.
It has a non-hdl simulator, which I find tedious,
but you might like.

    -- Mike Treseler

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

I always liked reasoned arguements.. go ahead. :)

Quoted text here. Click to load it

I'm not saying you're wrong, but I don't understand what makes inherently
more difficult to use schematic than HDL as projects get larger.

I think in a "object oriented" way.. for example, I make Flip-Flops from
NAND gates. So I get a Flip-Flop object. I make registers/latches from
Flip-Flops, so I get a Latch object. I mean, complexity can naturally
get encapsulated and encapsulated, till you have a whole ALU, or a whole
processor, etc.. and your schematic always looks simple (circuits and
subcircuits encapsulated into virtual devices).
I don't have much experience with current schematic software (I used
mostly my own.. nothing fancy anyway, but worked well for encapsulating
at least), but I see no reason why schematic based (using macros) should
be any slower or more confusing than HDLs?

I can only think about one problem: simulation gets slower and slower.
But neither this must be true: if simulating a whole Latch via NAND
gates may be slow, after I know it works well and I have its timing
characteristics known, I can encapsulate also them into the "black
box" and simulation of a Latch will be very quick.. having just to
simulate the function (and delays) from input to output.

HDL's IMHO are very confusing, hardware wise. A schematic is much more
natural and intuitive. IMHO of course.

On the other hand the non-intuitive, too abstract HDLs will make you
design things that then in silicon are very inefficient.. will not
give you a good "big, real picture" of what you're doing, etc..

Quoted text here. Click to load it

Yep, and that just makes me think that the problem is not in the
schematic idea per se, but in the current software.

This is a typical situation for the usual "no programs satisfied my needs,
so I wrote my own". :D

Too bad I don't have that much free time.. so I'd prefer to stick with
something already available. I have my own schematic based simulator but
its editor is nothing mature at all, and it's missing many features.

Quoted text here. Click to load it

Right, I feel much "out of the world" by not following the HDL route.. but
I can't help.. it's a hobbyst project and I have to enjoy it. This definitely
means "no HDLs". ;)

Quoted text here. Click to load it

That's very interesting. Please, can you elaborate more on this?

You mean that I could do schematic entry and schematic simulation on any
software that is able to save in EDIF format? What would be the best software
(simulation-wise) capable of it, can you name a few?

And then I could load the EDIF file into Webpack (?) and from there what
should I do? Is further simulation (more FPGA-device targetted) possible?

How could I express things like block-ram in the former schematic program,
if it's quite totally separed from the back-end tools?

Thanks for your time!

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it
Depending on how you do this, this could prevent you from using the physical
FFs already in the Xilinx architecture.  That would be a major mistake, as
the performance, clock skew and density would suffer drastically.

Quoted text here. Click to load it
This is what most people do with schematics.  There's no need to have
of pages of nearly identical structures, you make a hierarchy.  In fact,
a number
of parts in the Xilinx libraries are not primitives, directly, they are
constructs that contain instances of primitives.  All of the multi-bit
latches, comparators, etc. are made this way.

Quoted text here. Click to load it
You need to know that after the manufacturer's tools get done munching on
the 1-to-1 boolean equations that are extracted from your schematic, the
logic will bear little resemblance to what you created at the schematic
All sorts of optimizations are taken with any chunk of combinatorial
logic to
fit it best into the particular device architecture (4-input logic
blocks, for
instance).  If you have to follow through the final equations to figure
out how a
signal gets from here to there, you will see it does not resemble what
you started
with.  This can have some significant ramifications if you expect to
solve timing
problems by throwing extra gates in somewhere.  Anything extra will be

Quoted text here. Click to load it
Well, I'm pretty impressed with what Xilinx has done in their translation,
optimization and place&route software.  They get good packing of a lot of
stuff into the chips, I've never had an error that wasn't actually my
fault, and
the stuff just works.  I have done some mixed-mode designs, like a schematic
job with  binary-to-gray code and vise-versa in HDL, because that particular
function is a serial string, and just is very easy and natural to code
in HDL
form.  I have a little toy project that I could do in schematic, but I'm
to try it entirely in VHDL just to see how it goes.


Re: Schematic simulation and then FPGA programming? (John K.) wrote in message
Quoted text here. Click to load it

All real hardware engineers design with schematics.  Sometimes they're
use your method, but more often than not, schematics take the form of
sketches on bar napkins from which the designer codes HDL.  My point
is schematics and HDL are not two independent design methods.  Good
designers use both together.  Here's what I do:

  1. Draw up a design using paper, Visio, or whatever works.  (I've
found Simulink is the best dataflow block diagram editor around.)

  2. Then translate the schemtic to HDL (or better yet, CF).  Maintain
the same structure, hierarchy, and connections.

With this approach, you use a very small subset of HDL (Verilog
recommended), which is sure to pass through any simulation or
synthesis tool without complaints (Icarus recommended).  The
translation process from schematic to HDL actually goes very quickly.
Once you get the hang of it, you start doing step 1 in your head.

(I've got a small list of structural HDL coding guidelines, if

BTW, please don't code FPGA flip-flops as a pair of NAND gates. :-)

Quoted text here. Click to load it

Totally agree.  I need to see boxes and lines before I can make sense
of it.

Quoted text here. Click to load it

Commerical level HDL coding is always at RTL.  The same level as your
schematics.  If you stick with structural HDL coding, you'll know
exactly what's going on.  Golden rule: Never, ever, code HDL as a
sequential software program (else crap in = crap out).


Tom Hawkins
Launchbird Design Systems, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Schematic simulation and then FPGA programming? (John K.) wrote in message
Quoted text here. Click to load it

where is the problem? just use ISE schematics entry if you want so
its available and you can generate FPGA bitstream out schematics
exactly as you would from hdl designs. and you can also do simulation
if you need.


Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it
I have been using Xilinx's ISE for a while.  I used their Foundation
before that.  I was really mad at them for changing schematic vendors
so old schematics were no longer compatible with the newer software.
Also, the Aldec schematic entry tool is, to me, a totally horrible
nightmare.  I just find it works against me so much of the time.

I have been using Protel 99SE for some time, and find its schematic
entry much better.  Protel has a CPLD/FPGA tool, but it is pretty rough
around the edges.  I tried to use it for Xilinx CPLDs and FPGAs, but there
are some problems generating bitstreams for the newer and larger devices.

I tried some time ago to port XNF files from Protel to Xilinx, and ran into
problems.  Recently, I got mad again, and now that ise takes edif files,
I tried
to make it work again.  Well, Protel's idea of EDIF format is not
identical to
Xilinx's, but it is close enough that I think a parsing/converting
program could
be thrown together fairly easily to make it work.  I'm pretty sure that
Protel's EDIF format is actually just WRONG, as net names have & in front
of them in some places and not others.  Just deleting all  &'s fixes that.

I have actually pushed a schematic through and hand edited the EDIF
file, and
got Xilinx to accept it and produce translation and map reports that
look right.

So, if you have any schematic capture software that has the Xilinx
library primitives
in it, and can put out an EDIF file, you might want to try that out.
 I'm pretty
sure all the Xilinx tools can accept an EDIF, now.


Re: Schematic simulation and then FPGA programming?
I can sympathize.  I was in a multi-day argument thread a couple months back
with an HDL zealot.  I, too, am a schematic based designer primarily because
the currently trendy methods offer no advantages, and have numerous
down-sides (like creating legions of people calling themselves "designers"
who have no idea how the circuit they described in software is actually

But, that is a very stale argument.  Both camps like what they like.

I have stayed with Altera tools for more than a decade because they are
vastly superior for a schematic based design.  I have the latest ISE tools
as well, and the schematic capture tools are state-of-the-art -- for the
year 1985.  I can't stand using their tools, and if I am forced into using a
Xilinx part, I do the design in the Altera tools first, then transfer it.
It is vastly quicker and easier than dealing with the primitive Xilinx
schematic tools.  They don't have an integrated simulator either, which
truly bites.  These tools seem like bits and pieces cobbed together into a
not-so-great package.

The free Altera tools will provide you the easiest route to design with
schematics.  All the features of the full paid-for Quartus tools are
available in the free web tools, including the integrated simulator.  For
schematic designers, the Altera simulator is excellent and intuitive.  The
free tools don't support all their devices, which is the major difference
from the version you pay for -- at least as far as I'm concerned.

Another advantage with Altera is the new Cyclone family.  You can pretty
much get all those parts now.  You don't have to wait until next year to get
production versions of these fast, inexpensive parts and start at about $17
(quantity one price for a 1C3 -8 speed grade).

What's not to like?  This is the way to go for schematic lovers.

Quoted text here. Click to load it

Re: Schematic simulation and then FPGA programming?
I'm not sure I agree with HDL offering no advantage.  Let me preface first by
stating that I was a long time holdout prefering schematics (viewlogic) over
I changed to HDLs when they finally provided enough controls to permit me to
do the RLOCing (placement) that I was doing with schematics, partly because the
tools were starting to not support schematics, partly because customers insisted
HDLS, and partly because of superior macro generation capabilities.  HDLs do
a couple of distinct advantages:

1) you can read the source with a generic text editor.  After getting stuck on
designs that needed updates and finding the schematic program (viewlogic)
data base format or libraries had changed it was refreshing not to have the
version of reader to be able to look at an archived design.  This is
important for archived designs.

2) For portions of the design where time to completion is critical and
or density is not, the ability to synthesize from higher level code is nice to
have.  This
is particularly true with state machines.

3) The ability to mix high level language style programming with hardware
is very helpful for writing testbenches for simulating the circuit.  Because of
ability, it is much easier to write testbenches that simulate the circuit both
realistically and more completely than is possible within a reasonable amount of
using strictly schematic tools.

4) Parameterized construction reduces the size of libraries, as well as the
required to maintain them.  For example, with an HDL, you can have a macro
automatically size the logic to the width of either the inputs or outputs rather
having a different library element for each width or function variation (eg.
vs. unsigned adders).  This is particularly helpful if you are using the HDL as
a placed macro generator, as the RLOC values are generated within the code.

The major disadvantage to HDLs is that it can be harder to interpret, especially
data path designs constructed from primitives rather than inferred logic.  Much
of that
difficulty can be worked around using one of the HDL to schematic viewer tools,
even though the results from those are less than perfect.

Patrick MacGregor wrote:

Quoted text here. Click to load it

--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

Maybe it's because I'm using the v5.2.03i of the free WebPack, but
I can't find any schematic option in the New Source window. :(

I can see only:

User Document
BMM File
MEM File
Implementation Constraints File

Quoted text here. Click to load it

Yup, I'm thinking to dump Xilinx and go with Altera instead. But
it's very confusing for me to find the right target device. What
would be a rough equivalent of the Spartan 2E 300? Altera has so
many families that it's very confusing (at least for me).

Moreover, what about programmers and development boards? My former
choice for Xilinx was motivated by the large (till 10 millions of
equivalent (fake, I know) gates!) rich choice of sizes, the low
cost development boards (like the ones from Digilent and Burched)
with integrated programmer. I need cheap, for the moment.

One thing, though, that puzzled me is why similar designs to the
one I have in mind, i.e. the C-One and XGameStation, both use
Altera devices. No, I won't ask if they're superior than Xilinx
(or inferior, for the matter :) ) to avoid to cause a possible
very boring flamewar here. ;)
What I really ask is instead if Altera devices are suitable for
low budget development (just to get confident with the FPGA world)
using schematic entry and simulation, and if then they will offer
the power to do serious stuff, without having to dump it all and
change brand/family of chips. Moreover, why not Actel or Lattice/
Vantis, or why not Lucent or QuickLogic (just to name those that
I heard the existance of and visited thousands times the website
of, without much results anyway)?
Moreover, if I go with Altera, which are the families roughly
equivalent in specs to the Spartan 2E and Virtex of Xilinx?

Thanks a lot for all your big patience and help!


Re: Schematic simulation and then FPGA programming?
There are very few applications where any FPGA brand is "the only" solution
to the problem.  Most designs are gates and flops, and they all do that
pretty well.  Most engineers, myself included, end up using what they know
and trust and feel they have the best chance of success with -- whether it
is parts or design methodology etc.

Perhaps the simplest way to compare X's to A's is to look at the "logic
cell" count.  This would be the number of 4-input lookup-tables that feed
flops.  The X datasheets are a bit obtuse in this area, and you have to be
careful when you go from family to family.  For example, the Virtex2 parts
describe one CLB as containing 4 "slices", and each "slice" has 2 LUT + FF.
So, one CLB has 8 LUT + FF.  But, they don't list how many CLBs are in the
parts -- they show "slices".  An XC2V250 has 250K "gates", comprising 1536
"slices", or a tad over 3000 flops.  This is about the same size as a
Cylcone 1C3, which is advertised as having 2910 flops.

As for Spartan 2E, the 2S300E has 6912 "logic cells" and 1536 CLBs.  Here's
where you have to pay attention to their inconsistent language.  In S2E's,
one CLB = 4 "logic cells" and each LC = LUT + FF.  So, you have 4 FF per
CLB, not 8 like in V2/2Pro.  What's more strange is that 1536 x 4 = 6144,
not the 6912 they advertise.  They are counting other elements in the design
as "logic cells" beyond the 6144 that are in each CLB.  Not sure what that's
all about.  You certainly should have at least 6144 flops in the 2S300.
This is about equal to a 1C6 Cyclone part, which has 5980 flops.

I don't have any pricing numbers on the X parts, but a 1C3 can be had for
about $17 in quantity 1 pricing, and the 1C6 starts at about $27.

X and A differ on the types of I/O each family of devices will support, so
you have to pay close attention to that too.  If you have large internal
memory requirements, you need to move to the more costly Stratix parts from
Altera, or the Virtex2/2PRO parts from Xilinx.  X and A have differing
memory architectures too, and both companies' high-end parts have dedicated
hardware for implementing DSP functions.  Once Spartan 3 comes into full,
qualfied production, those parts have the promise of low cost and DSP
stuff -- Cyclone parts don't include DSP hardware, so you'd have to roll
your own.  Different vendors also have different power consumption, which
may or may not be a factor.

Both companies' newer parts can run amazingly fast.  The cheapest, smallest,
slowest Cyclone parts can handle OC-48 SONET rates without breathing hard,
and I expect Spartan 3 can do the same.  Pushing into the fastest speed
grade parts can accomodate in excess of 35 Gbps pipelined processing on
128-bit wide buses.  You can "get serious" with parts from either vendor,
even in the low-cost families.

I have never had difficulties migrating old designs into newer part
families, so portability works out well too.

Hope this helps.

Quoted text here. Click to load it

Site Timeline