Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 23:54
  • Jul 31 2020 15:41
    JimLewis commented #27
  • Jul 31 2020 15:40
    JimLewis commented #27
  • Jul 31 2020 15:39
    JimLewis commented #27
  • Jul 19 2020 00:47
    JimLewis commented #10
  • Jul 19 2020 00:46
    JimLewis commented #10
  • Jul 18 2020 22:06
    NJDFan commented #13
  • Jul 18 2020 21:59
    Paebbels commented #13
  • Jul 14 2020 16:08
    LarsAsplund commented #13
  • Jul 13 2020 18:21
    LarsAsplund commented #10
  • Jul 13 2020 16:15
    GlenNicholls commented #27
  • Jul 13 2020 13:00
    JimLewis commented #10
  • Jul 13 2020 12:54
    JimLewis commented #10
  • Jul 12 2020 22:15
    NJDFan commented #27
  • Jul 12 2020 22:01
    JimLewis commented #27
  • Jul 11 2020 20:54
    Paebbels commented #27
  • Jul 11 2020 20:46
    Paebbels commented #10
  • Jul 11 2020 16:08
    JimLewis commented #27
  • Jul 09 2020 15:56
    JimLewis commented #27
  • Jul 09 2020 15:56
    JimLewis commented #27
Lars Asplund
@LarsAsplund
Ok, let's get this forum going. The other day when I tried interfaces with the new Riviera PRO 2020.4 release I failed assigning default values to an entity interface port in the same way we assign values to a normal port. My bad, Aldec's bad or a limitation in the LRM? Anyone tried?
Patrick Lehmann
@Paebbels
I haven't tried assigning values. I suspect the problem is in the LRM.
For now I just tested compiling the packages itself.
Should we add tests with entities to the Interfaces repository or to Compliance-Tests?
Patrick Lehmann
@Paebbels
I made an initial list of interfaces we could collect and provide: VHDL/Interfaces#6
Maybe this list is to long for a v1.0 :)
Patrick Lehmann
@Paebbels
OK, I found a missing VHDL-2019 feature in Riviera-PRO: VHDL/Interfaces#8
Lars Asplund
@LarsAsplund
We should setup tests in the interface repo to verify all the interfaces it provides. The compliance test repo should have tests to verify if interfaces are supported so the purpose is different.
Lars Asplund
@LarsAsplund
Now that we have a VUnit action in Githus's marketplace it will be easy to setup the CI. Problem is that GHDL doesn't support interfaces yet. I've just started a discussion with Aldec to see if we can enable a Github CI running their simulators so hopefully that can be solved shortly.
eine
@eine

We should setup tests in the interface repo to verify all the interfaces it provides. The compliance test repo should have tests to verify if interfaces are supported so the purpose is different.

Agree. The tests from the interfaces can be a subset of the Compliance tests, tho. We can just pull them in CI.

Patrick Lehmann
@Paebbels
How would we test interfaces?
For sure: the package to compile the definitions (records, views, aliases, generic packages)
Is a harness (entity + architecture) plus 2 components enough?
Or are you aiming to toggle all bits in the interface?
I think for this we would need models like from VUnit or OSVVM to drive them plus matching IP cores on the other side. I would defer this to a repo implementing infrastructure IP cores.
Lars Asplund
@LarsAsplund
@Paebbels As a bare minimum the CI should make sure that everything compiles, just like you've done. We should probably have some sorts of test alsos. Haven't thought about what they should be like. The interfaces are basically bunch of wires with no specified behavior unless we also provide protocol checkers and that is probably too ambitious for now. We should definitively not build our tests on VUnit or OSVVM IPs. Those IPs should depend on this repo, not the other way around. Using VUnit and OSVVM "basic functionality" in any tests we write is another thing and something I don't have any issues with
Patrick Lehmann
@Paebbels
hi
I made an issue #9 for the thoughts on testing.
In a long meeting I discussed improvements to the naming of interfaces with @JimLewis. This is in #10. I'll update soon.
Meanwhile I created a basic skeleton for the documentation and pushed it to RTD: https://vhdl-interfaces.readthedocs.io/en/documentation/#
eine
@eine
I think that the kind of issues that would be found by testing the interfaces with actual IPs, don't need to be tightly coupled. The repo provides definitions which should be valid VHDL, and that's what we need to test only. The usability of them (how they are used by VUnit, OSVVM, or any other project with IPs) is a different issue, that should be handled as "regular feedback" through issues/PRs.
Patrick Lehmann
@Paebbels
I wrote down another discussion issue for unresolved vs. resolved. See #13
Patrick Lehmann
@Paebbels
So now we have some first parts for AXI4-Lite in #14 ...
Patrick Lehmann
@Paebbels
I created some issues for protocols were we can accepts merge requests: #17, #18, #19 and #23, #24, #25
Jim Lewis
@JimLewis
@LarsAsplund WRT your July 4 question, it is a limitation to the LRM. What did you want to do with the default expression? Do you have a use model?
Lars Asplund
@LarsAsplund
@JimLewis Take the VUnit AXI stream master for example. It has a complete interface with all signals but not all slave IPs support that so in those cases some of the master ports are left unconnected. The default values on those unconnected ports makes sure that the master still functions as intended. For example the active low reset input has a default value of 1 and so does the tready port. The standard explicitly describes some signals as optional and what the default value is. If an interface can't have default values then the user must remember to set these signals explicitly. A user may not even know what the proper default for an unused signal like tkeep should be.