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..
Hi, 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) 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. 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) May be I'm a slow learner, or I missed something here, would like to hear other opinions. Regards,
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.
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.
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?
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.
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.
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.
This is what most people do with schematics. There's no need to have thousands 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 hierarchical constructs that contain instances of primitives. All of the multi-bit counters, latches, comparators, etc. are made this way.
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 actual logic will bear little resemblance to what you created at the schematic level. 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 optimized out.
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 going to try it entirely in VHDL just to see how it goes.
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 implemented).
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.
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 HDLs. 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 on HDLS, and partly because of superior macro generation capabilities. HDLs do give a couple of distinct advantages:
1) you can read the source with a generic text editor. After getting stuck on old designs that needed updates and finding the schematic program (viewlogic) data base format or libraries had changed it was refreshing not to have the right version of reader to be able to look at an archived design. This is particularly important for archived designs.
2) For portions of the design where time to completion is critical and performance 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 description is very helpful for writing testbenches for simulating the circuit. Because of this ability, it is much easier to write testbenches that simulate the circuit both more realistically and more completely than is possible within a reasonable amount of time using strictly schematic tools.
4) Parameterized construction reduces the size of libraries, as well as the effort 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 than having a different library element for each width or function variation (eg. signed 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 with 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:
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
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:
Draw up a design using paper, Visio, or whatever works. (I've found Simulink is the best dataflow block diagram editor around.)
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 interested.)
BTW, please don't code FPGA flip-flops as a pair of NAND gates. :-)
Totally agree. I need to see boxes and lines before I can make sense of 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).
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?
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.
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.