Honored Contributor
Honored ContributorHi Rysc,
I have a few other questions about constraing the EHP interface, which reference how to apply sensible constaints in TimeQuest. The thing that throws me is this: An FSM drives the following signals out to the DSP via a top level module ...the top level module instantiates the actual EHPI driver VHDL module, so this is a 2 tier hierarchy : 1) hcs_ni : REG : directly drives output port : hcs_n 2) has_n : REG : directly drives output port : has_n 3) hds_ni : REG : directly drives output port : hds_n 4) hrnw : REG : directly drives output port : hrnw 5) had_oe : port is driven as follows: had_oe <= (ha_ena or ha_ena_d); where ha_ena and ha_ena_d are both REGS had_oe is the Tristate control for the Bidirectional data/addr/cotrol bus to the DSP. 6) had_rddata : 16 bit input bus from top level, REGISTERED in EHPI module 7) had_wrdata : 16 bit outputbus to top level and DSP HAD bus In the top level module which instantiates the EHPI driver module the top level BIDIR I/O HAD bus is driven as so: -- Read Data always reflects the INPUT BUS had_rddata <= had; -- write control for HAD bus had <= had_wrdata when had_oe_r = '0' else (others => 'Z'); 8) I also have a few feedback and handshaking signals from the DSP a) hrdy : DSP ready line b) h2dack_n : DSP acknowledge of a transfer complete... c) d2hreq : DSP request for service.. These sre all used by logic interal to the EHPI driver....basically in parts of the FSM, but they are all REGISTERED before use. Now my questions are: 1) For the actual interface signals: a) hcs_n (EHPI DSP chip select, active low) is asserted by the FSM a couple of clocks before any action takes place, ie before any read or writes start. b) has_n (address / control strobe, DSP latches HAD[1:0] on falling edge). This signal is asserted a clock after chip select and a clock before hds_n has been asserted. c) hds_n (data strobe, DSP latches data from the FPGA HAD[15:0] bus on the rising edge d) hrnw : Read not write : this signal is asserted two clocks before chip select by the FSM So as you can see in a way this interface is self timed,,,,because of the FSM control states which assert and de-assert each of the interface signals in a well defined sequence, with whole clock delays between state changes. The tristate control is another worrying part....because it has some OR logic after the pair of registers driving the actual Tristate contro port signal, had_oe. How is best to constrain this type if siganlling ...would i be best to add a REG like so: ADD CLOCKED REGISTER : had_oe_reg <= ha_ena or ha_ena_d); then async apply : had_oe <= had_oe_reg; But i still need to apply sensible constraints to all the EHPI to/from DSP signals so that TimeQuest can optimize the design and generate sensible reports. So Is my current approach sensible and best practice for this type of interface do you think ? Many many thanks for your help :)
