DevineDrive.com

Xilinx ISE 10.1

In my case, it looks like the Translate step could not find some Xilinx generated cores. The search path is a hard-coded path, so if you’re checking out a project that is used by others, you will need to manually adjust the macro search path. To do this:

1. Right click on Translate under the Implement Design step in the Processes window.
2. Select Properties
3. Change the Macro Search Path to point to the location of the cores.
4. Click Apply.
5. Re-run the Translate step.

Since I’m checking out a project from SVN that is shared by other folks, the Macro Search Path was set to another developer’s macro path.

A 20 day free trial can be obtained from the Aldec website. The link to the download is provided via email. The download takes longer than the installation, so start the download before going for lunch or something.

A good tutorial for using Active HDL can be found here.

The main components of FPGA development are:

1. Design Entry

2. Synthesis

3. Implementation

The Design Entry phase is the starting point for the design. The design is created either in a Hardware Description Language (HDL), like VHDL or Verilog, or entered as a schematic capture. There are tools that will allow designers to enter designs as flow-charts or state diagrams.

The Synthesis phase is the translation of the HDL into a netlist. A netlist is a group of signals connection logic and flops together. The netlist is considered a flat netlist because there is no hierarchy. Meaning that there is only one netlist file and that netlist file contains all the nets (signals) for the entire design. The design hierarchy (modules and sub-modules) may be shown through the signal names, but that’s about it.

The Implementation phase is where the netlist is translated into FPGA-specific physical resources such as logic blocks and switching resources. The output of the implementation phase is a file that can be downloaded into the FPGA and run.

1. Signal - A signal is internal to the module. Signals are also used to connect up to ports of a module. Akin to wire in Verilog.
2. Block/Module - Designs are usually broken into one or more blocks or modules. These blocks/modules are usually a logical division of the work involved in the overall design. Each block can be described by two components: an external component and an internal component. The external component is called the entity declaration and the internal component is called the architecture declaration.
   1. Entity declaration - The entity declaration describes the interface to the block. For the philosophy folk in the crowd, the entity declaration provides the answer to the “Who am I?” question. For C++ programmers, think of this as a class definition.
   2. Architecture declaration - The architecture declaration describes the logic that is inside the block. The architecture declaration is the answer to the “What do I do?” question. For C++ programmers, this is akin to the function declaration. (Note: note that with HDL, function definitions are meaningless because the block isn’t accessed via functions, but through the signal interface.) (Also Note: There can be more than one architecture declaration associated with an entity declaration.)
3. Process block - Logic that is controlled by a sensitivity list. The sensitivity list is a list of signals that will trigger the execution of the block. Flops are done in process blocks.
4. Design Entry - Coding up your design. This can be done in a few ways. Two of the most popular ways are hand-coding of the design and schematic capture of the design. There are pros and cons to each.
5. Synthesis - Translating the HDL code into a netlist that represents the connection of signals and logic blocks for the entire design.  Optimization of logic may occur at this stage. The output of the Synthesis stage is a netlist usually in Electronic Design Interchange Format (EDIF).
6. Place and Route (P&R, PAR) - Takes the output of the Synthesis phase and assigns the FPGA resources to physical resources and switching resources in the FPGA. It is at this point where you can find out where logic will end up when the FPGA is programmed. The output of the P&R phase
7. Mapping - May be part of the P&R phase and converts the netlist into FPGA physical resources (logic and switching resources). This is where you will see if your design fits into the selected FPGA. N.B: Even if the design fits, it might not work.
8. Timing - The act of determining if the design will work properly with the provided clock. Basically, checking to see if the output of a flop will make it to the next flop within a clock cycle. The maximum clock speed you can run your design at is usually a factor of the length of the critical path.

Here is a list of tutorials available for free online:

• http://www.gmvhdl.com/VHDL.html
• http://instruct1.cit.cornell.edu/courses/ee475/tutorial/VHDLTut.htm#TOPP
  • Quick and dirty tutorial.  If you’ve used VHDL/Verilog in the past, real quick basic refresher.  It’s here on the list because it offers a ton of links to other tutorials at the bottom.
• http://teal.gmu.edu/courses/ECE545/viewgraphs_F04/loCarb_VHDL_small.pdf
  • The Low-Carb VHDL tutorial.  The name made me giggle.
• http://www.derepas.com/fabrice/hard/ 
  •  Great site if you have the Spartan 3 starter kit.

