cube1 at charter.net
Sat May 23 09:54:33 CDT 2020
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:
>> 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
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
More information about the cctech