EDK : FSL macros defined by Xilinx are wrong

e.
MyHDL, on the other hand, has been around for many years, and has a
reasonable-sized community. It is definitely worth looking at if you
are not happy with Verilog or VHDL.
Click to expand...
I don't believe there is any risk in trying/using MyHDL for the followin
reasons.

1. It is stable and has been used for many FPGA and an ASIC project.
2. It is open-source.
3. The output is Verilog/VHDL, you can go back to an old flow i
desired.

The 3rd might not seem reasonable to some because it is computer generate
HDL but it is not computer generated HDL like most think. It is simply
translation from one RTL language to another RTL language (MyHDL -
Verilog/VHDL). The structure will be the same just some minor nam
adjustments.

.chris

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Apr 12, 5:49 am, Chris Higgs <chiggs...@googlemail.com> wrote:

I fail to understand why people don't code testbenches in a nice
dynamic language like python.
Click to expand...
Well, I do. But for really basic stuff, I use Verilog.
 
On Apr 12, 4:23 am, Jan Decaluwe <jandecal...@gmail.com> wrote:
On Apr 11, 5:03 am, Patrick Maupin <pmau...@gmail.com> wrote:

So, no, I don't think I'm confused at all (I can't speak for my
readers; I often leave those confused, I'm sure) and I stand by my
assertion that one of the key principles of programming in Python is
that typing errors are typically the least of the possible errors in a
real program.

As a thought experiment, imagine a Verilog revision based on a
pythonic mindset. Here's what would likely happen to Jonathan's
examples:

Issue: Most-significant bits silently lost when you copy a
wide vector into a narrow one.
New behavior: run-time or compile-time error.
Rationale: "Errors should never pass silently". (Python zen)
Click to expand...
I agree that this particular issue would better be served by an error,
but, in point of fact, all the synthesizers and simulators and lint
checkers I use allow you to treat this as an error if you so choose.

Issue: Signed values silently zero-filled to the width of a
wider target.
New behavior: Use sign bit extension instead.
Rationale: Obvious language design errors should be fixed.
Click to expand...
Again, this is a nice to have, already covered by the tools. And even
in Python, there are few, in retrospect, "obvious language design
errors" that were not fixed until 3.0, because breaking backward
compatibility is a huge problem.

Verilog
designers are surprizingly tolerant to those, but a Python language
designer would never get away with this.
Click to expand...
It is certainly believable that if an HDL were designed by Guido, it
wouldn't have these particular issues. However, these errors you
describe are relatively inconsequential, in that even the most
rudimentary of testbenches would catch them, and IMO the mindset of
both good Python programmers and good RTL programmers is that
testbenches are de rigueur.

As a conclusion, your reference to Python to justify Verilog's
current behavior is rather unconvincing.
Click to expand...
I'm not justifying its behavior per se, just pointing out that none of
the good Python programmers I have worked with would have any problem
getting Verilog up and running. And I will categorically state that,
despite its flaws, the design of the Verilog language is much closer
to Python than the design of VHDL is.

Regards,
Pat
 
Are you using Python to test VHDL or Verilog HDL? Which simulator are
you using? I know of MyHDL, but if I could use Python to test my VHDL
that would be interesting :), particularly if I can use it to build
my FPGA design too. For the later I'm currently use Tcl.
Click to expand...
My guess would be which ever Python to HDL simulation method you use ther
would be some learning curve for the interface. With MyHDL there is ver
little you need to learn to write your testbenches. Most everything can b
accomplished with basic Python. Also, the MyHDL group is very helpful i
you need assistance or run into trouble.

Even if you are only interested in writing testbenches in MyHDL I believ
it is straight forward and it provides you all the tools of Python.

There are scripts available to run/control the FPGA tools from Python.
Mainly consists of executing the correct cli commands.

MyHDL support Icarus and Cver open-source Verilog simulators and has bee
used with commercial simulators such as ModelSim.

.chris

---------------------------------------
Posted through http://www.FPGARelated.com
 
On 12 Apr, 12:44, Chris Higgs <chiggs...@googlemail.com> wrote:

Using python, I can generate packets using an existing library,
directly read (and modify) the internal state, use the state to
determine the correct actions for each packet (not possible in an HDL
testbench without artificially bringing signals out of the top level).
I can also use the exact same software written to configure and
control the programmed FPGA in hardware to control the unit under test
in the testbench, widening the scope of the test coverage. The biggest
advantage, however, is the speed with which I can write complex tests.

*Obviously this is all in my own humble opinion and limited
experience. I'd be interested to hear alternative approaches to
testing that people use. I just happen to be strongly prejudiced and
believe many people would benefit from adopting approaches more
similar to my own ;)
Click to expand...
Are you using Python to test VHDL or Verilog HDL? Which simulator are
you using? I know of MyHDL, but if I could use Python to test my VHDL
that would be interesting :), particularly if I can use it to build
my FPGA design too. For the later I'm currently use Tcl.
 
There are scripts available to run/control the FPGA tools from Python.
Mainly consists of executing the correct cli commands.
Click to expand...
Should say, Python scripts are available on the web, not part of MyHDL, fo
controlling the various vendors tools.

.chris

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Apr 12, 7:44 am, Chris Higgs <chiggs...@googlemail.com> wrote:
The way most people* tend to write testbenches is to use a scripting
language to generate stimuli file and check the results (also written
to a file) afterwards.
Click to expand...
I have no idea whether or not "most people" test as you say or not...I
will say that I must not hang around with those folks though since my
crowd writes self checking testbenches. I do use file I/O for some
stimulus/response, but is more along the lines of something like
- Reading in a .BMP file (JPG, TIFF, etc.) to model an image that is
an input to the system
- Writing out those types of files as well as CSV files of various
transactions to use aid debug to find out what went wrong when the
testbench hits an assertion.

The point is that HDLs
aren't well suited for writing complex testbenches.
Click to expand...
Maybe...that is until you've got the packages written to support all
these nice things. But once you do have those packages, you don't
rewrite them in order to use them on the next project.

'High level' scripting languages have many inherent advantages. For
example - I'm currently testing an "ethernet switch" like device. It's
behaviour depends on various dynamic configuration options and
internal state (fill levels etc). Try writing a testbench for that in
VHDL - it would take forever!
Click to expand...
I can't comment on your specific case, but I don't find writing models
for things to be that difficult...in fact it is rather liberating
since I'm free of the shackles of 'synthesizable' code.

Using python, I can generate packets using an existing library,
directly read (and modify) the internal state, use the state to
determine the correct actions for each packet (not possible in an HDL
testbench without artificially bringing signals out of the top level).
Click to expand...
Not sure why you say it's not possible. I've yet to bring signals out
of the top level for simulation test purposes...on rare occasion I
have cheated a bit by having a 'magic comms' package but by and large,
the system testbench ferrets everything out based on the actual
simulation behavior without having any cheats.

I can also use the exact same software written to configure and
control the programmed FPGA in hardware to control the unit under test
in the testbench, widening the scope of the test coverage. The biggest
advantage, however, is the speed with which I can write complex tests.
Click to expand...
That's a good advantage to have too.

Kevin Jennings
 
On 12/04/2010 17:00, cfelton wrote:
e.

MyHDL, on the other hand, has been around for many years, and has a
reasonable-sized community. It is definitely worth looking at if you
are not happy with Verilog or VHDL.



I don't believe there is any risk in trying/using MyHDL for the following
reasons.

1. It is stable and has been used for many FPGA and an ASIC project.
2. It is open-source.
3. The output is Verilog/VHDL, you can go back to an old flow if
desired.

The 3rd might not seem reasonable to some because it is computer generated
HDL but it is not computer generated HDL like most think. It is simply a
translation from one RTL language to another RTL language (MyHDL -
Verilog/VHDL). The structure will be the same just some minor name
adjustments.
Click to expand...
Point 1 is, I think, more important. The reason I think MyHDL is a
valid choice is that the software itself is pretty stable, and more
importantly the community and developers are stable. Point 3 (as you
expanded on it) is more for damage limitation rather than risk
mitigation. It means that if MyHDL should suddenly go away or for some
other reason be unusable, then your generated output is still useful.
But having been bitten by using a useful but half-finished tool
(confluence) whose developer went away (again, I don't blame him at all,
but thank him for what he gave out), I think it is important to consider
the risks involved in choosing tools like this.

MyHDL is open source, but that is not in itself a guarantee that the
tool, its development, and its community will continue. It's a
guarantee that it always /can/ continue (if you are willing to put in
the necessary resources) - but not that it /will/ continue.

With a project like this, you have to consider what would happen if the
main developer went away (hit by a bus, hired by the competition, or
just gets bored with it). I think in the case of MyHDL, the community
is strong enough to continue - with confluence, it was not (confluence
was also open source).

I haven't done much FPGA work for a while, but if and when I get back to
it, I will be using MyHDL. All I am saying here is that these are
issues that you need to think about before choosing a tool - just like
you do before choosing a hardware vendor.
 
On Apr 12, 7:44 pm, Paul <pault...@googlemail.com> wrote:

Are you using Python to test VHDL or Verilog HDL? Which simulator are
you using? I know of MyHDL, but if I could use Python to test my VHDL
that would be interesting :), particularly if I can use it to build
my FPGA design too. For the later I'm currently use Tcl.
Click to expand...
To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
the simulation (embedding the python interpreter into Riviera), but
something similar could be done for Modelsim. The entity under test is
directly instantiated (no testframe wrapper) and all inputs/outputs
are driven/read directly from python. You can navigate through the
hierarchy as though each entity/signal were an attribute of the root
unit under test object. Tests are written using the python yield
statement (similar to myHDL). A test yields an event which returns
control back to the simulator, resuming the python execution when the
event happens. A simple but pointless example (the "<=" operator is
overloaded for convenience):

