Re: [casper] PAR could not meet all timing constraints.
Hi David, Thank you very much! I could synthesize running at 400MHz, I had to change DFS_FREQUENCY_MODE and DLL_FREQUENCY_MODE twice in the vhd file. The problem now arises with my equipment, I realize that I have only 120MHz function generator and the I need at least 128MHz (128MHZ/4 = 32MHz minimun to DCM). Is there a way to use the internal clock in ROACH as the iADC external clock (clk_i)? Regards, Daniel. On Mon, 13 Dec 2010 21:50:44 +0200, David George david.geo...@ska.ac.za wrote: Hi Daniel I tried to clock at 100MHz system clock and 400Mz for ADC, now I changed to 200/800 respectively and it compiled! Why adc_clk_buf has issues with lower frequency? Where I can find it in my design? It looks like your timing error was inside the iADC yellow block, which corresponds to a pcore in your EDK project. I suspect you have run into a minimum timing constraint on a DCM which is configured for high speed clocks. The minimum input clock frequency for DCMs on Virtex-5 is 120 MHz. So this timing error isn't one that adding latency can fix. If you want to run at less than 120 MHz, you need change two parameters (vhdl generics) in xps_lib/XPS_ROACH_base/pcores/adc_interface_v1_01_a/hdl/vhdl/adc_interface.vhd. Both DFS_FREQUENCY_MODE and DLL_FREQUENCY_MODE should be equal to LOW (as opposed to HIGH) This represents a bug in the toolflow (or I suppose a missing feature) as this could very comfortably be done automatically. I'll file a bug report on this and it will probably be fixed soon. Hopefully I'm correct in understanding the problem and have helped ease your mind about it too. Cheers, David George
Re: [casper] PAR could not meet all timing constraints.
Hi, I don't know the details of how to connect a Roach internal FPGA clock to the iADC input clock but assuming it can be done it may not be wise to do so. The jitter on that clock may be unacceptable for your targe SNR; it was pretty lousy clocks on older Xilinx FPGAs. I'd carefuly check it out before proceeding down that path. Maybe by setting the Jitter Filter or Ref_jitter parameters or cascading PLLS or something for the IOB too an acceptable clock signal would be produced. I would be curious to learn how it turns out if you should give it a try. Matt On Thu, 16 Dec 2010, Daniel Esteban Herrera Pena wrote: Hi David, Thank you very much! I could synthesize running at 400MHz, I had to change DFS_FREQUENCY_MODE and DLL_FREQUENCY_MODE twice in the vhd file. The problem now arises with my equipment, I realize that I have only 120MHz function generator and the I need at least 128MHz (128MHZ/4 = 32MHz minimun to DCM). Is there a way to use the internal clock in ROACH as the iADC external clock (clk_i)? Regards, Daniel. On Mon, 13 Dec 2010 21:50:44 +0200, David George david.geo...@ska.ac.za wrote: Hi Daniel I tried to clock at 100MHz system clock and 400Mz for ADC, now I changed to 200/800 respectively and it compiled! Why adc_clk_buf has issues with lower frequency? Where I can find it in my design? It looks like your timing error was inside the iADC yellow block, which corresponds to a pcore in your EDK project. I suspect you have run into a minimum timing constraint on a DCM which is configured for high speed clocks. The minimum input clock frequency for DCMs on Virtex-5 is 120 MHz. So this timing error isn't one that adding latency can fix. If you want to run at less than 120 MHz, you need change two parameters (vhdl generics) in xps_lib/XPS_ROACH_base/pcores/adc_interface_v1_01_a/hdl/vhdl/adc_interface.vhd. Both DFS_FREQUENCY_MODE and DLL_FREQUENCY_MODE should be equal to LOW (as opposed to HIGH) This represents a bug in the toolflow (or I suppose a missing feature) as this could very comfortably be done automatically. I'll file a bug report on this and it will probably be fixed soon. Hopefully I'm correct in understanding the problem and have helped ease your mind about it too. Cheers, David George
Re: [casper] PAR could not meet all timing constraints.
Hi Mark,
I tried to clock at 100MHz system clock and 400Mz for ADC, now I
changed
to 200/800 respectively and it compiled! Why adc_clk_buf has issues
with
lower frequency? Where I can find it in my design? I can't add latency
if
I don't know where adc_clk_buf signal is. Thank you.
Daniel.
On Sun, 28 Nov 2010 18:59:25 -0800, Mark Wagner
mwag...@eecs.berkeley.edu wrote:
Hi Daniel,
How fast are you trying to clock you design? Try opening the timing
report by typing dos('timingan') from the Matlab prompt and
File--Open ./XPS_ROACH_base/implementation/system.twx from inside
the
design directory. This should tell you where the offending paths are
(i.e. negative slack). You could then add latency strategically to
give the data some time to propagate.
Mark
On Wed, Nov 24, 2010 at 1:51 PM, Daniel Esteban Herrera Pena wrote:
Hi CASPER team,
I wanted to test the iADC tutorial on my ROACH but I can't.
I followed the tutorial changing XSG core from iBOB to sx95t and
removing
ibop_lwip from original design. Simulation worked perfect but when I
start
bee_xps the following error appears after a while twice:
ERROR: 2 constraints not met.
PAR could not meet all timing constraints. A bitstream will not be
generated.
I saw what Mark Wagner recommended to see:
/XPS_ROACH_base/implementation/system_map.mrp
The thing I have here is a large file but I suspect that the problem
is
around this part:
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
--
Constraint |
Check | Worst Case |
Best Case | Timing | Timing
|
| Slack |
Achievable | Errors | Score
--
* NET iadc_test_adc/iadc_test_adc/adc_clk_ | MAXPERIOD |
-1.666ns|
| 1| 1666
buf PERIOD = 10 ns HIGH 50% | MINLOWPULSE |
4.666ns|
5.334ns| 0| 0
--
* PERIOD analysis for net iadc_test_adc/ia | SETUP |
8.535ns|
1.465ns| 0| 0
dc_test_adc/adc_clk_dcm derived from NE | HOLD |
0.148ns|
| 0| 0
T iadc_test_adc/iadc_test_adc/adc_clk_bu | MINPERIOD |
7.779ns|
2.221ns| 0| 0
f PERIOD = 10 ns HIGH 50% duty cycle co | MAXPERIOD |
-1.666ns|
| 1| 1666
rrected to 10 nS HIGH 5 nS |
| |
| |
--
Both constraints have a MAXPERIOD of -1.666ns, I don't know that a
minus
have to do here with time, but is what the report says.
Do you have any insights of this?. Or I just disable the PAR timing
check?
Best!
Daniel Herrera
Links:
--
[1] mailto:danherr...@udec.cl
Re: [casper] PAR could not meet all timing constraints.
Hi Daniel,
How fast are you trying to clock you design? Try opening the timing report
by typing dos('timingan') from the Matlab prompt and File--Open
./XPS_ROACH_base/implementation/system.twx from inside the design directory.
This should tell you where the offending paths are (i.e. negative slack).
You could then add latency strategically to give the data some time to
propagate.
Mark
On Wed, Nov 24, 2010 at 1:51 PM, Daniel Esteban Herrera Pena
danherr...@udec.cl wrote:
Hi CASPER team,
I wanted to test the iADC tutorial on my ROACH but I can't.
I followed the tutorial changing XSG core from iBOB to sx95t and removing
ibop_lwip from original design. Simulation worked perfect but when I start
bee_xps the following error appears after a while twice:
ERROR: 2 constraints not met.
PAR could not meet all timing constraints. A bitstream will not be
generated.
I saw what Mark Wagner recommended to see:
model_directory/XPS_ROACH_base/implementation/system_map.mrp
The thing I have here is a large file but I suspect that the problem is
around this part:
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
--
Constraint|Check| Worst Case |
Best Case | Timing | Timing
| |Slack |
Achievable | Errors |Score
--
* NET iadc_test_adc/iadc_test_adc/adc_clk_ | MAXPERIOD |-1.666ns|
| 1|1666
buf PERIOD = 10 ns HIGH 50% | MINLOWPULSE | 4.666ns|
5.334ns| 0| 0
--
* PERIOD analysis for net iadc_test_adc/ia | SETUP | 8.535ns|
1.465ns| 0| 0
dc_test_adc/adc_clk_dcm derived from NE | HOLD| 0.148ns|
| 0| 0
T iadc_test_adc/iadc_test_adc/adc_clk_bu | MINPERIOD | 7.779ns|
2.221ns| 0| 0
f PERIOD = 10 ns HIGH 50% duty cycle co | MAXPERIOD |-1.666ns|
| 1|1666
rrected to 10 nS HIGH 5 nS | ||
||
--
Both constraints have a MAXPERIOD of -1.666ns, I don't know that a minus
have to do here with time, but is what the report says.
Do you have any insights of this?. Or I just disable the PAR timing check?
Best!
Daniel Herrera
