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: 
Highlighted
Visitor piflodrops
Visitor
1,412 Views
Registered: ‎04-25-2017

Multiple Interface definition in the source code for the same port

Jump to solution

Hi,

 

I am currently working an a old project that somebody else than me did a couple of years ago (vivado hls 2015.2) and I am facing some problems...

In the following function, the person wrote:
void my_function (  uint32 *buffer_in, uint32 *buffer_out, struct struct_reg *reg ){

 

#pragma HLS INTERFACE axis register port=buffer_in

#pragma HLS INTERFACE axis register port=buffer_out

 

#pragma HLS INTERFACE s_axilite port=reg
#pragma HLS INTERFACE ap_none port=reg

 

/*..... and the rest of the code ...*/

}

 

with:

struct struct_reg {
uint64 a;
uint64 b;
};

 

 

Because there are 2 INTERFACE definitions for port 'reg', I have no idea how Vivado HLS synthetise the interface.

 

When I watch the synthesis report, I never see that the port 'reg' has been synthetise.

And also, when I look how the IP is designed in IP integrator on Vivado, there is absolutly no port 'reg'. 

So my question is, do you know how the tool manage to synthetise port 'reg' in such a case? Does it become an internal register or something like that ?

 

When I watch the vivado_hls.log after synthesis, I get:

@I [RTGEN-500] Setting interface mode on port 'my_function/reg_a' to 's_axilite & ap_none'.
@W [RTGEN-101] Port 'reg_a' with mode 'ap_none' may require an associated data valid signal to correctly communicate with other blocks or a test bench; automatic C/RTL co-simulation may not be able to verify such a port.

 

Thanks for your help. Hope I've been clear enought.

 

Pierre

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Voyager
Voyager
1,884 Views
Registered: ‎06-24-2013

Re: Multiple Interface definition in the source code for the same port

Jump to solution

Hey Pierre,

 

So my question is, do you know how the tool manage to synthetise port 'reg' in such a case?

Yes, let me explain what happens here ...

 

First, HLS interprets struct elements as ports, unless you force it to combine them.

So 'reg' with elements 'a' and 'b' will end up as 'reg_a' and 'reg_b' ports.

 

Without any INTERFACE #pragma (or directive) the interface for reg would simply become ...

    reg_a : IN STD_LOGIC_VECTOR (63 downto 0);
    reg_b : IN STD_LOGIC_VECTOR (63 downto 0);

... with the default handshake for the function return.

 

The first INTERFACE #pragma changes that into an AXI-Lite register mapped interface with the following register layout ...

-- ------------------------Address Info-------------------
-- 0x00 : reserved
-- 0x04 : reserved
-- 0x08 : reserved
-- 0x0c : reserved
-- 0x10 : Data signal of reg_a
--        bit 31~0 - reg_a[31:0] (Read/Write)
-- 0x14 : Data signal of reg_a
--        bit 31~0 - reg_a[63:32] (Read/Write)
-- 0x18 : reserved
-- 0x1c : Data signal of reg_b
--        bit 31~0 - reg_b[31:0] (Read/Write)
-- 0x20 : Data signal of reg_b
--        bit 31~0 - reg_b[63:32] (Read/Write)
-- 0x24 : reserved
-- (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on Handshake)

... note that HLS already reports (at least for recent HLS) ...

INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_a' to 's_axilite & ap_none'.
INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_b' to 's_axilite & ap_none'.

... which means that 'ap_none' was automatically added to 's_axilite'.

 

So the second INTERFACE #pragma is redundant here, but let's see what happens if we change that to ...

#pragma HLS INTERFACE ap_vld port=reg

... HLS will now report ...

INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_a' to 's_axilite & ap_vld'.
INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_b' to 's_axilite & ap_vld'.

... and the register layout will adapt to ...

-- ------------------------Address Info-------------------
-- 0x00 : reserved
-- 0x04 : reserved
-- 0x08 : reserved
-- 0x0c : reserved
-- 0x10 : Data signal of reg_a
--        bit 31~0 - reg_a[31:0] (Read/Write)
-- 0x14 : Data signal of reg_a
--        bit 31~0 - reg_a[63:32] (Read/Write)
-- 0x18 : Control signal of reg_a
--        bit 0  - reg_a_ap_vld (Read/Write/SC)
--        others - reserved
-- 0x1c : Data signal of reg_b
--        bit 31~0 - reg_b[31:0] (Read/Write)
-- 0x20 : Data signal of reg_b
--        bit 31~0 - reg_b[63:32] (Read/Write)
-- 0x24 : Control signal of reg_b
--        bit 0  - reg_b_ap_vld (Read/Write/SC)
--        others - reserved
-- (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on Handshake)

