UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
5,271 Views
Registered: ‎03-22-2017

HLS AXI4-lite problem in Linux

I created a module with Vivado HLS that has an AXI4-lite interface and I target a ZynqMP (ZCU102). The bare-metal execution (Vivado SDK) works fine, but it has problems in Linux.

 

If I try to read or write the AXI4-lite memory mapped registers, the entire board hangs.

 

For example, the AXI4-lite interface is mapped at 0x00_A000_0000 (it is a Cortex-A53). 

 
$ devmem2 0x00_A000_0000
 
-----> hangs the CPUs
 
Do you have any suggestion? 
0 Kudos
30 Replies
Voyager
Voyager
5,206 Views
Registered: ‎06-24-2013

Re: HLS AXI4-lite problem in Linux

Hey @gdg,

 

$ devmem2 0x00_A000_0000  ... hangs the CPUs

 

devmem2 does not understand the underscore in your address and will end up with an illegal address.

Try using devmem2 0xA0000000 Insted and make sure that the PL side is initialized properly, otherwise the access to one of the AXI master ports will certainly hang your system.

 

Hope this helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Explorer
Explorer
5,184 Views
Registered: ‎03-22-2017

Re: HLS AXI4-lite problem in Linux

@hpoetzl, when I wrote the post I copied and paste that address from the memory mapping in Vivado. But when I run devmem2 on the Linux (running on the board) I do not use underscores. And it still hangs.

 

The PL is configured properly. Or, at least, the same bitstream that works in bare-metal is loaded on the PL when the OS is running.

 

So the problem is still open...

0 Kudos
Scholar u4223374
Scholar
5,163 Views
Registered: ‎04-26-2015

Re: HLS AXI4-lite problem in Linux

@gdg The obvious question to ask is "does this only affect HLS blocks?"

 

I would suggest putting a VDMA and Test Pattern Generator (TPG) block in there and seeing if those work. The VDMA is HDL code; the TPG is a HLS block provided by Xilinx.

 

If neither works, there's something messed up with Linux or the commands you're using. If the VDMA works but the TPG does not, then there's something going on with HLS - and Xilinx has a major incentive to fix it since it breaks their own TPG block. If both work fine but your block does not then it's either something you're doing or a problem with the version of HLS you're using.

Adventurer
Adventurer
5,132 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@gdg which version of HLS and Vivado are you using? I'm having AXI4-lite slave issues with an HLS block that I wrote in 2017.2 as well. My board isn't hanging, but the bare metal system is correct  yet the devmem2 implementation returns garbage.

 

See this thread here, kinda smells like a similar issue

Explorer
Explorer
5,102 Views
Registered: ‎03-22-2017

Re: HLS AXI4-lite problem in Linux

@bigbrett, I am using 2017.1.

 

I will try @u4223374 suggestions.

 

 

0 Kudos
Adventurer
Adventurer
5,079 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@u4223374 @gdg I can now verify that I have the same issue, and it is not dependent on the internals of my HLS block...... I stripped out all complex logic from my HLS design, and replaced it with a simple test that just does something like:

*s_axi_lite_output_reg = one_of_my_s_axi_lite_input_regs 

I set ap_start =1 using devmem and the whole axi interface becomes unresponsive. If I set ap_start=1 using my kernel module, the kernel crashes and I assume the axi interface does as well.

 

Here is the devmem output on the PS:

 

