DrTrigon

Map Errors due to IOB / BUFGMUX clock component not placed at an optimal site pair

Recommended Posts

To whom it may concern

 

First; thanks a lot for this amazing Papilio DUO thingy!!! This is what I was looking for since quite some time; a simple but still powerful and transparent approach to dive into FPGA, that does not hide or remove any part of the complexity but is equipped with tools to help you understand whats going on. Thanks and Congrats!

 

I am very new to FPGA, my first project was to take "Multiple_Serial_Ports" and modify it slightly to make a 1-wire sniffer from it (basically it's 2 UARTs, one at 9600, one at 115200 listening on the same line with some ZPUino code). My second project now is to try to create a Library from Internet code! (from Make a Wishbone Library). Btw.: Thanks for the nice tutorials!

 

Here my problem: I got some VHDL and Verilog code from a third-party source and everything worked out well until "Step 3 – Generate Programming File". Here I got several ERRORs that I could solve by changing some pins from "Arduino_28", "Arduino_34" and "Arduino_36" to "Arduino_8", "Arduino_11" and "Arduino_12". But the last ERROR is related to the "CLK" pin which I obviously cannot change, so here's the message:

 

ERROR:Place:1108: - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock IOB component <CLK> is placed at site <P94>. The corresponding BUFG component <CLK_IBUF_BUFG> is placed at site <BUFGMUX_X3Y8>. There is only a select set of IOBs that can use the fast path to the Clocker buffer, and they are not being used. You may want to analyze why this problem exists and correct it. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule. < NET "CLK" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Pack:1654: - The timing-driven placement phase encountered an error.

 

So actually I have no idea what's going on here. But I came across VHDL newbie: 'if' on a process sensitivity list element where Jack mentioned:

The thing to remember is that FPGA's don't have native support for latches, if you need to hold a value then you want a register instead. So if you see a latch being implemented then 9 out of 10 times there is a problem...

 

Looking at my Synthesis Report showed:

[...]
Synthesizing Unit <one_wire_interface>.
    [...]
    Found 1-bit register for signal <tbe_int>.
    Found 1-bit register for signal <EOWSH_int>.
    Found 1-bit register for signal <ersf_int>.
    Found 1-bit register for signal <erbf_int>.
    Found 1-bit register for signal <etmt_int>.
    Found 1-bit register for signal <etbe_int>.
    Found 1-bit register for signal <ias_int>.
    Found 1-bit register for signal <epd_int>.
    Found 1-bit register for signal <pre_0_int>.
    Found 1-bit register for signal <pre_1_int>.
    Found 1-bit register for signal <div_1_int>.
    Found 1-bit register for signal <div_2_int>.
    Found 1-bit register for signal <div_3_int>.
    Found 1-bit register for signal <CLK_EN_int>.
    Found 1-bit register for signal <FOW_int>.
    Found 1-bit register for signal <sr_a_int>.
    Found 1-bit register for signal <OD_int>.
    Found 1-bit register for signal <BIT_CTL_int>.
    Found 1-bit register for signal <STP_SPLY_int>.
    Found 1-bit register for signal <STPEN_int>.
    Found 1-bit register for signal <EN_FOW_int>.
    Found 1-bit register for signal <PPM_int>.
    Found 1-bit register for signal <LLM_int>.
    Found 1-bit register for signal <pd_int>.
    Found 1-bit register for signal <EOWL_int>.
    Found 8-bit register for signal <xmit_buffer>.
    Found 1-bit register for signal <owr_int>.
    Found 1-bit register for signal <clr_activate_intr_int>.
    Found 1-bit register for signal <xmit_buffer_full>.
    Found 8-bit 7-to-1 multiplexer for signal <DOUT> created at line 55.
WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<2>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<1>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<0>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
    Summary:
    inferred  36 D-type flip-flop(s).
    inferred   3 Latch(s).
    inferred   1 Multiplexer(s).
Unit <one_wire_interface> synthesized.
[...]

 

Then looking at the VHDL code:

[...]
    ----------------------------------------------------------------------------
    --  Transparent address latch
    ----------------------------------------------------------------------------
    process(ADS_bar,ADDRESS,EN_bar)
      begin
        if(((not ADS_bar) and (not EN_bar))='1') then
          sel_addr <= ADDRESS;
        end if;    
    end process;
[...]

 

This was kind of irritating, since as it appears there is an address latch that was introduced on purpose. So what to do with that? How to convert this into registers? Would such a conversion make sense at all? (as I understand latches are asyncronous where registers are syncronous only, right?)

 

The thing is, actually I have no clue whether this is related to my CLK issue this post is describing... To be honest I don't care about latches for now (it's only 3 bits, right? ;) but I need to solve the CLK issue described in the beginning in order to be able to generate a programming file and proceed. Any hint is greatly appreciated.

 

