aboutsummaryrefslogtreecommitdiff
path: root/build/config.py
diff options
context:
space:
mode:
authorPavel V. Shatov (Meister) <meisterpaul1@yandex.ru>2020-01-23 11:16:12 +0300
committerPavel V. Shatov (Meister) <meisterpaul1@yandex.ru>2020-01-23 11:16:12 +0300
commit35359243a63cac4a9e8cce6bd718f17756ce8a98 (patch)
treedd1a893c31667dfba35bb437071e12c252f49fd4 /build/config.py
parentfbf287f57879678fe8cf4a74e07e72ca5c7b153b (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