# Read ap_ctrl
root@zedboard-zynq7:~# devmem2 0x43c00000 /dev/mem opened. Memory mapped at address 0xb6f5a000. Read at address 0x43C00000 (0xb6f5a000): 0x00000004
# set ap_ctrl=1 root@zedboard-zynq7:~# devmem2 0x43c00000 b 1 /dev/mem opened. Memory mapped at address 0xb6f64000. Read at address 0x43C00000 (0xb6f64000): 0x04 Write at address 0x43C00000 (0xb6f64000): 0x01, readback 0x01
# Read ap_ctrl after start root@zedboard-zynq7:~# devmem2 0x43c00000 /dev/mem opened. Memory mapped at address 0xb6f6b000. Read at address 0x43C00000 (0xb6f6b000): 0x00000001
# Read ap_ctrl again root@zedboard-zynq7:~# devmem2 0x43c00000 /dev/mem opened. Memory mapped at address 0xb6f07000. Read at address 0x43C00000 (0xb6f07000): 0x00000001
# Try to manually clear ap_start root@zedboard-zynq7:~# devmem2 0x43c00000 b 0 /dev/mem opened. Memory mapped at address 0xb6f3a000. Read at address 0x43C00000 (0xb6f3a000): 0x01 Write at address 0x43C00000 (0xb6f3a000): 0x00, readback 0x00 #readback looks ok
# Read ap_ctrl to make sure readback isn't lying (spoiler alert: it is) root@zedboard-zynq7:~# devmem2 0x43c00000 /dev/mem opened. Memory mapped at address 0xb6fe9000. Read at address 0x43C00000 (0xb6fe9000): 0x00000001 # <<< ap_start=1 still!

 

And yes, it does this when I write a word at a time as well, AND when I read-modify-write

 

Here is a screenshot of the BD. Just a simple HLS block tied to the PS.

The HLS block's AXI lite Address range begins at 0x43C00000

bd.png

 

0 Kudos
Scholar u4223374
Scholar
5,052 Views
Registered: ‎04-26-2015

Re: HLS AXI4-lite problem in Linux

I've brought these two threads to the attention of the Xilinx admins.

 

In order to make the bug-finding job easier for them, could you please provide some information about exactly what hardware/software is in use here?

 

@bigbrett - I see that you're on HLS 2017.2 (Windows or Linux?) and from your code it looks like you're most likely using a Zynq 7000 chip. Is this one of the standard Xilinx development boards? I assume that the Linux you're running on the board is Petalinux 2017.2?

 

@gdg - Vivado HLS 2017.1 (Windows or Linux?) and a ZCU102?

 

 

Explorer
Explorer
5,016 Views
Registered: ‎03-22-2017

Re: HLS AXI4-lite problem in Linux

@u4223374, I am using Vivado HLS 2017.1 on Linux (Ubuntu 16.x/17.x) and I am running it on a ZCU102 (Rev. 1.0 / ES 2). On the A53s I am running either the Petalinux rootfs or a customized Ubuntu image.

 

Thank you!

 

 

Adventurer
Adventurer
5,010 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@u4223374 Thank you, thank you, thank you!

 

I'm using Vivado and HLS 2017.2 on Ubuntu 16.04 LTS, kernel version 4.4.0-87-generic. I'm targeting the Zedboard. Linux that I'm running on the board is a Yocto Linux, using the meta-xilinx and meta-xilinx-tools layers.

 

Two important things that Xilinx might want to see:

  1. HERE is the simplest version of the design yet. It is just the vivado project, and the HLS project, where the HLS block is pure modular exonentiation and nothing else. The design works in bare metal, and I have verified that all the right data is being written to the block across the AXI bus. But both the kernel module and manually using devmem fail in the same way.
  2. HERE is the rootfs that I am using for my linux image (I don't know why this would be useful, but at least they can have it if they need it. At the very least examine /proc/config.gz to see my kernel build flags

 

Quoting from my other thread, in the embedded linux forum, which discusses the debugging steps I've taken so far:

 

I stripped out everything from the HLS block except for computing one single modular exponentiation operation (i.e. just encrypting the input data and returning it), and the same issue is present. However when I remove the modular exponentiation entirely, and just pass through a specific selection of the input values to the output, I am able to see the expected output from within linux. This would obviously point to something being wrong with my modular exponentiation function, however that can't be the case because it works in bare metal!

 

For example: I make the following changes to the top-level HLS function, it returns the expected answer (same as bare metal). I don't understand how the presence of the operating system would dictate whether or not one of the nested subfunctions in my HLS block works correctly??

 

void wsrsa1024(
		memword_t base_mem[NUM_MEMWORDS],
		memword_t publexp_mem[NUM_MEMWORDS],
		memword_t modulus_mem[NUM_MEMWORDS],
		memword_t result_mem[NUM_MEMWORDS])
{
	static uintRSA_t base,publexp,modulus,result;

	// Copy in the inputs from AXI memory (shift in, rather than using range operator because 
// otherwise HLS generates a bazillion LUTs for (int i=0; i<NUM_MEMWORDS; i++) { base.range(NUM_BITS-1,(NUM_BITS)-MEMWORD_SIZE) = base_mem[i]; publexp.range(NUM_BITS-1,(NUM_BITS)-MEMWORD_SIZE) = publexp_mem[i]; modulus.range(NUM_BITS-1,(NUM_BITS)-MEMWORD_SIZE) = modulus_mem[i]; // COMMENT THIS LINE OUT // result_mem[i] = 0; if (i!=NUM_MEMWORDS-1) { base >>= MEMWORD_SIZE; publexp >>= MEMWORD_SIZE; modulus >>= MEMWORD_SIZE; } } // I COMMENT OUT THE MODULAR EXPONENTIATION, ON THE NEXT LINE... // rsaModExp(base,publexp,modulus,&result); // perform modular exponentiation // AND INSTEAD REPLACE IT BY WRITING A PORTION OF THE INPUT TO THE OUTPUT result = modulus.range(31,0) + base.range(NUM_BITS-1,(NUM_BITS)-MEMWORD_SIZE); // copy outputs to AXI memory, using shift rather than range operator for (int i=0; i<NUM_MEMWORDS; i++) { result_mem[i] = result.range(NUM_MEMWORDS-1,0); if (i!=NUM_MEMWORDS-1) result >>= MEMWORD_SIZE; } }

 

 

 

Adventurer
Adventurer
4,706 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

Ok, big news!!! I figured out the exact point of failure under Linux, and managed to get the HLS block to work correctly! However, I don't know *why* or *how* this breaks/doesn't break the hardware, but only that it does. @u4223374 Please let me know if you have a good explanation for this behavior, otherwise it is still an open issue.....

 

The code below is my *ultra simplified* version that eventually revealed where the failure occurred. The algorithm has a running result variable (xbar) that constantly is updated based on the result of montgomery multiplication operations (the montMult() function....don't worry about what this does, its irrelevant, but shown below for reference).

 

I figured my last hope to debug what was going wrong would be to expose this internal variable to the top-level, so I could watch it on the ILA and compare its value after each loop iteration to the correct value (determined from print statements in simulation, and using an ILA on the bare-metal design). I removed the rsaModExp function from previous versions of the code, and manually inlined it into the top level function shown below. When I added in the line of code colored hot pink in the code below, the design miraculously worked!

 

Again, all I did was just write the value of the internal variable xbar to the top level port so I could view it on the ILA. This had the bizarre effect of causing the design to function correctly! When I tried to break it again, all I had to do was remove the write of the intermediate values (hot pink), and instead comment it out or set it to zero at the top of the function (shown in green). I then replicated this with a macro, so you can easily turn the behavior on and off before synthesizing.

 

The full code that works/doesn't work is shown below. If CORRECT_RESULT is set to 1, the design will work.

 

 

#define CORRECT_RESULT 1

const ap_uint<1025> r     = ap_uint<1025> ("179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216",10);
const ap_uint<1024> Mbar  = ap_uint<1024>("CAC00639454E47A7CDCA9033E4AD317E95421D6998C6DEFE79AE2246321BD1AD60CDABE20BA4154D1202EA2635E55C326F443311D267D8B69F989823676264904DBF2C73CADAC30BE1AA3964E12E61C64CBB5FDE42FE3A02F21D4C959F2209E4A2F7E5D7C3EFF321AF6A4878E0374ACF095CC07EB77C7EC3AF932C988890548F",16);
const ap_uint<1024> xbar0 = ap_uint<1024>("26B27761777AC22768965E7FEA5F5D19407D40CA901EB0DAE04B0A1D20F260656B5975CF3BD74C61CC9D04C8865B68131515C8EFF0D9B2804604E5680409DEECC21AA023464E52F285CE4C86DE9286DAD0A3AD846439C27C2B130B2E2BA3407BC17B8B45439AA16449866345885B815057C7D69B8B503DB414637DA48C140AB7",16);

void wsrsa1024encrypt( ap_uint<32> base_mem[32],
		           ap_uint<32> publexp_mem[32],
	 	           ap_uint<32> modulus_mem[32],
ap_uint<1024> *xbar_dbg, // THIS IS THE DEBUG PORT I ADDED TO COMPARE THE EVOLUTION OF XBAR THROUGHOUT THE LOOP, TO CHECK AGAINST A KNOWN RESULT ap_uint<32> result_mem[32]) { #pragma HLS ALLOCATION instances=montMult limit=1 function // Local values of the inputs and output ap_uint<1024> base, publexp, modulus, result=0; ap_uint<1024> xbar = xbar0; // local copy of the initial value of partial sum // IF WE SET THE DEBUG SIGNAL TO ZERO FOR THE DURATION OF THE FUNCTION, // AND DO NOT WRITE TO IT EVERY LOOP ITERATION, THEN THE END RESULT // RESULT WILL BE INCORRECT, AND DIFFERENT EVERY TIME #if (CORRECT_RESULT==0) *xbar_dbg=0; #endif // Copy in the inputs from AXI memory, by grabing top 32bit word and shifting down to prevent // HLS from putting in a bunch of extra LUTs for the MUXes for (int i=0; i<32; i++) { base.range(1023,992) = base_mem[i]; publexp.range(1023,992) = publexp_mem[i]; modulus.range(1023,992) = modulus_mem[i]; if (i!=31) { base >>= 32; publexp >>= 32; modulus >>= 32; } } // running partial sum for modular exponentiation. Initialized to the const value in ROM ap_uint<1024> xbar = xbar0; // compute montgomery modular exponentiation using square and multiply algorithm for (int i=1023; i>=0; i--) { montMult(xbar,xbar,modulus,&xbar); // square if (publexp.test(i)) { montMult(Mbar,xbar,modulus,&xbar); // multiply }
#if (CORRECT_RESULT==1) // WRITE INTERNAL DEBUG SIGNAL TO VIEW IN ILA, FOR EACH LOOP ITERATION. IF WE DONT // DO THIS, THEN THE DESIGN WILL BREAK *xbar_dbg = xbar; #endif } // undo montgomery transform montMult(xbar,1,modulus,&result); // copy outputs to AXI memory for (int i=0; i<32; i++) { result_mem[i] = result.range(31,0); if (i!=31) result >>= 32; } } // This is the helper function to perform mongomery multiplication, given for reference void montMult(ap_uint<1024> X0, ap_uint<1024> Y0, ap_uint<1024> M0, ap_uint<1024>* outData) { #pragma HLS ALLOCATION instances=mul limit=256 operation ap_uint<1026> S = 0; ap_uint<1026> X = X0, Y = Y0, M=M0; for (int i=0; i<1024; i++) { if (X.test(i)) { S += Y; } if (S.test(0)) { S += M; } S = S >> 1; } if (S >= M) S -= M; *outData = S.range(1023,0); }

 

@u4223374 do you have any idea why this behavior causes the HLS block to fail ONLY UNDER LINUX? That is what I can't wrap my head around......

 

 

 

Scholar u4223374
Scholar
4,684 Views
Registered: ‎04-26-2015

Re: HLS AXI4-lite problem in Linux

@bigbrett I must admit that I am at a loss to explain this behaviour!

 

All I can think of is that as Linux boots up, it's doing something that breaks the HLS blocks. HLS state machines do seem to be somewhat "fragile" - maybe Linux is issuing a reset while an AXI transaction is in progress (or something similar) and that's leaving the HLS block in a state that it can't recover from.

 

In any case, you've done some excellent troubleshooting there, which should make it very much easier for Xilinx's programmers to track down the bug.

0 Kudos
Adventurer
Adventurer
4,656 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@u4223374 Thats a good hypothesis. I did some investigating and couldn't detect any evidence of this though.

 

  • I reprogrammed the FPGA before each test, with Linux running the entire time, so it has nothing to do with linux boot-up.
  • Once the FPGA is configured, I monitored the ap_resetn signal with an ILA to ensure that it never went low. It doesn't.

So if something is corrupting the state machine, it must be happening right after the FPGA configuration, otherwise I should have seen it....

 

I can only hope Xilinx sees this soon.....this is a critical portion of my thesis, and my time is running out :O

0 Kudos
Explorer
Explorer
4,648 Views
Registered: ‎03-22-2017

Re: HLS AXI4-lite problem in Linux

@bigbrett, how are you reprogramming the fpga? Can you try from SDK, Vivado and the OS? It may be completely equivalent, but you may be lucky and find out that one of the three works.

0 Kudos
Voyager
Voyager
4,635 Views
Registered: ‎06-24-2013

Re: HLS AXI4-lite problem in Linux

Hey @bigbrett,

 

Ok, big news!!!

I don't want to spoil your excitement here, but ...

 

I figured out the exact point of failure under Linux,

Please elaborate where exactly it fails ... from your post, all I could extract is that exposing an internal variable to an external port miraculously 'made it work' ...

 

and managed to get the HLS block to work correctly!

I do not consider this a fix, although it might be a workaround to paper over a deeper issue/bug.

 

Is it still true that the bare metal app works as intended, even without the exposed variable?

If so, I'm still pretty confident that the problem is with the memory access or the caching and not the code.

 

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Adventurer
Adventurer
4,621 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@gdg I tried all three of those methods, and it unfortunately doesn't make a difference

 

 @hpoetzl:

Please elaborate where exactly it fails ... from your post, all I could extract is that exposing an internal variable to an external port miraculously 'made it work' ...

That is actually exactly what made it work. But it didn't make the whole design work, it just made the ultra simplified version return the correct result...which is significant because it's the first time that occurred running under linux. I removed a bunch of necessary functionality to reduce the complexity for debugging, and adding any of that back in causes the erroneous behavior to resume. So it's not a solved issue by any means, which is why I haven't marked it as solved. But I think this is indicative that something is causing a reset somewhere, and the registers are getting cleared.

 

Is it still true that the bare metal app works as intended, even without the exposed variable?

Yes, this is still true. The bare metal app works in both cases, because nothing about the underlying algorithm to compute modular exponentiation changed

 

If so, I'm still pretty confident that the problem is with the memory access or the caching and not the code.

 

Agreed, I can't think of anything else that would cause this behavior either. I was thinking it could be something architectural, maybe with the different ARM processor operating in a different mode under Linux, but I also don't see how that could effect something in the PL. After all, I watched all the right data come across the AXI bus on the ILA....everything in that regard looked fine.

 

I'm starting to think @u4223374 is onto something, with his hypothesis that an erroneous reset on the AXI bus, or something else might be braking HLS state machines somehow. 

0 Kudos
Voyager
Voyager
4,619 Views
Registered: ‎06-24-2013

Re: HLS AXI4-lite problem in Linux

@bigbrett,

 

I'm starting to think @u4223374 is onto something, with his hypothesis that an erroneous reset on the AXI bus ...

Not buying it. Why would a 'reset' matter without the exported variable but be fine when you export it?

 

If it isn't caching or access related, then in my opinion, the only other option is a subtle timing issue where modifying the design also changes the timing just enough to make it work ... by accident. Access from Linux might just be different enough from the bare metal version to trigger this.

 

Unfortunately I'm quite busy at the moment so I won't get to look into it before Monday or probably Tuesday.

 

All the best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Adventurer
Adventurer
4,566 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

Not buying it. Why would a 'reset' matter without the exported variable but be fine when you export it?

Because the HLS tool generates a fragile state machine, and an additional read/write to the top level port changes that generated state machine slightly....just slightly enough that the HLS block is now in a different state when the reset comes along (which always happens at a consistent point in the test code) and so handles it differently. Recall that I have an ILA in hardware, and verified that the correct inputs are indeed reaching the HLS block in PL. So this eliminates anything to do with caching, since the ILA is on the other side of the cache. Linux is indeed screwing things up, it is doing so in a way that isn't visible or obvious to someone living in the PL.

 

If it isn't caching or access related, then in my opinion, the only other option is a subtle timing issue where modifying the design also changes the timing just enough to make it work ... by accident. Access from Linux might just be different enough from the bare metal version to trigger this

I believe this is actually what @u4223374 is saying, and what I am thinking. Yes, Linux does something differently from the bare metal design. This is obviously the case, since the test fails under Linux but works in bare metal. But it is plausible that access from Linux is just slightly different enough that the HLS block's exported state machine can't handle it and breaks, or resets the values halfway through the computation of modular exponentiation. I think we are all saying the same thing, but @u4223374's hypothesis is just that the point of failure of the HARDWARE (in response to Linux accessing it differently) lies in the FSM generated by HLS. So the underlying reason for the failure is that Linux is accessing it differently, yes. However when code is added to the HLS block that might put it in a different state when that reset comes along, it would make sense that the hardware would behave differently.

 

Linux is doing things differently, but maybe the HLS block shouldn't fail in light if this difference. I'm going to attempt to look at the generated VHDL from the HLS block. It looks pretty cryptic, so I don't know what I'll be able to glean from it, but it is worth a shot.

 

And again, the design doesn't "work" by any means. I just was able to trick it into returning the correct result in that one case

 

0 Kudos
Moderator
Moderator
4,483 Views
Registered: ‎06-24-2015

Re: HLS AXI4-lite problem in Linux

Hi all,

 

We have intimated our factory to look into this issue.

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
Scholar u4223374
Scholar
4,469 Views
Registered: ‎04-26-2015

Re: HLS AXI4-lite problem in Linux

@nupurs Excellent, thanks for that. Please keep us updated!

 

I guess an interesting question to ask here is "if I was trying to design a PL block to detect whether the PS was running bare-metal or Linux, how would I do that?" Presumably the HLS block is doing exactly that, inadvertently. I can think of some options, but none of them really explain this behaviour, and most of them rely on things that @bigbrett isn't using (eg. AXI Masters and Zynq UltraScale+).

Adventurer
Adventurer
4,330 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

@hpoetzl Just wanted to ping you to see if you might have some time to check this out? I don't think that Xilinx will be able to look at it anytime soon, and I've investigated pretty much every possibility I could think of.

0 Kudos
Explorer
Explorer
4,256 Views
Registered: ‎03-22-2017

Re: HLS AXI4-lite problem in Linux

@bigbrett, after few weeks I had time to go back to this problem.

 

Let me summarize my situation when I opened this thread: any read/write operation on the memory mapped registers of the PL accelerator (AXI4-lite) was hanging the Linux (ZynqMP Ultrascale+, ZCU102).

 

Apparently, when we received the board, we assumed it was an engineering sample (ES), it was not (!), and I did not personally double check it. I just realized it yesterday when I restarted my project.

 

Thus, I downloaded the correct Petalinux BSP (Production), I recreated the Linux image, and the hanging problem disappeared. Now I am testing if the accelerator that works in baremetal is functionally correct when I run it from Linux.

 

I hope this may help you.

0 Kudos
Visitor vn2101
Visitor
3,721 Views
Registered: ‎01-30-2018

Re: HLS AXI4-lite problem in Linux

Hey @gdg,@

(1) Development Tools Version: Vivado 2017.2.

(2)chip mode:xczu3eg-sfva625-1L-i

(3)Engineering logic diagram:

1.png

4) MP SoC configuration:
Clock input 33.33MHz

1.png

Clock output PL0 = 100MHz

1.png

DDR configuration

1.png

(5) register module reg_wr_rd
a) How to generate
Tools --- Create and Package New IP --- Create AXI4 Peripheral.
b) register read and write
Defined eight registers, the value is fixed to 1-8 for testing, other parts of the code without any changes.

1.png

(6) Generate Bitstream
(7) File --- Export --- Export Hardware export hdf file to the Linux software engineer.
(8) use petalinux2017.2 tools, according to the hdf file to create a project, configure the project, compile the project, packaged to generate QSPI can boot BOOT.BIN (including the boot kernel dtb rootfs) file.

(9) Download the startup file to the QSPI FLASH through the SDK, set the DIP switch to the QSPI startup mode, and start the system normally. Go to the U-BOOT command line and read the register value through the "md" command. :

1.png

Now only the "0xa0000000" address and "0xa0000010" address read back the correct value, the other address value is 0.

10) We did an experiment, the ps clock output to a test point, the clock is 100MHz, but after the system is started, go through the oscilloscope to measure, then the clock is only 1MHz, PS output clock right now. The logic analyzer is not good at all.

 

 

