Open Blebowski opened 1 week ago
@nickg I can try to have a look at some of the PSL issues, but I need to know what to deal with so that we will not have conflicts, or work on the same stuff...
I think VHDL std_logic_vector
also "maps" on PSL bitvector
, so it should be legal. AFAIR I had this discussion with Tristan already during testing or implementing PSL stuff in GHDL. I try to find the exact wording in the PSL LRM.
I maybe was not precise:
BitVector
definitely maps to std_logic_vector
.BitVector
does not map to std_logic
and IMHO should return the same error as onehot
when called with argument of std_logic
type.PSL standard (IEEE 1850-2010):
5.1.2:
In VHDL, type STD.Standard.Bit, and type IEEE.Std_Logic_1164.std_ulogic, as well as subtypes thereof, are Bit types.
5.1.3:
In VHDL and GDL, any type that is a one-dimensional array of a Bit type is interpretable as a BitVector type.
I maybe was not precise:
* PSL `BitVector` definitely maps to `std_logic_vector`. * PSL `BitVector` does not map to `std_logic` and IMHO should return the same error as `onehot` when called with argument of `std_logic` type.
Ah, okay. So you mean is_unknown()
should not work on Bit
and std_logic
.
Yes, that is it.
Some of the PSL built-in functions crash. E.g.
rose
andfell
crash:crashes with:
Almost equal crash occurs with
rose
.When I try
isunknown
but pass only argument ofstd_logic
type, I get slightly different crash:with the crash:
with argument of
std_logic_vector
, theisunknown
seems to work correctly. I think parser should reject this at analysis time, sinceisunknown
is defined only forBitCector
type in PSL LRM. NVC behaves that-way foronehot
function, e.g.:and returns correct error:
TO reproduce is the same repo as other issues with:
9024a2cdc3d134904ae784781d8a62278b8baf6d
make psl_fell