Sorry I've been absent for a while. I've been working on P2 and have been off the forums.
Baggers emailed me and told me a mutiny could be in progress. I've skimmed the last ~30 posts and see there's lots of bickering going on.
Everything has been taking longer than anticipated. Most of my time in the last three months has been spent massaging our schematic in ridiculous ways so that when we export it from our Tanner tools in EDIF format and it gets imported into Treehouse's Cadence system, it isn't complete garbage. EDIF is a tenuously-supported exchange format that nobody seems particularly dedicated to making work between platforms. A vendor is more inclined to make an EDIF import than an export work so that customers come their direction, not their competitor's. Anyway, our schematic initially showed up on Treehouse's end as a mishmash of ports piled on top of themselves with misaligned/mis-sized component labels, etc. I've had to add wires to all ports and replace port names with labels and show the ports once on each schematic sheet. All this need came after I redid all schematics to a 10-based grid from my original 2^n grid and also replaced all component symbols from my own to OnSemi's (which vary between Tanner and Cadence setups!) Treehouse now has LVS working on their end, but the visual is still messy. Tanner has been helping us a lot by developing a special script that processes their current EDIF output so that Cadence can better ingest it. Right now, we have a problem we are trying to resolve where all above-bottom-level schematic blocks are showing ports where there should be just labels, causing complete unreadability. Hopefully, this gets fixed soon. These sporadic 3-week detours back into schematic land have cost me a lot of time. It takes days for me to spool back up where I left off on the Verilog, afterwards.
At this time, I'm back on the Verilog and I've got the instruction set completed. I'm just arranging opcodes now so that they make optimal sense to me and future observers, and are efficient to decode. There is a full 'D/#,S/#' instruction space left empty for those who will modify the Verilog for their own purposes, as well as lots of 'D/#' instruction spaces. As soon as I think this is complete, I will post it. Once that is done, I'll need to spend a few weeks going through everything and making efficiency optimizations. I think it's all pretty clean, already, but I'll feel a lot more confident after I've made that effort.
Thank you all for your sustained interest in this project. I think, once we are done, there won't be any disappointment, but we've still got a little ways to go.
That real world stuff sounds like a huge pia:)
Stick to the verilog... it is so much more fun.
I've been full bore p1v for quite a while... nothing but fun. I haven't posted anything for a while, because I've been having a problem with noise on my camera interface. I can plug it into a real P1 and. all of the signals are fine. Plug it into a DE2-115 and all hell breaks loose. I've tried everything and waiting for further inspiration:)
Rich
Hi Chip it's great to hear from you.
That all sounds like a total nightmare. I cannot imagine the complexity of this except from my time years ago working on PCB CAD. I know vendors like to keep their software silos import only. Any gesture towards open interchange is just a token effort to satisfy a bullet point on some marketing blurb.
Never mind all of us whining about the current forum fiasco. That's only fluff that will get fixed.
....And sorry about this new forum software. We know it's a headache and we're trying to make it right.
For those of you who wondered what the "...and" alluded to, I just discovered another feature(?) of this new forum software. Go to the first page in this thread. If you see a newly-posted comment by Chip, look just above at the line stating "341 Comments sorted by" and make sure to click on "Date Added". Now return to page 12 and you should see Chip's prior comment in context.
Anyway, our schematic initially showed up on Treehouse's end as a mishmash of ports piled on top of themselves with misaligned/mis-sized component labels, etc. I've had to add wires to all ports and replace port names with labels and show the ports once on each schematic sheet. All this need came after I redid all schematics to a 10-based grid from my original 2^n grid and also replaced all component symbols from my own to OnSemi's (which vary between Tanner and Cadence setups!) Treehouse now has LVS working on their end, but the visual is still messy. Tanner has been helping us a lot by developing a special script that processes their current EDIF output so that Cadence can better ingest it. Right now, we have a problem we are trying to resolve where all above-bottom-level schematic blocks are showing ports where there should be just labels, causing complete unreadability. Hopefully, this gets fixed soon.
Ouch. Do the designs pass round-trip netlist integrity checks ?
It's Chip's dream, it's his company. I'm glad there are people in the world with such dreams.This is so true, and I too am glad there are people in the world with such dreams, we wouldn't have had the Prop 1 if it wasn't for Chip and Ken and their unique approach, running their company their way, without having the red tape of investors, yes it must be a hell of a lot harder without that multi million dollar investments, but at the end of the day, they can do things however they see fit!
And whenever it comes out, be-it Christmas this year, next year or even the year after ( I hope it's the first one obviously lol ) I'm sure it'll be awesome and a total joy to work with, as the P1 has been.
@cgracey, thank you very much for the very informative newsfeed. Glad to hear the Prop-2 is progressing despite the minor setbacks.
Recognizing that the specs can change in the course of this project, can Parallax give a snapshot at the latest specs (speed, memory, I/Os, ADCs, etc.)?
Ouch. Do the designs pass round-trip netlist integrity checks ?
In the end, we will do an LVS on our side comparing their layout extraction against my original schematic.
Whilst clean visual aspects are a 'nice to have', I'd focus on the round-trip netlist-level checking.Surely someone else can do the visual cleanups, to avoid the Verilog re-start issues ?
@cgracey, thank you very much for the very informative newsfeed. Glad to hear the Prop-2 is progressing despite the minor setbacks.
Recognizing that the specs can change in the course of this project, can Parallax give a snapshot at the latest specs (speed, memory, I/Os, ADCs, etc.)?
There are 16 cogs with 512 longs of cog RAM and 256 longs of lookup table memory.
There is 512KB of hub RAM with sequential byte/word/long-per-clock R/W access from every cog, simultaneously.
There is a scale-corrected pipelined CORDIC that all cogs can use simultaneously. Latency is ~36 clocks. It does scaled SIN/COS (polar to cartesian), rotate (X,Y) around (0,0), arc-tangent (cartesian to polar), LOG, EXP, SQRT, MUL, and DIV. Precision is at least 32 bits for all inputs and results.
There are 64 I/O pins. Each set of 4 I/Os has their own power/ground pad set. Ground is common on the thermal pad of the chip. Each I/O has fast 75-ohm and 1k-ohm DACs, an integrating ADC, a level comparator, and many digital I/O modes.
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
Ouch. Do the designs pass round-trip netlist integrity checks ?
In the end, we will do an LVS on our side comparing their layout extraction against my original schematic.
Whilst clean visual aspects are a 'nice to have', I'd focus on the round-trip netlist-level checking.Surely someone else can do the visual cleanups, to avoid the Verilog re-start issues ?
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.round-trip netlist checks are the same as this : " LVS on our side comparing their layout extraction against my original schematic"ie a non visual, data base level compare, that confirms no dropped, or added nodes.
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.round-trip netlist checks are the same as this : " LVS on our side comparing their layout extraction against my original schematic"ie a non visual, data base level compare, that confirms no dropped, or added nodes.
Oh, I thought you were saying that kind of check was inadequate and there was some other kind of process, but you were just saying to focus on that type of check and not worry about the visual. I understand now. The visual problems had slowed down layout-driven schematic on Treehouse's side. They were clicking on the garbled schematic to get net names and then redrawing it on paper to make sense of it. That was way too tedious for them to be bothering with. It was wasting a lot of their time and costing us more money. That's why I had to redo things the second time.
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
Chip,
You have just reminded me of a statement made my a big boss at Intel during the launch presentation of the Intel i860 in London. The worlds first chip, they said, with a million transistors. He said:
"When you have a million transistors, making sure every every trace is connected to something at both ends is a non-trivial task"
I mean, wow, never mind the complexity of the logic, do the wires have dangling ends on the chip?!
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
I don't see HubExec ?
Oh, yes, hub exec is there, too.Chip,
You have just reminded me of a statement made my a big boss at Intel during the launch presentation of the Intel i860 in London. The worlds first chip, they said, with a million transistors. He said:
"When you have a million transistors, making sure every every trace is connected to something at both ends is a non-trivial task"
I mean, wow, never mind the complexity of the logic, do the wires have dangling ends on the chip?!
All the wires connect to something. This chip, in hub RAM, alone, has over 25 million transistors (512K * 8 bits * 6 transistors per bit).Glad to hear P2 is still going forward.
How much of the full P2 will run on the Propeller 1-2-3 board?
I'll need to conserve on smart pin logic to get 16 cogs to fit. I want that board to run all the cogs, so maybe every pin won't be 'smart'.
I'll need to conserve on smart pin logic to get 16 cogs to fit. I want that board to run all the cogs, so maybe every pin won't be 'smart'.
Does that caveat apply to the final design, or just what is needed to fit in the FPGA on board ?I know Altera recently changed which devices are supported in WebPack - does that make a difference?
I'll need to conserve on smart pin logic to get 16 cogs to fit. I want that board to run all the cogs, so maybe every pin won't be 'smart'.
Does that caveat apply to the final design, or just what is needed to fit in the FPGA on board ?I know Altera recently changed which devices are supported in WebPack - does that make a difference?
It's to fit into the FPGA. If the silicon gets cramped, not every pin would get smarts, either, though.
I just checked Altera's site to find out if they now support the Cyclone V -A9 with Quartus II Web Edition, and they don't, according to a document from last year (2014).
Oh, one other thing...
I had the opcode space to increase the 512KB address range to 1024KB (from 19 to 20 bits).
The silicon will still only have 512KB of RAM, but this extra bits gives some room for future memory increase in denser technologies.
Comments
koehler said:
Rather than rebut, make it personal.
Happily, its not a trend here.
Pretty simple really. You've been rebuked ten times over on every point individually already. You've become a stuck record.
Damn!, this new forum software leaves a bit to be desired. I'm squished into a two line edit window!
Baggers emailed me and told me a mutiny could be in progress. I've skimmed the last ~30 posts and see there's lots of bickering going on.
Everything has been taking longer than anticipated. Most of my time in the last three months has been spent massaging our schematic in ridiculous ways so that when we export it from our Tanner tools in EDIF format and it gets imported into Treehouse's Cadence system, it isn't complete garbage. EDIF is a tenuously-supported exchange format that nobody seems particularly dedicated to making work between platforms. A vendor is more inclined to make an EDIF import than an export work so that customers come their direction, not their competitor's. Anyway, our schematic initially showed up on Treehouse's end as a mishmash of ports piled on top of themselves with misaligned/mis-sized component labels, etc. I've had to add wires to all ports and replace port names with labels and show the ports once on each schematic sheet. All this need came after I redid all schematics to a 10-based grid from my original 2^n grid and also replaced all component symbols from my own to OnSemi's (which vary between Tanner and Cadence setups!) Treehouse now has LVS working on their end, but the visual is still messy. Tanner has been helping us a lot by developing a special script that processes their current EDIF output so that Cadence can better ingest it. Right now, we have a problem we are trying to resolve where all above-bottom-level schematic blocks are showing ports where there should be just labels, causing complete unreadability. Hopefully, this gets fixed soon. These sporadic 3-week detours back into schematic land have cost me a lot of time. It takes days for me to spool back up where I left off on the Verilog, afterwards.
At this time, I'm back on the Verilog and I've got the instruction set completed. I'm just arranging opcodes now so that they make optimal sense to me and future observers, and are efficient to decode. There is a full 'D/#,S/#' instruction space left empty for those who will modify the Verilog for their own purposes, as well as lots of 'D/#' instruction spaces. As soon as I think this is complete, I will post it. Once that is done, I'll need to spend a few weeks going through everything and making efficiency optimizations. I think it's all pretty clean, already, but I'll feel a lot more confident after I've made that effort.
Thank you all for your sustained interest in this project. I think, once we are done, there won't be any disappointment, but we've still got a little ways to go.
Thanks for the update.
That real world stuff sounds like a huge pia:)
Stick to the verilog... it is so much more fun.
I've been full bore p1v for quite a while... nothing but fun. I haven't posted anything for a while, because I've been having a problem with noise on my camera interface. I can plug it into a real P1 and. all of the signals are fine. Plug it into a DE2-115 and all hell breaks loose. I've tried everything and waiting for further inspiration:)
Rich
That all sounds like a total nightmare. I cannot imagine the complexity of this except from my time years ago working on PCB CAD. I know vendors like to keep their software silos import only. Any gesture towards open interchange is just a token effort to satisfy a bullet point on some marketing blurb.
Never mind all of us whining about the current forum fiasco. That's only fluff that will get fixed.
For those of you who wondered what the "...and" alluded to, I just discovered another feature(?) of this new forum software. Go to the first page in this thread. If you see a newly-posted comment by Chip, look just above at the line stating "341 Comments sorted by" and make sure to click on "Date Added". Now return to page 12 and you should see Chip's prior comment in context.
Ouch. Do the designs pass round-trip netlist integrity checks ?
Ouch. Do the designs pass round-trip netlist integrity checks ?
In the end, we will do an LVS on our side comparing their layout extraction against my original schematic.
And whenever it comes out, be-it Christmas this year, next year or even the year after ( I hope it's the first one obviously lol ) I'm sure it'll be awesome and a total joy to work with, as the P1 has been.
Recognizing that the specs can change in the course of this project, can Parallax give a snapshot at the latest specs (speed, memory, I/Os, ADCs, etc.)?
Ouch. Do the designs pass round-trip netlist integrity checks ?
In the end, we will do an LVS on our side comparing their layout extraction against my original schematic.
Whilst clean visual aspects are a 'nice to have', I'd focus on the round-trip netlist-level checking.Surely someone else can do the visual cleanups, to avoid the Verilog re-start issues ?
Recognizing that the specs can change in the course of this project, can Parallax give a snapshot at the latest specs (speed, memory, I/Os, ADCs, etc.)?
There are 16 cogs with 512 longs of cog RAM and 256 longs of lookup table memory.
There is 512KB of hub RAM with sequential byte/word/long-per-clock R/W access from every cog, simultaneously.
There is a scale-corrected pipelined CORDIC that all cogs can use simultaneously. Latency is ~36 clocks. It does scaled SIN/COS (polar to cartesian), rotate (X,Y) around (0,0), arc-tangent (cartesian to polar), LOG, EXP, SQRT, MUL, and DIV. Precision is at least 32 bits for all inputs and results.
There are 64 I/O pins. Each set of 4 I/Os has their own power/ground pad set. Ground is common on the thermal pad of the chip. Each I/O has fast 75-ohm and 1k-ohm DACs, an integrating ADC, a level comparator, and many digital I/O modes.
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
Ouch. Do the designs pass round-trip netlist integrity checks ?
In the end, we will do an LVS on our side comparing their layout extraction against my original schematic.
Whilst clean visual aspects are a 'nice to have', I'd focus on the round-trip netlist-level checking.Surely someone else can do the visual cleanups, to avoid the Verilog re-start issues ?
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.round-trip netlist checks are the same as this : " LVS on our side comparing their layout extraction against my original schematic"ie a non visual, data base level compare, that confirms no dropped, or added nodes.
I guess I don't know what round-trip netlist-level checks are, exactly.
And, no, there's no one else to handle the schematic massaging, but me.round-trip netlist checks are the same as this : " LVS on our side comparing their layout extraction against my original schematic"ie a non visual, data base level compare, that confirms no dropped, or added nodes.
Oh, I thought you were saying that kind of check was inadequate and there was some other kind of process, but you were just saying to focus on that type of check and not worry about the visual. I understand now. The visual problems had slowed down layout-driven schematic on Treehouse's side. They were clicking on the garbled schematic to get net names and then redrawing it on paper to make sense of it. That was way too tedious for them to be bothering with. It was wasting a lot of their time and costing us more money. That's why I had to redo things the second time.
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
I don't see HubExec ?
You have just reminded me of a statement made my a big boss at Intel during the launch presentation of the Intel i860 in London. The worlds first chip, they said, with a million transistors. He said:
"When you have a million transistors, making sure every every trace is connected to something at both ends is a non-trivial task"
I mean, wow, never mind the complexity of the logic, do the wires have dangling ends on the chip?!
Dare I ask if hubexec is still planned?
How much of the full P2 will run on the Propeller 1-2-3 board?
Clock frequency is planned at 160MHz. Cogs execute instructions in 2 clocks. That makes 1280 MIPS across 16 independent cogs.
There's a lot more detail to this, but I need to write documentation, yet.
I don't see HubExec ?
Oh, yes, hub exec is there, too.Chip,
You have just reminded me of a statement made my a big boss at Intel during the launch presentation of the Intel i860 in London. The worlds first chip, they said, with a million transistors. He said:
"When you have a million transistors, making sure every every trace is connected to something at both ends is a non-trivial task"
I mean, wow, never mind the complexity of the logic, do the wires have dangling ends on the chip?!
All the wires connect to something. This chip, in hub RAM, alone, has over 25 million transistors (512K * 8 bits * 6 transistors per bit).Glad to hear P2 is still going forward.
How much of the full P2 will run on the Propeller 1-2-3 board?
I'll need to conserve on smart pin logic to get 16 cogs to fit. I want that board to run all the cogs, so maybe every pin won't be 'smart'.
Does that caveat apply to the final design, or just what is needed to fit in the FPGA on board ?I know Altera recently changed which devices are supported in WebPack - does that make a difference?
Does that caveat apply to the final design, or just what is needed to fit in the FPGA on board ?I know Altera recently changed which devices are supported in WebPack - does that make a difference?
It's to fit into the FPGA. If the silicon gets cramped, not every pin would get smarts, either, though.
I just checked Altera's site to find out if they now support the Cyclone V -A9 with Quartus II Web Edition, and they don't, according to a document from last year (2014).
I had the opcode space to increase the 512KB address range to 1024KB (from 19 to 20 bits).
The silicon will still only have 512KB of RAM, but this extra bits gives some room for future memory increase in denser technologies.