0 Kudos
Visitor vn2101
Visitor
3,717 Views
Registered: ‎01-30-2018

Re: HLS AXI4-lite problem in Linux

hey,@

I have a same problem with you,My board isn't hanging,but writing and reading are not correct,Have you solved this problem? Or what good advice, I use the chip is xczu3eg-sfva625-1L-i。

0 Kudos
Adventurer
Adventurer
3,701 Views
Registered: ‎07-08-2016

Re: HLS AXI4-lite problem in Linux

Hi @vn2101,

 

I wish I could help, but I have not solved this problem, and have not received any more support from Xilinx. Last I heard, a bug report was filed. None of the professors or lab technicians at my university have been able to figure it out either. 

0 Kudos
Visitor vn2101
Visitor
3,693 Views
Registered: ‎01-30-2018

Re: HLS AXI4-lite problem in Linux

Hi@

0 Kudos
Highlighted
Visitor m.schappeit
Visitor
2,371 Views
Registered: ‎08-08-2018

Re: HLS AXI4-lite problem in Linux

Hi@and all!

 

 

 

Tags (3)
0 Kudos
Observer eshopper
Observer
2,273 Views
Registered: ‎03-27-2018

Re: HLS AXI4-lite problem in Linux

A hint or possible workaround from talking to a Xilinx Expert in Dublin could be to use the stub (drivers) of the bare metal run of HLS and (manually) make use of them also from Linux.

