1. Home
  2. Field-Programmable Gate Arrays
  3. SCHEMATICS ... Is anybody as frustrated as I am with the software?
  4. Page 2

SCHEMATICS ... Is anybody as frustrated as I am with the software?

Symon, note that the above textual spec (albeit clear in itself) has ZERO information about what's feeding data in, where the output is going, etc.. What a schem/block gives one is the -connectivity-, and at a -glance-. I think that's what I was trying to get at....the ease of seeing -interrelationsips- in a graphical format.

I might find it hard to argue in the case of the multi-million gate chip....but then I again think that even the mega-chip is generally wired as -blocks- of logic, is it not? I.e. functional blocks. At

-any- size, there can always be a hierarchy; just as there is with textual description.

Nevertheless; your mention of a mega-chip did cause me to sit back and wonder if there is the "optimum" approach might be size-related?? I.e., those who are repeatedly doing desgins of a few hundred registers (like myself) may benefit more from a graphical approach than the designer who is tackling the million-gate monster.

I have to say though, that when it comes time to troubleshoot the

-product- that your monster-chip is embedded in, I will -still- want a block-diagram of your chip! LOL

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----

formatting link
The #1 Newsgroup Service in the World! >100,000 Newsgroups

---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Reply to
metal
Loading thread data ...

Hi there, Yeah, fair point on the block diagram! And 'monster-chip' is an apt description of some of the stuff I seem to be involved with. :-) I think you're right on the optimum approach depends on size. For a small design or, as you point out, a small part of a 'monster' design, a schematic could be a good way to do things. OTOH, for a large DSP design drawing 18 bit multipliers gets old very soon. Writing a

Reply to
Symon

I don't think many people would dispute that a well-drawn block diagram makes it much easier to visualize a system than the equivalent pile of VHDL port map statements. But as soon as the number of components, their sizes, and their interconnection patterns have to change according to the configuration of the system or subsystem -- i.e. as soon as you have a generic, re-usable design -- then schematics become virtually unusable.

Try drawing schematics for an arbitrarily-sized tree of binary adders. Wouldn't that be a useful thing to have in your library of re-usable IP for future projects? With VHDL this is a breeze. Good luck with the pictures-only version. And as soon as you have to contemplate writing scripts (text!) to generate or alter schematics, you've given up the fight.

One of the powerful things about a block diagram is that I can draw:

+-----+ +---------+ | | WIBL | |+ | A |========| B ||+ | | | ||| +-----+ +---------+|| +--------+| +-------+

...and it says "there's widget A connected to several widget Bs via the Widget Interconnect Bus Lines". In my HDL source code I can see the various bus signals and the exact number of Widget Bs and all the other details of the design that shouldn't be visible at this high level. As soon as they make these types of diagram compilable, maybe I'll be a graphical design entry convert! But such powerpoint-to-gates technology is not available today...

Cheers,

-Ben-

Reply to
Ben Jones

doxygen and graphviz work together to produce call and dependency graphs from c , c++ source code to be inserted into doxygen produced api type docs

formatting link
maybe there is a way to use them to parse vhdl or verilog into a schematic or at least block diagrams?

Doesn't altium with the lastest version of altium designer use netlists as the backend ? or have import to schematic I'll try to remember to have a look tomorrow at work

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.