myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] my patches

[Sébastien B. <seb...@mi...>]

On 10/18/2011 11:42 AM, Ben wrote:
> So what now ?

Well, since I disagree with your conservative policies, I will fork MyHDL.

Re: [myhdl-list] my patches

[Ben <ben...@gm...>]

On Tue, Oct 18, 2011 at 10:49, Sébastien Bourdeauducq
<seb...@mi...> wrote:
> On 10/18/2011 10:03 AM, Jan Decaluwe wrote:
>> The deal is: we work efficiently by agreeing on a spec
>> first,
>
> So, do you disagree with being able to build constant drivers? Or being
> able to read signals within objects in @always_comb blocks?
>

The point is that we shouldn't be reading your patch and try to
understand from it which is the problem you tried to solve.

You'd better introduce them in the following way:

1. This is my problem

Stop here wait for feedback: Maybe people won't agree that it is a
problem, and they might rely on this as a feature.

2. This is an example on how it could be solved

Stop here and wait for feedback: Maybe someone can find a more elegant
way to fix it.

3. Following patch tries to achieve that.

Repeat step 3. until the patch get accepted.

4. Enjoy having fixed something in the MyHDL source code, and having
your name in it.


You jumped to step 3. without defining the "that", with a note that
the tests are hidden on the other side of an URL. This is the reason
no one bothered looking at it, we don't want to play hide and seek
with your hypothetical issues.

So what now ?

Now that you wrote a patch, you should introduce it to this list with
a description about which problem you faced, and how you fixed it. To
this date, I still haven't seen this. (Might be scattered among
multiple emails, but I don't want to bother trying to put all the
pieces together though.)

If you want to make it right, I recommend you writing a MEP
(http://myhdl.org/doku.php/meps:intro) and hosting it on the wiki
among the other ones. If you do think your feature is so simple that
you don't need such a document, mail should do.

Good luck !

Benoit.

Re: [myhdl-list] my patches

[Sébastien B. <seb...@mi...>]

On 10/18/2011 10:03 AM, Jan Decaluwe wrote:
> The deal is: we work efficiently by agreeing on a spec
> first,

So, do you disagree with being able to build constant drivers? Or being 
able to read signals within objects in @always_comb blocks?

> you do all the hard work including testing and
> fixing problems,

Yes, I can certainly improve testing a bit, as has already been pointed out.

Other comments?

Sébastien

Re: [myhdl-list] my patches

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

On 10/17/2011 03:13 PM, Sébastien Bourdeauducq wrote:
> On 10/17/2011 03:12 PM, Jan Decaluwe wrote:
>> I believe the guidelines are reasonable, clear, and have been
>> communicated to you before:
>>
>> http://myhdl.org/doku.php/dev:patches
>
> So, what's the deal? You just want a hg bundle instead of
> copy-pasting my email into the patch command?

Please. Don't reduce the guidelines to a way to create
changesets. (Actually, the guidelines give you two options,
at your discretion, exact command line sequences included.)

The deal is: we work efficiently by agreeing on a spec
first, you do all the hard work including testing and
fixing problems, and you get the credit for the work
through authoring information. That is what the guidelines
try to accomplish.

--
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] CHIP, a myhdl like project

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

On 10/17/2011 10:38 AM, Sébastien Bourdeauducq wrote:
> On 10/17/2011 09:51 AM, Jan Decaluwe wrote:
>> One way, and the big winner to date, is the event-driven paradigm.
>> That is what VHDL, Verilog and MyHDL have in common.
>>
>> It is incorrect (although often done) to call such languages "RTL"
>> languages. Instead, RTL is a semantic subset of such languages.
>> There are other ways to do RTL, but I'm convinced that this is the
>> single way to do it right.
>
> Oh, come on. For synchronous systems, which is what the common
> mortals who design with FPGAs almost always deal with, the
> event-driven paradigm is just a complicated way of getting things
> done. Cycle-based simulations are simpler, faster, and also correct.

I was not talking about simulation techniques, but about the
fundamental paradigm behind language design. Verilator is still
a Verilog simulator, and Verilog is an event-driven language.

Historically, the name RTL (Register Transfer Language) refers
to a totally different paradigm: one in which registers are explicit
and (clock) events are implicit. AHDL is probably the best example
that is still in use. Many other RTL languages of this type
have been proposed over the years. They are all but forgotten, to
the point that it is even hard find any traces about them on
the internet. And of course, this gives room to the occasional
genius to construct a new "fully synthesizable" HDL that is
"much less verbose" than Verilog or VHDL.

In event-driven RTL, (clock) events are explicit and registers are
implicit (inferred). We kept the name RTL, but that really is a
misnomer. Something like "clocked behavior language" would be
more accurate. Regardless of the name, this is the winning
paradigm for RTL. And the reason it has won is that many
designers need much more powerful modeling than just RTL,
within the same language.

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] CHIP, a myhdl like project

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

 >>> On 10/17/2011 11:40 AM, Sébastien Bourdeauducq wrote:
 >>> On 10/17/2011 09:51 AM, Jan Decaluwe wrote:
 >>>>  One way, and the big winner
 >>>>  to date, is the event-driven paradigm. That is what
 >>>>  VHDL, Verilog and MyHDL have in common.
 >>>>
 >>>>  It is incorrect (although often done) to call such
 >>>>  languages "RTL" languages. Instead, RTL is
 >>>>  a semantic subset of such languages. There are
 >>>>  other ways to do RTL, but I'm convinced that this
 >>>>  is the single way to do it right.
 >>>
 >>> Oh, come on. For synchronous systems, which is what the
 >>> common mortals who design with FPGAs almost always deal
 >>> with, the event-driven paradigm is just a complicated way
 >>> of getting things done. Cycle-based simulations are simpler,
 >>> faster, and also correct.

> On 10/17/2011 03:07 PM, Christopher Felton wrote:
>> Ok you lost me here.  Best of my knowledge, most simulators are event
>> based simulators.  They have event queues and at each simulation cycle
>> the event queues are inspected.  Once all events are processed, the
>> simulator moves on to the next cycle.  A cycle-based simulation without
>> events and event queues would need to do a lot of explicit checking and
>> unneeded execution without the queues.  I don't understand how a cycle
>> based simulation without events is faster?
>
> See Verilator for an open-source example.
>
> S.

Feeling left out because I was unaware of cycle-based simulation :(  I 
thought I better try and educate myself.  I didn't find any useful 
information on the Verilator site to define cycle-based versus 
event-driven.  But this article seemed to explain the difference, 
http://chipdesignmag.com/display.php?articleId=192&issueId=13

"""
In an event-driven simulator, the entire logic function is re-evaluated 
each time one of the inputs changes value. Re-evaluation increases the 
simulation time and reduces the event-driven simulator's performance. 
Cycle-based simulators evaluate each logic function once per cycle. 
Cycle-based simulators effectively use flattened cones of logic. Each 
cone is evaluated once during a simulation cycle.
"""

Other than defining what a "cone" of logic is the description seems 
straight-forward.  And it seems to fit my "guess" description; that 
cycle-base would have to evaluate each set (cone) of logic on each 
cycle.  Intuitively this would seem slower (but intuition is often 
wrong).  So, the missing data is; why would a cycle-based simulation be 
faster?  It isn't too hard to think of examples in which either 
implementation would be slower.  In my mind, for cycle-based to be 
faster, on average most designs have to have logic blocks which inputs 
change multiple times per cycle.  This seems reasonable but some data to 
support this would be nice.

The Verilator benchmarks probably not a good source for this data.  One, 
it is doing more than just using cycle-based vs. event-driven.  And 
second, some of their comparisons are "guesses".  He takes published 
results and uses some multiplier to adjust of different machines etc.

As the Verilator site and the ChipDesign article show, it can only be 
used for a subset of the language.  I guess you should have said "common 
mortals who design with FPGAs using a subset ..." :)
Or you believe "most only _use_ the RTL portion of popular HDLs".

In the end, the comment seemed out of placed and introduced a fairly 
off-topic discussion (although educational for me and somewhat 
interesting).  The idea of how the simulator *implements* the simulation 
is not the same as how a language abstracts (represents) the 
design/hardware and what those paradigms should be called.

Regards,
Chris

Re: [myhdl-list] CHIP, a myhdl like project

[Sébastien B. <seb...@mi...>]

On 10/17/2011 03:07 PM, Christopher Felton wrote:
> Ok you lost me here.  Best of my knowledge, most simulators are event
> based simulators.  They have event queues and at each simulation cycle
> the event queues are inspected.  Once all events are processed, the
> simulator moves on to the next cycle.  A cycle-based simulation without
> events and event queues would need to do a lot of explicit checking and
> unneeded execution without the queues.  I don't understand how a cycle
> based simulation without events is faster?

See Verilator for an open-source example.

S.

Re: [myhdl-list] my patches

[Sébastien B. <seb...@mi...>]

On 10/17/2011 03:12 PM, Jan Decaluwe wrote:
> I believe the guidelines are reasonable, clear, and have
> been communicated to you before:
>
> http://myhdl.org/doku.php/dev:patches

So, what's the deal? You just want a hg bundle instead of copy-pasting 
my email into the patch command? Or are there other problems?

Re: [myhdl-list] my patches

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

On 10/07/2011 11:17 PM, Sébastien Bourdeauducq wrote:
> Hi,
>
> could you consider applying the two patches I sent last month?
> http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list
> http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list

I believe the guidelines are reasonable, clear, and have
been communicated to you before:

http://myhdl.org/doku.php/dev:patches

-- 
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] CHIP, a myhdl like project

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

On 10/17/11 3:38 AM, Sébastien Bourdeauducq wrote:
> On 10/17/2011 09:51 AM, Jan Decaluwe wrote:
>   >  One way, and the big winner
>   >  to date, is the event-driven paradigm. That is what
>   >  VHDL, Verilog and MyHDL have in common.
>   >
>   >  It is incorrect (although often done) to call such
>   >  languages "RTL" languages. Instead, RTL is
>   >  a semantic subset of such languages. There are
>   >  other ways to do RTL, but I'm convinced that this
>   >  is the single way to do it right.
>
> Oh, come on. For synchronous systems, which is what the common mortals
> who design with FPGAs almost always deal with, the event-driven paradigm
> is just a complicated way of getting things done. Cycle-based
> simulations are simpler, faster, and also correct.
>

Ok you lost me here.  Best of my knowledge, most simulators are event 
based simulators.  They have event queues and at each simulation cycle 
the event queues are inspected.  Once all events are processed, the 
simulator moves on to the next cycle.  A cycle-based simulation without 
events and event queues would need to do a lot of explicit checking and 
unneeded execution without the queues.  I don't understand how a cycle 
based simulation without events is faster?

>> The back-end is VHDL RTL, and
>> as I noticed before, I think MyHDL would have been a
>> better choice.
>
> Then maybe you'll like my HLS prototype better? If so, please consider
> merging my patches which are needed to support it.
>
>   >  * "A hardware model written in an imperative style cannot be
>   >  synthesised"
>   >
>   >  This is wrong: an imperative style is actually very useful to describe
>   >  combinatorial and clocked RTL logic.
>   >  (...)
>   >  I agreed with the author that RTL is "low-level". However, it  is
>   >  definitely not as "low-level" as he suggests. If the starting
>   >  point is shaky, I don't have a lot of confidence in the "solution".
>
> I think he meant "imperative style for a complete algorithm", not
> "imperative style for describing what can be done within one clock
> cycle". From this point of view, it is true that the efficient synthesis
> of a complex algorithm written in imperative style is a very difficult
> problem, and that using a different "dataflow" paradigm can make sense.

I agree, I think the author poorly described the point.  And probably 
should have said "would implement an algorithm in an imperative style". 
  Given how it is worded it gives the wrong impression.

Regards,
Chris

>
> S.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct

Re: [myhdl-list] toVHDL Observation

[Sébastien B. <seb...@mi...>]

