EDK : FSL macros defined by Xilinx are wrong

Tue Apr 13, 2010 4:15 pm   

On 13 Apr, 13:45, "cfelton" <cfelton_at_n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
wrote:


Agreed, I think MyHDL has a lot of potential and there is significant
functionality overlap and similarities to the environment our company
uses. What I'm lamenting is the reluctance of 'hardware engineers" to
adopt advances made in the software field, in terms of regression and
unit testing frameworks. More people should be using MyHDL or
homegrown alternatives to provide rapid simulation verification and
object oriented abstraction models. As a community we are very slow
moving when compared to other related fields.

I believe MyHDL would do well to emphasise more strongly the pure
testbench environment functionality. Many engineers do not want the
VHDL/verilog generation features but could make good use of the
simulation parts of MyHDL. Expanding the cosimulation interface
options to support ModelSim FLI and VHPI would help move it forward.

Thanks,

Chris

Tue Apr 13, 2010 11:01 pm   

On 13 Apr, 14:15, Chris Higgs <chiggs...@googlemail.com> wrote:


It possibly isn't reluctance - there isn't too much in the way of
resources to show how to get started, to investigate alternative
approaches, is there? (with the exception of MyHDL).


Agreed. Although, what's the approximate cost of a sim with FLI/VHPI?
Possibly out of the reach for experimenting. (again, + for MyHDL)

It might be considered better to use just the one language for sim +
RTL because then you're using just the one language. Although
currently I use two languages, one scripting language for various
hardware test scripts + fpga build, and then VHDL for testbenches and
RTL. If I'm able to script testbenches, then I'm still using two
languages. With MyHDL for example, then possibly it's one more step to
*really* only using one language.

My experiences with the Xilinx sim hasn't been the best in terms of
support for behavioural VHDL when I've used it in the past. Hmmmm...
if Xilinx sim supported Python...

Although Tcl is the scripting language I use mostly of late. I have
been investigating the possible use of scripting test benches with
Tcl, and I _think_ it should be possible to do things like the
following in Tcl (not with 8.4 though!)

bench UartTx {} {
test sub UartTx_test {} {
run * c
run * bc
reset
run {set data $DATA; set wr 1; wait @clk; set wr 0}
assert [getSerial] {0 $DATA 1}
}

sub getSerial {} {
set t 8681 ; # 115200 baud
wait @clk {!$ready}
waitFor {$t / 2}; set start $serialOut
set data 0
repeat $BITS {
waitFor $t
set data [expr {($data << 1) | $serialOut}]
}
waitFor $t; set stop $serialOut
return [list $start $data $stop]
}

sub c {} {set clk 0; wait 25; set clk 0; wait 25}
sub bc {} {set baudClk 1; wait @clk; set baudClk 0; wait 173 @clk}
sub reset {} {set rst 1; waitFor 100; wait @clk; set rst 0}
}

Then run the testbench a couple of times, something like:

foreach BITS {7 8} DATA {0x5a 0xa5} {
verify -config {BITS $BITS} -const {DATA $DATA} UartTx
}

Tcl is pretty malleable, includes incrTcl OO in 8.6, but has the $,
expr, [] and # weirdness. I have _some_ of the above working but not
all. What I really need is a sim with Tcl 8.6. Or maybe a sim with
VHPI? I'll have to see if I beg, borrow or steal one. ( about the
last one, or two!).

Whatever the scripting language, I think it's good to at least have
the option of a reasonably succinct and expressive option for
scripting test benches.

Wed Apr 14, 2010 8:45 am   

On 13/04/2010 15:15, Chris Higgs wrote:

I disagree with that.

I haven't done much programmable logic design, and what I have done was
a few years ago now, so I don't have anything like the experience of
most people in this group (I work mainly with embedded software in C,
and some PC software in Python). However, I have made small systems
with both VHDL and Verilog.

What I can say is that both Verilog and VHDL are very verbose, they both
have a lot of features that are confusing and lead easily to wrong code
or extra effort (for example, the difference between the different
assignments in Verilog, or the different logic, bit, and numeric types
in VHDL). There also seems to be a very unclear boundary between
synthesisable and non-synthesisable parts of the languages, and there
can be inconsistencies between simulation and working synthesised behaviour.

