- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Atlys Spartan6 - multiclock domain system capturing data from CMOS camera
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-19-2012 04:05 PM
Hi, I would like to ask if someone can possibly be aware of solution for my problem...
Well, I am using Atlys board to capture and process data obtained from digital CMOS camera. System is created under the system generator in Simulink and then compiled into .bit file in Xilinx ISE.
System is designed as multiclock domain, where first domain just obtains data and takes care of writing in and resetting shared FIFO and is clocked (and therefore also run at the same clock speed - at about 8MHz) from the camera - this signal is used in Sys.gen. properties as FPGA clock with appropriate clock pin.
Second domain is responsible for image processing actions and other stuff and clock speed for this domain is set to 100MHz from clock pin L15, as we wish to process data faster than they are obtained.
Everything seems to be ok, simulations under simulink shows pretty nice results, but..it doesn't work at all when send into an FPGA....
When system is modified to be just a single clock domain, driven by the frequency of camera, it works very nice and also data can be captured by the chimp-scope and observed on the pc..but multiclock doesn't want to work and chimp-scope is falling with some error.
So can anyone, please, tell me some advice?
Thanks in advance, O.
Solved! Go to Solution.
Debugging a design...
[ Edited ]- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-19-2012 04:18 PM - edited 02-19-2012 04:21 PM
What part of your design is working as expected?
Can you narrow down which parts of the design are failing?
Have you created timing constraints?
Are there any warning messages from the synthesis and timing analyser tools?
My favourite warning on designs which 'do not work' is to check your design for asynchronous inputs and clock domain crossings which are improperly handled. Your experience with single-clock and multi-clock versions would seem to point the bony finger of failure at problems with clock-domain crossings.
If you cannot debug your design in its entirety, you will have little option but to re-build your design in smaller bits, and debug your design one block at a time until you have the entire design re-built.
-- Bob Elkind
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369
Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Re: Debugging a design...
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-19-2012 04:45 PM
Ok, system has to parts:
1.input domain - running at approx. 8MHz from camera, timing analysis says max. frequency around 220MHz, tested separately like single clock system and actually worked well
2.system domain - tested with 100MHz with error on timing constraints (that they can't make it on several paths in less than 12ns..that is more than 10ns for 100Mhz) so system was set to 12ns and also 15ns..timing is now without errors, but still doesn't work..that makes me to think about generation of the clock on Atlys and not using packed 100Mhz oscillator for clocking..instead of to use separate oscillator with, lets say 66Mhz to have step time of 15ns..
and yes, i'm suspicious of sys.gen. functionality with multi-clock crossing with shared FIFO (and I tried both versions-block ram and onboard ram with the same results)...
Thanks, O.
Re: Debugging a design...
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-19-2012 05:12 PM
- If your design works reliably when chilled (use freeze spray, for example), your greatest problem is operating frequency (speed).
- If failures still occur when chilled, but the frequency of failure changes, this is an indication of possible clock domain crossing problems or signal integrity (the wrong IOSTANDARD, for example) problems.
- If your design fails identically whether chilled or not, this indicates a possible logic bug.
You must figure out a way to isolate the failures to a manageable set of code or functions.
... that makes me to think about generation of the clock on Atlys and not using packed 100Mhz oscillator for clocking..instead of to use separate oscillator with, lets say 66Mhz to have step time of 15ns.
Divide the 100MHz clock by 2 (a 1-bit counter will do this), buffer the resulting signal with a BUFG, and you have instant 50MHz clock.
-- Bob Elkind
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369
Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Re: Debugging a design...
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-20-2012 02:29 PM
Thanks for help and quick replies Bob :smileywink: ...
Problem finally solved (hopefully..), shame on Multiple system generator and me (of course).
For all others:
Multiple system generator really doesn't store or use clock pin locations, even though you think you are so smart and included them earlier in Sys.gen. tokens in specified subsystems, you have to include .ucf files when implementing system in Xilinx ISE, change name "clk" in global period constraint of the clock (to something like "something_cw_clk") and add clock pin location...











