On 5/22/2020 4:45 PM, Chris Hanson wrote: > On May 21, 2020, at 8:46 AM, Jay Jaeger via cctalk <cctalk@classiccmp.org> > wrote: >> >> Helpful tips - I agree with avoiding vendor extensions. Thanks. > > I’d strongly suggest that the situation with FPGAs & HDLs requires a bit more > nuance than that. You *should* probably avoid or carefully isolate vendor > *language extensions*. However, you *should not* avoid vendor *IP blocks*. > > As an example, let’s say you have a design that needs a RAM controller. Do > you: > > (1) Write your own DDR controller as part of your design; or, > > (2) Interface your design to your FPGA vendor’s DDR controller IP block? > > In general you *should* do the latter—as long as you can do so via a sane > abstraction—rather than the former, unless you have an extremely compelling > case for doing the former. > > And “portability” isn’t actually that compelling of a case: Virtually every > set of tools and chips you might want to work with will have a similar > variety of IP blocks available, many implemented via dedicated on-device > logic (rather than consuming general-purpose logic cells), so as long as you > can isolate their use you can still keep your overall design portable. > > This is particularly important for things that have strict timing > requirements and that might otherwise soak up a lot of your device’s > bandwidth, e.g. HDMI input/output, RAM control, Ethernet, and so on.
I don't think a 100K character IBM SMS machine needs DDR. 8D For my old student ECE ZAP machine, I just used very simple on-development-board RAM, with a layer in between. Probably do the same here. Ethernet might be nice, but I don't think I'd include a whole IP just to get that - probably just use I2C or SPI to an external micro controller (for lamps, switches, the console selectric, etc.) Doing this would also help me fit to a smaller FPGA. Context matters. ;) > > -- Chris > JRJ
