If going with smart/smartx/smarty what about smartrd (smart read) instead of getsmart (BTW its 8 chars and IIRC we are limited to 7).
smart/smartx/smarty could also be smartwr/smartwx/smartwy too.
Instead of smart, perhaps spin (oops??) or ipin (oops??)
RD and WR make sense as prefix, but 'smart' is just too long to fit.
Pin is too close to Physical Pin, so I think that only leaves Cell, from the destination name of Smart Pin Cell
SMRT
SMRTx
SMRTy
and finally my favorite
WTF
( for development purposes only)... to be replaced by GetIT in the PG-13 version, since what IT is is whatever we asked for in the first place
Just tried COGATN... works perfectly //really cuts down on all of the mental gymnastics to match clocking in parallel cogs, really nice.
Hmm, KERNEL32.DLL is get an "access violation" trying to write to address $485C02 when it opens the comport on a CTRL-G. The "Checking COM1" window appears but nothing further happens. Doesn't matter if the comport exists or not, both the fault and target address are always the same.
Tried on both WinME in a VM and Win98SE that was on an old laptop.
They work, I can get a blinky tx led without problem on both platforms. Although I did learn the VM had the wrong config type in the process. Had to be set to raw file rather than device. But that didn't have any impact on Pnut outcome. EDIT: Device was the correct setting after all. I've now got the two talking with terminal typing through the comports. WinME on the VM in Linux using a USB UART and the laptop using it's built-in comport with native Win98SE install.
And without changing anything I can quit the terminal program and run up PNut and ctrl-G still gives the same $485c02 write address fault from kernel32.dll.
I can't actually connect the FT231X in the Prop123-A9 board to the old Win98 laptop. There is no driver for it. I'm using a physical comport to test on there.
Luckily Linux automatically sorts that out for the VM so WinME just thinks it's a real comport.
I just posted a new v9b which includes increased FIFOs for all implementations, to cover worst-case FIFO requirements.
These FIFO's have grown pretty big and on the 16-cog version, they are as big as smart pins. I contacted OnSemi this morning about getting a small dual-port SRAM instance from them that would handle this requirement a lot more gracefully. We need a 32-location by 36-bit dual-port SRAM. This would save a lot of logic on the FPGA, too, as there are plenty of unused RAM resources we could tap, instead of the logic fabric.
Did you have to change the 16-cog fifo? I thought it was only the smaller ones that needed fixing...
From my simulation, I learned that everything was deficient. I just didn't ever stress the design sufficiently to break it. The simulator I made using a Prop1 would do random read bursts and rests to really bang things end to end. After a few seconds of simulation, you find out what the requirements are. Randomness is great to use in tests where the system is complex and hard to qualify.
All I know is that it held up well with constant streaming from a PropCam. Since the last release, I have seen an address get screwed up after several hours, but wrote it off to my teeny WIn10 computer ... which loses it's graphics driver if I leave too much running ... My thought was that it must be doing something to distract my P2 at the same time. Not my best thought:)
If the idea to parameterized the model had come from the community... the average response would have been
"are you nuts?"
Thankfully, you did it before anyone could put their coffee down:)
Just amazing.
Here is an experiment. Go to bed early tonight, think nothing except about this issue until you fall asleep.
Report back to us if it worked.
There are many famous people that when asked..."how did you do that?" The response was... it came to me in my sleep.
But you have to clear your mind and try to think only about the problem.
The symptom occurs in the screen write. The way it looked was that the screen was correct except that what was being displayed was being slowly scrolled to the bottom... as though the screens base address was being indexed by 320, (NTSC,320x240, gray). SO... it appears that occasionally, when I index the line to the next line... somehow that index is being applied to the screen's base address.
This doesn't happen right away... it takes several hours for it to show up. Today, I started the P2 working, went to 5 different locations 60 miles apart hunting for frogs. I finally found a frog, went home, cleaned the old tank, scrubbed the refrigerator and finally sat down to check in and the screen was just beginning to scroll. It doesn't wrap:) when it gets to the bottom it then just fills the screen with what look to be alien transmissions. One variable getting indexed wrong after hundreds of thousands of correct values. I'm glad you understand it:)
I should have thought to do a simulation the first time around. It would have saved a lot of headaches.
I thought I had a sure solution, but never realized its fault until I tried to scale it for fewer cogs and then couldn't figure out HOW to think about it. That's when I figured I should just simulate it under extreme conditions.
Reluctantly, I made a Simulator using a Prop1, just because I know that Spin doesn't do weird things with binary, and so the simulation could be straightforward.
When I simulated the initial design, I was surprised to find the FIFO level, which should always be at least 1, dropping to -5 in some cases. Yowza! I never knew that could happen.
So, it turns out that the "full" level needed to be #cogs + 6 (not #cogs, as I had it). The total number of levels needed is therefore #cogs + 11, or 5 more than the "full" level. The 5 comes from the hub latency. Once the hub is "full" and the cog quits issuing reads, five more read results pile into the FIFO, over the next 5 clocks.
Comments
I also added BeMicro CV (A2) support. Those boards, at under $50, are the cheapest way to try out the Prop2.
I hope you all can test out the smart pin modes, as well as hub exec, on these new reduced-eggbeater configurations.
Thanks!
BeMicro CV-A2 is alive now too.
wrspcx
wrspcy
rdspc
ackspc
SMRTx
SMRTy
and finally my favorite
WTF
( for development purposes only)... to be replaced by GetIT in the PG-13 version, since what IT is is whatever we asked for in the first place
Just tried COGATN... works perfectly //really cuts down on all of the mental gymnastics to match clocking in parallel cogs, really nice.
It looks like the paid version supports multiprocessors.
Does compile time scale well with # processors?
Unless their license changed, I think you can also get multiprocessor mode if you turn on talkback, or whatever it's called.
Doesn't sound worth it:
https://www.altera.com/support/support-resources/knowledge-base/solutions/rd03222007_376.html
The paid one has a few extra features that you don't really need, but it doesn't work any better than the free one, in my experience.
Any chance PNut_v9a.exe works under Win98/ME?
It should. It's written in a 20-year-old version of Delphi.
Delphi rules !
Tried on both WinME in a VM and Win98SE that was on an old laptop.
And without changing anything I can quit the terminal program and run up PNut and ctrl-G still gives the same $485c02 write address fault from kernel32.dll.
Luckily Linux automatically sorts that out for the VM so WinME just thinks it's a real comport.
These FIFO's have grown pretty big and on the 16-cog version, they are as big as smart pins. I contacted OnSemi this morning about getting a small dual-port SRAM instance from them that would handle this requirement a lot more gracefully. We need a 32-location by 36-bit dual-port SRAM. This would save a lot of logic on the FPGA, too, as there are plenty of unused RAM resources we could tap, instead of the logic fabric.
From my simulation, I learned that everything was deficient. I just didn't ever stress the design sufficiently to break it. The simulator I made using a Prop1 would do random read bursts and rests to really bang things end to end. After a few seconds of simulation, you find out what the requirements are. Randomness is great to use in tests where the system is complex and hard to qualify.
Did you ask about Flash or Eeprom?
All I know is that it held up well with constant streaming from a PropCam. Since the last release, I have seen an address get screwed up after several hours, but wrote it off to my teeny WIn10 computer ... which loses it's graphics driver if I leave too much running ... My thought was that it must be doing something to distract my P2 at the same time. Not my best thought:)
If the idea to parameterized the model had come from the community... the average response would have been
"are you nuts?"
Thankfully, you did it before anyone could put their coffee down:)
Just amazing.
Here is an experiment. Go to bed early tonight, think nothing except about this issue until you fall asleep.
Report back to us if it worked.
There are many famous people that when asked..."how did you do that?" The response was... it came to me in my sleep.
But you have to clear your mind and try to think only about the problem.
The symptom occurs in the screen write. The way it looked was that the screen was correct except that what was being displayed was being slowly scrolled to the bottom... as though the screens base address was being indexed by 320, (NTSC,320x240, gray). SO... it appears that occasionally, when I index the line to the next line... somehow that index is being applied to the screen's base address.
This doesn't happen right away... it takes several hours for it to show up. Today, I started the P2 working, went to 5 different locations 60 miles apart hunting for frogs. I finally found a frog, went home, cleaned the old tank, scrubbed the refrigerator and finally sat down to check in and the screen was just beginning to scroll. It doesn't wrap:) when it gets to the bottom it then just fills the screen with what look to be alien transmissions. One variable getting indexed wrong after hundreds of thousands of correct values. I'm glad you understand it:)
I should have thought to do a simulation the first time around. It would have saved a lot of headaches.
I thought I had a sure solution, but never realized its fault until I tried to scale it for fewer cogs and then couldn't figure out HOW to think about it. That's when I figured I should just simulate it under extreme conditions.
Reluctantly, I made a Simulator using a Prop1, just because I know that Spin doesn't do weird things with binary, and so the simulation could be straightforward.
When I simulated the initial design, I was surprised to find the FIFO level, which should always be at least 1, dropping to -5 in some cases. Yowza! I never knew that could happen.
So, it turns out that the "full" level needed to be #cogs + 6 (not #cogs, as I had it). The total number of levels needed is therefore #cogs + 11, or 5 more than the "full" level. The 5 comes from the hub latency. Once the hub is "full" and the cog quits issuing reads, five more read results pile into the FIFO, over the next 5 clocks.
At my age, I'm not jealous of much... but for you, I make an exception.
Thanks,
Rich