Egbert Molenkamp said:
I think this is the problem.
All statements IN a process are sequential statements.
process (clr_l, pr_l, clk) is -- I removed clr and pr
begin
pr <= not pr_l; clr <= not clr_l;
if (clr and pr) = '1' then q <= '0'; qn <= '0';
elsif clr = '1' then q <= '0'; qn <= '1';
elsif pr = 'q' then q <= '1; qn <= '0';
elsif rising_edge(clk) then q <= d; qn <= not d;
end if;
end process;
The process above will resume execution when one of the signals in the
sensitivity list is changed.
Suppose clr_l becomes '0'. Then when the SEQUENTIAL statement
clr <= not clr_l; is executed clr will become '1' in the next delay
(assuming no others assignements is made to clr).
So during the remaining execution clr is still '0'.
Then if all processes have suspended execution the simulation time is going
to the next delta and the signal clr becomes '1'. ALL processes sensitive
to signal CLR resume execution. So if clr is not in the sensitivity list
of a process that process is not executed (as you already noticed
during simulation).
OK, I see now. The key here is that clr is updated in the NEXT time slot,
hence the process will not run past one delta time period later unless the
clr is executed, because it cannot trigger the execution of the process until
it appears in the sensitivity list.
I guess in this case then the synthesizer would have to ignore the if
statement and its contents altogether, since the if can never run... (?)
"a wire is a wire" .. well may be you should look at VHDL from a
more programming view in stead of a hardware description. I don't think
the word synthesis (or something like that) is used in the LRM of VHDL.
You're right. Folk lore has it that VHDL is different from other programming
languages, and that you should think about what you write it in terms of
the underlying hardware. This is partly true, because if you want to
synthesize your model, then you want to organize the code in a way
that will make the synthesizer's job easier and so that it will
infer the right hardware elements in its macrocells. However,
what several books lack, is a description of the synthesis
process. Also, several books spend lots of lines on the
syntax on the language, but do not delve into software
engineering issues too much, relating to how to good
design practices. Also, they do not delve into common
mistakes and how constructs such as the one discussed
would differ from each other. Syntax alone is useless
if you don't know something about how the simulator
uses the syntax and how the synthesizer synthesizes
it. However, we should all remember that VHDL was
originally not meant for synthesis, and that is
why the LRM does not mention it. Nevertheless,
synthesis is the new horizon for VHDL and how
to synthesize and syntheisis algorithms is a
hot topic of research these days in hardware
systems such as FPGAs. The key issue is that
one must know how the simulator, and the
synthesizer, interpret VHDL, despite its
syntactical correctness. Most important,
I feel that books do not satisfactorily
describe the pitfalls of VHDL when
compared to other programming
languages constructs like C.
We are lucky that there are powerful synthesis tools available nowadays
that can handle a suset of VHDL very well. However in the beginning
these tooling were not very good.
Did they exist at all in the beginning???
Many tools nowadays still (and will be in the future, I guess for
portability
reasons?) have the problem that early synthesis tool did not really take
care of the sensitivity list.
I guess no synthesizer fully supports all VHDL syntax, even though they
all seem to parse all of VHDL correctly.
In fact if a signal is read it is assumed that that signal is in the list
(sometimes generating a warming if it is not there).
Well, there should be a warning! The problem though, is that VHDL compilation
time takes so, so, so, so, so long, that users become discouraged and sometimes
do not bother fixing warnings once the thing works. This is very bad, and I
very much regret the slowness of the synthesis process, given that C code
that mimics similar VHDL code can be compiled and debugged so quickly.
I wonder whether there's a way to speed the design process up.
Simulation seems not the answer, since you still need to write
testbenches for simulation, and it is hard to test manually.
For example a simulator will not show you LED outputs
directly as they would appear on a board, nor can it
take input directly from a PS/2 keyboard. THIS, is
the major drawback of the VHDL design process, and
this is precisely why coding in VHDL takes an
unnecessarily long time!
Best Regards,
Thanks!
Neil