6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:06 pm

All times are UTC




Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Thu Oct 29, 2015 10:43 pm 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
BigDumbDinosaur wrote:
That is one of the reason why I decided to use Atmel's CPLDs. Their ATF150xAS series can be run at 5 volts. The ATF1508AS has 128 macrocells and 64 uncommitted I/O pins.

Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.

The other reason to use 3.3 volts is because very few modern parts work with 5 volts any more so if you're building a hybrid system (e.g. retro CPU with modern peripherals), you're going to need a 3.3-volt interface anyway.


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 29, 2015 11:02 pm 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
Quote:
Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.


That was the main reason I was put of Atmel PLD parts as well. It's a shame, because their AT40K FPGAs sound quite nice. But in addition to the programmer problem, the tooling did not appear to be nice and integrated like it is with the Xlinix and Altera parts (I have no experience with Lattice, yet).

Quote:
The other reason to use 3.3 volts is because very few modern parts work with 5 volts any more so if you're building a hybrid system (e.g. retro CPU with modern peripherals), you're going to need a 3.3-volt interface anyway.


I've yet to come across something I'm desperate to include in my micros that is 3.3V only. Yes there's some funky 3.3V SPI/I2C peripherals but, really, what else 3.3V only would you want to include in a "mostly retro" 8 bit micro? Just curious to hear your ideas, and to find out what I'm missing out on.

_________________
8 bit fun and games: https://www.aslak.net/


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 29, 2015 11:17 pm 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
Aslak3 wrote:
Quote:
I've yet to come across something I'm desperate to include in my micros that is 3.3V only. Yes there's some funky 3.3V SPI/I2C peripherals but, really, what else 3.3V only would you want to include in a "mostly retro" 8 bit micro? Just curious to hear your ideas, and to find out what I'm missing out on.

In no particular order:

  • ESP8266 http://www.instructables.com/id/Using-the-ESP8266-module/
  • Microcontrollers -- I'm working on a PIC24-based UART right now and it runs only at 3.3V
  • Lots of SPI & I2C devices only work at 3.3 volts. These include lots of fun devices to play with like sensors (accelerometers, gyros, environmental sensors, etc.).

The third bullet above really does include lots of neat devices. For example a 9-DOF combination 3-axis accelerometer, magnetometer, and gyro can be used for lots of interesting applications if you have a 3.3 volt interface available. Basically, if you're into robotics, sensors, and more you're really going to want a 3.3 volt interface on your system.


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 29, 2015 11:22 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1746
Location: Sacramento, CA
I'm jumping in kind of late, but my SBC-4 does most of the things jmp(FFFA) mentioned. It use an AVR to load RAM during reset, and buffered most of the IO, including 8 bit data bus, 4 bit address, and 4 device selects with assoicated interrupts. I have composite video, pc keyboard, 65SPI with CF FAT16 drive, ethernet, and a 65C22 running through the CPLD with no timing issues.

More info can be found here:
http://sbc.rictor.org/info4.html

thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Last edited by 8BIT on Sat Jun 27, 2020 8:56 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 29, 2015 11:31 pm 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
8BIT wrote:
I'm jumping in kind of late, but my SBC-4 does most of the things jmp(FFFA) mentioned.

Thanks Daryl. Indeed it does look a lot like what I started out thinking of, before Arlet convinced me to take another look at using an FPGA instead of the CPLD. I'd certainly prefer to leverage the work one of you folks have already done rather than try to re-invent the wheel myself.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 1:09 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BigDumbDinosaur wrote:
I foresee some interesting timing problems associated with interposing a CPLD in between the 65C02 and the rest of the system.
jmp(FFFA) wrote:
how would it be different from using a bus transceiver to isolate the CPU from an external bus? Something like the 74HC245?
It wouldn't be different, although I guess it's somewhat interesting. Even interposing a simple bus transceiver between the 65C02 and the rest of the system results in a timing penalty. For example a read requires an address to be sent from CPU to memory and for the data to be sent back to the CPU. Usually a direct path is fastest. Sometimes a transceiver (or other interposed circuitry) is unavoidable -- or maybe there's an associated benefit which outweighs the penalty -- and that's fine.

But running all the address lines and data lines through the CPLD may be overkill. If the state of the address lines, for instance, ends up simply being input on one set of CPLD pins and then output, unmodified, on another set of pins then you've incurred the penalty but there's no benefit.

8BIT wrote:
I'm jumping in kind of late
Tell me about it! I just replied to the last post on page 1, not realizing that several subsequent posts had caused a page 2 to appear! :roll:

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 2:39 am 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
Dr Jefyll wrote:
But running all the address lines and data lines through the CPLD may be overkill. If the state of the address lines, for instance, ends up simply being input on one set of CPLD pins and then output, unmodified, on another set of pins then you've incurred the penalty but there's no benefit.

Agreed. I'll admit I can't conceive of any scenarios offhand where it would make sense to run, say, the lower 8-10 address lines through the FPGA or CPLD (depending on the pagesize of the MMU you were planning). OTOH, it's just those previously un-thought-of scenarios that make reconfigurable hardware an asset if it's connected.

If nothing else comes up, I think I'll go ahead and re-build my existing testing system using my XC2C256 CPLD breakout board or maybe with a suitable small+cheap FPGA board like the Lattice Brevia if I want to play around with VGA video. But not, of course, until I have the PIC-UART up and running.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 4:38 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
jmp(FFFA) wrote:
BigDumbDinosaur wrote:
I foresee some interesting timing problems associated with interposing a CPLD in between the 65C02 and the rest of the system. The system would be leading or lagging the 65C02 on every bus transaction.

How would it be different from using a bus transceiver to isolate the CPU from an external bus?

If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

Quote:
A modern CPLD could probably implement 2-3 levels of logic in the T(pd) time of a single 74HC245.

You keep focusing on 74HC logic, yet there are several other logic families that are faster, such as 74AC (what I used in POC V1) and 74ABT. For example, a 74ABT245's typical input to output prop time on 5 volts at 25° C is 2.2ns. The same value in a 74HC245 under the same operating conditions is 7ns. Also, the 74AC and 74ABT devices have greater fanout. I haven't built anything with 74HC logic in a long time, as it offers little more than 74LS, except better noise immunity.

You might find this page on NXP's website to be of interest, as it lists the logic families for which they are producing discrete devices. Take a look at the buffer/driver units and bus transceivers listed under the 74ABT family.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 6:45 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Quote:
If you have any interest in making a V2 board, I'm willing to collaborate. Here is a random list of features I'd be in favor of supporting:

Analog VGA output (25.175 MHz clock would be fine for anything I'm thinking of)
8 Mbit of fast SRAM for system use
65C02 and 65C816 support (I'm game for other 8-bit CPUs as well)
SPI flash for FPGA configuration and bootloader storage (just like you did in V1)
MicroSD SPI interface for virtually unlimited storage of programs and data by the system
UART for debugging or serial access via something like an ESP8266
PS/2 port for a keyboard interface (USB is another possibility though more work)


Sounds interesting. I'm kinda busy with other work right now, but starting next week, it should ease up a bit, so I could do some fun stuff again. The biggest problem I was struggling with is the FPGA pin count. Using a design where the FPGA sits between the CPU and the memory requires a lot of I/O pins, leaving very little for anything else (V1 had 11 I/O pins left on the FPGA). I don't know how many colours you want for the VGA, but potentially it could cost quite a few pins.

That's why for V2, I had decided to attach the SRAM directly to the processor, and the FPGA hanging on the bus as a peripheral. The disadvantage is that you have less control over the memory, and it wastes a lot of SRAM access time that could otherwise be used to do DMA or video. So, even though I had made that decision, I wasn't really thrilled about it.

Adding more pins would require moving to BGA, which I'm not too excited about either. It requires a more expensive board, make assembly harder, and cost more.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 7:03 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigDumbDinosaur wrote:
If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

Yes, but that's not a problem. When you add regular decoding logic between the CPU and the peripherals, they also see the signals slightly sooner.

Quote:
You keep focusing on 74HC logic, yet there are several other logic families that are faster, such as 74AC (what I used in POC V1) and 74ABT. For example, a 74ABT245's typical input to output prop time on 5 volts at 25° C is 2.2ns. The same value in a 74HC245 under the same operating conditions is 7ns.

The point is that 7 ns is fast enough, especially if you only need one logic layer.

Edit: for 65c02, read access time at 5V is 30ns. Take a 10ns SRAM, and there's still 20ns left over for the CPLD. When moving to 3V3, it becomes a very comfortable 60 ns.


Last edited by Arlet on Fri Oct 30, 2015 11:17 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 10:15 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Aslak3 wrote:
Quote:
Nothing against the Atmel CPLDs, but the last time I looked at them (some time ago), it was impossible to get a programmer for them that didn't cost an arm and a leg. With Xilinx, Altera, or Lattice parts, JTAG programmers cost under $50.


That was the main reason I was put of Atmel PLD parts as well. It's a shame, because their AT40K FPGAs sound quite nice. But in addition to the programmer problem, the tooling did not appear to be nice and integrated like it is with the Xlinix and Altera parts (I have no experience with Lattice, yet).


The Atmel PLD are only an issue when you want to use the JTAG pins as normal IO pins. As long as the JTAG pins are dedicated to the JTAG interface a normal JTAG programmer will do the job. Actually I'm doing exactly that. Currently I have set up a system with a ATF1504AS that does more or less all the GLUE logic job (as I did not have enough pins I had to add a GAL22V10 for further signals) and implements a 6502 system compatible with a Apple IIe. Also the system's ROM image is loaded via an AVR, using the blind load method (i.e. the AVR creates the clock via software and feeds the databus with the expected bytes). A ATmega328P is all you need and the ATmega328P also implements the PS/2 interface. It is similar to my ROMulus1st http://forum.6502.org/viewtopic.php?f=4&t=3458breadboard setup. However ROMulus1st only requires a GAL22V10 + 74AC00 as GLUE. The good thing is that the Atmel PLD are available and 5V devices.

The ATF1504AS is rather small to implement all the features jmp($FFFA) mentioned, my Apple IIe clone really goes to the limits of the CPLD. So I'm thinking about replacing the ATF1504S with a ATF1508AS, even though TQFP-100 is difficult to solder for me. TQFP-44 of the ATF1504AS on the other side is very easy to solder.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 11:51 am 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
BigDumbDinosaur wrote:
If the only thing between the MPU and all other hardware are bus transceivers then all devices, including the CPLD, are seeing the same signals at the same time. When the CPLD becomes the bus transceiver, its innards are seeing signals slightly sooner that the outside world.

I agree with what you are saying here. I'm not convinced the timing problems would be insurmountable, but they could certainly become an issue. I've run into exactly this problem with my current test setup when my logic delays finally added up to the point where the memory stopped working. Interestingly, I didn't fix the problem by going to the faster logic families that you are in favor of -- I just adjusted the system clock to compensate for the extra delays.

This is another reason in favor of Arlet's suggestion to use an FPGA instead of a CPLD. Since most FPGAs have PLL blocks on board, you can create clocks signals with arbitrary phases. Thus if you have fixed delays introduced by logic, you can easily change their timing relative to clock edges. Obviously you are still limited by the total width of the various timing windows on the CPU, but I don't think that will often be an issue at speeds as high 8 MHz (fastest speed supported at 3.3 volts), and perhaps even 14 MHz would not be difficult to reach either.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 12:10 pm 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
cbscpe wrote:
The Atmel PLD are only an issue when you want to use the JTAG pins as normal IO pins. As long as the JTAG pins are dedicated to the JTAG interface a normal JTAG programmer will do the job. Actually I'm doing exactly that.


Well, that is the same as I've used both the XC9500 and Flex 10Ks, but with vendor specific programmers (or clones, in the case of Altera). I did not now the Atmel parts can be used with generic programmers though.

But what I really struggled with is the tooling. With both the Xilinx and Ateml PLDs, everything is nicely contained: HDL synthesis, simulation, programming etc. And free. It wasn't nearly so clear how to get started with the Atmel parts, so I basically gave up. I'd be interested to hear what software you use in your tooling.

_________________
8 bit fun and games: https://www.aslak.net/


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 12:27 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Quote:
This is another reason in favor of Arlet's suggestion to use an FPGA instead of a CPLD. Since most FPGAs have PLL blocks on board, you can create clocks signals with arbitrary phases.


Using multiple clocks may not even be necessary. What I did in my project was generate an internal 96 MHz clock, and divide it by 12 to generate the 8 MHz output clock for the 65C02. Starting at falling edge of PHI2 I would wait (internal) 4 cycles, and grab the address from the 6502 bus, and copy it to the SRAM address bus. Two cycles later, I would take the data from the SRAM bus, and write it to the 6502 bus, with a few cycles to spare. In the remaining 10/11 cycles the SRAM was free to be used by the FPGA.


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 30, 2015 2:00 pm 
Offline

Joined: Wed Sep 23, 2015 8:14 pm
Posts: 171
Location: Philadelphia, PA
Arlet wrote:
Sounds interesting. I'm kinda busy with other work right now, but starting next week, it should ease up a bit, so I could do some fun stuff again. The biggest problem I was struggling with is the FPGA pin count. Using a design where the FPGA sits between the CPU and the memory requires a lot of I/O pins, leaving very little for anything else (V1 had 11 I/O pins left on the FPGA). I don't know how many colours you want for the VGA, but potentially it could cost quite a few pins.

I'm not sure what you are using all of the I/O pins for, but if you aren't married to Xilinx FPGAs, here are a couple of non-BGA FPGAs to consider:

Lattice XP2: LFXP2-17E-5QN208C -- 146 I/O pins available in a 208-PQFP package
Altera Cyclone III: P3C16Q240C8 -- 160 I/O pins available in a 240-PQFP package

I like the way you set things up on V1 where you interleave access to fast SRAM between the CPU and other peripherals (e.g. video). A 25.175 MHz video clock (enough to support 640x480 -- I don't see much point in higher resolutions with an 8-bit processor) should still leave enough time for the 8 MHz 65C02/65C816 to access the SRAM with no wait states, and the FPGA can create an MMU which will give the 65C02 access to an arbitrarily large amount of memory. I don't know if there's any value in making the system clock a multiple of the video clock or just go ahead and create two clock domains. Probably the latter since it's no big deal to introduce pipelines of any reasonable size for video processing anyway.

Oh, and I would be happy with 12 bits for color (4-bit DACs). More would be nice, but returns diminish rapidly above 4-5 bits anyway.

Arlet wrote:
Adding more pins would require moving to BGA, which I'm not too excited about either. It requires a more expensive board, make assembly harder, and cost more.

Have a look at the two FPGAs above and let me know what you think. If you don't need more than 160 pins for what you're thinking of using it for, then perhaps there is no need to go to a BGA package. I don't expect that soldering the 240-PQFP package will be fun, however! :)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 16 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: