Here is a simple model of ideal Digital to Analog Converter (DAC):

`from myhdl import modbv, Signal, delay, always, Simulation, traceSignals, instance, now

import numpy as np

def clock_source(clock, frequency): period = 1 / frequency / 10 ** (-9) # ns half_period = delay(round(period / 2))

@always(half_period)
def clksrc():
    clock.next = not clock

return clksrc

def digital_sin_source(clock, sine, frequency, bits): out_range = 2 ** (bits - 1)

@always(clock.posedge)
def sinsrc():
    sine.next = int(out_range * np.sin(2 * np.pi * frequency * now() / 10 ** 9))

return sinsrc

def ideal_dac(clock, digital, analog, bits, amin=-1, amax=1): step = (amax - amin) / 2 ** bits

@always(clock.posedge)
def dac():
    analog.next = amin + step * digital

return dac

def test_ideal_dac(): bits = 8 clock = Signal(bool(0)) digital = Signal(modbv(0, min=-(2 ** (bits - 1)), max=2 ** (bits - 1))) analog = Signal(float(0))

clksrc = clock_source(clock, 100 * 10 ** 6)
sine = digital_sin_source(clock, digital, 10 * 10 ** 3, bits=bits)
dac = ideal_dac(clock, digital, analog, bits=bits)

@instance
def test():
    yield delay(10)

return clksrc, sine, dac, test

traceSignals.filename = 'test' test_inst = traceSignals(test_ideal_dac) Simulation(test_inst).run(100000) `

This code generates test.vcd file. Then I open it in GTKwave (version 3.3.100) and add all signals. The "analog" signal is a real value signal, so I choose in GTKwave: Data Format -> Analog -> Interpolated. But nothing happens. When I locally modified _printVcdStr function and install MyHDL using pip from local files all is ok.

Can you provide a simple excerpt of code showing the problem ?

traceSignals function incorrectly writes real value signal to VCD. Verilog Standard states that a real value signal in VCD dump should start with "r" or "R" identifier. But instead, MyHDL creates signal starting with "s". So GTKwave can't make an analog wave. A function _printVcdStr caused this behavior. Just change 's' to 'r'.

Yes, that the way it works.

@cfelton this will replace the parameter with its values, in the generated verilog, isn't it?

no the attribute signed in line 1604 originally.

Just updated the PR...

I ran into an issue where the FIFO was reset and data became available the cycle after. The FIFO axis-slave hast tready asserted, but the internal write address is not correct in that case. One solution might be to deassert tready for the cycle after the reset. Alternatively the address calculation can provide the correct address immediately after reset. This implements the latter. Also I think the tready signal should be deasserted during reset. The core is definitely not going to be ready to receive data and hence should signal accordingly. I prepared test cases for these fixes and added them to the test bench.

The registers in question have now been removed, so I'm considering this resolved.

@josby, @ThomasHornschuh thanks for the clarification, understand.

yes, I agree looks good. If you push that small change I will merge it.

Well, after doing some investigating, it's unclear why I added that reg in the first place. At the time I was working with the VCU108 board with a XCVU095 FPGA. However, the block RAM on that FPGA doesn't absorb those address registers, and removing them results in the same level of timing performance. For UltraRAMs, I think all inputs need to be registered, both address and data. I'm thinking I will remove that register completely and consider adding parametrizable input registers to aid in timing when using URAMs.

I think I can see what the issue is now. However, I explicitly did not reset that register so that there would be no issues with merging it into block RAM instances. Adding a reset could prevent proper inference of the block RAM. I would have to do quite a bit of reading and/or synthesis testing for various targets to figure out if adding that reset is acceptable. What I can look in to, however, is disabling the tready input for one cycle after reset is released.

It seems that it does not simulate correctly.

This is not a surprise. Anyway, the @alwaysparameters are not good. .negedgeshould not be used here. At least for `RESETn'. I still think the way to go is to fix the simulation.

@NicoPy

I have not checked if it simulates correctly.

It seems that it does not simulate correctly. Maybe among other things, some combinatorial processes are not being informed correctly about signals that are written in this sequential process. Also: Not sure, if there is a difference between Python2 and Python3 (worse in Python3).

@LarsRlrs Yes. I was showing the way it is intended to be used (from my understanding).

Another code that suits your requirements is the following :

    @always(clk.posedge, RESETn.negedge)
    def seq():
        if clk.posedge :
            out1.next=in1 or in2
            out2.next=in1 and in2
        
        if RESETn == 0:
            out1.next=0
        else :
            pass

MyHDL complains there is no else ? Well... just add an else ;)

However, the conversion result is surprising :

INC_SEQ: process (clk, RESETn) is
begin
    if rising_edge(clk) then
        out1 <= stdl(bool(in1) or bool(in2));
        out2 <= stdl(bool(in1) and bool(in2));
    end if;
    if (RESETn = '0') then
        out1 <= '0';
    elsif rising_edge(clk) then
        null;
    end if;
end process INC_SEQ;

I have not checked if it simulates correctly.

@NicoPy Just one comment: The code that you wrote, makes out2 dependent from RESETn.

@LarsRlrs From what I understand, @always intended use is like this :

    @always(clk, RESETn)
    def seq():
        if RESETn == 0:
            out1.next=0
        elif clk.posedge :
            out1.next=in1 or in2
            out2.next=in1 and in2

    return instances()

You will notice there is an else ;) It translates to the following :

INC_SEQ: process (clk, RESETn) is
begin
    if (RESETn = '0') then
        out1 <= '0';
    elsif rising_edge(clk) then
        out1 <= stdl(bool(in1) or bool(in2));
        out2 <= stdl(bool(in1) and bool(in2));
    end if;
end process INC_SEQ;

For a reset at the end of the process, your version1 converts correctly but does not simulate. Maybe this is the way to go and try to make simulation work corectly.

Probably, but I wonder what priority it will get and who is going to make the PR.

Hopefully, it is easy and not much effort to fix.

Xilinx also recommends synchronous resets?

Yes. But I can't do that at the moment.

And then you have the 3-process approach. I don't find that it increases the (source) code size that much. And it does not increase resource usage - win some, lose some.

I'd say, up to 50% and beyond is significant. Starting with one processes, you need one additional combinatorial signal for every interaction between functionality that is then separated into two sequential processes. Multiple interactions per state and a couple of states et voila: "ldlq", "ldlqw", "sellqw" (https://gist.github.com/josyb/efec12907bb82a06e42758c039767c7f). Much more for modules with a couple of counters and ShiftRegs.

Could this be fixed so that mhdl-conversion does not insist on the else-clause of the Reset but uses the stuff before the Reset for rising clock edge?

Probably, but I wonder what priority it will get and who is going to make the PR.

The FPGA vendor Xilinx recommends to reset as few FFs as possible.

Xilinx also recommends synchronous resets?

But it really increases the code size. I would have to use an additional combinatorial process because two sequential processes alone will not do (additional clock cycle from one sequential process to the other).

And then you have the 3-process approach. I don't find that it increases the (source) code size that much. And it does not increase resource usage - win some, lose some.

@josyb

Does your desired construct synthesize?

Yes.

In all literature the standard VHDL asynchronous reset follows

The same literature that states one shall use Python for HDL? ;) It took until VHDL-2019 for VHDL to include interfaces. Writing the reset at the end is much older than 2017. We are not waiting for the literature :)

Again, MyHDL != Verilog. IMO the only way is to use two processes; one with a (either synchronous or asynchronous) reset and the second without.

Verilog synchronous: works Verilog asynchronous: works VHDL synchronous: works VHDL asynchronous: does not work

Could this be fixed so that mhdl-conversion does not insist on the else-clause of the Reset but uses the stuff before the Reset for rising clock edge?

The @always_seq construct was specifically added to simplify the choice of reset signal (active high or low; synchronous or asynchronous; or simply None) without having to update the MyHDL code depending on which FPGA vendor is targeted.

The FPGA vendor Xilinx recommends to reset as few FFs as possible.

I understand that this conflicts with the one-process state machine approach.

Your recommendation to use more than one process is cleaner from a design guide perspective and this almost makes me want to rewrite code. But it really increases the code size. I would have to use an additional combinatorial process because two sequential processes alone will not do (additional clock cycle from one sequential process to the other).

Does your desired construct synthesize? In all literature the standard VHDL asynchronous reset follows this template:

process (Clock, Reset)
begin
  if Reset = '0' then
    -- reset register, Q <= 0
  elsif RISING_EDGE(Clock) then
    -- increment register, Q <= Q + 1;
  end if;
end process;

Again, MyHDL != Verilog. IMO the only way is to use two processes; one with a (either synchronous or asynchronous) reset and the second without. The @always_seq construct was specifically added to simplify the choice of reset signal (active high or low; synchronous or asynchronous; or simply None) without having to update the MyHDL code depending on which FPGA vendor is targeted. I understand that this conflicts with the one-process state machine approach.

@NicoPy The version1 conversion result is the output that I expect to have. But the version1 myhdl code does not simulate correctly. It seems that this is executed twice for each clk rising edge.

It is my understanding that the notation in myhdl should include @always(clk.posedge), but I found no way to get to the expected VHDL conversion result with this. The reason seems to be that myhdl-conversion is searching for an else to the if RESETn==0, but there is no else and so myhdl-conversion raises an error.

    @always(clk.posedge, RESETn.negedge)
    def seq():
        out1.next=in1 or in2
        out2.next=in1 and in2
        
        if RESETn==0:
            out1.next=0

leads to No separate else clause found And

    @always(clk.posedge, RESETn)
    def seq():
        out1.next=in1 or in2
        out2.next=in1 and in2
        
        if RESETn==0:
            out1.next=0

leads to base type error in sensitivity list VHDL conversion result for synchronous reset is working. VHDL conversion result for asynchronous reset is not worling.

Again, here is the expected/desired conversion result (VHDL with asynchronous reset, but not every FF):

architecture MyHDL of inc is
begin

INC_SEQ: process (clk, RESETn) is
begin
    if rising_edge(clk) then
        out1 <= stdl(bool(in1) or bool(in2));
        out2 <= stdl(bool(in1) and bool(in2));
    end if;
    if (RESETn = '0') then
        out1 <= '0';
    end if;
end process INC_SEQ;

end architecture MyHDL;

@LarsRlrs That's what you get. But what is the output you expect to have?

Version1:

from myhdl import *
@block
def inc(clk, RESETn, in1, in2, out1, out2):
    @always(clk,RESETn)
    def seq():
        if clk.posedge:
            out1.next=in1 or in2
            out2.next=in1 and in2      
        if RESETn==0:
            out1.next=0
    return instances()

def convert_inc():
    clk=Signal(bool(0))
    RESETn=Signal(bool(0))
    
    in1,in2,out1,out2=[Signal(bool(0)) for k in range(4)]
    inc_1 = inc(clk, RESETn, in1, in2, out1, out2)

    inc_1.convert('VHDL')

Version 1 conversion (conversion result is as expected but does not simulate correctly in myhdl):

architecture MyHDL of inc is
begin

INC_SEQ: process (clk, RESETn) is
begin
    if rising_edge(clk) then
        out1 <= stdl(bool(in1) or bool(in2));
        out2 <= stdl(bool(in1) and bool(in2));
    end if;
    if (RESETn = '0') then
        out1 <= '0';
    end if;
end process INC_SEQ;

end architecture MyHDL;

Version 2:

from myhdl import *
@block
def inc(clk, RESETn, in1, in2, out1, out2):
    @always(clk,RESETn)
    def seq():
        if bool(clk.posedge) and clk==1:
            out1.next=in1 or in2
            out2.next=in1 and in2      
        if RESETn==0:
            out1.next=0
    return instances()

def convert_inc():
    clk=Signal(bool(0))
    RESETn=Signal(bool(0))
    
    in1,in2,out1,out2=[Signal(bool(0)) for k in range(4)]
    inc_1 = inc(clk, RESETn, in1, in2, out1, out2)

    inc_1.convert('VHDL')

Version 2 conversion (simulation seems to be ok but conversion is not ok; synthesis will use CE):

architecture MyHDL of inc is
begin

INC_SEQ: process (clk, RESETn) is
begin
    if (rising_edge(clk) and (clk = '1')) then
        out1 <= stdl(bool(in1) or bool(in2));
        out2 <= stdl(bool(in1) and bool(in2));
    end if;
    if (RESETn = '0') then
        out1 <= '0';
    end if;
end process INC_SEQ;

end architecture MyHDL;

Anything with @always(clk.posedge....) makes things worse.

@LarsRlrs Can you provide the resulting VHDL code you expect ? Please embed the code in the body of your message (using markdown code tag), not in an external file. It will be much easier to read this thread.

My understanding is that myhdl is supposed to increase freedom and possibilities. Yes, but MyHDL is not Verilog in disguise -- although one might think so because of the @always decorators.