A good friend of mine just finished a class in VHDL. Hopefully, he'll get to use it soon. The reason I mention this here is that he brought me back an anecdote. The instructor (allegedly) explained that, among US HDL users, there is a very clean break that coincides with the Mississippi River. Those west of the river use Verilog, while those east of it use VHDL. Except for little islands here and there, the split is supposed to be pretty clean. I don't know if that's true, but it's certainly interesting.
Have I mentioned that I'm lazy? If not, now's a good time for you to figure it out.
After my previous blog, we now have a hardware designer's Hello World implementation working on our board. There are some additional things we can do, but we'll need to play with some more I/Os real soon. This would seem to be the point to install some connectors on our breakout boards.
Go to your favorite vendor, and buy some 100mil pitch connectors. You can get them pre-sized, or you can purchase the kind you can break off to length. Another alternative (probably easier) is to go to Opal Kelly's page, where pre-sized connectors are available for relatively reasonable prices. (Look at the bottom of the Products Page for the Accessories category.)
I noticed that the standard square connectors will barely fit in the mounting holes. I actually had to press them in. I went ahead and soldered them after the fact, but it probably wasn't necessary. Also, I dropped in pins instead of female connectors, but you might not want to do that; it's a bad design practice. I just used what I had in my scrounge drawers. (Now you see what I mean about being lazy.) It would be nice just to plug a wire into the female connector, but I'm left with having to make pins. Be forewarned. I wired up to an old protoboard that's been lying around probably since around 1986.
As a fun thing to do in the meantime, I put together a new version of my Hello World implementation using the schematic editor. Basically, this comprises a series of clock dividers feeding a ring counter. The clock is gated using the mom switch (my vernacular for a momentary switch). If you are a newbie, you might want to see if you can figure out how to do this yourself. One of the hardest parts for me was figuring out how to initialize the registers at startup. Alternatively, you can download a compressed ZIP file containing my schematics and other files.
Here's a video of my new implementation.
Now take a look at the following picture. I'm sure I'm not the only one with a desk full of old parts, but how many of you can say yours looks this bad? And this is after I tidied up. I definitely need more space to play with.
Finally, a real question for the experts: Is there some way for us oldster newbies -- older engineers who are new to the programmable logic world and still like to capture designs using schematics -- to see the HDL generated by our schematics? This seems like a good resource for learning. What do you think? Is that worthwhile?
Shakeeb: @thrakkor - I too feel the same that "The schematic entry part of board design could be done better in an HDL like format."
I worked for a small company that used a text-based "schematic" entry design methodology. It was home grown and used emacs for entry because a bunch of LISP modules were written to do all sorts of things. It didn't use VHDL, though.
It was quite powerful. Basically, the system "knew" about all sorts of parts that existed in "libraries" in known locations in the file system. The parts in the "libraries" were just text descriptions of the part's pinout. It defined the usual pin types (input, output, bidirectional, passive, power, etc) and it handled passives (resistors, caps) and such all the way up to large BGA processors and FPGAs. The parts also had a defined PCB footprint, and part names followed a somewhat-straightforward standard nomenclature.
It was hierarchical, too, in that you could define a "module" which included all parts you'd need for say a processor -- the processor itself, decoupling caps, cache SRAM chips, etc etc, and you just instantiated the module into your "schematic."
After design entry was complete, you'd run a DRC which checked whether inputs and outputs were connected legally, and it flagged no-connects and missing pins on a part and all sorts of things. It spit out a netlist which was imported into the layout tool.
It also had hooks to build a BOM and some other useful manufacturing things.
Being text based, it was easy to diff and edit and compare and everything we take for granted with HDLs and software development, although it didn't use an SCC per se.
Of course it had downsides. The most obvious was that it was home grown and basically the only person who could support it was the president/half-owner of the company (long story). (The company was bought by a larger company and my group was axed pretty much right away but I found out that the president left soon after.) Also if you're looking for a job and you're asked "which EDA tools do you know?" it wasn't something you could put on a resume.
So yeah, a text-based schematic design entry method is nothing new but it's definitely something that requires a solid architecture.
Okay, I'm not being a complete naysayer here. I'll stick with my assertion about too much abstraction when working at the PCB level.
However, as far as an HDL for an analog circuit goes, this already exists, and has for many years (since the early 1980's, at least). This is called SPICE.
Every vendor of modern ICs supports it at some level, and it is flexible enough to model device physics at a reasonable level - so long as you understand the limitations, etc. The main thing that, say, a PADS netlist brings to the table is physical properties.
For me, at least, this is one of the great things about schematic entry - I can generate the circuit, model the circuit (with certain caveats), and then hand it off to ta PCB tool. In some cases it's all integrated (although not in many). No doubt, I often find myself at the netlist level "tweaking" things to get them to work correctly across tools.
But I also find it very difficult to look at a netlist and get an understanding of a circuuit topology without spendinga lot of time trying to recreate the circuit, whereas I can look at a schematic and almost imediately understand - at least for simple schematics.
Over the years, I have found myself having to reverse-engineer and troubleshoot, and the ability to trace a line on a schematic (or multiple lines, for that matter) has been requisite. I am sure that *I* would likely not be able to do the same with just a netlist. In fact, I would find myself rebuilding the schematic from the netlist, first, so I could more readily identify the problem areas.
And that brings up another point, too - physical placement of parts is very important in a circuit design. No netlist I've seen (beyond the Gerbers) puts that information in there, in a way that's easily understandable.
for component values, I would use VHDL's attribute mechanism.
also, while working on this, I remembered VHDL-AMS, which is VHDL - Analog Mixed Signal derivative of mainstream VHDL. looks like an even better candidate than what I whipped together.
@Hamster: HDLs are more than a generation old and yes, many have dropped schematics(practically everybody here). I have been talking about using block diagrams where the blocks have HDL design files used to generate the graphics that are certainly useful when iterating on a design to find ways to optimize it.
HLS ain't here yet, so it is up to the designer to optimize. If you have a way to do that with an HDL so be it and bless you.
HDLs are not for programmers, but some programmers may put forth the effort to understand that they are a way to describe hardware, no sympathy for programmers that do not understand hardware and try to write HDL -- go play with programs.
Now what is a good way to learn hardware fundamentals?
You are right that block diagrams are not detailed enough for implementation, but certainly can be useful to tie things together and develop concepts. I do not mean doing a quick experiment by throwing together a small amount of code or modifying code on a development board.
We really should define schematic entry so everyone knows if that means a bunch of TTL gate symbols with a ton of spaghetti thrown in OR does it mean blocks connected by functional named busses and external signals.
Did you just say that programmers start writing code on day one?
Maybe, maybe not. I'll be a complete heretic, here, and posit that I think there *IS* a such a thing as too much abstraction. *gasp*
All this abstraction is wonderful in the FPGA/programmable device world, as you are working with generic "fabrics" of sort (even in a GP processor). No doubt, people who understand what's going on "under the hood" will likely build better mousetraps than those who don't (generally speaking), but this intimate knowledge of the inner workings isn't necessary (or so it seems) beyond timing.
In the *very* analog world of circuit layout, I think there needs to be an understanding of not just the physics inside the things, but also a good grip on the physical characteristics of those things. I can point to the old wag about the guy who ordered a 1F capacitor (back in the 80's), but instead I'll point at something much more personal...
When I was in my 1st college-level digital class, the time came when we had to build our first project. It was something *really* simple, a handful of gates wired together on a protoboard. I ended up having to explain to some of my fellow studenst what an IC was, as they had no clue about the relationship of the devices in their hands as compared to the symbols they had been working with in homeworks. Some of them didn't even understand that they needed to have power.
More recently, I see people daisy-chaining power and grounds, not terminating lines, not looking at crosstalk issues, and so on. I think doing schematics, at least at some level, forces you to think about those things.
@Thrakkor: Given your background where you started with purely HDL, you had no things to "unlearn" and synthesis had matured and you took it as a given.
Duane and Crusty have commmented about carry overs from previous experience, so I really think they can relate to using familiar things and then to grasp the notion of using HDLs.
Maybe it would help if you illustrated "the 1:1 HDL description of a schematic (no abstraction).
I think they know what a schematic is, so now they need to understand why HDL is so much better.
I dig where you're coming from on FPGAs and other programmable "fabrics," but I'll have to disagree vehemently when it comes to PCBs. They are, by nature, analog. You can get away with a lot of sloppy stuff at low speeds, but they'll kill you on a number of fronts that don't even have to be particularly fast.
Regardless of what some vendor may tell us, laying out a PCB is an inherently manual process, and getting the components and connectivity correct is a part of that process. Sure, it can be defined by a netlist (that's a ll a PADS file is, after all), but the engineer/designer is going to be making the connections manually, for the most part.
One of the things I've been wondering is whether or not the "okWireOR" module is really just a giant OR, or if the order in which things are attached matters.
I am convinced that every country has its own governmental office buried deep down in some dark, dank basement -- on this office door is a single word: "They!"
In this column we will extend our Opal Kelly FrontPanel interface to have two "okWireOut" devices in the FPGA... or maybe not depending on your point of view.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
