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

All times are UTC




Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Jul 17, 2021 10:59 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Hi guys

Would someone be able to visually check my WinCUPL (Abel) code? It's (supposed to be) an octal D latch and will be used for latching D0-7 for A16-A23 in a 65c816 design.
The code compiles for me, but I have no device and test rig to test it on at the moment and the simulator doesn't seem to like it (at least for me).

Code:
Name      W65C816v2;
Partno    C;
Date      17/07/2021;
Rev       01;
Designer  mjkd;
Company   tst;
Assembly  None;
Location  None;
Device    f1508ispplcc84;


/* Input pins */
pin 2 = clk;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* Output pins */
pin [16,17,18,20,21,22,24,25,27] = [Q0..7];      /* Q output */

/* Logic */
[rst0..7] = [D0..7] & clk;
[set0..7] = ![D0..7] & clk;
[Q0..7] = !([set0..7] & [nQ0..7]);      
[nQ0..7] = !([rst0..7] & [Q0..7]);


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 12:47 am 
Offline

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166
I think what you want is this:

/* Input pins */
pin 2 = clk;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* Output pins */
pin [16,17,18,20,21,22,24,25,27] = [Q0..7]; /* Q output */

/* Logic */
[Q0..7].L = [D0..7]; /* Each Qi is a transparent latch with input Di */
[Q0..7].LE = clk; /* Each Qi is a transparent latch with enable connected to clk - follows input when clk low, latched when clk high */


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 6:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8480
Location: Midwestern USA
kernelthread wrote:
Code:
/* Input pins */
pin 2 = clk;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* Output pins */
pin [16,17,18,20,21,22,24,25,27] = [Q0..7];      /* Q output */

/* Logic */
[Q0..7].L = [D0..7]; /* Each Qi is a transparent latch with input Di */
[Q0..7].LE = clk; /* Each Qi is a transparent latch with enable connected to clk - follows input when clk low, latched when clk high */

When you post code, you can surround it with the code tags and it will display in monospace format, like I did above with your example.

Note that as the above is written, the Q0-Q7 outputs are really A16-A23.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 7:26 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
kernelthread wrote:
I think what you want is this:

/* Input pins */
pin 2 = clk;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* Output pins */
pin [16,17,18,20,21,22,24,25,27] = [Q0..7]; /* Q output */

/* Logic */
[Q0..7].L = [D0..7]; /* Each Qi is a transparent latch with input Di */
[Q0..7].LE = clk; /* Each Qi is a transparent latch with enable connected to clk - follows input when clk low, latched when clk high */


Thanks very much! As 'easy' as extensions seem to be, my brain still does not deal well with them and I didn't realise it was that simple.

[edit] Did you manage to get this simulated at all? WinSim doesn't seem to like it (what a surprise) with no results for Q0..Q7. 35 warnings come up when there is a .SI file (see below) so definitely a simulator issue.
No errors or warnings that I can find in the actual files. I'll keep looking, but this might be just a limitation of WinSim. I just love WinCUPL sometimes ... :wink: :roll:

The file being compiled is called OctalDlatch.pld and the header is the same in the .SI file:

Code:
Name     OctalDlatch;
PartNo   C;
Date     17/07/2021;
Revision 01;
Designer tst;
Company  tst;
Assembly None;
Location None;
Device   f1508ispplcc84;


ORDER: clk, D0..D7, Q0..Q7;


VECTORS:
0 'A0' ********
1 'A1' ********
0 'A2' ********
1 'A3' ********


Last edited by banedon on Sun Jul 18, 2021 8:19 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 8:11 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8480
Location: Midwestern USA
banedon wrote:
The code compiles for me, but I have no device and test rig to test it on at the moment and the simulator doesn't seem to like it (at least for me).

Code:
Name      W65C816v2;
Partno    C;
Date      17/07/2021;
Rev       01;
Designer  mjkd;
Company   tst;
Assembly  None;
Location  None;
Device    f1508ispplcc84;

/* Input pins */
pin 2 = clk;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* Output pins */
pin [16,17,18,20,21,22,24,25,27] = [Q0..7];      /* Q output */

