Multiple @always_comb needed - why?

Hi All,

I think I am missing something on how I an constructing combinatorial logic, as it seems like I need to specify a separate comb process if I calc and then use this calc further on in the same process.

(I hope I have captured working code below for someone to test)

In Verilog we can create a design like this:

module my_test(a, b, c);

input wire [3:0] a;
input wire [3:0] b;
output reg [4:0] c;

reg [3:0] z;

always @ (a, b) begin
z = a + 4’h1;
c = z + b;
end

endmodule

and from what I see you write this in myhdl as :
from myhdl import *

@block
def test(
a,
b,
c):

z = Signal(intbv(0)[4:])

@always_comb
def comb_logic():
    z.next = (a + intbv(1)[4:])
    c.next = (z + b)

return instances()

if (name == ‘main’):
a = Signal(intbv(0)[4:])
b = Signal(intbv(0)[4:])
c = Signal(intbv(0)[4:])

design = test(
            a,
            b,
            c)

it fails unless you specify the z.next in its own process … here’s the functioning code
from myhdl import *

@block
def test(
a,
b,
c):

z = Signal(intbv(0)[4:])

@always_comb
def comb_logic():
    z.next = (a + intbv(1)[4:])

@always_comb
def comb_logic():
    c.next = (z + b)

return instances()

if (name == ‘main’):
a = Signal(intbv(0)[4:])
b = Signal(intbv(0)[4:])
c = Signal(intbv(0)[4:])

design = test(
            a,
            b,
            c)

Hi Steve,

you stumbled on yet another remains of the early days; only this one throws an error.
I have discussed this at the time with the development leaders but it never got resolved. I commented out the offending code in my local development tree (which is totally separate from the support tree).
It is time we solve this one.

Regards,
Josy

Hi Josy,

Sorry for the uncovering of previous discoveries - its just that I have embarked on a full development cycle and have decided to use myHDL for this - and so using the tool in a serious way uncovers these pitfalls I guess.

Is there a timeline to getting this resolved, I cant do it as I have no python skills, and for now I can comment my code and it will compile in any case, but a fix would just make the code more sensible looking

Regards,
Steve

Hi Steve,

I already issued a PR to delete that error check. But it is waiting on the Travis-CI continuous integration check which, for reasons unknown to me, doesn’t start. I will try to look into that matter asap.

Regards,
Josy

Have you migrated from travis-ci.org to travis-ci.com?

If not it might be time to look at github actions. I moved over a project of mine a while back. It is a pain, but travis are beginning to charge a bit too much for their work.

Dave, thanks for the info.
I only recently received commit rights, and running this all is quite new to me.
I believe travis-ci is free for Open-Source projects. Getting it going again would be the easy (lazy, sorry) way out.

Edit: I checked travis-ci.com and don’t readily find a free plan :frowning:
Second edit: there is no free plan - just a one month trial. Then we’d have to subscribe at $69,- per month. looks like we have to switch to GitHub Actions after all.

1 Like

I can have a look at that, if you want, I have set it up a few times

That would be very much appreciated.
It is essential to check the incoming PRs before merging.
Perhaps I can take a peek in one of your projects to see and compare?

Sure, but some of my work was for blender, to run multiple blender builds like one runs multiple python builds, so it was a little more involved, but the infrastructure can be seen here:

Edit: The cool upgrade we got over travis, at the time, was that we could also run tests on windows and mac, in addition to linux.

Dave,

Adding Windows and Mac is cool. (I will catch some flak?)
I will read up on Github Actions asap. This week is too busy …
And then try to digest your config file.

Regards,
Josy

I did a quick pass through got something functional:

However there is something weird going on with the ghdl install, it complains when I try and add the ppa key and I have loads of failures locally when I try and run it (may or may not be related).

Here is a completed run, for reference:

I triggered the Actins on the official repo.
It fails for GHDL as well.
→ pck_myhdl_011.vhd:8:10: unit “numeric_std” not found in library “ieee”

Well that’s good in that it is consistent. I think this is a real issue that needs to be debugged. That is the ghdl that can be installed from ubuntu doing a apt install.

There is a feature in actions (that is also in travis) where you can run nightly builds (or weekly) this can catch cases where the dependent software you are using is also changing in time and may actually break after your last check in. This is why I set it up for blender that it was in high flux at the time allowed me to catch them when they were breaking the API (which they did between version 2.79 and 2.80).

Can you do a clean install and run locally?

I shook the tree:
maybe this gives a hint: vhld 2008 libraries missing in ghdl installation - Stack Overflow

Did there used to be a special version of ghdl that you guys were using? But is no longer available?

      sudo add-apt-repository ppa:mati75/ghdl -y;

Err:30 http://ppa.launchpad.net/mati75/ghdl/ubuntu focal Release
  404  Not Found [IP: 91.189.95.85 80]
Reading package lists...
E: The repository 'http://ppa.launchpad.net/mati75/ghdl/ubuntu focal Release' does not have a Release file.
Error: Process completed with exit code 100.

Did there used to be a special version of ghdl that you guys were using? But is no longer available?

I remember something of that kind of GHDL being version dependent.
(this something I hate about open source: they keep on breaking code every other day)

From that page:

It seems that the package of GHDL that you installed was built with “openieee”, instead of including libs from IEEE. This is because of licensing/distribution issues. You need to install a “regular” build of GHDL, or to download and build/install the libraries from ghdl/libraries at master · ghdl/ghdl · GitHub.

I am not sure how one does that from apt or without building from source, but it is a hint, I imagine this would have been an issue on travis.

OK this is what a build from source looks like:

It takes a little longer, 2 minutes instead of 30 seconds, but maybe not a bad way to go to maintain tracking with the head of ghdl. That may not be where you want to be.

All greens! If you think this is a way you want to proceed I can merge this version into the pull request