I'd rather switch than fight!
in [FPGA]
|
From: Chris Higgs on 13 Apr 2010 04:16 On Apr 12, 7:44 pm, Paul <pault...(a)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. 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?
From: David Brown on 13 Apr 2010 04:39 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. > 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.
From: cfelton on 13 Apr 2010 08:45 >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) > 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. @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
From: Chris Higgs on 13 Apr 2010 09:15 On 13 Apr, 13:45, "cfelton" <cfelton(a)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. Thanks, Chris
From: Paul on 13 Apr 2010 16:01
On 13 Apr, 14:15, Chris Higgs <chiggs...(a)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. 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. 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. |