dj-park
Occasional ContributorJoined 3 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
HPS and FPGA fabric communication for Agilex 7 devices
I'm very sure a tutorial for this exists but I haven't been able to find one. I am looking for a design example or tutorial that sends some data from HPS, computes(let's say simple vector addition in this case) and sends data back to HPS. We may need to create Quartus design that consists of 1)AXI interconnect and 2)vector addition compute kernel. We then have to generate the bitstream and program the FPGA device. Finally, the main.cpp that runs on HPS should dumps some data to certain address so that FPGA compute kernel can receive, compute and send the results back. What is the closest design tutorial for this simple HPS-FPGA fabric communication? The target device is Agilex 7 device. I do not intend to use oneAPI. I want to generate bitstream and compile the host code(that runs on HPS) separately.Re: Try to understand Hierarchical Partial Reconfiguration(HPR)
You are right. Probably, I shouldn't label it as "static"_top_lvl_2.qdb. But I still think this should be theoretically possible. There should be a full bitstream generated from the step below. If I load this bitstream, it should set the routing from the top level to the children level. Then if I program parent1 with bit1, it should overwrite the routing from parent to children. We can program parent2 with bit2_1 and bit2_2. bit2_1 and bit2_2 should not overwrite the routing from parent to children. The final programmed FPGA device should look like below. I am not sure whether such overwriting is supported in Quartus PR.Re: Try to understand Hierarchical Partial Reconfiguration(HPR)
Sorry for the confusion. So, static_top.qdb is highlighted in yellow below. It has boundary nets(red) from the top level to the parent1 and parent2. With static_top.qdb, if I subdivide parent1 into two children and subdivide parent2 into two children, I think I should get another static design for the level-2. I would call this as static_top_lvl_2.qdb, highlighted in green below. Note that boundary nets(red) propagate through the children regions. As we build upon static_top.qdb, boundary nets from top to parent1,2 are the same as static_top.qdb, and boundary nets from parent1,2 to children are routed down to children LL regions. So the dark green area shouldn't contain anything. I am thinking of giving one row of fence so that boundary nets can be routed down to the children LL regions. Does this make sense?Re: Try to understand Hierarchical Partial Reconfiguration(HPR)
Just to make sure, parent1 and parent2 are two different PR regions on the device. ... they are by their nature isolated from the parent, so you can either reconfigure the children themselves or reconfigure the parent, which in turn affects the children. ==> I understand. This is why I think my idea may be possible. You will lose some resources due to the fencing of LL regions .. ==> Yes, I understand the resource loss. but you are still essentially splitting the larger bit1 design into smaller child "chunks". ==> This is what I do NOT want to do. --- To clarify my idea, given a PR region(parent1 or parent2 LL region in the example below), I would like to load one large persona(like bit1 / bit2) or two smaller independent personas(like bit1_1 and bit1_2 / bit_2_1 and bit_2_2). The idea is that we first lock down the placement/routing of top level to parent1 and parent2. The static design for this is static_lvl_1.qdb. With this static_lvl_1.qdb, we can program parent1 and parent2 (bit1 or bit2). Building upon static_lvl_1.qdb, we can create static_lvl_2.qdb which has placement/routing info of top level to children LL regions. As you mentioned, I expect that we should leave some fence between parent1 and child1_1/child_1_2. With this staic_lvl_2.qdb, we can program children LL regions. 1) Can you confirm that this idea makes sense? 2) One concern I have is, when creating static_lvl_1.qdb, the tool doesn't know whether there will be child1_1, child1_2, child2_1, child2_2, etc, so the boundary ports may be randomly placed. Then, I are forced to create really small children LL regions not to overlap with these boundary ports...Re: Try to understand Hierarchical Partial Reconfiguration(HPR)
@sstrell Thanks for the reply. I understand your point. But I want to have some flexibility of using parent1 with a large single PR region or two smaller PR regions. As you said, once we've established LL regions for children, we can't remove them. So how about the flow below? The idea is to have one static qdb for a level-1(for parents) and another static qdb for a level-2(for children). And when we want to use a large single PR region, use static_lvl_1.qdb (bit1 in the example below). When we want to use two single PR regions, use static_lvl_2.qdb (bit2_1 and bit2_2 in the example below). My question is, are bit1 and bit2_1/bit_2_2 compatible? My guess is that static_lvl_2.qdb should have all those fixed placement and routing info from static_lvl_1.qdb. So maybe they are compatible... but I am not sure.Try to understand Hierarchical Partial Reconfiguration(HPR)
Hi, I went over AN 954: Hierarchical Partial Reconfiguration Tutorial. So the example design looks something like below and I understand the flow. What I want to do is something like below. I would like to sometimes allocate a large area for a parent persona entirely. I would like to sometimes allocate a large area to two children personas. The example use case is shown below: Q-1) Does the use case above make sense? Or is this not supported in Quartus HPR? Thanks in advance.Re: Manual routing in Quarutus
Yes, I am aware of routing region as well. However, as mentioned in the reply above, the routing region does not have a control over the "interface nets." (the nets that come in/out from the logic lock region) I want to control these nets so that they do not route over specific regions. My idea was to manually move over these nets if they end up routing over the regions. Thus, I asked the question whether we can manually route specific nets.Re: Manual routing in Quarutus
Thanks for the reply. I am aware of Logic Lock region. But I am asking about the fine-grain control over the routing. For example, with Logic Lock region, I don't have a control over the nets that come in/out from the Logic Lock region. I want to control these nets so that they do not route over specific regions.Manual routing in Quarutus
I know there were similar questions in the forum, just want to double check with the most recent Quartus version. I am using Quartus Prime Pro 23.1 on Ubuntu 20.04. Can I manually route so that it doesn't use routing resources in the specific regions? Or at minimum, can I manually route so that it doesn't cross the specific region and fix it? Xilinx Vivado does not have this feature but does have manual placement and routing (https://docs.xilinx.com/r/en-US/ug904-vivado-implementation/Manual-Routing). I wonder if I can achieve this in Quartus.Re: quartus tcl console, how to use?
Yes, I do know quartus_fit is command line command. The reason why I tried it in Tcl console is because of the error message above... I tried eco_reroute command is it says it's only available with quartus_fit command. Does this mean do I need to put "eco_reroute" command inside some tcl script (like reroute.tcl) and then run it in the command line with "quartus_fit -t reroute.tcl"? Then, what's the use of Tcl console?