In another case proper and careful setup of the AXI access with respect Semaphores to avoid any possibility of conflicting register access has removed a similar behavior of Linux not producting  the same results as bare metal.

Admittedly only vague ideas but in lack of a solution and with feedback from XLX internals that this has been seen before I thought this input might be helpful.

It would probably be best if a test case with simplified code but reproducable behavior could be shared.

Regards

J.Hofmann

0 Kudos
Visitor m.schappeit
Visitor
2,246 Views
Registered: ‎08-08-2018

Re: HLS AXI4-lite problem in Linux

Hi everyone!

 

I solved my problem. It's really a stupid one. I can't say if it applies to other posts here. But I write it down here for reference.

 

Two problems occured on the same time:

1. At some point HLS seems to generate a faulty c-header file with register adresses ("$PACKAGENAME_hw.h"):

20180911_broken_register_defines.png

As you can see on the left side (working) everything is in some kind of order, but on the right side (broken) a address is mixed up in between. I can't tell why. But i know, this is the cause for the phenomenon, that my HLS package works in baremetal (left side in screenshot) and not in Linux (right side).

 

2. Of course I wrote a script, that copies in a pre-build-step the driver folder from zsys_wrapper_hw_platform_0 into my Linux project folder to use the generated driver files mith mmap in Linux. To be sure that I have all the time the most update files, even if hardware has changed.

Unfortunately during my debugging journey I switched from Ubuntu Vivado 2016.4 to Windows Vivado 2018.2.1 to see, it the problem is solved in a newer version of Vivado. From that time on my script was not working anymore... No more driver file updates....

 

So. Quite stupid isn't it? What can readers learn or try out? Check your register defines for the HLS Package. At least at some point I had a faulty one in my development flow.

 

I hope this helps.

 

Bye, Marc.

 

0 Kudos
Visitor m.schappeit
Visitor
2,226 Views
Registered: ‎08-08-2018

Re: HLS AXI4-lite problem in Linux

Addendum:

 

I think I found the root cause that introduced all the trouble:

At some point I renamed a variable in HLS from 'd' to 'dist' (a more speaking name for 'distance'). This worked in Synthesis and Simulation. But only made problems then in co-simulation.

'dist' is a keyword in system verilog (but I use verilog!), which seems to confuse at least one tool in the design flow...

 

@ Xilinx developers: request for improvement: I think it would be a great idea to forbid to use HDL keywords as variable names during c-code entry in the HLS-IDE in the first place. Some keywords are of course obvious to avoid. But “dist” proves the contrary (haven't heard of it before).

 

Thanks for listening. Bye, Marc.

 

0 Kudos