6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 4:05 am

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: CUPL of woes
PostPosted: Thu Oct 18, 2018 9:14 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
cbscpe wrote:
There is no solution. Eigth 8-bit registers require all 64 macrocells. Each output also requires a macrocell. It wonˋt fit. I would reduce the number of bits in each register.


It seems that way, but the datasheet also claims a macrocell can have a combinatorial output with a buried registered feedback, which implies you can overlap the register with a non-registered output in a single macrocell.

From page 6 of the ATF1504AS datasheet: "Selecting the separate product term allows creation of a buried registered feedback within a
combinatorial output macrocell."

If this is possible, I am not ready to give in yet. It may be that it will require some deeper study of the intermediate processes to get this to work, though.

Daryl

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


Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Fri Oct 19, 2018 4:25 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Last night, I started a new layout. I added 8 registers assigned to the first 8 macrocells. These will represent bit 0 of the 8 register bank. I then added d0 for the input, and ma0 for the first stage of the register decoding (2 registers only). I also have the global reset, mclk, and the CE logic (including the rw and cs input that were not included in logic on the original design file). I successfully fit this design AND have validated that I can assign a buried node and have a combinatorial output in one macrocell.

I then added ma1 to the register decoding, which gives me a 1 of 4 decoding. This failed to fit it as written, but the fitter's second pass overrides the preset pin assignments and moves the macrocell assignments to make it fit. So what happened? It looks like the total product term count for macrocell 1 is at 5 (the maximum) and this prevents the use of the foldback path. Why is the foldback path needed? This allows for distributing of AND product terms back to inputs for building more complex logic. One of the problems facing this design is the ultimate use of 8 OR's with each output. The OR on the output of the PTMatrix only supports 5 inputs. You can gang adjacent macrocells within the logic block to increase this output, but the fitter rarely uses that option for some reason. I've seen the fitter generate a series of inverse ANDs that are then ANDed and inverted to generate the OR function. ( C = A OR B is the same as !C = !A AND !B). But, the foldback path is used to distribute these intermediate AND functions.

Even with the limited amount of product terms at each macrocell, I believe this design should fit. It will need almost every product term, and really max out the capacity of the chip, but it should fit. However, it will take more time than I can afford to unravel the internals. There could be some undocumented limitations also that are causing the fitter to act the way it does.

I will move on to working on my 65SPI conversion. I may continue to study this design further, but don't expect any real results in the foreseeable future.

Daryl

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


Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Sun Oct 21, 2018 6:49 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
8BIT wrote:
cbscpe wrote:
There is no solution. Eigth 8-bit registers require all 64 macrocells. Each output also requires a macrocell. It wonˋt fit. I would reduce the number of bits in each register.


It seems that way, but the datasheet also claims a macrocell can have a combinatorial output with a buried registered feedback, which implies you can overlap the register with a non-registered output in a single macrocell.

From page 6 of the ATF1504AS datasheet: "Selecting the separate product term allows creation of a buried registered feedback within a
combinatorial output macrocell."

If this is possible, I am not ready to give in yet. It may be that it will require some deeper study of the intermediate processes to get this to work, though.

Daryl

Looking at the diagram this should be possible but the fitter does not seem to support it. But still we do not know if the matrix supports this combination. My experience is no.

The total number of PT per macro cell is 5. But if you use output enable, clock or asynchronous reset one of the PT is used for it, which leaves you with 4 PT for combinatorial logic.. There is one exception to it, those are the global inputs for CLK, OE and CLR, if you use one of the signals associated to the global CLK, OE or CLR inputs none of the 5 PT is used to control the MC.

Also as the ATF have no output signal routing layer care must be taken to which output pins you assign the signals. E.g. if you have an output wich is adjacent to a burried MC then "cascade logic" can combine the PT of the output MC and the adjacent MC (the one with the lower number) and hence you can use 10 PT for the MC with the output. But this works only if only one equation uses more than one PT.

Perhaps you should upload your design files, then I could better explain what happens. The fitter output only shows what he think is his optimum, however this might not be the optimum. Many samples delivered with WinCUPL use special tricks to overcome the fitters deficiencies.


Peter


Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Sun Nov 04, 2018 1:46 am 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 362
Thank you both for continuing to look into it - I've been away on holiday for the last three weeks, hence my silence, and equally consequently I've not done any further work on the problem myself. I'm OK with having to reduce the number of bits if necessary, I'm just feeling very irritated that it seems like it should be possible, but doesn't seem to actually be so.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.


Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Sun Nov 04, 2018 4:57 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
I hope your vacation was fun. I have not had time lately to work on this more either. As Peter wrote, i think it can be done, it will just take some custom code to convince the software that the hardware can hold it.

Daryl

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


Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Sat Nov 17, 2018 6:01 pm 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 362
So, I've had another go at this, and decided that in order to make it fit I had two choices - reduce the number of registers, or reduce the bits in the registers. Both have their trade-offs: in the former case, less granulity, and in the latter, less pages (and thus address space) in total. I decided to go for the former approach, so this chip allows 4 windows instead of the previously intended 8. Each window is capable of addressing 256 pages. If the windows were 16KiB each (i.e. one quarter of the 64KiB 6502 address space) then that gives a total address space of 4MiB.

Whilst this code does compile, and I'm mostly happy with it, I do have a few concerns:
1. In the fitter report, it says "## ERROR : Bad user pin assignement : 45". This doesn't seem to stop it compiling, or indeed generating a JEDEC file, but it is concerning.
2. It only compiles if I set "LOGIC_DOUBLING" to "OFF". This isn't necessarily an issue in itself, it just seems odd to me that it would fail to compile when an optimisation option is on, but not vice-versa.
3. I couldn't find anywhere in the documentation anything which says how the .LE suffix actually works - is the latch transparent when .LE is high or when it is low?

I'm working on a WinSim vector file now to check simulated functionality.


Attachments:
File comment: MMUC fitter report
MMUC-fit.txt [26.74 KiB]
Downloaded 99 times
File comment: MMUC compiling CUPL code
MMUC-pld.txt [3.48 KiB]
Downloaded 117 times

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.
Top
 Profile  
Reply with quote  
 Post subject: Re: CUPL of woes
PostPosted: Sun Nov 18, 2018 2:30 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Alarm Siren wrote:
3. I couldn't find anywhere in the documentation anything which says how the .LE suffix actually works - is the latch transparent when .LE is high or when it is low?

Here's example code:

Code:
/*
======================
A16-A19 LATCHING LOGIC
======================
*/
bavalid         = vab & !PHI2;                    /* true if bank address valid  */
[blatch0..3].LE = bavalid & !wsext;               /* open latches, unless in wait-state */
[blatch0..3].L  = [D0..3] & bavalid & !wsext;     /* capture bank, unless in wait-state */

The key is the expression bavalid & !wsext (vab is true when the 65C816 says the address is valid). If the expression bavalid & !wsext is true the latches will open. Otherwise, they will be closed. It's that simple.

Everything in programmable logic is based on true/false, not a voltage level. Voltage level only gets into the picture when you tell WinCUPL that an input or output is inverted by declaring the pin name with a preceding !, such as !WD. When you write your code think in terms of true or false, not high or low.

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


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

All times are UTC


Who is online

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