myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Function calls in combinatorial blocks

[Christopher F. <chr...@gm...>]

On 3/1/2013 9:12 AM, Per Karlsson wrote:
> Hi!
> Is there a particular reason that we do not support function calls in
> combinatorial blocks?
>

I don't know if there is a reason, my guess is
not.  But it is currently *not* supported.  To
have the feature added it is ideal to create a
MEP describing the feature.  Can simply start
by describing the enhancement request to the
mailing-list.

My opinion, there are two levels: modeling and
conversion.  In some cases we might want to take
baby steps to implement, first just add for modeling
and then for conversion.

Regards,
Chris

[myhdl-list] Function calls in combinatorial blocks

[Per K. <bas...@gm...>]

Hi!
Is there a particular reason that we do not support function calls in
combinatorial blocks?

In 0.7 I get:
  File "[...]_analyze.py", line 165, in _analyzeGens
    _isMem(obj) or _isTupleOfInts(obj)

In 0.8dev I get:
  File "[...]_analyze.py", line 168, in _analyzeGens
    raise ConversionError(_error.UnsupportedType, n, info)
myhdl.ConversionError: File file.py, line 11: Object type is not supported
in this context: f

Here is a test snippet:
#########################
from myhdl import *

def w(a, b, c, clk):
    def f(a):
        out = intbv(0)[len(a):]
        if a<3:
            out[:] = a
        else:
            out[:] = 0
        return out

    @always_comb
    def cm():
        b.next = a

    @always(clk.posedge)
    def ck():
        c.next = f(a)

    return instances()

def test():
    a = Signal(intbv(0)[10:])
    b = Signal(intbv(0)[10:])
    c = Signal(intbv(0)[10:])
    clk = Signal(bool(0))
    dut = toVerilog(w, a, b,c ,clk)
    return instances()

s = Simulation(test())
s.run()
##########################

-Cheers!
/Per

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 02/26/2013 10:52 PM, Per Karlsson wrote:
> Hi guys! I'm just back from vacation. It seems to me that Jan and I
> should both try to keep a little cooler than we are used to when
> we're in the same discussion. I remember no "big" words from my
> keyboard, but I shall try to keep them smaller still. :D

I don't like it if something which is clearly a feature is
described as either an error or an annoyance. And I certainly
don't like it if such an analysis is based on the
"think hardware" conventional wisdom, which is my enemy in
HDL design and which is why I am actually developing MyHDL.

> So, first a little background: Yes, guilty as charged, I am mostly a
> Verilog person. I've spent only a few years with VHDL, and the rest
> of the time with Verilog. Therefore I am quite biased.
>
> I think VHDL is chatty, and for me it's harder to think about
> hardware in VHDL than in Verilog; and I always think about hardware
> when I design RTL. For me RTL is not programming, it is a way to
> describe hardware.

I am tired of such statements. Invariably, they are used as an excuse
for not learning the language in its full expressiveness, and for
ignoring the valuable lessons from software engineering.

> That said I'm very happy that I found MyHdl, because it allows me to
> write hardware in the leaf-cells, but I can use actual programming to
> build up the system from the basic blocks and in the testbenches.
>
> Normally I would either build Verilog from strings in Perl, or riddle
> my Verilog with code-words and then run it through a Perl
> pre-processor (depending on the needs of a particular design). MyHdl
> allows me to stay in the same language and use Verilog as a netlist
> format. I'm quite pleased with the design and test environments I
> have set up using MyHdl, and they are going to get really nice when
> MEP108 is implemented!
>
> Now, on topic: So, Jan, you are saying that we should never write
> hardware where a combinatorial calculation takes more than one delta
> cycle?

No I don't say that. I don't like words like "never" or "always" -
delta cycles have their role.

What I am saying is that the systematic usage of delta cycles and
events as an implicit way to order a sequence of calculations is
a bad idea, given that the language has many provisions to do
so directly, explicitly and locally, without events and delta cycles.

I personally don't see how that is possible,

Really? Well, my designs typically use close to 0 delta cycles. I may use
some combinatorial logic to condition some inputs/outputs, but
that's basically it. Everything is basically done in clocked processes.
BTW - that's much closer to the original meaning of RTL -
Register Transfer Level. True RTL languages don't have events,
delta cycles, or explicit combinatorioal logic.

> but I have some
> respect for the amount of thinking that you have done in this area so
> I am open to the possibility that you will convince me otherwise.

I am not trying to "convince" anyone - everything is provided
for free here so one should convince oneself, or not.

All I'm doing is pointing out misunderstandings and managing
(possibly false) expectations for efficiency reasons. Noone
should lose time unnecessarily.

> It may be my hardware background fooling me (I started out as a
> rectangle pusher), but for me glitches in combinatorial nets are near
> unavoidable.

Of course not.

> You can of course balance all the paths to make the
> logic glitch-free, but its hardly worth the hassle unless you are
> designing clock gating or a reset signal.
>
> This is not to say, of course, that the language has to mimic the
> ripple behavior of physical hardware to be of any use.

That is the point. In synchronous design, that ripple behavior
is irrelevant.

> But still,
> when sub-blocks or IPs have combinatorial inputs and outputs, or when
> there is a combinatorial path through a block I don't see how it is
> avoidable.

All IP blocks should have registered outputs. This is just a matter
of complexity management: localization of concerns.

> You shouldn't take my rant about partitioning design too seriously, I
> usually go a bit overboard when I try to prove a point. Certainly a
> single process is best in a self-contained system with few
> dependencies

Dependencies are not a given, but something that you can
manage and that should be minimized when partitioning a design.

but it is really the only way?

No. It's only the way I prefer.

>
> On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>
> On 02/26/2013 08:02 PM, Christopher Felton wrote:
>> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
>>> Chris:
>>>
>>> We are overthinking this. Forget about delta cycles,
>>> combinatorial logic and race conditions.
>>
>> Fair enough.
>>
>>>
>>> What we have is a language that hopefully tries to help us to
>>> write better, clearer code.
>>>
>>> A signal assignment is an assignment also (albeit to a future
>>> value which may or may not be overwritten.) When a designer
>>> specifies explicitly that a variable/signal should *always* be
>>> within a range that he specifies, it is a good thing that the
>>> language flags a violation immediately. The fact that signals
>>> have complex postponed behavior is a secondary issue.
>>>
>>> What disturbs me a little in this discussion is the Verilog
>>> angle. I think it is rather clear that VHDL is my reference for
>>> "good design" (and Verilog for "very bad design"). No?
>>
>> It was inadvertent.  It was not the goal to imply myhdl should
>> behave like Verilog.  The oversight was --as you identified-- not
>> jumping to the VHDL example using a similar type, that is: the
>> constraint integer.
>
> Chris - I was not targetting you in any way. I fully understand how
> you try to be helpful and open to arguments.
>
> I referred to the OP (Mr. Karlsson). Yes, I have a problem with
> people who, after looking at MyHDL superficially from just one angle
> (Verilog), immediately start using big words and declarations just
> because it doesn't look exactly like what they are used to.
>
> Moreover - because of Verilog's bad design choices (e.g. not making a
> difference between signals/variables) what many Verilog designers are
> used to as a coding style is equally bad. Using that as the norm is
> just too crazy for words to me.
>
> All of this is of course just my personal opinion - but I made it
> abundantly clear on many occasions. Quite obviously, MyHDL is my
> attempt to offer a sensible Verilog alternative to those that share
> this analysis.
>
>> I am in agreement but I may beat on this topic some more, purely so
>> that I have a consistent and concise understanding for future
>> communications.
>
> No problem. For example: it is *definitely* a problem when an
> "invalid" value sneaks through delta cycle. A signal monitor has no
> way to know where it is in delta cycle convergence process.
> Therefore, it could take seemingly "impossible" decisions based on
> that invalid value.
>
> (I am not talking about hardware here, but about the language as it
> may be used in models and test benches. The inclination to interprete
> everything in a hardware sense is another sign of a bad
> methodology.)
>
> -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python
> as a HDL: http://www.myhdl.org VHDL development, the modern way:
> http://www.sigasi.com World-class digital design:
> http://www.easics.com
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

[myhdl-list] ResetSignal.pulse() proposal

[Christopher F. <chr...@gm...>]

I understand this may not be considered until 0.9dev.

Since we have the /ResetSignal/ type I think it would
be useful to add a /pulse/ function.  This function would
be for simulation only and would handle the *toggling*
of the reset, example:

     reset = ResetSignal(0, active=0, async=True)
     ...
     @instance
     def tb_stimulus():
         yield reset.pulse(10)

Couple reasons why I think this would be useful.  One
it simplifies the test code, we have a /ResetSignal/
object might as well have additional simulation utility.

Two, the /@always_seq/ and /ResetSignal/ allow a user
to arbitrarily modify the reset type.  If they do this
they have to go change the simulation code, manually
modify the stimulus.  The /pulse/ function will
automatically reflect the /active/ parameter (possibly
the /async/ also).

I was thinking it would be something like:

     reset = ResetSignal(0, active=0, async=False)
     # ...
     yield reset.pulse(10)
     # reset.next = False
     # yield delay(10)
     # reset.next = True

     yield reset.pulse(10, 9)
     # reset.next = False
     # yield delay(10)
     # reset.next = True
     # yield delay(9)

     yield reset.pulse(8, 10, 9)
     # yield delay(8)
     # reset.next = False
     # yield delay(10)
     # reset.next = True
     # yield delay(9)

Or it might be better to have a single argument /pulse(waits)/
and have it be a tuple, then it signifies the values are
related?  /pulse((8,10,9)/.  I can supply a patch if we
think this is a worthwhile addition.

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 24.02.2013 21:51, schrieb Jan Decaluwe:
> On 01/17/2013 11:23 PM, Thomas Heller wrote:
>> Am 17.01.2013 17:26, schrieb Tom Dillon:
>>> Hi,
>>>
>>> This is interesting but I don't think it would be a bug. I am not sure
>>> the MyHDL specs call for automatic size conversions.
>>
>> I'd say it is a bug, because the generated VHDL code behaves differently
>> than the MyHDL simulation.
>
> That is correct - no excuses. If the conversion succeeds, the VHDL
> should be have as the VHDL, otherwise it's a bug.
>
> Of course, this doesn't mean that it would be easy to fix :-)
>
> However, I think the issue you reported is fixed now in development.

Thanks, Jan, for confirming that my understanding of MyHDL is correct.
And thanks for fixing the problem of course.  I'll try it out when I get
back to my project again.

Thomas

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Christopher F. <chr...@gm...>]

<snip>
>
> Normally I would either build Verilog from strings in Perl, or riddle my
> Verilog with code-words and then run it through a Perl pre-processor
> (depending on the needs of a particular design). MyHdl allows me to stay
> in the same language and use Verilog as a netlist format.
> I'm quite pleased with the design and test environments I have set up
> using MyHdl, and they are going to get really nice when MEP108 is
> implemented!

