Starting with my first SBC Project, Plans and Confusions
Re: Starting with my first SBC Project, Plans and Confusions
Ok here is the second revision of the board, well atleast the Schematic of it.
Important changes:
Fixed the Reset button.
Added a Resistor array to pull down the unused inputs of the 541 (U3) (also added a pin header).
Added a decoupling capacitor to the 3.3V rail of the FT240X.
Connected all unused inputs on the GALs with GND (there was only 1 usused input on U2, for the rest of the IO Pins i can set them to output in WinCUPL).
Added a power switch, when off it connects the board's Vcc lines to GND (through a resistor to avoid any kind of shorts).
am I missing anything?
Important changes:
Fixed the Reset button.
Added a Resistor array to pull down the unused inputs of the 541 (U3) (also added a pin header).
Added a decoupling capacitor to the 3.3V rail of the FT240X.
Connected all unused inputs on the GALs with GND (there was only 1 usused input on U2, for the rest of the IO Pins i can set them to output in WinCUPL).
Added a power switch, when off it connects the board's Vcc lines to GND (through a resistor to avoid any kind of shorts).
am I missing anything?
Re: Starting with my first SBC Project, Plans and Confusions
Here's another idea (if I am correct) about the '541 enable, since we were worried about that being slow.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
Curt J. Sampson - github.com/0cjs
- BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Starting with my first SBC Project, Plans and Confusions
Proxy wrote:
Ok here is the second revision of the board, well at least the Schematic of it.
x86? We ain't got no x86. We don't NEED no stinking x86!
- BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Starting with my first SBC Project, Plans and Confusions
cjs wrote:
Here's another idea (if I am correct) about the '541 enable, since we were worried about that being slow.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
Ultimately, the solution will be in using a CPLD for the glue logic. An ATF1504AS has much more in the way of logic resources than any GAL, plus has 32 uncommitted I/O pins in a PLCC44 package. Also, the entire ATF15xx family can be programmed in-circuit via JTAG, which makes logic changes a quick and easy process. An ATF1504AS will easily handle what this circuit is doing, plus more.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Starting with my first SBC Project, Plans and Confusions
cjs wrote:
Here's another idea (if I am correct) about the '541 enable, since we were worried about that being slow.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.
BigDumbDinosaur wrote:
I think that would work, although it could be classified as a kludge. 
Ultimately, the solution will be in using a CPLD for the glue logic. An ATF1504AS has much more in the way of logic resources than any GAL, plus has 32 uncommitted I/O pins in a PLCC44 package. Also, the entire ATF15xx family can be programmed in-circuit via JTAG, which makes logic changes a quick and easy process. An ATF1504AS will easily handle what this circuit is doing, plus more.
Ultimately, the solution will be in using a CPLD for the glue logic. An ATF1504AS has much more in the way of logic resources than any GAL, plus has 32 uncommitted I/O pins in a PLCC44 package. Also, the entire ATF15xx family can be programmed in-circuit via JTAG, which makes logic changes a quick and easy process. An ATF1504AS will easily handle what this circuit is doing, plus more.
plus i wasn't sure if i should directly replace the GALs with the ATF1504 because i never worked with it before.
but i guess you guys have, so as long as i show the schematic of how i want to wire it up on the board you could tell me if there is something wrong with it.
also i wanted to order a breakout board for the ATF1504 so i could experiment with it on it's own. I know i could've made it a lot slimer but i wanted to see what each pin does.
I'm also not 100% sure on the pinout of the JTAG connector. i assume this is correct:
BigDumbDinosaur wrote:
Proxy wrote:
Ok here is the second revision of the board, well at least the Schematic of it.
Re: Starting with my first SBC Project, Plans and Confusions
It's a fine idea to implement your glue logic with a CPLD, but it's also a fine idea to use GALs. Don't let one opinion give you the idea that there's only way to do things, or that there's a consensus among members as to which approach to pick.
Re: Starting with my first SBC Project, Plans and Confusions
BigEd wrote:
It's a fine idea to implement your glue logic with a CPLD, but it's also a fine idea to use GALs. Don't let one opinion give you the idea that there's only way to do things, or that there's a consensus among members as to which approach to pick.
plus one of my ultimate goals is to use standalone FPGAs in projects, so starting with CPLDs is a great idea.
but this again makes me unsure if i should replace the GALs in the next revision
or keep the GALs for now, order the breakout board so i can safely experiment with the CPLD so i can properly implement it in the 3rd revision.
Re: Starting with my first SBC Project, Plans and Confusions
BigDumbDinosaur wrote:
cjs wrote:
Here's another idea (if I am correct) about the '541 enable, since we were worried about that being slow.
(Yes, I am a software guy. Even though I now, unlike twenty years ago, understand why a lot of hardware I programmed was the way it was, I still have difficulty forgiving hardware designers for what they put me through. And yes, I'm looking at you, Woz. :-))
Curt J. Sampson - github.com/0cjs
- BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Starting with my first SBC Project, Plans and Confusions
BigEd wrote:
It's a fine idea to implement your glue logic with a CPLD, but it's also a fine idea to use GALs. Don't let one opinion give you the idea that there's only way to do things, or that there's a consensus among members as to which approach to pick.
That said, there is a potential problem with the way he's doing things right now, in that there can be a race between GALs due to differences in internal prop time. GAL prop times are specified on worst-case pin-to-pin values. No minimum is specified and that's where one can run into trouble with two GALs making logic decisions "in parallel." While I'm not saying that is what is happening in his system, the possibility does exist.
Back in the days (around 1991) when I was writing code for a 65C02 terminal server that used two GALs, every so often the unit given to me for testing would go whack-a-doodle for no apparent reason. I spent a lot of time poring over my code trying to find the error that surely had to be causing all the trouble.
The cause turned out to be a difference in GAL speeds resulting in some logic going "backwards." Ø2 was 8 MHz in this unit, which was clipping right along for a 65C02-based system in those days. Timing was somewhat touchy. When the board was hooked up to a logic analyzer it was seen that one of the GALs was slowing down more than the other as its temperature rose (back then, GALS were more power-hungry than now). The board had to be redesigned because of this behavior and the new design ended up with a small CPLD so all logic could be encapsulated in a single device.
x86? We ain't got no x86. We don't NEED no stinking x86!
- BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Starting with my first SBC Project, Plans and Confusions
Proxy wrote:
well i would like to start with the ATF1504, but i need a programmer...
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Starting with my first SBC Project, Plans and Confusions
BigDumbDinosaur wrote:
BigEd wrote:
It's a fine idea to implement your glue logic with a CPLD, but it's also a fine idea to use GALs. Don't let one opinion give you the idea that there's only way to do things, or that there's a consensus among members as to which approach to pick.
That said, there is a potential problem with the way he's doing things right now, in that there can be a race between GALs due to differences in internal prop time. GAL prop times are specified on worst-case pin-to-pin values. No minimum is specified and that's where one can run into trouble with two GALs making logic decisions "in parallel." While I'm not saying that is what is happening in his system, the possibility does exist.
Back in the days (around 1991) when I was writing code for a 65C02 terminal server that used two GALs, every so often the unit given to me for testing would go whack-a-doodle for no apparent reason. I spent a lot of time poring over my code trying to find the error that surely had to be causing all the trouble.
The cause turned out to be a difference in GAL speeds resulting in some logic going "backwards." Ø2 was 8 MHz in this unit, which was clipping right along for a 65C02-based system in those days. Timing was somewhat touchy. When the board was hooked up to a logic analyzer it was seen that one of the GALs was slowing down more than the other as its temperature rose (back then, GALS were more power-hungry than now). The board had to be redesigned because of this behavior and the new design ended up with a small CPLD so all logic could be encapsulated in a single device.
BigDumbDinosaur wrote:
Proxy wrote:
well i would like to start with the ATF1504, but i need a programmer...
i found the same on Mouser as well so i can order it with my other components. problem is that they are out of stock, and it will take a few months for new ones to arrive (acording to the site).
ok now a few questions about somne of the pins on the ATF1504.
I know the use of the 4 JTAG pins, and will avoid using them for IO stuff. (I assume my JTAG connector is correct as i cannot find a pinout of the Atmel Programmer's connector online)
I have an idea what some other pins do, like the GCLR (Global Clear) which probably resets all internal flip flops.
and the GCLK (Global Clock) pins, which are likely used for the clock input of the flipflops, why there are 3 of them though, no idea.
but now the confusing pins:
OE (Output enable), there are 2 of these and one of them is on the same pin as a Global clock, no idea what they are for.
PD (???), there are also 2 of these, again no idea what they might be for.
Re: Starting with my first SBC Project, Plans and Confusions
BigDumbDinosaur wrote:
I'm not opining there is only one way.
Re: Starting with my first SBC Project, Plans and Confusions
The multiple GCLKs, OE and so on will be configurable in their use, based on what you program into the device. You'll need to look at the internal structure of the device to figure out what it's capable of and how those signals can be used.
Re: Starting with my first SBC Project, Plans and Confusions
Chromatix wrote:
The multiple GCLKs, OE and so on will be configurable in their use, based on what you program into the device. You'll need to look at the internal structure of the device to figure out what it's capable of and how those signals can be used.
and i thought i read through the whole thing...
ok with the help of that i tried to assign all the pins in such a way that makes it easier to route.
overall i used up all IO pins, and there were only 2 input pins open that i connected to GND. (pin 2 and pin 44)
it also fits on the PCB, though i had to move some Ground Traces around for that.
- BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Starting with my first SBC Project, Plans and Confusions
Proxy wrote:
morale of the story, throw everything you can into a single chip.
BigDumbDinosaur wrote:
Proxy wrote:
well i would like to start with the ATF1504, but i
This is the one I use.
Quote:
need a programmer...
i found the same on Mouser as well so i can order it with my other components. problem is that they are out of stock, and it will take a few months for new ones to arrive (acording to the site).
Quote:
I know the use of the 4 JTAG pins, and will avoid using them for IO stuff. (I assume my JTAG connector is correct as i cannot find a pinout of the Atmel Programmer's connector online)
Quote:
OE (Output enable), there are 2 of these and one of them is on the same pin as a Global clock, no idea what they are for.
PD (???), there are also 2 of these, again no idea what they might be for.
PD (???), there are also 2 of these, again no idea what they might be for.
PD is "power down" and would be used to reduce power consumption when the circuit is idling. As with OE, PD can be used for regular I/O.
Other than avoiding the use of the designated JTAG pins as I/O (there is a booby-trap waiting for you if you do declare one of those pins for anything other than JTAG), and applying your clock signal (if used) to GCLK and reset to GCLR, you are free to use pins as required. However, I recommend you design your logic before you lay out the rest of the circuit and let the fitter decide how to best use the CPLD's resources.
x86? We ain't got no x86. We don't NEED no stinking x86!