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
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. :-).
My understanding of the problem is that Digilent's reference FPGA implementation for RAM access uses tristate signals, so it only works in specific configurations. Carl's blog has details: https://rescue1130.blogspot.com/2016/09/ram-problems-due-to-...
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.
If you're in the SF Bay Area, I'd also suggest seeing the 1401 in person on Wednesdays (3:00 to 3:30) or
Saturdays (11 - 11:30) - see also: http://ibm-1401.info/