MEP108 (conversion top-level class methods) is implemented in
0.8dev.

http://www.myhdl.org/doku.php/meps:mep-108

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Per K. <bas...@gm...>]

Hi guys!
I'm just back from vacation. It seems to me that Jan and I should both try
to keep a little cooler than we are used to when we're in the same
discussion. I remember no "big" words from my keyboard, but I shall try to
keep them smaller still. :D

So, first a little background: Yes, guilty as charged, I am mostly a
Verilog person. I've spent only a few years with VHDL, and the rest of the
time with Verilog. Therefore I am quite biased.

I think VHDL is chatty, and for me it's harder to think about hardware in
VHDL than in Verilog; and I always think about hardware when I design RTL.
For me RTL is not programming, it is a way to describe hardware.

That said I'm very happy that I found MyHdl, because it allows me to write
hardware in the leaf-cells, but I can use actual programming to build up
the system from the basic blocks and in the testbenches.

Normally I would either build Verilog from strings in Perl, or riddle my
Verilog with code-words and then run it through a Perl pre-processor
(depending on the needs of a particular design). MyHdl allows me to stay in
the same language and use Verilog as a netlist format.
I'm quite pleased with the design and test environments I have set up using
MyHdl, and they are going to get really nice when MEP108 is implemented!

Now, on topic: So, Jan, you are saying that we should never write hardware
where a combinatorial calculation takes more than one delta cycle?
I personally don't see how that is possible, but I have some respect for
the amount of thinking that you have done in this area so I am open to the
possibility that you will convince me otherwise.

It may be my hardware background fooling me (I started out as a rectangle
pusher), but for me glitches in combinatorial nets are near unavoidable.
You can of course balance all the paths to make the logic glitch-free, but
its hardly worth the hassle unless you are designing clock gating or a
reset signal.

This is not to say, of course, that the language has to mimic the
ripple behavior of physical hardware to be of any use. But still, when
sub-blocks or IPs have combinatorial inputs and outputs, or when there is a
combinatorial path through a block I don't see how it is avoidable.

You shouldn't take my rant about partitioning design too seriously, I
usually go a bit overboard when I try to prove a point. Certainly a single
process is best in a self-contained system with few dependencies, but it is
really the only way?

Humble greetings in small words
/Per




On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 02/26/2013 08:02 PM, Christopher Felton wrote:
> > On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> >> Chris:
> >>
> >> We are overthinking this. Forget about delta cycles,
> >> combinatorial logic and race conditions.
> >
> > Fair enough.
> >
> >>
> >> What we have is a language that hopefully tries to
> >> help us to write better, clearer code.
> >>
> >> A signal assignment is an assignment also (albeit
> >> to a future value which may or may not be overwritten.)
> >> When a designer specifies explicitly that a variable/signal
> >> should *always* be within a range that he specifies,
> >> it is a good thing that the language flags a
> >> violation immediately. The fact that signals have
> >> complex postponed behavior is a secondary issue.
> >>
> >> What disturbs me a little in this discussion is the
> >> Verilog angle. I think it is rather clear that
> >> VHDL is my reference for "good design" (and Verilog
> >> for "very bad design"). No?
> >
> > It was inadvertent.  It was not the goal to imply myhdl
> > should behave like Verilog.  The oversight was --as you
> > identified-- not jumping to the VHDL example using a similar
> > type, that is: the constraint integer.
>
> Chris - I was not targetting you in any way. I fully
> understand how you try to be helpful and open to
> arguments.
>
> I referred to the OP (Mr. Karlsson). Yes, I have a
> problem with people who, after looking at MyHDL superficially
> from just one angle (Verilog), immediately start
> using big words and declarations just because it doesn't
> look exactly like what they are used to.
>
> Moreover - because of Verilog's bad design choices
> (e.g. not making a difference between signals/variables)
> what many Verilog designers are used to as a coding style
> is equally bad. Using that as the norm is just too
> crazy for words to me.
>
> All of this is of course just my personal opinion - but I
> made it abundantly clear on many occasions. Quite obviously,
> MyHDL is my attempt to offer a sensible Verilog alternative
> to those that share this analysis.
>
> > I am in agreement but I may beat on this topic some more,
> > purely so that I have a consistent and concise understanding
> > for future communications.
>
> No problem. For example: it is *definitely* a problem when
> an "invalid" value sneaks through delta cycle. A signal
> monitor has no way to know where it is in delta cycle
> convergence process. Therefore, it could take seemingly
> "impossible" decisions based on that invalid value.
>
> (I am not talking about hardware here, but about the language
> as it may be used in models and test benches. The inclination
> to interprete everything in a hardware sense is another
> sign of a bad methodology.)
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>      Python as a HDL: http://www.myhdl.org
>      VHDL development, the modern way: http://www.sigasi.com
>      World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 02/26/2013 08:02 PM, Christopher Felton wrote:
> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
>> Chris:
>>
>> We are overthinking this. Forget about delta cycles,
>> combinatorial logic and race conditions.
>
> Fair enough.
>
>>
>> What we have is a language that hopefully tries to
>> help us to write better, clearer code.
>>
>> A signal assignment is an assignment also (albeit
>> to a future value which may or may not be overwritten.)
>> When a designer specifies explicitly that a variable/signal
>> should *always* be within a range that he specifies,
>> it is a good thing that the language flags a
>> violation immediately. The fact that signals have
>> complex postponed behavior is a secondary issue.
>>
>> What disturbs me a little in this discussion is the
>> Verilog angle. I think it is rather clear that
>> VHDL is my reference for "good design" (and Verilog
>> for "very bad design"). No?
>
> It was inadvertent.  It was not the goal to imply myhdl
> should behave like Verilog.  The oversight was --as you
> identified-- not jumping to the VHDL example using a similar
> type, that is: the constraint integer.

Chris - I was not targetting you in any way. I fully
understand how you try to be helpful and open to
arguments.

I referred to the OP (Mr. Karlsson). Yes, I have a
problem with people who, after looking at MyHDL superficially
from just one angle (Verilog), immediately start
using big words and declarations just because it doesn't
look exactly like what they are used to.

Moreover - because of Verilog's bad design choices
(e.g. not making a difference between signals/variables)
what many Verilog designers are used to as a coding style
is equally bad. Using that as the norm is just too
crazy for words to me.

All of this is of course just my personal opinion - but I
made it abundantly clear on many occasions. Quite obviously,
MyHDL is my attempt to offer a sensible Verilog alternative
to those that share this analysis.

> I am in agreement but I may beat on this topic some more,
> purely so that I have a consistent and concise understanding
> for future communications.

No problem. For example: it is *definitely* a problem when
an "invalid" value sneaks through delta cycle. A signal
monitor has no way to know where it is in delta cycle
convergence process. Therefore, it could take seemingly
"impossible" decisions based on that invalid value.

(I am not talking about hardware here, but about the language
as it may be used in models and test benches. The inclination
to interprete everything in a hardware sense is another
sign of a bad methodology.)

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Christopher F. <chr...@gm...>]

On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
> Chris:
>
> We are overthinking this. Forget about delta cycles,
> combinatorial logic and race conditions.

Fair enough.

>
> What we have is a language that hopefully tries to
> help us to write better, clearer code.
>
> A signal assignment is an assignment also (albeit
> to a future value which may or may not be overwritten.)
> When a designer specifies explicitly that a variable/signal
> should *always* be within a range that he specifies,
> it is a good thing that the language flags a
> violation immediately. The fact that signals have
> complex postponed behavior is a secondary issue.
>
> What disturbs me a little in this discussion is the
> Verilog angle. I think it is rather clear that
> VHDL is my reference for "good design" (and Verilog
> for "very bad design"). No?

It was inadvertent.  It was not the goal to imply myhdl
should behave like Verilog.  The oversight was --as you
identified-- not jumping to the VHDL example using a similar
type, that is: the constraint integer.

I am in agreement but I may beat on this topic some more,
purely so that I have a consistent and concise understanding
for future communications.

Regards,
Chris

Re: [myhdl-list] Synopsis of reported issues

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

On 02/25/2013 03:47 AM, Christopher Felton wrote:
>
> Absolutely, there were a couple issues that prevented me
> from achieving this:
>
> 1. Currently, on my system with my version of GHDL
>      conversion.analyze and conversion.verify does not
>      work (0.7 and 0.8dev).  None of the VHDL conversion
>      unit tests run successfully.  I have not investigated
>      this but randomly noticed I had to remove the *_ghdl
>      from the output name (-o %(*)s_ghdl).

I understand - the setup can be rather tricky.

What you could do is just provide a (convertible) stand-alone
test that prints out (using print) the values that differ
between MyHDL and converted VHDL. I can use that with
my compile.verify function directly for an automatic test.

See the file attached to bug #39 for an example.

Thanks for the great support work - it really is a great help.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

Chris:

We are overthinking this. Forget about delta cycles,
combinatorial logic and race conditions.

What we have is a language that hopefully tries to
help us to write better, clearer code.

A signal assignment is an assignment also (albeit
to a future value which may or may not be overwritten.)
When a designer specifies explicitly that a variable/signal
should *always* be within a range that he specifies,
it is a good thing that the language flags a
violation immediately. The fact that signals have
complex postponed behavior is a secondary issue.

What disturbs me a little in this discussion is the
Verilog angle. I think it is rather clear that
VHDL is my reference for "good design" (and Verilog
for "very bad design"). No?

Consider the following trivial VHDL:

--
entity test is
end entity test;

architecture beh of test is

signal a: integer range 0 to 7;

begin

process is
begin
     a <= 8; -- illegal assignment
     a <= 7;
     wait;
end process;

end beh;
--

Modelsim even gives a *compile-time* error here onthe
first assignment, though it is clear that it will
never define the eventual value.

Jan


On 02/25/2013 04:48 PM, Christopher Felton wrote:
> On 2/25/2013 9:22 AM, Jan Decaluwe wrote:
>> On 01/28/2013 04:06 PM, Christopher Felton wrote:
>>> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>>>> Hi!
>>>> Over the weekend I have come to the conclusion that it is an error.
>>
>> I don't get this. Here, MyHDL tries to check dubious code a soon as
>> possible (like VHDL). This prevents you from writing convoluted code
>> that require you to play delta cycle games to see whether or not
>> a value is in the range it is supposed to be.
>>
>> That is a good thing, and the intention.
>>
>
> When we were discussing this, the point that got
> my attention was:  "where would you insert the
> assertion" if it was not build into the /intbv/.
>
> The example provided was someone implementing
> a gating operation.  The gate signal occurs at
> the same time as the out of bound value.  Yes,
> the out of bounds (OOB) is detected ASAP but the
> designers intent was to have the OOB gated (blocked).
>
>       @always_comb
>       def hdl():
>          if block_oob:
>             downstream.next = oob_truncation
>          else:
>             downstream.next = upstream
>
> In this example the designers intent is to prevent
> the OOB on the downstream, assuming the upstream
> has greater range, the /block_oob/ was generate by
> some other logic (OP's example was third party IP).
>
> Are we saying, that generating a combinatorial
> selection like this should be avoided because it
> is a race-condition and you can't prevent /downstream/
> from talking on the OOB value, simulation or physical?
>
> Obviously changing the above to:
>
>      @always_seq(clock.posedge, reset=reset)
>      def hdl():
>         if block_oob:
>            downstream.next = oob_truncation
>         else:
>            downstream.next = upstream
>
> will fix the issue.
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Christopher F. <chr...@gm...>]