Thanks a lot for your time and greetings

Share this post


Link to post
Share on other sites

First, on latches: The Xilinx Spartan-6 does support latches.  The registers in a CLB can be edge-triggered flip-flops or level-sensitive latches.  The are other FPGA families that only have edge-triggered flip-flops.

 

The CLK placement error is more serious.  This error usually means that there's a conflict between two or more clock signals trying to use the same clock buffers.  Your conflict might be the latch clock, or it could be something else.  Spartan-6 clocking is very complex (see the Xilinx "Spartan-6 FPGA Clocking Resources User Guide UG382).  Take a look at all the signals in the Map/Placement report that Xilinx thinks are clocks, and how Xilinx has assigned them to pins and clock buffers.  There may be some surprises there.  I've found it useful to print out some of the clock diagrams in UG382 to check for conflicts.

 

It might be useful to post your VHDL source.  I mostly do Verilog myself, but others in this community might see from the VHDL why you're having problems.

 

In FPGA designs, it's usually best to have a single clock.  You then sample inputs using this clock, usually with an extra flip-flop stage to reduce metastability.  Slower clocks are often simulated by the FF's clock enable to convert the master clock to a slower clock.
 

  • Like 1

Share this post


Link to post
Share on other sites

Hi,

 

I suspect your UART code attempts to trigger some FF based on a signal that is not a clock. It may be actually related to the accidental latch.

Don't ever do this on an FPGA, unless you know what you're doing (only edge triggered FFs driven by a true clock signal).

 

You may get rid of the warning if you put the offending signal to a pin with "global clock" capability (only a few of them have this feature, check the Spartan 6 documentation). Still, it's a hack.

 

There are many, especially older and entry-level textbooks that don't make the distinction and encourage the reader to slap blocks together in any way that makes electrical sense. But in modern synchronous digital design there is a clear distinction between "information" signals and "clock" signals; break that rule and we're back in the dark ages (or in high speed / asynchronous / ASIC / legacy design reuse / Voodoo priest territory).

 

PS: And keep in mind that any off-chip signal like a UART input needs to be registered twice to avoid Metastability.

Share this post


Link to post
Share on other sites

First, on latches: The Xilinx Spartan-6 does support latches.  The registers in a CLB can be edge-triggered flip-flops or level-sensitive latches.  The are other FPGA families that only have edge-triggered flip-flops.

 

So generally speaking they are fine if introduced on purpose (and by somebody that knows what (s)he's doing ;). Ok, that's fine then, good.

 

The CLK placement error is more serious.  This error usually means that there's a conflict between two or more clock signals trying to use the same clock buffers.  Your conflict might be the latch clock, or it could be something else.  Spartan-6 clocking is very complex (see the Xilinx "Spartan-6 FPGA Clocking Resources User Guide UG382).  Take a look at all the signals in the Map/Placement report that Xilinx thinks are clocks, and how Xilinx has assigned them to pins and clock buffers.  There may be some surprises there.  I've found it useful to print out some of the clock diagrams in UG382 to check for conflicts.

 

It might be useful to post your VHDL source.  I mostly do Verilog myself, but others in this community might see from the VHDL why you're having problems.

 

In FPGA designs, it's usually best to have a single clock.  You then sample inputs using this clock, usually with an extra flip-flop stage to reduce metastability.  Slower clocks are often simulated by the FF's clock enable to convert the master clock to a slower clock.

 

I did not have time to check the documents you suggested - will do this the next days. I just had another look to the reports; nothing special in Translation or Map Report but found this in the Synthesis Report:

 

[...]

Clock Information:

------------------

--------------------------------------------------+---------------------------------------------+-------+

Clock Signal                                      | Clock buffer(FF name)                       | Load  |

--------------------------------------------------+---------------------------------------------+-------+

CLK                                               | IBUF+BUFG                                   | 13    |

Arduino_12                                        | IBUF+BUFG                                   | 33    |

Arduino_11                                        | IBUF+BUFG                                   | 1     |

XLXI_61/clk_1us(XLXI_61/xclk_prescaler/clk_1us1:O)| BUFG(*)(XLXI_61/xone_wire_interface/tbe_int)| 96    |

Arduino_8                                         | BUFGP                                       | 3     |

XLXI_61/xonewiremaster/rbf_set                    | NONE(XLXI_61/xonewiremaster/rbf_int)        | 1     |

--------------------------------------------------+---------------------------------------------+-------+

(*) This 1 clock signal(s) are generated by combinatorial logic,

and XST is not able to identify which are the primary clock signals.

Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic.

INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems.

[...]

 

Is this useful? How to use the buffer_type contraint?

 

Thanks and greetings!

Share this post


Link to post
Share on other sites

Hello DrTrigon,

 

Glad to see you are jumping in here with some cool projects. :)

 

