Forum Discussion

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

Bidirectional bus - noob question

Sorry if this is a basic misunderstanding, but I'm just learning FPGAs (I did electronics at university, but that was 20+ years ago).

I've got the Cyclone II dev kit, and I'm trying to set it up so that a (slow) CPU connected to the GPIO ports can access the SRAM via the FPGA. So, I need a bidirectional bus 'inside' the FPGA.

Having spent hours chasing varying compilation errors, I think I'm getting there - but the problem now seems to be down to the fact that the FPGA doesn't support internal tristate behaviour.

I've now got a tristate buffer at the SRAM side and one at the GPIO side and 'split' the internal database bus into a read direction bus and a write direction bus (seemed simpler than trying to get a bidirectional bus internally). So, that's OK and makes sense.

Now my problem is that I need several things to feed into the 'read' direction bus - eg the CPU can read the SRAM, or it can read control registers, and that's where I'm getting stuck. In old fashioned discrete logic, you'd have a tristate bus, tie the various outputs together, and only enable the outputs on the thing you want to read, but you can't do that on the FPGA because it doesn't support internal tristate lines.

The only way I can think of doing it is to use lots of ORs and ANDs (or NORs and NANDs) to achieve the same, but that seems overcomplicated (and slower) - is that what I have to do, or am I missing something basic?

(See the attached image for what I think I need to do, but 8 x (number of readable items) times, for an 8 bit bus)

6 Replies

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

    There is probably where writing some HDL is going to be a massive life saver. For this you need an address decoder, which in HDL would be something like this: 

    
--turn everything off unless decoded.
reg_en <= '0';
sram_en <= '0';
temp_sensor_en <= '0';
case cpu_addr(7 downto 4) is
    when x"0" =>
        --access some registers
        reg_en <= '1';
    
    when x"1" => 
        sram_en <= '1';
        
    when x"2" =>
        temp_sensor_en <= '1';
        
    ----etc

    I wouldnt want to write that out in logic gates. Let the synthesisor do the work for you.

    If you insist on schematics, you can use lpm_compare blocks and lpm_constants for the values. Extract the bits out of the address bus to decode into individual enables.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    OK - I'm slowly learning HDL. The confusing thing at the moment is that there seem to be multiple options, and I don't really want to have to learn all of AHDL, VHDL & Verilog...

    I actually have an address decoder already (written out in logic gates ;-), but the HDL way seems better). In my old discrete logic way of doing things, I'd have used the address decoder to enable the relevant tristate output onto the bus, but I don't seem to be able to do that with the FPGA.

    Once I have an address decoder, do I then do what I thought I'd have to do with and/or gates, or use something like a multiplexer, or is there a better way?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    You'll need a mux to send data back to the CPU as it will be coming back from several sources.

    As for HDL - pick one of either VHDL or Verilog. AHDL is old, cannot be simulated and is not portable (and altera would rather you use VHDL or verilog).

    Tri states are only available on the pins. You can use tri states in your code but the synthesisor will convert them to muxes, so best try and model what actually will be placed.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Thanks. I think I'll give VHDL a go, people seem to say that might be better than Verilog for beginners as it's supposedly a bit harder to shoot yourself in the foot with it :-)

    I'll use muxes then - I just wanted to check I wasn't missing something. The synthesizer gives warnings if I use tri-states, and I don't like getting warnings if I can help it, and I like to know what is really happening rather than have things changed to something 'similar', so using muxes makes me happier.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    A lot of people like Verilog because of its similarities with C, but that makes people fall into the programming trap, rather than trying to describe hardware. VHDL annoys people because of it's strong typing, but this clears a lot of errors that the Verilog compiler will allow and you'll only notice when your code doesnt work properly.

    Either way, you're describing the same hardware. Once you understand one language, the other is easier to understand/write.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    --- Quote Start ---

    A lot of people like Verilog because of its similarities with C,

    --- Quote End ---

    That was one of the things I thought about when I was choosing between Verilog & VHDL to learn first. My main job is a C++ programmer, so I thought "Verilog's similar to C, cool", but then I thought "hang on, it's for a totally different thing, why do I want it to be similar?".

    At least while I'm learning, I'd rather have something a bit stricter so I have to be more precise, and don't really care that it's not like C - in fact, not being like C means that I'm less likely to think like a programmer, which will probably help :-)