From: Cary R. <cy...@ya...> - 2008-01-10 21:13:02
|
I have a fix for the problem reported in pr1867161, but I would like some feedback if this is an appropriate solution. The fundamental problem is that the right shift b<<3 is using index 0 and the immediate value add is also using index 0. The assert appears to be catching this double use of the same index 0 (overwrite) My solution, all in tgt-vvp/eval_expr.c, is to move the index 0 load out of draw_load_add_immediate() and into draw_signal_dest() just before the %load. This left one other problem in that this construct is doing an array access with a constant increment. This is a combination of %load/av and %load/vp0. In that spirit I created a new %load/avp0. This does an array access with an immediate add using index 0 for the value to add like /vp0 and index 3 for the array element to access like /av. My preliminary patch is attached. It passes the current test suite. The second problem which is not noticeable until a after the assert is fixed/bypassed is that invalid results will be calculated for some array accesses. The problem is that if the net used to calculate the offset from the base index is not large enough to contain the largest index value you will get incorrect results. This is because the addition is done at the width of the offset, not the width of the maximum array index. So reg [31:0] array [10:5]; reg [2:0] offset; array[5+offset] = 0; would only work correctly for array elements 5, 6 and 7 since they are the only indexes that fix in 3 bits. My thought on a solution is to enhance %load/vp0 and now /avp0 to take an additional parameter that is the final width. The addition and any padding would be done at that width. This means /vp0 and /avp0 would auto pad. Let me know if all this sounds reasonable. Cary ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping |