Project to create an ATX 80286 mainboard based on the IBM 5170

[rodney]

I tried to add the pll into the block schematic and went through the megawizard which can also be recalled and taken through the settings again at any later stage for an update to the block component.

So mostly it's just a matter of filling in the values, and the megawizard will create a number of HDL files and a block schematic part for the altpll function. If you update it, it can overwrite a new set of files.

And what's significant here for our understanding is that you can verify the actual operation mode of the PLL, which is shown in a confusing way due to a simplification of the factors displayed next to the values you entered, is to read a bit lower on the screen what the running values will be for fVCO for the PLL.

In the attachment the example steps for creating 286_CLK and HDL_CLK.
So I named the general FPGA clock signal HDL_CLK to illustrate that it's the clock used for general FPGA mechanisms.

In the attachment you can see below the resulting value for fVCO is indeed 768 MHz as per the example frequency scheme I wrote about.
I was not able to set this myself anywhere but it's still automatically concluded from the values of factors.
So it's good to be able to actually see that value there.

So with the 24/48 MHz values for SYS_CLK and 286_CLK, we would divide fVCO by 6 and end up with 128 MHz for the fast internal FPGA clock.
I am doing that also because I want to be able to modify the value for m and then end up with a range of 286_CLK between 18 and 30 MHz roughly and end up with what I think are reasonable values for the FPGA clock. So this can enable us to easily and quickly test with other frequencies to clock the 286 with.

Okay so I finished this part of the design now and moving on where I added the pll component into the block schematic and wired it in.
And there also becomes evident that we, in the current design evolving from REV3D, cannot output the PLL clock directly on the PLL_OUT pin.
That's because we want to manipulate the 286_CLK in novel ways which is just incompatible to the PLL_OUT idea.

Anyway I added the 286_CLK output pin on the PLL_OUT pin of PLL 1 anyway since this is also a normal IO pin if the design needs that instead.
Though I don't see this actual specific use unless we keep the CPU frequency constant which so far has only worked at around 16-18MHz.
In that case the VGA cycles are really efficient and practically identical to the normal RAM access.
And that is of course cool and interesting but practically not very useful for our goal to increase the performance.
Which is always going to need cycle speed manipulation to be an integral part.
After creating the PLL HDL file set, I reviewed the code and I did see a lot of options which are not exposed to connections in the block schematic part for the PLL.

Anyway due to the nature of our PC/AT project, I don't see any purpose for clock output enables to be used so I didn't try to pursue that in more detail.
Possibly if that is the case, quartus could deduce it by itself and use the clock control block area of the chip automatically I suppose.
Which it already seems to do for the clock multiplexer used for 286 cycle control since it lists a message about this to be "protecting" that area.
In the technology map view quartus shows the HDL code of the PLL in separate block diagram parts spread out in the diagram.

So after looking at the existing clock design in the system controller, I revisited the SYS_CLK / PCLOCK usage in the design with a few experiments in the REV3D system controller.
However the apparent issue is that SYS_CLK by design starts running at the moment when the 286 asserts the first cycle status outputs to read the ROM code.
So that's rather specific and cannot be exchanged with PCLOCK which is always running to first sync the 286 to the clock when coming out of RESET.
Same goes for the RESET_286 logic suggested by Intel and elaborated by IBM in the 5170 design.
That 286 RESET area added by IBM naturally follows from other sections in the 286 documentation book by Intel for when the 286 executes the status output sequence resulting in resetting the 286 separately while the rest of the system including the VGA controller keeps running.

Changing any area, at least in the REV3D system, where we know that the CPLD designs can also be sensitive to modifications, results in a range of outcomes between moderately stable but showing timing mismatches to completely not posting. Finally I abandoned that work when it became apparent that it won't lead to useful outcomes for the REV4.

Besides possible sensitivity of the REV3D to modifications, several areas in the design just appear to need the SYS_CLK behavior which becomes active at the first assertion of the 286 status outputs and cannot run on a constantly active clock during system or 286-only RESETs.

So the conclusion so far is that we are going to need both SYS_CLK and PCLOCK in the REV4 design.
I can do more testing in case we can succeed to fully debug the REV4 ISA test card.

Also it remains unclear why in the REV3D system controller SYS_CLK and PCLOCK seemed to be in phase with eachother.
At least, I have measured that earlier with my simple LCD scope which surprised me at the time.

Likely it's due to the timing of ENAS which depends on the 286 which determines a specific falling edge of 286_CLK the SYS_CLK will transition on.
Which will be a delicate process that also depends on the clock speed itself. Which would also explain why the REV3D system operates best in a specific clock speed window, which makes sense.

In the design and during the debugging of the REV3D, I have gone on pure observation of stability tests to choose certain design modifications.
The system will quickly show it if anything is slightly off so that's useful to pick up on more or less stable functionality.
So later in the debugging work I observed the phase alignment between PCLOCK and SYS_CLK.
Depending on the 286_CLK frequency, SYS_CLK may "jump" on another phase.
I am sure in the FPGA it will be more certain which phase it will jump to compared to the REV3D.
We can modify this accordingly.

Definitely in the REV1 design they were counter phased so it must be the timing of that specific CPLD being different resulting in a different outcome for SYS_CLK.
Anyway, of course I moved the REV3D design forward according to what designs functions best which led to the final quartus versions so far which I published on GitHub.
And in addition we raised the clock above 20MHz which changes many areas of the system control design timing so that needed to be compensated for.
That includes the READY timing which is also delicate.

By the way, I observed specific differences in compilation approach by quartus when working with an FPGA.
One remarkable thing is how quartus deals with those D-flipflops which specifically have active signals on both the preset and clear inputs.
Here, quartus is more aware of the situation and modifies the circuit to accommodate that usage.
In the CPLD design I have had to make my own modifications, and even created two D-flipflops using a number of NAND3 gates to get better operation mode and timing.
Which of course takes more logic fabric but it's just necessary to gain the same efficiency as with lower clocks.
Of course you can modify the preset and clear inputs with some gates but that only is able to result in an override when both are applied, either way as you wish.
So the mileage on that varies as well. To get both outputs to go high, in fact, to even obtain both those outputs, it really needs the NAND approach in speed critical areas.
I did see some alternative D-flipflop parts but I never tested out their operation mode, and quartus throws a message that it's not advisable to use these parts.

So I am now going to work on the schematic to update with the final pin assignments, and then I will look at the other areas of the design.
I am thinking to dual purpose certain pins to possibly be able to generate some display output even when the 286 is on the card.
Which could be cool for diagnostics during the debugging since we don't have the POST displays.
But I am not sure to what degree this could possibly work yet. Maybe only MDA type of output, and there is also the amount of logic needed which I don't know yet, I will update more on this later when I know more details. If there is some chance to get some type of display output, I will prepare the card PCB for that.

So the REV4 test card is going to use 4 layers and I will order the cards made with ENIG finish since this is more solid and structurally stronger to solder larger SMD parts.

Kind regards,

Rodney

 

[kevju]

@rodney I took a closer look at your REV3 project, and offer some constructive criticism Some REV4 advice follows.

First, your schematics are enormous. You can make them make them significantly smaller by using bus connectivity. For example:


In the RTL viewer, you can see how the components form an array automatically:

Note that the bdf editor in Quartus can be kind of quirky...in particular, placing components directly on a bus might connect with node lines instead of bus lines, so draw bus lines explicitly to be sure.

Second, you do some naughty things with delay dependencies, clock gating, latches and async logic. You should consider refactoring the project to clean this up:

• The low hanging fruit is to use DFFE instead of DFF registers so that you can get your clocks out of the logic. Every DFFE should be clocked directly from the global clock network(FCLOCK). Your goal is to enable the FF just before the clock edge arrives and disable it directly after. It may be helpful to run an inverted copy of FCLOCK on the other global clock network so that the enable edges straddle the clock edge precisely. There is a mechanism built into the clock networks to support this setup separately from the macrocell logic(it effectively doubles the clock under certain scenarios). Don't use the divided clocks for anything but driving external clocks or controlling the FF enables. This alone may improve REV3 timing enough to let you hit the 25Mhz you were looking for.
• Don't use PRn and CLRn for logic. Connect every CLRn to the global clear network, and don't use PRn. I know that old mainboards did stuff like that with TTL chips. Make sure that CLRn is released synchronized to FCLOCK by keeping your clock generator disabled for a few cycles - you could use a few element shift register with it's input (and CLRns) tied to global clear and output tied to the enable of the frequency divider.
• Consider using the Altera State Machine Editor (File->New->State Machine File) to capture some of your state machines, or even implement them in HDL. Have a look at The Fundamentals of Efficient Synthesizable Finite State Machine Design Note that one-hot encoded state machines are typically used in FPGA designs, but binary encoding is fine for CPLDs if you are low on registers.
• Consider increasing FCLOCK. This is a more significant refactor and you will need to make sure that an edge on GCLK1 doesn't interact with an edge from GCLK2 (or vice versa) without a full clock cycle in between. 100Mhz with the inverted clock above would give you down to 5ns resolution.
• Consider writing timing constraints files for the projects. If you at least define FCLOCK, Quartus can make better decisions about synthesis and placement. I did this for the U1 project (32Mhz) and it fails to close timing by a small margin.

With respect to REV4, anything around 20-30Mhz will work to generate the high speed internal FPGA clock. If you don't want to bother with a separate clock for OSC and the PIT, you could use 28.6363Mhz with M/N of 18/5 for 100Mhz. Digikey does stock 21.47727Mhz which would let you hit M=32 perfectly with a great range for N, but there is only one part listed (at least in the US). Running your clock to both sides of the FPGA will let you use both PLLs if you need to define more phases of the high speed clock.

 

[rodney]

Hi kevju,

Thanks for your message, I appreciate your tips and advice!

Note that the bdf editor in Quartus can be kind of quirky...

I had noticed that a lot and recently I found a few more workarounds to other quirks of miss aligned placement of part connections when pasting stuff.
There seems to be some coordinate quirks going on where the parts will suddenly glitch to the adjacent spot when clicking on the mouse, it's jittery but I can work around it.
So I will remember to carefully draw the bus always outward from the component connection first and then route it on to other areas.

The block diagram is even larger in the REV4 design which will shock you but I haven't had trouble to navigate it so far using zoom in/out and the hand tool is particularly fast when moving around, it must be the code of quartus that works better with that hand tool.

Eventually I will probably grow more used to the bus lines which already pop up on the HDL core AT controller parts.
It's neat to see how that works with the duplicate parts in the result, nice example!

Particularly the clock enable flipflops, I had not looked into using these yet so thanks for drawing my attention to these, this already will inspire me to think about a lot of applications, super useful!

I remember previously wanting to prevent that flipflop outputs change state and not let them clock through constantly, for which the clock enable is much more ideal where you can insert more conditions using that mechanism. I just did some searching about this which illustrated some other details, nice.
I frequently do more tests and development on the REV3D CPLDs, I will do some experiments with these clock enable parts.

I will provide the OSC externally on an input for the timing sections of the system timer HDL part.
If that turns out not to work well, I can still change the plan later.

Okay I will wire the second PLL up as well, I think I should be able to do that by moving one IRQ to a different pin.

I am prepared to expect anything when starting the REV4 testing, it may end up being an adventure which is totally okay, we will see then how to deal with that, I can adapt the approach.

Anyway a few positive things already are the large number of registers available and of course the much improved clock management.
No more running out of registers is just cool.
I just really like the idea of changing the 286 clock speed by updating the programming, I look forward to trying that out.

I appreciate your continued tips kevju!

Kind regards,

Rodney

 

[kevju]

wire the second PLL up as well

Make sure that the traces are the same length so that the difference in phase between the two sides is as small as possible. A balanced-T would work well with a 33 ohm series resistor at the oscillator and 22 or 33 ohm resistors on either side of the T (immediately adjacent to the junction and located directly in the center of the chip on the bottom side of the board).

I just really like the idea of changing the 286 clock speed by updating the programming

The Cyclone II is honestly not great for this. There is no provision for dynamically changing the frequency (Cyclone III and later), and you have only 5 bits of divide/multiply to work with. You could use a Si5351 which has a much more flexible PLL (20 bits divisor) and can be reprogrammed dynamically to change frequency and phase (and do it in a way to avoid short-cycles). You can use this to smoothly sweep the system clock to any arbitrary value while it is running, or even adjust OSC by a few Hz at a time for CGA composite output.

 

[rodney]

Make sure that the traces are the same length so that the difference in phase between the two sides is as small as possible. A balanced-T would work well with a 33 ohm series resistor at the oscillator and 22 or 33 ohm resistors on either side of the T (immediately adjacent to the junction and located directly in the center of the chip on the bottom side of the board).

Okay, thanks for the tip, I will keep this in mind.

The Cyclone II is honestly not great for this. There is no provision for dynamically changing the frequency (Cyclone III and later), and you have only 5 bits of divide/multiply to work with. You could use a Si5351 which has a much more flexible PLL (20 bits divisor) and can be reprogrammed dynamically to change frequency and phase (and do it in a way to avoid short-cycles). You can use this to smoothly sweep the system clock to any arbitrary value while it is running, or even adjust OSC by a few Hz at a time for CGA composite output.

At least it's now programmable which is super useful and a lot better than needing to swap crystals for testing the 286 clock limits.
The oscillator can be soldered down solid thanks to that which is also an improvement.

That chip looks interesting, maybe I could try to build a test clock generator with this using some cheap micro controller and display.

Kind regards,

Rodney

 

[kevju]

maybe I could try to build a test clock generator

Breakout boards using that part are widely available: https://learn.adafruit.com/adafruit-si5351-clock-generator-breakout/overview

Note that you get no clock output until they are programmed, but there is an OTP memory to allow clock output at startup.

 

[rodney]

Note that you get no clock output until they are programmed, but there is an OTP memory to allow clock output at startup.

Thanks kevju, good to know.

I will look into this because it will be very useful to try this chip out.

Kind regards,

Rodney

 

[rodney]

I have worked more on the 286 system control.

I have done numerous attempts in the past years to approach the system control in a synchronous way, however there were a few issues.
Particularly the 286 initiating the S1 and S0 status outputs was occurring off the existing edges which were available so far.
So I was not able to clock this in and connect the rest of system control on these events so I proceeded to take the 286 status asynchronously since this was fully functional in my tests.

Indeed, using a higher frequency clock input can create higher resolution to catch the 286 exactly on it's internal timing.
However, using the CPLDs this is likely to start to need more registers to create a matching timing with the 286 since this is off the existing clocks, at least, it was in the REV1 system control, up to 18MHz.

It's difficult when even adding one register can throw off the timing. I am not sure if this will be possible, but I will explore this further despite expecting that to happen, since I have had this plan since a long time and did various attempts before, so far unsuccessful. However since the REV3D timing running at 44.8MHz 286_CLK is very different from the REV1, it needed to be in order to even be a functional system at 44.8MHz where I did some experimental level stuff in the design to make the timing work, I plan to revisit a few previous ideas within the limited constrictions of the CPLD register capacity. So I may need to free up registers first in order to be able to use these later on.

So I'm currently considering to add two more state machines in order to replace a number of existing registers. So I am going to build two state machine models to control the wait state and READY timing, processing the conversion scenarios, and to operate the conversion A0, ALE and re-enabling mechanisms needed during the command in progress. If the state machines can replace a lot of registers, it's my hope that this can free up more logic to deal with applying the new control. So it's a matter of trying to do more with less logic, I am trying to explore that. The state machines will be binary for register efficiency using CPLDs. Later I may have a look at the quartus native state machine designer, but I already saw (in V13) that this is a really constricted process where you cannot add in any descriptive information. The quartus designer program is really limited to only be able to add in the state machine into the design. Maybe I can find some alternative method to generate a HDL based state machine and then insert that into quartus as a design file. At least I want the state machine to be able to reflect what it is doing in the system, so a reader can more easily be able to follow the construction, since my designs are also meant to reflect and illustrate historic designs for the future when original machines will be much less available for study and use. If the system becomes more abstract without being able to recognize the separate mechanisms anymore, that will defeat my original purpose to provide insight and understanding and be pretty useless to me. I am not merely after getting a system that functions, and there are already models for that such as the ao486, it also needs to remain a good illustration of what's going on and being able to see the different parts that form the system. And, in addition, I hope to be able to keep using the original CPU chips of the time period. Replacing these with HDL as well seems to lose some identity and feels undesirable to me, at least for the time being when time period CPUs are still available, I would want to see original CPUs on the board when possible.

So using a state machine we can anticipate that the timing, if exactly on the 286_CLK and derived, will need the entire design to operate more tightly on the clocks, including the 286 itself. So this also involves examining the 286_RESET timing which directs the 286 where to synchronize itself. I will not exclude that I still will need certain asynchronous circuits if I don't have enough resolution in this CPLD to catch the 286 status in a functional timing, but I will try to get things synchronized in the interest of the coming REV4.

I have no testing experience with FPGAs yet which will happen soon, but being able to use small phase differences to get different timing and having so many registers available, that should provide many more means to work with than I have now. My idea is also to obtain a more synchronous model now that can be used as a possible starting point to get a functional FPGA version running. Having an operational design is the best possible starting point from which we can work to replace and improve the system control in incremental steps. The new system control can run alongside the previous one, and then we can gradually put the new signals into operation.

So yesterday I examined the clock situation another time. And there it's not so straight forward to take any measurements because when connecting internal signals to a pin in order to record their timing, this potentially(likely) can shift all the timing beyond the fully functional levels they are currently in. If the system is non functional or functions differently, that defeats the purpose to get the timing from it.

A non functional system can happen in a few levels, the 286 can continue running cycles in undefined function where we have only a partial POST up to 01, 10 or 0A, or the 286 will stop somewhere in a cycle in progress where we don't get any POST level. Sometimes this can be observed when the 286_CLK remains in slow speed, which probably means it was operating in some BIOS routine from the 8 bit ROM and then stopped. Also the VGA INIT can happen in different degrees such as enabling the VGA monitor sync but no picture yet. Ideally that is not a scenario we want to happen. So the work involves every time copying the functional design and retry to add modifications that are able to be integrated without throwing off the whole design, it's very time consuming and uncertain if and how it will work out. Timing diagrams from 286 documentation are not an exact science, and besides, when running a much faster 286_CLK of 44.8 MHz the timing becomes much more critical. Especially around 40MHz there is a boundary which seems to need new timing compared to around 16-18MHz.

In addition, there is a slight difficulty to analyze the out of RESET timing of the 286 because the first reads by the 286 in this particular system are from an 8 bit ROM chip which involves the slower 286_CLK. I have done some experiments similar to how the ENAS timing works to initiate the dynamic clock a little later but so far it didn't pan out. It's another factor of influence to the design.

 

[rodney]

Anyway, I have worked to try to get some measurements of the exact relationship between PCLOCK, which is where the 286 synchronizes itself on because the RESET_286 timing is controlled by this clock, and SYS_CLK, which is evolved from the 5170. So in the measurements I have been able to establish that the SYS_CLK signal is slightly behind PCLOCK, with only about 5ns or so, which is extremely difficult for me to measure with the inaccurate LCD scope, I use a method where I reverse the probes and measure again, so I can establish the measurement error between the channels on the display and factor this into a better understanding of the actual timing. In attachment the PCLOCK in yellow and SYS_CLK in green. The signals look a bit unstable and wobbly but that is due to ground connection of the clips on the PC case as well. Anyway it's the timing that matters and we can read this from the measurements. I measured the SYS_CLK from the slot with the PCLOCK directly from the SC_SP3 pin on the System controller CPLD which turned out to be a functional design to be able to measure from. So the measurement is an explanation for how the current logic at 44.8 MHz 286_CLK is able to fully function. In certain areas the delay between the clocks is helping the design to meet the timing that is necessary to function, for that design model.

Well, I have made a potentially crucial step forward yesterday, I have now finally succeeded to get a functional design which only uses PCLOCK, on which the 286 aligns itself, and no longer using the SYS_CLK. The design no longer needs the ENAS signal either to start the SYS_CLK and derived clocks. So I am running PCLOCK instead of SYS_CLK on the slot output now which is also used by the VGA controller. So in that design, PCLOCK is now substituted in the previous SYS_CLK usage.

However there is at the moment a substantial price to pay for being able to do that. At least, so far, which is that we lost some VGA cycle performance in the process. The VGA writes are reduced from 11120W per ms down to 8969W per ms. Nonetheless I will continue this avenue of testing and development to see if the higher performance may be able to regained later on after integrating the two state machines. Also, if the existing design will not function in the FPGA as a starting point to work from, I can have this different model available for testing later. If that functions, I will be able to use the new "one-hot" state machine type to replace the CPLD state machines, and continue from there.

So I have established a new system control which is even able to synchronously clock in the READY sample conditions, which is the first time I was ever able to do this so far since REV1. It appears that the 286 in this alternative REV3D CPLD design is more tightly aligned to the clocks than was previously the case, which now enables to do a whole new range of development and tests to modify the system design. I will also try to eliminate the NAND flipflops which so far have been critical to get to a functional level at 44.8MHz 286_CLK, however these NAND circuits also contain some feedbacks which consume much more logic than regular registers, so it will be better if it would be possible to eliminate them at some point. I will work on this and see how far I can get, and possibly later on I may test with faster input clocks and divide down for the 286_CLK output. However I anticipate this will probably also require the new state machines to free up more logic by replacing a number of existing registers. The idea is to get a functional system with a lot less registers, which could then enable to work off a faster input clock. I think I have a 80MHz oscillator somewhere, I will try to find it later.