When I used confluence, my results were far better. It was simpler and
clearer, and it handles the low-level Verilog or VHDL details
automatically. You can't accidentally end up with a latch or
asynchronous logic in your state machines - in fact, it won't let you
generate latches at all. You don't have registers that are reset in
simulation and preset in synthesis, because all the Verilog/VHDL
registers are generated with explicit resets (or presets). You don't
have problems when mixing signed and unsigned values, because these are
handled correctly.

I haven't used MyHDL for more than brief tests, but it appears to give a
similar isolation from the messy low-level details of Verilog and VHDL,
while (even more than confluence) it gives you higher level features.
People often compare Verilog to "C", and VHDL to "Ada" - I think they
both share a lot with assembly language.

I am also unconvinced of the value of Verilog or VHDL functional
simulation (timing simulation is another matter, of course), if the code
you have written is not in Verilog or VHDL in the first place. If your
code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is
accurate, then you can do all your functional testing entirely within
Python and MyHDL. cosimulation is only relevant when you have parts
that are not written in MyHDL (and cannot easily be modelled in MyHDL).

confluence "died" because the author was more interested in formal
verification systems than synthesis (or testbenches). While
testbenching and integration with Verilog and VHDL simulators is
important, I believe it is more important to have good tools that help
you write correct code in the first place, rather than just to find the
mistakes you've made.

As I say, I don't have the experience in programmable logic design of
most people here. That may mean my opinions here are pretty worthless -
perhaps I'd be happy with Verilog and VHDL if I spend longer getting
used to them. But it may also mean that I can think about this without
the bias of long established practice.

Wed Apr 14, 2010 3:27 pm   

On Apr 14, 8:45 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:


In my experience (which again is limited), there are many engineers
who are happy writing synthesisable code in VHDL. They may find MyHDL
useful for to generate type/conversion packages (it would be nice to
have a union function to convert a record type to a vector and vica-
versa) but want to continue doing the majority of coding in raw VHDL.
I personally believe this comprises the majority of VHDL engineers
(otherwise takeup of tools like MyHDL would be far higher). For this
group having an easy way to interface to the simulator using a
language other than VHDL is the sweetspot which might persuade them to
try a different design flow. MyHDL is almost ready to fill that
space...

Wed Apr 14, 2010 6:18 pm   

Well, you will never get that call because that isn't the point/goal o
MyHDL. But given this argument you would not be interested in using Pytho
in your flow (or any script language except TCL), whether it be for buil
scripts, testbenches, generation of constants, etc.

I think the goal of MyHDL is to replace a bunch of tools in the developer
toobox with a unified tool, in this case a programming language. Man
developers find themselves doing many tasks in a scripting languages, be i
Python, TCL, etc. With Python and MyHDL all this can be done in a singl
language, hopefully improving efficiency.

MyHDL adds *RTL* to Python. The Python-RTL (MyHDL) is converted t
Verilog/VHDL. There is no need or desire for direct support by a synthesi
vendor. And MyHDL doesn't try to do higher level synthesis. Highe
level-synthesis tools can be developed on top of MyHDL if desired. MyHD
has a focused goal which is to add *RTL* to Python, IMO makes it mor
attactive.

I agree, any tool and/or method is easier to adopt if it has a trac
record. But I think the track record you are looking for might be a littl
misdirected (ie some large EDA company adopting). The goal of a compan
should be to increase efficiency and ROI. Tools like Python/MyHDL (an
other languages) provide this. We outlined some of the possible risks an
risk mitigation methods.


---------------------------------------
Posted through http://www.FPGARelated.com

Wed Apr 14, 2010 7:43 pm   

MyHDL is a promising language, but at this point, it is just that:
promising.

I can't go to my director and tell him I'm going to use a non-
commercially-supported language/toolset (VHDL/Verilog RTL converter at
this point) that is at version 0.6 for his next project, and expect to
still have respect, or even a job afterwards. I suspect the vast
majority of non-academic HDL professionals are in exactly the same
boat.

Call me back when it does synthesizable fixed/floating point and has
direct support from at least one major synthesis vendor. Sorry,
converting to VHDL/Verilog RTL to use with anyone's tool does not cut
it, unless the vendor supports the conversion process too.

Andy

Wed Apr 14, 2010 11:23 pm   

On Apr 14, 6:43 pm, Andy <jonesa...@comcast.net> wrote:


MyHDL has good support for subversive behavior :-)

Seriously, that's why conversion to VHDL/Verilog gets so much
attention. It allows you to view MyHDL simply as a more effective
or fun way to create your trusted VHDL/Verilog design.

