VHDL vs. Schematic Capture

"function",

that

libraries,

with

as

I'm not sure what you could be saying "no" to, they are simply statements of fact.

No thinking involved, so no possible flaw in it ;-) I speak from nearly two decades of direct experience with FPGAs, and three decades of direct experience with ASICs. I know exactly what it takes to use both methodologies, as well as a combination of both. Also, pins aren't "linked" entirely manually. And, hooking wires is typically quite a bit faster than typing things in. I have not found this issue to be a significant part of the process, on either end.

No, not at all.

Of course, I have plenty of them, but the time savings is far less significant, than it is for schematic libraries. Especialy for elements such as muxes/counters/registers/IO, things that are multi-bit, that in HDLs are one liners. People who draw FPGA/ASIC schematics without such libraries surely will take longer to implement the same than than someone will using HDLs.

into

I would disagree. To repeat my self again, the tools are only as capable as the person using them. I have not seen many schematics drawn that well, IMO. The same goes with commenting HDL code, I see little of it actually commented well...but if someone is skilled at communicating in this regard, s/he can do a stupendous job. I include ASCII block diagrams and timing diagrams in my HDL. It helps me remember what it is I was trying to do, much less anyone else!

HDL.

To me, that's kind of a "so what". I can certainly visualize the dataflow of HDL code, as I believe any good coder would be able to, but what good is that excpt for the immediate point in time? It doesn't help anyone else, and doesn't help me the next time I go to look at it. A block diagram of some kind, at least for the datapath, I believe is far more useful.

an

decade

bit

was

Actually, no. I prefer the tool that gets the job done in the least amount of time, including making it work...which means making timing, and making the design fit. HDLs were not capable of getting the job done. Now, they are far more capable (for varied reasons), and therefore useful. Not only are the synthesizers better but IMO the biggest bonus to HDLs is that FPGAs are larger and faster. The same thing happened to high level software programming languages and CPUs/memory/disk drives. People don't need to be as skilled, in general, these days as they used to have to be to get a majority of the FPGA jobs done. This is a good thing for the industry IMO.

Of course.

come

an

now,

need to

I don't see how that relates to my comment...

schematics

are.

Possibly, but one of the arguments is that makes them tool specific and non-portable. This is an arguement that has been around for decades.

Regards,

Austin

Gary, are you still listening? Like I said before: "If you are considering learning VHDL (or Verilog), my advice is a resounding YES; Do it, learn it."

Austin, Austin.....

More than two decades working with programmable logic and you are NOT READY to suggest that learning VHDL or Verilog would enhance the skill set of a schematic designer!

Tell the truth, you want to be the only one with multiple skills don't you!! ;-)

I whole heartedly encourage Gary to "code in HDL"; he already uses schematic entry and doesn't require any encouragement maintaining that skill.

Hi Dave...

You're putting words in my mouth that I didn't say or even remotely hint at!

Of course someone working with programmable logic should, these days, learn an HDL. I never said differently, nor even addressed that issue.

I would too...but that isn't what I was commenting on, now was it? ;-)

Regards,

Austin

Yup, I figured this out about halfway through that project. But, the customer was real wary of synchronizing to any system clock. False logic, of course, but you are quite right. It could have been done totally without the binary-Gray and back again. Hmmm, now I don't remember, but I think the counter clock strobed the Gray code into a Gray-code register, which would then be free of any glitches. It was then sampled safely by a clock from a different domain. A hell of a lot of logic to synchronize 48 signals when only one signal really needed to be synchronized.

Jon

In FIFOs that use uncorrelated clocks for read and write, you need to use Gray counters for glichless compare. If you also want to detect programmable "almost empty" (dipstick) you really need binary addresses to do the math on. Since counting is so much easier in binary, it seems best to start with binary address counters, and then create a Gray version of it. But the Gray version must be registered, otherwise you move the binary glitches to the Gray lines. My trick is to derive the Gray logic from the binary D inputs. That way the binary and Gray count values are in sync, not offset. Minor point, but I like it... Peter Alfke, Xilinx Applications

My two cents are that i like to do breakup up my design in to modules first and come up with their interfaces and a rough schematic diagram then the deeper design and implementation is done in HDLs each module simulated tested etc then i fit them in the original schematic design. In this way i get a birds eye view of the whole design and the beauty of the schematic diagrams as well as abstraction of HDLs.

I dissagree with everyone else, and firmly believe that you should NOT learn VHDL and should just stick with schematic capture. Reasons:

1. I don;t need the competition; by not knowing VHDL you'll be stuck doing simple designs and will need my consulting services to do anything remotely complex.
2. WHy bother learn something new on your own? Now that you have your degree, you should just stick with learning new "team building paradigms" to make the MBA's in your company's work easilier.
3. The fact that all engineering curriculae now have a requirement to know vhdl (at least in the eastern US) shouldn''t worry you. Just make all the new hires do everything using s(c)hamtic capture., and they'll soon forget everything they learned about vhdl by the time they get their first layoffs.
4. By using schematic capture, you participate in the great globalization trends of outsourcing currently underway. Your management will soon realize that their native US design engineers are two decades behind the times and will immediately increase their bonuses by outsourcing your job to either India or preferably China, where the communist party can keep the chinese engineers in line.
5. Lastly, but not learning VHDL, one day your idiot vice president will get the briliant idea that all his engineers will learn systemC, just based on management-oriented marketing. Since he probably knows C, he figures by forcing everyone to use systemC (1) he'll finally be able to figureout and and thereby "help" everyone with their designs. (2) be able to hire a bunch of low paided and layed off software engineers to do hardware, and finally (3) just give the project to some REALLY low paid software engineers in India just becaise they know C.

Allways glad to help (don't call us - we'll call you)

Gary Pace wrote:

I draw a block diagram of the major components as well before putting stylus to papyrus & generating HDL code.

Does the VHDL spaghetti exist? I do see many ugly schematic drawings. Well anyway, learning the hardware description language is not that hard if you are the schematic guru, for ones with such experience it may take 1-2 weeks to get the basic and more...and that's enough to do the rocknroll :)

Mounard,

Would you consider the Alpha processor remotely complex, or a simple design?

Austin