+1 for Smart Pins
-1 for Smart Cells
The term "Smart Pin" immediately conveys the essence of the feature. "Smart Cell" requires some additional description to convey that it refers to I/O on the pins. Maybe a more descriptive term would be "Smart I/O".
+1 for Smart Pins
-1 for Smart Cells
The term "Smart Pin" immediately conveys the essence of the feature. "Smart Cell" requires some additional description to convey that it refers to I/O on the pins. Maybe a more descriptive term would be "Smart I/O".
I'm not suggesting the Smart Cell is the right choice, but I disagree with you about Smart Pin. This new functionality is not in the pin. It clearly sits between the pins and the cogs. For instance, I can configure smart "pin" zero to only read pins one and two, not using actual pin zero at all! The whole reason I ended up using "cell" is precisely because I couldn't use the term "smart pin" without requiring "some additional description". The reality is that this thing is going to require explaining, whatever it's called. As an overall concept, I agree that "Smart I/O" better conveys the essence of the feature. But I would still like a name/term for the individual unit.
I/O Engine, maybe?
"The Propeller 2 has Smart I/O, which consists of 64 independent I/O Engines..."
I've been busy the last few days making some schematic changes for Treehouse, revolving around the ESD structures in the I/O pins. It turns out there's a special device name for those I/O transistors which have long unsilicided (higher-Z) drains for heat dissipation. I didn't have those devices in the symbol library I was using, so I had to figure out what they were called and I made my own. I'll hear tomorrow if they flowed into Cadence Composer all right.
As posted on another thread tonight, here is the final planned pinout:
Chip, is that so? If so, I understand if there isn't the space for it. But if there is, it would still be nice to have the simplified version that I laid out (or something like it). It would still allow some small level of flexibility for future protocol/signaling support. Frankly, I thought the state machines were one of the neatest features of the smart pins/cells, at least in concept.
We could improve the programmable modes and put them into even pins, while odd pins can have USB modes.
Interesting idea. However, I suspect this would make configuration complicated. Not only that, but this would be a significant departure from the (repeatedly) stated design goal that every pin/cell be the same.
On the other hand, it bothers me that we are adding USB support to every smart cell. As I mentioned in an earlier post, I think this is overkill and a waste of resources.
Taking your "every other" idea further (mind you, I'm just spit balling here):
Separate the cells into two kinds:
* The currently documented smart cell, minus state machines, plus the additional USB and serial modes. These cells are accessible at indexes %xxx0xx (i.e. $00-03, $08-0B, $10-13, $18-1B, etc.).
* State machine cells. These cells are accessible at indexes %0001xx (i.e. $04-07, $0C-0F, $14-17, $1C-1F, etc.). Note that the PINSETM parameters could vary significantly for these cells (compared to the existing PINSETM for the other cell type).
The reason for this organization clusters the cells such that it maximizes the +3 to -3 overlap of adjacent cells of the same type. At the same time, it ensures that at least 3 cells of the same type have access to every pin. This presupposes that, when multiple pins are being used together, the same cell types will be used. On the other hand, this could be simplified to simply doing odd/even mapping (cell-type 0 is on even pins, cell-type 1 is on odd pins). This will mean less overlap for the same cell type, but more overlap for the two cell-types. The choice would also affect smart cell output, as the output pin selection is hardwired to the same index as the cell.
In case it wasn't clear, this also means that there would be only 32 of each type of cell.
As I said, this is just pushing Chip's comment a little further. I don't know whether it's a practical compromise or not. At the end of the day, the state machine can be handled in software, albeit at much lower speeds. I still don't like adding USB support to every cell. But if it allows us to keep the "every cell is the same", it might just have to be the way that it is.
....
...
In case it wasn't clear, this also means that there would be only 32 of each type of cell.
...
That's the same resource as Chip is mentioning, & currently USB is quite a bit smaller than State Support.
You raise a good point about the adjacent pin mapping, and it may be sensible to choose the placement of the 32+32 to best use that adjacent feature.
Zooming out a little, SPI/UARTS make sense at the pins, because it is quite likely one COG will service many channels.
USB is perhaps more of a cycle-hog, and if working code shows that one COG is fully consumed just servicing one USB, then that sets a ceiling on how many USBs can be practically managed, and the final placement for USB Logic may be better closer to a COG (reduces to 16 copies, not 32)
This placement probably also can give shorter turn-around, so there could be technical gains too.
That decision can wait until USB is at the functional test stage.
For now, it makes sense to test the USB Logic in the Pin cell, as it is still modest Logic cost.
Zooming out a little, SPI/UARTS make sense at the pins, because it is quite likely one COG will service many channels.
USB is perhaps more of a cycle-hog, and if working code shows that one COG is fully consumed just servicing one USB, then that sets a ceiling on how many USBs can be practically managed, and the final placement for USB Logic may be better closer to a COG (reduces to 16 copies, not 32)
Good point about USB maximum support likely limited to 16 due to cog involvement. Originally, I was going to propose the split as follows:
%xxx0xx : smart DAC/counter/sync/async cells (x32, groups of 4)
%xxx10x : smart USB cells (x16, groups of 2)
%xxx11x : smart state cells (x16, groups of 2)
But, let's face it. Unless the propeller wants to actually do something in addition to the USB, we could probably say that 8 USB cells is an even more realistic maximum. At that point, you could do something like the following:
%xxx0xx : smart DAC/counter/sync/async cells (x32, groups of 4)
%xxx10x : ???
%xxx110 : smart USB cells (x8, groups of 1)
%xxx111 : smart state cells (x8, groups of 1)
But approaches like this are only really useful if:
a) There's not enough room to make all the cells the same, and/or
b) Using the cell index as part of the mode selection frees up necessary configuration bits in PINSETM.
Again, mostly just food for thought at this point. I'm sure we'll have a better idea of what's realistic/practical once Chip finishes the USB-related stuff.
They quietly omit mentioning how large the ROM is, but they do say "The result is the MCL86, which is basically a 7-instruction, 32-bit micro-sequencer. Some of the micro-sequencer's instructions are specialized so as to allow it to rapidly decode instructions as well as nest function calls. With these seven instructions, I was able to microcode all of the 8086 opcodes in a relatively small number of micro-sequencer clocks."
Addit:
I see comments saying fhe core needs 100MHz to give 4.77MHz emulation, and another note saying 180MHz spec on Kintex-7 FPGA, indicates 8.586 MHz top speed ( and ~21:1 microcode MHz to CPU MHz )
Updated to mention 4 Blocks for ROM, I think means ~18k Bytes, so quite a bit of 'microcode' ?
They quietly omit mentioning how large the ROM is, but they do say "The result is the MCL86, which is basically a 7-instruction, 32-bit micro-sequencer. Some of the micro-sequencer's instructions are specialized so as to allow it to rapidly decode instructions as well as nest function calls. With these seven instructions, I was able to microcode all of the 8086 opcodes in a relatively small number of micro-sequencer clocks."
Addit:
I see comments saying fhe core needs 100MHz to give 4.77MHz emulation, and another note saying 180MHz spec on Kintex-7 FPGA, indicates 8.586 MHz top speed ( and ~21:1 microcode MHz to CPU MHz )
Updated to mention 4 Blocks for ROM, I think means ~18k Bytes, so quite a bit of 'microcode' ?
That's interesting! That might make very small custom silicon, as those ROMs would be very small and there's not much logic. It's just slow, as it takes umpteen clocks to get an 8088 instruction executed. Pretty interesting exercise.
It looks like a nice board. The twin GPIO headers are packed with i/o unlike the BeMicro's
Got to be careful with the LE claims on Cyclone V. It has 15094 ALMs, Altera claim that's equivalent to 40k LE's but a few people have posted that "2.65" is an optimistic ratio for this kind of work, so might not end up much bigger than the DE0-Nano. However if that lets a 2nd cog fit, and perhaps allows the cordic to squeeze back in, and works with the existing parallax DE0-Nano breakout, could be a good new starting point.
There is a big difference in FPGA RAM - 2700kb vs 594kb. Ie should support 256kB Hub
All in all a lot of extra value for the extra $20 above a DE-Nano
Don't be. He's sorting through this stuff to simplify it and make it accessible to people.
This is new functionality. Takes an iteration or few to get going.
True, but it would be nice to get another status update. I'm eager to play with the serial modes (the existing sync/async stuff, not USB). Though the current image has serial, it's not documented and is already outdated (based on some of Chip's earlier comments). Also, it looks like the state machines have been removed, so there's no point in testing those any further.
I guess the point is: it seems we've got a lot of idle FPGAs. Time to get them back to work!
Mine isn't idle. It's nice to just be building something up with what we do know, maybe find another bug. So, that's what I've been doing. Hopefully, I've got something to show one day soon.
Always nice to get an update, and we will get one. There has to be something to update, and that something is brewing right now, IMHO.
True, but it would be nice to get another status update. I'm eager to play with the serial modes (the existing sync/async stuff, not USB). Though the current image has serial, it's not documented and is already outdated (based on some of Chip's earlier comments). Also, it looks like the state machines have been removed, so there's no point in testing those any further.
I guess the point is: it seems we've got a lot of idle FPGAs. Time to get them back to work!
Yes, present Serial has limited bit-length choices, and no fractional baud, which limits testing coverage, but I think Chip was working on the USB Software layer just above the Smart pins, as that will take a little juggling to get the Hardware/Software boundary working well.
USB Signaling needs to be simple, with fast turn-around times, but with lowest logic cost.
It is still unclear if USB needs 2 pin cells.
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
Sounds good.
What about using one Prop1 to target another? That way, if the target crashes due to a bug, you don't have to start over. That's how I've envisioned the Prop2 tools, anyway.
Comments
Glial Pins... hmmmm
It does wrap as confirmed with this little test.
Serial RX data on pin 63 watched on pin 0
-1 for Smart Cells
The term "Smart Pin" immediately conveys the essence of the feature. "Smart Cell" requires some additional description to convey that it refers to I/O on the pins. Maybe a more descriptive term would be "Smart I/O".
Good to have that confirmed.
I'm not suggesting the Smart Cell is the right choice, but I disagree with you about Smart Pin. This new functionality is not in the pin. It clearly sits between the pins and the cogs. For instance, I can configure smart "pin" zero to only read pins one and two, not using actual pin zero at all! The whole reason I ended up using "cell" is precisely because I couldn't use the term "smart pin" without requiring "some additional description". The reality is that this thing is going to require explaining, whatever it's called. As an overall concept, I agree that "Smart I/O" better conveys the essence of the feature. But I would still like a name/term for the individual unit.
I/O Engine, maybe?
"The Propeller 2 has Smart I/O, which consists of 64 independent I/O Engines..."
It will get called something. I like SIO.
Yes. They wrap around. Physically, they are proximitous.
As posted on another thread tonight, here is the final planned pinout:
Was just looking that the IC development Gant chart here:
http://treehousedes.com/asic-ic-solutions-services/asic-ic-development-process
Is P2 in the orange yet?
Treehouse will be sitting at the FDR line, waiting on Chip. :P
Interesting idea. However, I suspect this would make configuration complicated. Not only that, but this would be a significant departure from the (repeatedly) stated design goal that every pin/cell be the same.
On the other hand, it bothers me that we are adding USB support to every smart cell. As I mentioned in an earlier post, I think this is overkill and a waste of resources.
Taking your "every other" idea further (mind you, I'm just spit balling here):
Separate the cells into two kinds:
* The currently documented smart cell, minus state machines, plus the additional USB and serial modes. These cells are accessible at indexes %xxx0xx (i.e. $00-03, $08-0B, $10-13, $18-1B, etc.).
* State machine cells. These cells are accessible at indexes %0001xx (i.e. $04-07, $0C-0F, $14-17, $1C-1F, etc.). Note that the PINSETM parameters could vary significantly for these cells (compared to the existing PINSETM for the other cell type).
The reason for this organization clusters the cells such that it maximizes the +3 to -3 overlap of adjacent cells of the same type. At the same time, it ensures that at least 3 cells of the same type have access to every pin. This presupposes that, when multiple pins are being used together, the same cell types will be used. On the other hand, this could be simplified to simply doing odd/even mapping (cell-type 0 is on even pins, cell-type 1 is on odd pins). This will mean less overlap for the same cell type, but more overlap for the two cell-types. The choice would also affect smart cell output, as the output pin selection is hardwired to the same index as the cell.
In case it wasn't clear, this also means that there would be only 32 of each type of cell.
As I said, this is just pushing Chip's comment a little further. I don't know whether it's a practical compromise or not. At the end of the day, the state machine can be handled in software, albeit at much lower speeds. I still don't like adding USB support to every cell. But if it allows us to keep the "every cell is the same", it might just have to be the way that it is.
That's the same resource as Chip is mentioning, & currently USB is quite a bit smaller than State Support.
You raise a good point about the adjacent pin mapping, and it may be sensible to choose the placement of the 32+32 to best use that adjacent feature.
Zooming out a little, SPI/UARTS make sense at the pins, because it is quite likely one COG will service many channels.
USB is perhaps more of a cycle-hog, and if working code shows that one COG is fully consumed just servicing one USB, then that sets a ceiling on how many USBs can be practically managed, and the final placement for USB Logic may be better closer to a COG (reduces to 16 copies, not 32)
This placement probably also can give shorter turn-around, so there could be technical gains too.
That decision can wait until USB is at the functional test stage.
For now, it makes sense to test the USB Logic in the Pin cell, as it is still modest Logic cost.
Good point about USB maximum support likely limited to 16 due to cog involvement. Originally, I was going to propose the split as follows:
%xxx0xx : smart DAC/counter/sync/async cells (x32, groups of 4)
%xxx10x : smart USB cells (x16, groups of 2)
%xxx11x : smart state cells (x16, groups of 2)
But, let's face it. Unless the propeller wants to actually do something in addition to the USB, we could probably say that 8 USB cells is an even more realistic maximum. At that point, you could do something like the following:
%xxx0xx : smart DAC/counter/sync/async cells (x32, groups of 4)
%xxx10x : ???
%xxx110 : smart USB cells (x8, groups of 1)
%xxx111 : smart state cells (x8, groups of 1)
But approaches like this are only really useful if:
a) There's not enough room to make all the cells the same, and/or
b) Using the cell index as part of the mode selection frees up necessary configuration bits in PINSETM.
Again, mostly just food for thought at this point. I'm sure we'll have a better idea of what's realistic/practical once Chip finishes the USB-related stuff.
http://www.embedded.com/electronics-blogs/max-unleashed-and-unfettered/4441454/Only-308-FPGA-LUTs-required-to-create-cycle-accurate-8088-8086-soft-processor-core
They quietly omit mentioning how large the ROM is, but they do say
"The result is the MCL86, which is basically a 7-instruction, 32-bit micro-sequencer. Some of the micro-sequencer's instructions are specialized so as to allow it to rapidly decode instructions as well as nest function calls. With these seven instructions, I was able to microcode all of the 8086 opcodes in a relatively small number of micro-sequencer clocks."
Addit:
I see comments saying fhe core needs 100MHz to give 4.77MHz emulation, and another note saying 180MHz spec on Kintex-7 FPGA, indicates 8.586 MHz top speed ( and ~21:1 microcode MHz to CPU MHz )
Updated to mention 4 Blocks for ROM, I think means ~18k Bytes, so quite a bit of 'microcode' ?
Interesting, thanks for the link
That's interesting! That might make very small custom silicon, as those ROMs would be very small and there's not much logic. It's just slow, as it takes umpteen clocks to get an 8088 instruction executed. Pretty interesting exercise.
https://www.altera.com/products/boards_and_kits/dev-kits/partners/cyclonev_soc_atlas.html
Has a 40kLE 3,080kb memory, 5CSEMA4U23C6N FPGA
- almost 2x LE of older nano.
How many COGs + Smartpins would build into the CV-A4 ?
Got to be careful with the LE claims on Cyclone V. It has 15094 ALMs, Altera claim that's equivalent to 40k LE's but a few people have posted that "2.65" is an optimistic ratio for this kind of work, so might not end up much bigger than the DE0-Nano. However if that lets a 2nd cog fit, and perhaps allows the cordic to squeeze back in, and works with the existing parallax DE0-Nano breakout, could be a good new starting point.
There is a big difference in FPGA RAM - 2700kb vs 594kb. Ie should support 256kB Hub
All in all a lot of extra value for the extra $20 above a DE-Nano
This is new functionality. Takes an iteration or few to get going.
True, but it would be nice to get another status update. I'm eager to play with the serial modes (the existing sync/async stuff, not USB). Though the current image has serial, it's not documented and is already outdated (based on some of Chip's earlier comments). Also, it looks like the state machines have been removed, so there's no point in testing those any further.
I guess the point is: it seems we've got a lot of idle FPGAs. Time to get them back to work!
Always nice to get an update, and we will get one. There has to be something to update, and that something is brewing right now, IMHO.
USB Signaling needs to be simple, with fast turn-around times, but with lowest logic cost.
It is still unclear if USB needs 2 pin cells.
I'm still working on the USB circuit. It's taken some time figuring out what the interface needs to be, as there are events and byte transfers to report and handle. The cog software needs to have an easy time with this. So, it's been slowly congealing what needs to be done. I think when I have it all figured out, the implementation will come together really simply.
Good brew takes time. Let it percolate.
We have lots to do and explore in the meantime.
Great news Chip.
Sorry I haven't been much help this time around.
Been too busy with getting P1 on chip compilation to work under FAT32 drivers and OS - buried way deep in a few bugs
Will surface shortly
Sounds good.
What about using one Prop1 to target another? That way, if the target crashes due to a bug, you don't have to start over. That's how I've envisioned the Prop2 tools, anyway.