6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 21, 2024 9:46 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Tue Oct 03, 2017 2:33 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Well, after the parent company's decision to scale down the US startup, I (and about 6 other colleagues so far) find ourselves with a lot of free time now. I opted to work on a few backlog projects and decided to learn enough about WinCUPL to make a glue chip for a new SBC I've been toying with for a while. I had purchased some Atmel ATF22V10C chips previously so this was also a chance to see if my pricey Dataman programmer would successfully program these as well.

It took some doing to figure out some of the WinCUPL stuff... and as previously noted, it is a buggy chunk of bytes. However, I finally managed to create a configuration that handles qualified memory read and write signals, 5- I/O selects that are 32-bytes wide, plus ROM and RAM selects. Inputs are the CPU clock, R/W signal and address lines A5 through A15. I managed to get everything working and used some prototype jumpers to get it wired to my original 65C02 processor board. The board uses a 74HC00, 74HC30 and 74HC138 and is basically the CPU board I did in wire-wrap back in the late 80's with all CMOS parts.

Now that I have a completed glue chip, I'll move on to the next phase... a new reset chip that provides both a positive and negative reset signals which are open collector (TL7705) and replacing the 65C51 with a NXP part. I'm hoping to get this on a working PCB by Xmas, unless another opportunity snatches me away again.

Below is the code pasted from WinCUPL:

Code:
Name     SBC-Glue2 ;
PartNo   01 ;
Date     10/3/2017 ;
Revision 01 ;
Designer K. Maier ;
Company  Analogue Technologies ;
Assembly SBC-01 ;
Location U4 ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */
PIN 2    = A15                       ; /*                                 */
PIN 3    = A14                       ; /*                                 */
PIN 4    = A13                       ; /*                                 */
PIN 5    = A12                       ; /*                                 */
PIN 6    = A11                       ; /*                                 */
PIN 7    = A10                       ; /*                                 */
PIN 8    = A9                        ; /*                                 */
PIN 9    = A8                        ; /*                                 */
PIN 10   = A7                        ; /*                                 */
PIN 11   = A6                        ; /*                                 */
PIN 13   = A5                        ; /*                                 */
PIN 23   = RW                        ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 14   = IO1                       ; /*                                 */
PIN 15   = IO2                       ; /*                                 */
PIN 16   = IO3                       ; /*                                 */
PIN 17   = IO4                       ; /*                                 */
PIN 18   = IO5                       ; /*                                 */
PIN 19   = ROM                       ; /*                                 */
PIN 20   = RAM                       ; /*                                 */
PIN 21   = MWR                       ; /*                                 */
PIN 22   = MRD                       ; /*                                 */

/*
 * Logic:  All outputs are active low.
 */

/*
 * RAM  = $0000
 * ROM  = $8000
 * IO1  = $FE00
 * IO2  = $FE20
 * IO3  = $FE40
 * IO4  = $FE60
 * IO5  = $FE80
 * MWR  = (CLK & !RW);
 * MRD  = (CLK & RW);
 */

RAM  = A15;
ROM  = !A15 # (A14 & A13 & A12 & A11 & A10 & A9 & !A8);
IO1  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5);
IO2  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & A5);
IO3  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & A6 & !A5);
IO4  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & A6 & A5);
IO5  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & A7 & !A6 & !A5);
MWR  = !(CLK & !RW);
MRD  = !(CLK & RW);

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 03, 2017 9:23 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
This looks like it will work. The closest thing to a problem that I can see is that you've done what I did at first and not declared active-low pins that way. I'm told that it uses less of each macrocell if you do that, and it does make it a bit easier to read.


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 03, 2017 11:41 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I've no doubt that there are better ways to do this, especially as this is a first try. However, it is currently functioning with an existing board set. I removed the three 74xx chips and wired the ATF22V10 in and the board is working driving a 65C51 and 65C22. However, I'm only using two of the five I/O selects and the am not using the RAM select as the board has the RAM select wired directly to A15 from the processor. I did build up a working model with the chip on a protoboard and have LEDs connected to the outputs and a 1MHz can oscillator driving the CLK line. Using some DIP switches to change the state of all input lines, it functions lighting the LEDs correctly which also matches the Simulator output from WinCUPL.

