myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Re: toVHDL co-simulation

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

Günter Dannoritzer wrote:
> Jan,
> 
> I looked through the myhdl.c code for the Icarus co-simulation,
> searching for the functions and data types used by MyHDL for co-simulation.
> 
> I would like to write them out to the wiki, so that it is documented
> what functions of the PLI are required for MyHDL. That could be used as
> a base to discuss what is needed from a VHDL simulator for co-simulation.
> 
> There is some notion on the GHDL mailing list to go on with the
> development of the existing C-based VPI interface (not the Ada based
> VHPI). If we could show them our requirements, we might be able to
> influence what parts they are implementing. At least we could use it as
> a base to asked whether we could ever expect that functionality from GHDL.
> 
> Should I add the requirements to the toVHDL page you created or make a
> new page specific for that?

I suggest to add a new page (e.g [[vhdl_cosimulation]]) and make it
accessible under the "Development Zone".

> Am I going the wrong way with this?

It's progress, so it's always the right way! To implement VHDL
co-simulation, your efforts will be very helpful, so I suggest
to document your findings while they are still fresh.

However, as you can see from the toVHDL page, I am currently
suggesting to try to find a way to verify without co-simulation.
I am sceptical that we will get VHDL co-simulation to work
as needed any time soon; so for VHDL conversion it would be
helpful if we can do without it.

Thanks and regards,

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] toVHDL co-simulation

[<dan...@we...>]

Jan,

I looked through the myhdl.c code for the Icarus co-simulation,
searching for the functions and data types used by MyHDL for co-simulation.

I would like to write them out to the wiki, so that it is documented
what functions of the PLI are required for MyHDL. That could be used as
a base to discuss what is needed from a VHDL simulator for co-simulation.

There is some notion on the GHDL mailing list to go on with the
development of the existing C-based VPI interface (not the Ada based
VHPI). If we could show them our requirements, we might be able to
influence what parts they are implementing. At least we could use it as
a base to asked whether we could ever expect that functionality from GHDL.

Should I add the requirements to the toVHDL page you created or make a
new page specific for that?

Am I going the wrong way with this?

I appreciate any comments.

Cheers,

Guenter

[myhdl-list] Re: 0.5dev3 testing

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

Hi:

I have put the current approach on hold for reconsideration.

See also my comments:

Tom Dillon wrote:
> Jan,
> 
> I don't like making all signals signed in a design just because you use 
> one signed number somewhere in the design.  Let's say you have a design 
> basically working (with all unsigned numbers) and you need to pull in a 
> module that needs to do a single signed operation, all your signals now 
> grow by a bit, for no good reason. That doesn't seem right to me.

I agree it seems brute-force, but the good reason would be get it right.

My thinking was that it would not be common to have a single, or a
few signed operations - I thought either none, ore lots of them. But I
agree that the scenario you describe is not like that.

Internally in the design, I think the issue is largely psychological
(although that counts) - I don't think there would be any significant
impact on efficiency in synthesis results by adding a sign bit
systematically (if it's needed, you'll be glad it's there, otherwise
a synthesis tool may remove it by logic optimization).

However, at the port level the additional (unexpected) bit may be
disturbing. And perhaps also for special cases like single-bit signals.

> I would prefer to be in control of the bit widths of all signals from 
> the MyHDL source.
> 
> MyHDL simulation really does all math signed, and the only concern it 
> has is that you always assign a number to a variable that is within its 
> min/max range.
> 
> For example, if you do the following with a, b, x all having their _min 
> set to 0,
> 
> x.next = a - b,
> 
> it will work fine until you try it with b > a. Once you try with b > a, 
> you get a MyHDL simulation error and need to fix the problem.  The fix 
> is as a minimum make x._min negative enough to hold all the the results 
> of your simulation. This is no different than the simulation catch a 
> x._max too small.
> 
> The next problem you will run into is anywhere x goes, will also need to 
> be have a similar _min or else the simulation will again flag an error 
> and stop when the assignment occurs that violates the _min. My point is, 
> MyHDL simulation forces proper prorogation of the signed numbers, at 
> least if you do a reasonable simulation. So far this is good with MyHDL 
> providing a very nice means of making sure all your numbers can be 
> contained within all the signals of your design.
> 
> The real trouble comes if only one of a or b are signed and the target 
> is signed. Since the MyHDL simulation will always do the math correctly, 
> it is hard to match the Verilog simulation.  

Interesting statement :-) (I have to remember that one!)

> I would suggest one of the following for this case:
> 
>    1. Do nothing, force a good simulation which will leave some Verilog
>       debugging.

I think what you suggest here is that after conversion, a succesful
MyHDL simulation would not necessarily match the Verilog simulation.

That would definitely be not an option for me. If at all possible, I
want to make sure (ideally guarantee) that the simulations match.
I believe this is the only way to create a level of confidence in
a new tool. Also, it makes it unambiguous where the bug is (that is,
if the simulations don't match, it's a MyHDL bug).

On 2 occasions in the past, I have rejected EDA tools that didn't
follow this approach.

>    2. Locally add a bit to a or b if unsigned and make MSB 0, basically
>       concatenate a 0 during the operation and force the operation to be
>       signed.

That's a valid alternative - a fine-grained approach.

Initially, I was a little overwhelmed by the apparent complexities
in getting this right in Verilog. So I looked for an approach that
would "always" work. Hence the current coarse-grained approach.

However, during implementation, I noticed that this fine-grained
approach might not be too difficult after all. I don't have to
deal with *any* Verilog, only with code that comes from MyHDL.
And this code is structured in a way that may make it not
too hard to do it like that.

So I'll reconsider all this and give it some thinking.

> Another note on signed numbers. I have found that the only way to 
> propagate a negative number through a slice operation is to use a[:n]. 
> That seems to work fine, while slicing from the MSB down doesn't get the 
> negative number passed. This is OK, but maybe a note is needed in the 
> manual on that.

This is modelled after Verilog.
There's a note on this in the reference part on the intbv. I agree
it should be also be mentioned when slicing is introduced.

> What if I want to concat() some bits together to form a signed number (a 
> negative one). For example if I wanted to sign extend a negative number. 
> Normally I would expect this to work (at least in an HDL):
> 
> b.next = concat(a[MSB],a[MSB],a) # with b 2 bits bigger than a.
> 
> But this will always result in a positive number in the MyHDL simulation.

Of course in this case "b.next = a" would work as expected. In general,
I guess manipulating the bits of a signed number would be easiest:

a[:] = -1
a[3:] = .....

Or a sign-extension function.

concat itself returns positive numbers as you note. To me it's a bit
like slicing: when working on a limited number of bits, I think
you're normally not concerned about positive/negative interpretation.

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: 0.5dev3 Verilog signal name conflict

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

Thanks for this bug report and the fix. Especially thanks for providing
a small failing example!

I have fixed this (long-standing) bug in 0.5dev4.

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: one more for 0.5dev3

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

Tom Dillon wrote:
> I found one more hierarchical related problem in 0.5dev3, this one I 
> think is new to the development version.

Yes. Nothing fundamental fortunately, bad choice in using names
in the hierarchy. Believe it or not, hierarchical extraction has
actually become much cleaner and more general!

Thanks for the bug report and the example.

A fix is provided in 0.5dev4.

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

Re: [myhdl-list] Re: 0.5dev3 testing

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

Jan,

I don't like making all signals signed in a design just because you use 
one signed number somewhere in the design.  Let's say you have a design 
basically working (with all unsigned numbers) and you need to pull in a 
module that needs to do a single signed operation, all your signals now 
grow by a bit, for no good reason. That doesn't seem right to me.

I would prefer to be in control of the bit widths of all signals from 
the MyHDL source.

MyHDL simulation really does all math signed, and the only concern it 
has is that you always assign a number to a variable that is within its 
min/max range.

For example, if you do the following with a, b, x all having their _min 
set to 0,

x.next = a - b,

it will work fine until you try it with b > a. Once you try with b > a, 
you get a MyHDL simulation error and need to fix the problem.  The fix 
is as a minimum make x._min negative enough to hold all the the results 
of your simulation. This is no different than the simulation catch a 
x._max too small.

The next problem you will run into is anywhere x goes, will also need to 
be have a similar _min or else the simulation will again flag an error 
and stop when the assignment occurs that violates the _min. My point is, 
MyHDL simulation forces proper prorogation of the signed numbers, at 
least if you do a reasonable simulation. So far this is good with MyHDL 
providing a very nice means of making sure all your numbers can be 
contained within all the signals of your design.

The real trouble comes if only one of a or b are signed and the target 
is signed. Since the MyHDL simulation will always do the math correctly, 
it is hard to match the Verilog simulation.  

I would suggest one of the following for this case:

   1. Do nothing, force a good simulation which will leave some Verilog
      debugging.
   2. Locally add a bit to a or b if unsigned and make MSB 0, basically
      concatenate a 0 during the operation and force the operation to be
      signed.

Another note on signed numbers. I have found that the only way to 
propagate a negative number through a slice operation is to use a[:n]. 
That seems to work fine, while slicing from the MSB down doesn't get the 
negative number passed. This is OK, but maybe a note is needed in the 
manual on that.

What if I want to concat() some bits together to form a signed number (a 
negative one). For example if I wanted to sign extend a negative number. 
Normally I would expect this to work (at least in an HDL):

b.next = concat(a[MSB],a[MSB],a) # with b 2 bits bigger than a.

But this will always result in a positive number in the MyHDL simulation.

Tom



Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>>
>>
>> Jan Decaluwe wrote:
>>
>>> Tom Dillon wrote:
>>>
>>>> I had been using the following:
>>>>
>>>> Signal(intbv(0,min=0,max=2))
>>>>
>>>> to get a 1 bit register or wire.
>>>>
>>>> With the development version I get a 2 bit signal. Is that 
>>>> intentional?
>>>>
>>>> I thought the range should be min <= Num < max.
>>>
>>>
>>>
>>>
>>> Tom:
>>>
>>> To understand whether this is expected or not, can you please tell
>>> me if you have *somewhere* in your MyHDL code, an intbv that can
>>> have negative values?
>>>
>> Yes.
>
>
> Tom:
>
> In that case, it was not possible to convert with 0.4, so you already
> gain :-)
>
> What I expect is that you don't just get a 2 bit signal, but a *signed*
> 2 bit signal. For a signed representation of just 0 and 1, you do need
> an additional sign bit (which will be zero).
>
> Of course the question is - why a signed representation for a positive
> intbv? I have tried to answer that here:
>
> http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#support_for_signed_arithmetic 
>
>
> Please review this. The point is that it's tricky to get signed right
> in Verilog - using signed as a "default" for intbv representation
> helps in getting it right.
>
> Note that there are special cases, such as slicing, indexing and also
> single bit signals. The latter is relevant to you. As a matter of style,
> I suggest to use Signal(bool()) to represent single bit signals. It's
> more efficient, less typing, and it is clearer. You dont' lose anything
> in terms of operations because bool is a subtype of int in Python.
>
> Moreover, bool() is treated specially by the convertor - the reasoning
> is that signed/unsigned clearly doesn't make a lot of sense in this
> case. Moreover, you want signals like clocks and resets to be single
> bit (unsigned) regs in Verilog. So if you use bool(), you will still
> get a single bit unsigned reg/wire in Verilog.
>
> Regards, Jan
>

[myhdl-list] Re: 0.5dev3 testing

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

Tom Dillon wrote:
> 
> 
> Jan Decaluwe wrote:
> 
>> Tom Dillon wrote:
>>
>>> I had been using the following:
>>>
>>> Signal(intbv(0,min=0,max=2))
>>>
>>> to get a 1 bit register or wire.
>>>
>>> With the development version I get a 2 bit signal. Is that intentional?
>>>
>>> I thought the range should be min <= Num < max.
>>
>>
>>
>> Tom:
>>
>> To understand whether this is expected or not, can you please tell
>> me if you have *somewhere* in your MyHDL code, an intbv that can
>> have negative values?
>>
> Yes.

Tom:

In that case, it was not possible to convert with 0.4, so you already
gain :-)

What I expect is that you don't just get a 2 bit signal, but a *signed*
2 bit signal. For a signed representation of just 0 and 1, you do need
an additional sign bit (which will be zero).

Of course the question is - why a signed representation for a positive
intbv? I have tried to answer that here:

http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#support_for_signed_arithmetic

Please review this. The point is that it's tricky to get signed right
in Verilog - using signed as a "default" for intbv representation
helps in getting it right.

Note that there are special cases, such as slicing, indexing and also
single bit signals. The latter is relevant to you. As a matter of style,
I suggest to use Signal(bool()) to represent single bit signals. It's
more efficient, less typing, and it is clearer. You dont' lose anything
in terms of operations because bool is a subtype of int in Python.

Moreover, bool() is treated specially by the convertor - the reasoning
is that signed/unsigned clearly doesn't make a lot of sense in this
case. Moreover, you want signals like clocks and resets to be single
bit (unsigned) regs in Verilog. So if you use bool(), you will still
get a single bit unsigned reg/wire in Verilog.

Regards, 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] one more for 0.5dev3

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

I found one more hierarchical related problem in 0.5dev3, this one I 
think is new to the development version.

The following code:

def add(x,a,b) :
  def logic() :
    x.next = a + b
  L0 = always_comb(logic)
  return L0

def add4(x,a,b,c,d) :
  xL = [Signal(intbv(0,min=-2**(width+2),max=2**(width+2))) for i in 
range(2)]

  A0 = add(xL[0],a,b)
  A1 = add(xL[1],xL[0],c)
  A2 = add(x, xL[1],d)

  return instances()

def TestModule(x,a,b,c,d,e) :
  x0 = Signal(intbv(0,min=-2**(width+2),max=2**(width+2)))

  A0 = add4(x0,a,b,c,d)
  A1 = add4(x,x0,e,a,b)

  return instances()



The Verilog generated by toVerilog has reg name conflicts on the xL list 
of signals in add4().

I don't have a fix for this one, but it looks like it uses the wrong 
hierarchy in the signal name, the same one for each occurrence of it.

Let me know if you need more information.

Tom

[myhdl-list] 0.5dev3 Verilog signal name conflict

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

This isn't new to the development version, but I just ran into it again 
while testing 0.5dev3.

The following code produces a wire name conflict in the toVerilog 
generated Verilog code.

width = 8

def add(x,a,b) :
  def logic() :
    x.next = a + b
  L0 = always_comb(logic)
  return L0

def add3(x,a,b,c) :
  x0 = Signal(intbv(0,min=-2**(width-1),max=2**(width-1)))
  A0 = add(x0,a,b)
  A1 = add(x,x0,c)

  return instances()

def TestModule(x,a,b,c,d,e) :
  x0 = Signal(intbv(0,min=-2**(width-1),max=2**(width-1)))

  A0 = add3(x0,a,b,c)
  A1 = add3(x,x0,d,e)

  return instances()


The following changes in _toVerilog/_analyze.py fix the problem. This is 
from line 83.

# TPD fix to problem caused by not popping high enough in the hierarchy.
prefixes = prefixes[:curlevel-1]
prefixes.append(name)
# old way
# prefixes = prefixes[:curlevel]


Let me know if you need any more information.

Tom

Re: [myhdl-list] Re: 0.5dev3 testing

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

Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>> I had been using the following:
>>
>> Signal(intbv(0,min=0,max=2))
>>
>> to get a 1 bit register or wire.
>>
>> With the development version I get a 2 bit signal. Is that intentional?
>>
>> I thought the range should be min <= Num < max.
>
>
> Tom:
>
> To understand whether this is expected or not, can you please tell
> me if you have *somewhere* in your MyHDL code, an intbv that can
> have negative values?
>
Yes.

[myhdl-list] Re: 0.5dev3 testing

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

Tom Dillon wrote:
> I had been using the following:
> 
> Signal(intbv(0,min=0,max=2))
> 
> to get a 1 bit register or wire.
> 
> With the development version I get a 2 bit signal. Is that intentional?
> 
> I thought the range should be min <= Num < max.

Tom:

To understand whether this is expected or not, can you please tell
me if you have *somewhere* in your MyHDL code, an intbv that can
have negative values?

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] 0.5dev3 testing

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

I had been using the following:

Signal(intbv(0,min=0,max=2))

to get a 1 bit register or wire.

With the development version I get a 2 bit signal. Is that intentional?

I thought the range should be min <= Num < max.

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

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,
> 
> 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] 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] 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

[myhdl-list] Re: Black box discussion

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

Tom Dillon wrote:
> OK, here is my start to a black box implementation discussion.

I was looking for something more general. See:

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

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 on decorators in MyHDL

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

Günter Dannoritzer wrote:

> Maybe it would be a good idea to add a page on the wiki about toVHDL and
> create a specification. Then Jan could guide, without having to do all
> the work.

Good idea. However, there are several open issues and I think it's
best to discuss/resolve them on the newsgroup first. I'm almost done
with a 0.5 feature (1-2 days) and after that, I'll organize my thoughts
to get this started in parallel.

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 on decorators in MyHDL

[David B. <dav...@fr...>]

I'd like to be involved into that project, although I don't think tha=
t=20
that I've done could be reused. I started writting a toVHDL but then =
I
didn't have time to work on it any more and I stopped in the middle o=
f
it. I'd rather start with something new, so I'll be watching the
progress of that project on the wiki.

Regards,

David.



G=FCnter Dannoritzer wrote:

>Tom Dillon wrote:
>...
> =20
>
>>One thought on VHDL support, we (and I'm sure there are others) wou=
ld
>>like to help write the toVHDL module. My problem is I don't know wh=
ere
>>to start or what really needs to be done. What could be used from
>>toVerilog and so on.
>>   =20
>>
>
>Maybe it would be a good idea to add a page on the wiki about toVHDL=
 and
>create a specification. Then Jan could guide, without having to do a=
ll
>the work.
>
> =20
>
>>Maybe we could figure out how to break the design up into some piec=
es
>>that a few of us could tackle to get toVHDL done?
>>
>>   =20
>>
>
>Actually in June of this year there was a post from David Brochart
>(subject: "Re: Opencores project") about his Opencores project. It s=
eems
>like that he started already with some toVHDL. Maybe he would like t=
o
>join into that too?
>
>Cheers
>
>Guenter
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. =
Download
>it for free - -and be entered to win a 42" plasma tv or your very ow=
n
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.ph=
p
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
> =20
>

Re: [myhdl-list] Re: Feedback request on decorators in MyHDL

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

Bedros,

Have not tried with ActiveHDL VHPI, only Riviera and VPI.

Tom


bedros wrote:

>Tom,
>
>are you successfully using MyHDL with aldecs VHPI? I'm
>using Aldec ActiveHDL and would like to use MyHDL with
>their VHPI interface.
>
>-Bedros
>
>--- Jan Decaluwe <ja...@ja...> wrote:
>
>  
>
>>Tom Dillon wrote:
>>    
>>
>>>Jan,
>>>
>>>We use Aldec Riviera with MyHDL. It works great.
>>>
>>>Also, Riviera supports VHPI.
>>>
>>>You can get an evaluation version of Riviera if
>>>      
>>>
>>that helps to get the 
>>    
>>
>>>VHDL support done.
>>>
>>>One thought on VHDL support, we (and I'm sure
>>>      
>>>
>>there are others) would 
>>    
>>
>>>like to help write the toVHDL module. My problem
>>>      
>>>
>>is I don't know where 
>>    
>>
>>>to start or what really needs to be done. What
>>>      
>>>
>>could be used from 
>>    
>>
>>>toVerilog and so on.
>>>
>>>Maybe we could figure out how to break the design
>>>      
>>>
>>up into some pieces 
>>    
>>
>>>that a few of us could tackle to get toVHDL done?
>>>
>>>Unfortunately (my opinion) VHDL is very popular in
>>>      
>>>
>>FPGA designs and I 
>>    
>>
>>>would say 75% of our clients either prefer or
>>>      
>>>
>>require we deliver VHDL.
>>
>>Really? I'm starting to like this FPGA market more
>>and more! What about
>>the international correlation (you know, the cliche
>>Europe=VHDL,
>>US=Verilog)?
>>
>>For the record, I like VHDL - in the past I have
>>co-builded a company
>>based on it. Fundamentally, MyHDL is mainly inspired
>>by VHDL - not
>>Verilog. I'm just disappointed with the way VHDL has
>>been (mal)treated
>>by major EDA vendors. So I'm happy to hear that it's
>>not dead.
>>
>>Of course, we all know that VHDL is rather
>>inflexible. So, there seems
>>to be large opportunity for MyHDL here: VHDL users
>>will recognize the
>>concepts, but get an unrivaled flexibility.
>>
>>On toVHDL: it seems about time that I dump my
>>current thoughts on
>>this, but I'll do that in another thread.
>>
>>Jan
>>
>>-- 
>>Jan Decaluwe - Resources bvba -
>>http://www.jandecaluwe.com
>>Losbergenlaan 16, B-3010 Leuven, Belgium
>>     Electronic design with Python:
>>     http://myhdl.jandecaluwe.com
>>
>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>SF.Net email is sponsored by:
>>Tame your development challenges with Apache's
>>Geronimo App Server. Download
>>it for free - -and be entered to win a 42" plasma tv
>>or your very own
>>Sony(tm)PSP.  Click here to play:
>>http://sourceforge.net/geronimo.php
>>_______________________________________________
>>myhdl-list mailing list
>>myh...@li...
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>  
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>myhdl-list mailing list
>myh...@li...
>https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>  
>

Re: [myhdl-list] Re: Feedback request on decorators in MyHDL

[bedros <be...@ya...>]

Tom,

are you successfully using MyHDL with aldecs VHPI? I'm
using Aldec ActiveHDL and would like to use MyHDL with
their VHPI interface. 

-Bedros

--- Jan Decaluwe <ja...@ja...> wrote:

> Tom Dillon wrote:
> > Jan,
> > 
> > We use Aldec Riviera with MyHDL. It works great.
> > 
> > Also, Riviera supports VHPI.
> > 
> > You can get an evaluation version of Riviera if
> that helps to get the 
> > VHDL support done.
> > 
> > One thought on VHDL support, we (and I'm sure
> there are others) would 
> > like to help write the toVHDL module. My problem
> is I don't know where 
> > to start or what really needs to be done. What
> could be used from 
> > toVerilog and so on.
> > 
> > Maybe we could figure out how to break the design
> up into some pieces 
> > that a few of us could tackle to get toVHDL done?
> > 
> > Unfortunately (my opinion) VHDL is very popular in
> FPGA designs and I 
> > would say 75% of our clients either prefer or
> require we deliver VHDL.
> 
> Really? I'm starting to like this FPGA market more
> and more! What about
> the international correlation (you know, the cliche
> Europe=VHDL,
> US=Verilog)?
> 
> For the record, I like VHDL - in the past I have
> co-builded a company
> based on it. Fundamentally, MyHDL is mainly inspired
> by VHDL - not
> Verilog. I'm just disappointed with the way VHDL has
> been (mal)treated
> by major EDA vendors. So I'm happy to hear that it's
> not dead.
> 
> Of course, we all know that VHDL is rather
> inflexible. So, there seems
> to be large opportunity for MyHDL here: VHDL users
> will recognize the
> concepts, but get an unrivaled flexibility.
> 
> On toVHDL: it seems about time that I dump my
> current thoughts on
> this, but I'll do that in another thread.
> 
> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba -
> http://www.jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>      Electronic design with Python:
>      http://myhdl.jandecaluwe.com
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's
> Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv
> or your very own
> Sony(tm)PSP.  Click here to play:
> http://sourceforge.net/geronimo.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

Re: [myhdl-list] Re: Feedback request on decorators in MyHDL

[<dan...@we...>]

Jan Decaluwe wrote:
...
> 
> Is VHPI actually used? By which simulator?
> 
...

I am adding a quote from the GHDL mailing list, as someone just asked a
question about the VPI/VHPI interface of GHDL there. Maybe this helps
getting a better idea about its status.

Cheers,

Guenter



GHDL mailing list post from today:

Subject: Re: VPI or VHPI

> Felix Bertram wrote:
>> GHDL's VPI support is very incomplete. It was implemented to  interface
>> GHDL with the IVI (Icarus Verilog Interactive) GUI  frontend- which
>> worked quite fine two years ago.
>> 
>> IVI implemented the following functionality:
>> - load a design
>> - select signals from the signal hierarchy
>> - view signal traces
>> - start simulation
>> - break simulation
>> - restart simulation
>> 
>> It did not implement single-stepping or source-breakpoints. Having a 
>> look at the IVI project should result in a few ideas on how to create  a
>> debugger frontend using VPI.
>> 
>> I am not sure, if the VPI stuff still works, as it is a long time  since
>> I last used it. GHDL has improved quite a bit, and maybe things  got
>> broken somewhere during this process. Improving GHDL's VPI  capabilities
>> would definitely be a major step. I believe there is  several people
>> around here willing to contribute to this, sure it  would be good to get
>> everybody together and coordinate the efforts a  bit. Christian?
>> Jean-Noel? Richard?
>> 
>> 
>> Best regards, Felix
>> 

[myhdl-list] Re: Feedback request on decorators in MyHDL

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

Tom Dillon wrote:
> Jan,
> 
> We use Aldec Riviera with MyHDL. It works great.
> 
> Also, Riviera supports VHPI.
> 
> You can get an evaluation version of Riviera if that helps to get the 
> VHDL support done.
> 
> One thought on VHDL support, we (and I'm sure there are others) would 
> like to help write the toVHDL module. My problem is I don't know where 
> to start or what really needs to be done. What could be used from 
> toVerilog and so on.
> 
> Maybe we could figure out how to break the design up into some pieces 
> that a few of us could tackle to get toVHDL done?
> 
> Unfortunately (my opinion) VHDL is very popular in FPGA designs and I 
> would say 75% of our clients either prefer or require we deliver VHDL.

Really? I'm starting to like this FPGA market more and more! What about
the international correlation (you know, the cliche Europe=VHDL,
US=Verilog)?

For the record, I like VHDL - in the past I have co-builded a company
based on it. Fundamentally, MyHDL is mainly inspired by VHDL - not
Verilog. I'm just disappointed with the way VHDL has been (mal)treated
by major EDA vendors. So I'm happy to hear that it's not dead.

Of course, we all know that VHDL is rather inflexible. So, there seems
to be large opportunity for MyHDL here: VHDL users will recognize the
concepts, but get an unrivaled flexibility.

On toVHDL: it seems about time that I dump my current thoughts on
this, but I'll do that in another thread.

Jan

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