STA assumes port in and out are linked?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
LeEs_793571
Level 2
Level 2
5 replies posted 5 questions asked 5 sign-ins

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.

0 Likes
1 Solution

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

View solution in original post

0 Likes
3 Replies
SampathS_11
Moderator
Moderator
Moderator
250 sign-ins 250 solutions authored 5 questions asked

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

pastedImage_0.png

the slack time reduces to ~3ns.

If we double sync with clock, as shown in the image

pastedImage_1.png

there is no setup time violation.

Best regards,

Sampath Selvaraj

0 Likes

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!)

Screenshot 2020-07-28 at 08.53.20.png

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.

0 Likes

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

0 Likes