Re: Tri-State BiDirectional Pin MAX10

Altera_Forum · ‎03-31-2017

All, Since I am trying to port some older schematic files to the MAX10. I have found out it isn't just a recompile (it doesn't like Alt_IOBUFs or ALT_OUTBUF_TRIs).

It was suggested to me from this Forum to migrate to Verilog.... so....

I was having errors with Tri-state pins and BiDirectional Tri-state pins.

It seems like I have managed to get the Tri-State issues worked out in Verilog, but am not sure how to approach the Tri-State BiDirectional pins.

Here is a drawing of how the older Quartus 9 implemented the Tri-State BiDirectional pins (Mega Function Alt_OIBUF).

https://alteraforum.com/forum/attachment.php?attachmentid=13446&stc=1

Since I am working with a MAX10, I have jumped to Quartus 16 (another somewhat learning curve. Definitely "DO NOT" like the User Friendliless of ModelSim, the older version Simulator Tool was a lot easier to use.... at least for all my older designs) anyway....

Here is what I am "thinking" the way it should work.

When EN = 1

Green inout (out) = Blue In

Purple out = Blue In

When EN = 0

Purple out = Green inout (in)

Blue (output) = "Z"

This is where I get confused. How do I get the output of the "Blue input" to be high Z while still letting the Purple out to be able to see the inout?

Any ideas to help me along?

Thanks,

Keith

Altera_Forum · ‎04-01-2017

HDL equivalent of ALT_IOBUF

if (EN = 1)
 Green = Blue;
else
  Green = "Z";
Purple = Green;

You are apparently misunderstanding the function, only the INOUT (or bidirectional) port green can be tri-stated.

Altera_Forum · ‎04-01-2017

OK... but in its High Z state will it still pass data through to the output of the Purple port?

Altera_Forum · ‎04-01-2017

Yes, the purple port outputs the actual level of the bidirectional pin, which can be either '1' or '0' when read as a digital signal, bot not 'Z'. The primary purpose is to read the level driven by an external device, but if the pin is temporary floating, you still read '1' or '0', may be arbitrarily changing, or in case of CMOS logic more likely holding the previously driven level for at least several µs.

Altera_Forum · ‎04-01-2017

OK that makes sense.

Yea, converting from Quartus 9 -- MAX-II -- schematic to Quartus 16 -- MAX-10 -- Verilog, is not necessarily an easy step. I was wanting to keep as much schematic as I could for now, until I had more time to learn Verilog. Hopefully, the only issues I might have right now is the alt_IO portions. Once I get them converted to Verilog, we'll see how the rest compiles and works.

Have a good weekend.

Keith

Altera_Forum · ‎04-02-2017

I don't exactly understand what's the problem with ALT_IOBUF. Basically old bdf schematics can be used with MAX10 and Quartus 15 (I guess, Qurtus 16 as well). "Not supporting" ALT_IOBUF seems to be more a point of cleaning up old libraries than anything technically substantiated. You can replace ALT_IOBUF by a TRI and a WIRE primitive and get the same function with MAX10.

Altera_Forum · ‎04-03-2017

FvM,

I'll give that a try tomorrow at work and let you know how it turns out.

Thanks for your support!!

Keith

Altera_Forum · ‎04-03-2017

FvM,

Here is the error I receive on the ALT_IOBUF. I received the same error on ALT_OUTBUF_TRI, and that part lead me to create a Verilog outbuf_tri that so far seems to compile OK, but I haven't seen if it works correctly as I keep finding more incompatible parts as it keeps compiling more and more.

Error (12168): I/O primitive ALT_IOBUF is not supported for the selected family (MAX 10)

Any ideas?

Keith

Altera_Forum · ‎04-03-2017

As suggested in post# 6, use TRI and WIRE primitive instead which are supported for MAX10.

Altera_Forum · ‎04-03-2017

Yep, That is seeming to do the trick.

Thanks a bunch!!!!

Keith