On 10/17/2011 10:25 AM, Jan Decaluwe wrote:
> The mechanisms in the convertor to avoid name and keyword clashes
> are broken (in the sense that they aren't present :-)).
>
> I keep delaying it, because the problem is not that simple in
> general.

How about using extended names (at least for internal signals)?

Verilog:
http://eesun.free.fr/DOC/VERILOG/verilog_manual1.html "Escaped 
Identifiers (identifier whose first character is a backslash (\))permit 
non alphanumeric characters in Verilog name. The escaped name includes 
all the characters following the backslash until the first whitespace 
character."

VHDL:
http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html "there are a set 
of extended identifier rules which allow identifiers with any sequence 
of characters. ..."

Re: [myhdl-list] CHIP, a myhdl like project

[Sébastien B. <seb...@mi...>]

On 10/17/2011 09:51 AM, Jan Decaluwe wrote:
 > One way, and the big winner
 > to date, is the event-driven paradigm. That is what
 > VHDL, Verilog and MyHDL have in common.
 >
 > It is incorrect (although often done) to call such
 > languages "RTL" languages. Instead, RTL is
 > a semantic subset of such languages. There are
 > other ways to do RTL, but I'm convinced that this
 > is the single way to do it right.

Oh, come on. For synchronous systems, which is what the common mortals 
who design with FPGAs almost always deal with, the event-driven paradigm 
is just a complicated way of getting things done. Cycle-based 
simulations are simpler, faster, and also correct.

> The back-end is VHDL RTL, and
> as I noticed before, I think MyHDL would have been a
> better choice.

Then maybe you'll like my HLS prototype better? If so, please consider 
merging my patches which are needed to support it.

 > * "A hardware model written in an imperative style cannot be
 > synthesised"
 >
 > This is wrong: an imperative style is actually very useful to describe
 > combinatorial and clocked RTL logic.
 > (...)
 > I agreed with the author that RTL is "low-level". However, it  is
 > definitely not as "low-level" as he suggests. If the starting
 > point is shaky, I don't have a lot of confidence in the "solution".

I think he meant "imperative style for a complete algorithm", not 
"imperative style for describing what can be done within one clock 
cycle". From this point of view, it is true that the efficient synthesis 
of a complex algorithm written in imperative style is a very difficult 
problem, and that using a different "dataflow" paradigm can make sense.

S.

Re: [myhdl-list] toVHDL Observation

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

On 10/10/2011 06:22 PM, Christopher Felton wrote:
> Not much thought or investigation behind this.  But I notice today
> when converting a state-machine which used enum() for state
> definitions to VHDL, that I had to be careful with the names I chose.
> VHDL keywords and other VHDL naming rules had to be considered
> (obeyed).
>
> I had a state-machine I intended to convert to Verilog and VHDL but
> had only converted to Verilog.  When I tried VHDL, D'oh.  Simply, had
> to rename some of the states, like 'WAIT' and 'END' as well as
> removing trailing underscores (which were place-holders).

The mechanisms in the convertor to avoid name and keyword clashes
are broken (in the sense that they aren't present :-)).

I keep delaying it, because the problem is not that simple in
general. However, maybe we should do this in phases. Keyword checking
should be simple. What could be done:

* check for all keywords in VHDL/Verilog  in the conversion.analyzer.
* issue an error for a keyword clash in the target conversion language,
   and a warning for a keyword of the other one

-- 
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] CHIP, a myhdl like project

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

On 10/14/2011 05:25 PM, Martín Gaitán wrote:
> I was randomly browsing PyPi  when I found this project:
> http://dawsonjon.github.com/chips/
>
> Although (in a a not so deep review) it looks inmature compared with
> MyHDL, I wonder if the chip's author knows MyHDL and why not put his
> effort in order to improve this.
>
> Has somebody hear about this project and/or its author?

Yes, and I don't worry too much about it. I don't think
you are correct in saying that this is "MyHDL-like".

Recently, there have also been other sources of confusion
about the nature of MyHDL (and conversion), e.g. how it
relates to beasts like guarded atomic actions.

Let me therefore try to clarify some concepts.

There are several paradigms to construct "hardware
description" languages. One way, and the big winner
to date, is the event-driven paradigm. That is what
VHDL, Verilog and MyHDL have in common.

It is incorrect (although often done) to call such
languages "RTL" languages. Instead, RTL is
a semantic subset of such languages. There are
other ways to do RTL, but I'm convinced that this
is the single way to do it right.

The point to remember is that in MyHDL (and VHDL and
Verilog) events are the name of the game. Trying to
stuff in other paradigms will just lead to confusion.

Consider MyHDL conversion. What it does is to convert
an event-driven model into an equivalent event-driven
model. Conversion is "event accurate". Within this
constraint, it tries to automate as much as possible,
but that doesn't make it a synthesis tool. The goal
of conversion is to make sure that a MyHDL-based
design flow plays well with the mainstream event-driven
HDLs. Nothing more, nothing less.

In contrast, high-level synthesis can be defined as
a tool that creates an equivalent lower-level RTL
model without the constraint of "event accuracy". The
high-level input models may not be based on events at
all. The big difficulty with such tools is to
define clearly what "equivalent" means.

Unlike RTL, there are many potentially meaningful
ways to do high-level modeling/synthesis. For the user,
the most important concept is the modeling paradigm,
as implemented by the input language.

MyHDL could possibly be the input language of a high-level
synthesis tool based on high-level event-driven models.
However, this has been tried before with VHDL and Verilog
without a lot of success. This does not mean that MyHDL
has no role to play in high-level synthesis. On the
contrary: I believe that it is the ideal back-end language
for such tools: with the same effort, one can support
3 RTL back-ends instead of one, thanks to conversion.

Now consider CHIPS. It is clearly a high-level modeling/
synthesis attempt. The paradigm seems to be some kind of
stream-based modeling. No events in sight. Therefore,
it is not "MyHDL-like". The back-end is VHDL RTL, and
as I noticed before, I think MyHDL would have been a
better choice.

Whether this particular approach is useful is something
that everyone should judge for himself. Personally, I
don't see how it could be useful for the kind of
project I am doing. Moreover, in the very first paragraphs
of the rationale behind the project, the author makes
makes a few doubtful statements:

http://dawsonjon.github.com/chips/introduction/index.html#a-new-approach-to-device-design

* "A hardware model written in an imperative style cannot be synthesised"

This is wrong: an imperative style is actually very useful to describe
combinatorial and clocked RTL logic.

* "The primitive elements of an RTL design are clocked memory
   elements (registers) and combinational logic elements."

Actually, those are the primitive elements of a gate level
synthesized from RTL. In my view, the primitive elements in
RTL design are clocked processes (and an occasional combinatorial
process.) In particular, registers are inferred from behavior,
not implied or instantiated.

(Note: the name RTL is historical. For event-driven RTL as
we all are using, it is a misnomer.)

I agreed with the author that RTL is "low-level". However, it  is
definitely not as "low-level" as he suggests. If the starting
point is shaky, I don't have a lot of confidence in the "solution".

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

[myhdl-list] CHIP, a myhdl like project

[Martín G. <ga...@gm...>]

I was randomly browsing PyPi  when I found this project:
http://dawsonjon.github.com/chips/

Although (in a a not so deep review) it looks inmature compared with MyHDL,
I wonder if the chip's author knows MyHDL and why not put his effort in
order to improve this.

Has somebody hear about this project and/or its author?

Re: [myhdl-list] OT - Atmel ProChip Designer software

[garyr <ga...@fi...>]

Thanks very much for your reply. Many thanks also for MyHDL, an amazing
program.

Gary Richardson

----- Original Message ----- 
From: "Jan Decaluwe" <ja...@ja...>
To: <myh...@li...>
Sent: Friday, October 14, 2011 12:39 AM
Subject: Re: [myhdl-list] OT - Atmel ProChip Designer software


> On 10/13/2011 10:58 PM, garyr wrote:
>> My question does not specifically concern MyHDL. If there is another
>> newsgroup where it would be more appropriate please let me know.
>>
>> I would like to use the free Atmel ProChip Designer software  to
>> generate code for one of the ATF15xx CPLDs. The brochure for it lists
>> four types of software packages: Design&  Entry, Synthesis,
>> Simulation and Fitters& Devices. I think I understand the function of
>> Design&  Entry, Simulation and  Fitters&  Devices but Synthesis has
>> me puzzled. The synthesis packages are  all very expensive
>> third-party items. Is the synthesis software necessary  for code
>> development or just convenient?
>
> When you use HDL-based design, synthesis is necessary.
>
> Tools from mainstream EDA vendors are typically going to be expensive,
> as a consequence of the nature of EDA (currently). For synthesis,
> that is even understandable (as opposed to simulation for example).
>
> However, mainstream FPGA vendors such Xilinx and Altera understand
> that synthesis (and HDL-based design) is necessary for designers
> to cope with the complexity of their devices. Therefore, they
> subsidize EDA tools, including decent synthesis, as a way to
> sell more devices. Basically, you get it for free or for a
> low price.
>
> I would therefore consider moving to a vendor with such an offering.
> Xilinx and Altera have it, don't know about Actel and others.
>
> 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
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] OT - Atmel ProChip Designer software

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