Kind regards,

Rodney

 

[rodney]

I have done a lot of work to create an additional state machine in the REV3D system controller CPLD.
The idea there has been to accurately predict the possible cycle types which can occur in the PC/AT, where eventually the plan is to derive the system control timing from this model which runs synchronously along with the system.

So primarily we have the fast 16 bit memory cycle which starts the memory command in the first command cycle based on the requirement that CMDLY is not applicable, and depending on the zero wait state option could proceed to READY immediately, or continues an additional command cycle and then continues to READY using a single wait state.

Then we get the fast 16 bit IO cycles starting in the second normal command period, where at the same time all other types of commands are asserted at the same time as well, so only in the second command cycle from the perspective of the 286, we are able to fully decode all remaining scenarios outside of fast 16 bit memory. In this second command cycle there is branching in the state machine to either run a converted cycle or remain in fast 16 bit mode to proceed to a third 16 bit IO command cycle where we extend the IO commands and then proceed to READY with a two wait state timing for 16 bit IO.

In the conversion cycle branch of the state machine, the conversion mechanisms starts with 286_CLK_n timing:
- CONVA0 pulse starts, and CNTL_OFF starts, disabling the command in progress and storing the low data byte in the conversion register at the exact same time as the command is paused
- CONVALE pulse on period, clock store CONVA0 into LS_A0 which drives the SA0 line on the system bus during 286 cycles
- CONVALE pulse off period
- asserting SET_ARDYEN0_n and stops the CNTL_OFF period where the command then becomes active again
- proceeding to run a converted command cycle time period where the previously stored low byte is processed to the 8 bit address location
- READY timing occurs for the converted cycle and the actual transfer is performed by the 286

Basically this procedure covers all the 286 cycles. One critical factor is getting a correct timing model while the system remains in stable operation. VGA cycles for VGA controllers that support 16 bit mode can be separately decoded and apply READY at other timing, depending on whether dynamic clock is present or not.

So I have done a lot of measurements to see where the mechanism signals become active compared to the 286 cycle timing.
When I connect an additional pin with certain logic output in the quartus programming, this can either result in a working system or render the system non functional because the design may(and likely will) end up being compiled differently by quartus in order to route the signal to the pin for measurement. In other words, not all internal signals in the CPLD system controller are able to be measured while the system remains functional, which makes this work a lot more difficult and time consuming.

Another factor is the number of registers consumed by the design. When this increases, it also becomes more likely that quartus will create a program file which is significantly different from the operational version.

I tried two models of a state machine which follows the different cycle types in progress based on the cycle timing and wait states.
One transitions mid period same as the wait state shift register, and the other transitions at the 286 cycle boundaries.
The state machine which transitions on the 286 cycle boundaries so far appears the most useful one to derive timing from.
So I was able to initiate CONVA0 and CNTL_OFF timing from the state machine, but I was not able to get much further than that because of compilation issues where I could no longer get a successful POST going. Also the state machine decodes showed some minor glitching which indicates that the timing of decoded signals is slightly off due to propagation. It seemed to still run accurately but the skewed pulses became visible on the scope which to me indicates that the state machine is on the edge of what is possible in timing.

What I really need is super accurate timing measurements so I can draw out timing diagrams obtained from the functional system with a higher degree of accuracy. The 286 READY timing appears to be the most delicate and apparently must occur slightly off the typical boundaries of PCLOCK and 286_CLK, which is just difficult to create. So in all my development and tests, I so far was only able to do this by slight changes in the logic which result in the necessary delays. I think in the 82284 they did this by creating a certain precise delay in the PCLOCK from the 286_CLK falling edges, which is then internally used to clock READY on the exact right timing where the 286 is able to complete the data transfers. In the REV1 and REV3D system control designs this has been the most difficult aspect to be able to produce in the quartus program file results. If I wanted to create the READY timing in clock accuracy, that would require a much faster input clock, and a number of additional registers.

For now I will probably save this work for the FPGA stage design where we can attempt to get all the timing from faster clock boundaries instead of logic delays. Maybe this new design can then be reduced to a minimal version operating from the faster input clock, which then might be possible to transfer into the CPLD system controller. Maybe we can create the equivalent of the 82284 PCLOCK or possibly a 286_CLK which contains that delay, and that could then aid in obtaining the READY timing more easily on those clock boundaries. So that's my current plan, first get a minimal synchronous model in the FPGA, where we can apply READY with higher accuracy and more directly. The idea is to derive the cycle scenario's from logic in the timing model when those scenarios actually occur, simplifying the decoding for each separate event and keeping that more on the clock boundaries. From the number of clocks used by the FPGA in a functional design to base READY on, we can create a highly accurate simplified timing model that suits the 286 processor. It then becomes the challenge to try to obtain the same timing in a synchronous design in the severely register restricted system controller CPLD. I will create a complete cycle timing diagram when I have the means to get this done accurately.

In the mean time I may get tempted to try more design variations on the REV3D system controller. Maybe if I can find a 80MHz oscillator here somewhere I could try using that to get READY functional exactly on a derived clock boundary. If that helps to simplify READY maybe I can use the freed up logic capacity to use some shift register type design. Alternatively I have also considered using some kind of counter which runs at 286_CLK speed and decode the outputs which are then used for system control timing. I just need to get the most minimal design without dynamic clock needed so I can have more registers and logic available. Maybe that can be done based on 32MHz 286_CLK using a 64MHz oscillator, which I do have.

Recently I also found out that the REV3D system is even able to run to some degree completely on 44.8/22.4 MHz without a dynamic clock. The only point where we run into trouble is the VGA cycles, though possibly these could also be modified using wait states instead of dynamic clock. This is also a challenging idea for me to further sort out in testing the REV3D system in the future. The REV3D system may have unexplored future improvements available in the future which I will share on the GitHub project if and when successfully implemented. The reference VGA controller for the REV3D is a Cirrus Logic, where my goal is to attempt to make do with the more affordable 5422 controller based cards. Ideal sound card and a big recommendation is the Trust Sound Expert Deluxe 16 plus. This sound card has the added effect on the system to allow IDE port detection to run in a few ms rather than needing to time out in the XT-IDE BIOS. I will examine this effect more in the future, possibly it's related to the optional CDROM ports on the card.

I have given the FPGA test PCB a lot more thought and decided it may be better to design a smaller sized ATX mainboard for testing the QFP FPGA in a reduced REV4 version design. Something similar in size to the TOPCAT test mainboard. This will allow more space and a more solid power connection to provide 3.3V to the FPGA. We can position everything more ideally on the board when having a larger square area available around the FPGA, etc., which I am liking a lot more than a card design. We can populate the slot connectors as required by the testing. So I will most likely pursue the full mainboard design for testing, which I will update on a GitHub project.

I will design a separate new ISA slot card for IDE, floppy drive and UART which I can use universally for all testing purposes, including with period mainboards. The card will probably be based on a 208 pin 5V CPLD which will do decoding and provides the super stable IDE interface of the REV3D for the test system, and additionally we will have a POST display and other diagnostic LEDs on the card which can provide more detailed insight to what's happening on some of the ISA slot signals. I still have one desoldered 208 pin CPLD which I will straighten out and see whether it can serve on this combined IO card.

Let's see how soldering goes on a ENIG plated board when using the more dense 208 pin QFP ICs, compared to HASL SMD pads as we have previously done on the REV3D, hopefully better which I will share here in the thread.

 

[rodney]

Other plans I have is to design a memory subsystem card for the 5170 and similar cloned mainboard models like the ARC, NCR and Copam etc. The card will contain the entire memory bus including a 8 bit mode 1 megabit ROM to support BIOS and option ROM. After designing and testing this card, I will detail the simplest least invasive way to modify the 5170 mainboard to support the new memory subsystem. Adding a complete memory subsystem replacement will make the 5170 much more enhanced system for those who just want to replace the DRAM system memory in a convenient and efficient way using a very minimal amount of RAM chips which don't need the refresh and vulnerable parity checking logic mechanisms etc., improving the overall system reliability. I will then also test and verify the clock speed limits of the 5170 mainboard further if I can find a good way to connect a different 286 on the board.

Kind regards,

Rodney

 

[rodney]

I'm working on the REV4 first test mainboard based on the QFP FPGA, and working out the pin distribution another time after knowing the ideal placements.

In the process I realized that on the slots we have the A20 line from the 286, however this needs to be gated for backward compatibility reasons.

However, in our system we include all the system RAM on the mainboard where we internally can apply the GATE_A20 function on the memory decoders.
So I decided to do some tests with the direct A20 line from the 286 on the LA20 line of the slots.
In principle this should not pose any issues in our pin reduced FPGA design since the lines are only used by VGA controller chips on the slots which decode whether the current cycle address is within the VGA RAM windows.

So doing some tests indeed the system initialized without any errors reported by the MR BIOS POST checks, and additionally the VGA controller functioned correctly without any glitches.
I have found that the Cirrus Logic VGA controllers use the LA lines on the slot to decode the 286 cycles so there the critical thing for this purpose is that the 286 signal states arrive as fast as possible on the LA lines, and the fastest way is wiring them directly, or at least, with minimal logic and especially never latching the address lines from the 286 first which will change the timing when they are updated on the slot. Arriving too late, this will result in different kinds of DOS text mode glitching, most notably the first character column being affected on each row. So the Cirrus Logic design, at least in the 5422, depends on pipeline mode timing of the 286 address lines in order to make the VGA RAM cycle timing work correctly. Maybe the card likes to skip cycles early on in order to be able to do more internal graphics memory processing instead, that would make sense to make better use of the time available.

In all my development on the REV3D (hundreds of design variations), I have found one small hickup up to now. In DOS, there is no problem or issue at all, on the contrary, it's rock solid stable so far, however in windows 3.1 the stability has not been completely 100%. Basically I can play some windows card games and puzzle games like mahjongg for hours, but occasionally windows could freeze or exited and threw a stack dump in DOS. Usually a power cycle helped best to resolve the matter and make a fresh start. Notably if I left windows 3.1 running for a few hours without doing anything, I found it frozen eventually. Windows 3.1 is really a more critical test of a PC system to know whether all cycles are 100% right. Letting it run idle is also another level of test which apparently was more difficult to pass, so far.

Well, I went over all the logic of the system controller to see if there is some room for improvement. Since the timing is on the edge at 22.4 MHz, any shift in either direction will soon be noticeable, which could be useful to have this situation sometimes because it can be telling about knowing the stability effect of any change in the design. Besides the extremely difficult matter of the READY timing, there is always the chance that the compilation may get skewed significantly off the perfect spot in the timing.

When I went over the system control, I came across the logic which applies the DEN function, the data bus enable mechanism. Basically I attempted to follow the descriptions of the Intel 82288 controller datasheet regarding DEN. However there the mileage varied.

In the 5170 PC/AT design, the CEN input of the 82288 controller is connected with the CNTL_OFF_n net. Basically the CNTL_OFF_n mechanism goes low briefly during byte conversion which interrupts the command in progress, and also puts the DEN output into disabled (low) state. This mechanism turns the data bus off during the CNTL_OFF period.
I had experimented with this mechanism in the REV1 system, but frankly got some issues when I did a hard implementation of this CNTL_OFF function on the data bus enable logic.
So I changed the circuit a little and the issues stopped, so at the time I moved on and continued with creating all the other system control signals in order to get the entire system control replaced.
Later I had a look at the circuit a few times and simplified it, but tests appeared not to go well, likely due to the sensitive timing of enabling and disabling the data bus exactly in the right instances.
The documentation is also detailed on how that could cause issues particularly in read operations if the DEN timing is off.

However since the REV3D is a different design in many regards, I decided to have another more detailed look at the DEN logic just to see how this would influence overall stability.
The idea was to try to simplify the logic and not disable the DEN signal if not needed, particularly during continuous activity by the 286 and during the converted cycles.

In the 5162 design things are different, IBM made an update in the DEN logic, where they basically have overridden the normal function of the 82288 to allow the data bus to remain enabled during the entire byte converted cycle. They used the ARDYEN_n signal for this purpose. When there is a cycle decoded to be in need of conversion, the ARDYEN_n signal is raised high, which disables all READY qualification, and in the 5162, IBM made a change and used the raised ARDYEN_n signal to also keep the data bus constantly enabled during the converted cycle period, also when CNTL_OFF_n is active which in the 5170 disables the data bus. This modification in the 5162 effectively bridges the period of the 82288 DEN output going offline briefly during the converted cycle. No doubt this was done for general improvement and stability reasons, it's not directly related to the zero wait state timing of the 5162.
So since the REV1 I also kept this signal involved in enabling the data bus, but I also left the CNTL_OFF logic in place on the DEN circuits. Even though it didn't do anything on the DEN output, I noticed today that quartus didn't minimize these gates away in the RTL diagram either.

So today I have done some tests and indeed I was able to completely remove CNTL_OFF from the DEN logic, I could skip another gate in the path and the ARDYEN_n signal continues to perform the bridge function to keep the data bus enabled during conversion. Ultimately, I performed some tests on this new logic version and this has greatly improved the overall stability in windows 3.1 at 22.4 MHz clock speed.
The system has been running idle in windows 3.1 for hours and no more freezing, which is a definite improvement in overall stability, I am pretty pleased with this outcome.

I have seen the 5162 to be noted as a weird design choice by IBM, especially because of putting it in a XT case while being an AT design, however the overlooked aspect of the 5162 design there is that it is basically a continued development step in the PC/AT logic where the designers have attempted to improve the 5170 logic further. So historically, the 5162 is an important design to take note of. I still hope that some day I can have the chance to get a 5162 mainboard and do tests on this system. Even a defective specimen with the programmable chips intact, particularly the 20L8 IC, U27. This chip likely holds some cool design modifications which are so far still unknown and published nowhere. Especially there should be some modified wait state decoding present in the chip. Just to know what IBM actually programmed in this regard would be pretty cool to know more about, at least for me it would and I think there are many people who would be interested. If I ever find the chance to examine the 5162 mainboard, I will share the detailed info here in the thread. Maybe a damaged or corroded 5162 mainboard could ever be found for a reasonable price. That is also how I got my 5170 mainboard which looked a little corroded and had a very reasonable price on ebay. The mainboard also led to all the reverse engineered findings in the REV1 design, without that board it would not have been possible to determine the complete 5170 logic. The other examples of discrete chipset boards so far all turned out to be less stable and reliable than the 5170 specimen so these did not inspire me to dive into their designs as deeply as I have done with the 5170.