In any case, if you have some good feedback and examples, I'm more than happy to continue making changes that would be beneficial. So far, I'm pretty happy with the results, as 1- the general feedback here is that WinCUPL is buggy and 2- that finding a programmer that can successfully program the Atmel logic chips can be difficult. Thanks.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 04, 2017 3:47 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
DerTrueForce wrote:
you've done what I did at first and not declared active-low pins that way. I'm told that it uses less of each macrocell if you do that, and it does make it a bit easier to read.
I don't doubt the "easier to read" observation, but this notion of consuming less resources or more resources is an eyebrow raiser and I wonder if your source is reliable. You're just expressing the same thing in a different way, and CUPL is almost certainly able to figure that out -- otherwise there's one heck of a bug. Which is not impossible, so who knows? Floobydust, are you in the mood to try the thing both ways and tell us whether it changes resource consumption? Sounds like you're having fun playing with this... :)

-- Jeff

_________________
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: Wed Oct 04, 2017 6:32 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
Dr Jefyll wrote:
DerTrueForce wrote:
you've done what I did at first and not declared active-low pins that way. I'm told that it uses less of each macrocell if you do that, and it does make it a bit easier to read.
I don't doubt the "easier to read" observation, but this notion of consuming less resources or more resources is an eyebrow raiser and I wonder if your source is reliable. You're just expressing the same thing in a different way, and CUPL is almost certainly able to figure that out -- otherwise there's one heck of a bug. Which is not impossible, so who knows? Floobydust, are you in the mood to try the thing both ways and tell us whether it changes resource consumption? Sounds like you're having fun playing with this... :)

-- Jeff

Not declaring active-low outputs as active-low (e.g., PIN 4 = !ROMSEL for an active-low ROM chip select) may result in greater PT consumption on some Atmel devices. From what I learned in E-mail exchanges with their technical support people, this is due to an inversion function being added when negative logic is used to drive an active-low output in lieu of declaring the pin as active-low. Going on their advice, I declared all active-low outputs as active-low in the CUPL code for POC V2 and exclusively used positive logic to drive all outputs. I also made extensive use of buried logic (not available in GALs) to handle intermediate logic functions, as well as to implement flops. The result was that I only used about one half the total available logic resources in an ATF1504AS, despite have a bunch of chip selects, hardware management registers and wait-state generation. Every uncommitted I/O pin was used.

Based on all that:

Code:
IO1  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5);

should utilize device resources more efficiently if written as:

Code:
IO1  = A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5;

with IO1 declared as active-low.

Further simplification could be had with:

Code:
IO1  = A15 & A14 & A13 & A12 & A11 & A10 & A9 & !(A8 # A7 # A6 # A5);

Aside from whatever efficiency might be had, I find use of positive logic easier to understand. As always, your mileage may vary.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 04, 2017 7:11 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BigDumbDinosaur wrote:
Based on all that:

Code:
IO1  = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5);

should utilize device resources more efficiently if written as:

Code:
IO1  = A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5;

with IO1 declared as active-low.

There must be a problem somewhere. I can't agree there should be a difference in resource-use efficiency simply by switching between two differently-worded expressions if they boil down to the same thing (as is the case in the example you provide). A rather drastic CUPL bug might explain the anomaly. Or perhaps your contact at Atmel thought you were contemplating actually changing the polarity of the signal at the output pin (and presumably also changing external circuitry to suit). In such a case the before-and-after expressions do not boil down to the same thing -- and it would be useful to know which version consumed less resources, so in fact it's a valuable point to consider. However, the example you provide shows two expressions that have the same meaning. I'm not a CUPL user but it seems obvious that CUPL shouldn't care at all whether you said tomayto or tomahto.