Therefore, no need to ask nor tell anyone. If you're intrigued,
just do it, and do it as a good engineer: start with a simple
but relevant module, not with a whole design. After conversion,
few will be able to tell (you may even get praise for the
code quality ).

Along the way, you may discover unique features that you want to
share with others, even with directors. You'll know when it's time
to come out.

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
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

Fri Apr 16, 2010 12:33 am   

On Apr 14, 9:45 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:


It is easy to use MyHDL in "Confluence mode", for example to describe
recursive structures and dataflows. However, conceptually the
languages are completely different.

It is remarkable that most HDLs that are *proposed*, including
Confluence,
have parallel-only semantics. This idea of a "HDL closely matching
hardware" is rediscovered once in a while. However, it seems the
market just doesn't want it. Personally I'm convinced that such HDLs
are not powerful enough for general purpose digital design work.

In this respect, MyHDL is proudly in the VHDL/Verilog camp, with
strong support for sequential descriptions also. That gives you much
more power, but it implies that there is more to learn and to
understand.

For example, with MyHDL you will also have to learn about latch
inference and how to avoid "unwanted latches". However, just like in
VHDL/Verilog there is a much better solution for this than using a
limited HDL: use a clocked process template by default.

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
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

Fri Apr 16, 2010 10:47 am   

On 15 Apr, 22:33, Jan Decaluwe <j...@jandecaluwe.com> wrote:


In a rather long thread about vhdl Vs verilog, you seem to have
placed your can opener on another tin of worms marked one process
state machines vs two. What you trying to do, crash google's servers?

Sat Apr 17, 2010 6:40 am   

I don't agree with this. Why provide such a general framework when
all you really want is the "clocked process" anyway. VHDL, Verilog
and MyHDL all let you make the same mistake over and over again.

Cheers,
Andy

Sat Apr 17, 2010 9:21 am   

On 17 Apr, 04:40, "evilkid...@googlemail.com"
<evilkid...@googlemail.com> wrote:

AFAIK, to avoid latch inference you need a non-sequential language,
and most don't want that.

Sat Apr 17, 2010 11:50 am   

On Apr 17, 5:40 am, "evilkid...@googlemail.com"
<evilkid...@googlemail.com> wrote:

The context of the "clocked process" paradigm is synthesizable RTL
code.
For many engineers working on complex projects, writing such code is
only
a fraction of their work. For high-level modeling and verification,
you can
use the power of the language in its full generality.

For powerful HDLs such as VHDL/Verilog/MyHDL, the synthesis coding
constraints are imposed by synthesis technology, not by the language.
It is easy to design a "fully synthesizable" HDL that incorporates
such
constraints in the language definition itself. It just seems that the
market
doesn't want those. I certainly don't. You are of course free to
ignore
that observation.

Jan

P.S not all latches are "unwanted"

Sat Apr 17, 2010 5:48 pm   

On Apr 17, 2:21 am, Paul <pault...@googlemail.com> wrote:

I'm not clear on what either of you are saying. I don't seem to have
a problem with latch inferrence mainly because I know what causes
inferred latches. It has nothing to do with sequential or non-
sequential languages. VHDL has non-sequential capabilities and I can
infer a latch using that.

a <= b when (c = '1'); -- use "c" as a latch enable

What am I missing?

Rick

Mon Apr 19, 2010 8:18 pm   

On Apr 14, 3:23 pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:


And do what? Be forced into a design/coding paradigm that is the least
common denominator of verilog and vhdl?

No thanks, I don't need or want another code generator.

Code conversion is only applicable if you never have to read it or
maintain it in its converted form. I can't rely on myhdl in order to
maintain the source.

Andy

Mon Apr 19, 2010 11:56 pm   

On Apr 19, 7:18 pm, Andy <jonesa...@comcast.net> wrote:

Not necessarily, because conversion happens after elaboration
by the Python interpreter, and because MyHDL's type system
for RTL is at a more abstract level.


Sure, don't bother if it doesn't solve a real problem
for you. Just let it be an informed decision.

Please: don't call it code generation. It's essentially a
powerful HDL with strong conversion capabilities.

Also, last time I forgot to mention that there actually is
commercial support (though it may not be expensive enough
to impress you )

http://www.myhdl.org/doku.php/support


I wouldn't know why not. You can even maintain equivalent VHDL and
Verilog simultanuously. What other technology can do that?

Jan