EDK : FSL macros defined by Xilinx are wrong

Mon Apr 12, 2010 12:23 pm   

On Apr 11, 5:03 am, Patrick Maupin <pmau...@gmail.com> wrote:


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)

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. Verilog
designers are surprizingly tolerant to those, but a Python language
designer would never get away with this.

As a conclusion, your reference to Python to justify Verilog's
current behavior is rather unconvincing.

Jan

Mon Apr 12, 2010 1:49 pm   

On Apr 9, 9:05 pm, Patrick Maupin <pmau...@gmail.com> wrote:


I fail to understand why people don't code testbenches in a nice
dynamic language like python.

Limit the use of HDLs to describing the hardware and make use of a
high-level scripting language to read in files/generate stimuli, check
results and introduce errors/modify state dynamically. It's time to
move on from the immensely limited HDL fileIO testbench model.

Thanks,

Chris

Mon Apr 12, 2010 2:12 pm   

On Apr 12, 6:49 am, Chris Higgs <chiggs...@googlemail.com> wrote:

Because it's just as productive to code models and deal with only one
language.


Perhaps you should adjust your mindset and consider that testbench
models are in no way limited to 'fileIO testbench models'.
Testbenches can use real models of real devices, it's not that hard.
Error injection handled easily as well. 'High level' scripting
languages don't necessarily have any inherent advantages, they're just
different languages.

KJ

Mon Apr 12, 2010 2:44 pm   

On Apr 12, 12:12 pm, KJ <kkjenni...@sbcglobal.net> 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. That's fine if you're doing some pipelined
transformation function where no re-ordering or dropping of data can
occur, but falls down with less rigid designs. The point is that HDLs
aren't well suited for writing complex testbenches. Yes, many things
are possible but in practice they are clunky and tend to balloon into
a mess. I've seen far too many unmaintained, overly complicated and
indecipherable testbenches written in HDLs. I've seen a several
thousand line VHDL package to generate ethernet frames. In python its
as simple as "from scapy.all import Ether; pkt=Ether()".

'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!

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 ;)

Thanks,

Chris

Mon Apr 12, 2010 3:03 pm   

On 11/04/2010 01:06, -jg wrote:

That occurred to me too. FPGA design is not limited to VHDL or Verilog
- there are many other options.

One of the challenges is finding a tool that has strong enough support
to be around for the future. Many years ago I did some FPGA (and CPLD)
work using confluence - I found it much easier to write compact and
correct code with confluence than with VHDL or Verilog. But the tool's
author dropped development to work on other projects (fair enough, I
suppose - he never claimed confluence to be anything other than free
development software). Although it was open source, it didn't have a
strong enough community to survive.

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.

Mon Apr 12, 2010 4:00 pm   

e.

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

Mon Apr 12, 2010 5:44 pm   

On Apr 12, 5:49 am, Chris Higgs <chiggs...@googlemail.com> wrote:


Well, I do. But for really basic stuff, I use Verilog.

Mon Apr 12, 2010 7:06 pm   

On Apr 12, 4:23 am, Jan Decaluwe <jandecal...@gmail.com> wrote:

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.


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.


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.


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

Mon Apr 12, 2010 8:46 pm   

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

Mon Apr 12, 2010 9:44 pm   

On 12 Apr, 12:44, Chris Higgs <chiggs...@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.

Mon Apr 12, 2010 10:04 pm   

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

Mon Apr 12, 2010 10:16 pm   

On Apr 12, 7:44 am, Chris Higgs <chiggs...@googlemail.com> wrote:

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.


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.


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.


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.


That's a good advantage to have too.

Kevin Jennings

Tue Apr 13, 2010 9:39 am   

On 12/04/2010 17:00, cfelton wrote:

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.

Tue Apr 13, 2010 11:16 am   

On Apr 12, 7:44 pm, Paul <pault...@googlemail.com> wrote:


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?

Tue Apr 13, 2010 1:45 pm   

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