14 comments

[ 2.6 ms ] story [ 39.8 ms ] thread
These posts are great! I'd love to see more posts from vintage computer enthusiasts. Anyone know where they hang out?
I love reading these write-ups. These guys have amazing skills!
Agreed, I'm waiting with bated breath for the next one... first boot is exciting.
It's time consuming enough without having to blog and take pictures. Sure is nice of them to take us along on the ride.
Love the clamped to the desk fat cable going from the board to the diablo drive.
It's a prototype - what do you expect? :-)
Ahh, the quirks of FPGA development. If I recall correctly, you shouldn't use tristate signals internally because there's actually no such thing within any modern or even semi-modern FPGA (and I believe the same may even be true of ASIC development).
The hardware internally doesn't use tristate signals, but your VHDL compiler should be smart enough to turn...

    pin <= 'Z' WHEN tristate ELSE '0' WHEN zero ELSE '1';
...into an instantiation of a tristate IO-buffer on an external "pin" which can high-Z. Sometimes the logic isn't that trivial, though, and you (as a programmer) might not realize that your code actually prohibits the pin from going 'Z'... (or you've confused the VHDL compiler).

Better stick to something explicitly simple as the code above, or directly instantiate a bidirectional I/O pin from your chip vendor's VHDL library:

    the_pin: IOBUF port map (
        T => tristate,   -- '1' == high_z
        I => data_out,   -- data leaving the FPGA, may be tristated
        O => data_in,    -- data entering the FPGA
        IO => pin);      -- physical I/O pin
I wouldn't recommend letting a tool decide what your IO is supposed to be.
There are cases where you absolutely must instantiate something from your vendor's libraries. But inference tristate I/O from a single concurrent statement will be safe (and also the recommended way to handle tristate i/o on the three platforms I've used).

    -- output data, driven active when \WR is LOW, high-Z otherwise
    d <= d_out WHEN wr_en_n = '0' ELSE (others => 'Z');

    -- input data
    d_in <= d;
Just don't bury the logic in some deeply nested if/else tree tree in a process or state machine, this is likely to not synthetize to what you had intended. :-).
Internal tristates, whether emulated or not, are usually just avoided by designers. If they are actual tristates, you run the risk of damaging silicon if you goof up your logic.

I can't say I really understood the problem Carl was having. It seemed to be IO tristates and incorrectly configured port directions, but the post was confusing.