jacko said:
Take nibz12.vhd from
http://nibz.googlecode.com and eliminate the
enumeration state indqq. This is to prevent post increment on register
assign.
It does more than just that from a logic perspective. Just a simple perusal
by searching for 'indqq' shows that deleting the 'indqq' enumeration would
change the following:
- Logic for signals 'p', 'q', 'r' and 's' would be different. As written,
there would be instances (i.e. when 'indirect = indqq') where p,q,r,s would
not be updated; by deleting the 'indqq' enumeration one of these four would
always be doing something. Refer to lines 122-134 of nibz12.vhd, the
snippet of the code is at the end of this post as "Nibz12.vhd example #1".
There are other instances of this as well.
- Logic for signal 'pre' would be different. Refer to lines 223-234 of
nibz12.vhd or "Nibz12.vhd example #2" at then end of this post. Without
'indqq' as an enumeration, the statement "pre <= q;" that occurs when in the
case when 'indirect = indqq' would need some modifications.
- Logic for the signal 'ir' would be different. refer to case statement
starting at line 273 (or "Nibz12.vhd example #3" at the end of this post)
and in particular, the assignment "ind <= indqq;" on line 282 which would
produce a compile error if you deleted the 'indqq' enumeration.
I have no idea why you would toss this out as an example of the particular
sub-topic of demonstrating what you claim to be differences when there are
multiple assignments to a signal within a single process...but at this point
I don't really much care.
Obviously you didn't even take the time to see that simply deleting the
'indqq' enumeration...
- Would produce code that wouldn't compile
- Would change the logical function being implemented.
- Is not an example to support your claim that multiple assignments to a
signal within a process produces different synthesis results in terms of
either resource usage or performance.
I'm guessing that your claims are more based on the arrogrance of ignorance
than anything else.
According to you the fact that post-increment code occurs
before register assignment code, register assignment should overide,
and the state indqq would not be required.
No I didn't say that at all. What I said was that from the perspective of
- Logic function
- Synthesis resources
- Synthesized performance
the following two forms are exactly identical. Perhaps you should take some
more time reading and understanding what is being presented instead of going
off on various tangents stating things that you don't really know about.
Unfortunately, a person who doesn't know what they don't know is in a far
worse situation than someone who at least knows what they don't know.
-- #1
process(clk)
begin
if rising_edge(clk) then
if (reset = '1') then
-- do some sync resets
else
-- do something else
end if;
end if;
end process;
-- #2
process(clk)
begin
if rising_edge(clk) then
-- do something else
if (reset = '1') then
-- do some sync resets
end if;
end if;
end process;
I have tried it, it makes it larger and slower! A real example of
using or avoiding 'double' assignment.
It's a real example of something, but it is not an example of how avoiding a
'double' assignment changes anything. It may be an example of pipelining,
I'm not interested enough to find out. In order to show your point, you
would have to produce two designs that are
- Logically exactly equivalent (every signal has the same value in both
designs at every clock cycle).
- The only source code difference is that at least one signal has a 'double'
assignment in the one design but not the other.
- Demonstrates different resource usage or clock cycle performance
cheers
jacko
p.s. wouldn't consider doing a pointless simple test as reduction of
logic form just too obvoius to any silicon compilier.
But not so obvious to you for some reason.
The "pointless simple test" as you call it has nothing to do with scale,
those two templates would produce the exact same results whether the process
in question was one of a handful of lines (as was presented) or 10,000 lines
with multiple loops, case, if statements and whatever. You seem to feel
otherwise, even in spite of
- The comments of multiple people who know what they are talking about.
- The presentation of a complete design (not just a snippet of the relevant
code) that was provided that in the previous post that you could use to
prove it to yourself by simply copying it and trying it out.
In any case, I took the time to review what you suggested and pointed out
the flaws in your argument. The reason for your resource usage and clock
cycle differences have nothing to do with double assignment in the source
code it has completely to do with changing the logical function itself which
generally does produce changes in both of these metrics. A simple example
of this is pipelining where you break up a computationally 'expensive' logic
function into smaller ones that span several clock cycles. While at some
higher level of abstraction the two designs can be thought of as being
equivalent, the fact remains that the one with pipelining has more latency,
it will produce results at a different (later) time, the logic function
being implemented is different. That is not news, that is well known.
As a final point, since you pointed me to your code, here are some other
suggestions:
* You don't know how to name signals and constants in a meaningful way to
indicate what they logically represent. Some examples are...
signal p, q, r, s, c, x0, a0, x1, a1, car, ctmp
constant z, z4
* You don't understand what signals belong in the sensitivity list of a
synchronous process. Example:
process (CLK_I, RST_I, ACK_I) -- KJ: ACK_I is not needed.
* You don't understand what signals elong in the sensitivity list of a
combinatorial process. Example:
process(ir)
But this process (starting at line 206 of nibz12.vhd) depends on the
following signals as well: 'cycle', 'indirect', 'dir', etc. This will
synthesize to something that is functionally different than simulation.
That is a huge blunder, debugging in the simulator is way more productive
than on the bench...once you have sufficient skill that is.
* You probably don't simulate your source code.
Good luck on your learning experience, I'm done with this one.
Kevin Jennings
---- Nibz12.vhd example #1
case indirect is
--pre decrement??
when indp =>
p <= ADR_O;
when indq =>
q <= ADR_O;
when indr =>
r <= ADR_O;
when inds =>
s <= ADR_O;
when indqq =>
end case;
---- Nibz12.vhd example #2
case indirect is
when indp =>
pre <= p;
when indq =>
pre <= q;
when indr =>
pre <= r;
when inds =>
pre <= s;
when indqq =>
pre <= q;
end case;
---- Nibz12.vhd example #3
case ir(3 DOWNTO 0) is
when "0000" =>
-- BAck
ind <= indr;
wrt <= rd;
dir <= dirp;
post <= din;
when "0001" =>
-- Fetch In
ind <= indqq;
wrt <= rd;
dir <= dirq;
post <= din;
....