/* Logic */
[rst0..7] = [D0..7] & clk;
[set0..7] = ![D0..7] & clk;
[Q0..7] = !([set0..7] & [nQ0..7]);      
[nQ0..7] = !([rst0..7] & [Q0..7]);

First off, your A16-A23 output assignment pin [16,17,18,20,21,22,24,25,27] = [Q0..7]; is incorrect. Q0..7 says there are eight pins total, but you listed nine.

Next, the following lines are unnecessary and while they may compile without errors, no simulation or JEDEC file would be generated:

Code:
[rst0..7] = [D0..7] & clk;
[set0..7] = ![D0..7] & clk;

What are you trying to accomplish in that code? What are rst0..7 and set0..7 supposed to be?

kernelthread's above example will compile and should correctly simulate, but doesn't take advantage of the 1504's extensive buried logic capabilities, which if correctly used, will greatly help performance and conserve logic resources.

I would start with:

Code:
pinnode = extram[0..7];

The PINNODE verb tells the compiler and fitter that the referenced elements are buried logic, not inputs or outputs. I gave these elements the name extram to make it clearer what it is that is being processed—the MSB of an extended RAM address. Note that PINNODE is declared without a pin number, despite the name.

Once that statement has been made, you would write:

Code:
extram[0..7].LE = PHI1;
extram[0..7].L  = D[0..7];

The first statement opens the latches when PHI1 is high, which, of course, is when PHI2 is low. That statement also implicitly declares extram to be transparent D-latches (the .LE and .L suffixes do that).

The second statement causes the latches to follow D0-D7 until PHI1 goes low, at which time the latches will be closed and retain their content. Note that this is not qualified by PHI1 because D0-D7 become "don't cares" as soon as PHI1 goes false and the latches close (which happens in a nanosecond or so after the fall of PHI1). There is no harm in doing so, but all you will accomplish is to unnecessarily consume logic resources.

Your output statement would be:

Code:
A[16..23] = extram[0..7];

A16-A23 would be actual pins declared with a statement such as:

Code:
PIN = A[16..23];

You could add logic to the output statement to not drive A16-A23 unless VDA # VPA is true. However, as I mentioned elsewhere, VDA and VPA are "don't cares" when it comes to latching A16-A23. Chip selects are what care about VDA and VPA, since you don't want to be accessing hardware while the MPU is busy outputting bogus addresses.

Along with the above, I would declare:

Code:
pinnode = bnk0;

followed later by:

Code:
bnk0 = extram[0..7]:['b'00000000];

The above will cause bnk0 to go true any time the MSB of the address is $00, that is, the address is in bank $00. You can then use that as a term in your chip select logic to cause ROM and I/O to only appear in bank $00. Without that sort of logic, ROM and I/O will mirror in all banks. The 'b' prefix means binary or bitwise. I could also write it as:

Code:
bnk0 = extram[0..7]:['h'00];

Use whatever is most understandable to you.

During your logic creation/edit/compile workflow, I suggest you not assign pin numbers to anything except the clock inputs (GCLK1 for Ø1 and GCLK2 for Ø2 it what I use) and reset, if being used (connect that to GCLR). Let the fitter work out the rest of the pins for you and concentrate on getting your logic correct. The fitter will distribute pin assignments as needed to make the best usage of the CPLD's logic resources and avoid I/O combinations on any one macrocell that would exceed the available PTs. If you insist on assigning all pins yourself then you will have to be prepared to study the CPLD's structure in detail to determine how to distribute your logic and avoid running out of PTs with a particular macrocell.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 8:19 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Sorry BDD I didn't see you post there. I'll have a read of yours then respond.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 10:18 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Thanks BDD - especially for the explanation as to what does what.


Last edited by banedon on Sun Jul 18, 2021 11:49 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 11:44 am 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
I don't think you're actually assigning any value to A16..A23 in the pld code, so it doesn't make sense to monitor and test them in the simulator. I think it would treat them as input-only by default.

Try monitoring extram0..extram7 in the simulator instead.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 11:50 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
gfoot wrote:
I don't think you're actually assigning any value to A16..A23 in the pld code, so it doesn't make sense to monitor and test them in the simulator. I think it would treat them as input-only by default.

Try monitoring extram0..extram7 in the simulator instead.

I realised my mistake so edited my post - and you'd posted in the meantime LOL


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 5:21 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Ok so it all compiles with 3 warnings (which so far I cannot find in any of the files), but whether I monitor extram0..7, A16..23, and .L version of them it makes no difference - no data for extram/A.

Code:
Name      OctalDlatch;
Partno    C;
Date      17/07/2021;
Rev       01;
Designer  tst;
Company   shalewyn.com;
Assembly  None;
Location  None;
Device    f1508ispplcc84;


/* define inputs */
pin 2 = PHI1;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* define outputs */
pin = [A16..23];         /* A16..23 pin declaration. not defining the pins (i.e. PIN = A[16..23]) is useful for debug/testing */

/* define intermediates */
pinnode = [extram0..7];      /* declare 'extram[0..7] as being buried in logic, not as I/O pins */
pinnode = bnk0;         /* delcares bnk0 as being buried logic, not as I/O pin */

/* latch logic */
[extram0..7].LE = PHI1;      /* extram0..7 latch when PHI1 is high */
[extram0..7].L  = [D0..7];      /* extram0..7 latch inputs are set to D0..7 */
[A16..23] = [extram0..7];

/* bank0 handling */
bnk0 = [extram0..7]:['h'00];   /* make bnk0 true if extram0..7 becomes 0 */


Last edited by banedon on Sun Jul 18, 2021 6:12 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 6:00 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8480
Location: Midwestern USA
banedon wrote:
Ok so it all compiles with 3 warnings (which so far I cannot find in any of the files), but whether I monitor extram0..7, A16..23, and .L version of them it makes no difference - no data for extram/A.

Code:
Name      OctalDlatch;
Partno    C;
Date      17/07/2021;
Rev       01;
Designer  tst;
Company   shalewyn.com;
Assembly  None;
Location  None;
Device    f1508ispplcc84;


/*
I would start with:

Code:
pinnode = extram[0..7];

The PINNODE verb tells the compiler and fitter that the referenced elements are buried logic, not inputs or outputs.
I gave these elements the name extram to make it clearer what it is that is being processed-the MSB of an extended RAM address.
 Note that PINNODE is declared without a pin number, despite the name.

Once that statement has been made, you would write:

Code:
extram[0..7].LE = PHI1;
extram[0..7].L  = D[0..7];

The first statement opens the latches when PHI1 is high, which, of course, is when PHI2 is low. That statement also implicitly
declares extram to be transparent D-latches (the .LE and .L suffixes do that).

The second statement causes the latches to follow D0-D7 until PHI1 goes low, at which time the latches will be closed and retain
their content. Note that this is not qualified by PHI1 because D0-D7 become "don't cares" as soon as PHI1 goes false and the latches
close (which happens in a nanosecond or so after the fall of PHI1). There is no harm in doing so, but all you will accomplish is to
unnecessarily consume logic resources.

Your output statement would be:

Code:
A[16..23] = extram[0..7];

A16-A23 would be actual pins declared with a statement such as:

Code:
PIN = A[16..23];

You could add logic to the output statement to not drive A16-A23 unless VDA # VPA is true. However, as I mentioned elsewhere, VDA and VPA
are "don't cares" when it comes to latching A16-A23. Chip selects are what care about VDA and VPA, since you don't want to be accessing
 hardware while the MPU is busy outputting bogus addresses.

Along with the above, I would declare:

Code:
pinnode = bnk0;

followed later by:

Code:
bnk0 = extram[0..7]:['b'00000000];

The above will cause bnk0 to go true any time the MSB of the address is $00, that is, the address is in bank $00. You
can then use that as a term in your chip select logic to cause ROM and I/O to only appear in bank $00. Without that sort
of logic, ROM and I/O will mirror in all banks. The 'b' prefix means binary or bitwise. I could also write it as:

Code:
bnk0 = extram[0..7]:['h'00];

Use whatever is most understandable to you.

During your logic creation/edit/compile workflow, I suggest you not assign pin numbers to anything except the clock inputs
(GCLK1 for PHI1 and GCLK2 for PHI2 it what I use) and reset, if being used (connect that to GCLR). Let the fitter work out
the rest of the pins for you and concentrate on getting your logic correct. The fitter will distribute pin assignments as
needed to make the best usage of the CPLD's logic resources and avoid I/O combinations on any one macrocell that would exceed
the available PTs. If you insist on assigning all pins yourself then you will have to be prepared to study the CPLD's structure
in detail to determine how to distribute your logic and avoid running out of PTs with a particular macrocell.
*/



/*  Octal latch with D and clock inputs, D is passed to Q on  low, latch on clk high */

/* extram[0..7] is buried logic (pins). we'll be using these for the latch and feeding them with D0..7 inputs */

/* define inputs */
pin 2 = PHI1;
pin [4,5,6,8,9,10,11,15] = [D0..7];

/* define outputs */
pin = [A16..23];         /* A16..23 pin declaration. not defining the pins (i.e. PIN = A[16..23]) is useful for debug/testing */

/* define intermediates */
pinnode = [extram0..7];      /* declare 'extram[0..7] as being buried in logic, not as I/O pins */
pinnode = bnk0;         /* delcares bnk0 as being buried logic, not as I/O pin */

/* latch logic */
[extram0..7].LE = PHI1;      /* extram0..7 latch when PHI1 is high */
[extram0..7].L  = [D0..7];      /* extram0..7 latch inputs are set to D0..7 */
[A16..23] = [extram0..7];

/* bank0 handling */
bnk0 = [extram0..7]:['h'00];   /* make bnk0 true if extram0..7 becomes 0 */

The above is hard to read. How about if you attach your actual .PLD file without all the extraneous commentary.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 18, 2021 6:11 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Sorry - edited the post to get rid of the extra stuff - I usually do that to make notes later but forgot to remove it.

[edit] Attached PLD file without the page of commentary :mrgreen: :
Attachment:
OctalDlatch.zip [1003 Bytes]
Downloaded 93 times


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 19, 2021 2:13 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8480
Location: Midwestern USA
banedon wrote:
Sorry - edited the post to get rid of the extra stuff - I usually do that to make notes later but forgot to remove it.

[edit] Attached PLD file without the page of commentary :mrgreen: :
Attachment:
OctalDlatch.zip

I'll give it a look and get back to you.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 19, 2021 8:21 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8480
Location: Midwestern USA
banedon wrote:
Sorry - edited the post to get rid of the extra stuff - I usually do that to make notes later but forgot to remove it.

[edit] Attached PLD file without the page of commentary :mrgreen:

Please see the attached, containing your logic source file, a simulation file and the rest of the entourage. I suggest you compile and simulate it without any editing to verify it's all working. You can then play around with it—but be sure to make a backup copy...just in case.

After a successful compile, you should read the .FIT file for details on how the fitter synthesized your design into the CPLD. Also, read the .PIN file for a complete list of pin assignments.

Some things to watch for in CUPL. Although the language is supposedly case-sensitive, two variables with identical names but opposite cases will confuse the compiler.

Secondly, in the header of the source file, the field named Revision was named Rev. You can omit header fields. However, I don't advise renaming fields, as neither the compiler or simulator will like it.

I reduced the scope of your source file to four bits of extended address decoding (A16-A19) so it would be easier for you to see how selection of the different RAMs is done based upon the effective address. Once it's all clear to you you can fix it up to handle all eight bits of extended addressing.

There are notes in the file to explain some of what I did. :D Also, some belatedly-discovered typos in the comments, but not in the source code. :oops:

Attachment:
banedon.zip [26.03 KiB]
Downloaded 98 times

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 19, 2021 4:00 pm 
Offline

Joined: Fri Jul 09, 2021 10:12 pm
Posts: 741
BigDumbDinosaur wrote:
[color=#000000]
kernelthread's above example will compile and should correctly simulate, but doesn't take advantage of the 1504's extensive buried logic capabilities, which if correctly used, will greatly help performance and conserve logic resources.

That's interesting, that its better to use buried logic in addition to outputs, do you have any more information on what effect it has and when to do it? Is it just generally bad to use output values as inputs at all?


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

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: