How does VHDL handle bitwise operations

digital-logicvhdl

I'm having a problem in some VHDL code I'm writing. I want to drive a signal with two other signals AND'd together like this:

mysignal <= "010" and '1';

The result I expected was a bitwise AND, resulting in mysignal receiving the value of "010". Instead, I got a compiler error telling me "No feasible entries for infix operator "and"." When I try:

mysignal <= "010" and "111";

it compiles. Is it possible in VHDL to do a bitwise logical operation, without having to alter my signals and make them all the same width?

Best Answer

One way is to simplify generating signals of the right range. For example:

mysignal <= "010" and (mysignal'range => '1');

This creates a new value for the second operand, the correct size, with all bits set to '1',

Related Solutions

Electrical – How to handle overflow or underflow in VHDL

Get the arithmetic correct before moving to hardware. Either in higher level VHDL for simulation, or in Matlab/Ada/Python/etc before moving to VHDL.
At this level, detect and handle overflows EXPLICITLY, i.e. not using accidental characteristics of the arithmetic in your chosen language. Verify this explicit model against a full resolution model (e.g. using double precision floating point) to make sure it delivers identical results, or results with acceptably low (rounding) error.
Three reasons I like Ada for this are:
(a) it supports custom fixed point types as first class citizens
(b) it raises exceptions for range errors, overflows, etc so I have confidence that I'm catching problems early. (NOTE : the gcc Ada compiler needs some flags set to do this properly)
(c) commonality with VHDL makes translation between them a breeze.
FIX problems and verify that the answers are satisfactory. For example:
(a) verify that over/underflows come in pairs and cancel out to give correct answers in some types of symmetric filter
(b) widen intermediate data types to handle overflows, then round and truncate into the required output data type
(c) Detect out-of-range values and saturate them to the range limits (in Ada, you can do this in an exception handler)

Once you know the mathematics is correct in detail, translate to synthesisable VHDL and verify the synthesisable version gives bit-identical results.

Electronic – Can a VHDL concurrent assertion reference the LAST_EVENT attribute

Thank you for taking the effort to make a proper MCVE. My build of ghdl-0.34dev does the same, so there is clearly a ghdl bug here.

If the behaviour is legal, this should work, and if it's illegal, ghdl should exit cleanly with a description of the error.

Instead, ghdl isn't crashing, it has identified a shortcoming, a case where it "cannot handle LAST_EVENT attribute" (applied to another attribute) and shutdown with diagnostics.

I'll leave open the question whether a fine reading of the LRM determines its actual legality or not...

Putting anything at all beyond generics and ports in the entity as opposed to the architecture is rare ... I can't say I've ever seen it in production code - so you are out in the tall grass, though it's a valid thing to do.

In any case, moving this assertion into the architecture yields the same error, so that isn't the problem.

So, I've reporting it on ghdl's development site as https://github.com/tgingold/ghdl/issues/256 and I'll update my answer with any developments.

EDIT : A fix for this issue is now tested, and will be pushed to github following a full regression test.

HOWEVER : due to a subtlety in concurrent asserts, the two forms are not equivalent.

ghdl -r testcase_testbench
testcase.vhd:7:9:@30ns:(assertion error): Assertion violation

ghdl -r testcase_testbench
testcase2.vhd:4:5:@10ns:(assertion error): Assertion violation
testcase2.vhd:4:5:@25ns:(assertion error): Assertion violation
testcase2.vhd:4:5:@30ns:(assertion error): Assertion violation

In the first case, the process triggers on clk as requested. Delete the "wait" and put clk in the sensitivity list, and it does the same.

However, in Testcase2, the concurrent Assert is equivalent to a sensitivity list process, but the sensitivity list is clk'delayed.

As Tristan points out on the issue report (same link as above), clk'delayed is active in more than one delta cycle at 10ns, and so fails the test (because last'event is 0 ns between them!) Put clk'delayed in the sensitivity list for the Testcase process and see.

As "diogratia" points out there, a similar example in "The VHDL Designer's Guide" (Peter Ashenden) has a simple change to Testcase2 avoiding the issue : restrict the Assert to clk events...

entity testcase2 is
    port(clk: in bit);
begin
    check: assert (not clk'event) or clk'delayed'last_event >= 10 ns;
end entity testcase2;

architecture empty of testcase2 is
begin
end architecture empty;

EDIT 2 : As of commit b42069e this is fixed in ghdl-0.34dev. If your workaround using a process doesn't meet your needs, you can update to this version, but it means building ghdl from source.

Best Answer

Related Solutions

Electrical – How to handle overflow or underflow in VHDL

Electronic – Can a VHDL concurrent assertion reference the LAST_EVENT attribute

Related Topic