On 10/13/2011 10:58 PM, garyr wrote:
> My question does not specifically concern MyHDL. If there is another
> newsgroup where it would be more appropriate please let me know.
>
> I would like to use the free Atmel ProChip Designer software  to
> generate code for one of the ATF15xx CPLDs. The brochure for it lists
> four types of software packages: Design&  Entry, Synthesis,
> Simulation and Fitters& Devices. I think I understand the function of
> Design&  Entry, Simulation and  Fitters&  Devices but Synthesis has
> me puzzled. The synthesis packages are  all very expensive
> third-party items. Is the synthesis software necessary  for code
> development or just convenient?

When you use HDL-based design, synthesis is necessary.

Tools from mainstream EDA vendors are typically going to be expensive,
as a consequence of the nature of EDA (currently). For synthesis,
that is even understandable (as opposed to simulation for example).

However, mainstream FPGA vendors such Xilinx and Altera understand
that synthesis (and HDL-based design) is necessary for designers
to cope with the complexity of their devices. Therefore, they
subsidize EDA tools, including decent synthesis, as a way to
sell more devices. Basically, you get it for free or for a
low price.

I would therefore consider moving to a vendor with such an offering.
Xilinx and Altera have it, don't know about Actel and others.

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

[myhdl-list] OT - Atmel ProChip Designer software

[garyr <ga...@fi...>]

My question does not specifically concern MyHDL. If there is another
 newsgroup where it would be more appropriate please let me know.

 I would like to use the free Atmel ProChip Designer software  to generate
 code for one of the ATF15xx CPLDs. The brochure for it lists four types of
 software packages: Design & Entry, Synthesis, Simulation and Fitters &
 Devices. I think I understand the function of Design & Entry, Simulation 
and  Fitters & Devices but Synthesis has me puzzled. The synthesis 
packages are  all very expensive third-party items. Is the synthesis 
software necessary  for code development or just convenient?

[myhdl-list] toVHDL Observation

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

Not much thought or investigation behind this.  But I notice today when 
converting a state-machine which used enum() for state definitions to 
VHDL, that I had to be careful with the names I chose.  VHDL keywords 
and other VHDL naming rules had to be considered (obeyed).

I had a state-machine I intended to convert to Verilog and VHDL but had 
only converted to Verilog.  When I tried VHDL, D'oh.  Simply, had to 
rename some of the states, like 'WAIT' and 'END' as well as removing 
trailing underscores (which were place-holders).

Regards,
Chris

Re: [myhdl-list] my patches

[Ben <ben...@gm...>]

That's not a comment on the content of your patches, but the fact that
your tests are at another places burden me.

This means, if someone wants to look t it, he has to look at two
places at the same time, ... You'd have better chance at someone
looking at them if you include the tests in MyHDL testing framework
... This way, also, someone making maintenance on those feature will
know if he broke it.

Good luck with it !
Benoit

On Fri, Oct 7, 2011 at 23:17, Sébastien Bourdeauducq
<seb...@mi...> wrote:
> Hi,
>
> could you consider applying the two patches I sent last month?
> http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list
> http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list
>
> Thanks,
> Sebastien
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] my patches

[Sébastien B. <seb...@mi...>]

Hi,

could you consider applying the two patches I sent last month?
http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list
http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list

Thanks,
Sebastien

Re: [myhdl-list] howto cite MyHDL

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

On 10/06/2011 12:35 AM, Christopher Felton wrote:

> I will see if I can provide some details on the MyHDL designs I have
> fielded.  If not I will provide some generic descriptions in the
> user/project space.

Great, thanks. Once we have 4-5 projects, I propose to
add a "Silicon Success" page with the links, on a prominent
position on the website.


-- 
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] Sigma-Delta DAC

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

On 10/5/2011 10:51 AM, Bob Cunningham wrote:
> On 10/05/2011 03:36 AM, Christopher Felton wrote:
>> On 10/4/11 2:37 AM, Bob Cunningham wrote:
>>> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>>>
>>> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>>>
>> I think what you are getting at, is that you want an AGC part of your
>> design.  This should not be part of the delta-sigma module.  You might
>> consider it part of your "DAC" but I don't think it should be part of
>> the delta-sigma module.
>
> AGC?  No, I don't think that's an issue.

I am a little confused, I don't know if you are worried about ENOB or 
loading on the circuit (or impedance matching or any other circuit 
issue).  I would argue not the same issues.  In one case you need to do 
the noise analysis of your analog circuit and make sure the noise floor 
doesn't corrupt the dynamic range of of your DAC#bits.  The other you 
might desire a pre-emphasis (equalization) to account for any 
distortion.  In both cases I would not modify the d-s modulator, unless 
it was the number of bits used.

You are probably better off, backing up looking at the system design and 
analysis.  Determine the architecture of the ADC and DAC you want and 
what external circuits you want.  You should not need to add anything to 
the d-s DAC.

>
> But if you start with an d-s DAC, adding an analog comparator and a simple circuit change yields a d-s ADC.  It won't necessarily be high-fidelity (that will best be accomplished using external ADC and DAC hardware), but it will be both minimal and adequate.  And interesting!
>

You don't need a delta-sigma (d-s) DAC for a d-s ADC.  You only need one 
d-s modulator per converter, just happens, in one case it is a 
continuous and the other a discrete.

>>> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>>>
>>> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>>>
>>> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>>>
>>> The question is: Would the extra processing be worth doing?  Why or why not?
>>>
>>>
>>> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>>>      - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>>>      - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>>>      - Or am I missing some of the intent of the test?
>>>
>> The integration time, might be poorly named, in the testbench.  It is
>> simply some amount of time delayed for each step to test.  You can work
>> backwards and analytically determine the response time (I don't know
>> this off the top of my head).  Or you could apply a step function to the
>> module and empirically determine the response time.  Is there a reason
>> you want to change it?
>
> The signal seems to be correctly named.  The PDM output is summed until the integration time passes.
>
> The test integrates for the specified number of clocks, then checks to see if the PDM output reaches the correct average value.  It ignores any specification for DAC response time: How long *should* it take for the output to stabilize?
>
> If you look at the specified output RC filter (3.3 Kohm, 2 nF), it has a tau of 6.6 uS, for a 3 dB knee at 24.1 KHz ('good enough' for a 20 KHz audio output bandwidth).  So allowing a minimal amount of Nyquist headroom, a 44.1 KHz input word rate to the DAC seems about right.
>

Yes, it is an ok name.  But the tb does not try to emulate the RC-LPF 
used in the tb.  Introducing the parameters of the external RC-LPF at 
this point will only cause confusion, IMO.

The value is arbitrary, but it is fine for what the tb is testing.  It 
is just verifying, for each input state the modulator converges to a 
value.  If the input is not changing, the output should have an average 
of zero, regardless of the input value.

> Nominally, the DAC output integration time shouldn't (can't?) be slower than the input word rate (44.1 KHz), else the output won't be stable before the next input sample starts to be processed.  That would be no more than 362 cycles of the 16 MHz clock.  512 samples doesn't seem to test anything useful, and it could allow a poorly-converging DAC to pass!
>
> Then again, using an integration time that is a power of 2 does make the test *slightly* simpler.
>
> In my current career of creating software for embedded real-time systems, such as nuclear power plant monitoring systems and aircraft instruments, fanatical testing at all levels (hardware and software, from components to system) forms the core of safe and reliable products.  I'm not about to start getting sloppy now!
>
> In this specific case, it may be best to calculate the maximum allowed number of PDM clocks, then round down to the next lower power of 2, which in this case would be 256.  If it passes at that count, it should pass with any higher count.
>
>
>> For the most part, these are general design questions.  You might want
>> to cross-post to comp.arch.fpga or sci.electronics.design (.basic).
>> There were no protest to post here, as stated I think it is fine, but
>> you might get a better response from some of the other news/irc groups
>> in addition.
>
> Well, this is still seems (to me) to be more about myHDL than anything else.  As a newbie, I want to make maximal use of published myHDL sample code before I start writing anything of my own.  I want to know what really good myHDL code should look like (content and style), and how all instances of the test and development processes should proceed.  So I'm beating on this DAC for multiple reasons!
>

This particular conversation is mostly about d-s basics.  Don't mean to 
discourage conversation here, just want to set expectations.

