upgrade ip (system.bd) from rpad

[pita]

Hi Nils

..or someone else who is familiar with this:
When I tried a "make build/fpga.bit" in the Redpitaya_ddrdump repository,
vivado gripes about system.bd version and locks it:

Code: Select all

red@pitaya:~/redpitaya/RedPitaya_ddrdump$ make build/fpga.bit
make -C FPGA
make[1]: Entering directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA'
make -C release1/fpga FPGA_TOOL=vivado fpga
make[2]: Entering directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga'
vivado -mode tcl -source $PWD/run_vivado.tcl -tclargs build

****** Vivado v2015.4 (64-bit)
  **** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
  **** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
    ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.

source /home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga/run_vivado.tcl
# open_project ./vivado/red_pitaya.xpr
Scanning sources...
Finished scanning sources
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1704] No user IP repositories specified
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository '/opt/Xilinx/Vivado/2015.4/data/ip'.
WARNING: [BD 41-1661] One or more IPs have been locked in the design 'system.bd'. Please run report_ip_status for more details and recommendations on how to fix this issue.
List of locked IPs:
system_xlconcat_0_0
system_processing_system7_0_0

# update_compile_order -fileset sources_1
# if {[lindex $argv 0] == "clean"} {
#    ## clean implementation
#    reset_run impl_1
# 
#    ## clean synthesis
#    reset_run synth_1
# 
#    ## clean PS project configuration
#    reset_target all [get_files  ./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd]
# }
# if {[lindex $argv 0] == "build"} {
# 
#    ## export PS configuration
#    generate_target all [get_files  ./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd]
#    open_bd_design ./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd
#    export_hardware [get_files ./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd]
#    close_bd_design system
# 
#    ## do synthesis
#    launch_runs synth_1
#    wait_on_run synth_1
# 
#    ## do implementation
#    launch_runs impl_1
#    wait_on_run impl_1
# 
#    ## make bit file
#    launch_runs impl_1 -to_step write_bitstream
#    wait_on_run impl_1
# }
CRITICAL WARNING: [filemgmt 20-1365] Unable to generate target(s) for the following file is locked: /home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga/vivado/red_pitaya.srcs/sources_1/bd/system/system.bd
Locked reason: 
* BD design contains locked IPs. Please run report_ip_status for more details and recommendations on how to fix this issue. 
List of locked IPs: 
system_xlconcat_0_0
system_processing_system7_0_0

Adding component instance block -- xilinx.com:ip:processing_system7:5.3 - processing_system7_0
Adding component instance block -- xilinx.com:ip:xlconcat:1.0 - xlconcat_0
Successfully read diagram <system> from BD file <./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd>
invalid command name "export_hardware"
    while executing
"export_hardware [get_files ./vivado/red_pitaya.srcs/sources_1/bd/system/system.bd]"
    invoked from within