On 2/25/2013 9:22 AM, Jan Decaluwe wrote:
> On 01/28/2013 04:06 PM, Christopher Felton wrote:
>> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>>> Hi!
>>> Over the weekend I have come to the conclusion that it is an error.
>
> I don't get this. Here, MyHDL tries to check dubious code a soon as
> possible (like VHDL). This prevents you from writing convoluted code
> that require you to play delta cycle games to see whether or not
> a value is in the range it is supposed to be.
>
> That is a good thing, and the intention.
>

When we were discussing this, the point that got
my attention was:  "where would you insert the
assertion" if it was not build into the /intbv/.

The example provided was someone implementing
a gating operation.  The gate signal occurs at
the same time as the out of bound value.  Yes,
the out of bounds (OOB) is detected ASAP but the
designers intent was to have the OOB gated (blocked).

     @always_comb
     def hdl():
        if block_oob:
           downstream.next = oob_truncation
        else:
           downstream.next = upstream

In this example the designers intent is to prevent
the OOB on the downstream, assuming the upstream
has greater range, the /block_oob/ was generate by
some other logic (OP's example was third party IP).

Are we saying, that generating a combinatorial
selection like this should be avoided because it
is a race-condition and you can't prevent /downstream/
from talking on the OOB value, simulation or physical?

Obviously changing the above to:

    @always_seq(clock.posedge, reset=reset)
    def hdl():
       if block_oob:
          downstream.next = oob_truncation
       else:
          downstream.next = upstream

will fix the issue.

Regards,
Chris

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/29/2013 03:06 PM, Per Karlsson wrote:
> Hm, that would enforce a coding style where every combinatorial cloud
> must be written monolithically. You could never break down a
> combinatorial problem into parts.
>
> I think this is a bad coding style. It makes for unreadable code, and
> it limits the amount of complexity that can be tackled successfully.

Come on, it's really the other way around. *Of course* it is better
to limit a combinatorial block to a single delta cycle, and possibly
use local variables for intermediate steps, instead of doing
everything with signals and a myrad of concatenated combinatorial blocks.




-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/29/2013 01:21 PM, Per Karlsson wrote:
> OK, the range check is essentially an assertion. Now, you wouldn't put an assertion in a combinatorical block, would you?

Of course I would. Why not?


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/28/2013 05:01 PM, Per Karlsson wrote:
> Hm. Let's say the flag computation is something a lot more complex,
> and the flag is used in a lot of places. Then the verilog is going to
> be more compact, easier to maintain and less error prone.

Of course not. It's going be convoluted and require playing delta
cycle games to understand what happens.

> Why then would we want myhdl?

MyHDL is for those who understand that Verilog's extreme
permissevess is evil.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

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

On 01/28/2013 04:06 PM, Christopher Felton wrote:
> On 1/28/2013 5:54 AM, Per Karlsson wrote:
>> Hi!
>> Over the weekend I have come to the conclusion that it is an error.

I don't get this. Here, MyHDL tries to check dubious code a soon as
possible (like VHDL). This prevents you from writing convoluted code
that require you to play delta cycle games to see whether or not
a value is in the range it is supposed to be.

That is a good thing, and the intention.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Synopsis of reported issues

[Christopher F. <chr...@gm...>]

On 2/24/13 2:47 PM, Jan Decaluwe wrote:
> Chris:
>
> Thanks for the work to summarize all this.
>
> I am definitely using the SourceForge bug tracker to keep
> track of things.
>
> What is most useful for fixing is to enter a bug report with a
> stanalone testcase. For conversion issues, the easiest
> is to use conversion.analyze or conversion.verify, which
> automatically compares MyHDL and generated Verilog/VHDL.

Absolutely, there were a couple issues that prevented me
from achieving this:

1. Currently, on my system with my version of GHDL
    conversion.analyze and conversion.verify does not
    work (0.7 and 0.8dev).  None of the VHDL conversion
    unit tests run successfully.  I have not investigated
    this but randomly noticed I had to remove the *_ghdl
    from the output name (-o %(*)s_ghdl).

2. I was triaging multiple issues and some required
    more than just the analyze and elaborate.  They
    needed to verify VHDL match the MyHDL behavior,
    currently this is more difficult with VHDL than
    Verilog.

Lastly, I ran out of time.  I had to make a decision
to create a ticket for the two issues I felt confident
were bugs, with what I had.

>
> I have solved issue 4 based on Thomas Hellers' example.
> I have used his example and entered it as bug #39 in the
> bug tracker. See the attached file for the test case - this
> will directly be used as a MyHDL unit test.
>
> /Probably/ this is the same as bug #38 that you created,
> however the provided test case didn't fail as indicated.
> I notice that you have other test cases - could you check
> whether the issue is solved and mark the bug as closed-fixed also,
> if so?

Yes, I did a poor job with issue #38 description, sorry about
that.

I did get your latest changes and my tests do not fail (i.e.
they pass).  I will change the ticket to "closed", as soon as
I figure out how to do so :)

