Top level module question
Added by Conor O about 12 years ago
Hi all,
I'm a bit of newbie with FPGAs but I've written my own top level GPIO test design and it at least synthesises. There are a few warnings though which leads me to a small question on the top level modules. So this is a real newbie question I guess. And pedantic...
Looking at the top level VHDL examples for Industrial IO and MityDSP, one obvious change is the dropping of the DCM. The MityDSP vhdl example (MityDSP_L138_top.vhd) shows port maps for EMIFA_dcm. While the Industrial IO example drops all that and uses BUFG (there's a "-- TODO -- DCM???" comment too!)
Tracking through to the base module none of the dcm i/o seems to be generated at all. So can I just delete the dcm_lock, dcm_reset, dcm_status signal declarations and do this:
o_dcm_reset => open, i_dcm_status => "000", i_dcm_lock => '0',
instead?
I presume EMIFA_dcm is instantiated in EMIFA_dcm.xco and dcm_ctlr.ngc so I can just throw away those files :-) They aren't used in the example IndustrialIO.xise files.
Thanks,
Conor.
Replies (2)
RE: Top level module question - Added by Michael Williamson about 12 years ago
Hi Conor,
First, the most recent MDK should include code in the base module to support the DCM reset logic as well as read out the digital DNA of the Spartan 6 device. Are you using an older version?
Many folks (including Critical Link) use a Digital Clock Manager (DCM) to clean up the input clock in order to reduce clock skew as well as generate derived clocks using the built in digital lock loop multiplier/divider capability. The Spartan 6 also includes a true phase lock loop for additional clocking capabilities.
The trouble with the DCMs is that if the input clock stalls, goes away, or changes frequency, the DCMs will break lock and stop. They do not have auto-reset logic built in, and need to be hit with a reset strobe. This will happen if you change the CPU frequency of the OMAP-L138 while the FPGA is loaded. The purpose of the base module o_dcm_reset logic is to create a simple ring oscillator to drive a simple circuit that monitors the lock status of the DCM and forces a pulse on the reset signal to bring back the FPGA clocks.
Using a BUFG just puts the input clock line onto a low skew clock net, and for a lot of designs (with a properly constrained timespec) that is good enough to close timing. It's also sidesteps the issues associated with changing the CPU clock frequency mentioned above. But, it limits what sort of clocks you can generate in your design. Our examples did that primarily because it was easy and quick and timing closed. Feel free to do the same (your current approach). Sorry for the confusion.
-Mike
RE: Top level module question - Added by Conor O about 12 years ago
That was a fast reply! Thanks Mike.
I'm using the latest MDK alright and I do see that there is generics and code for GEN_DCM_RST and GEN_DNA_PORT. I thought there had been a change of mind about using a DCM generally and you'd decided to use a BUFG more. The Industrial IO examples have quite a lot of cores included and still use BUFG so I gathered that in most cases that's adequate. I see others in the forums have used the DCM though.
As the base module does the reset etc of the DCM I was only concerned in case not using the DCM in the top module had other effects. For example if GEN_DCM_RST was true and i_dcm_status wasn't wired up, or default high (111) that would be a problem. But it looks fine - just Xilinx ISE complaining about i_dcm_status not being driven.
Once GEN_DCM_RST is FALSE which it is by default, o_dcm_reset, i_dcm_status, i_dcm_lock don't appear to be used so I guess it doesn't matter what they are wired to in the base module port map. I'll set them to 000 just to keep ISE happy.
Thanks for that and thanks for the linux drivers and cores for the fpga. That's a really handy feature to have, especially for someone like me who has a random number of i2c/uart/spi connections to deal with.
Conor.