"if {[lindex $argv 0] == "build"} {

   ## export PS configuration
   generate_target all [get_files  ./vivado/red_pitaya.srcs/sources_1/bd/system/syst..."
    (file "/home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga/run_vivado.tcl" line 42)
Vivado% quit
INFO: [Common 17-206] Exiting Vivado at Wed Feb 24 22:32:13 2016...
make[2]: Leaving directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga'
make -C release1/fpga FPGA_TOOL=vivado sw_package
make[2]: Entering directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga'
sed -i 's/C_SDIO_CLK_FREQ_HZ\"\ VALUE=\"50000000/C_SDIO_CLK_FREQ_HZ\"\ VALUE=\"125000000/' vivado/red_pitaya.sdk/SDK/SDK_Export/hw/system.xml
sed: can't read vivado/red_pitaya.sdk/SDK/SDK_Export/hw/system.xml: No such file or directory
make[2]: *** [hw_src_copy] Error 2
make[2]: Leaving directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA/release1/fpga'
make[1]: *** [release1/fpga/vivado/red_pitaya.sdk/SDK/SDK_Export/fsbl/Debug/fsbl.elf] Error 2
make[1]: Leaving directory `/home/red/redpitaya/RedPitaya_ddrdump/FPGA'
make: *** [build/fpga.bit] Error 2

SoI opened up the system.bd file in Vivado gui
to upgrade IPs /xlconcat_0 and /processing_system7_0_0 to newer major versions.

That wasn't such a good idea as now..
Vivado tells me: "Dectected external port difference while upgrading IP system_processing_system7_0_0".
Moreover - according to above - it seems in 2015.4 there's no longer export_hardware command..

Would it be possible to fix this ?


Best regards
pita

[Nils Roos]

Hi,

I have not yet tried to migrate the IPs to 2015.4 Vivado. Porting them to 2014.2 required minor modifications (though some were not easy to find).

I'll give it a go, probably over the weekend.

[Nils Roos]

Moreover - according to above - it seems in 2015.4 there's no longer export_hardware command..

write_hwdef does something similar.

But while migrating the FPGA logic to 2015.4 is (probably) possible, you will need the 2013.3 SDK to build the remainder of the software. Xilinx changed the way the support libraries are generated with the 2014 releases, and you will have to change pretty much everything in the project to make the ddrdump branch build completely in the v0.94 development environment.

My recommendation would be to plug a pre-generated FPGA bitstream into the 0.94 build process and don't bother with the remainder of the old ecosystem. And you already figured out how to get rpad.ko onto the new system.

[pita]

Oh - this is really just a matter of the Xilinx version ?!
That's funny, why is Vivado not backwards-compatible regarding this.. ts ts ts..

Hm... the longer I'm thinking about this..
it is very very kind of You that You'd offer me and other people this possibility !! Thank You !!
But if it works with the 2013.4 I don't wanna be the one who ruins Your weekend hihi.
I'll try get the 2013.4, save Your weekend for... other stuff !


Cheers !
pita

[Nils Roos]

My recommendation would be to plug a pre-generated FPGA bitstream into the 0.94 build process

Just using the ddrdump Verilog code - like you already suggested - is of course the best option. Sorry, didn't see the forest for the trees there I'll see what I can do^^

I'll try get the 2013.4, save Your weekend for... other stuff !

Very thoughtful of you, but this is what I do for fun, actually.

And the recommended version would be 2013.3, I never tried 2013.4, so no guarantees.

[pita]

My recommendation would be to plug a pre-generated FPGA bitstream into the 0.94 build process

The thing is:
Last week I tried sampling 4.000.000 samples with the rpad driver and
there were slight discontinuities (phase changes) in the signal when connecting a 1kHz source
to channel A.

At this point I am still unsure what it is:
- Maybe its the sampling buffer from rpad which might be too short (0x400000)
- or it could also be the Arm CPU that's too slow for copying samples to another buffer location in ddr memory
while the FPGA (PL) keeps spinning round that buffer. If it's that I needed to be able to update fpga stuff.

Will try fixing this.

[Nils Roos]

Last week I tried sampling 4.000.000 samples with the rpad driver and
there were slight discontinuities (phase changes) in the signal when connecting a 1kHz source
to channel A.

At this point I am still unsure what it is

At what speed (decimation factor) did you run the acquisition ? And how did you read the data and what did you do with them afterwards ? Depending on these factors it is certainly possible that you have been overtaken by the writing.

In other news, I reviewed the changes and migrated the IPs to 2015.4 Vivado, and the same set of modifications that I found for 2014.2 is still sufficient to build the logic successfully. Next I'll put in some small extensions, like a control flag to stop recording when reaching the end of the buffer and a 14bit legacy option.

[pita]

In other news, I reviewed the changes and migrated the IPs to 2015.4 Vivado

Cool ! Thank you very much !!!

Okay what I did was/is the following:

Code: Select all

- handle_rpad = fopen("/dev/rpad_scope0", "r"); 
- rp_set_params():  TRIG_MODE_PARAM=2 (SINGLE), TIME_RANGE_PARAM=1 (-> decimation factor 8) 
- fread(data, sizeof(int16_t),1024*1024,handle_rpad);  // record 1024*1024*int16_t samples -> 1MB
- transmit data via TCP/IP to matlab 
- plot in matlab. 

This is what I get then (matlab figure/image) for a 1kHz sine wave input at CH_A:

http://s000.tinyupload.com/?file_id=077 ... 1430617937


For a decimation of 64 I nearly get the same results. (regarding broken samples)
I also found that - in the fpga code - there's no real stop criteria.
Neither for the scope, nor for axi_master.v.
That would also mean that while looping rount the circular DDR buffer the axi_master
might cause discontinuities at the junctions between old data (from last loop-around) and new data.
Or am I wrong with that ?
I'll try to ... yeesss what You said .. maybe I (we) should add a stop criteria for the axi_master.v somewhere
where it says:

Code: Select all

if (start_new_tx & (buf_newready[0] | buf_newready[1])) begin
    if (ddr_a_next >= ddr_a_end_i) begin
        ddr_a_curr <= ddr_a_base_i; // stop here. 
    end else begin
    ddr_a_curr <= ddr_a_next;
    end
end else if (ddr_control_i[2]) begin
    ddr_a_curr <= ddr_a_base_i;
end else begin
    ddr_a_curr <= ddr_a_curr;
end

[Nils Roos]

Code: Select all

- rp_set_params():  TRIG_MODE_PARAM=2 (SINGLE), TIME_RANGE_PARAM=1 (-> decimation factor 8) 

You mean the rp_set_params() from Applications/scope/src/main.c ?
That's - uh - a surprise, mixing functions from the original applications with the rpad driver is outright dangerous.

If you did not call rp_app_init() before, rp_set_params() is a no-op. I am not implying that you should, though, just get rid of anything from the non-rpad-related sources. Unexpected behaviour, up to and including crashes might occur otherwise. You can copy any initialisation and configuration code - or data transfer functions, for that matter - from rp_remote_acquire.

For a decimation of 64 I nearly get the same results. (regarding broken samples)

Not surprising, since you probably don't actually set a different decimation with the rp_set_params() call.

[...] Or am I wrong with that ?

You are quite right. And because you use fread() to get the data, it is even more likely to happen since this is the slowest option to read the data.

maybe I (we) should add a stop criteria for the axi_master.v somewhere where it says: [...]

I did just that over the weekend. Not committed to the repo yet, I didn't have time to test.

[pita]

That's - uh - a surprise, mixing functions from the original applications with the rpad driver is outright dangerous.

Hehe yes I know. It was just the most comfortable way of doing it quick.

If you did not call rp_app_init() before..

I DID call rp_app_init() before and I was also able to see the changes in time scaling while changing the decimation factor.
So it works, but You're of course right in saying it's a dirty way of mixing code snippets.

Ah okay - I didn't know about this rp_remote_acquire.
I see it's using mmap(), yes that might be faster than copy_to_user().
I'll try merging this into my code.


Many thanks and Best regards
pita