Regards,
Chris

>
>
> On 02/02/2013 05:32 AM, Christopher Felton wrote:
>> Ok, there have been a burst of issues reported in the last couple
>> weeks.  I am trying to keep track of them, understand them,
>> and determine how severe the issues might be and possible
>> corrections.  All with the hope, to provide a clear definition
>> of the issues and help move things along.  Jan D. will have the
>> final say on all the issues.  There were two general simulation
>> and modeling issues and the rest were VHDL conversion failures.
>>
>>       1. Mixing /bool/ and /intbv/.  This is a new issues in
>>          0.8dev.  This may simply be a mid-feature collision?  The
>>          fix, I believe makes sense, is to cast (is that the correct
>>          Python terminology) the /val/ in /_SetNextBool/ to a
>>          /bool/ and to an /int/ in /_SetNextInt/.  This will
>>          prevent the /Signal/ type (/val/) from changing.
>>
>>          I can submit a patch for these changes but I will wait
>>          to see if the 0.8dev changes are in a final form [1].
>>
>>
>>       2. The "bound check race condition".  This is the error that
>>          arises from an /intbv/ bound check on a delta cycle,
>>          essentially an *assertion*.  Complex descriptions might
>>          have invalid delta cycle values (everything cannot be
>>          updated simultaneous).  Per K., which I agree, correctly
>>          identified that the bound check should be deferred to the
>>          end of the simulation step (after all delta-cycles).
>>
>>          I have some ideas (I am sure Jan D. has the solution :) )
>>          and I can proposed an enhancement in a seprate thread, it
>>          could get involved.
>>
>>       3. The following fails in VHDL conversion:
>>          x = Signal(intbv(0, min=0, max=8))
>>          y = Signal(intbv(0, min=0, max=8))
>>          z = Signal(bool(0))
>>
>>          @always ...
>>              z.next = x[0] * y[0]
>>
>>          The bit-operation "castings" might need some looking at?
>>          The tests could use some updating to cover lots of these
>>          cases.
>>
>>       4. More than two right hand side operands fail VHDL
>>          conversion if the operands are mixed sizes:
>>             ...
>>             z.next = a + b + c
>>
>>          Thomas Heller, pointed out this issue and reinforced that
>>          MyHDL has the design goal to handle the sizing and typing.
>>
>>       5. Possible enhancment, VHDL conversion fails for an edge
>>          sensitive conditional for the following cases:
>>          It was indicated the following (at least 2) worked in
>>          previous versions.  Need to verify this and determine
>>          what might changed for edge sensitive conditionals.
>>             2. if sig == False
>>             3. if sig == intbv(0)
>>
>>          And I am not convinced that /if not sig/ should not be
>>          supported.  It is acceptable (as shown in the mailing
>>          list) for non edge sensitve signals.  Why the limitation
>>          for edge sensitive signals in VHDL conversion.
>>
>>       6. Older issue that was identified as a bug, for modeling
>>          only, attributes fail to be added to the sensitivty list
>>          in /always_comb/ generators.
>>
>>
>> I have tests for all of these in a bitbucket repo [2].
>>
>> Thanks to everyone for reporting the issues and being patient
>> as we figure them out.  I was mistaken, it looks like Jan D.
>> has been actively using the sourceforge tracking [3] so I will
>> start adding the above to the bug list.
>>
>> Regards,
>> Chris
>>
>> [1]
>> https://bitbucket.org/cfelton/myhdl_dev/src/tip/myhdl/_Signal.py?at=0.8-dev#cl-260
>>
>> [2] https://bitbucket.org/cfelton/myhdl_tests
>>
>> [3] http://sourceforge.net/tracker/?atid=596332&group_id=91207&func=browse
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_jan
>>
>
>

Re: [myhdl-list] Bug in generated code?

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

On 02/24/2013 09:51 PM, Jan Decaluwe wrote:
> On 01/17/2013 11:23 PM, Thomas Heller wrote:
>> Am 17.01.2013 17:26, schrieb Tom Dillon:
>>> Hi,
>>>
>>> This is interesting but I don't think it would be a bug. I am not sure
>>> the MyHDL specs call for automatic size conversions.
>>
>> I'd say it is a bug, because the generated VHDL code behaves differently
>> than the MyHDL simulation.
>
> That is correct - no excuses. If the conversion succeeds, the VHDL
> should be have as the VHDL

Of course, I meant that the VHDL should behave like the MyHDL :-)


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] AttributeError in 0.8-dev but not in 0.7

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

On 01/24/2013 03:39 PM, Per Karlsson wrote:
> Yes, I think you're right! It is mixing intbv[1:0] and bool that
> causes it.
>
> If that is to be forbidden, there needs to be an assert as soon as
> possible. But I don't see why we should disallow it. The reason I
> didn't see it sooner was that the bool and the intbv were
> instantiated in separate modules. And unless we ban one-bit intbvs or
> bools outright

I don't see what you mean here. You could just use intbv[0] to
assign to a boolean Signal.

  I don't see how that sort of thing can be avoided. One
> hardware designer's bool is another's one bit integer. :) /Per

