News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_robcfg

Gate array decapped!

Started by robcfg, 16:54, 12 April 16

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

SerErris

@gerald

Looking at the schematics from you again and comparing to the verilog code in MISTER implementation (which is a port from the schematic) I realize a difference, I like to understand.


Topic: Registers and where do the flipflops get its clock signal from.


Looking at the schematics it looks like that the registers are build by D-FlipFlops with Set and Reset (not all signals are connected) and clock is "enable". So they are not really clocked in terms of directly clocked by the 16mhz clock. Instead they are clocked by the sequencer (+ some other conditions) by U401.

So in essence as S0 and S7 are only high turing one cycle of the sequencer (FFh), they are actually clocked at 1mhz with a 1/16th active time. That makes sense as the data is only valid for that amount of time (4 clocks of the Z80 for any operation) which runs at 4MHz. ...

So I think I did understand how the GA works internally.


However looking at the code from MISTER it clocks much higher (16MHz).




////// REGISTERS /////

reg  [4:0] inksel;
reg  [4:0] border;
reg  [4:0] inkr[16];
wire       irq_reset;
reg        hromen;
reg        lromen;
reg        mode1;
reg        mode0;

wire       reg_latch = (S[0] & S[7]) | (fast & ~E244_N);
wire       reg_sel   = reg_latch & ~IORQ_N & ~A[15] & A[14] & M1_N;
wire       ink_en    = reg_sel & ~D[7] & ~D[6];
wire       border_en = reg_sel & ~D[7] &  D[6] &  inksel[4];
wire       ctrl_en   = reg_sel &  D[7] & ~D[6];
wire       inkr_en   = reg_sel & ~D[7] &  D[6] & ~inksel[4];

assign     irq_reset = ctrl_en & D[4];

always @(posedge clk) begin
    if (ink_en) inksel <= D[4:0];
    if (reset) border <= 5'b10000; else if (border_en) border <= D[4:0];
    if (reset) {hromen, lromen, mode1, mode0} <= 0;
    else if (ctrl_en) {hromen, lromen, mode1, mode0} <= D[3:0];
    if (inkr_en) inkr[inksel[3:0]] <= D[4:0];
end

assign MODE = {mode1, mode0};
So I think that again has to do with the "FAST" mode they implemented in the FPGA CPC version. But for my CPLD I think it should more look like that:

////// REGISTERS /////

reg  [4:0] inksel;
reg  [4:0] border;
reg  [4:0] inkr[16];
wire       irq_reset;
reg        hromen;
reg        lromen;
reg        mode1;
reg        mode0;

wire       reg_en = (S[0] & S[7] & ~IORQ_N & ~A[15] & A[14] &M1_N;
wire       ink_en    = ~D[7] & ~D[6];
wire       border_en = ~D[7] &  D[6] & inksel[4];
wire       ctrl_en   = D[7] & ~D[6];
wire       inkr_en   = ~D[7] &  D[6] & ~inksel[4];

assign     irq_reset = ctrl_en & D[4];

always @(posedge reg_en) begin
    if (ink_en) inksel <= D[4:0];
    if (reset) border <= 5'b10000; else if (border_en) border <= D[4:0];
    if (reset) {hromen, lromen, mode1, mode0} <= 0;
    else if (ctrl_en) {hromen, lromen, mode1, mode0} <= D[3:0];
    if (inkr_en) inkr[inksel[3:0]] <= D[4:0];
end

assign MODE = {mode1, mode0};
I know it is pretty much analog, but more direct implementation of the schematic with some simplifications (e.g. the inkr_en directly derived from the original signals than  doing all the real logic like in the chip)

Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

gerald

Quote from: SerErris on 12:06, 29 January 22
Looking at the schematics from you again and comparing to the verilog code in MISTER implementation (which is a port from the schematic) I realize a difference, I like to understand.
In the GA the registers are implemented a latches (hence the enable input), which requires less gate to be implemented and are OK for their purpose.
In the mister code, the use a DFF with an enable. Using latches in FPGA is not recomended.

SerErris


@gerald


I am not sure if that has been mentioned, but there is a small bug in the latest schematic (v3 afaik).


On the overall cover sheet there is one wire missing from VSync to ColourDecode. It is in both individual schematics of the modules, but missing in the overall GA module.


Signal is hcntlt28 and it also missing on the outputs list of the VSync module.


All on Page 1/18.


Not sure if you have this already corrected in a later version. So if done so - disregard my input :-)
Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

gerald

Quote from: SerErris on 10:34, 01 February 22
Not sure if you have this already corrected in a later version. So if done so - disregard my input :-)
Well spotted. I'm wondering how I got this ,missing. Fixed in the kicad file. I'll upload the fixed pdf later.

slingshot

#279
Quote from: SerErris on 12:06, 29 January 22

However looking at the code from MISTER it clocks much higher (16MHz).

The schematics cannot be translated to FPGA 1:1. Async logic won't pass timing closure, and will have erratic behavior. It had to be translated to synchronous logic, which might need changes like "thinking ahead" what will happen on the next cycle. But I left the original logic also in the source code, to cross-check in a simulator. However Verilator also not designed to deal with asynchronous logic fully, so there might be some unexpected glitches even when the circuit is simulated.
PS: I did the GA for MiST (and MiSTer) from Gerald's schematics (40010-simplified_V03.pdf - is this the latest?).

gerald

Quote from: slingshot on 16:26, 20 February 22The schematics cannot be translated to FPGA 1:1. Async logic won't pass timing closure, and will have erratic behavior. It had to be translated to synchronous logic, which might need changes like "thinking ahead" what will happen on the next cycle. But I left the original logic also in the source code, to cross-check in a simulator. However Verilator also not designed to deal with asynchronous logic fully, so there might be some unexpected glitches even when the circuit is simulated.
Async logic in FPGA is mainly a tool support issue. For sure, timing closure is a mess as you have tons of different clocks and modern design is full synchronous for good reasons, mainly predictable timing and tests.
It's not a big deal to convert an asynchronous design to synchronous. Converting latches to DFF may sometime lead to functional differences.

Quote from: slingshot on 16:26, 20 February 22PS: I did the GA for MiST (and MiSTer) from Gerald's schematics (40010-simplified_V03.pdf - is this the latest?).
Yes. The only fix I did is that missing wire on the top level page.

slingshot

QuoteAsync logic in FPGA is mainly a tool support issue. For sure, timing closure is a mess as you have tons of different clocks and modern design is full synchronous for good reasons, mainly predictable timing and tests.
It's not a big deal to convert an asynchronous design to synchronous. Converting latches to DFF may sometime lead to functional differences.

I don't fully agree. During the old days, they even checked timings manually on the mylar sheet by measuring traces length. In an FPGA synthesis, you must write very complicated sdc files to achieve this. And FPGAs has dedicated clock networks, if you're (ab)using dozens of clocks, they'll surely exhausted.
Converting sometimes is not straightforward, e.g. acting on a generated clock edge in a master clock domain need to think ahead about what will happen in the next cycle. And it's OK until there's no external signal, which affects the result, but if there is (like a CPU written register value), then things can easily go complicated.

QuoteYes. The only fix I did is that missing wire on the top level page.
Great! I want to say thanks for your work.

slingshot

I remember one particular think, which was very tricky: MODE_SYNC
As it's a clock generated by a ripple counter, it was really a mess how it worked with a simultaneous clear signal on the same D-flip-flop (U818). It's happening when the hsync length from the CRTC is 2 clock wide, then MODE_SYNC just produces a very short pulse. It's a nightmare and totally unpredictable if you implement it 1:1 in FPGA.

slingshot

Quote from: SerErris on 19:12, 24 January 22And we do have the clock output with positive and negative edge ... not sure why. So this is already 6 lines that should not be there.. There is for instance a Mode output .. (2bit ? ) ..
Those are clock enables for synchronous external modules in a SoC design. If you don't need those - then don't use them. The actual clocks are also exposed. If you check them out in a simulator, you can see the clock enable relationship with the original clocks (one master cycle earlier than the clock edge).

SerErris

Thanks @slingshot for coming back to me on that.

Anyhow I can only experiment a little as there is no way to aquire a suitable CPLD right now. Non of them can get delivered. They are either to small or far to large (footprint wise)... 
Proud owner of 2 Schneider CPC 464, 1 Schneider CPC 6128, GT65 and lots of books
Still learning all the details on how things work.

issalig

#285
I have just discovered this functional Gate Array project (warning:work in progress). Not sure if the author is someone from here.

https://github.com/codedchip/AMSGateArray

CaptainRon

Is there any real difference between the 40010 and 40007 logic? I assembled some of Darren Johnstone's boards that @issalig posted above and it is so close but not quite right. I'm wondering if there is some slight difference in timings or something else that could account for the issue? I have documented the issue a bit on the Github page ( https://github.com/codedchip/AMSGateArray/issues/4 ). I have now tried with two CPLD chips and made sure to do excellent solder work with quality 2% silver bearing solder under a Meiji EMZ-5 inspection microscope, especially on the second one. Both chips gave the same result on my Schneider CPC464. People are reporting success on the 40010 but I seem to be the first to test the 40007. Any ideas?





If anything's gonna happen, it's gonna happen out there.

robcfg

In theory, the only difference between gate arrays is the fabrication process and the pin assignments.

That is, you could take a 40010 and make an adapter to make it fit the 40007 socket, and it should work exactly the same.

dragon

You have rehused a mainboard that originally have a 40010?.

There are slightly diferencies en resistance valors.when one or other gate array are mounted.

Check this service manual.

https://acpc.me/ACME/DOCS_TECHNIQUES/SERVICE_MANUALS/CPC464_neue_Platinenversion_SCHNEIDER_Service_Manual%5BENG%5D%5BGER%5D%28acme%29.pdf

issalig

I have built the 40010 version and it works on a 6128. The 40007 just seems to have a different pinout

CaptainRon

My original 40007 works perfectly. I have checked the pins.ucf_40007 file against the 40007 pinout here at cpcwiki and against the gerber file. everything looks correct. I originally thought it might be a low voltage issue but I checked voltages on pins 9 and 38, both are 5v, and the CPLD is getting 3.5v. When I power it on I get a lot of garbage on the screen and sometimes it stays running long enough to test good for beep with the delete key or enter a few characters before it resets or freezes. sometimes it tries to initialize the cassette drive with a relay click, or shows ***program failed to load***. I tested with a different CRTC also with the same results. 

I wonder if it is an issue with logic levels on the old LS series vs. HC series, or if there is some slight timing issue? I am fairly certain it is not an issue with the assembly of the board because it did the same with two different CPLD chips. I have some from a different batch but I hate to keep using these expensive chips unless someone thinks it is possible that I got a bad batch. they programed with no issues though  
If anything's gonna happen, it's gonna happen out there.

CaptainRon

@dragon it is an old Schneider 464 with 40007 from factory and still works perfectly with the original chip. Which resistors are you referring to in the manual? I thought this was interesting

 Amendment to CPC464: 16.5.85
1. IC 125 LS7400E. It has been changed to 74HCUO4.

Mine has an old Ferranti hex inverter, I can't find much info on it but my guess is it is probably an LS series chip. I wonder if the 3.5v logic levels of the CPLD are just barely enough to trip the gates and its just twitching out between high and low? I have some Texas Instruments level shifter chips here, what signals are necessary to shift between 5v and 3.5v? Maybe I can try to dead bug wire some shifters between the CPLD board and a set of pin headers?
If anything's gonna happen, it's gonna happen out there.

dragon

#292
In page 4 in the upper left there is a little table that tell mk4 ferranti resistors value and sgs (40010) resistors value.

Also in the last page at finish there is another table.

If you need know details about the ula was a ra043 the 5000 series ferranti  ula, it's described in the book of the zx spectrum how build a micromputer

That's another thing just curious. How your cpld works with VRAM Rasterization timings?.

https://www.grimware.org/doku.php/documentations/devices/gatearraydo=export_xhtml

(go to the finish part of the page there is a program there to test it).



CaptainRon

It is not stable enough to run more than a few seconds before locking up. every once in a while I can type a few characters or test the beep with the delete key, but that is it. I cant type in the program before it will lock up. I can connect a logic analyzer or o-scope if there are any specific signals you are interested in.
If anything's gonna happen, it's gonna happen out there.

robcfg

LS and HC have different activation levels, that could be definitely an issue.

Bread80

LS series logic requires a signal higher than about 2V to register a logic high.
For HC series that requirement is 3.15V when running at 4.5V, and will be higher at higher supply voltages.
And, having just checked, that HCU04 requires a signal of over 3.6V. Although the 6128 schematics show a pull up to 5V - R140 (1k), but maybe that changes on different board revisions.

And I've only just noticed that the schematic okays both LS and HC logic. In that case any GA replacement will need to be outputting 5V to work properly across all machines.


CaptainRon

I ordered a replica 464 and 6128 board from Rob Taylor (PeepoUK). My plan is to build up the 2 replica boards and test the CPLD gate array on both. I will put my original 464 back in stock condition and keep it put up. These old CPC computers are rare as hen teeth here in the USA, so I will just use the replica boards for the tests when they arrive. I will post here again with my results
If anything's gonna happen, it's gonna happen out there.

codedchip

Quote from: Bread80 on 17:40, 24 July 22LS series logic requires a signal higher than about 2V to register a logic high.
For HC series that requirement is 3.15V when running at 4.5V, and will be higher at higher supply voltages.
And, having just checked, that HCU04 requires a signal of over 3.6V. Although the 6128 schematics show a pull up to 5V - R140 (1k), but maybe that changes on different board revisions.

And I've only just noticed that the schematic okays both LS and HC logic. In that case any GA replacement will need to be outputting 5V to work properly across all machines.


From my checking on a 464 I have managed to get hold of I'd say that I should have incorporated level shifters on the board to get to a 5V output. That's likely all that's wrong with it. I'll spin another revision incorporating those.

That said, as I mentioned in GitHub, the purpose of the boards is to test the verilog. I'm now pretty confident that works and I'm sure someone else would be able to do a better job of the physical boards anyway. The verilog source for my purposes has moved beyond the prototype boards and is now part of a bigger project I'm working on to make a replacement motherboard, where I can control the logic chips and also use the "opened up" GA to provide expansions.

So, I'll create a new revision with level shifters and try it on a 464 and publish it on GitHub. I'll also convert to kicad while I'm at it.

revaldinho

QuoteSo, I'll create a new revision with level shifters and try it on a 464 and publish it on GitHub. I'll also convert to kicad while I'm at it.
Thanks for making all of this work available on GitHub.

If you're making a small batch of these revised boards then I would be interested in getting one.

I have a request though - could there be an additional row of in-line pins, say 5 or so, to give direct access to unused CPLD IOs ? It would be handy/fun for experimenting with customizations of the GA to be able to bring in other signals which aren't in the standard pin-out.

Also, in the schematic there is only one 220nF cap on VCCIO with nothing at all on VCC. Xilinx recommend one 0.1uF cap per VCC pin close to the CPLD for high speed designs. Now this isn't a 100MHz+ design, but even so, it would be good to have a couple more closer to the CPLD with dedicated caps on both VCCIO and VCC. Perhaps make pads available on the back of the board if otherwise there are restrictions on single-sided assembly.

codedchip

No problem. I can do that. Thanks so much for the feedback. PM me, I'll be happy to send you a test board.


Powered by SMFPacks Menu Editor Mod