I sure hope that Xilinx puts more effort into their schematic tools, even though it comes at the expense of their high level language support.
I had a funny interaction with a representative of a certain FPGA company that will remain unamed. (It could have been any of them, as they all say the same thing.) He told me that their new logic system was going to allow automatically generated logic to be placed as efficiently as hand placed logic. I told him that I had known him for 10 years, and he had made that promise through 4 FPGA silicon generations, and that I doubted it was true this time.
When FPGA sales guys go to companies, they usually have to sell to management. Management wants to hear that they can get rid of their nasty, overpaid grey-haired engineers and get the same quality of work out of fresh faced, good smelling youngsters, fresh out of college, who will work for stock options. Management believes that they can achieve this goal if they can just pick a tool set that doesn't require a lot of intellectual effort on the part of the user. In particular, management doesn't want to have to hire engineers that are capable of floorplanning.
(A side note about Altera. It used to be that they bragged that their FPGAs had predictable routing delays. That is, the wire delays didn't depend on the precise location of source and destination. They don't brag about that anymore, since the last couple generations have been forced to a more segmented architecture. Not only does their LAB logic wire delays depend on whether the source and destination are on the same row, it also depends (horribly) on how many destinations are used on that row, and how far apart they are. You cannot get good performance out of Altera without floorplanning, and their technology/tools are not nearly as good as the Xilinx RLOC feature. (I'd still like to see the Virtex slice mess fixed up, though, so don't you Xilinx guys start slacking off on me!))
Management would also like to have a logic design technique that is very portable. That is, if the company finds a cheaper way of doing things, (for instance, if they want to put an FPGA design into an ASIC), they want their source code to be easily taken to an alternative vendor.
The first goal is probably a will-o-the-wisp. Floorplanning is just too important. The second goal is at least partly achievable by using a "high level" design language. These high level languages are text based, rather than graphics based. It is intended that the engineer enter the design in text instead of through a graphics interface. This strikes me as contrary to the forward march of technology. Didn't DOS get replaced by Windows because humans generally do better with graphical interfaces?
Anyway, their are two high level design languages that are particularly common now, VHDL and Verilog, and Xilinx also supports a third ABEL, which they may be soon buying the ownership of (from Data I/O).
Of the three, VHDL is the worst. It is incredibly verbose. Implementing a simple 4-bit decade counter takes 31 lines of code. Verilog is still pretty nasty, at 17 lines. The other problem with VHDL is that it is a general programming language. (An equivalent schematic decade counter would require a synchronously clearable 4-bit counter, and a 2-input AND gate. A total of two primitive parts and six wires, plus five port symbols.) One could write operating system software in VHDL, it just wouldn't be particularly efficient. ABEL, on the other hand, is similar to PALASM. No complications, it is very straight forward to use. Xilinx suggests ABEL be only used in CPLDs. I wish that Xilinx would more fully support it in their FPGAs, as it provides a real WYSIWYG interface for control freaks like me.
There are two basic ways of describing a block of logic in VHDL and Verilog. The first is to describe logic by describing how smaller logic functions are interconnected. "Instantiation" means to create a particular case of a general type. For instance, it is possible to make an RS latch by instantiating, and cross connecting, two NOR gates. Engineers call this sort of logic description a "netlist".
If the only way high level languages could describe logic was through netlists, I am sure that nobody would use them. But in fact, the top levels of complicated VHDL and Verilog designs I have seen implemented have always been done by the netlist form. Keeping these updated is typically the worst part of a project. It basically turns an engineer into a netlist compiler.
As an example, suppose your top level logic (called BKT) has (among others) two sub-blocks, BKA, and BKB, and you want to add a signal, SIGN as an output of BKA, and hook it up as an INPUT of BKB. This sort of modification is going to happen repeatedly as you build a design, and change things in it.
Here's what you do (in VHDL source code)
Open the source code for BKA. Add the code:
SIGN : out STD_LOGIC;
to the "port" section. Now, if the variable is used anywhere in your BKA code, you may have to rename it to something new, like SIGNsig. The reason for this is that VHDL will croak if you try to do certain things with a port signal (like using the state of an output port inside the routine). If this is the case, you add the code:
SIGN <= SIGNsig;
to the architecture section, after you have gone through the code and replaced every occurence of SIGN with SIGNsig.
Now do the same to the BKB code, except you need to add:
SIGN : in STD_LOGIC;
to the port section. You also don't have to deal with signal copies, cause this is an input signal. I'll ignore whatever you are going to do with SIGN now that you have it going into BKB.
Time to open up the BKT code, which contains instantiations of BKA and BKB. Find the "component" declaration for BKA. I should note that finding it may be somewhat more difficult than it sounds. Even FPGAs can have many hundreds of I/O signals. If the document contains the pin list, that is going to be 400 or 500 lines of code already. There can be an awful lot of stuff to look through. When you do find it, add the following code to the "port" list:
SIGN : out STD_LOGIC;
Similarly, find the component declaration for BKB. Add this code there:
SIGN : in STD_LOGIC;
Now find the "signal" section, where all the signal names are declared. Add the following code there:
signal SIGN : STD_LOGIC;
Now find where BKA is instantiated. (Hopefully only one place...) Add the following code to the "port map" section:
SIGN => SIGN;
Do the same for BKB, adding the same code:
SIGN => SIGN;
Congratulations, you have now added a connection between two blocks! You had to add code to 8 diffent places in (typically) three different files! Yes, you are now a human netlist manager! Feels great, doesn't it! Maybe you should compile it and see if you managed to mistype something... If you're really lucky, maybe the compiler will actually come up with a useful description of what the error is in your 10 thousand lines of source code...
Compared to VHDL, making the modification in schematic land is pretty easy:
Open up the top level schematic. Select block BKA, and go into its symbol editor. Add an "output" pin, with the name SIGN to the symbol. Close it.
Repeat with BKB, but make it an "input" pin.
Draw a wire connecting the BKA and BKB "SIGN" pins.
Now open up the BKA schematic sheet. Add a hierarchy connector of type "output" with the signal name SIGN. Close the sheet.
Open up the BKB schematic sheet. Add a hierarchy connector of type "input" with the signal name SIGN. Do whatever you wanted to do with it... CLose the BKB sheet. Close the BKT sheet. You are done.
The above sort of thing gets worse for more complicated designs, with multiple levels of hierarchy. It might be more typical to have four levels of hierarchy rather than the two I have described above. In that case, you will have to go into all the intermediate hierarchy levels and repeat the process...
So much for the instantiation (human netlist generator) part of VHDL. The other half is typically used for lower level blocks, and is intended to describe what the circuit does, rather than what it is composed of. The idea is that the compiler will then figure out what sorts of logic would best do what the designer wants done. The manual uses the word "inference" to describe how you get from a description of an action to the actual circuit. Inference. Being a control freak, I like to give orders. This sort of VHDL is more like announcing your wishes, and then hoping that your friend will "infer" what it is you want. Sometimes I wonder if VHDL wasn't designed as a welfare project for underutilized engineers. The language was designed by the IEEE, so it makes you wonder...
-- Carl |
