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

Greets,
John
 

Re: Schematic simulation and then FPGA programming?
Quoted text here. Click to load it

Could I suggest you try the usually very helpful comp.arch.fpga group.

Jim




Re: Schematic simulation and then FPGA programming?
Quoted text here. Click to load it
<snip>

Quoted text here. Click to load it

Just noticed you have already multi-posted this to there. ;)




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

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

Note - I don't have all that much experiance in fpga design, so I'm happy to
be corrected by others with more experiance.  I'm also the sort of
programmer who prefers a good editor and makefiles to IDEs, I write
documentation using LaTeX rather than a word processor, and I hand-code my
html, so I might appear a bit biased...

Quoted text here. Click to load it

This sort of encapsulation is essential for managing large projects, and it
is a natural way to work with HDL designs.  It is not a natural system for
schematic packages I have seen (but maybe there are schematic packages which
*do* work in this way - I have only seen a few, and I've never used
schematic programs that come with fpga tools).  Schematic software is mainly
designed for working with "normal" electronics, so objects on the schematic
correspond directly to physical components.  In fpga design, that means
low-level "fundamental" objects like gates, pins and flip-flops, together
with things like block rams.  You are mostly stuck on a two-level system -
library parts and schematic diagrams.  What you are looking for is a
multi-level system.

Quoted text here. Click to load it

There are some advantages of schematics for fpga design - for example, it is
easy to get an overview when looking at a "black-box" sheet, which is
effectively a block diagram of the system.  It is quite possible to use such
a sheet as the top level, while the black boxes are designed in an HDL.  It
is also quicker to make very small systems, since you don't need all the
extra "padding" of an HDL (entity declarations, library statements, etc.,
that are needed in an HDL file in addition to the actual design-specific
code).  And it is much easier to learn schematic design, especially if your
background is in "normal" electronic design rather than programming.

However, there are a number of points in favour of HDLs.  Imagine you have
designed an 8-bit wide multiplexer, and have used it in both the ALU and the
register file part of your cpu design.  Then you think of an enhancement or
bug-fix for the multiplexer.  In the schematics packages I have used, the
nearest there is to macro-type design is effectively an advanced
copy-and-paste - the macro is run (or the sub-design copied) into the sheet
that uses it.  Changes to the macro (or sub-design) are not carried through
to the parts that use it, and you have to edit each manually.

The suppose that other parts of your design need a 4-bit multiplexer, or a
12-bit multiplexer.  In an HDL design, it is natural to paramatise such
parts, so that you design a single n-bit wide multiplexer and decide the
width when you use it.  How easy would that be in a schematic?  Suppose you
need a fast multiply-by-three element in your design - in a schematic its a
mess, and dependant on the width of the data.  In an HDL, it's a single
line.  Suppose you need to change it to a multiply-by-five instead?  In a
schematic, you're back to the drawing board - in an HDL, you change a "3" to
a "5".  You have a much greater flexibility with an HDL - macro schematic
packages would help, in the same way that macro assemblers are more flexible
than fixed assemblers, but it does not make them the best tool for anything
but small or specialist uses.

Some types of design can be clear in schematics, but other parts are bound
to be a mess.  A seven-segment display encoder written as a truth table will
be far clearer than mass of gates.  A large state machine can be elegantly
written in a case statement, while schematics are going to be hard to follow
and almost certainly inefficient.

There are also great benifits in terms of the efficiency of your final
design - schematic design is basically a WYSIAYG system - what you see is
*all* you get.  While an HDL can make it easier to make very inefficient
systems, it also allows the tools far greater scope for optomisations.


Quoted text here. Click to load it

You can write bad code in any language, and the less familiar you are with
the language, the greater the chance of that.  It is also quite easy to
write HDL code that is unintelligble to its author (I know, I've been
there) - good documentation is essential.  But exactly the same applies to
schematic designs.  I have not the slightest doubt that that old design,
which was hard to follow in an HDL, would have been impossible to follow as
a schematic (if it had even been possible to draw it in the first place).

Quoted text here. Click to load it
tools

Software for fpga design is written by two sorts of companies - fpga chip
companies, who want to make the software as appealing as possible so that
people will buy its chips, and fpga software specialists, who want people to
buy the "bigger" licences for their software.  As far as I understand it,
from other posts in comp.arch.fpga amongst other sources, the support for
schematics has gone down in some packages, and certainly is of lower
priority than HDL designs.  I think the tool vendors are following the
patterns of their customers here, and not vice versa.  It may be just a
fasion, but I don't think so.

Quoted text here. Click to load it

As far as I can see, most current schematic packages are not the sort of
"macro schematic" software that you have talked about, so there is probably
plenty of use for it.

Quoted text here. Click to load it

Have you had a look at http://www.geda.seul.org/ ?  It could be that you
could work with them, combining your efforts.

Quoted text here. Click to load it
newsgroup
that
definitely

HDLs can be fun too :-)


Quoted text here. Click to load it
do
in

Sorry, not much - I've not done it myself.

Quoted text here. Click to load it
software

Protel is the only program I have used extensively for schematic design, but
I have not done any significant simulation with it (although I know you
can).

Quoted text here. Click to load it

I believe you can treat the external EDIF file as a black-box, and use it
for both simulation and synthesis (although you can't optomise it much).  I
think that is the way mixed-entry designs (part schematic, part HDL, or
mixing two different HDLs) are handled.

Quoted text here. Click to load it

That's out of my depth - ask it as a seperate issue in comp.arch.fpga.

Quoted text here. Click to load it



Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

in project navigator
->new source ->schematic  type in the name of the file for it to create
click okay
ecs (xilinx schematic editor) will start up and you
can start drawing up your schematic.

with webpack the major hassle is simulating a schematic design.
You have to convert your design to vhdl or verilog so
modelsim can load your design.

Altera's software is much better for simulating schematics than =
xilinx's.

If your looking at using schematics you may be better off with other =
software.

Protel can handle schematic designs for fpga's.(Just rather expensive)
Worth keeping an eye on their web site for announcements sometime in the =
next few months.
With it, there will be no need to use any of the fpga manufacturers =
software.
http://www.altium.com/media/mr_BoC.htm

Alex

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!

Greets,
John
 

Re: Schematic simulation and then FPGA programming?

Quoted text here. Click to load it

thats weird I have the same version of webpack

Quoted text here. Click to load it

looks like at uni, they are going to dump xilinx and go with altera.
Just due to the simulation hassles.

Also looking at changing from cplds to smaller (50k to 100k gates).

For fpga questions you are better off asking in comp.arch.fpga.

Alex

Site Timeline