I've recently noticed that the schematic software that's included with XILINX' ISE WebPack and with Altera's Quartus WebEdition software is pretty lame. It looks as though the folks who generate, maintain, and repair this stuff have never had to make their living with it.
I recently abandoned the last two releases of XILINX' WebPack stuff because there were problems making it nearly unuseable. Release 7 was apparently written in VB or JAVA, hence, was so slow I couldn't use it, and release 8 was not only slow but "broken" in a number of ways that I couldn't use it either.
Several bugs that I reported in 2002 still can be found, including a problem aligning bus taps with nets drawn on the grid that aligns with the symbol pins, translation/netlist errors, random breakdown in sequential signal-numbering (tell it to increment, and it decrements, and vice-versa, but not always) ... I could go on, and will in a note to the local sales rep ...
The release 3 and 4 of Quartus wouldn't display whole text strings on any of our HP desktops. That meant that, for a year, no Altera development could be done, except with MaxPlus-II.
The current Quartus doesn't associate net names between net segments, i.e. if I put a right angle in a "wire," it loses its net-name property. There are cases wherein a net name can't be deleted from a sheet, even if the net's gone, where a net name=>pin assignment won't work because the assignment editor doesn't allow editing of the net name, and busses ... well ...
So, are any of you guys seeing the same sorts of problems? Doesn't it make sense to have a half-hour review of a schematic rather than a week-long review of a ream of HDL listings?
For most of us, the days of schematics are long gone but they still remain useful for high level views and for floorplanning. The best schematic tool I ever used was VLSI/Compass for ASIC design, it got most everything right and even allowed true edit in place of symbols within a live schematic but VLSI Inc developed that for their ASIC biz some 20yrs ago. When it garbage collected though it died for 20mins. Once synthesis & HDLs took over, all these schematic tools went south, there is no revenue model for them.
My big gripe has been the uselessness of the synthesized schematics from code, if the code is trivial to understand, the schematics can be passable but not of much real help. If the code is too complex to understand, the software has no way to know how to reconstruct a decent looking schematic. Since these are constructed each & every time from synthesis, the slightest change to source code means a complete regeneration of synthesized schematic. Much of the code wouldn't really translate well to schematics as it looks more like C expression code than object instances. I would like to see a mechanism where by the synthesized schematic could be somewhat edited for good presentation and that the result be reused for the next pass without the tool getting confused by small changes. The biggest joke is when you build datapaths n bits wide, and these tools usually just consider these bit paths as just more soso giving mostly random placements that are easily made non linear by smaller edge details. If a draftsman created these machine like schematics, they be out the door pronto. In the ASIC world they have $$$ software that can take flattened mass of logic with regular hierarchy removed and refind the natural hierarchy and put it back in for more regular layout, but that wouldn't work too well over FPGA fabric. Don't expect too much from unpaid software.
HDL code is optimized for simulation and synthesis. It makes more sense to review the simulation waveforms. because, for the right design rules, the waves will be the same on the bench.
I was using schematic entry for as much of my design work as possible a year or two ago, much to my colleague's dismay!
(I must admit, finding and placing bus joiners and creating new nets just to wire up a component that would be 2 lines of VHDL was beginning to annoy me.)
However, since then I've been doing a lot more HDL work and have actually gone back and converted all my early schematics to VHDL! I'm now a "born-again" HDL'ian and find it so much quicker and more convenient to develop, maintain, re-use and *PORT* HDL code - not to mention source control is a lot nicer/easier now. My testbenches are all written in HDL as well now (mainly Verilog).
FWIW, I'd never return to schematics. Yes, top level can be nice as Mike pointed out, but I find the disadvantages - slow, buggy tools, cumbersome maintenance, no portability - far outweigh the benefits.
If you could watch the operation of the circuits inside your prototyping board directly on your schematics as they run in real-time, or clock by clock would you find this useful?
I worked with some tools way back when that had this capability - I think Mentor quicksim/design architect IIRC - or maybe it was Daisy. I found it to be not really that useful. You really need to see waveforms to make sense of what is going on.
Speaking of schematic editors, Mentor's Design Architect was a fantastic editor. The "stroke commands" were genius. Hold the middle mouse button in and draw little free-hand "glyphs" that would disappear when you released the button as a way to invoke common commands like select, copy, move, delete etc.
Yes that is what our product does, you can see the values directly on components, and as waveforms as well. Best of both worlds, only it is not a simulator, what you see is what's going on in the hardware. Here is a picture of what I mean:
formatting link
If you look at the bottom of this page there is a picture of our long time scale waveform view. With this you can watch for spikes etc. over days of real time. Can you do that with your simulator?
Synplicity sell something called Identify. It shows the operation of the circuit in the HDL source, I believe. Uses the JTAG interface. Dunno if it's any good, I never make any coding errors, so I don't need it. Ahem! ;-)
formatting link
Personally, I fail to see any benefit of schematics. Once you've been using HDLs long enough, it's just as easy to visualise the FFs, gates etc. from the code as it is to look at a pictorial representation of them. You can also see a lot more of them on one page! Mike's point about simulation reviews is spot on, and in my opinion, people who are using schematics would be better off following this course rather than reviewing the schematic sheets. I don't want to start a flame war here, this is only my personal preference, greatly influenced by the fact that I wasted the best part of an afternoon last week when I had to maintain some old viewlogic stuff. Turns out a square dot doesn't connect like a round one. The problem was compounded when the software engineer solved it. Arse. Cheers, Syms. p.s. One last point, it's easy to write Perl scripts to create/change HDLs. How you gonna do that with schematics? HDLs also have much more powerful reuse capabilities. Generics to control bit widths, blah, blah, blah. This schematics vs. HDLs must've been gone over a hundred times on CAF. I'll shut up.
It was the utter uselessness of the schematic tools for programmable logic (they sucked 15 years ago too) that helped push me to learn Verilog and VHDL. I am now far more comfortable using those languages than schematic entry for programmable designs (although I use schematic tools for PCB designs, obviously).
I know there are some who have no choice but to maintain old schematic based programmable designs, but for new designs I would just go to a synthesis language.
Syms, I think the strongest argument for schematics is readability. I still often have to draw out the schematic on an HDL design to fully grok what is going on, and I've been pretty much exclusively VHDL since aroun 1999. On the flip-side, the state of the HDL tools makes it much easier to reuse. It can be done with schematics, but the mainstream tools didn't do a very good job of supporting it. Back when I was an avid viewlogic user (and maybe a rabid one too), I had more or less perfected a system where I got much more reuse than the average bear. My schematics were also much more hierarchical than most, with each level of a design fitting on one sheet, and the low levels consisting of one and two bit slices. I could still use a good HDL to schematic viewer that allows you to hand edit the position of stuff to make it a readable schematic.
Ray, yeah it's interesting to hear what works well for different folks. After about 8-9 years of almost exclusively doing HDL designs, I've found myself doing a fair bit of maintenance on some viewlogic stuff over the last month or so, and, for readability, I've found myself doing the same as I do for VHDL, i.e. drawing timing diagrams to work things out. It's got to the point where I've looked (unsuccessfully) for tools to do some PCB design entry using VHDL. I'm getting sick and tired of drawing a bunch of rectangles with hundreds of wires coming off them to represent an FPGA. Also, adding each and every bypass cap. If I could use VHDL for this, I could cut and paste a lot of the pin information from the data sheet to be more accurate and quicker. Of course, for analog electronics this makes little sense, but it would be nice to be able to mix and match the two entry methods. Cheers, Syms. p.s. This is a useful link which automates some of the symbol creation tedium.
The better PCB packages will allow ASCII Merge (multi import) of NetLists - so you could use scripts to create a PCB FPGA netlist, from the Pin reports, for example. That does properly track Changes.
I think you'd still want the Caps, and FPGA itself in the SCH :- that gives correct BOM, and in many cases you can build parts with SIGPINS that invisibly connect to GND, + 3.3V etc - so your CAPS and FPGA symbols could have NO manual connections needed.
Might be OT, but I'm interested in any pointers to the current state-of-the-art in automatic schematic generation. By this I mean: I give it a netlist, it draws what it thinks is a "pretty" schematic for some heuristic definition of "pretty". Even if "pretty" means "just barely not hideously ugly".
In the area of mathematical graphs (spline edges, no 90-degree requirements -- a very different problem) GraphViz is sort of the "reference point" from which everybody else makes improvements:
formatting link
... I'm looking for some similar analogous feature-point for schematics rather than general directed graphs. And yes, I know this will never be as good as human-drawn schematics.
I don't have an answer for you, but did want to thank you for posting the link to graphviz. It may be the solution to a problem I've been trying to solve for a long time.
Ironically, even as a 'born again' HDL'er, you just pointed out that the "benefits" of HDL over Schematics may not have had anything to do with actual benefits; but rather, may have been due simply to the abysmal fpga-schematic -tools- that we were all forced to deal with.
Assuming -excellent- schematic tools, the benfits of graphical presentation will shine, as they must -always- do. This is simply because the human brain is -wired- to process graphical information; and graphical/visual presentation has a higher info-content than plain text.
Think of graphical-info as "high level langauge" vs. a screen full of text as "assembly", and that'd be a semi-accurate analogy I believe.
As I write this, I realize that there are -two- aspects of this issue;
1) Design is one (the OP's original subject)
2) but Presentation is a 2nd aspect
Schematics have it all over HDL for 2), and as Ray pointed out, have distinct benefits in top-level design as well.
I've forgotten who posted about having invested a lot of time in setting up an optimized Viewlogic setup; but his description of how it operated gave a glimmer of just what an -excellent- FPGA schematic front end tool would be like. Just think if it was easily -2 way- !
Where one was dealing with a major functional block, and it was faster and easier to understand visually, you could drop a box on the screen, label it, and open an HDL window to 'populate' it. And where it was quicker to just write 3 lines of HDL, you could start with that, and have the tool automatically plop a finished and labeled box on the screen for you. You'd be working in both high level visual -and- low level HDL code -simultaneously-. Now -that- would be nice...
Regarding the complaints about drawing "hundreds" of wires coming off an FPGA, and having to draw all the caps on the FPGA....c'mon, those are both partially specious I think.
In the first place, the vast majority of pins on the vast majority of FPGA designs are -bus- lines; which are virtually- always drawn as a single line representing 8,16, 32, or more, connections/wires. Draw just 4 or 5 of those, and you've finished 80% of the connections on a
160 qfp like a PCI intfc design. It ain't -that- tough...
In the 2nd place, the convention for bypass caps is to group them all on their own schematic; i.e a "power and ground" page. It is rare that I ever see them placed right next to chip symbols on any schematic these days. (one -does- want to remember to pass placement notes to the layout-man though! )
With most modern schem/pcb systems, a dozen bypass caps can be instantiated onto the sheet, and connected to GND and 3.3V, in about
60 seconds.
In terms of 'readability'...let's all be honest now. Only the most
-expert- of HDL designers can look at a multi-page listing of dense code and have -any- understanding of what the hell an FPGA -does-, in any short time frame (i.e. seconds or minutes).
The rest of us, even most HDL designers, will spend MANY minutes, even hours, trying to figure out what the heck the part -does-; let alone how it works.
Yet -everyone- could look at a schematic of that chip and gain at least a glimpse of the overall functionality in mere -seconds-; and a pretty in-depth understanding in perhaps 2 minutes.
For all the rest of the engineers and technicians on the entire planet, a schematic of the inside of that FPGA is an -invaluable- aid in troubleshooting and repairing the equipment that it's a part of.
I have spent plenty of years on both ends of the stick, design and troubleshooting, both my own designs and those of many others; and that's how I've learned to value both the code AND the high-level visual presentation.
You will notice that even in the pure software world, higher-level tools like flowcharters and "code block layout" tools retain a place of importance. Again, graphical/visual presentation is simply more
-efficient-....it carries more information per visual/brain "bit", so to speak.
A single 8x11" schematic page can -easily- represent -many- pages of HDL code....and even represent that HDL -and- 10,000 lines of software combined. (i.e. one little rectangle labeled "DSP core for FFT's", etc. etc..). This is an extremely valuable design-method, and presentation-type, that we shouldn't be letting escape from our toolboxes so blithely.
I thank the posters who talked about or asked about what tools are out there; for both the OP's entirely valid complaint on the current offerings; and for the other category of tools to -extract- readable schems from HDL code.
I'm a firm believer in HDL as well, and would love to have a toolset for automated schema production from code; but in no way does plain text replace visual/graphical display of information, imho.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
formatting link
The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
I hate to admit it sometimes, but for several recient fpga boards I've just skipped doing schematics for them entirely, choosing instead to design with scripts, augmented parts libraries, and netlists.
It's much faster to verify a board with netlists when parts have reasonable signal names on library pins, and using script driven netlisting with reverse annotation from the layout to transfer net names to the fpga pins. Visually scanning netlists for 1517 ball bga's is MUCH quicker than following that many lines on a schematic and verifying pin/ball numbers.
It would be very nice to document a design if there were tools that would take the same finished netlist and pcb layout, and autogenerate schematics --- except for the fact that thousand pin bga's just don't fit well on schematics anyway using 1960's drawing standards.
The last great schematics bundled with Xilinx software is ver 2.1i. The schematics is very intuitive and very easy to use. The schematic software that is bundled with Xilinx 3.1i and later is very clumsy. The diagram looks very ugly too. I have never used Schematics anymore after they released ver 3.1i
It does make sense for one to learn schematic first before learn HDLs. Schematic forces you to think in term of hardware. In my opinion, it is not a good idea for one to learn HDL directly without having any exposure to shematics or get their hands dirty with TTL chips. People who never learn schematic usually treat HDL just like C. When they do that, their codes either do not compile or compile but the result is totally different from their expectation. HDL has a great advantage over schematic but one should know the schematic representation of their HDL codes.
A trip to the DAC website and look at the software vendors of EDA component parts that Synopsys, Synplicity, and others buy from. There was/is a company in Germany that made these netlist => schematics last time I went and I chatted with the developer about precisely these concerns in this thread. He was surprised at my comments, they only seem to talk with their immediate customer and not final end users so don't get real feedback. He asked me for examples of bad schematics that could be drawn better and what the heuristics might be, but I never took him up on it.
OK, so this 'pictures are better' idea is not necessarily so. Cro-magnon man was great at cave painting. However, as someone once nearly said, I didn't get where I am today by looking at pictures. It took the printing press to move mankind to the level of technology we're at now.
How many textbooks are on your shelf? How many have a list of chapters in text, and how many have a picture representing the contents of each section? Who says top-level design should be in schematics?
Yep, in the old days of PQ160s it was easy enough. Now that there are 1000's of pins, it's a right royal PITA! It's true you may have busses connecting to the FPGA. The trouble is, you need to connect the bus to the FPGA in a manner that reduces the number of layers of PCB you need. If you just whack the bus on the side of the schematic symbol, the poor layout guy will spend weeks adding layers, vias and God-knows-what trying to route your design. Use a picture of the BGA balls (NB. I'm not totally anti-picture!) and work out the best pin connections for the bus, and type them into a text file.
That's not nearly enough caps. ;-) C'mon, how long does it take to type "12 Vccint 100nF Caps"? Less than a minute, and you understand it!
No. For both methods, HDL or schematic, the key to understanding something you've just come across, is to read the comments. In text. The signal names should be meaningful. Text, text text!!
ENTITY DSP_core_for_FFTs IS PORT( CLOCK : in std_logic; DATA_IN : in std_logic_vector(127 downto 0); DATA_OUT : out std_logic_vector(127 downto 0) ); END DSP_core_for_FFTs;
Pretty clear to me.
I'm unconvinced that with today's multi-million gate designs that schematics have much of a role. The designs are so complex that a language based description is the way the design must be specified. I agree totally that the FPGA designer should have a 'view' of the basic hardware they're trying to fit their design into, I don't think that has to be a bunch of rectangles with legs on! Some well placed block diagrams can do wonders to illustrate connectivity and function, but well written text is better! Finally, if anyone wants to refute any of the points I've made in this post, I'd appreciate it if they could express their points in a viewlogic schematic. Thanks. :-) Cheers, Syms.
p.s. OK, that whole post was deliberately provocative, I know YMMV. I don't want to tell others how they should design, everyone has their own way of doing stuff, this is just my POV!
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.