In a past life, I was an ASIC designer for Sun Microsystems.  That was about 8 years ago.  Since then, I’ve worked at a patent law firm and most recently at an embedded systems company mainly doing C/C++ coding.  But, I’ve finally made it back, boys.  I’ve finally made it back. 

I’ve been working for a bleeding-edge video test equipment company for about 2 years now working on implementing an HDMI HDCP compliance test.  Hard work?  Yes.  Long hours?  Yes.  Worth it?  (hesitantly…) Yes.  The code base is as loose as a sick dog’s business and stinks just as bad.  However, I’ve learned that I can get through immensely abstracted code and see the otherside.

And the upside? 

I’ve now moved on to (back to?) FPGA development.  FPGA’s are kind of like the little sisters of ASICs.  The upside with FPGA development is that you are responsible for design, implementation, verificaiton, timing, and synthesis.  In ASIC-land, there were people dedicated to each task of the project.  I had a verifier and our team had a Physical Design guy who was responsible for fitting the design into a chip and making timing.  I’m amazed at how much I still remember from my college days about VHDL syntax.  (I worked in Verilog at Sun.) After two long years of torturous code, I’m finally back to where I belong.

You might have read in previous posts that I am working on an article that explores how and why engineers diversify their training in other engineering disciplines. This appears to be a topic of discussion as I have been exposed more and more to the concept and importance of innovation (”India hitches its start ot embedded design model”, Wallace, Richard, Oct. 2, 2007 edition of EETimes, Issue 1498) and IEEE meeting on Outsourcing from Oct. 24, 2007 at IIT Rice campus. The link between these two concepts is that through diversification we can achieve innovation. Read the rest of this entry »

I just got back from the TI Technology day in sunny Schaumburg, IL which was held at the Stonegate conference center. Great event. TI really knows how to host a conference!

While I was disappointed with the number of third-party vendors that were onsite, I was greatly pleased with how TI chose to setup the exhibitor area. TI chose to set up booths in-between their third-party vendors. They had different products and applications. On big display was the TI MSP430 product line.

I’ve been to a few of the MSP430 days, and was even at the big launch at the Embedded Systems Conference 2007 in Boston. At that event, we walked away with an MSP430 development kit. Little USB form-factor design. At the TI Technology day, the new MSP430 development kit has an proprietary narrow-band RF transceiver as an add on to the USB kit. Neat. That kit retails for about $50 and comes with two devices. You’re supposed to be able to take the devices out of the box, download some code, power the devices up, and have a working demo. We’ll see how well it all turns out

The two seminars that I attended, Video Fundamentals I and II, were well planned. I believe that a bulk of the material came from the Video Fundamentals webcast that is on TI’s website here. (Look for the Video Fundamentals Hardware and Software links in the lower right hand corner.)  It was a great introduction to the common terminology in the audio/video industry.  I, myself, have been learning the lingo for the past year as I have been working for a very well-known audio & video test equipment company in the Chicago-land area.

One of the topics that I found most helpful was the crash-course in compression.  The TI field engineer did a great job of breaking down what can be an enormous amount of information.

I learned something new today. I learned that virtual functions in C++ remain virtual all the way up the hierarchy. Why did I need to know this? Because I am adding features to an existing code base that is expansive, complex, and obviously written by a mad scientist. Or genius. I’m still on the fence about that.

Being a consultant, I have to deal with many different coding styles, languages, and implementations. Another thing that I have to deal with is the level of readability of ones’ code. In this current situation, the code is hardly documented and utilizes a high amount of inheritance and abstraction. From the 10,000 foot view, it is breathtaking. From the 1 foot view, it’s quite daunting to understand. The inheritance tree for a menu item is something like 6 classes deep.  This would be great if the code was documented or if there was an architectural document, but there isn’t.  The result is that the consultant has to spend time (and the client’s money) figuring out what the code does.

My advice to anyone writing code is to document.  Even if it ends up being a few boxes and arrows on a napkin.  It’s a starting point.

Unfortunately, the Agile method, in my opinion and exposure, teaches away from documentation.  Instead, the Agile method prefers “real-time” communication to written documents.  This is a great method to follow for those quick-to-market high-pressure products that we all know and love.  My question is “How can this work for long-term products where engineers may come and go?” I don’t think it can.  Do you?

I’ve started an engineering women networking group in the area of the Chicago suburbs. We meet once a month from 6-8pm for dinner and great discussions. If you are interested in attending, please subscribe to the mailing list at: Networking Mailing list.