08-02-2008 06:00 PM - edited 08-04-2008 04:13 PM
So I was reading through the standard cc module for a 4 lane simplex tx aurora core v3.0 today.
I noticed that the comments mention monitoring the channel up signal. Then I started reading the user guide ug353. It lists the standard cc io ports as...
WARN_CC, DO_CC, and CHANNEL_UP.
Guess what is not in the module that coregen gave me... That's right CHANNEL_UP. There is a RESET port. And it seems to be used in the CC module in places where it refers to CHANNEL_UP. But I can't really tell if I need to connect a CHANNEL_NOT_UP or CHANNEL_UP to the RESET port.
So I looked at the example code that coregen provided... That's right CHANNEL_UP is not connected to the CC_MODULE in the example.
Anyone resolved this issue already?
08-04-2008 06:58 AM
So I connected ~TX_CHANNEL_UP to the reset of the CC_MODULE.
It works much better now. I am still not entirely convinced that this is the complete solution based on the code in the CC_MODULE, so I will open a web case to make sure. I'll re-post the answer next week when I get it (haha).
08-05-2008 11:01 AM
Faster than expected response... But I am always prepared for disapointment from web support of any kind.
Basically seemed to indicate that ~CHANNEL_UP should be connected to the reset port of the CC_MODULE. Although the exact response was not exactly in complete sentences.
This is a bug which is due to some fix we made recently. It will be fixed in the future release It’s is better to connect CHANNEL_UP and TX_CHANNEL_UP or inverted RESET as this happens
If clock module is continuously kept in RESET (and RESET is active low in example design).