myhdl-list

[myhdl-list] Feedback request: User-defined Verilog code

[Jan D. <ja...@ja...>]

Hi:

I have made (and implemented) a proposal for including user-defined
Verilog code during the conversion.

I have not yet made a snapshot, because I would like to have feedback
first. Please read:

    http://myhdl.jandecaluwe.com/doku.php/meps:mep-101

and provide feedback.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Feedback request: User-defined Verilog code

[Tom D. <td...@di...>]

Jan,

Funny I was reading that late last night and it was half complete, you 
must have been working on it.

That looks good to me, and more general (better) than what I was thinking.

In your example, I am assuming that instead of the assign you could have 
any Verilog statements. Such as a module instantiation using MyHDL 
signals as connections?

One question, what is the difference between the wire and reg for 
.driven? I'm not used to worrying about that when connecting Verilog 
modules together.

Tom



Jan Decaluwe wrote:

> Hi:
>
> I have made (and implemented) a proposal for including user-defined
> Verilog code during the conversion.
>
> I have not yet made a snapshot, because I would like to have feedback
> first. Please read:
>
>    http://myhdl.jandecaluwe.com/doku.php/meps:mep-101
>
> and provide feedback.
>
> Regards,
>
> Jan
>

[myhdl-list] Re: Feedback request: User-defined Verilog code

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Jan,
> 
> Funny I was reading that late last night and it was half complete, you 
> must have been working on it.

Yes, with a wiki it all happens in real time!

> That looks good to me, and more general (better) than what I was thinking.
> 
> In your example, I am assuming that instead of the assign you could have 
> any Verilog statements. Such as a module instantiation using MyHDL 
> signals as connections?

Yes. You can do instantiations, but also anything that can occur where
instantiations can occur. (I don't know whether this formulation
is clear). I'm not sure whether that is equivalent to "any verilog
statement" though.

> One question, what is the difference between the wire and reg for 
> .driven? I'm not used to worrying about that when connecting Verilog 
> modules together.

Think about it this way: after the user-defined code is inserted, how
should the (driven) signal be declared in Verilog? If it's driven by
an assign or if it's connected to an output port of an instantiated
module, it should be a wire. But if it's driven from an always block,
it should be a reg.

Perhaps one could think that this could be simplified by only allowing
instantiations, which only require wires. But that doesn't solve the
issue: you still need to tell the convertor which signals are supposed
to be driven by the block. (You would have to say "sig.driven = True"
or something). Otherwise, the convertor will infer an undriven
wire and issue a warning.

Note that normally in MyHDL, you don't have to specify what "inputs"
and "outputs" are - it's all inferred from usage. So this is an
exception.

Note also that a similar issue doesn't exist with signals that are
merely used by the block: everything can be inferred
from the context.

Finally, note that if you forget to set the attribute, or if you
set it to an incorrect value, you will always find out: the convertor
will issue warnings, and/or the Verilog code will not compile. So
I guess this is acceptable.

Let me know if this is acceptable, whether it's clear, and otherwise,
how to explain it better.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: Feedback request: User-defined Verilog code

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

>
> Think about it this way: after the user-defined code is inserted, how
> should the (driven) signal be declared in Verilog? If it's driven by
> an assign or if it's connected to an output port of an instantiated
> module, it should be a wire. But if it's driven from an always block,

Yes, I see that now.  Would it make sense to default it to "wire"? I 
think that would be the most common type, at least from my perspective.

Tom

[myhdl-list] Re: Feedback request: User-defined Verilog code

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Jan Decaluwe wrote:
> 
>>
>> Think about it this way: after the user-defined code is inserted, how
>> should the (driven) signal be declared in Verilog? If it's driven by
>> an assign or if it's connected to an output port of an instantiated
>> module, it should be a wire. But if it's driven from an always block,
> 
> 
> Yes, I see that now.  Would it make sense to default it to "wire"? I 
> think that would be the most common type, at least from my perspective.

In the MyHDL conversion logic, there is a different default already:
namely that a signal is not driven at all. In that case, it will be
either a top-level input, or an undriven wire. In the latter case, a
warning is issued, and an assignment keeps the wire to a constant value. 
I think it is clear why this default makes sense: the convertor can
normally detect whether a signal is driven, and otherwise, the default
is correct - except in the special case of user-defined code.

I'm hoping to be able to keep the default as it is, and ask more help
from the user for the special case. I've not yet found a better
solution.

The "driven" attribute was already used internally for inference of
input, outputs, wire, regs. What I did now is simply make it a public
attribute that can be manipulated by the user, to resolve issues with
user-defined code.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Feedback request: User-defined Verilog code

[Jan D. <ja...@ja...>]

Jan Decaluwe wrote:
> Tom Dillon wrote:
> 
>> Jan Decaluwe wrote:
>>
>>>
>>> Think about it this way: after the user-defined code is inserted, how
>>> should the (driven) signal be declared in Verilog? If it's driven by
>>> an assign or if it's connected to an output port of an instantiated
>>> module, it should be a wire. But if it's driven from an always block,

I have added more info on this to the MEP page.

I have also released snapshot 0.5dev4 with this feature.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com