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

All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: MORE WINCUPL SHENANIGANS
PostPosted: Mon Nov 28, 2022 7:07 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
I really wish the fine folks at Microchip would invest a little time in fixing the numerous bugs in WinCUPL. One of those bugs seems to be out to get me with a vengeance.

The attached file appears to be clean and will compile in the sense that the compiler itself doesn’t spit out any diagnostics. However, the .FIT file has no useful information in it and no .JED file is produced. Removing the pin number assignments for all but GCLK, PHI2 and RESB has no effect. Removing even those assignments has no effect.

It's enough to make me want to throw away anything to do with programmable logic and stick with discrete gates. :twisted:

Attachment:
File comment: CUPL File That Doesn’t Work
clocking.txt [12.14 KiB]
Downloaded 92 times

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 28, 2022 9:16 pm 
Offline

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166
Are 'extram' and 'vab' meant to be registered? I'm guessing not. If you delete lines 184 and 186:

# extram.AR = !RESB; don't want this
[hmu0..1].AR = !RESB;
# vab.IOAR = !RESB; or this
wstimer.AR = !RESB;

it compiles and produces a JED file.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2022 8:53 am 
Offline

Joined: Sun Jun 29, 2014 5:42 am
Posts: 352
BigDumbDinosaur wrote:

It's enough to make me want to throw away anything to do with programmable logic and stick with discrete gates. :twisted:

In these cases where the fitter fails early due to design errors, running the fitter manually from the command prompt allows you to see the error:
Attachment:
clocking1.png
clocking1.png [ 45.35 KiB | Viewed 4979 times ]

Commenting out just the following line gets rid of the error:
Code:
//   vab.IOAR     = !RESB;

Hope this helps...

Dave


Top
 Profile  
Reply with quote  
 Post subject: MORE WINCUPL SHENANIGANS
PostPosted: Tue Nov 29, 2022 4:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
kernelthread wrote:
Are 'extram' and 'vab' meant to be registered? I'm guessing not.

extram latches A16, which is why it is registered. I removed the pinnode declaration for vab and am treating vab as an ordinary variable. The design now compiles and fits, and a JEDEC fuse map is being generated.

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 29, 2022 4:53 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
hoglet wrote:
Commenting out just the following line gets rid of the error:
Code:
//   vab.IOAR     = !RESB;

Hope this helps...

See my above reply. Not sure what I was thinking when that got into the source file. vab was supposed to just be an intermediate variable so I didn’t have to keep typing VDA # VPA. :D

_________________
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  [ 5 posts ] 

All times are UTC


Who is online

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