07-25-2017 03:36 PM
in the course of my master thesis I'm dealing with partial reconfiguration and during the development of a showcase design a question concerning this mechanism arose:
Assuming a design with a partition that is to be partially reconfigured. Further assume, that the (partial) configuration is the same as the one that is currently loaded in the partition.
Is there a possibility to preserve the state of the registers during the reconfiguration, s.t. the reconfigured partition contains exactly the same configuration and data after the reconfiguration?
This may sound a little bit weired, because the reconfiguration has no effect in this example, but it is an abstraction of a more complex scenario.
What I already tried/figured out:
I implemented a showcase as described before and disabled the "reset after configuration" option. During the reconfiguration process I disable the clock for the partition by using a clock buffer in the static portion of the design. If the partial design has no reset, the previously described behavior can is observed. But if the design uses a reset, the state seems to change during the reconfiguration. The kind of reset (active high/low, synchronous/asynchronous) seems to have no effect. My guess is that the reconfiguration affects the reset net and produces a pulse on the reset input of the storage elements in the CLBs. Is that correct?
Thank you very much,
07-26-2017 06:42 AM
What you describe is similar to what happens for Static cells within the RP frames. A configuration frame is a clock region high, so if an RP Pblock is not clock region aligned, and Static logic gets placed with the same frame, the static logic will be reconfigured.
For 7series, RESET_AFTER_RECONFIG cannot be set if the RP Pblock is not frame aligned, otherwise we will apply the rest to the Static logic in those frames, and disrupt the design. For UltraScale we have better control of how the global reset (GSR) gets applied, and we can mask those Static sites so that they are not affected. In UltraScale, RESET_AFTER_RECONFIG is always applied.
I wouldn't expect any pulse/glitch on this reset line if you are programming the exact same partial bit file. Just like Static logic within the RP frame, or just like logic that gets rewritten during scrubbing from our SEM IP, the logic shouldn't reset if RESET_AFTER_RECONFIG is disabled (7series) and no reset is being activated. The partial bit file just reprograms the frames, and doesn't treat (or know) a reset net differently from any other net.
I don't have a good explanation for what you are seeing, but I don't think it is expected, and maybe some of this information can help you debug further. For you particular reset scenario, is the reset driver Static, or part of the RM? If it is in the RM, try driving it from Static to see if it changes the result.
07-26-2017 07:12 AM
Thank you very much for your fast reply!
The design that is reconfigured is a simple counter. The driver for the reset net is placed in the static region of the design, as far as I can see in the floorplan. Moreover, the partition is one clock region high and I set the following properties:
set_property RESET_AFTER_RECONFIG false [get_pblocks pblock_uut]
set_property SNAPPING_MODE ON [get_pblocks pblock_uut]
I disable the clock signal that is routed to the partition before reconfiguration with a BUFR (that is also placed in the static portion of the design). I'm loading exactly the same counter (all registers have the same logic location) to the partition and after the reconfiguration the clock is enabled again.
What I'm expecting is that the counter continues counting from the value that it had before the reconfiguration, but what I observe is that the value of the counter changes during reconfiguration.
07-26-2017 09:27 AM
I took a version of the PR tutorial design that two instances of a counter (led_count_count). Both counters are RPs. The first is driven by a BUFG that is free running. The second count instance is driven by a BUFR, where the CE is tied to a dip switch. I was able to disable the BUFR clock at specific value of the count (eg. 4'b1001). I then downloaded the partial bit file for the same RM that was part of the initial full bitstream (countUp). After PR completes, I re-enabled the counter and saw the value continue starting at 4'b1010).
The counter RMs do have a reset that is driven by a push button.
This test targets a KC705 board. I'm not sure if you have access to this, but I've attached the design if you do. If not, you can still compare this design to what you are trying. Maybe it will help.
To run the design, extract the archive and source 'design.tcl'
>vivado -mode batch -source design.tcl
This will run synthesis for all partitions, implement the initial configuration, and generate bit files. You can see the reset and clock enable locations in the XDC (./Sources/xdc/top.xdc).
Hope this help.
07-26-2017 04:52 PM
Thank you for the example, I really appreciate your effort :)
I have access to a KC705 board at the company I work. Unfortunately, I took some time off to focus on my master thesis and will not be there until next week. But I will examine your example asap.
Until then I will try to get it working on my private Artix board.
Maybe you could answer me another short question.
I marked the RP as HD.RECONFIGURABLE which should include the properties EXCLUSIVE_PLACEMENT and CONTAIN_ROUTING according to ug909.
The designflow I use is also based on the scripts from that example.
A closer look at the floorplan revealed something that I can't really understand:
The component that is assigned to the pblock "pblock_uut" is called UUT. Outside of UUT there is the BUFR and a register that controls the enable signal of this buffer. The buffer gates the clock of UUT.
Although the properties mentioned before are set, it seems that the register that controls the BUFR is placed inside pblock_uut (c.f. screenshot in attachement).
Moreover, it seems that some signals of the static design are routed through pblock_uut.
Isn't it enough to set the properties mentioned in order to tell the P&R tool not to use this block?
07-27-2017 01:06 AM
This is common confusion point. Let me try to clarify.
07-27-2017 07:51 AM
Thank you :)
I wasn't able to solve the problem yet, so I extracted the part of the design that does not work properly.
Maybe you could take a short look at it?
The clock-enable signal is mapped to a switch and there is a up- and a down-counter to be partially reconfigured.
The arty.xdc file contains constraints for the logic locations of the registers of the counters, s.t. the same registers are used for the up-counter and the down-counter.
My intention was to be able to start the design with the up-counter and then being able to replace it by the down-counter, which starts counting from the same value that the up-counter had.
If this does not work in general, I better start searching another topic for my master thesis :-S
PS: The original design of course contains synchronizers and more constraints, but I wanted to keep this example as clear as possible.
07-27-2017 09:02 AM
07-27-2017 11:13 AM
Meanwhile I figured out a little bit more. It seems that the reset is routed through a LUT that is located in the RP and not directly through the reset net for some of the registers. Other registers are not connected to a LUT in the RP although they are described in the same part of the VHDL code and both of them are reset to 0. Is there a possibilty to constraint the reset in a way so that it is routed directly to the RS inputs of the registers?
07-27-2017 12:53 PM
I'm not sure why the reset is routed differently to some flops than others when they have the same polarity You should the design at various stages to try and determine where this LUT is introduced. If it is at synthesis, double check the logic to on the flops that are connected to the LUT. Maybe they have other control logic (CE), and synthesis is combining this logic?
Anyway, thanks for the additional information. I didn't realize you were re-configuring with a different partial bit file. Locking down the placement of the relevant logic is not sufficient. If the routing of the reset, clock enable, etc aren't exact, these nets will toggle/glitch during the PR process. So even if you resolve the reset issue you are seeing, you'll have to lock down the site and bel locations of both the driver and loads, and then user directed routing constraints to lock down the routing. There may be additional constraints (like lock_pins) that are required to prevent pin swapping if LUTs are involved.
I think what you are trying to do seems feasible, but is beyond anything I've ever tried with PR.
Good luck, and let us know how it goes!
07-27-2017 01:23 PM
I found a document
that describes the "use of LUTs as Route-Thrus". But I could not find an option to disable this feature yet.
Sorry that I didn't mention that I also plan to reconfigure the partition with another bitstream.
The problem also occured during the reconfiguration with the same bitstream.
If I ensure that the SR and CE inputs of the storage elements are not connected and only the global reset (GSR) is used to reset the partition, do you think that this would work? I have to reconfigure the partition with a bitstream that uses another routing than the previously loaded one.