def clock(clk, period):
clk <= 0
while True:
yield EventTimer(period)
clk <= not clk.val

def test(tb):
clkthr = tb.thread(clock(tb.uut.clk, 3.2))
yield tb.uut.pkt.valid.edge(1) # Wait for a
rising edge on output valid
print "pkt = %08X" % (tb.uut.pkt.data.val)
tb.kill(clkthr)

The nicest part is the intuitive ease with which layers of abstraction
can be combined. I tend to write a class to handle queuing and
receiving data for each bus which calls a callback when a transfer is
complete.

We use makefiles to drive the test/regression suite and synthesis
tools from the command line. Would there be any advantage to combining
or linking the two?
 
To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
the simulation (embedding the python interpreter into Riviera), but
something similar could be done for Modelsim. The entity under test is
directly instantiated (no testframe wrapper) and all inputs/outputs
are driven/read directly from python. You can navigate through the
hierarchy as though each entity/signal were an attribute of the root
unit under test object. Tests are written using the python yield
statement (similar to myHDL). A test yields an event which returns
control back to the simulator, resuming the python execution when the
event happens. A simple but pointless example (the "<=3D" operator is
overloaded for convenience):

def clock(clk, period):
clk <=3D 0
while True:
yield EventTimer(period)
clk <=3D not clk.val

def test(tb):
clkthr =3D tb.thread(clock(tb.uut.clk, 3.2))
yield tb.uut.pkt.valid.edge(1) # Wait for a
rising edge on output valid
print "pkt =3D %08X" % (tb.uut.pkt.data.val)
tb.kill(clkthr)
Click to expand...
I imagine what you posted works very well and accomplishes what you intend
I think for a new users adopting Python testbenches MyHDL would be a muc
better choice. I is documented, has a nice manual, there are example
available, and a community to support questions. The user doesn't need t
worry about HDL conversion if they do not want. Here is a basic example o
a testbench in MyHDL.

@instance
def stimulus():
rbuf = [0]
wbuf = [0]

TracePrint('Start Testbench')
test_data1 = [0xAA, 0x55, 0x0B, 0x0C, 0x0D]

TracePrint('Write Wishbone LEDs')
yield fx2Model.WriteAddress(0x0101, 1)
yield fx2Model.WriteAddress(0x0103, 0xAA)

TracePrint('Read Wishbone LEDs')
yield fx2Model.ReadAddress(0x0103, rbuf)

# Setup for RAMP Test input
yield fx2Model.WriteAddress(0x0800, 0x01)

TracePrint(' Check Ramp Data')
rmpData = 0
r1 = []; r2=[]
for jj in range(100):
yield fx2Model.WaitData(fx2Model.EP8, 512)
yield delay(128 * fx2Model.IFCLK_TICK)

for ii in range(512):
rdata = fx2Model.Read(fx2Model.EP8)
r1.append(rdata); r2.append(rmpData)
if rdata != rmpData:
pass # Add some an assert or error exception
rmpData = (rmpData + 1) % 256

print " "
yield delay(20*fx2Model.IFCLK_TICK)

TracePrint(' Disable Ramp')
yield fx2Model.WriteAddress(0x0800, 0x00)


.chris

---------------------------------------
Posted through http://www.FPGARelated.com
 
On 13 Apr, 13:45, "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
wrote:
I imagine what you posted works very well and accomplishes what you intend.
 I think for a new users adopting Python testbenches MyHDL would be a much
better choice.  I is documented, has a nice manual, there are examples
available, and a community to support questions.  The user doesn't need to
worry about HDL conversion if they do not want.  Here is a basic example of
a testbench in MyHDL.
snip
Click to expand...

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
 
On 13 Apr, 14:15, Chris Higgs <chiggs...@googlemail.com> 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.
Click to expand...
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).

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.
Click to expand...
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.
 
On 13/04/2010 15:15, Chris Higgs wrote:
On 13 Apr, 13:45, "cfelton"<cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org
wrote:
I imagine what you posted works very well and accomplishes what you intend.
I think for a new users adopting Python testbenches MyHDL would be a much
better choice. I is documented, has a nice manual, there are examples
available, and a community to support questions. The user doesn't need to
worry about HDL conversion if they do not want. Here is a basic example of
a testbench in MyHDL.
snip

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.
Click to expand...
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.
 
On Apr 14, 8:45 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

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).
Click to expand...
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...
 
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
Click to expand...
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
 
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
 
On Apr 14, 6:43 pm, Andy <jonesa...@comcast.net> wrote:

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.
Click to expand...
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
 
On Apr 14, 9:45 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

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.
Click to expand...
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
 
On 15 Apr, 22:33, Jan Decaluwe <j...@jandecaluwe.com> wrote:

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.
Click to expand...
:) 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?
 
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.
Click to expand...

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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top