ContributionsMost RecentMost LikesSolutionsRe: Simple standalone IP using oneAPI? Alright, I got to read the example, and there are several unclear issues to me. Yes, it appears like I can attach this adder IP to some memory mapped host interface. I can also export this OutputPipe (sourcecode) class to a mysterious memory mapped agent interface (called add_report_di_0_csr_ring_root_avs), but only drivers and software will (may?) explain how this mapping works out. As a mainly FPGA skilled man, I honestly did not expect a pipe to instantiate as a memory mapped interface. There is a lot of mystery in this. Since I (at this time) care less about hooking the IP to a memory mapped host, I would like to know how I can get scalar IO (both in and out), and HLS compatible stream interfaces, also both in and out from oneAPI coding. Keep in mind I want to write code that mainly resolves to II=1, so memory mapping interfaces are not very interesting. Also, I am curious to know what is, and how I can control the IRQ sender and exception bus that is generated from the code. Can you help? Should I just stay with HLS for what I want to do? Best regards, Re: Simple standalone IP using oneAPI? Thanks BB. You example design link looks very interesting. I will dig into it and come back if I meet problems. Re: Global hls_singlepump? Hi BB The answer at 13-09-2023 does not answer my question in a clear manner. I need to know if there is a global way to do hls_singlepump to prevent any possible 2x clock interface. There is no way to tell if arrays will be implemented as single or doublepump until compiled and verified. I already know that I can apply hls_singlepump to arrays, but pre compilation, I can not tell what arrays will be implemented in memory, registers or even flattened out and removed. I just need to tell the compiler to stay away from 2x clock domain in general, because my architecture does not have a 2x clock available. I guess the answer to my question is no then. Simple standalone IP using oneAPI? I wonder if oneAPI is able to generate a standalone IP block with defined IO ports, just like HLS can do. I have been playing with the oneAPI compiler examples, and it appears like the compiler can just generate full designs on specific supported hardware with an interface to a PC, linking the PC executable and the FPGA functions. If the compiler is able to do component only, is there an example that does this? I would like to see how to define the IO ports for it. Both scalar and stream ports. If the compiler is (yet) unable to do this, are there any plans of supporting this? Re: Global hls_singlepump? Is this last post an automated post? I expected more feedback from you. Re: HLS compiler failed I just noticed, you may want to try a space between the ">>" like this. typedef ihc::stream_in<samples, ihc::usesReady<false>, ihc::usesValid<false> > sampleStream_t; Re: Global hls_singlepump? @BoonBengT_Altera wrote: Can you provide more insight on what you mean by 2x clock? I assumed this is a known thing for HLS users. The compiler will try to maximize memory performance and one of it's tools are "doublepumping", meaning it will use the 2x clock domain and your component instance will have both clk and clk2x as input pins. You can use the keyword "hls_singlepump" on each array that you define to prevent this, but this may lead to other problems since you don't know at processing time if the array is becoming a register or a memory array. I want a global way of preventing this to happen. Global hls_singlepump? I want to avoid any 2x clock interface to my HLS code, and I wonder if there is a way to do this globablly for a component. Regards SolvedRe: stream_in memory type Thanks Unfortunately I cannot share the code as is. I would have to write a test using the same stream, but that is not on my priority list right now. As long as 17.1 compiler can build this, I have a way out. Note:This is not the simulation not working. It is the RTL that stops working. C simulation works fine. I have not simulated RTL in modelsim cause I dont have the right testbench for that type of simulating (I draw the results visually using windows gdi, not comparing numbers).. Re: stream_in memory type Thanks for looking into this. Im hoping this will arrive in a future version. Apparently there was a change after 17.1 version and I can't find the details on this. After 17.1, I get non functional RTL when implementing a 608bit wide, 64 deep stream, wich seems to be implemented in MLABs only. My "area analysis" report lists a few of "Memory with unknown name (address space xx)" that seems to behave wrong. ALUTs FFs RAMs MLABs DSPs Details Memory with unknown name (address space 64) 0 0 0 32 0 Stall-free,\n76B requested,\n128B implemented. Memory with unknown name (address space 65) 0 0 0 12 0 Stall-free,\n76B requested,\n128B implemented. Memory with unknown name (address space 67) 0 0 0 26 0 Stall-free,\n76B requested,\n128B implemented. Stream 'prq_prep_pullstream' 15 30 0 1 0 608b wide with 64 elements.