I will conclude the stability tests now by changing the slot LA20 line to an "ungated" version of the 286 line for further testing. I was distracted by the occasional freeze in windows 3.1 so far however this appears to have been more related to the critical DEN timing since after changing that, those issues disappeared. After confirming that the limited pin count design can make do without a separate gated A20 line on the slot, I can proceed with the design to simply use the 286 lines directly. During DMA, the 286 is in hold and the FPGA can generate the DMA page mapper output states on the LA lines instead, and during possible ISA bus master activity, the LA lines are also taken as inputs and control the memory chip select decoders. So it looks like we can keep using an additional pin for other functions like IRQ support after all. The reduced pin count FPGA test mainboard design is proceeding nicely and I hope to have this finished soon so we can order the board from JLCPCB.

Kind regards,

Rodney

 

[rodney]

I have worked more on the mainboard layout for the REV4 QFP FPGA based system.

So this will be a 4 layer design based on the 208 pin QFP Cyclone II. By only featuring a system bus and driving a few of the slot signals directly from the 286 I actually found a way to feature a complete PC/AT system with a single smaller type of FPGA chip.

Using 6 SRAMs provides us with a maximum of 6MB RAM. The system ROM will be a 1 megabit chip in 8 bit mode.
I found in the REV3D that using the system ROM in 8 bit mode with the 286 allows much higher clock speeds without using shadow copy.
This is thanks to the byte conversion and cycle control, though the latter may not even be necessary.
Anyway, in the FPGA stage, which has ample fast logic compared to CPLDs, I will do a lot more development.

Of course, I will first need to get through the debugging stage, so this REV4 design to me is also a stepping stone which will give me a much better impression how we can proceed with the larger 672 pin BGA FPGA in the design after that. It's the same as when I first started with CPLDs, after working with those in REV1, I got a better vision of what I wanted a next stage design to look like.

Same goes here, this first reduced REV4 mainboard stage can be very helpful to completely rework the entire system control. Apparently the logic in this smaller FPGA can even suffice to replace the core AT controllers and design a new version of 286 system control. Which frankly surprised me a little. So after realizing this. I decided to attempt to design a fully operational system based on this small FPGA.

In this system I have also made the decision to include a little more on the mainboard.
The design will feature a single 100 pin CPLD to create an IDE port, a POST LED display, do some IO decoding and clock division for the system timer.
The POST LED display is easy to monitor and will give me a much better impression of the level of functionality of the FPGA design while debugging the system.

So I am building up the layout to include everything I wanted to add. I included the Floppy controller and UART in PLCC packages to save PCB area.
Also I found that the PLCC Floppy controller is actually better because it also includes reading the /DC pin from the floppy drive bus which the DIP version doesn't do.

I decided to also use a bus switch to connect the RP2040 USB to serial mouse converter by Limeprogramming with the UART in 5V logic levels to 3.3V.
I could have powered the UART with 3.3V which I briefly considered but that would need a separate data bus etc to be routed to the chip, so it's much better to just use a bus switch instead. The CPLD also does some signal buffering for IO commands and address inputs for the FDC, IDE and UART, same as the REV3D.

So I took a lot of time to work on the design, and in the mean time I noticed that mouser ran out of stock the NOR flash chips.
So I will select a different one instead.

The design is still under heavy development while building up the layout, and certain things are going to be moved around in the process, however in attachment a picture to give you an early impression of what the final design is going to look like. Most areas and design aspects are now worked out so the remaining work is just fully sorting the layout out. The FPGA, SRAMs and CPU are pretty fixed now on the board.

I am still considering what type of board I will order from JLCPCB, I may still decide for a normal HASL board after all since this should work out well, I will check the price difference and then decide on what to order. In the order I will also get a few other boards including a few more SRAM module boards for testing the TOPCAT chipset with SRAMs using a small CPLD. If that works out well, I may design future SCAMP etc boards also using SRAM chips soldered directly on the mainboard. It is my theory at the moment that zero wait states should also be possible with the same address timing when translating the multiplexed address back to a full address bus. It's not the fact that they are using DRAMs with RAS/CAS but rather the more optimal timing of establishing the memory address updates. And the decoding is already done inside the chipset so this can be used in the same way. Anyway, I will have the chance to experiment with this idea which will tell me a lot more about these chipsets and the whole concept of DRAM timing in these 286 chipset systems.

I will work more to finalize the REV4 QFP board design and then I will probably also design a custom slot card to replace the 5170 memory subsystem so I can combine this in a single order. I want to do a lot more testing to establish the clock limits of the original 5170 board when replacing the memory subsystem and memory bus using a slot card design. I will feature a pin header on the memory card to be able to test out different signal connections and decoding logic to see how these impact the clock speed limits.

Kind regards,

Rodney

 

[Quagmire]

I have worked more on the mainboard layout for the REV4 QFP FPGA based system.

So this will be a 4 layer design based on the 208 pin QFP Cyclone II. By only featuring a system bus and driving a few of the slot signals directly from the 286 I actually found a way to feature a complete PC/AT system with a single smaller type of FPGA chip.

Using 6 SRAMs provides us with a maximum of 6MB RAM. The system ROM will be a 1 megabit chip in 8 bit mode.
I found in the REV3D that using the system ROM in 8 bit mode with the 286 allows much higher clock speeds without using shadow copy.
This is thanks to the byte conversion and cycle control, though the latter may not even be necessary.
Anyway, in the FPGA stage, which has ample fast logic compared to CPLDs, I will do a lot more development.

Of course, I will first need to get through the debugging stage, so this REV4 design to me is also a stepping stone which will give me a much better impression how we can proceed with the larger 672 pin BGA FPGA in the design after that. It's the same as when I first started with CPLDs, after working with those in REV1, I got a better vision of what I wanted a next stage design to look like.

Same goes here, this first reduced REV4 mainboard stage can be very helpful to completely rework the entire system control. Apparently the logic in this smaller FPGA can even suffice to replace the core AT controllers and design a new version of 286 system control. Which frankly surprised me a little. So after realizing this. I decided to attempt to design a fully operational system based on this small FPGA.

In this system I have also made the decision to include a little more on the mainboard.
The design will feature a single 100 pin CPLD to create an IDE port, a POST LED display, do some IO decoding and clock division for the system timer.
The POST LED display is easy to monitor and will give me a much better impression of the level of functionality of the FPGA design while debugging the system.

So I am building up the layout to include everything I wanted to add. I included the Floppy controller and UART in PLCC packages to save PCB area.
Also I found that the PLCC Floppy controller is actually better because it also includes reading the /DC pin from the floppy drive bus which the DIP version doesn't do.

I decided to also use a bus switch to connect the RP2040 USB to serial mouse converter by Limeprogramming with the UART in 5V logic levels to 3.3V.
I could have powered the UART with 3.3V which I briefly considered but that would need a separate data bus etc to be routed to the chip, so it's much better to just use a bus switch instead. The CPLD also does some signal buffering for IO commands and address inputs for the FDC, IDE and UART, same as the REV3D.

So I took a lot of time to work on the design, and in the mean time I noticed that mouser ran out of stock the NOR flash chips.
So I will select a different one instead.

The design is still under heavy development while building up the layout, and certain things are going to be moved around in the process, however in attachment a picture to give you an early impression of what the final design is going to look like. Most areas and design aspects are now worked out so the remaining work is just fully sorting the layout out. The FPGA, SRAMs and CPU are pretty fixed now on the board.

I am still considering what type of board I will order from JLCPCB, I may still decide for a normal HASL board after all since this should work out well, I will check the price difference and then decide on what to order. In the order I will also get a few other boards including a few more SRAM module boards for testing the TOPCAT chipset with SRAMs using a small CPLD. If that works out well, I may design future SCAMP etc boards also using SRAM chips soldered directly on the mainboard. It is my theory at the moment that zero wait states should also be possible with the same address timing when translating the multiplexed address back to a full address bus. It's not the fact that they are using DRAMs with RAS/CAS but rather the more optimal timing of establishing the memory address updates. And the decoding is already done inside the chipset so this can be used in the same way. Anyway, I will have the chance to experiment with this idea which will tell me a lot more about these chipsets and the whole concept of DRAM timing in these 286 chipset systems.

I will work more to finalize the REV4 QFP board design and then I will probably also design a custom slot card to replace the 5170 memory subsystem so I can combine this in a single order. I want to do a lot more testing to establish the clock limits of the original 5170 board when replacing the memory subsystem and memory bus using a slot card design. I will feature a pin header on the memory card to be able to test out different signal connections and decoding logic to see how these impact the clock speed limits.

Kind regards,

Rodney

Hi Rodney,

It's kind of late on the game to be asking about this, but did you ever give any consideration to employing at least 1 PCI slot? Would be great for an early video card.

Great work!

Tom

 

[rodney]

Hi Rodney,

It's kind of late on the game to be asking about this, but did you ever give any consideration to employing at least 1 PCI slot? Would be great for an early video card.

Great work!

Tom

Hi Tom,

It's great to hear from you, thanks for your message!

I am definitely thinking about PCI in the future.

In this first QFP stage we will initially use a smaller 208 pin FPGA with less logic capacity, as a first very important step for getting started with FPGA technology.
So this smaller first chip doesn't have the necessary pins for adding a PCI slot and is only able to support a reduced pin count and simplified version of the 16 bit PC/AT system bus on the ISA slot connectors.
Hopefully this simplified bus system after further development will be able to function at much higher clock speeds and efficiency than we have seen so far with the CPLD systems.

After we are finished with debugging and developing the smaller FPGA chip in this first stage, we will move on to the large 672 pin FPGA chip, which has a lot more pins available to do lots of experimentation and development. The strong point of FPGA technology is that we can create new custom hardware to enhance the system further.

An open source PCI controller FPGA project does exist on GitHub, so I will certainly look into trying to use this project in the future to start working on adapting a suitable PCI VGA card to work with a 286. We can choose an "ideal" candidate PCI card which is not too expensive to obtain and offers good performance and features.

One of the things that will need to happen to enable such a card to function is that the VGA BIOS ROM will need to be decompiled and partially modified to run with 286 CPU instructions in order to be able to initialize the VGA controller chip and to do data transfers into VGA RAM with the highest possible speeds. Possibly after decompiling the ROM code, this can provide more insight into whether it will be more or less difficult to convert the existing ROM code.

It would be cool to eventually be able to use different PCI slot cards in the system, however converting the BIOS ROMs will be a time consuming work.
So I think choosing some ideal example PCI VGA card (ATI, S3, etc) to work on will result in the most advantage to be potentially gained from doing that ROM adaptation work.

There also exists the ao486 project which includes a VGA controller written in HDL code, possibly this controller will also turn out to be very interesting to try to adapt it to our system.
Basically we need fast system RAM to VGA RAM transfers to be possible and for the VGA BIOS to be rewritten to use 286 compatible instructions.

So on the larger FPGA chip mainboard stage, we will include a VGA connector and also a PCI test slot connector, so we can be able to work on both these ideas and a lot more.
When creating a PCI slot on the board, we also can use the connections for testing other ideas by manufacturing different boards that are able to be plugged into the PCI slot connector.
If a certain design is a great addition to the system, we can feature it on the next mainboard stages as a permanent addition.

So initially it will be really important to get the smaller FPGA system debugged and developed further.
That will also provide the basic necessary integrated system components such as the core AT controllers which will be used in later stages as well.
For example the ISA slot, keyboard controller, RTC, CMOS RAM, system timer, etc, are also used in 486 systems so these elements in the design will continue to be very useful in future designs.

I will also look into other things such as experimenting with SATA drives and testing with newer types of RAM chips technology, and maybe we can find some CPU cache controller example projects.
So we may face some ROM code challenges in the process as well.
I noticed that a PC sound card featured in FPGA HDL code does consume a large amount of logic capacity, so I may possibly also look into other solutions for producing sound blaster compatible audio.
Another interesting idea would be to feature a floppy drive controller and UART in the FPGA as well so we can eliminate these components in the future.

Anyway, as with all the previous designs, it's a step by step process to work through, I hope that the first FPGA stage, besides offering us the higher integration level already, can also help us achieve much faster clock speeds and higher efficiency with the 286 CPU.

I will also experiment with different timing and cycle decoding for the system RAM, which may give us zero wait state speeds if that works out to establish the address bus sooner in the 286 status cycle.
For this purpose, I have included the LA23 pin on the FPGA which I will experiment with to attempt to prevent decodes to happen while the address bits are using different update timing during fast system RAM cycles. This same LA23 pin is also connected to the CPLD on the mainboard which will allow us to experiment with disabling the IO decodes during zero wait state and EMS RAM cycles as well.
When working with the larger FPGA later on, we also can introduce other features like a quiet ISA slot which only becomes active if something on the slot is being addressed.
And we can do more elaborate work on the memory address bus timing as well.

Thanks for the message Tom!

Kind regards,

Rodney

 

[kevju]

use a bus switch to connect the RP2040 USB to serial mouse converter by Limeprogramming with the UART in 5V logic levels to 3.3V

The RP2350 is 5V tolerant.

 

[acgs]

Using 6 SRAMs provides us with a maximum of 6MB RAM. The system ROM will be a 1 megabit chip in 8 bit mode.

What is the reason you would want to limit the systems to only 6MB? Towards the end of the 286's run, systems were being built capable of the 286's maximum accessible limit of 16MB. This allows the computer greater flexibility when running OS/2 or Desqview under DOS as examples. While there might be only a few people interested in a "fully powered 286", wouldn't it be a good idea to allow for it in the design?

 

[sqpat]

It is really difficult to use more than 4 MB on a 286, unless you are running a multiuser environment/server or something. I don't think desqview or os/2 is going to do it.

Rodney can explain better than I can for sure but additional chips means more components, more and longer traces, bigger boards and more cost, and probably complicates the memory controller and takes up more pins. The biggest benefit to more ram chips would be imo if interleaving could be implemented.

 

[rasz_pl]

I see you are already on version 3 and plowing into v4 since the last time I saw this thread. Nice!
Im sad you are still only posting gerbers Cant really see whats going on with the PCB properly. Takes a lot of energy and work to reverse it back into pcb. When I looked at your V1 there were numerous routing problems, I cant remember where I commented on it hmm .. ah yes github https://github.com/rodneyknaap/atx-286at-v1-mainboard/issues/1

V3 still looks very questionable
- routing signals in ground/power layers, this cuts the ground/reference layers and destroys signal integrity. Whole ISA subsystem is routed this way, same for RAM, around U5 Address Bus Driver and CPU itself.
- L2 being power layer while most critical signals are on L1 means reference is all the way thru ~1.5mm of prepreg.
- VIAs bunched up in neat rows cuts ground plane.
- 4 layer PCB means L1 L4 ground pours are pretty useless. Instead of helping with anything they make you cram tracks closer together.
- 10mil traces with 10mil clearance (8 on diagonals) is really bad for signal integrity. You should always aim for at least 2x track width between tracks when running in parallel. Try 6 mil tracks while keeping 12mil distance to nearby tracks. You can go smaller clearance on copper pours, like for example 8 mils - this will allow you to route two tracks between ISA/THT pins. Some motherboard vendors went down to crazy 3 tracks between ISA pins (Asus around 1994) using really slim ISA Slot pins and 5 mil tracks.
- useless vias and flipping thru layers for no reason. For example 14MHz clock starts on L1, goes to L4 for 2 cm and back to L1.
- 14MHz clock then cuts thru whole PCB between ISA slots without proper ground reference. Nearest ground 20mils away while L2 is only 1.5mil down with tons of sensitive data/address lines going across. 16MHz clock also cuts thru whole PCB under ISA slot without proper ground reference.

My tips to see where you have most obvious problems:
1. In Kicad right click on Appearance tab and "Hide all layers but" L2, there should be _no cuts_, no via clearance holes merging into black lines. Now do same for L3, same rules.
2. Board Setup/Design Rules/Net Classes setup at least "data" and "power" classes. Add data/address busses to data class, give it 6 mil track width and 8mil clearance. Now you should be able to route two tracks between ISA pins. When done bump clearance to 12mils, run DRC, fix clearance errors that arent caused by nearby Pins.

V4 great idea about integrating peripherals into FPGA.

Maybe you have seen this already, here https://maniek86.xyz/projects/m8sbc_486.php is 486 FPGA project by maniek86 (Piotr Grzesik). His prototype PCB worked on first try despite many problems. https://github.com/maniekx86/M8SBC-486/tree/main/pcb, here for comparison my somewhat fixed attempt https://github.com/raszpl/M8SBC-486/tree/main/pcb halved via and track lengths on most critical signals, fixed ground issues. Load both up in Kicad side by side and compare routing. Im also planning to incorporate PIC, PIT and limited DMA into FPGA for this project + pico on board for loading FPGA firmware, picoGUS and maybe even as a clock source for FPGA. I/O is VERY tight on FPGA with only 86 available to begin with.

 

[rodney]

means more components, more and longer traces, bigger boards and more cost, and probably complicates the memory controller and takes up more pins. The biggest benefit to more ram chips would be imo if interleaving could be implemented.

Hi Patrick,

Absolutely all of these are very valid considerations, thanks for mentioning this.

Indeed, some form of interleaving is still something I am thinking about frequently so this may become the answer or part of it.
I suppose some predictive mechanism for block transfers other block type of CPU operations like clearing sections of RAM etc could be used and if that doesn't hit on the next cycle, the cycle could be adjusted to be a non interleaved slower type. Maybe something like that. With the larger FPGA we can play with a lot more cool ideas in the future.
Even possibly some form of caching controller to speed up the memory access when we are using even faster clock speeds.
Anyway, I am not committing to one or the other before more careful consideration, testing and experimentation.
Generally and ideally I would prefer to make all RAM cycles match the native CPU speeds.

acgs, I have created the QFP FPGA design as a test board, I have explained the details leading up to that particular board a few posts back.
I will keep your post in mind for the full FPGA mainboard design. Maybe I can add 16MB of SRAM which can then be assigned as XMS or EMS based on user preference.
I mean, if there are people following my project and maybe they have some ideas in mind what they plan to do, please do reach out here and let me know about your ideas.
I can always keep those in mind and consider them in design choices, on the condition that the design aspect doesn't otherwise interfere with the other project goals such as system speed as Patrick also mentioned is a big concern for me.

The project is always more fluid between iterations so I may end up using other more modern types of RAM as well if these can also support fast access.
If I can find a suitable type of RAM and the logic to drive and refresh it transparently, that could be a good candidate to become the next solution.
So we will have the PCI slot connector for testing in the large FPGA board which can then take all sorts of experimental stuff too, it not necessarily needs to be a PCI controlled slot and we will not make the design dependent on the PCI slot connector so we can have the flexibility to play around with the PC/AT system in various ways.

The QFP package has a certain number of pins, and is able to accommodate only a certain number of chip select outputs.
So it can support six separate chip selects, which the design is using. It is already a fortunate fact that the QFP FPGA may be able to support powering a full PC/AT system.
Until I have fully debugged the design I will reserve this fact/idea. Hopefully for the project this design can actually work out well, which can move us forward with more certainty.
After all that was the reason leading up to making this test design first now when we were considering the configuration documentation to be somewhat confusing.

Anyway, I have put in the necessary heavy lifting in this project, and maybe if I run into difficulty I will ask for some help if someone with a mindful and supportive mindset really wants to help me with the project.
I will experiment more with HDL languages in the future of course so there is ample work and planning ahead for me.

As I have commented before, I will design actual system control for a real 486(DX etc) chip in the future, so not a HDL representation of the CPU, for me that is not the goal.
Everyone can make what they like which is fine, however I will keep on the straight path of my vision for this project, and I will definitely accommodate wishes which are expressed, as far as I am able to and it can suit the concept of the project.

Basically what I want to achieve is to design system control which is capable to form a complete system in a similar way as was done in the time period.
If anyone knows of some kind of decapping projects going on to be able to document the chipsets, I would love to hear about those too.
In the GitHub I want to mention again the very cool conversation with costastep who shared some very interesting stuff he has thought about.
I am extremely interested in this type of work as well so anyone doing this, feel free to reach out!

just an idea to consider · Issue #1 · rodneyknaap/ATX-286_PCAT-REV4-FPGA_mainboard

hi Rodney, my understanding from your project description is that your current goal is: "to approximate the original function of the controller chips" but have you considered making exact "copies" ...

github.com

Let me repeat, the primary concern here in my project is preservation of historic designs and technology.
I already have a working CPLD design in revision 3 which functions perfectly as intended by the design.

We are working with FPGAs now with the purpose to further enhance the PC/AT system and allow it to benefit from more technology.
Like for the purpose of adding cool stuff like PCI and more advanced cycle and memory control.
That is really future stuff in the planning well worth our consideration and time/effort.
Achieving new types of design that only FPGAs can support.
And I will try my best to keep preserving as much of the 5170 technology as possible in ways that still make sense further along.

Thanks to all the readers and followers of the project for all your positive interest!

kind regards,

Rodney