Schematic simulation and then FPGA programming?

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

Reply to
John K.
Loading thread data ...

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

Jim

Reply to
Jim

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

Reply to
Jim

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

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

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.

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". ;)

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

Reply to
John K.

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.

formatting link

Alex

Reply to
Alex Gibson

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

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

Reply to
John K.

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

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.

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.

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

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.

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.

Have you had a look at

formatting link
? It could be that you could work with them, combining your efforts.

newsgroup

that

definitely

HDLs can be fun too :-)

do

in

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

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

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.

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

Reply to
David Brown

create

thats weird I have the same version of webpack

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

Reply to
Alex Gibson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.