23 May
2020
23 May
'20
7:54 a.m.
On 5/22/2020 4:45 PM, Chris Hanson wrote:
On May 21, 2020, at 8:46 AM, Jay Jaeger via cctalk
<cctalk at classiccmp.org> wrote:
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. ;)
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.
-- Chris
JRJ