I think there's a mode for this, where the '1' level is generated by fast settling dac (to an arbitrarily set voltage). And the paired pin can be set to invert that same data input. Kind of pseudo-lvds.
This kind of documentation is hard. As we probably all know. Somebody has to extract the definitive meaning of everything from the creator, Chip, and translate and present is as something normal humans will understand and can make use of.
In the past, I've often found it much easier to write documentation if someone else writes something for me first, even if it's completely wrong. To that end, would it make sense to start with the Propeller 1 Manual, replace P8x32A with P8x64A (or whatever) then start fixing everything that's wrong?
Would 16 cogs and 1 MB of Hub be worth a speed reduction from 160 MHz to 120 MHz?
YES. Think active/passive cooling AND margin (i.e 80MHZ Prop 1 running at 100MHZ just fine). If the same margin is there, surely 150 ish is possible with a 120MHZ version.
I say Yes. Yes. Yes. You will blow up the paradigm.
I ran it by OnSemi and they said it would reset the whole contract back to the quoting phase. That was a "banker's NO".
On the other hand, we have a minimum Fmax requirement of 160 MHz, with a stretch goal of 200 MHz. We may be able to pursue the 200Mhz if size permits. That's a 10ns instruction cycle for anyone in Rio Linda.
I'm not sure how much help I'll be, but I do have some experience writing technical documentation, tutorials, etc. and would love to help out with the Prop 2 docs.
I also vote for using GitHub. Being able to review changes in a pull request alone is worth it in my opinion, especially if we're hoping to get lots of help from the community.
Here is how the new VCO mux got implemented. It was my first time actually building circuits, though I've moved lots of metal around. This was fun.
Here is the old PLL_MATH circuit:
The problem here is that the VCO runs too fast for the VCO dividers to track. It was going 630MHz on the test chip, while the counters lost track at 420MHz. I slowed down the VCO inverters by lengthening their gates from 300nm to 500nm. The VCO tops out at 285MHz, worst case, now, which is always trackable by the VCO dividers.
We can't rely on being able to use the VCO post-divider output to toggle a flop, anymore, at 400MHz, since that's near the limit of the digital divider's ability and the VCO no longer goes that fast (thankfully). So, we need a mode where we can use the VCO output, directly, for 100MHz..200MHz frequencies.
Here's the new PLL math circuit, which allows direct use of the VCO signal when P[3:0] = %1111:
I made the change, myself. First, I got all the standard cells that I needed:
Then I wired them together:
...And wired the new mux circuit into the existing circuit, replacing the old flop and two inverters:
It only took 1/2 hour on the phone, working with Nathan at OnSemi, to have him stream the new GDS in from the cell I had modified, and then make the top-level edits to wire in the new PLL output. It passed DRC and LVS without any more edits. Done!!!
The problem here is that the VCO runs too fast for the VCO dividers to track. It was going 630MHz on the test chip, while the counters lost track at 420MHz. I slowed down the VCO inverters by lengthening their gates from 300nm to 500nm. The VCO tops out at 285MHz, worst case, now, which is always trackable by the VCO dividers.
It only took 1/2 hour on the phone, working with Nathan at OnSemi, to have him stream the new GDS in from the cell I had modified, and then make the top-level edits to wire in the new PLL output. It passed DRC and LVS without any more edits. Done!!!
Great Lucky there was that tram line space ! Have you had someone else double checked all the connections/netlist ?
How closely do the measurements line up with the Spice predictions ?
What is the Process/Temperature Min MHz, for the VCO Max value ?
The problem here is that the VCO runs too fast for the VCO dividers to track. It was going 630MHz on the test chip, while the counters lost track at 420MHz. I slowed down the VCO inverters by lengthening their gates from 300nm to 500nm. The VCO tops out at 285MHz, worst case, now, which is always trackable by the VCO dividers.
It only took 1/2 hour on the phone, working with Nathan at OnSemi, to have him stream the new GDS in from the cell I had modified, and then make the top-level edits to wire in the new PLL output. It passed DRC and LVS without any more edits. Done!!!
Great Lucky there was that tram line space ! Have you had someone else double checked all the connections/netlist ?
How closely do the measurements line up with the Spice predictions ?
What is the Process/Temperature Min MHz, for the VCO Max value ?
The SPICE predictions showed that the VCO should run up to ~1GHz, but I only saw it going 630MHz. It also showed the dividers working up to ~600MHz, but they were outpaced at ~420MHz. Not sure why such great discrepancies.
The new VCO tops out at 285MHz, worst-case (90% voltages, 125C, slow process corner). It will never outpace the dividers now. If it suffers a big derating, it should still cover 160MHz. I'm going to do some more tests on that now, because I'm worried it may wind up being too slow, in reality.
We know that the layout matches my schematic because it passes LVS (layout-vs-schematic). And I simulated it to make sure it was okay, even though the change was very simple.
Tonight I'm going over the I/O pad, making sure it's doing what it's supposed to do and that it also works properly with the smart pin modes.
I was testing out the ADCs and DACs by running a signal into one I/O pad configured as a 33mV full-scale (100x mag) ADC, then taking the ADC sample and running it through another I/O configured as 16-bit dithered DAC.
In 33mV full-scale ADC mode, the signal to be quantized needs to be capacitively coupled into the I/O pad, as the pad must be allowed to set the average level to somewhere around VIO/2. Then, it quantizes changes spanning up to 33mV, resulting in ADC values from near 0% to near 100%.
You can see in the picture that the function generator is coming in on channel 1 of the scope and it is outputting a 30mV peak-to-peak sine wave of 50KHz. It's getting converted to a 5-bit ADC sample at an 80/32 = 2.5MHz rate and then output from a DAC onto channel 2. I noticed there was a 10mV ~500KHz signal superimposed on the conversion. It turns out this is VIO power supply noise, causing the ADC reference to move around against the incoming signal. It's being faithfully quantized by the delta-sigma ADC converter in the I/O pin. This is what ought to be expected. The remedy for this is filter the VIO supply that goes to I/O pins that are performing accurate A/D conversions.
Anyway, the ADC resolving power is quite good on small AC signals.
Here's the code:
con n = 5 'number of conversion bits
dat org
hubset #$FF 'run at 80MHz
wrpin adc_mode,#4 'adc mode for P4
wxpin ##1<<n,#4 'n-bit conversion
wypin #0,#4 'count a-highs
dirh #4 'adc enable
wrpin dac_mode,#5 'dac mode for P5
wxpin ##1<<n,#5 'n-bit conversion
dirh #5 'dac enable
setse1 #%110<<6+4 'se1 triggers on adc sample
loop waitse1 'wait adc sample
rdpin x,#4 'get adc sample
shl x,#16-n 'shift up and set dac
wypin x,#5
jmp #loop 'loop
adc_mode long %0000_0000_000_100111_0000000_00_01111_0
dac_mode long %0000_0000_000_10100_00000000_01_00011_0
x res 1
Chip,
I'm interested in running that. Does that work on the A123 board? I'm assuming those pin numbers are someway mapped to the ADC and DAC connectors.
Chip,
I don't like to be the one to say this, but you have only just received the test chip back from OnSemi, so there has not been much time for you to test this, amongst doing other things with the P2 Verilog and OnSemi.
Add to this the fact that there has hardly been ANY decent testing of the Verilog/FPGA for some considerable time, and there has been numerous changes recently, which have uncovered a number of bugs, and by reviewing the code, not by real testing.
Are you really in a position to get the Production Test Chip underway now, with minimal risk ???
Personally I have no confidence that adequate testing has been done at this point in time. But its not my money.
However, if an error is discovered, the timescales you have given would indicate if you go ahead now, a respin will cost ~26weeks. What would be the delay if you wait for the next shuttle run to allow more testing time?
I know we all want the P2 years ago, me included. But I also don't want to wait for the sample Chip to find bugs.
Chip,
I'm interested in running that. Does that work on the A123 board? I'm assuming those pin numbers are someway mapped to the ADC and DAC connectors.
To test this, you would need the test silicon chip.
Not sure how many of those parallax got ?
Certainly seems a good idea to expand the testing
"The SPICE predictions showed that the VCO should run up to ~1GHz, but I only saw it going 630MHz. It also showed the dividers working up to ~600MHz, but they were outpaced at ~420MHz. Not sure why such great discrepancies." .... This makes perfect sense to me. There are parasitic considerations in layout that need to need to be addressed that the SPICE model can not completely simulate.
"We know that the layout matches my schematic because it passes LVS (layout-vs-schematic). And I simulated it to make sure it was okay, even though the change was very simple." .... Just because LVS passes does not mean you are out of the woods. There are many other things to consider that must be empirically tested. This means physical test structures that represent your process and layout characteristics of other nearby structures. Looking at the layout for the "new PLL math circuit" you posted earlier scares me quite a bit. Not because I might be a little biased, of course I am, but from a professional level of quality layout work. When I worked at National Semiconductor, I mentored the students from Georgia Tech in a classroom/lab environment on what to do vs. what not to do in terms of layout. I see several issues with the PLL math circuit layout you posted. I can't stress enough the need for empirical testing. While at NSC, we were constantly updating and tweaking the SPICE models used for TSMC's process. This was an iterative process, where through empirical testing our data from NSC was actually defining the SPICE models other companies would use. One of my specialties at NSC was to create a standard cell library, characterize each cell through timing and parasitic analysis, and update the SPICE model to reflect the physical layout results. That's just how it is done. You can not solely rely on what the SPICE model might tell you is supposed to happen. There are just too many other variables at play that must be considered when it comes to timing and getting it just right.
"So, what is wrong with the layout, anyway?" ... The first thing I see is how that cell block is powered. TOP LEFT, and then BOTTOM RIGHT. You would be much better off if you mirrored the X axis of just that block and strapped power in a more direct approach to the adjacent cells. If the power is done like that there, then most likely it is done that way in several other places. There are some other common sense errors that just come with experience. That layout looks typical to how I would see the Georgia Tech students attempt at layout. It might get the job done but it's not as organized as it should be for that kind of structure and frequencies you are expecting. I didn't see any guard rings except maybe in the lower right structure partially off screen, but one contact width for a guard ring is usually not adequate.
I see. Thanks for the elaboration. I'm pretty much the best layout guy here on the farm, and maybe even in Red Bluff.
My only concern is that I understand why the VCO was so off. I can understand that with long wire runs, the digital counters could slow, but I don't know how something as compact as the VCO could be so far off. I wish there was a way to know what the regulated voltage was for the VCO supply. I high-z filter the 1.8V power, then replicate it from the 3.3V supply. If that voltage wound up being really low, that would explain the speed difference.
My only concern is that I understand why the VCO was so off. I can understand that with long wire runs, the digital counters could slow, but I don't know how something as compact as the VCO could be so far off..
A simple litmus test is to add some fF of parasitic C to every inverter, and adjust that to drop the Spice-1G to the Measured-630MHz
You only need to add ~42ps to each inverter.
"I see. Thanks for the elaboration. I'm pretty much the best layout guy here on the farm, and maybe even in Red Bluff." ... As I said, I might be a little biased, only for a good reason though. I didn't realize you were doing the layout. Hind sight is 20/20
What is the process limitation for frequency? ... While at NSC, the TSMC rule of thumb for 180nm was about 350MHz mostly due to substrate leakage. That rule of thumb is usually derated, so double that would not be out of the question. However with appropriate use of NWELL isolation you could greatly reduce the substrate leakage where higher frequencies would be achievable.
Comments
I guess at the end of the day raw signalling speed is only part of the problem.
It might be useful to be able to use that capability to speak to other things than just between Propellers.
At which point some kind of standard protocol adoption is called for.
Like Tile Link https://www.sifive.com/documentation/tilelink/tilelink-spec/
OK, that seems to be for communication between parts on a SoC. But it is also used for chip to chip links. As far as I can tell.
Obvious candidates are HS-USB, and HDMI type Displays, plus there are some high performance ADCs with LVDS...
Then there is M-LVDS, the 'RS-485' equivalent operation
https://en.wikipedia.org/wiki/Low-voltage_differential_signaling#Multipoint_LVDS
hmm,
Mike
Good. Wonder how I missed that? Doc looks good heater. That's the bare minimum needed.
I think I saw 450MHz somewhere. Those are interesting links.
I'll keep digging a bit more.
I think there's a mode for this, where the '1' level is generated by fast settling dac (to an arbitrarily set voltage). And the paired pin can be set to invert that same data input. Kind of pseudo-lvds.
In the past, I've often found it much easier to write documentation if someone else writes something for me first, even if it's completely wrong. To that end, would it make sense to start with the Propeller 1 Manual, replace P8x32A with P8x64A (or whatever) then start fixing everything that's wrong?
https://www.youtube.com/results?search_query=LVDS
Datasheet's:
http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PlainTextSearch|LVDS|3|,Ny:True,Nea:True,N:898
WIKI:
https://en.wikipedia.org/wiki/Low-voltage_differential_signaling
Raspberry Pi LVDS Example:
How to Connect Raspberry Pi to a Laptop LCD Panel via LVDS/LCD Controller Board
YES. Think active/passive cooling AND margin (i.e 80MHZ Prop 1 running at 100MHZ just fine). If the same margin is there, surely 150 ish is possible with a 120MHZ version.
I say Yes. Yes. Yes. You will blow up the paradigm.
On the other hand, we have a minimum Fmax requirement of 160 MHz, with a stretch goal of 200 MHz. We may be able to pursue the 200Mhz if size permits. That's a 10ns instruction cycle for anyone in Rio Linda.
Okay. Thanks!
I also vote for using GitHub. Being able to review changes in a pull request alone is worth it in my opinion, especially if we're hoping to get lots of help from the community.
Here is the old PLL_MATH circuit:
The problem here is that the VCO runs too fast for the VCO dividers to track. It was going 630MHz on the test chip, while the counters lost track at 420MHz. I slowed down the VCO inverters by lengthening their gates from 300nm to 500nm. The VCO tops out at 285MHz, worst case, now, which is always trackable by the VCO dividers.
We can't rely on being able to use the VCO post-divider output to toggle a flop, anymore, at 400MHz, since that's near the limit of the digital divider's ability and the VCO no longer goes that fast (thankfully). So, we need a mode where we can use the VCO output, directly, for 100MHz..200MHz frequencies.
Here's the new PLL math circuit, which allows direct use of the VCO signal when P[3:0] = %1111:
I made the change, myself. First, I got all the standard cells that I needed:
Then I wired them together:
...And wired the new mux circuit into the existing circuit, replacing the old flop and two inverters:
It only took 1/2 hour on the phone, working with Nathan at OnSemi, to have him stream the new GDS in from the cell I had modified, and then make the top-level edits to wire in the new PLL output. It passed DRC and LVS without any more edits. Done!!!
How closely do the measurements line up with the Spice predictions ?
What is the Process/Temperature Min MHz, for the VCO Max value ?
The SPICE predictions showed that the VCO should run up to ~1GHz, but I only saw it going 630MHz. It also showed the dividers working up to ~600MHz, but they were outpaced at ~420MHz. Not sure why such great discrepancies.
The new VCO tops out at 285MHz, worst-case (90% voltages, 125C, slow process corner). It will never outpace the dividers now. If it suffers a big derating, it should still cover 160MHz. I'm going to do some more tests on that now, because I'm worried it may wind up being too slow, in reality.
We know that the layout matches my schematic because it passes LVS (layout-vs-schematic). And I simulated it to make sure it was okay, even though the change was very simple.
I was testing out the ADCs and DACs by running a signal into one I/O pad configured as a 33mV full-scale (100x mag) ADC, then taking the ADC sample and running it through another I/O configured as 16-bit dithered DAC.
In 33mV full-scale ADC mode, the signal to be quantized needs to be capacitively coupled into the I/O pad, as the pad must be allowed to set the average level to somewhere around VIO/2. Then, it quantizes changes spanning up to 33mV, resulting in ADC values from near 0% to near 100%.
You can see in the picture that the function generator is coming in on channel 1 of the scope and it is outputting a 30mV peak-to-peak sine wave of 50KHz. It's getting converted to a 5-bit ADC sample at an 80/32 = 2.5MHz rate and then output from a DAC onto channel 2. I noticed there was a 10mV ~500KHz signal superimposed on the conversion. It turns out this is VIO power supply noise, causing the ADC reference to move around against the incoming signal. It's being faithfully quantized by the delta-sigma ADC converter in the I/O pin. This is what ought to be expected. The remedy for this is filter the VIO supply that goes to I/O pins that are performing accurate A/D conversions.
Anyway, the ADC resolving power is quite good on small AC signals.
Here's the code:
I'm interested in running that. Does that work on the A123 board? I'm assuming those pin numbers are someway mapped to the ADC and DAC connectors.
I don't like to be the one to say this, but you have only just received the test chip back from OnSemi, so there has not been much time for you to test this, amongst doing other things with the P2 Verilog and OnSemi.
Add to this the fact that there has hardly been ANY decent testing of the Verilog/FPGA for some considerable time, and there has been numerous changes recently, which have uncovered a number of bugs, and by reviewing the code, not by real testing.
Are you really in a position to get the Production Test Chip underway now, with minimal risk ???
Personally I have no confidence that adequate testing has been done at this point in time. But its not my money.
However, if an error is discovered, the timescales you have given would indicate if you go ahead now, a respin will cost ~26weeks. What would be the delay if you wait for the next shuttle run to allow more testing time?
I know we all want the P2 years ago, me included. But I also don't want to wait for the sample Chip to find bugs.
Not sure how many of those parallax got ?
Certainly seems a good idea to expand the testing
"We know that the layout matches my schematic because it passes LVS (layout-vs-schematic). And I simulated it to make sure it was okay, even though the change was very simple." .... Just because LVS passes does not mean you are out of the woods. There are many other things to consider that must be empirically tested. This means physical test structures that represent your process and layout characteristics of other nearby structures. Looking at the layout for the "new PLL math circuit" you posted earlier scares me quite a bit. Not because I might be a little biased, of course I am, but from a professional level of quality layout work. When I worked at National Semiconductor, I mentored the students from Georgia Tech in a classroom/lab environment on what to do vs. what not to do in terms of layout. I see several issues with the PLL math circuit layout you posted. I can't stress enough the need for empirical testing. While at NSC, we were constantly updating and tweaking the SPICE models used for TSMC's process. This was an iterative process, where through empirical testing our data from NSC was actually defining the SPICE models other companies would use. One of my specialties at NSC was to create a standard cell library, characterize each cell through timing and parasitic analysis, and update the SPICE model to reflect the physical layout results. That's just how it is done. You can not solely rely on what the SPICE model might tell you is supposed to happen. There are just too many other variables at play that must be considered when it comes to timing and getting it just right.
So, what is wrong with the layout, anyway?
Does the simulation include layout delays & supply inductance effects, or it is just a circuit-simulation ?
My only concern is that I understand why the VCO was so off. I can understand that with long wire runs, the digital counters could slow, but I don't know how something as compact as the VCO could be so far off. I wish there was a way to know what the regulated voltage was for the VCO supply. I high-z filter the 1.8V power, then replicate it from the 3.3V supply. If that voltage wound up being really low, that would explain the speed difference.
A simple litmus test is to add some fF of parasitic C to every inverter, and adjust that to drop the Spice-1G to the Measured-630MHz
You only need to add ~42ps to each inverter.
What is the process limitation for frequency? ... While at NSC, the TSMC rule of thumb for 180nm was about 350MHz mostly due to substrate leakage. That rule of thumb is usually derated, so double that would not be out of the question. However with appropriate use of NWELL isolation you could greatly reduce the substrate leakage where higher frequencies would be achievable.