... with two extra addresses where you can confirm that the provided data is 'valid'.

 

In general, you can always set a handshake related INTERFACE #pragma together with a protocol/interface related one, as long as there is some kind of handshake in this protocol.

 

The warning you get at the end that 'ap_none' might cause problems with verification and co-simulation is because there is no good way for the code to know when the data changed, because there is no handshake.

 

Hope this clarifies,

Herbert

-------------- Yes, I do this for fun!
3 Replies
Voyager
Voyager
1,885 Views
Registered: ‎06-24-2013

Re: Multiple Interface definition in the source code for the same port

Jump to solution

Hey Pierre,

 

So my question is, do you know how the tool manage to synthetise port 'reg' in such a case?

Yes, let me explain what happens here ...

 

First, HLS interprets struct elements as ports, unless you force it to combine them.

So 'reg' with elements 'a' and 'b' will end up as 'reg_a' and 'reg_b' ports.

 

Without any INTERFACE #pragma (or directive) the interface for reg would simply become ...

    reg_a : IN STD_LOGIC_VECTOR (63 downto 0);
    reg_b : IN STD_LOGIC_VECTOR (63 downto 0);

... with the default handshake for the function return.

 

The first INTERFACE #pragma changes that into an AXI-Lite register mapped interface with the following register layout ...

-- ------------------------Address Info-------------------
-- 0x00 : reserved
-- 0x04 : reserved
-- 0x08 : reserved
-- 0x0c : reserved
-- 0x10 : Data signal of reg_a
--        bit 31~0 - reg_a[31:0] (Read/Write)
-- 0x14 : Data signal of reg_a
--        bit 31~0 - reg_a[63:32] (Read/Write)
-- 0x18 : reserved
-- 0x1c : Data signal of reg_b
--        bit 31~0 - reg_b[31:0] (Read/Write)
-- 0x20 : Data signal of reg_b
--        bit 31~0 - reg_b[63:32] (Read/Write)
-- 0x24 : reserved
-- (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on Handshake)

... note that HLS already reports (at least for recent HLS) ...

INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_a' to 's_axilite & ap_none'.
INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_b' to 's_axilite & ap_none'.

... which means that 'ap_none' was automatically added to 's_axilite'.

 

So the second INTERFACE #pragma is redundant here, but let's see what happens if we change that to ...

#pragma HLS INTERFACE ap_vld port=reg

... HLS will now report ...

INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_a' to 's_axilite & ap_vld'.
INFO: [RTGEN 206-500] Setting interface mode on port 'my_function/reg_b' to 's_axilite & ap_vld'.

... and the register layout will adapt to ...

-- ------------------------Address Info-------------------
-- 0x00 : reserved
-- 0x04 : reserved
-- 0x08 : reserved
-- 0x0c : reserved
-- 0x10 : Data signal of reg_a
--        bit 31~0 - reg_a[31:0] (Read/Write)
-- 0x14 : Data signal of reg_a
--        bit 31~0 - reg_a[63:32] (Read/Write)
-- 0x18 : Control signal of reg_a
--        bit 0  - reg_a_ap_vld (Read/Write/SC)
--        others - reserved
-- 0x1c : Data signal of reg_b
--        bit 31~0 - reg_b[31:0] (Read/Write)
-- 0x20 : Data signal of reg_b
--        bit 31~0 - reg_b[63:32] (Read/Write)
-- 0x24 : Control signal of reg_b
--        bit 0  - reg_b_ap_vld (Read/Write/SC)
--        others - reserved
-- (SC = Self Clear, COR = Clear on Read, TOW = Toggle on Write, COH = Clear on Handshake)

... with two extra addresses where you can confirm that the provided data is 'valid'.

 

In general, you can always set a handshake related INTERFACE #pragma together with a protocol/interface related one, as long as there is some kind of handshake in this protocol.

 

The warning you get at the end that 'ap_none' might cause problems with verification and co-simulation is because there is no good way for the code to know when the data changed, because there is no handshake.

 

Hope this clarifies,

Herbert

-------------- Yes, I do this for fun!
Visitor piflodrops
Visitor
1,322 Views
Registered: ‎04-25-2017

Re: Multiple Interface definition in the source code for the same port

Jump to solution

Hi Herbert,

 

Thank you for your answer which is really complete and clear!!!!

 

Everything seems clear now for me!

 

Thank you again.

 

Pierre

0 Kudos
Voyager
Voyager
1,292 Views
Registered: ‎06-24-2013

Re: Multiple Interface definition in the source code for the same port

Jump to solution

You're welcome!

 

All the best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos