Try to understand Hierarchical Partial Reconfiguration(HPR)

[dj-park]

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.

[sstrell]

I'm pretty sure that once you've established LL regions for a child/children, you can't remove them with a PR operation.  Like the first page of that app note says (https://www.intel.com/content/www/us/en/docs/programmable/683687/23-3/tutorial-for-the-fpga-development-board.html) performing a PR on the parent reconfigures the child/children back to their default persona.

It may just make sense in your case to just have more personas for what you're calling "parent1" instead of trying to do HPR on it.

[dj-park]

@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.

[sstrell]

I'm not entirely getting what you are suggesting here, but once you create child regions/partitions, 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 think what you could do is have the default personas for parent1, child1_1, and child1_2 be your larger "bit1" design, distributed between the parent and the two children instead of just one larger partition.  Then you could PR the children to alternate personas bit2_1 and bit2_2.  You will lose some resources due to the fencing of LL regions (which can't be avoided), but you are still essentially splitting the larger bit1 design into smaller child "chunks".

Maybe a better explanation of your idea here would help.

[dj-park]

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...

[sstrell]

Still not clear.  The file you're calling static_lvl_1.qdb: is this for the top-level static logic generated from the base revision or is that the .qdb for either parent1 or parent2?  If it's supposed to be for the top-level static logic, then it has nothing to do with the logic contained in parent1 or parent2.

Better naming here perhaps: static_top.qdb for the top-level static logic compiled from the base revision and never changes.  static_parent1.qdb for parent1 containing default persona logic for child1_1 and child1_2.  static_parent2.qdb for parent2 and defaults for child2_1 and child2_2.

Now child1_1 and child1_2 could have their own other personas represented with bit1_1.qdb and bit1_2.qdb.  Similar for child 2_1 and child2_2.

There will be a qdb for every part of this: top-level static logic, top-level parent logic that includes child default persona, and child logic when the child logic is supposed to be different from the default defined by the parent.  So with this better naming, can you explain your idea?

[dj-park]

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?

[sstrell]

No this is not how the static region works.  The static region is exclusively the yellow in your first diagram and always will be.  It cannot be "extended" into a PR partition.  That's why it's static.  The whole point of PR is that the static (yellow) logic remains the same always while the logic in a PR partition (like parent1 or parent2) can be reconfigured, either the parent and all of its children or individual children, leaving the parent logic (dark green in your third diagram) alone.

There's no such thing as static_top_lvl_2.qdb as you've labeled it.  Yes, you could have the dark green parent logic contain just wires connecting between the static logic (yellow) and the child logic (white), but you can't just skip over the parent logic design to connect the children to the top.  If you're going to do this, you might as well just have the children be 4 individual PR partitions without parents in between.

[dj-park]

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. 

[sstrell]

No.  Again, you can't have the top-level include the fence and logic of a lower-level partition.  static_top_lvl_2.qdb is not possible unless parent1 and parent2 were not separate design partitions, but they need to be for HPR.

[SyafieqS]

I now transition this thread to community support. If you have a new question, Please login to https://supporttickets.intel.com/, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

p/s: If any answer from community or Intel support are helpful, please feel free to mark as solution, give Kudos and rate 5/5 survey