6502.org http://forum.6502.org/ |
|
Octal D latch on ATF1508AS http://forum.6502.org/viewtopic.php?f=10&t=6694 |
Page 1 of 2 |
Author: | banedon [ Sat Jul 17, 2021 10:59 pm ] |
Post subject: | Octal D latch on ATF1508AS |
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]); |
Author: | kernelthread [ Sun Jul 18, 2021 12:47 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 */ |
Author: | BigDumbDinosaur [ Sun Jul 18, 2021 6:49 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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. |
Author: | banedon [ Sun Jul 18, 2021 7:26 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 ... 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' ******** |
Author: | BigDumbDinosaur [ Sun Jul 18, 2021 8:11 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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. |
Author: | banedon [ Sun Jul 18, 2021 8:19 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
Sorry BDD I didn't see you post there. I'll have a read of yours then respond. |
Author: | banedon [ Sun Jul 18, 2021 10:18 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
Thanks BDD - especially for the explanation as to what does what. |
Author: | gfoot [ Sun Jul 18, 2021 11:44 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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. |
Author: | banedon [ Sun Jul 18, 2021 11:50 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 |
Author: | banedon [ Sun Jul 18, 2021 5:21 pm ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 */ |
Author: | BigDumbDinosaur [ Sun Jul 18, 2021 6:00 pm ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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. |
Author: | banedon [ Sun Jul 18, 2021 6:11 pm ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 : Attachment:
|
Author: | BigDumbDinosaur [ Mon Jul 19, 2021 2:13 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 : Attachment: OctalDlatch.zip I'll give it a look and get back to you. |
Author: | BigDumbDinosaur [ Mon Jul 19, 2021 8:21 am ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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 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. Also, some belatedly-discovered typos in the comments, but not in the source code. Attachment:
|
Author: | gfoot [ Mon Jul 19, 2021 4:00 pm ] |
Post subject: | Re: Octal D latch on ATF1508AS |
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? |
Page 1 of 2 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |