(V)HDL Toolsets

[Jay Jaeger]

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
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