Module Minimization

Use of "ELSE" Statements

Much of your code will make use of many "IF", "ELSIF" and "ELSE" statements. Avoid "ELSE" statements unless they are really necessary (state machine variables, etc). Leaving an "ELSE" when an "ELSIF" could be used will bloat your code, from our experience, it will roughly double it. The following example should clarify this point:

IF done_waiting ='1' THEN

do something important

ELSE

do something else

END IF;

A better way to write the above code is

IF done_waiting ='1' THEN

do something important

ELSIF done_waiting = '0' THEN

do something else

END IF;

This code is funtionally equivalent and reduces the number of modules. Make sure you only leave ELSE statements if it is the only way to do it.

One final note: Our module count was reduced from ~1200 to 540 using this. This reduction lowered our count with no comprimize in functionality or features.

Editing Pinouts

Editing the pinouts in Designer is a great way of not only making your design easier to phisically construct, but it also increases you modules by up to 10%. Designer goes through a lot of effort to optimize the layout of the chip in the layout stage and can minimize the number of modules used if no constraints are put on it as to where the actual pins are located. For a minimal design, let Designer decide where to map your pins to, it can do a better job than you can.

Frequently Asked Questions

Q:

I've mapped my VHDL to the chip and my back annotated simulation doesn't work. What's going on.

A:

how are you vectors assigned? VHDL supports the use of two vector types: "to" and "downto". The best one to use, theoretically is the "downto" vector type. This will map your variables with the most Significant Bit (MSB) first, as the higher order bit, the down to the Least Significant Bit (LSB) (ie, "7 downto 0", the 7th bit is the MSB, 0 is the LSB.) As in many aspects of life, however, theory and reality do not intersect. While it is possible to use the downto vector assignment, a few words of caution will hopefully steer you away from this decision.

The initial VHDL Quick Sim will operate as expected, forcing the vectors is as simple as type "force vect "00001111", where "0" is the MSB and "1" is the LSB. After testing your back annotated simulation, however, you will notice that the same command reverses the order of the bits. I have no reasonable explanation fro this anomolie, only a few educated guesses. The best way of avoiding this problem is to use "to" vectors instead. You can then use the same forcing functions to implement you design in VHDL and back annotated simulation. This is not the best solution, nor is it technically correct. This was the only working solution that we discovered. This is an engineering project, not math or philosophy. If it works, do it. When two other groups in the lab were having similar problems, this was the fix that they eventually resorted to on our persistance (and contrary to authoritative advice) and got their simulations working. Such difficulties were common, so heed this advice and ONLY us "to" vectors.

Q:

I've minimized the number of modules as much as I can and it still won't fit. What can I do?

A:

Get rid of some functionality. Decide what you really need and what you don't. Our design used and LCD for displaying the charger's status which was probably overkill; status could have been just as effectively communicated to the user user using LEDs. Put some thought into what is necessary and what is not. As a last resort, try going to the Xilinx system. Be aware, however, that this complete prototyping system has no available back annotated simulation (at the time this was written, Dec '97). Simulating a fuse file is critical in the design of the Actel chips, and while you can write to the Xilinx board multiple times, this is a time consuming process. Only one of the 4 groups using the Xilinx boards had their systems working for their presentation this term. I will not go into the pros and cons of each platform (both have their merrits and pitfalls) but be forewarned about this specific deficiency.

Q:

My simulation works fine, but in back annotation, a bunch of my variables are "unknown " in back annotated simulation.

A:

This problem baffled us for some time. The problem was solved by adding a hardware reset to our code. This reset was intended to be active during startup or whenever problem occured. The following code will work in simulation and will NOT work in back annotated simulation

IF bob = '1' THEN

next_bob <='0';

ELSIF bob = '0' THEN

next_bob <='1';

ELSE

next_bob <='1';

END IF;

END PROCESS;

.....

BEGIN

WHEN CLOCK

bob<=next_bob;

end process;

The final "ELSE" is not a functional way to initialize the variable next_bob. When you think about it this makes perfect sense: what exactly would bob be other than a '1' or a '0'. By adding a power on reset, you can specify what next_bob will be at start up. The above code can be easily reset as follows:

IF reset = '1' THEN

next_bob<= '0';

ELSIF reset = '0' THEN

IF bob = '1' THEN

next_bob <='0';

ELSIF bob = '0' THEN

next_bob <='1';

ELSE

next_bob <='1';

END IF;

END IF;

END PROCESS;

.....

BEGIN

IF reset = '1' THEN

bob<= '0';

ELSIF reset = '0' THEN

WHEN CLOCK edge

bob<=next_bob;

END IF;

end process;

Adding this type of reset to each process will take care of most of your initialization problems. To implement this reset in hardware, you can either a) add a switch or b) use an RC charging circuit. The RC circuit can be easily implemented by placing a resistor and a capacitor in series from power to ground and taking the reset off the middle of these two. The R and C values are determined by your clock speed when in doubt, make this longer (does it really matter if your circuit powers up in 5mSec or in 500mSec. For our 1kHz clock speed, the values of R and C were 330 Ohms and 1micro Farad. Start with a switch to do your initial testing the go to an RC timer.

Q:

My VHDL compiles in Actmap just fine, but when I go to layout the circuit, it gets to 88% then actmap exits less than gracefully.

A:

This problem has cropped up for a number of groups during the course of this term. In our specific case (and this has not worked for all groups) we removed all of our manipulation of variable from the top level entity. If this doesn't work, try renaming the file, or moving it to another directory.

Q:

Where do I get a slow cyrstal for my clock?

A:

Idunno. We used a 555 timer for our circuit. There are plenty of places to find information on using 555 timers on the net or go buy a book called "555 Timer Circuit" from Radio Shack (it costs about 3 bucks).

Q:

My back annotated fuse file isn't simulating properly and Quick Sim gives me a bunch of timing errors. What's going on?

A:

The fuse file is the closest you will get to a complete simulation of your design. Many of the timing and fanout specifications not implemented in the .edn or .vhd files are accounted for here. Running into problems this late in the game can be very frustrating, but they can be overcome. Start by looking at all of your internal variable waveforms. Are there any glitches? What effect, if any, will these have on your circuit? The next step is to try lowering you fan out. LOWERING the fan out will force the layout tools to bring individual modules closer together. This causes the delays to be shortened, which was the solution in our case.

Q:

What is the best way of throwing a Sun Ultra 1 out of the window?

A:

Please don't. As frustrating as designing an FPGA can be, its not worth getting kicked out of school for. When you run into problems consult you collegues. The lab should be occupied with students working with the same tools until 3am (or 4 or 5 or...) every day. Work together, EE552 is not a course that can be tackled alone. I am more than willing to give anyone a hand. Feel free to contact me if at:

dmcmilla@gpu.srv.ualberta.ca or

dmcmilla@afternet.com