Topic: FPGA Recreations

in the FPGA world, should a recreation of a classic platform be gate identical (copying the schematics etc.) as close as possible, or functionally identical ?

for instance, it's much easier to decode a memory map in VHDL than it would have been using TTL chips.

is there really a point to having 74138 implementations and AND/OR gates on address lines, when you can just use a switch statement ?


I ask because the commodore pet I FPGA I was putting together has functionally identical video hardware, but it has little in common to how it was done in the real hardware - I don't see a problem with that, but wondered what other peoples opinions on this would be

2 (edited by WoS 2013-12-24 21:56:10)

Re: FPGA Recreations

You probably won't be able to do a fully 1:1 replacement. Combinatorial stuff is here the least problem. One may chose the TTL approach because of simplicity of porting. But the real problem is the way how clocks are handled.

Most of the "TTL graveyards" use a lot of local clocking systems, combinatorial output as clocks, latch functions etc., some gate delays (on purpose) - this won't work (or very limited) on FPGAs and the tools without running into quite some problems, I'd say. So to ensure it is running stable it is probably wise to change the set up to a (more) synchronous design (and leave the TTL path). In this sense it will also fit (much better) to the Replay platform which is limited to a few clock domains with proper constraining.

In the past I found quite some discussions on philosophy about that. My lessons learned from this ones: I'd say it is more important to use the time to implement something people can try out and judge on facts - instead of wasting it for discussion which will not end  wink

In my (personal) opinion every approach is ok:
- the more modern the coding, the easier to maintain the setup and keep it stable, but you might run in troubles supporting e.g. some "asynchronous behaviour" of the core (requiring clever solutions)
- keeping it on a "TTL level" may allow to set up the core more easily with a more accurate behavior, but at a point modern FPGA hardware won't do it anymore (won't fit and/or won't route w/o timing issues, even if they quite "slow" in terms of FPGA capabilities) - especially for clocks, less problematic for simple logic.
Which concludes for me: the best is to find a good balance between this approaches. And look at the warnings on synthesis tools about your setup - they are usually a sign for implementations not well supported and causing problems...

But the "TTL-coding" approach could be an easier entry point to understand what is going on and then port it to a synthesize-able setup. I do it similar just without coding: I own the original board I am going to set up and use a logic-analyser as support to understand the circuits (sometimes documents are even wrong!) and to have some patterns I am going to recreate as close as possible. With custom chips on the board, sometimes the only way (I know) to get it working...

/WoS

3 (edited by JimDrew 2013-12-25 18:15:43)

Re: FPGA Recreations

When writing normal emulations (like the Mac II I did back in the early 90's), I found that it was best to try to emulate the custom chip(s) at the lowest possible level, working out any quirks by analyzing the real chip while performing functions.  If I had FPGAs back then, I would have taken the gate-level approach because this is the only way to really emulate all of the odd (perhaps illegal and/or undocumented) states that can exist.  I found that it ended up being a slower chipset emulation if you had tons of case table entries for events as opposed to gate emulation.  Both methods can work, and with the FPGA there probably is no speed difference in the end result.

Re: FPGA Recreations

FWIW I agree with everyone else here. Having attempted a MAME-like approach with the PACE framework, I can say it works very well for some situations but is almost useless for others. I found myself using both approaches (a generic framework that is functionally equivalent, vs. an attempt to re-create as accurately as possible) for different projects.

From a purist perspective though, I'd have to say that I prefer the latter approach. However it's a lot more time-consuming and you find yourself re-inventing the wheel quite often, which was the whole point of the framework I developed. But since I was (am) perpetually in a 'proof-of-concept' phase, I didn't mind the non-pure approach too much.

Good question BTW Macro, and certainly something I've thought about before!

Re: FPGA Recreations

It's really a personal choice. I like each subsystem to resemble the original hardware, so I might have a component which has the same function and pinout (maybe with different clocking/enabled) as a custom IC.

I wouldn't go down to TTL level, usually a process can model a couple of ICs.
For example :

  p_adder : process(vol_ram_dout, frq_ram_dout, accum_reg)
  begin
    -- 1K 4 bit adder
    sum <= ('0' & vol_ram_dout & '1') + ('0' & frq_ram_dout & accum_reg(5));
  end process;

replaces the adder ICs in the Pacman audio circuit. No need to write these at gate level wink
/Mike

Re: FPGA Recreations

Yes, I see it the same way. Having the boundary of custom chips especially helps for debugging / verification against an original one. Nevertheless, for Galaga I removed parts from the custom ICs not needed for this board to make it leaner and removed the hierarchy.

Another example is H/V sync counter and generation. Instead of coding e.g. several 74161 or similar, I just set up a vector signal with the required width and code it as a single sync. counter with load. Everything else is just a lot of additional work without benefit for me.

Of course this abstraction requires to fully understand what the circuitry does prior to implementation (so probably a little more paper & pencil work).

Just coding the same TTL blocks which are usually trivial to set up and connecting them according to the schematic may initially avoid to dig into details and may look to be a faster approach, but this changes as soon as something does not work as intended (beside other problems which might pop up, like bad timing and larger implementation).

/WoS

7 (edited by hicks 2017-06-21 12:36:51)

Re: FPGA Recreations

Bumping this thread to add my opinion as I've been pondering this for the last few evenings whilst looking into doing an Acorn Electron core. This is my current view on how I'd like to approach it, however, as I've yet to implement a core this  is in no way a suggestion of the "right" way. For all I know this approach is doomed to failure.

The way I've gone with the initial implementation is one of externally pin identical, but internally just functionally identical. By functionally identical I mean I see any kind of initial implementation of the innards of the IC as fine as long as it externally appears to work the same as the original IC.

Over time improvements could then be made to iron out corner cases where due to the implementation choice it wasn't actually quite the same as the original IC.

As an example, with the ULA on the Electron that needs to access 4 x 1bit 64k RAM ICs I wanted to keep the ULA ports of the component the same as the original ULA pinout with ram0, ram1, ram2 and ram3 lines along with /cas, /ras, /we etc. As a consequence of that decision, the RAM which I had assumed would be reasonably simple to add has become a little more involved.

I  needed to implement a new quad RAM IC which operates via those signals. Internally though  I went with BRAM which as a consequence meant my RAM implementation also needed an external clock too, a compromise on pin identical smile

I may change my mind on this once I start working on the innards of the ULA as I'll now have to include logic to generate /cas, /ras, /we and so on rather than just reading straight out of a 8bit ram module and taking only 4 bits each clock (the ula does two read cycles to get 8bits from the 4 ram modules).

That said, my reasoning behind this approach is I'd like it to be possible to take someone else's 6502 implementation or 12C021 ULA and swap it in for the version used in the core with as few changes as possible, maybe renaming a signal or adding a clock.

I have gone back and forth on this for a few days though and in the end I think "whatever works" will turn out to be the right solution smile

In the time since this thread was created, has anyone changed their minds on their approach?

Re: FPGA Recreations

My opinion is that one should try to follow the original hardware as closely as possible, if only to make it easier to make later modifications and additions and refer to the original schematics. As mentioned above the more closely it resembles the original hardware, the more modular it tends to be. Obviously there are some cases where it makes sense to deviate somewhat, taking advantage of the characteristics of FPGAs. Also while it may not be quite right for this topic, I always avoid instantiating any primitives directly, trying to make everything as platform-agnostic as possible. Some projects are very easy to port from one FPGA type to another while others require extensive modifications.