> Next, I'll want to wrap good VHDL and Verilog code within myHDL, and eventually translate it to pure myHDL.  Only as a last resort will I want to do my own design on this first project!  My FPGA board should arrive fairly soon, and I hope to not just have a demo binary ready to go, but one that has been tested well enough to present no surprises when loaded into the FPGA.
>
> Despite not being a much of a circuit designer, I see things in the referenced code that don't look quite right.  I'm not sure if it is due to a poor circuit design, a poor test harness, my own limited knowledge of myHDL and circuit design, or a combination of all of them.  Hence the use of this forum.
>
> For the specific case of an all-digital ADC and DAC (the gateway to my audio effects processor), if my learning curve permits I hope to also cosimulate the RC output and input networks using myHDL with Spice.  So the 'real' test could be in the analog domain, where an audio signal is supplied to the ADC and compared to the DAC output.  It's about more than just a specific circuit or project: My true goal is to put the myHDL development and test environment through its paces in every way I can.
>
> I expect to pursue my digital design education at a fairly lazy rate, driven by the problems I want to solve and the projects I want to build, rather than a textbook or a class.  But I will want to do it *all* within the myHDL environment, which is why I plan to collect my notes and eventually write a "FPGA Projects in myHDL" tutorial, based on a progression of non-trivial but easily understood and useful examples that are well-designed, well-written, and obsessively tested (simulation, cosimulation, circuit test with and without a synthesized test bench, etc.).
>
> That's a primary reason why I chose an audio effects processor:  Once the ADC and DAC are in place, much of the rest is just creating relatively simple audio processing modules.  Due to the slow data rate (KHz, not MHz), the design can easily be evolved to use single module instances with multiple audio streams (time domain switching), perform multi-track mixing, and change the module order (crossbar switching).  I also expect it to consume a relatively small portion of the FPGA, leaving adequate room to integrate a processor core and proceeding to an entire SoC (perhaps with a Wishbone interface).  I have no idea how I will test a processor core within the myHDL environment, but I can't wait to figure it out!
>

> In other areas of study, the tutorials that have been the most useful to me were written by recent beginners, and edited by gurus.  Plus, I learn best by teaching:  Writing a thorough introductory tutorial is a great way to master the basics of any field of endeavor.  I'll be pushing the members of this forum to help me create examples of myHDL code (and a library of polished projects) we'll all be proud to share with the world.
>
> If I visit the other forums you recommend, I'm afraid they'll ask me to speak VHDL or Verilog or SystemC or something...  Or, worse, ask for an ASCII-art schematic.   ;^)  But I will start monitoring them.

Again, just depends on the feedback you want.  You will get good 
feedback here for all things MyHDL and good feedback for other design 
domains.  Some topics, such as d-s design and theory, cross posting 
might be useful.  You can separate the design/functionality questions 
from the language implementation.  The suggestion wasn't to indicate to 
get MyHDL information from somewhere else, but the others forums might 
help with d-s or other general issues.

Good luck with the endeavor.

Regards,
Chris

>
> Thanks,
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

Re: [myhdl-list] howto cite MyHDL

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

On 10/5/11 9:58 AM, Jan Decaluwe wrote:
> On 10/05/2011 12:21 PM, Christopher Felton wrote:
>> On 10/2/11 9:33 PM, Dan White wrote:
>>> I've used MyHDL for some digital parts on my last mixed-signal ASIC
>>> for my PhD research.  The chip is currently in fab and I've been
>>> waiting to get a die photo after testing to announce here the second
>>> verified silicon using MyHDL in the flow.
>>>
>>
>> Congratulations as well!  It seems MyHDL might have found a niche in
>> mixed-signals ICs.
>
>    From what I see, this is becoming the niche of ASICs tout court:
> pure digital designs are systematically migrating to FPGAs,
> the few exceptions being super high volume and complexity designs.
>
True, very true, I agree.

> Therefore - there must be some MyHDL FPGA success stories
> out there as well. We may not have heard about them because
> the typical ASIC milestones like sign-off and tape-out are
> not applicable (fortunately I would add.) But I would encourage
> anyone with such success stories (especially FPGAs in production)
> to tell us about it if possible.
>
I will see if I can provide some details on the MyHDL designs I have 
fielded.  If not I will provide some generic descriptions in the 
user/project space.

> More than anything else, I think the project needs the
> credibility from working silicon, FPGAs included.
>

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

On 10/05/2011 03:36 AM, Christopher Felton wrote:
> On 10/4/11 2:37 AM, Bob Cunningham wrote:
>> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>>
>> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>>
> I think what you are getting at, is that you want an AGC part of your
> design.  This should not be part of the delta-sigma module.  You might
> consider it part of your "DAC" but I don't think it should be part of
> the delta-sigma module.

AGC?  No, I don't think that's an issue.

But if you start with an d-s DAC, adding an analog comparator and a simple circuit change yields a d-s ADC.  It won't necessarily be high-fidelity (that will best be accomplished using external ADC and DAC hardware), but it will be both minimal and adequate.  And interesting!

>> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>>
>> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>>
>> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>>
>> The question is: Would the extra processing be worth doing?  Why or why not?
>>
>>
>> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>>     - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>>     - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>>     - Or am I missing some of the intent of the test?
>>
> The integration time, might be poorly named, in the testbench.  It is
> simply some amount of time delayed for each step to test.  You can work
> backwards and analytically determine the response time (I don't know
> this off the top of my head).  Or you could apply a step function to the
> module and empirically determine the response time.  Is there a reason
> you want to change it?

The signal seems to be correctly named.  The PDM output is summed until the integration time passes.

The test integrates for the specified number of clocks, then checks to see if the PDM output reaches the correct average value.  It ignores any specification for DAC response time: How long *should* it take for the output to stabilize?

If you look at the specified output RC filter (3.3 Kohm, 2 nF), it has a tau of 6.6 uS, for a 3 dB knee at 24.1 KHz ('good enough' for a 20 KHz audio output bandwidth).  So allowing a minimal amount of Nyquist headroom, a 44.1 KHz input word rate to the DAC seems about right.

Nominally, the DAC output integration time shouldn't (can't?) be slower than the input word rate (44.1 KHz), else the output won't be stable before the next input sample starts to be processed.  That would be no more than 362 cycles of the 16 MHz clock.  512 samples doesn't seem to test anything useful, and it could allow a poorly-converging DAC to pass!

Then again, using an integration time that is a power of 2 does make the test *slightly* simpler.

In my current career of creating software for embedded real-time systems, such as nuclear power plant monitoring systems and aircraft instruments, fanatical testing at all levels (hardware and software, from components to system) forms the core of safe and reliable products.  I'm not about to start getting sloppy now!

In this specific case, it may be best to calculate the maximum allowed number of PDM clocks, then round down to the next lower power of 2, which in this case would be 256.  If it passes at that count, it should pass with any higher count.


> For the most part, these are general design questions.  You might want
> to cross-post to comp.arch.fpga or sci.electronics.design (.basic).
> There were no protest to post here, as stated I think it is fine, but
> you might get a better response from some of the other news/irc groups
> in addition.

Well, this is still seems (to me) to be more about myHDL than anything else.  As a newbie, I want to make maximal use of published myHDL sample code before I start writing anything of my own.  I want to know what really good myHDL code should look like (content and style), and how all instances of the test and development processes should proceed.  So I'm beating on this DAC for multiple reasons!

Next, I'll want to wrap good VHDL and Verilog code within myHDL, and eventually translate it to pure myHDL.  Only as a last resort will I want to do my own design on this first project!  My FPGA board should arrive fairly soon, and I hope to not just have a demo binary ready to go, but one that has been tested well enough to present no surprises when loaded into the FPGA.

Despite not being a much of a circuit designer, I see things in the referenced code that don't look quite right.  I'm not sure if it is due to a poor circuit design, a poor test harness, my own limited knowledge of myHDL and circuit design, or a combination of all of them.  Hence the use of this forum.

For the specific case of an all-digital ADC and DAC (the gateway to my audio effects processor), if my learning curve permits I hope to also cosimulate the RC output and input networks using myHDL with Spice.  So the 'real' test could be in the analog domain, where an audio signal is supplied to the ADC and compared to the DAC output.  It's about more than just a specific circuit or project: My true goal is to put the myHDL development and test environment through its paces in every way I can.

I expect to pursue my digital design education at a fairly lazy rate, driven by the problems I want to solve and the projects I want to build, rather than a textbook or a class.  But I will want to do it *all* within the myHDL environment, which is why I plan to collect my notes and eventually write a "FPGA Projects in myHDL" tutorial, based on a progression of non-trivial but easily understood and useful examples that are well-designed, well-written, and obsessively tested (simulation, cosimulation, circuit test with and without a synthesized test bench, etc.).

That's a primary reason why I chose an audio effects processor:  Once the ADC and DAC are in place, much of the rest is just creating relatively simple audio processing modules.  Due to the slow data rate (KHz, not MHz), the design can easily be evolved to use single module instances with multiple audio streams (time domain switching), perform multi-track mixing, and change the module order (crossbar switching).  I also expect it to consume a relatively small portion of the FPGA, leaving adequate room to integrate a processor core and proceeding to an entire SoC (perhaps with a Wishbone interface).  I have no idea how I will test a processor core within the myHDL environment, but I can't wait to figure it out!

In other areas of study, the tutorials that have been the most useful to me were written by recent beginners, and edited by gurus.  Plus, I learn best by teaching:  Writing a thorough introductory tutorial is a great way to master the basics of any field of endeavor.  I'll be pushing the members of this forum to help me create examples of myHDL code (and a library of polished projects) we'll all be proud to share with the world.

If I visit the other forums you recommend, I'm afraid they'll ask me to speak VHDL or Verilog or SystemC or something...  Or, worse, ask for an ASCII-art schematic.   ;^)  But I will start monitoring them.

Thanks,

-BobC