Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
First time I've seen it.I learned from books that I should exhaust all branches of "if"
statement, so I write in the following way:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if (INPUTEND = '1') then
...
else
null;
end if;
else
null;
end if;
But I also saw on the Internet sometimes people don't write code in my
cubersome way...
Can anybody clarify a little for me? When I need to write this "else
null", and when I don't need it?
Dear all,
I feel confused by "else null" statement:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if(INPUTEND = '1') then
...
end if;
end if;
I learned from books that I should exhaust all branches of "if"
statement, so I write in the following way:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if (INPUTEND = '1') then
...
else
null;
end if;
else
null;
end if;
But I also saw on the Internet sometimes people don't write code in my
cubersome way...
Can anybody clarify a little for me? When I need to write this "else
null", and when I don't need it?
Thanks a lot,
-Walala
Dear Kelvin,
Thank you for your answer...
But it is unclear that which style is better...Can you tell me? (A) or
(B)?
By the way, I really don't have anything to do in "else" block, so I put
"null"... will that still infer a latch?
"u had better put something in the else{}, otherwise you get a
latch..."
(A)
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if(INPUTEND = '1') then
...
end if;
end if;
(B)
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if (INPUTEND = '1') then
...
else
null;
end if;
else
null;
end if;
walala wrote:
Dear all,
I feel confused by "else null" statement:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if(INPUTEND = '1') then
...
end if;
end if;
*Registers:*
In the above example the if-statement is in a *clock-section*.
For example:
if(INPUTEND = '1') then
output <= inputsignal1;
end if;
The synthesisis-tool generates a register for the signal called output.
The clock input of the register is connected to the clock, and the
enable signal of the register is generated by a block of logic. Here it
is obviously, that there don't needs to be logic.
Attention: It doesn't matter if here is a else-branch. In any case a
register will be generated.
*Latches:*
Latches are elements, that are triggered by a signal.
If you write the following out of a clock section then the
synthesis-tool generates logic.
if(INPUTEND = '1') then
output <= inputsignal;
else
output <= inputsignal;
end if;
But if you write only:
if(INPUTEND = '1') then
output <= inputsignal;
end if;
the synthesis tool has to generate a latch because it can't generate
logic because it can't generate a boolean equation for the logic. So it
has to generate a latch.
Some architectures don't have latches, so they shouldn't used.
*Avoidance of Latches:*
To avoid (unwanted) latches you either have to desribe what will happen
with each signal in each branch (like in the logic-example) or do the
following.
If you are only interested what happens if INPUTEND='1' and the other
cases don't care, you can set a default value for the signal output.
Then in all cases where you haven't specified, what should be happen
with the ouput-signal the standard value is used by the synthesis-tool
and logic is genereated. So you can save code and avoid the generation
of latches.
A little example (out of a clock section again):
output <= (others=>'0');
if(INPUTEND = '1') then
output <= inputsignal;
end if;
It gets only the value of inputsignal, when INPUTEND='1', in all other
not explicit specified cases it gets the value zero.
I hope this helps you understand the problem.
I can't say anything about the sense of null-statements in the
else-branches, because I never used it there.
Regards,
Ingmar Seifert
Thanks ;-).Dear Ingmar,
Thank you very much for your complete and informative explanation for
such a newbie as me. I recommend this article to be assembled into
VHDL FAQ... :=)
I'm sure you have this from a book. No, you don't need to put somethingI now understand that in a clocked section, the "else" branch can be
safely ignored since it will be a register anyway... I also understand
that special care should be taken when the "if" statement is outside
the clocked section...
I want to further ask:
p0: PROCESS(rst, clk)
BEGIN
if rst = '1' then
for I in 0 to 7 loop
for J in 0 to 7 loop
XX(I)(J)<=0;
end loop;
end loop;
elsif (clk'event and clk = '1') then
XX(POSY)(POSX)<=CONV_INTEGER(X);
else
...
end if;
END PROCESS p0;
I the above code, since the "else" part is outside the clocked
section, but parallel to the asynchonous reset section, do I need to
put something inside the "else" branch? Or, can I safely ignore the
"else" branch?
Could you please use your real name for further posts.-Walala
Dear all,
I feel confused by "else null" statement:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if(INPUTEND = '1') then
...
end if;
end if;
I learned from books that I should exhaust all branches of "if"
statement, so I write in the following way:
if rst = '1' then
count <= 0;
elsif clk'event and clk = '1' then
if (INPUTEND = '1') then
...
else
null;
end if;
else
null;
end if;
But I also saw on the Internet sometimes people don't write code in my
cubersome way...
Can anybody clarify a little for me? When I need to write this "else
null", and when I don't need it?
Thanks a lot,
-Walala
You can replace the loop with:
if rst = '1' then
XX <= (others => (others => 0) ) ;
Cheers,
Jim Lewis
--
is really coming into real play for verification.Being primarily a hardware designer, timing diagrams are a common form of
thinking/explaining for me. I used this in my last job to do verification of
some IP we were developing for a customer and it was the best verification
environment I have used.
Thin PSL Property Specification Language as Assertion-Based Verification (ABV)
Synth tools generally dislike "else" statements after "if" statements thatp0: PROCESS(rst, clk)
BEGIN
if rst = '1' then
for I in 0 to 7 loop
for J in 0 to 7 loop
XX(I)(J)<=0;
end loop;
end loop;
elsif (clk'event and clk = '1') then
XX(POSY)(POSX)<=CONV_INTEGER(X);
else
...
end if;
END PROCESS p0;
I agree, the power of directed testing is you can take your inate knowledgeRethorical question: how are you going to do directed test to check
that, say, a CPU interface fpga works correctly in a specific
sequence, which includes a DRAM refresh cycle? Hardware is fine for
statistical and random testing, but when it comes to directed testing,
testbenches win hands down. Don't get me wrong: I'm advocating the
use of BOTH directed *and* random testing here.
I agree, the great thing about simulation is it gives you visibility intoroot-cause. In this case, using a simulation to probe the internal
state at various points of the arbiter was essential to pinpoint why
the mechanisms that we had put in didn't kick in as expected.
Yeah the more tools you have to attack a problem, the better. Each has it'sI did run some 10 test runs in the lab to assess which parameters did
or did not affect the problem. Then, it was off to (more)
simulations, and from the synthesis of those two things a fundamental
understanding of the problem arose.
http://groups.google.com/groups?q=vhdl+logically+serial+flag+stuffCan bit-stuffing be done on a parallel incoming data? Is there any
flow/algorithm to implement it.
Assertion-Based Verification is gaining popularity for the documentation ofI need design my coverage methodology where I can identify certain events
and then get the coverage of no only when those events trigger, but also all
the combination of which they occurred.
Example: I have the following events: A, B and C
I need the coverage tool to report whether or not the following occurred: A,
B, C, AB, AC, BC and ABC.
Does anyone know a good tool that helps me out with this effort?
There are no guarantees with synthesis timing estimatesI am trying to figure out how zero timing violations in synthesis and
STA is sufficient to *guarantee* that there will not be any timing
violations during PAR.
Why not define these as "unsigned(31 downto 0)"? You're representing
real numbers after all, not just large collections of bits (which is
all a std_logic_vector implies).