We are talking about intbv versus bool. Intbv also has a "bit-vector"
meaning. To me, a bit-vector with a width 1 is just a degenerated
vector, not the same as a single bit variable/signal. In VHDL it is
also like that - therefore if we start changing this there will be
all kinds of tricky issues after conversion.

For single bit variables/Signal, the idiomatic MyHDL way is bool,
not intbv[1:0], which looks like a user error to me.
I agree that there is should be a direct error check to prevent assigning
an intbv[1:0] to a bool Signal however, so that the issue if
flagged early on.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Bug in generated code?

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

On 01/17/2013 11:23 PM, Thomas Heller wrote:
> Am 17.01.2013 17:26, schrieb Tom Dillon:
>> Hi,
>>
>> This is interesting but I don't think it would be a bug. I am not sure
>> the MyHDL specs call for automatic size conversions.
>
> I'd say it is a bug, because the generated VHDL code behaves differently
> than the MyHDL simulation.

That is correct - no excuses. If the conversion succeeds, the VHDL
should be have as the VHDL, otherwise it's a bug.

Of course, this doesn't mean that it would be easy to fix :-)

However, I think the issue you reported is fixed now in development.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Status update

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

Any new features/feature request will have to wait until 0.8
is released - as it has been heavily used already all I will do for
that is fix obvious bugs and complete the documentation.

On 11/07/2012 11:31 AM, Angel Ezquerra wrote:
> On Wed, Nov 7, 2012 at 10:16 AM, Jan Decaluwe <ja...@ja...> wrote:
>> Hello:
>>
>> I haven't been able to track all recent activity here for two reasons.
>>
>> First, in the past months I have been working intensively on a very
>> interesting design project (also involving MyHDL).
>>
>> Second, I have not yet given up on APP :-) and I have given it
>> a lot of attention.
>>
>> The project has been taped-out now. I'm preparing for a new one
>> (also involving MyHDL) but there will be some time left to make
>> progress on MyHDL itself. I will start by catching up with the
>> posts here.
>>
>> Regarding APP, I not really happy with how it works out so far.
>> Consider my last post:
>>
>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=252295
>>
>> It think it makes a strong and clear case for Python, but from the
>> response my feeling is people still just don't get it, or are
>> not willing to get it. For example, I spent a lot of effort
>> in the comment section, not show to why Python is good choice
>> to write reference models, but why reference models are a
>> good idea in the first place. And apparently I didn't succeed!
>> It's just so tiresome at times.
>>
>> Anyway, I have an even stronger post ready, and we'll see.
>>
>> Jan
>
> Hi Jan,
>
> glad that you are back :-)
>
> If you have time, could you review some of the patches that I sent to
> the list a few weeks ago? I'd like to know if I was going on the right
> direction with them.
>
> As for your recent blog posts I found them excellent. However I think
> you should try to make the case for how one would integrate MyHDL into
> an existing "traditional" workflow, as we have been recently
> discussing in this list. I think that the "how to get from here to
> there" question may be what makes it harder for people to imagine how
> MyHDL could be useful for them, as opposed to a nice concept.
>
> Cheers,
>
> Angel
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Synopsis of reported issues

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

Chris:

Thanks for the work to summarize all this.

I am definitely using the SourceForge bug tracker to keep
track of things.

What is most useful for fixing is to enter a bug report with a
stanalone testcase. For conversion issues, the easiest
is to use conversion.analyze or conversion.verify, which
automatically compares MyHDL and generated Verilog/VHDL.

I have solved issue 4 based on Thomas Hellers' example.
I have used his example and entered it as bug #39 in the
bug tracker. See the attached file for the test case - this
will directly be used as a MyHDL unit test.

/Probably/ this is the same as bug #38 that you created,
however the provided test case didn't fail as indicated.
I notice that you have other test cases - could you check
whether the issue is solved and mark the bug as closed-fixed also,
if so?


On 02/02/2013 05:32 AM, Christopher Felton wrote:
> Ok, there have been a burst of issues reported in the last couple
> weeks.  I am trying to keep track of them, understand them,
> and determine how severe the issues might be and possible
> corrections.  All with the hope, to provide a clear definition
> of the issues and help move things along.  Jan D. will have the
> final say on all the issues.  There were two general simulation
> and modeling issues and the rest were VHDL conversion failures.
>
>      1. Mixing /bool/ and /intbv/.  This is a new issues in
>         0.8dev.  This may simply be a mid-feature collision?  The
>         fix, I believe makes sense, is to cast (is that the correct
>         Python terminology) the /val/ in /_SetNextBool/ to a
>         /bool/ and to an /int/ in /_SetNextInt/.  This will
>         prevent the /Signal/ type (/val/) from changing.
>
>         I can submit a patch for these changes but I will wait
>         to see if the 0.8dev changes are in a final form [1].
>
>
>      2. The "bound check race condition".  This is the error that
>         arises from an /intbv/ bound check on a delta cycle,
>         essentially an *assertion*.  Complex descriptions might
>         have invalid delta cycle values (everything cannot be
>         updated simultaneous).  Per K., which I agree, correctly
>         identified that the bound check should be deferred to the
>         end of the simulation step (after all delta-cycles).
>
>         I have some ideas (I am sure Jan D. has the solution :) )
>         and I can proposed an enhancement in a seprate thread, it
>         could get involved.
>
>      3. The following fails in VHDL conversion:
>         x = Signal(intbv(0, min=0, max=8))
>         y = Signal(intbv(0, min=0, max=8))
>         z = Signal(bool(0))
>
>         @always ...
>             z.next = x[0] * y[0]
>
>         The bit-operation "castings" might need some looking at?
>         The tests could use some updating to cover lots of these
>         cases.
>
>      4. More than two right hand side operands fail VHDL
>         conversion if the operands are mixed sizes:
>            ...
>            z.next = a + b + c
>
>         Thomas Heller, pointed out this issue and reinforced that
>         MyHDL has the design goal to handle the sizing and typing.
>
>      5. Possible enhancment, VHDL conversion fails for an edge
>         sensitive conditional for the following cases:
>         It was indicated the following (at least 2) worked in
>         previous versions.  Need to verify this and determine
>         what might changed for edge sensitive conditionals.
>            2. if sig == False
>            3. if sig == intbv(0)
>
>         And I am not convinced that /if not sig/ should not be
>         supported.  It is acceptable (as shown in the mailing
>         list) for non edge sensitve signals.  Why the limitation
>         for edge sensitive signals in VHDL conversion.
>
>      6. Older issue that was identified as a bug, for modeling
>         only, attributes fail to be added to the sensitivty list
>         in /always_comb/ generators.
>
>
> I have tests for all of these in a bitbucket repo [2].
>
> Thanks to everyone for reporting the issues and being patient
> as we figure them out.  I was mistaken, it looks like Jan D.
> has been actively using the sourceforge tracking [3] so I will
> start adding the above to the bug list.
>
> Regards,
> Chris
>
> [1]
> https://bitbucket.org/cfelton/myhdl_dev/src/tip/myhdl/_Signal.py?at=0.8-dev#cl-260
>
> [2] https://bitbucket.org/cfelton/myhdl_tests
>
> [3] http://sourceforge.net/tracker/?atid=596332&group_id=91207&func=browse
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] A puzzling error

[Christopher F. <chr...@gm...>]

<snip>
>>>
>>>
>>
>> If the converter generated /--547/ sounds like this could
>> be a bug.  But I haven't been able to reproduce conversion
>> that generates /--547/ versus /(-(-547))/.  What version of
>> Python and MyHDL are you using?
>>
>
> I'm using Python 2.6.7 and MyHDL 0.7
>

I just double checked, I can reproduce the error with 0.7 but
not 0.8dev.  This has been fixed in 0.8!

Regards,
Chris

Re: [myhdl-list] myhdl + qucs

[Christopher F. <chr...@gm...>]

On 2/17/13 12:22 PM, Todd Greenwood-Geer wrote:
> I'm new to EE, and trying to learn analog, digital, + vhdl. I don't have
> any hardware, so I'm trying this all via open source digital toolkits.
>
> My real attempt at this is to take a simple myhdl snippet (the
> incrementer here
> http://www.myhdl.org/doc/current/manual/conversion_examples.html),
> generate the VHDL, and then insert that into a QUCS project. Why? Well,
> I'd like to generate simple VHDL components, and then test them in a
> real circuit with things like transistors and mosfets and whatnot. If
> there is a better path to this, please speak up :).
>
> My issue is that QUCS (via freeHDL) rewrites the vhdl to a different
> directory, and then chokes on the include file generated by myHDL.
>
> // import line chokes on 'work' in QUCS/freeHDL
> use work.pck_myhdl_07.all;
>
> // error
>   >>> work.pck_myhdl_07 is undeclared
>
> Now, these are clearly not myHDL issues. However, I've tried various
> things to work around this...copying the include file into the target
> vhdl, copying the include file next to the source vhdl file, etc. So, my
> questions are:
>
> 1. Is there a way to tell myHDL to just generate a single VHDL output file?

Not that I am aware of.  This would be a reasonable request to
embedded the functions in the architecture for single file use
cases but it would probably be awhile before someone could get
around to making the enhancement.

>
> 2. Is there a better tool chain for learning all this stuff?
>
> Thanks!
>

This might be of interest, 
http://www.myhdl.org/doku.php/projects:mixedmodesimulation

Another MyHDL user created an example connecting eispice
(Python wrapper around spice) and MyHDL.  eispice is not as
full featured as qucs but it might be enough to do what you
want.  And you get the benefit of doing everything in Python!

Regards,
Chris

[myhdl-list] myhdl + qucs

[Todd Greenwood-G. <t.g...@gm...>]

I'm new to EE, and trying to learn analog, digital, + vhdl. I don't have 
any hardware, so I'm trying this all via open source digital toolkits.

My real attempt at this is to take a simple myhdl snippet (the 
incrementer here 
http://www.myhdl.org/doc/current/manual/conversion_examples.html), 
generate the VHDL, and then insert that into a QUCS project. Why? Well, 
I'd like to generate simple VHDL components, and then test them in a 
real circuit with things like transistors and mosfets and whatnot. If 
there is a better path to this, please speak up :).

My issue is that QUCS (via freeHDL) rewrites the vhdl to a different 
directory, and then chokes on the include file generated by myHDL.

// import line chokes on 'work' in QUCS/freeHDL
use work.pck_myhdl_07.all;

// error
 >>> work.pck_myhdl_07 is undeclared

Now, these are clearly not myHDL issues. However, I've tried various 
things to work around this...copying the include file into the target 
vhdl, copying the include file next to the source vhdl file, etc. So, my 
questions are:

1. Is there a way to tell myHDL to just generate a single VHDL output file?

2. Is there a better tool chain for learning all this stuff?

Thanks!

-- 
Todd