Almost all synthesized designs these days will run at down to a 0 clock rate. The tough part of getting a design to work is to meet all the hold times, which comes into play with a clocking system where there are multiple buffers in the path trying to balance the whole thing. Something that would take a human, years to accomplish. Once the hold times are met for whatever the target speed is, they are automatically met for slower.
The only exception might be in the memories, if there are pre-charge type sense amps, and often those will have a minimum cycle time. These memories were apparently done by hand. They may be completely static designs, that is a question for Chip. If they are completely static, they would run down to very slow rates.
This got me wondering whether it will be more energy-efficient to run 4 cogs at 40 MHz or run one cog (with 4 tasks) at 160 MHz. If a faster clock with fewer cogs is more efficient, I could easily see people using tasks for that reason alone.
And, following up on that, is there any way to start a COG up without resetting it? I could imagine a COG stopping itself to save power, then having another COG start it back up again (from the next instruction after the COGSTOP). I suppose you could do something similar by using WAITPEQ on PortD, but I have to imagine that halting a COG altogether would be more energy-efficient.
Almost all synthesized designs these days will run at down to a 0 clock rate. The tough part of getting a design to work is to meet all the hold times, which comes into play with a clocking system where there are multiple buffers in the path trying to balance the whole thing. Something that would take a human, years to accomplish. Once the hold times are met for whatever the target speed is, they are automatically met for slower.
The only exception might be in the memories, if there are pre-charge type sense amps, and often those will have a minimum cycle time. These memories were apparently done by hand. They may be completely static designs, that is a question for Chip. If they are completely static, they would run down to very slow rates.
The design is fully static, both the synthesized logic and our memories. It can run down to 0Hz.
Last night (this morning), I got the Verilog done with everything except a synchronous transceiver, which I'll address next.
I discovered some ways to speed up a few of the most critical paths, so timing is closing faster now, with no paths consistently sticking out as critical. The Verilog from the last full-chip attempt was compiling on the Cyclone IV FPGAs with an Fmax of 60MHz. With all the latest enhancements it's now hitting 73MHz, which is about a 22% improvement. I'm confident that this will synthesize well for the ASIC. I think it might be realistic to get 200MHz (worst case) on the real silicon using OnSemi's fast 180nm process.
I've got to make a bunch of documentation changes and then I'll post the new FPGA configuration files for the DE0-Nano and DE2-115 boards.
The new pixel-math instructions make photo-realistic graphics with a little bit of programming. I'll try to get a picture on here today.
Last night (this morning), I got the Verilog done with everything except a synchronous transceiver, which I'll address next.
I discovered some ways to speed up a few of the most critical paths, so timing is closing faster now, with no paths consistently sticking out as critical. The Verilog from the last full-chip attempt was compiling on the Cyclone IV FPGAs with an Fmax of 60MHz. With all the latest enhancements it's now hitting 73MHz, which is about a 22% improvement. I'm confident that this will synthesize well for the ASIC. I think it might be realistic to get 200MHz (worst case) on the real silicon using OnSemi's fast 180nm process.
I've got to make a bunch of documentation changes and then I'll post the new FPGA configuration files for the DE0-Nano and DE2-115 boards.
The new pixel-math instructions make photo-realistic graphics with a little bit of programming. I'll try to get a picture on here today.
The pixel math instructions with be nice for doing visualizations of data too.
I know the first run fails sucked, but the changes and additions we're ending up with as a result are really excellent and could help the chip stand out even more against others....
I don't know, for this round. It's been shorter because I've got a sinus infection and the kids and wife have the flu. Last night, I was happy to go to bed at 4:00am after getting everything cleaned up and proven.
Does OnSemi have any process block to do a 1% or better oscillator or able to be trimmed? Would be nice to be able to achieve a 1% clock without a crystal.
The Verilog from the last full-chip attempt was compiling on the Cyclone IV FPGAs with an Fmax of 60MHz. With all the latest enhancements it's now hitting 73MHz, which is about a 22% improvement. I'm confident that this will synthesize well for the ASIC. I think it might be realistic to get 200MHz (worst case) on the real silicon using OnSemi's fast 180nm process.
I've got to make a bunch of documentation changes and then I'll post the new FPGA configuration files for the DE0-Nano and DE2-115 boards.
Once that is put to bed, it could be interesting to run a synth pass targeting the new Cyclone V's ?
Devices like 5CEFA2F23C8N & 5CGXFC5C6F27C7N, have $42 and $179 Eval Board price points, with more RAM.
Last night (this morning), I got the Verilog done with everything except a synchronous transceiver, which I'll address next.
I discovered some ways to speed up a few of the most critical paths, so timing is closing faster now, with no paths consistently sticking out as critical. The Verilog from the last full-chip attempt was compiling on the Cyclone IV FPGAs with an Fmax of 60MHz. With all the latest enhancements it's now hitting 73MHz, which is about a 22% improvement. I'm confident that this will synthesize well for the ASIC. I think it might be realistic to get 200MHz (worst case) on the real silicon using OnSemi's fast 180nm process.
I've got to make a bunch of documentation changes and then I'll post the new FPGA configuration files for the DE0-Nano and DE2-115 boards.
The new pixel-math instructions make photo-realistic graphics with a little bit of programming. I'll try to get a picture on here today.
Totally awesome news/work Chip as always!
Looking forward to playing with the new update, and ultimately the final chip, especially at 200Mhz, with all that it was before the changes, let alone the new awesome mods you've done!
Much kudos, and get well soon bud!
I've got the Verilog into a nice place. I'd say it's about perfect, barring the SERDES issue. It compiles well for the DE0-Nano and the DE2-115.
I'm still working on the documentation file, as many things need attention there. The assembler is working great, and there is one minor thing I plan on adding now.
Hopefully, in the next three days, I'll have the update out.
Thanks for the update Chip. Sounds great.
Hope you and the family have fully recovered.
Thanks. We're all fine now. I need to start running again, though, as it helps clear the brain and makes all problems seem small and manageable. When I drift out of shape, work starts to seem insurmountable. Things are under pretty good control now, however. All my working files are clean and free of fix-it notes to myself. I just need to get these doc's done, get it out to you guys, and get back on the full-custom circuitry so that Beau can tweak things for OnSemi's process.
Thanks. We're all fine now. I need to start running again, though, as it helps clear the brain and makes all problems seem small and manageable. When I drift out of shape, work starts to seem insurmountable. Things are under pretty good control now, however. All my working files are clean and free of fix-it notes to myself. I just need to get these doc's done, get it out to you guys, and get back on the full-custom circuitry so that Beau can tweak things for OnSemi's process.
Thanks. We're all fine now. I need to start running again, though, as it helps clear the brain and makes all problems seem small and manageable. When I drift out of shape, work starts to seem insurmountable. Things are under pretty good control now, however. All my working files are clean and free of fix-it notes to myself. I just need to get these doc's done, get it out to you guys, and get back on the full-custom circuitry so that Beau can tweak things for OnSemi's process.
It's really nothing big. There are about 22 instructions which read S and write D (as opposed to modify D). These are basically unary operations dressed up as MOV's. Because we had plenty of 'D,S' opcode space, they were made more flexible, with two operands. What I'm going to do is make the assembler accommodate the case of only ONE operand, so that if you want to do an INCPAT on a single register, you can just do 'INCPAT D', instead of 'INCPAT D,D'. I probably just spent more time explaining it than it will take to accomplish. It's just a little enhancement to make PASM more writable and readable.
Comments
P1 works like this, and at low power too. But, those are Chip's polygons, designed with that in mind. I'm not sure the synthesis does that.
The only exception might be in the memories, if there are pre-charge type sense amps, and often those will have a minimum cycle time. These memories were apparently done by hand. They may be completely static designs, that is a question for Chip. If they are completely static, they would run down to very slow rates.
-Phil
The design is fully static, both the synthesized logic and our memories. It can run down to 0Hz.
I discovered some ways to speed up a few of the most critical paths, so timing is closing faster now, with no paths consistently sticking out as critical. The Verilog from the last full-chip attempt was compiling on the Cyclone IV FPGAs with an Fmax of 60MHz. With all the latest enhancements it's now hitting 73MHz, which is about a 22% improvement. I'm confident that this will synthesize well for the ASIC. I think it might be realistic to get 200MHz (worst case) on the real silicon using OnSemi's fast 180nm process.
I've got to make a bunch of documentation changes and then I'll post the new FPGA configuration files for the DE0-Nano and DE2-115 boards.
The new pixel-math instructions make photo-realistic graphics with a little bit of programming. I'll try to get a picture on here today.
I know the first run fails sucked, but the changes and additions we're ending up with as a result are really excellent and could help the chip stand out even more against others....
@Roy: I think so too. This adventure really did get us good optimization information. Good times ahead.
Good news on the static design. Not sure where I heard otherwise...
Does OnSemi have any process block to do a 1% or better oscillator or able to be trimmed? Would be nice to be able to achieve a 1% clock without a crystal.
You the man Chip!
Once that is put to bed, it could be interesting to run a synth pass targeting the new Cyclone V's ?
Devices like 5CEFA2F23C8N & 5CGXFC5C6F27C7N, have $42 and $179 Eval Board price points, with more RAM.
(read the later messages too - get better soon (you, and your whole family))
Though at this point I'd be happy just to get my hands on any P2 chip regardless.
Keep up the good work everyone!
Looking forward to playing with the new update, and ultimately the final chip, especially at 200Mhz, with all that it was before the changes, let alone the new awesome mods you've done!
Much kudos, and get well soon bud!
I'm still working on the documentation file, as many things need attention there. The assembler is working great, and there is one minor thing I plan on adding now.
Hopefully, in the next three days, I'll have the update out.
Thanks for you patience, Everyone.
Hope you and the family have fully recovered.
Thanks. We're all fine now. I need to start running again, though, as it helps clear the brain and makes all problems seem small and manageable. When I drift out of shape, work starts to seem insurmountable. Things are under pretty good control now, however. All my working files are clean and free of fix-it notes to myself. I just need to get these doc's done, get it out to you guys, and get back on the full-custom circuitry so that Beau can tweak things for OnSemi's process.
Nice news.
That's great Chip!
We're all excited out here in P2 land!
Way to go as always. Looking forward to "tasting" the fruit!
Propeller 2 is important... but family is even more important
It's really nothing big. There are about 22 instructions which read S and write D (as opposed to modify D). These are basically unary operations dressed up as MOV's. Because we had plenty of 'D,S' opcode space, they were made more flexible, with two operands. What I'm going to do is make the assembler accommodate the case of only ONE operand, so that if you want to do an INCPAT on a single register, you can just do 'INCPAT D', instead of 'INCPAT D,D'. I probably just spent more time explaining it than it will take to accomplish. It's just a little enhancement to make PASM more writable and readable.