by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Thomas Hornschuh
    @ThomasHornschuh
    I just run the test suite. All test except core fail. I think I need to configure a few things, e.g. it states that there is no simulator configured
    Can you give me a hint what to do?
    Thomas Hornschuh
    @ThomasHornschuh
    I tried to run the inital_values test alone: py.test --sim ghdl test_initial_values.py
    Result:
    FAILED test_initial_values.py::test_unsigned - assert 1 == 0
    FAILED test_initial_values.py::test_signed - assert 1 == 0
    FAILED test_initial_values.py::test_bool - assert 1 == 0
    FAILED test_initial_values.py::test_modbv - assert 1 == 0
    FAILED test_initial_values.py::test_enum - AssertionError: assert 1 == 0
    FAILED test_initial_values.py::test_long_signals - assert 1 == 0
    FAILED test_initial_values.py::test_single_length_signals - assert 1 == 0
    FAILED test_initial_values.py::test_unsigned_list - assert 1 == 0
    FAILED test_initial_values.py::test_signed_list - assert 1 == 0
    FAILED test_initial_values.py::test_modbv_list - assert 1 == 0
    FAILED test_initial_values.py::test_long_signals_list - assert 1 == 0
    FAILED test_initial_values.py::test_bool_signals_list - assert 1 == 0
    FAILED test_initial_values.py::test_init_used - AssertionError: assert 1 == 0
    Martin
    @hackfin
    @ThomasHornschuh, the tests will only pass when you have an older GHDL version installed (same version as in travis)
    It's got to do with stdout/stderr behaviour, so plenty of FAILs will occur when you have a recent GHDL version
    Thomas Hornschuh
    @ThomasHornschuh
    Sounds time consuming. Think it will be the easiest way to set up a new Linux VM for MyHDL testing
    Martin
    @hackfin
    I've got a Docker container as reference, if you want to play with it
    So all the cosim/test stuff is setup in there with the fairly recent GHDL/iverilog releases. See also #322, I documented some there
    Thomas Hornschuh
    @ThomasHornschuh
    Sounds also not very appealing. I experimented a bit with Docker a year ago, stopped because it did not gave enough value for my use cases...
    Martin
    @hackfin
    well, i know of no other method saving you most of the reproduction hassle
    But I'm aware it is not always smooth on Windows hosts
    Thomas Hornschuh
    @ThomasHornschuh
    Windows is not the issue, I do all my development work solely with Linux, Windows is only used as VM host, just because I avoid any hardware comaptibltly issues
    So I think extra Linux VM will be the fastest way for me. I can than still install your docker container. Which version of docker is needed for this?
    Martin
    @hackfin
    Then it's a one liner: docker run -it --rm hackfin/myhdl_testing
    Henry Gomersall
    @hgomersall
    yeah, docker is good. I use a chroot which works well too
    The chroot is easy with schroot
    Thomas Hornschuh
    @ThomasHornschuh
    I‘m checking @hackfin s readme, I will give it a try
    Martin
    @hackfin
    it's pretty much a bare bone debian buster with the tools to build myhdl and install ghdl (sudo apt-get ...)
    Thomas Hornschuh
    @ThomasHornschuh
    BTW: Is there any way to supress the MyHDL conversion warnings ?
    Martin
    @hackfin
    Tried warnings.filterwarnings? Or you could do output capture to a io.FileIO
    Josy Boelen
    @josyb

    BTW: Is there any way to supress the MyHDL conversion warnings ?

    write good code :)
    suppressing them in MyHDL doesn't keep them from appearing in the generated V*

    Not that you will notice them in Vivado or Quartus; your generated warnings will be buried under a shitload generated by their IP (which must have developed by the lowest bidder)
    Thomas Hornschuh
    @ThomasHornschuh
    write good code :)
    Thomas Hornschuh
    @ThomasHornschuh
    I'm focusing on the "Signal is not driven" and "Driven but not read" warnings. I have some configation options in my processor core which intentionally does not expose everything inside to the toplevel. E.g. I have a debug interface which allows in simulation to capture all commited instructions with their destination register number and value, but it is not exposed for synthesis. Of course I could set the driven or read attributes. But with more dynamic configuation it is not so easy to do this in a robust yet easy to maintained way
    Henry Gomersall
    @hgomersall
    @josyb it's sometimes necessary to have the warnings.
    Thomas Hornschuh
    @ThomasHornschuh
    suppressing them in MyHDL doesn't keep them from appearing in the generated V*
    Good point, so the best would be when MyHDL could optimze unused signals away .. I'm kidding
    Henry Gomersall
    @hgomersall
    @ThomasHornschuh we have a few of these
    with warnings.catch_warnings():
        warnings.filterwarnings(
            'ignore',
            message='Signal is driven but not read: '
            'lvds_serdes_control0_lvds_serdes_control_interface_clk_reset',
            category=ToVerilogWarning)
    We make try hard to be explicit about every signal so as to avoid errors
    then do the conversion inside that context
    Thomas Hornschuh
    @ThomasHornschuh
    Sorry, I regulary forget the empty line after a quote....
    @hgomersall I'm still a Python rookie, where must I apply the with clause? Behind convert?
    Henry Gomersall
    @hgomersall
    with warnings.catch_warnings():
        warnings.filterwarnings(
            'ignore',
            message='Signal is driven but not read: '
            'lvds_serdes_control0_lvds_serdes_control_interface_clk_reset',
            category=ToVerilogWarning)
        foo.convert()
    like that
    Thomas Hornschuh
    @ThomasHornschuh
    Can I also redirect some to some log file? Background: I'm currently running the RISC-V complicance test suite on the VHDL conversion of my cpu core, for simplicity it is converted on every test, and the >50 repeats of the same warnings make the output hard to read
    Thomas Hornschuh
    @ThomasHornschuh
    @hgomersall Just tried it out, works :-)
    Martin
    @hackfin
    @ThomasHornschuh out of curiosity: do u use the google test suite for the riscv?
    Thomas Hornschuh
    @ThomasHornschuh
    @hackfin Not sure what you mean, I use https://github.com/riscv/riscv-compliance
    I'm not yet using riscv-formal, but this is on my longer term goals.
    Martin
    @hackfin
    Meant the stuff around this one: https://github.com/google/riscv-dv
    Thomas Hornschuh
    @ThomasHornschuh
    OK, was not aware of this yet. I'm very intersted in the RISC-V ecosystem, but it is growing faster and larger as a single person can follow :-)
    @hackfin BTW, just tried out your container, "smoke testing" with your default Makefile. It loads all the things, but ends up with syntax errors, is this expected?
    Josy Boelen
    @josyb

    suppressing them in MyHDL doesn't keep them from appearing in the generated V*
    Good point, so the best would be when MyHDL could optimze unused signals away .. I'm kidding

    Actually it can, at least in my branch.
    I created an OpenPort() class and modified both VHDL and Verilog converters to prefix the line with a comment; and gone are those pesky warnings ...

    Everywhere ...
    Thomas Hornschuh
    @ThomasHornschuh

    I just tried a fresh start, cloned my MyHDL repo and run py.test in the test root directory,

    ImportError while loading conftest '/home/masocist/myhdl/myhdl/test/conftest.py'.
    /usr/lib/python2.7/dist-packages/six.py:709: in exec_
        exec("""exec _code_ in _globs_, _locs_""")
    conftest.py:4: in <module>
        from myhdl.conversion import analyze, verify
    E   ImportError: No module named myhdl.conversion

    I think it has to do with using python2.7. Just crosschecked on another "clean" VM, with just Python and pytest installed

    But no worries, I can also use your Dockerfile as template and adapt it.
    Martin
    @hackfin
    @ThomasHornschuh, you'll have to use py.test-3, I started ditching 2.7 compat
    The CI-tested that always works is tagged :yosys, :latest might no longer run from the box
    but :yosys is obviously testing against the jupyosys fork
    Thomas Hornschuh
    @ThomasHornschuh
    Still struggling. I'm not sure what is the correct way to invoke the Tests. Running py.test (or py.test-3) in myhdl/myhdl/test seems only to work when myhdl is already installed with pip/pip3
    Thomas Hornschuh
    @ThomasHornschuh

    I temprarely gave up on the docker image and decided to go back to the roots and debug the test on my standard config. I made a funny observation: My GHDL version crashes on the test benches generated by MyHDL:

    Please report this bug on https://github.com/ghdl/ghdl/issues
    GHDL release: 0.37-dev (v0.36-1548-gc83bce97) [Dunoon edition]
    Compiled with GNAT Version: 7.4.0
    Target: x86_64-linux-gnu
    /home/thomas/development/myhdl/
    Command line:
    ghdl -r --std=08 initial_value_bool_list_bench
    Exception TYPES.INTERNAL_ERROR raised
    Exception information:
    raised TYPES.INTERNAL_ERROR : files_map.adb:83
    Call stack traceback locations:
    0x55df9bfb2279 0x55df9bfb4835 0x55df9bfbe95f 0x55df9c02fe7c 0x55df9c03093c 0x55df9c030a0e 0x55df9c10337a 0x55df9c1030b0 0x55df9c1031b6 0x55df9c104921 0x55df9c11436e 0x55df9c1cc00b 0x55df9c113864 0x55df9c0ab41f 0x55df9c1cf9ef 0x55df9beb55f9 0x7f8f58546b95 0x55df9beb42c8 0xfffffffffffffffe
    ******************************************************************

    Funny, I use this version since more than a year with fairly complex VHDL code (using structs, file handling ,whatever...) and also with my MyHDL based RISC-V core never crashed it. There is nothing looking "dangerous" in the MyHDL test code. I will make a new GHDL build, and if it still crashes raise an issue there. But not today....