Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
818 Views

Avalon Verification; readdatavalid assertion failures

Hi all, 

 

I'm in the process of using Altera's Verification IP to check out whether some custom slaves and masters work correctly. 

 

I was quite surprised to find Altera's own IP would fail assertion tests! Eg. In a system consisting of an Avalon-MM BFM master, an Avalon-MM Monitor, a PIO slave and an LCD slave, accesses to either the PIO or LCD generate assertion failures. The problem is that the SOPC fabric asserts readdatavalid at the monitor master interface (which connects to the slaves) during the same clock as waitrequest deasserts. The Avalon Interface specification comments on the readdatavalid timing requirement in Table 3-1 on p3-4 (there must be a cycle of latency between the read being accepted, i.e., read asserted and waitrequest low, and readdatavalid asserting) and then shows the required timing in Figure 3-5 on p3-10. This timing is violated when the Avalon signals are probed at the master interface of the monitor (when the access is to a slave that does not use the readdatavalid signal; the fabric creates it for those types of slaves). 

 

Since the Avalon-MM monitor is generating assertion failures, the rule for the slave in Table 3-1 is being applied to the Monitor master interface, however, the rules for the master signals in Table 3-4 on p3-21 do not have the same comment regarding readdatavalid assertion. Its quite possible there is a subtle distinction here. However, if this were the case, then SOPC builder should not put logic between the monitor and slaves it is supposed to be monitoring! Gotta love ambiguity in specifications! 

 

I wrote a simple slave model and parameterized its use of readdatavalid and the latency between when waitrequest is deasserted and readdatavalid is asserted. Feel free to download the attached zip file and check it out (the readme.txt describes how to regenerate the SOPC system and simulate it). This simulation clearly shows the problem is the arbiter fabric created between the slaves and the monitor. 

 

This is a mixed language design example; VHDL for my components, and the Altera Verification IP is in Verilog/SystemVerilog, so you need Modelsim SE to run this and see the assertion errors. I've copied the tail end of the errors below. The assertion failures for; 

 

* waitrequest during reset are due to the SOPC fabric, not my custom component 

* the byteenable assertion is deliberate (it shows that my version of Modelsim SE supports SVA) 

* the readdatavalid failures are what concerns me 

 

The zip file has a PDF of the simulator output, so you can always look at it. The example also shows how to write a SOPC builder _hw.tcl file for a custom component. 

 

I've been waiting on an SR for a couple of days. I wrote this test case to encourage a response from Altera on the problem. 

 

Perhaps others on this list can share any experience they have had in this area. 

 

Cheers, 

Dave 

 

 

# 220000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: waitrequest must be asserted while reset is asserted 

# 230000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: waitrequest must be asserted while reset is asserted 

# REG0: Test invalid access (invalid byte enables). 

# 310000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: byteenable has an illegal value 

# REG1: Test invalid access (invalid byte enables). 

# 550000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: byteenable has an illegal value 

# 550000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: readdatavalid must be asserted after read command 

# REG0: Test valid accesses (byte enables asserted). 

# REG1: Test valid accesses (byte enables asserted). 

# 1130000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: readdatavalid must be asserted after read command 

# 1150000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: readdatavalid must be asserted after read command 

# 1170000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: readdatavalid must be asserted after read command 

# 1190000: FAILURE: ASSERTION: reg_verify_tb.tb.DUT.the_monitor_0.monitor_0.master_assertion.print_assertion: readdatavalid must be asserted after read command 

# Simulation complete. 

# Break in Module reg_verify_tb at reg_verify_tb.v line 181
0 Kudos
0 Replies