I'd rather switch than fight!
in [FPGA]
|
From: fpgabuilder on 12 Apr 2010 12:32 > > How comfortable are you with most-significant bits being > silently lost when you copy a wide vector into a narrow > one? How about signed values being silently zero-filled > to the width of a wider target? > I always ran into this problem at my old employer as there wasn't strict enforcement of coding guidelines. But I never tripped on it in a messy way because the tools always caught the problem as a warning (not an error). And they were pretty consistent about it. One aspect of the learning the language I found quite useful was that I thought of coding with the language as if I was drawing a schematic with it. I filtered all the new knowledge about the language through this fundamental premise. Here Palnitkar's book really helped me. Ofcourse at that time verilog 2001 was just getting a lot of attention.
From: Paul on 12 Apr 2010 14:44 On 12 Apr, 12:44, Chris Higgs <chiggs...(a)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 ;) 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.
From: KJ on 12 Apr 2010 15:16 On Apr 12, 7:44 am, Chris Higgs <chiggs...(a)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. 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. 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! > 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). 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. > That's a good advantage to have too. Kevin Jennings
From: cfelton on 12 Apr 2010 15:46 >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. > > My guess would be which ever Python to HDL simulation method you use there would be some learning curve for the interface. With MyHDL there is very little you need to learn to write your testbenches. Most everything can be accomplished with basic Python. Also, the MyHDL group is very helpful if you need assistance or run into trouble. Even if you are only interested in writing testbenches in MyHDL I believe 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 been used with commercial simulators such as ModelSim. .chris --------------------------------------- Posted through http://www.FPGARelated.com
From: cfelton on 12 Apr 2010 17:04
>There are scripts available to run/control the FPGA tools from Python. >Mainly consists of executing the correct cli commands. > Should say, Python scripts are available on the web, not part of MyHDL, for controlling the various vendors tools. .chris --------------------------------------- Posted through http://www.FPGARelated.com |