Hacker News new | past | comments | ask | show | jobs | submit login
Restoring YC's Xerox Alto day 7: experiments with disk and Ethernet emulators (righto.com)
88 points by dwaxe on Sept 22, 2016 | hide | past | web | favorite | 14 comments



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. :-).


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.


I love reading these write-ups. These guys have amazing skills!


It's time consuming enough without having to blog and take pictures. Sure is nice of them to take us along on the ride.


Agreed, I'm waiting with bated breath for the next one... first boot is exciting.


These posts are great! I'd love to see more posts from vintage computer enthusiasts. Anyone know where they hang out?


The Computer History Museum has some special interest groups: http://www.computerhistory.org/groups/

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/


This guy has a phenomenal collection and he posts insightful videos with system walkthroughs et cetera.

https://m.youtube.com/user/jpkiwigeek?


Love the clamped to the desk fat cable going from the board to the diablo drive.


It's a prototype - what do you expect? :-)




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: