Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Bus mux issues

Hi all,

Im new to this forum and fairly new to CPLDS, so please bear with me

I have got by with schematic entry so far, and hope to keep doing so for the time being.

Anyway my issue is I am designing a full shadowing prom emulator using 2 srams, its not a conventional design as the a 16bit address and data bus is multiplexed into 8 data lines and 3 control lines but am using standard parallel bus srams.

Ive managed to implement all the functions required except the bidirectional data bus.

I need the host bus to connect to the 2 sram data buses and be bidirectional and have implemented them with lpm_bustri. The attached image shows how Ive done it.

The Select Line should switch between the 2 and the Dir line controls the direction. When I test it the host bus is always tristate, its not driven at all, now if I take the two bottom and gates out and ground the 2 inputs to the tribus i can read data back from the sram, if I deassert the DIR line the bus goes tristate as expected. So it works in 1 direction from the ram to the host.

Have I implemented it compleatly wrong ? Is it ok to tie the result and data togeather like I have done, if not how should I implement this ?

Thankyou

Andrew

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi,

    Your design looks ok to me so far...

    It is clear that at any given value of sel/dir only one buffer is switched on so I don't expect contention in your design itself.

    However, your test of cutting off of host drive points to the problem being a contention with host. Check that the host is cut off from there, not from your AND gates.

    Similarly the sram should not drive when written to.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    Is it ok to tie the result and data togeather.

    --- Quote End ---

    I understand, that you have three external busses. Physically, three-state driver I/O cells are required for each of it. I'm not sure, how the compiler understands your logic. You can consult the Quartus netlist viewer to check. But I suggest to use 3 bidir I/O symbols with the external sides connected to the busses and wire the internal sides accordingly. This should clearly instruct the compiler what to do.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Good point from FvM but I take it that the host pins will be permanantly enabled tristates.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks for the reply guys.

    There is somthing wierd going on, the RTL Netlist viewer looks ok from what I can tell.

    At the risk of sounding dumb, Im not sure I fully understand you FmV mean when you say "use 3 bidir I/O symbols with the external sides connected to the busses and wire the internal sides accordingly" I thought that is how I have implemented it.

    With further testing, instead of cutting off the AND gates, I bought the DIR signal out to a pin for the bottom 2 AND gates ( inst9 & inst10 ) and back in through another pin so I can measure whats going on, and it reads as expected but still doesnt work properly, its flakey, somtimes going tristate on readback, if I directly control the and AND gates seperatly by connecting the pin to ground and VCC it works as expected.

    I seem to be having some sort of bus contention, I cant see how though, the same DIR line is used to feed the OE signal for the selected ram.

    Now my design is really packed, and adding even 1 more pin makes the fitter not able to route the design. Is it possible that being so tight is causing it to act flakey?

    Im going to do some more testing tonight by using the host to drive the RAM > HOST Select and Direction signals seperatly and see if it works as a whole. Im hoping it will, as it works when phsically tying them to ground or vcc.

    Thanks

    Andrew.