## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• Feb 03 2022 02:13

umarcor on keep-compiling

ci: use the built-in '--keep-co… (compare)

• Feb 03 2022 02:12

umarcor on cosim

• Feb 03 2022 01:56

umarcor on cosim

WIP setenv (compare)

• Feb 03 2022 01:55

umarcor on main

cosim/dpi-ffi/ghdl-vffi/test: a… (compare)

• Feb 03 2022 01:54

umarcor on cosim

• Feb 03 2022 01:52

umarcor on main

WIP envvars (compare)

• Feb 03 2022 01:50

umarcor on cosim

WIP envvars (compare)

• Feb 02 2022 23:13

umarcor on master

• Feb 02 2022 23:13

umarcor on main

• Feb 02 2022 23:13

umarcor on cosim

• Feb 02 2022 23:10

umarcor on master

cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

• Feb 02 2022 22:58

umarcor on cosim

• Feb 02 2022 22:45

umarcor on cosim

• Feb 02 2022 22:43

umarcor on cosim

cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

• Oct 05 2021 13:29

umarcor on top-subtype

• Oct 05 2021 13:28

umarcor on master

• Sep 24 2021 20:07

umarcor on top-subtype

• Sep 24 2021 19:59

umarcor on top-subtype

• Sep 24 2021 19:54

umarcor on top-subtype

• Sep 23 2021 01:45

umarcor on style

sckoarn
@sckoarn
An all expense payed trip to Gnowere.
Jim Lewis
@JimLewis
@Farmadupe it looks like it has some conversations from comp.lang.vhdl. which would correlatate with low bandwidth
this might be beating a dead horse a bit, but i was just made aware of these old VHDL-93 tests: https://github.com/nickg/vests/tree/master/vhdl-93/billowitch ... and i know there isn't something like this for VHDL-2008 and definitely nothing like this for VHDL-2019 .. what do you think it would take to describe tests for just the new stuff such that it could be used for some type of rudimentary testing? not comprehensive, but at least basic ?
@umarcor i was reminded of this repository - https://github.com/VHDL/Compliance-Tests .. i saw the LCS2019.yml file here - https://github.com/VHDL/Compliance-Tests/blob/main/issues/LCS2019.yml .. is there something similar that can be taken from the twiki archive that @JimLewis has that could be used for vhdl-2008 as well?
@JimLewis do you have any contacts over at aldec that you could ask who may want to share how they do regression/compliance testing for their vhdl stuff?
hmm out of interest, does anyone know where the 'v' in modelsim came from? Sorta guessing it's just 'v' for verilog/vhdl
i think it's vhdl based since they use vcom for vhdl, and vlog for verilog
but sure, probably that
sckoarn
@sckoarn
Is there a place to talk about cross-language interfaces VHDL <-> Verilog?
there was an open vhdl wg ticket i thought .. let me see if i can find it
sckoarn
@sckoarn
I would be more than happy to work on a standard for this
oh, sorry - this was regarding VHPI/DPI/FFI .. unsure if this counts as that, or you meant something higher level - https://umarcor.github.io/ghdl-cosim/vhdl202x/index.html and IEEE-P1076/VHDL-Issues#10 i think try to capture the former
sckoarn
@sckoarn
That is DPI.
then i haven't found anything specific regarding SV cosimulation or anything ..
sckoarn
@sckoarn
It is kind of known that there is no standard.
though i did have an idea over the weekend to use VHPI/DPI and use open source simulators to cosimulate
as a proof of concept
sckoarn
@sckoarn
I think this is a big problem for the industry as each vendor has their own rules.
i can agree with that
sckoarn
@sckoarn
This is my current issue. This vhdl ID \DuT#%\ , how would you expect to use this ID in Verilog?
Well it seems that \DuT#% is the Verilog derivative ... so my VHDL lib has one name and Verilog has another? How can they ever match?
going further \Dut wSpace\ ID with a space in it. Verilog will terminate at the space?
So the rule I would make is that "extended" identifiers may not be used in cross language interfaces. End of story.
and what about cross language keywords ?
sckoarn
@sckoarn
For me, the interface is physical as in Pins. not functions and all that stuff. Keep it simple.
As in using the name in an interface which is a keyword in the other language?
yes
sckoarn
@sckoarn
Well that is silly :)
like int
sckoarn
@sckoarn
Hmm I would like to test that one. Thanks.
i am just saying that it needs to be explicitly stated what's allowed and not .. or else these questions come up, and then you get back to implementation dependent
sckoarn
@sckoarn
It is hard to get any info on this topic
Though it is a problem there is no group trying to fix it, is there?
unsure about who is trying to fix it in all honesty .. also unsure where it belongs - the SV language spec, the VHDL language spec, a collaboration specification that is completely different ?
sckoarn
@sckoarn
If a spec existed at least there would be something to argue over :)
SV will never do it.
i wonder if my idea still holds .. if there is a way we can utilize VHPI/DPI to perform the cross language talking ..
sckoarn
@sckoarn
Yes, it can be done.
so why not utilize that as the "standard" way to do it - with automatic code generators ?
sckoarn
@sckoarn
Will I have to do anything more than instance my item into the other language? Like what kind of over head will DPI introduce?
xilinx has a systemverilog zynq vip thing that i utilize for testing some designs .. it does axi transactions, can perform interrupts, write to "ddr memory", etc ..
sckoarn
@sckoarn
I have not used it.
in an ideal world it would all be figured out - but we're far from that utopia
sckoarn
@sckoarn
I see DPI for more complicated interfacing, rather than pin to pin connections.
FWIW, Verilog also has extended identifiers, starting with a backslash and ending with a space, so \int should work.