_________________
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: Wed Oct 04, 2017 6:34 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Okay, first, thanks to all for the feedback and input, valuable as always. I just took some power supply measurements. During operation and even putting a macro to loop on a bunch of monitor instructions, the ATF22V10C hovers at 36ma of current and basically doesn't change. I'm going to create a new project based on the input and assign the outputs as active low and change the logic definitions as well. I'll report back later today with my findings.
One thing I have noticed with WinCUPL, if I change any pin definitions, it basically hoses up the project and simulator which then crashes, hence my desire to create a new project instead.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 05, 2017 3:11 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I did a new version of the Glue chip with the outputs defined as active low. Upon doing this, the ROM was always selected regardless of the IO page ($FE00) being active and/or any of the I/O selects being active. Basically, I couldn't find any combination of logic statements that would work when defining ROM as active low. I then took a different approach... as, ideally, I wanted to have the unused bytes of the IO Page accessible if I wasn't using any of the five IO selects (this wasn't possible using the previous 74xx chips). So I changed the (ROM) logic statement to use the 5 IO selects as part of the statement. This actually works, which is nice... I gained back 3x32 bytes in the ROM which I can use for additional code or data.

Now that I have this new glue configuration working, I did another measurement on operating current and it's identical, i.e., 36ma. The initial attempt did result is a much smaller JED file. The first working file is roughly 3.29KB. The first attempt for the second version was around 1.68KB but had the anomaly of never deselecting the ROM for IO accesses. The new working version is larger however at 4.03KB.

Here's the current PLD file:

Code:
Name     SBC-Glue3 ;
PartNo   01 ;
Date     10/4/2017 ;
Revision 01 ;
Designer K. Maier ;
Company  Analogue Technologies ;
Assembly SBC-02 ;
Location U4 ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1    =  CLK                      ; /*                                 */
PIN 2    =  A15                      ; /*                                 */
PIN 3    =  A14                      ; /*                                 */
PIN 4    =  A13                      ; /*                                 */
PIN 5    =  A12                      ; /*                                 */
PIN 6    =  A11                      ; /*                                 */
PIN 7    =  A10                      ; /*                                 */
PIN 8    =  A9                       ; /*                                 */
PIN 9    =  A8                       ; /*                                 */
PIN 10   =  A7                       ; /*                                 */
PIN 11   =  A6                       ; /*                                 */
PIN 13   =  A5                       ; /*                                 */
PIN 23   =  RW                       ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 14   =  !IO1                      ; /*                                 */
PIN 15   =  !IO2                      ; /*                                 */
PIN 16   =  !IO3                      ; /*                                 */
PIN 17   =  !IO4                      ; /*                                 */
PIN 18   =  !IO5                      ; /*                                 */
PIN 19   =  !ROM                      ; /*                                 */
PIN 20   =  !RAM                      ; /*                                 */
PIN 21   =  !MWR                      ; /*                                 */
PIN 22   =  !MRD                      ; /*                                 */

RAM = !A15;
ROM = A15 & !(IO1 $ IO2 $ IO3 $ IO4 $ IO5);
IO1 = (A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & !A5);
IO2 = (A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & !A6 & A5);
IO3 = (A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & A6 & !A5);
IO4 = (A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & !A7 & A6 & A5);
IO5 = (A15 & A14 & A13 & A12 & A11 & A10 & A9 & !A8 & A7 & !A6 & !A5);
MWR = (CLK & !RW);
MRD = (CLK & RW);


I would also mention that WinCUPL is buggy... at one point, every compile showed errors... I had to kill it and relaunch it, then is started compiling without errors. Also, regardless of how I structure the first set of parameters (Name, Part No, etc.) these always show as warnings as being incorrect, yet I used the WinCUPL new project wizard and simply filled in the data. In any case, the ATF22V10 is working as I want it to. It does draw more current then the rest of the system, but I guess that's just the way these devices are. Unless someone has some other advice on getting the current consumption down, I think I have a functional glue chip to use going forward. Of course, thanks to all who replied!

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Thu Oct 05, 2017 4:53 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
floobydust wrote:
I did a new version of the Glue chip with the outputs defined as active low...The initial attempt did result is a much smaller JED file. The first working file is roughly 3.29KB. The first attempt for the second version was around 1.68KB but had the anomaly of never deselecting the ROM for IO accesses. The new working version is larger however at 4.03KB.

The 22V10 series of GALs does not implement exclusive-OR in hardware. WinCUPL converted your XOR operations in the ROM select logic to a melange of ANDs and ORs, which would explain the larger fuse map file.

Quote:
In any case, the ATF22V10 is working as I want it to. It does draw more current then the rest of the system, but I guess that's just the way these devices are. Unless someone has some other advice on getting the current consumption down, I think I have a functional glue chip to use going forward. Of course, thanks to all who replied!

GALs are from a time in the development of programmable logic where their current consumption was actually an improvement over a bunch of discrete gates implementing the same logic. Atmel's GALs are somewhat more efficient than earlier designs. 36 mA current draw sounds about right.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 23, 2017 6:33 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi floobydust,

I worked quite a bit with WinCUPL and used GALs and CPLDs and there is the following to note. First GALs and CPLDs are completely different beasts. As for defining outputs as inverted or not, with GALs there is no real choice, they have inverted outputs and you should define them as inverted PINs. With CPLDs it depends, I had various stages of success and sometimes I had to use the equation assigning the inverted value to the output and sometimes I better defined the PINs as inverted. This is mainly due to the fact that each OMLC of the GAL has fixed number of PTs and there is no internal logic (like foldback, softbuffer and cascaded macrocells) which can change the number of PTs assigned to an output like in a CPLD. Another thing is you need to know that the number of PTs in a GAL22V10 depends on the output pin. Pin 14 and 23 have 8 PTs, Pins 15 and 22 have 10, Pins 16 and 21 have 12, Pins 17 and 20 have 14 and Pins 18 and 19 have 16 product terms. If you use the OE of a output pin then it uses one of the available product terms.

When working with addresses and address ranges I use the following notation

Code:
FIELD ADDRESS = [A15..0];

Fields internally start always with 0, even if you don't use the lower address bits. It is always a good idea to define them with all bits. If you don't use them then WinCUPL does not require that they have been assigned a Pin and just suppresses them. With this your select signals can be defined in a much nicer way

Code:
RAM = ADDRESS:['h'0000..7FFF];
IO1 = ADDRESS:['h'FE00..FE1F];
IO2 = ADDRESS:['h'FE20..FE3F];
IO3 = ADDRESS:['h'FE40..FE5F];
IO4 = ADDRESS:['h'FE60..FE7F];
IO5 = ADDRESS:['h'FE80..FE9F];
ROM = ADDRESS:['h'8000..FDFF]
        # ADDRESS:['h'FEA0..FFFF];

if you put ROM at a pin with many PTs this should work. I recommand that you change the output options of WinCUPL and create all files (like .doc etc.) then you can check what WinCUPL really did.

Peter


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 30, 2017 3:34 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Hi Peter,

Sorry I just recently saw your post here, currently in Germany visiting some friends and gaining weight :shock:

I did notice the difference in the number of Product Terms when looking at the datasheets earlier, but with my simple decode requirements, I didn't think it would matter too much. In any case, I did use some of the lower PT I/O pins for the R/W, MRD and MWR lines.

I also didn't get into the Field Address section of WinCUPL, so appreciate the details/example on this. It does make better sense and more of a logical approach to getting the various output selects to function. When I get back home I'll certainly try this and re-program the 22V10 to see if I can get it to work. I'm guessing that not much of anything is going to result in a lower current consumption with one of these devices. It is apparent that using the 22V10 or 750CL draws more current (by itself) than the rest of the SBC components.

I am getting close to making a new SBC that will use the glue logic that I was able to get working and also using a NXP UART as the console chip as the initial code for that is also working. So many options, so little (free) time! Thanks again!!

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Tue Oct 31, 2017 3:17 am 
Offline

Joined: Tue Feb 24, 2015 11:07 pm
Posts: 81
cbscpe wrote:
Code:
RAM = ADDRESS:['h'0000..7FFF];
IO1 = ADDRESS:['h'FE00..FE1F];
IO2 = ADDRESS:['h'FE20..FE3F];
IO3 = ADDRESS:['h'FE40..FE5F];
IO4 = ADDRESS:['h'FE60..FE7F];
IO5 = ADDRESS:['h'FE80..FE9F];
ROM = ADDRESS:['h'8000..FDFF]
        # ADDRESS:['h'FEA0..FFFF];


That is a seriously tidy representation! Thank-you for the example.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 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: