myhdl-list — Mailing list for discussions on MyHDL

[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

[myhdl-list] Added my project to the wiki

[George P. <ge...@ga...>]

It's in http://myhdl.jandecaluwe.com/doku.php/projects

--=20
George Pantazopoulos
http://www.gammaburst.net

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

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

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

I have just been looking into the features of GHDL under:

	http://ghdl.free.fr/features.html

At the bottom of the page it talks about some VPI/VHPI features. I am
not that experienced to judge whether that is sufficient or not?

Maybe that is a starting point?

To add to my suggestion about a toVHDL page on the wiki, maybe a first
step would be to specify what functions of a VHPI interface are needed
in order to search for a suitable simulator or evaluated what is missing
with existing open source simulators?

Are there actually any other VHDL simulators, other than GHDL?

Cheers,

Guenter

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

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

Tom Dillon wrote:
...
> 
> 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 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.

> 
> 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?
> 

Actually in June of this year there was a post from David Brochart
(subject: "Re: Opencores project") about his Opencores project. It seems
like that he started already with some toVHDL. Maybe he would like to
join into that too?

Cheers

Guenter

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

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

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.

Tom




Jan Decaluwe wrote:

> bedros wrote:
>
>> great work Jan, I've not touched Myhdl in over a year,
>> and I'm very impressed with how you use decorators in
>> MyHDL. it makes Myhdl very similar to a real RTL.
>>
>> ease of use is very important to attract developers,
>> and it seems you're going in the right direction.
>>
>> what's holding me back from using it is the fact that
>> I  can't integrate it with VHDL code. What's the
>> status of VHPI interface?
>
>
> Not even thought about it :-)
>
> Is VHPI actually used? By which simulator?
>
> At some point I considered to do a modelsim interface
> in their proprietary interface, because I thought that
> was the most popular C-interface. But for various reasons
> (such as changing MyHDL priorities), I haven't started this.
> Also, I fear there might be legal issues if I develop
> something in a proprietary API without even owning
> a modelsim license.
>
> In Verilog, I have at least 2 options to develop a vpi
> interface with an open source simulator. I still don't know about
> an open-source VHDL solution with a vpi-like support.
> Without that, it's going to be hard. Moreover, one could
> argue that this means that the need is just not there.
>
>> Any updates on simulators for myhdl?
>
>
> I used cver and Icarus, and I know people are using
> Modelsim Verilog also.
>
> Regards, Jan
>
>