Hi, Just wanted to say, first time on the forums. I've noticed that the Ultra64 boards (specifically, the 2.0 revisions, hoho) have socketed CPLDs. By their labels, many of them seem to be DRAM controllers, but there's two that stand out: the DBG_CNT(Debug Controller?) chip and an illegible socketed chip down by the ADR0-1 chips. Has anybody managed to analyze these chips or possibly discern what they could function as on an Ultra64 board? DBG_CNT is probably an interface to memory/registers/signal I/O from the board or something like that, but the smallest socketed chip is completely unreadable or unidentifiable. A link to the image I saw this from (out of random googling for my second favorite console's development secrets): http://ompldr.org/vNndtMg/u64top2.jpg
Hard to tell without access to a better picture, it might just be an (ep)rom(/flash) though (it has another type of markings and no Altera logo as the other socketed ICs)
Indeed. By first glance I was thinking (possibly) IPL ROM, but I'm not quite so sure, as they would've directly laid that on the board in this late revision. Could be wrong, though.
There is a link to download some high resolution scans of the U64 board in the following thread, thanks to kammedo:- http://www.assemblergames.com/forums/showthread.php?p=298886
Thanks, link83, I was just searching for some high-res images. By the looks of it, it says Falce. I've heard that somewhere before, can't remember where... It doesn't look like it could be an IPL ROM, or even a ROM-variant at all...
The N64 IPL is in the NUS-PIF chip. My 2c : the DBG_CNT chip contains the logic for debugging services, and the logic for the GIO bridge.
That would be a PALCE, an electrically erasable CMOS PAL. Like marshallh said it's a simple PLD. They only have 8-10 registers and none of them are buried so they can't implement very complex state machines. 75% of the time they are used to implement non-registered logic ie random combinatorial functions / "address decoders". That said, from the pic the socketted chip near the DRAM CPLD appears to be a PAL. The socketted chip labeled "DBG_CNT" however appears to be a 44-pin CPLD -- probably either an EPM3032 or EPM3064 so it likely has 32 or 64-macrocells (and these are buried). It will be very difficult to just black box this with a massive I/O device, you'll need to trace out a netlist of the board (I don't see this happening) then watch what is happening on a logic analyzer. A 32-macrocell CPLD is a slightly formidable device for implementing things, a 64-macrocell should definitely be respected as it can implement logic that approaches impossible to crack. One really good sign though is that the engineer that designed this board wasn't terribly efficient, 3 CPLD adding up to 288 macrocells to implement a DRAM controller is over 550% of what is necessary. I would guess the PAL likely *is* an address decoder, and the "DBG_CNT" CPLD probably implements small registers and little to no sequential logic. Edit: to get started I would compile a program with debugging and disassemble it for the registers...
PALCE! Thank you, it was on the tip of my tongue. Just woke up and saw the thread, thanks guys. From what I can see, I'm agreeing with kammedo on the DBG_CNT chip. They wouldn't use a CPLD for the major purpose of registers, but I could be wrong on that. It has 32 Macrocells, and it's a EPM7032LC44. Datasheet is here. A PAL makes more sense. But using it for address decoding doesn't. DRAMCNT *should*, if they're smart, contain at least enough components for a decent memory control unit. On the case of DRAMADR0-1, I'm not so sure, but my guess is that they'd be the address decoder (why they're 2 CPLDs, I have no idea, but I just woke up. ) I can't read the numbers on the PAL chip so I can't track what model it is to make an educated guess. Going to start taking a look at some of the known models on the board, see what we're dealing with, or to at least get some clarification. EDIT: ...Yeah I don't think that the PAL is the address decoder due to the DRAM controller having over 160 macrocells. The EPM7160ELC84-15 is a powerhouse, to say the least, and they could fit decoding logic on-chip if done right. For the DRAMADR0-1 chips, EPM7064LC68-10s were used. Each have 64 macrocells. Still unknown on purpose of these chips. All in all, yeah it totals up to 288. Either they're really inefficient, or there's more going on inside those chips than we thought (none of these are low-cost, mind you, so they used them for a reason.) Now if only somebody could get the PAL's number...
???? Of course they would use a CPLD for registers, they wouldn't remask the ASIC for some debug registers on a low production item. The PAL *cannot* implement useful registers, it can implement a SINGLE 8-bit register, nothing close to a debug subsystem. There are many chips on the board that need simple decoding, a PAL suits the job; sometimes you don't tightly integrate systems if you only have the CPLD fusemaps and/or plan for expansion. The probable reason for two ADR CPLD is that the addresses are latched and directly output so other components (the PAL for example) wouldn't need to demultiplex the bus. That requires one CPLD's I/O. The other CPLD must then remultplex the bus for the DRAM, handle decoding and contain some refresh logic. The final chip (likely the big one) is a bus interface to the workstation (which possibly means demultiplexing another bus, decoding, arbitration, and whatever random logic is necessary take control from the second CPLD). But everyone knows better than me. Edit: BTW, the PAL, not that it matters, is a 20V8 or 22V10.
Valid point... I was thinking more generalized in terms of the PAL's use, sorry. But still, I'd think they'd at least bind it to the board, not leave it in-socket unless they had plans for expansion down the road (why, I have no idea) or other reasons. The ADR chips in that scenario would be plausible for use, entirely. I'm still a bit wary on DRAMCNT's place on the board, though. It doesn't seem like it'd be a workstation interface, looks to be only interfacing with on-board components.. I'm not familiar at all with console layout or actual real specification of console design as far as Nintendo goes, so excuse my idiocy in this field. Just thought it'd be an interesting topic to delve into.
The N64 was entirely SGI's design. The only exceptions are the PIF (which nintendo supplied), corresponding CIC lockout, and video/audio output by Rohm. The PAL is probably socketed because it needs to be programmed in an external jig. Same for the MAX cplds. I don't see JTAG ports for them anywhere. The GIO bus connections are under the board along the bottom edge. If I remember correctly the 128Mbit of DRAM on the board is directly accessible to the SGI workstation (usually Indy) What exactly are you trying to figure out? Is there a reason you think the CPLDs on it are noteworthy?
Was just interested in the internals of the chips. I thought I caught a glimpse of JTAG pins on the board somewhere near the DBG_CNT chip.. but looking it over again, you're right. Same with the GIO bus. Again, I was interested in the internals. I don't see socketed CPLDs or PAL devices on boards very often (especially on things like this) so I thought I'd look into it.
DRAM_CNT is situated near the CPU because it has to arbitrate interrupts/twiddle control signals. It will contain a state machine and control registers which like you said probably won't interface directly with the Indy bus as it's multiplexed. This pic shows that the PAL is an AMD PALCE22V10: http://www.schrotthal.de/main.php?g2_view=core.DownloadItem&g2_itemId=2421
good old 22v10, my nemesis.... had to use those once, doesn't have much space at all sounds strange that it doesn't have any jtag on a development board, especially since the altera max epm7160* does support to be programmed via jtag (iirc)
I confirm, all of the DRAM can be accessed directly by the Indy (and only Indy). No Indigo will ever fit a U64 board. point.
hyarion: Yeah, I'm surprised they didn't put any connectors on the board, but then again I don't think they wanted anybody messing with it.
The reason you don't see any JTAG headers is because these CPLD don't support JTAG, not until the MAX 7000S family.
guess i should have read that data sheet more carefully, I now see the foot note in the pinout section which says "JTAG ports are available in MAX 7000S devices only." doh :banghead:
