diff options
author | Pavel V. Shatov (Meister) <meisterpaul1@yandex.ru> | 2020-01-23 11:16:12 +0300 |
---|---|---|
committer | Pavel V. Shatov (Meister) <meisterpaul1@yandex.ru> | 2020-01-23 11:16:12 +0300 |
commit | 35359243a63cac4a9e8cce6bd718f17756ce8a98 (patch) | |
tree | dd1a893c31667dfba35bb437071e12c252f49fd4 /build/config.py | |
parent | fbf287f57879678fe8cf4a74e07e72ca5c7b153b (diff) |
Changed FMC I/O frequency to 45 MHz in the UCF file to match hardware and also
updated offset constraint values accordingly.
Another important change is that the core selector is now multicycle. The I/O
logic runs at 45 MHz, while all the cores and the core selector run at 90 MHz.
The job of the core selector is to distribute the write data (STM32 -> FPGA) to
the particular core being addressed and to select the read data (FPGA -> STM32)
from the core being addressed.
Timing issues arising from the distribution of write commands are mitigated by
replication of data and control signals. Each core has its individual set of
chip select, address and write data registers, they can be placed somewhere
inbetween the core itself and the selector and thus the critical timing paths
become twice shorter.
Readback logic has a huge multiplexor that selects the read data from the core
being addressed and then forwards it into the FMC bus arbiter. Since the FMC
arbiter operates at 45 MHz (twice slower, than the readback multiplexor), it
makes sense to give the multiplexor two 90 MHz clock cycles to select the
value, since the arbiter waits one 45 MHz clock cycle before sampling the
readback data. This is achieved by applying FROM-TO constraint. Note the two
gotches here (took me some time to figure out):
1) you attach the TNM or TNM_NET... well, okay, there's the third potential
gotcha here, since only one of the two works with I/O pads, read the CDG for
more details, but luckily, it's not out case, phew. So, you attach a TNM_NET
to a net, and ISE will follow the net and attach the TNM to **the next
register being driven by this net**. This is somewhat non-obvious: say, you
have a flip-flop called 'something_dout<0>' and it's output net is naturally
also called 'something_dout<0>', attaching TNM_NET to this net doesn't
apply the TNM to the flip-flop, it instead follows the net and attaches the
TNM to all the load flip-flops on the net. For FROM-TO to work as expected
we have to apply TNM_NET to all the output "read data" nets of all the
cores, so that they could be traced into the multiplexor. Note, that for a
multicycle multiplexor you actually need two FROM-TO constraints: one for
the data and one for the control signal.
2) Applying FROM-TO affects both the setup and the hold check in ISE. This is
different from Vivado, when you have to individually specify the setup and
the hold checks.
Diffstat (limited to 'build/config.py')
0 files changed, 0 insertions, 0 deletions