/home/tom/vivado/ip_repo/s9_leds_1_1/hdl -rw-r--r-- 1 tom tom 15672 Dec 3 20:34 s9_leds_v1_0_S00_AXI.v -rw-r--r-- 1 tom tom 2213 Dec 3 20:34 s9_leds_v1_0.vThe second (smaller) file can be left be. We make changes in the bigger file. We change our ID number as follows:
slv_reg0 <= 32'hdead0002;Now the "0002" serves as a version number at lets us verify that the bitstream we load contains the latest changes. Also, we add the following line:
assign slv_reg3 = slv_reg1 + slv_reg2;We can just tack this on the end because this is verilog and this is a continuous assignment. When the inputs change, the outputs will change.
First attemp -- Vivado does tell me to refresh the IP catalog.
I tell it to run synthesis. It tells me that it is up to date and asks me if I want to run it anyway. I do.
Now I run implementation and create the bitstream.
In Kyu, I have the following in my Makefile:
get_bit:
cp /u1/home/tom/vivado/s9_junk2/s9_junk2.runs/impl_1/design_1_wrapper.bit s9.bit
So I can type "make get_bit, make, and reboot.
I do not see the expected ID number, so this did not get the changes to the IP. Second attempt -- I try editing component.xml and bumping the version to 1.1 Now I try again. Once again the "run synthesis" tells me I an wasting time, but again I insist. This did not work either. Third attempt -- open the block model, delete the block, then use the big "+" to add it again. Now run synthesis doesn't warn me that I am wasting time. But it fails, warning me that I am assigning to a "non-net" object in my assign statement. Well at least it is paying attention to my edits now! I change my additions to this:
always @(*)
begin
slv_reg3 <= slv_reg1 + slv_reg2;
end
And I run synthesis again. I was imitating a design that declared slv_reg3 as a "wire", but my
vivado generated a "reg". Again I need to delete the block, add it again, then run synthesis.
It now warns me that slv_reg3 is "multi-driven", which sounds entirely true. The synthesis
does finish successfully. But this causes the implementation to fail.
Well, I was suspicious about the concept of just adding my changes to the end of the file.
I comment out this line, and try again:
// slv_reg3 <= slv_reg3;This does not fix the problem. My new idea is to write to reg3 whenever I see the host write to reg1 or reg2 -- so when reg1 gets updated, so does reg3, and likewise when reg2 gets updated. The code looks like this (in two places):
for ( byte_index = 0; byte_index <= (C_S_AXI_DATA_WIDTH/8)-1; byte_index = byte_index+1 )
if ( S_AXI_WSTRB[byte_index] == 1 ) begin
// Respective byte enables are asserted as per write strobes
// Slave register 1
slv_reg1[(byte_index*8) +: 8] <= S_AXI_WDATA[(byte_index*8) +: 8];
slv_reg3 <= slv_reg1 + slv_reg2;
end
Now I can generate a bitstream. And I see the correct "dead0002" ID, I try an add and see
strange behavior (the add happens later than expected) I make this change -- so that the first
assignment is a blocking assignment:
for ( byte_index = 0; byte_index <= (C_S_AXI_DATA_WIDTH/8)-1; byte_index = byte_index+1 )
if ( S_AXI_WSTRB[byte_index] == 1 ) begin
// Respective byte enables are asserted as per write strobes
// Slave register 1
slv_reg1[(byte_index*8) +: 8] = S_AXI_WDATA[(byte_index*8) +: 8];
slv_reg3 <= slv_reg1 + slv_reg2;
end
This does the trick. In the first case the add was taking place simultaneously and thus
using stale data. Success. Time for bed.
Tom's Computer Info / tom@mmto.org