11-18-2012 11:20 PM
I'm trying to connect an external netlist as a black box to a Zynq embedded design of XPS in PlanAhead. I'm using "AXI External Slave Connector" in order to make the individual AXI signals available as I/Os for my top level design in PlanAhead, where I connect them with I/Os of my netlist.
So far so good. What I'd also like to do is to clock my design as a whole with one of Zynq's FCLKs. But when I tried to simply make one of the clock signals externally available within XPS, and tried to connect the signal to the clock input of my netlist in my top, I got a bunch of errors. I apply the standard timing constraints at both the netlist input signal (when synthesizing it) and my top as well.
Any idea what might be causing this, or how I should actually do this?
Thank you and best regards,
11-19-2012 06:45 AM
You would have to share the errors you are receiving. I've used the FCLK many times. One thing to keep in mind is that the FCLKs are not guaranteeed to be edge aligned with each other.
11-26-2012 07:58 AM
thanks for your reply and sorry for my late input, but I've been busy with some other stuff.
It's pretty much the same things as described here: http://www.xilinx.com/support/answers/34771.htm
I feed a Clock Generator IP with FCLK_0 in XPS, and specify a buffered external output. Then I simply connect the clock_generator_pin to the clk_input of my other black box in the top file in PlanAhead. I really couldn't find any of the proposed attributes for Synthesis within PlanAhead in order to bypass this silly issue.
Any help highly appreciated!
11-30-2012 01:36 PM
The suggested flow is:
Instead of running XPS seperatly and creating netlists that you then copy into a planahead project, I suggest that you add the .xmp file as an embedded module in planahead. Make sure you right click on it and select 'generate top HDL' (or something close to that). This last step is necessary because it will add hooks into your edk project that allow planahead to comunicate with it. You can always delete the hdl file once it's created.
The advantage of the suggested flow is if you ever add microblaze to the embedded portion of the design, planahead will manage the bmm file that's necessary to place the microblaze elf in bram.
To hack a fix (not suggested), edit the .xmp and change the insert pad option to 'InsertNoPads: 1'.
11-30-2012 06:41 PM
thanks for your input. I actually already follow the flow you suggest (regarding XPS); that's not my issue.
I do following: my company uses Mentor's HDL Designer (for Revision Control, etc.), so I need to do my stuff within those tools. I synthesize my design with XST, and include the synthesized netlist in PlanAhead as a Black Box. As another Black Box I actually include the Embedded portion, which incorporates Zynq's ARM-MPCore, or PS_7 preferably.
I want to use a single Reference Clock (PS_CLK) and produce any other needed clock with the internal PLLs. Among others, I also want to route one of the FCLKs to the fabric. This clock should obviously drive the external netlist, too. So I need to route the produced clock signal out of one black box and drive another one. I edited the PS_7 MPD file, and removed the BUFG tag. I then declared the signal which connects the FCLK with the clk_input of my netlist as BUFG in my top, and it worked (sort of). I got it routed, but Timing is not the best.
Any suggestions on that?
12-03-2012 07:05 AM
Instead of editing the mpd (I hope you copied the ps_7 to your local pcores dir before editing) you could have just added the line 'PARAMETER C_FCLK_CLK0_BUF=FALSE' on the ps_7 by editing the mhs file.
Or, you could have left the bufg in the ps_7 and not used it in your external netlist.
You can not use PS_CLK in the fabric. It is a ps_7 pin only so there are no routing resources to use it in PL.
Can't really answer your 'timing is not the best' comment without understanding what timing isn't good.
I have other customers using HDL Designer with an XPS submodule so I know the flow is valid.
One thing to watch for is passing clocks back into the XPS module. You will need to assign the frequency to their XPS incomming ports. The axi_interconnect relies on these frequency parameters in order to determine if async logic needs to be enabled.
12-03-2012 07:40 AM
thanks for your reply. Yes, I made it local before editing it. Ok thanks, editing the MHS is a good idea - I also did the last thing you mentioned: BUFG in PS_7 and not @top - worked too! As I told you, I got it working (one way or another). The thing is that it doesn't get routed properly.
What I meant with my Timing statement was, that it doesn't meet Timing! :P I get a negative slack on the clock signal, and I cannot understand the reason. I'm still in test phase, so the design is rather small.
Furthermore, regarding PS_CLK, I meant that it is the reference for the internal PLLs (ARM, DDR and IO) - the I/O PLL among others also generates the 4 FCLKs which are routed to fabric (as far as I'm concerned, you may actually use any of the 3 PLLs to generate the FCLKs). And those are the clock signals that I want to use in order to clock my design!
I suspect that it is all about constrains - could it be that the BUFG applied to the signal at the Embedded module, doesn't get routed over the Global CLK traces to the other netlist?
Good to hear that there are people out there already working that way! :-)
12-03-2012 07:48 AM
If you are using planahead as the top level tool, open the synthesised design, seach for all clock instances, then highlight what your interested in, then right click-schematic. This is the quickest way to see what really happened in the design. If it comes down to routing, fpga editor will show you what's actually happening.
Beware that FCLK0 is not guaranteed to be edge aligned to FCLK1 etc. If you want a 200MHz and 100MHz edge aligned clocks, you would use FCLK0 to create say 200MHz, then a PLL to create the edge aligned 100MHz from 200MHz.
12-04-2012 12:42 AM
Thanks, I'm already doing that! :-) The problem is that you cannot look into the processor. PS7 is a closed box in both the schematic as well as any other view of the design. When I place a global buffer at the clock input of the other netlist, for example, I can obviously see it in the schematic.
Yeah, I'm aware of the FCLKs not being edge-aligned. And it's better design methodology to do it the way you proposed, anyway!
12-04-2012 09:11 AM
The PS7 (lowest level of instantiation) has a clock out but not a bufg. The edk core (processing_system7) adds a wrapper that has the parameterized option to enable a bufg (as you know since you've modified this wrapper).
You could use FPGA Editor to look at the actual routing between the PS7 and the BUFG that's in your other netlist. You should notice that the clock net from PS7 to BUFG uses global resources instead of local routing so once the net gets out of the PS7 gasket, it should be pretty well straight to the center of the device and then up or down to the BUFG. If you have a lock on the BUFG, you may have chosen a non-optimal location.
12-05-2012 08:08 AM
I verified the route of the unbuffered FCLK from PS_7 to the BUFG - it's exactly the same as in your attachment. I checked the rest of the clock traces (they're routed through BUFGs and BUFHs, etc. - looks pretty decent).
I really don't get it why Timing isn't met. Maybe my design isn't placed well (but it's sooo small... :S).
At this point I really need to thank you for your effort - that's rather rare in forums nowadays! :-)
12-05-2012 02:00 PM - edited 12-05-2012 02:02 PM
"I synthesize my design with XST, and include the synthesized netlist in PlanAhead as a Black Box."
How about turning off the "Add I/O Buffers" in the xst options when you generate your netlist.
Just my 2 cents...
12-10-2012 07:09 AM
thanks for your input, but unfortunately nop, it's not that. But I guess it's just some other settings within MAP or PAR which makes it fail at meeting timing (or bad design). I guess I'll figure it out sooner or later! My initial clocking issue was solved, though, and that makes me happy! :-)
Thanks guys, and kind regards,