This email illustrates some common problems faced by programmers who start
doing logic design (hardware). I'd like to take this opportunity to try
to make sure you're all clear on certain important issues.
An analogy is sometimes helpfull between hardware design and coding
software, especially since we are now doing some hardware design with a
language (but a Hardware Description Language (HDL), not a programming
language). However, in most cases such an analogy is flawed, and often
is flat out wrong. It is important that you make a mental shift from
sequential programs to concurrent hardware.
>
>I was trying to set a 'gobal variable' to remember the inputs in my
>encryptor... by
>
>architecture Final_Permute_arch of Final_Permute is
>signal count :natural;
first, let me suggest
signal count: integer range 0 to 7;
instead. this will take only 3 bits (instead of 20+), and also, if count
== 7 and you say count <= count + 1, then count ==0 (it automatically
wraps around).
remember that a signal is not a variable - it is an internal buffer that
will store whatever value is assigned to it. also, the concept of scope
and global vs local variable does not translate well into hardware.
consider the wires in the chip. do they have scope, is there any part of
the circuit that could not be connected to the rest? all signals must be
declared at the top, before the "begin" of the architecture section, so
all signals are "global".
>
>and pass it to several processes....
you cannot pass signals. processes do not have parameters. you cannot
call a process, it happens automatically. furthermore keep in mind that
multiple processes can be in effect concurrently. also, all the
statements in a process (such as signal assignments) happen
simultaneously. for example, if you have:
process(rst)
begin
if rst'event and rst = '1' then
var1 <= '0';
var2 <= var1;
var1 <= '1';
end if
end process
then everything get the value 1, since later assignments override earlier
assignments (they are removed by the implementation) and var2 <= var1 <= '1'
you need to stop thinking at a software level and think in term of hardware: gates and
wires and chunks of logic.
processes have sensitivity lists. when an event occurs on one of the
signals in the sensitivity list, the process is re-evaluated. an event is
a change from 0 -> 1 or 1 -> 0 on any bit. so it is like the process
"listens" to the signals in it's sensitivity list for changes, and changes
it's output whenever an event is detected. in hardware terms, think of it
more like a section of combinational logic in a larger circuit, where the
input and output are buffered until a condition on certain wires occurs.
>
>when I check the syntax there is no error or warning occured, but when I
>create the macro SECOND time... the warning and errors shows up....
>I was trying to fix this for the whole day but still can't get it done.
odd that this would only show up the second time...
but let me explain the errors.
>
>is it the problem that I didn't initialize the 'count' at first time?? and
>when I create the macro, the old 'count' is sitting there still ???????
>
there is no such thing as initialization in hardware. in hardware, you
reset the circuit to put it in a known state. in all designs, there
should (often must) be a reset input that sets all values to some known
initial condition. as soon as the chip is programmed, before anything
eles, you should cycle the reset to get the design ready. incidentally,
this happens in pretty much all electronic devices. after the power comes
on, a reset signal is raised to initialize the device, and then the "boot
sequence" (whatever that is for the device) is performed.
notice that typical reset code will look like this:
process(rst, clk, sig2 ...)
begin
if rst'event and rst = '1' then
count <= 0;
state <= "0010";
rdy <= '0';
...
elsif clk'event and clk = '1' then
count <= count + 1;
...
end if
end process
>here is the error message :
>
>Warning: Latch inferred in design 'Final_Permute' read with
>
> 'hdlin_check_no_latch'. (HDL-307)
this is just a warning, nothing is wrong (most probably). this probably
caused because you have an if or case statement, and do not assign a value
to the same set of signals in all the parts (eg set sig1 in the if, set
sig2 in the else). what this is saying is that a latch (sequential logic,
like a flip-flop, if you've learned about those yet - they store one bit,
like ram) has been used in the design, but your code does not explicitly
call for one. (the latch is used to keep the value the same)
eg:
if sig = '1' then
blah <= '0';
tmp <= '1';
elsif tmp = '1' then
tmp <= '0';
-- blah was not assigned to here, so we need a latch to keep it's
-- value the same.
-- including blah <= blah will remove the warning, since the latch is
-- now explicit.
end if
> Error: The net '/Final_Permute/count<19>' has more than one
>driver. (FPGA-CHECK-5)
a driver is a signal that is assigned from
eg: in a <= b, b is the driver of a.
because the vhdl actually represents a hardware design, there are certain
restrictions that are placed on it. one of these restriction is that you
can only assign to a signal in one process (but you can read from it in as
many as you like, and it can occurr in as many process sensitivity lists
as you like). so, for example, if you had the above "if" statement in one
process, you could not make any assignments to blah or tmp anywhere else
(outside that process) in the entire file.
this error will occur for each bit of the signal with more than one
driver. (note - if you have a bit vector, and you assign to disjoint
parts in differnt processes, that should be OK, since each bit is tested
individually).
> Error: The net '/Final_Permute/count<12>' has more than one
>driver. (FPGA-CHECK-5)
> Error: The net '/Final_Permute/count<16>' has more than one
>driver. (FPGA-CHECK-5)
> Error: The net '/Final_Permute/count<18>' has more than one
>driver. (FPGA-CHECK-5)
>.
>.
>.
>
>Thank you.
>
"Oh, there it is...
...Then what the heck was that other piece of code we changed?"
This archive was generated by hypermail 2.1.3 : Wed Nov 21 2001 - 15:50:12 MST