Hi John For ROACH1 you will still need to instantiate a Xilinx tri-state buffer per pin and tie the output enable with the external buffer direction (for all the GPIO pins used).
Henno On Fri, May 25, 2012 at 2:11 AM, John Ford <[email protected]> wrote: > > Hi all > > > > ROACH2 is more flexible and each pin can be individually configured to > > be input or output. We can implement Dave's suggestion on ROACH but the > > granularity is coarser, we have to configure an entire bank as input or > > output (each bank has a separate external buffer controlled by a single > > output enable). > > Hi all. Today we looked at adding a bidirectional 8 bit port. None of > us has ever built a yellow block before. We started off looking at the > gpio yellow block, and the yellow-block tutorial on the casper web site. > One of the difficulties seemed to be getting simulink happy with the idea > of a bidirectional port. > > It seems that the closest existing model for this is the shared bram, > which has an input, output, rd/wr, and an address bus. If you take away > the address bus, essentially you have a bidirectional port. > > So we fussed around with building a yellow block we called a bidirbus. It > was pretty straightforward to build a simulation that worked, using a RAM > with the address fixed to zero as the I/O element. We spent most of the > time figuring out what infrastructure we needed to get the thing to build. > I think we understand now what's needed. > > But after that, it seems to us (babes in the woods?) that adding a > tri-state or bidirectional capability to the existing gpio would be the > best solution. It seems to me the following is needed: > > 1) add the "inout" choice to the mask pulldown > 2) add it to the mask script, and check to make sure it's a good config > for the bits specified, and redraw the block with the extra direction > port. > 3) modify xps_gpio.m to handle the "inout" case > 4) Write/modify a vhdl module to implement the inout case. I'd guess this > would only be valid for a single-ended port. Anyone done this? > > Does this sound right? Is this the right way to go about it? > > As far as handling the simulation part, it seems to me that the model of > the shared bram is a reasonable model. But we really don't know at this > point... > > Any ideas are welcome! > > John > > > > > Regards > > Andrew > > > > On Tue, 2012-04-17 at 10:43 -0400, John Ford wrote: > >> > Hi All. > >> > > >> > The solution here is a new type of gpio pcore which has three gateway > >> > ports: gpio_o, gpio_i and gpio_oe. > >> > > >> > Currently there are two gpio pcores; one for in and one for out. > >> > >> Hi David. This seems like a good solution. Will this work with > >> Roach-II > >> as well as on Roach? I seem to recall the GPIO is different on the > >> Roach-2 board. > >> > >> John > >> > >> > > >> > David > >> > > >> > >> > >> > > > > > > > > -- Henno Kriel FPGA Engineer Digital Back End meerKAT SKA South Africa Third Floor The Park Park Road (off Alexandra Road) Pinelands 7405 Western Cape South Africa Latitude: -33.94329 (South); Longitude: 18.48945 (East). (p) +27 (0)21 506 7300 (p) +27 (0)21 506 7365 (direct) (f) +27 (0)21 506 7375 (m) +27 (0)84 504 5050
