<tpb>
Title: Fixing the sorting of database files by mithro · Pull Request #1226 · SymbiFlow/prjxray · GitHub (at github.com)
<mithro>
acomodi: Where are we with DDR?
<sf-slack>
<acomodi> mithro: I have modified the ddr-uart testing script to get to write/read to/from DDR. What I have discovered is that there is no actual data written or read. I am also assuming that the calibration is not actually working in the minilitex_ddr design.
<sf-slack>
<acomodi> mithro: there are a few ideas that I am implementing. I have noticed that the RST for the IDELAYCTRL was mis-placed so that it violated timing, but constraining it to have the cell placed as close as possible to the IDELAYCTRL didn't solve yet the issue.
<sf-slack>
<acomodi> mithro: we are also thinking that there might be an issue with the RESET logic, as we are using `FDPE` flip-flops in the design, which are asynchronous FFs, but VPR is actually not able to model them. This was an old issue we had, that maybe now became critical to solve.
<sf-slack>
<acomodi> mithro: being the IOSERDESes highly sensitive to the RESET signal, it may be that they won't correctly function if there is a mis-alignment of the resets
<sf-slack>
<acomodi> mithro: Vivado still reports a couple of hundreds of setup timing violations (between same clock domains) and a handful of hold timing violations (also these between same clock domains).
<sf-slack>
<acomodi> mithro: regarding the hold violations, all of them are related to DRAM64X1D cells
<sf-slack>
<acomodi> mithro: One of the issues, IMO is the fact that the placer is not aware of some critical blocks, that should be placed so to minimize the delay of a net (like the RST for the IDELAYCTRL).
space_zealot has quit [Remote host closed the connection]
space_zealot has joined #symbiflow
<mithro>
acomid: Have you been also testing under Yosys+Vivado?
<sf-slack>
<acomodi> mithro: you mean testing the ddr-uart stuff? That is actually working fine both in Yosys+Vivado and full Vivado
<sf-slack>
<acomodi> mithro: reading and writing to DDR with the test_sdram.py script is working fine as well
citypw has quit [Ping timeout: 272 seconds]
space_zealot has quit [Ping timeout: 272 seconds]
Bertl is now known as Bertl_zZ
space_zealot has joined #symbiflow
<litghost>
acomodi: Are we using the correct timing constraints with VPR? Does VPR report the same (ish) timing violations as Vivado?
<litghost>
acomodi: Until VPR sees the correct critical path to optimize, there is little hope of it optimizing to a valid solution
<litghost>
acomodi: Also the placer **does** have a criticality estimate using the placer delay matrix. Check pre- and post- placement timing estimates to see how off they are
<litghost>
acomodi: If the placer is misestimating the critical path and optimizing for the wrong things, it would result in very bad optimization
<litghost>
acomodi: My suggestion is to do the following:
<litghost>
- My an issue where you describe the current state of the UART DDR design
<litghost>
- List a set of concrete actions that you propose to take to try to make the design close timing
<litghost>
acomodi: The first set of actions should all be verification and validation oriented
<litghost>
acomodi: For example: Do Vivado and VPR report the same set of nets as the critical path?
<litghost>
acomodi: For the top 2-5 critical nets from Vivado, examine what VPR reports for the setup and hold
<litghost>
acomodi: For each hold violations present from the Vivado timing analysis, does VPR report a similiar hold violation
<litghost>
*Make an issue where you describe the current state of the UART DDR design*
<litghost>
The key with proceeding at this point is to break the problem down
<sf-slack>
<acomodi> litghost: Indeed, I'll proceed as suggested. I'll also prepare a tar with all the useful reports, so that everyone can have access to data.
<litghost>
acomodi: When you do that, please make sure to include the git hash of the relevant bits (prjxray-db (if you have local modifications), symbiflow-arch-defs, VTR, yosys
<sf-slack>
<acomodi> litghost: another thing to add is that the packer optimizes things in a wrong way. As an example, it happened that a reset-related cell gets packed with a carry chain that has nothing to do with there reset net itself. This may end up with the placer being forced to place the block in an not-optimal location, causing issues with timing.
<litghost>
acomodi: Turn of allow unrelated packing
<litghost>
acomodi: *Turn off*
<litghost>
acomodi: This will result in the design be less compact, but I don't think the UART DDR is at risk of running out of resources
<sf-slack>
<acomodi> litghost: sure, I think there is plenty also for the minilitex-ddr test
space_zealot has quit [Ping timeout: 268 seconds]
space_zealot has joined #symbiflow
<_whitenotifier-3>
[conda-packages] hzeller opened issue #70: Verible fails building currently due to tag version confusion - https://git.io/Jvcj7