- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm building a GPIB interface (which is working nicely) but I'm getting some STA warnings that seem to imply a linkage between the input of a given pin and the output to that pin despite the fact that they are unrelated in operation.
I will see if I can build a small project to show it clearly, but my current solution uses pins marked as both input and output, with each side having a hardware connection. They are configured as open drain, driving low.
With GPIB you are either in "input mode" in which case you are reading from these pins (and don't care about the output), or in "output mode" in which case you are writing (and don't care about the input), however the STA seems to show a linkage between the two (which is not there in practice) and I'm seeing paths incorporating the iocell pad_in, pad_out, and pin_input.
I assume there is no easy way for the STA to realise that these two modes are very different? Is there a way I can signal that the output and input are entirely separate?
It's all working fine, and I could probably slow it down further to make it "fit", but that seems a bit wrong.
EDIT: I've added a project that shows the same issue, in this case it's a setup violation, but you can see (what I think is) an unnecessary link between the pin input and output adding significantly to the timing path.
Thanks,
Lee.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Lee,
Your observations are perfect. The ST Analyzer finds that the inputs are connected to the outputs. On the active clock edge, the inputs really have a setup time violation, since the outputs are changing. Hence, a warning is issued, and the build is completed. We can chose to go ahead with the design as we planned.
Best regards,
Sampath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lee,
In our design, the inputs d_in are connected to outputs d_out. Therefore we get a setup time violation of ~22ns.
If we clock sync between output and input like shown in the image
the slack time reduces to ~3ns.
If we double sync with clock, as shown in the image
there is no setup time violation.
Best regards,
Sampath Selvaraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sampath,
Thankyou for your response ... I had actually experimented with this and you are correct it does reduce the problem, however it does this by introducing unnecessary delay and is actually just working around the problem.
The issue as far as I can see it is that the pins are actually NOT connected together ... the input is from the input buffer, and the output is to the pin driver ... the fact that they are related is totally irrelevant to this particular design.
If you use two different sets of pins (with a theoretical external connection) then you have absolutely no issue at all and (without any sync) the paths could all run 120MHz+ (if the device could!)
So whilst I will probably end up using sync to reduce these warnings I don't think it's actually solving the problem. Ideally I need a way to flag that the input and output are unrelated!
Lee.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Lee,
Your observations are perfect. The ST Analyzer finds that the inputs are connected to the outputs. On the active clock edge, the inputs really have a setup time violation, since the outputs are changing. Hence, a warning is issued, and the build is completed. We can chose to go ahead with the design as we planned.
Best regards,
Sampath