It can get a bit tricky sometimes to get multiple clocks setup in your project. I'm guessing that the new peripheral you are adding has a clock as one of the input signals and you are directly connecting the clk signal to it? (Just a guess, I could be totally wrong but this is where we usually see this error.) If that is the case then try to connect the clock to the 32Mhz clock that is on the right side of the ZPUino Soft Processor instead. That is the 32Mhz clock that is passed through the DCM that provides all the other clocks so it should not have a conflict.

 

If that is not the issue then please post a snapshot of your circuit or just package up the whole project here. Sometimes these clock error messages get a little complicated to sort out, they can always be solved, but it could get very frustrating for someone just getting started. We can help out to get it fixed up.

 

Oh, and yes, a latch is only a problem if it was unintentionally created, it is fine when someone who knows what they are doing purposely uses it. Your clock issue should be unrelated to the presence of latches in your design.  

 

Jack.

Share this post


Link to post
Share on other sites

Hello Jack

Thanks a lot for your answer (your product and work in general ;) ! Thanks also for all the additional info you provided (e.g. about latch, etc.).
 

It can get a bit tricky sometimes to get multiple clocks setup in your project. I'm guessing that the new peripheral you are adding has a clock as one of the input signals and you are directly connecting the clk signal to it? (Just a guess, I could be totally wrong but this is where we usually see this error.)

 

Indeed this is the case! :-)

 

If that is the case then try to connect the clock to the 32Mhz clock that is on the right side of the ZPUino Soft Processor instead.

 

I am setting up a library/symbol, so I am not that far yet (schematic is empty except for my part). Does this mean I should leave the CLK unconnected for now and connect it later while using the library in an ZPUino project?

 

Oh, and yes, a latch is only a problem if it was unintentionally created, it is fine when someone who knows what they are doing purposely uses it. Your clock issue should be unrelated to the presence of latches in your design.

 

This is what I understood from johnbeetem's answer, too. Thanks for the clarification.

 

Thanks and greetings (I might not be very resposive the next week - sorry)

Share this post


Link to post
Share on other sites

Ah, so I was making the assumption that the library was for use with the zpuino. Of not there is a Papilio clocks schematic symbol that you can use instead. It lets you connect one thing to clk and then provides a 32Mhz passthrough clock. Let me know of yoy have trouble locating it.

Share this post


Link to post
Share on other sites

Ah, so I was making the assumption that the library was for use with the zpuino. Of not there is a Papilio clocks schematic symbol that you can use instead. It lets you connect one thing to clk and then provides a 32Mhz passthrough clock. Let me know of yoy have trouble locating it.

 

Second step will be to Make a Wishbone Library for the zpuino, correct! But as I was still working at the first step to create a Library from Internet code! which involves adding a CLK in step 2 (Define Your Circuit) as can be seen from this scheme I was struggeling w/o having a zpuino yet.

 

I was using the CLK from Utility.sch (on “Design” tab) as shown here, is there another one?

 

Oh, and yes, leave it unconnected in library schematic. Connect later in example schematic using one of the two methods described above.

 

This finally helped! Omitting the CLK solved the issue as I was am able to generate/synthesize the programming file now. The thing I am still puzzeling is; why the example from your tutorial contains adding a CLK ... or better; why does this not work in my example?

 

What do you mean by "two methods" of connecting? I think, I might not get your point with the different clocks... can you explain this in more detail?

 

As mentioned, the second step now is to Make a Wishbone Library based on this symbol. Here I have completely other issue described in How to connect Wishbone Registers to pins defined as INOUT (BiDirectional). ;)

 

Thanks a lot for your hints and greetings

Share this post


Link to post
Share on other sites

 

 

I was using the CLK from Utility.sch (on “Design” tab) as shown here, is there another one?
This finally helped! Omitting the CLK solved the issue as I was am able to generate/synthesize the programming file now. The thing I am still puzzeling is; why the example from your tutorial contains adding a CLK ... or better; why does this not work in my example?

 

Ok, so I think something important to point out here is this: When you are defining the "chip" you do not want to use any I/O markers. The CLK that you copied from the utility.sch file is an external I/O marker so that is where your problem stems from I think. When you are defining a chip think of it as designing all the pins that people who are going to use the chip will need to connect to when they use the chip. You should not be synthesizing a chip, you are only defining it. Your chip is most likely going to need a clock input in order for it to work. You are going to define that clock input pin, but you are not going to actually connect it to anything in the step where you are defining the chip. (Think of a library as a chip.)

 

The next step after you define the chip is to then connect that chip into a circuit. It is in this step that you will want to connect the clock input pin you defined for your chip to an actual clock source and where you will synthesize the design. That clock source can either be the CLK I/O marker from utility.sch (which connects your chip directly to the 32Mhz oscillator on the Papilio) or you can go to symbols and chose the Building_Blocks category and find the papilio_clocks symbol. Put that symbol into your circuit and then connect the CLK_32Mhz_in pin to the CLK I/O marker. This will feed the 32Mhz oscillator on the Papilio board into a PLL that will generate several different clocks for you. Each one of these generated clocks should allow you to connect multiple "chips" to them without any errors. If you try to connect multiple "chips" to the CLK I/O marker you will get the error you originally mentioned. But going through the papilio_clocks symbol sets everything up to avoid that error.

 

The second method I mention is to use the ZPUino soft processor, it basically has the papilio_clocks symbol built into it and exposes some clocks on the right hand side of the symbol. It sounds like you want to use the papilio_clocks symbol though...

 

Jack.

Share this post


Link to post
Share on other sites

Hello Jack

 

You should not be synthesizing a chip, you are only defining it. Your chip is most likely going to need a clock input in order for it to work. You are going to define that clock input pin, but you are not going to actually connect it to anything in the step where you are defining the chip. (Think of a library as a chip.)

 

As I understand the tutorial at that point, one creates an example circuit for the library, correct? Synthesizing is useful since if it does not at that stage, it won't later on when used as library either. May be I miss-understood the tutorial?

 

The next step after you define the chip is to then connect that chip into a circuit. It is in this step that you will want to connect the clock input pin you defined for your chip to an actual clock source and where you will synthesize the design. That clock source can either be the CLK I/O marker from utility.sch (which connects your chip directly to the 32Mhz oscillator on the Papilio) or you can go to symbols and chose the Building_Blocks category and find the papilio_clocks symbol. Put that symbol into your circuit and then connect the CLK_32Mhz_in pin to the CLK I/O marker. This will feed the 32Mhz oscillator on the Papilio board into a PLL that will generate several different clocks for you. Each one of these generated clocks should allow you to connect multiple "chips" to them without any errors. If you try to connect multiple "chips" to the CLK I/O marker you will get the error you originally mentioned. But going through the papilio_clocks symbol sets everything up to avoid that error.

 

This is a very extensive and useful lecture - thanks! I was not aware of the papilio_clocks symbol at all. Now ... ummm ... I really don't want to be a pain in the neck, BUT I am tempted to ask again; why it does not work with the marker? I had a look at papilio_clock and the only obvious difference I can spot is the use of BUFG to buffer all in- and outputs. Is that the magic that is supposed to solve my problem?

I could not check on this, since I was not able to figure out how to open a library again (e.g. a second time) in DesignLab; the 'edit_library' tab, etc. are missing - can open the sketch only.

 

Thanks a lot!

Share this post


Link to post
Share on other sites

 

This is a very extensive and useful lecture - thanks! I was not aware of the papilio_clocks symbol at all. Now ... ummm ... I really don't want to be a pain in the neck, BUT I am tempted to ask again; why it does not work with the marker? I had a look at papilio_clock and the only obvious difference I can spot is the use of BUFG to buffer all in- and outputs. Is that the magic that is supposed to solve my problem?

I could not check on this, since I was not able to figure out how to open a library again (e.g. a second time) in DesignLab; the 'edit_library' tab, etc. are missing - can open the sketch only.

 

Yes, the trick is in getting the BUFG's right, but it is not always easy to get it just right... It's something that I try to hide from the casual user because it becomes very frustrating and time consuming.

 

Sorry about it not being clear how to open the library again, I removed that menu item because I felt the menu was getting too cluttered and confusing. This is a work in progress and I appreciate your willingness to bear with the awkwardness involved. :)

 

If you open up the directory where you saved your library you should see an edit_library.ino file, open that file to get back to editing your library.

 

Jack.

Share this post


Link to post
Share on other sites

Yes, the trick is in getting the BUFG's right, but it is not always easy to get it just right... It's something that I try to hide from the casual user because it becomes very frustrating and time consuming.

 

Indeed, directly got an impression of it; added the CLK marker connected to a BUFG connected to the CLK input of my symbol... error!

 

ERROR:Place:1136: - This design contains a global buffer instance, <XLXI_62>, driving the net, <XLXN_1>, that is driving the following (first 30) non-clock load pins. < PIN: XLXI_61/xclk_prescaler/clk_1us1.A1; > This is not a recommended design practice in Spartan-6 due to limitations in the global routing that may cause excessive delay, skew or unroutable situations. It is recommended to only use a BUFG resource to drive clock loads. If you wish to override this recommendation, you may use the CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote this message to a WARNING and allow your design to continue. < PIN "XLXI_62.O" CLOCK_DEDICATED_ROUTE = FALSE; >

ERROR:Pack:1654: - The timing-driven placement phase encountered an error.

 

Ok, let's have a look; yes there is a xclk_prescaler.vhd but my symbol connects its CLK input to it, so since I have a BUFG there it should affect everything. On the other hand there is some effect since it is not the same error as in my initial post anymore (ERROR:Place:1108).

 

Ok, next step; added the CLK marker connected to a papilio_clocks connected to the CLK input of my symbol... works! This is a miracle to me... ;) To make it clear; Jack, I'm not surprised that your solution works but by the subtlety and complexety involved into this clock and bufg stuff... so ... thanks a lot for the papilio_clocks symbol!!! ;)

 

What would happen, if I would use the CLOCK_DEDICATED_ROUTE constraint mentioned? (Despite bad performance, of course.)

 

Sorry about it not being clear how to open the library again, I removed that menu item because I felt the menu was getting too cluttered and confusing. This is a work in progress and I appreciate your willingness to bear with the awkwardness involved. :)
 

If you open up the directory where you saved your library you should see an edit_library.ino file, open that file to get back to editing your library.

 
 
No problem - actually I was positively surprised how well everything fits together and works hand-in-hand already. You for sure don't have to apologize for it! Currently I am working with DesignLab 1.0.7 in ubuntu and the only other flaw I came across was that the filename of the generated bitstream file has an issue with case sensitivity, e.g. "papilio_duo_lx9.bit" vs. "Papilio_DUO_LX9.bit". ISE uses capital letters where as DesignLab wants small ones only - I worked around it by creating symlinks called "papilio_duo_lx9.bit".
 
 

Your advice opening the edit_library.ino worked perfectly. And now it's documented here as well - great! :)

 

Greetings and Thanks

Share this post


Link to post
Share on other sites
On 11/22/2015 at 10:28 AM, johnbeetem said:

First, on latches: The Xilinx Spartan-6 does support latches.  The registers in a CLB can be edge-triggered flip-flops or level-sensitive latches.  The are other FPGA families that only have edge-triggered flip-flops.

 

The CLK placement error is more serious.  This error usually means that there's a conflict between two or more clock signals trying to use the same clock buffers.  Your conflict might be the latch clock, or it could be something else.  Spartan-6 clocking is very complex (see the Xilinx "Spartan-6 FPGA Clocking Resources User Guide UG382).  Take a look at all the signals in the Map/Placement report that Xilinx thinks are clocks, and how Xilinx has assigned them to pins and clock buffers.  There may be some surprises there.  I've found it useful to print out some of the clock diagrams in UG382 to check for conflicts.

 

It might be useful to post your VHDL source.  I mostly do Verilog myself, but others in this community might see from the VHDL why you're having problems.

 

In FPGA designs, it's usually best to have a single clock.  You then sample inputs using this clock, usually with an extra flip-flop stage to reduce metastability.  Slower clocks are often simulated by the FF's clock enable to convert the master clock to a slower clock.
 

Thanks a lot. It works johnbeetem

# PlanAhead Generated physical constraints

NET "I[0]" LOC = "J11";
NET "I[1]" LOC = "J12";
NET "I[2]" LOC = "H16";
NET "I[3]" LOC = "H13";
NET "I[4]" LOC = "G12";
NET "I[5]" LOC = "E14";
NET "I[6]" LOC = "D16";
NET "I[7]" LOC = "B16";
NET "S[0]" LOC = "C11";
NET "S[1]" LOC = "D11";
NET "S[2]" LOC = "B11";
NET "enable" LOC = "C13";

NET "I[0]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[1]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[2]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[3]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[4]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[5]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[6]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "I[7]" CLOCK_DEDICATED_ROUTE = FALSE;
NET "enable" CLOCK_DEDICATED_ROUTE = FALSE;

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now