03-12-2020 09:34 AM - edited 03-13-2020 03:33 AM
How is it to use the following statement instead of a clock triggered process .
x <= '1' when y = '1' else '0' when (rising_edge(CLK));
does it have any drawback ? or any benefit over process implementation.What are the trade offs.
Thanks and Best Regards,
Muhammad Hamza Muneer
03-13-2020 03:58 AM
03-12-2020 10:01 AM
I doubt that could be synthesized. What would you expect the hardware to look like, based on this code?
03-12-2020 10:29 AM
Current example is useless, as you're asking for '1' for the infinitely small time of the rising edge of the clock and '0' the rest of the time. I think you mean a register like this.
q <= d when rising_edge(clk);
This infers a process that looks like this
Process(clk) Begin If rising_edge(clk) then Q<= d; End if; End process;
Which is a normal process for a sync register. It should be perfectly sunthesisable. What you cannot do is infer a sync reset, but and async reset is possible.
Q <= '0' when reset else d when rising_edge(clk);
03-12-2020 11:56 AM
03-12-2020 04:03 PM
Nope, this style has existed since '87 afaik (using clk'event and clk = '1' as rising_edge was a '93 addition). Whether tools have supported it is another question, but Im pretty sure it has worked for quite some time for some (if not all) tools.
03-13-2020 03:36 AM
Thank you for your reply, this is synthesizeable and is working fine on vivado 2018.3. I just wanted to know how the synthesizer understands it
03-13-2020 03:38 AM
03-13-2020 03:58 AM
03-13-2020 05:58 AM
03-13-2020 06:39 AM - edited 03-13-2020 06:41 AM
The process form allows more flexability, as you could include syncronous resets and enables. In the shorthand, you could write:
q <= d when (rising_edge(clk) and en = '1');
But you may be open to some clock gating (Though I think in FPGAs the tools are clever enough not to).
With 2008, you can use aggregates on the LHS, so you can be even more concise:
(op0, op1, op2, op3) <= (ip0, ip1, ip2, ip3) when rising_edge(clk);
I think this is mostly a quesiton of style. What used to always work sticks, and people generally dont change (and text books never get updated or replaced)
03-13-2020 10:07 AM
03-13-2020 04:51 PM - edited 03-13-2020 04:56 PM
A inline assignment is only sensitive to the signals on the RHS of the assignment, so my previous exmaple would have a sensitivity list of clk, ip1, ip2, ip3, ip4.
Simulators are very optimised now, so sensitivity lists are pretty imaterial. remember VHDL2008 added process(all) so a process is sensitive (technically) to all signals available. In reality the compiler will just work out what its senstive to from the contents during compilation.
A process without a sensitivity list must have a wait statement in it, otherwise its an illegal process.
03-14-2020 02:03 AM
03-14-2020 04:25 AM
@drjohnsmiththat and the fact that adding all the required signals to an async process is tedious and error prone. Verilog has had always @* for a very long time, and it hasn't slowed their stimulation down.
03-14-2020 06:11 AM
03-14-2020 11:45 PM - edited 03-14-2020 11:46 PM
But sensitivity lists are nothing to do with VHDL typing and nothing like double entry book-keeping. They are a user instruction to the compiler that "this process should only be evaluated when these signals change". Its all too easy and possible to leave a signal out and cause a simulation synthesis missmatch because you forgot one, and its not always obvious whats missing. Even more dangerous, it is possible in some cases that different logic can be formed from a traditionally bad sensitivity list.
eg. Quartus will synth this as a register:
process(clk) begin if clk = '1' then q <= d; end if; end process;
whereas this becomes a latch:
process(clk, d) begin if clk = '1' then q <= d; end if; end process;
The only difference here is the sensitivity lists. Quartus is technically correct making a reg with this, as q is only updated when clk changes to a '1' from something else. But this flies against accepted norms of VHDL templates.
Back to the process(all), here, you're telling the compiler to do the work for you. Its not taking anything away from VHDL linting strengths, because it was never a check on anything. Only an instruction. Verilog has had always @(*) for 20+ years, and its use is highly encouraged.
03-15-2020 07:03 AM
03-15-2020 07:54 AM - edited 03-15-2020 07:55 AM
There is no such thing as an "incorrect" sensitivity list. Synthesis tools will give warnings (and only a warning) that a sensitivity list is incomplete because it interprets processes in a different way and ignores the lists (and generates it's own list from the contents of the process). A simulator will NEVER give a warning or an error for an incomplete sensitivity list, as missing signals are not an error. The simulator has no way of knowing what's "missing" or not.