It's a little late but we've gotten custom sockets built by Aries (http://www.arieselec.com/) for low pin count (36-64 pins) WLBGAs and fpBGAs for about $400 each, and TTS (http://tts-grp.com/) for about 3X that. If you're using a standard package, then maybe one of them has an off-the-shelf product that would work.
That AD7400 is a 2nd-order delta-sigma modulator which requires a complicated digital filter after it to produce 16-bit samples.
I think the AD7400 could work, in counter mode, but does ideally need CLK and CLKEN signal connection to P2 counter.
Actually 2 counters, as the MCLKOUT is somewhat variable, you would feed MCLKOUT to 2 Ctrs, and one would be always Enabled, the other is MDAT enabled. Now the counter ratio, is the voltage ratio.
In use, you would wait for 2^16 MCLK edges, then read the other (gated) counter A reading rates ~152Hz
HW capture of Enabled counter on the other Ctr overflow, would give values with no software overhead.
Can the P2 do that ? ie External clock to 2 counters, and also CLKEN to one ?
AD7400 says : A differential signal of 0 V results (ideally) in a stream of 1s and 0s at the MDAT output pin.
This output is high 50% of the time and low 50% of the time.
A differential input of 200 mV produces a stream of 1s and 0s that are high 81.25% of the time.
A differential input of −200 mV produces a stream of 1s and 0s that are high 18.75% of the time.
Addit: I see the MDAT changes after MCLK _/= and is stable when MCLK=L, so for Prop1 (and if P2 has no CLKEN), you could use a 1G57 universal Logic gate for
GCLK = MDAT & !MCLK,
and GCLK can feed any Prop Ctr.
That AD7400 is a 2nd-order delta-sigma modulator which requires a complicated digital filter after it to produce 16-bit samples.
The Prop2 has simple 1st-order delta-sigma modulators which output 0's and 1's in proportion to the input signal level. for example, a Vsup/2 level would produce the stream: 010101010101.... which is 1/2. A GND level would produce 0000010000000100000001... which is 1/8. A Vsup level would produce 1111101111111011111110... which is 7/8. So, you only need to count 1's over some number of clocks to get a sample. If you count for 256 clocks, you'll get an 8-bit quality sample ranging from 0 to 256. If the input is between GND and Vsup (1/8 and 7/8), you'll get values from 32 to 224.
Is it possible to let the counter count to 1024 or higher?
Is it possible to let the counter count to 1024 or higher?
Sure.
You can even run two time bases in SW - sample at say 2^16 (or less) for faster readout, using difference reading, and keep a slower total, perhaps over 0.5 second, for highest precision.
I think the AD7400 could work, in counter mode, but does ideally need CLK and CLKEN signal connection to P2 counter.
Actually 2 counters, as the MCLKOUT is somewhat variable, you would feed MCLKOUT to 2 Ctrs, and one would be always Enabled, the other is MDAT enabled. Now the counter ratio, is the voltage ratio.
In use, you would wait for 2^16 MCLK edges, then read the other (gated) counter A reading rates ~152Hz
HW capture of Enabled counter on the other Ctr overflow, would give values with no software overhead.
Can the P2 do that ? ie External clock to 2 counters, and also CLKEN to one ?
AD7400 says : A differential signal of 0 V results (ideally) in a stream of 1s and 0s at the MDAT output pin.
This output is high 50% of the time and low 50% of the time.
A differential input of 200 mV produces a stream of 1s and 0s that are high 81.25% of the time.
A differential input of −200 mV produces a stream of 1s and 0s that are high 18.75% of the time.
Addit: I see the MDAT changes after MCLK _/= and is stable when MCLK=L, so for Prop1 (and if P2 has no CLKEN), you could use a 1G57 universal Logic gate for
GCLK = MDAT & !MCLK,
and GCLK can feed any Prop Ctr.
In reading the AD7400 datasheet, it mentions needing a special digital filter chip, which can be one of their products or an FPGA of your own. Those filters are huge and complicated, but tied to a 2nd-order delta-sigma converter you get high-bit-count results much faster than you can with a first-order setup.
Chip, do you have a seat of the pants blue-sky idea of what kind of absolute microvolt resolution we might be able to expect from the P2 ADC on relatively low sample rates such as 60 Hz or slower? I am interested in reading the output of a wheatstone bridge either directly or with a single-stage 3v3 instrumentation amp. My tests in that area with P1 weren't up to snuff and I'm not really an analog design guy.
Here is a DAC with a 2nd-order modulator. Note that the analog section is big and the digital filter section (made of dense standard cells) is even bigger:
I hired a 2nd-order delta-sigma ADC consultant for a day during the development of Prop2's ADC circuit, and it was quickly apparent to me that trying to implement such a thing on every pin would be impractical. So, we have simple first-order modulators.
Chip, do you have a seat of the pants blue-sky idea of what kind of absolute microvolt resolution we might be able to expect from the P2 ADC on relatively low sample rates such as 60 Hz or slower? I am interested in reading the output of a wheatstone bridge either directly or with a single-stage 3v3 instrumentation amp. My tests in that area with P1 weren't up to snuff and I'm not really an analog design guy.
I really don't know, but I wouldn't be surprised if you could resolve microvolts, after noise is averaged away.
In reading the AD7400 datasheet, it mentions needing a special digital filter chip, which can be one of their products or an FPGA of your own. Those filters are huge and complicated, but tied to a 2nd-order delta-sigma converter you get high-bit-count results much faster than you can with a first-order setup.
I think the Digital Filter is optional - as you say, you get more bits-per-second with a Filter design, but you can also use a basic counter, given they have a direct % modulation.
With a filter, they say you can get 39KHz word (16b) rates, whilst a counter is 152Hz word rates.
Filters do have a inter-word crosstalk, so do not multiplex well.
Assuming someone did want to do such a filter in a COG, it would need
CLK + DAT shifter, and the Counter version would need CLK, CLK+CLKEN.
Can the P2 support both pathways ? ( CLK + DAT shifter or CLK, CLK+CLKEN Ctrs)
Do you have a description of what the loader needs to do to sign an image before loading it with the real P2 chip?
Thanks,
David
You need to do an HMAC/SHA-256 on the loader's longs ranging from $000..$1F7 using the 128-bit security key, and place it in $1F8..$1FF.
After downloading $200 longs, the booter computes its own HMAC/SHA-256 from the loader's longs in $000..$1F7 using the 128-bit security key. Then, it compares it to what you loaded for $1F8..$1FF. If the signatures match, the loader is run in cog0. If they didn't match and the security key is $00000000_00000000_00000000_00000000, the monitor runs. Else, the part waits for another reset.
For the FPGA version of the Prop2, loader must contain $00000001's from $1F8..$1FF.
I can get more info on the HMAC/SHA-256 procedure. I have it written in Delphi (Pascal), already.
openssl (the program that contains all the good stuff)
sha256 (the algorithm)
-mac HMAC (tell it to generate a digest using the HMAC protocol)
-macopt hexkey:00000000000000000000000000000000 (this is a hex value, all 128 bits of the secret key)
foo (the file you want to calculate the hash for)
Thanks! Is there a shortcut for chips that don't have a key programmed into them or do I have to use openssl with some default key? I guess this means that we need to distribute openssl with PropGCC or any program that will need to download to the P2. Has someone created executables for Windows, Linux, and Mac that we can add to our distributions? We'll have to provide RossH with this information as well so he can modify his Catalina loader.
You need to do an HMAC/SHA-256 on the loader's longs ranging from $000..$1F7 using the 128-bit security key, and place it in $1F8..$1FF.
After downloading $200 longs, the booter computes its own HMAC/SHA-256 from the loader's longs in $000..$1F7 using the 128-bit security key. Then, it compares it to what you loaded for $1F8..$1FF. If the signatures match, the loader is run in cog0. If they didn't match and the security key is $00000000_00000000_00000000_00000000, the monitor runs. Else, the part waits for another reset.
For the FPGA version of the Prop2, loader must contain $00000001's from $1F8..$1FF.
I can get more info on the HMAC/SHA-256 procedure. I have it written in Delphi (Pascal), already.
Ah, if you have a Pascal implementation then I can probably convert that to C pretty easily so I can link it directly with propeller-load to avoid having to shell out to openssl.
Presumably you would not use the opensll program but rather libssl which I guess enables you to do all of that stuff from within the loader program. libssl just becomes another dependency when building the loader.
Hmm...does this signing business belong in the loader or a separate signing program? Or both or what?
Presumably you would not use the opensll program but rather libssl which I guess enables you to do all of that stuff from within the loader program. libssl just becomes another dependency when building the loader.
Hmm...does this signing business belong in the loader or a separate signing program? Or both or what?
I think the loader at least needs to be able to sign with the default key. We could use a separate program to sign with a real key.
Edit: Also, good point about using libssl. If that is available for all three platforms it would certainly be the way to go for propeller-load and probably Catalina's payload program as well.
Thankyou Chip and JMG. Some good ideas there. I'll buy an AD7401 instead - It takes a clock as an input. I'll be able to dictate the timings better that way. And what's more I think I'll have a play using a Prop1 Cog to bit bash it instead trying to fiddle the counters.
Most Linux distributions install OpenSSL by default, if not you generally only need to add the 'openssl', 'openssl-libs', and 'openssl-devel' packages for the full monty.
When originally conceiving how the code signing and encryption might work from an end user perspective (developer), I imagined using a wizard program written in C with Qt to implement this.
I might actually consider writing it in Python for ease of development and make it simpler for people to modify. In any outcome, the idea would be to have a signing program that could help manage keys and do all the heavy lifting, then the loader simply needs to write to flash. Since the loader doesn't need any crypto, because the chip does everything on bootup, it can be simple and focused at the specifics.
The important part is to have a program that can generate a binary image to give to the loader, perhaps I'll put together a script that uses openssl today, so at least there's a simple and direct way of testing.
I'm not sure that a separate program will work well in a development environment. There is a "run" button in SimpleIDE that downloads a program to the chip and starts it running. We wouldn't want to have to write the generated program to a file and then run a Qt app to sign it on every download. I think it's important for the loader to be able to at least sign images with a default key during development. Signing with a real key for generating production images could be handled by this Qt app. Does that make sense?
On a new Prop2 chip, the security bits are all cleared, so the initial 128-bit key needed for generating the signature is $00000000_00000000_00000000_00000000. On the FPGA, I changed the ROM so that it just looks for eight $00000001's in $1F8..$1FF, so that nobody had to deal with creating HMAC signatures. Once you have to HMAC/SHA-256 code written, it's just one call to sign your loader.
Pedward figured all this out a year ago and wrote an initial Prop1 PASM implementation which I used as stock for making the Prop2 implementation. Many thanks for Pedward for getting all this stuff figured out. It was the right solution to a complicated problem which had hung around for a long time.
On a new Prop2 chip, the security bits are all cleared, so the initial 128-bit key needed for generating the signature is $00000000_00000000_00000000_00000000. On the FPGA, I changed the ROM so that it just looks for eight $00000001's in $1F8..$1FF, so that nobody had to deal with creating HMAC signatures. Once you have to HMAC/SHA-256 code written, it's just one call to sign your loader.
Pedward figured all this out a year ago and wrote an initial Prop1 PASM implementation which I used as stock for making the Prop2 implementation. Many thanks for Pedward for getting all this stuff figured out. It was the right solution to a complicated problem which had hung around for a long time.
Sounds like signing with the zero key should be easy if we link in libssl so that's what I'll plan to do in propeller-load. I'll leave signing with real keys to the Qt app.
Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken
Thankyou Chip and JMG. Some good ideas there. I'll buy an AD7401 instead - It takes a clock as an input. I'll be able to dictate the timings better that way. And what's more I think I'll have a play using a Prop1 Cog to bit bash it instead trying to fiddle the counters.
That variant would work better on a Prop1, but could be used with Counters with care.
The fish-hook is the delay from clk to data change, is spec'd at more than one nominal Prop clk, and you do not want to ever be right on that change.
However, the data is still stable during CLK=L, and the Prop 1 counter has Logic modes, so you can
a) Generate 10MHz MCLK out, using a Binary NCO
b) Use a LOGIC A & !B counter mode, !B is the MCLK pin, A is MDAT
(I'm assuming a CLK out from a Prop, is always GATE legal in IP delay terms)
That counter will increment when MDAT is high, 4 clocks at a time. (with 4 clk pauses)
Run for some fixed time (eg SysCLK/2^19), and read the LOGIC mode counter and >> 2 for direct Logic value.
Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken
Hehe, no tracking number ?
Could have raised all sorts of flags, at FedEX by crashing their tracking system !!
( It could already have landed, as I see the Date is two days ago, on Taiwan's side of the date line.)
Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken
Fingers and toes crossed! Good luck Parallax, you guys deserve every success and thanks for sharing
Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken
Many thanks for sharing such developments with us!
Comments
Thanks for the test socket pointers, Guys.
I think the AD7400 could work, in counter mode, but does ideally need CLK and CLKEN signal connection to P2 counter.
Actually 2 counters, as the MCLKOUT is somewhat variable, you would feed MCLKOUT to 2 Ctrs, and one would be always Enabled, the other is MDAT enabled. Now the counter ratio, is the voltage ratio.
In use, you would wait for 2^16 MCLK edges, then read the other (gated) counter A reading rates ~152Hz
HW capture of Enabled counter on the other Ctr overflow, would give values with no software overhead.
Can the P2 do that ? ie External clock to 2 counters, and also CLKEN to one ?
AD7400 says :
A differential signal of 0 V results (ideally) in a stream of 1s and 0s at the MDAT output pin.
This output is high 50% of the time and low 50% of the time.
A differential input of 200 mV produces a stream of 1s and 0s that are high 81.25% of the time.
A differential input of −200 mV produces a stream of 1s and 0s that are high 18.75% of the time.
Addit: I see the MDAT changes after MCLK _/= and is stable when MCLK=L, so for Prop1 (and if P2 has no CLKEN), you could use a 1G57 universal Logic gate for
GCLK = MDAT & !MCLK,
and GCLK can feed any Prop Ctr.
Is it possible to let the counter count to 1024 or higher?
Sure.
You can even run two time bases in SW - sample at say 2^16 (or less) for faster readout, using difference reading, and keep a slower total, perhaps over 0.5 second, for highest precision.
In reading the AD7400 datasheet, it mentions needing a special digital filter chip, which can be one of their products or an FPGA of your own. Those filters are huge and complicated, but tied to a 2nd-order delta-sigma converter you get high-bit-count results much faster than you can with a first-order setup.
I hired a 2nd-order delta-sigma ADC consultant for a day during the development of Prop2's ADC circuit, and it was quickly apparent to me that trying to implement such a thing on every pin would be impractical. So, we have simple first-order modulators.
I really don't know, but I wouldn't be surprised if you could resolve microvolts, after noise is averaged away.
Do you have a description of what the loader needs to do to sign an image before loading it with the real P2 chip?
Thanks,
David
I think the Digital Filter is optional - as you say, you get more bits-per-second with a Filter design, but you can also use a basic counter, given they have a direct % modulation.
With a filter, they say you can get 39KHz word (16b) rates, whilst a counter is 152Hz word rates.
Filters do have a inter-word crosstalk, so do not multiplex well.
Assuming someone did want to do such a filter in a COG, it would need
CLK + DAT shifter, and the Counter version would need CLK, CLK+CLKEN.
Can the P2 support both pathways ? ( CLK + DAT shifter or CLK, CLK+CLKEN Ctrs)
You need to do an HMAC/SHA-256 on the loader's longs ranging from $000..$1F7 using the 128-bit security key, and place it in $1F8..$1FF.
After downloading $200 longs, the booter computes its own HMAC/SHA-256 from the loader's longs in $000..$1F7 using the 128-bit security key. Then, it compares it to what you loaded for $1F8..$1FF. If the signatures match, the loader is run in cog0. If they didn't match and the security key is $00000000_00000000_00000000_00000000, the monitor runs. Else, the part waits for another reset.
For the FPGA version of the Prop2, loader must contain $00000001's from $1F8..$1FF.
I can get more info on the HMAC/SHA-256 procedure. I have it written in Delphi (Pascal), already.
openssl sha256 -mac HMAC -macopt hexkey:00000000000000000000000000000000 foo
explanation:
openssl (the program that contains all the good stuff)
sha256 (the algorithm)
-mac HMAC (tell it to generate a digest using the HMAC protocol)
-macopt hexkey:00000000000000000000000000000000 (this is a hex value, all 128 bits of the secret key)
foo (the file you want to calculate the hash for)
Thanks!
David
Hmm...does this signing business belong in the loader or a separate signing program? Or both or what?
Edit: Also, good point about using libssl. If that is available for all three platforms it would certainly be the way to go for propeller-load and probably Catalina's payload program as well.
Cheers,
Evan
You can find out about OpenSSL here: http://www.openssl.org/
Windows packages are here: http://gnuwin32.sourceforge.net/packages/openssl.htm
OSX comes with an older version of OpenSSL, there are some instructions about updating that here: http://homes.cs.washington.edu/~aczeskis/openssl.html
Most Linux distributions install OpenSSL by default, if not you generally only need to add the 'openssl', 'openssl-libs', and 'openssl-devel' packages for the full monty.
When originally conceiving how the code signing and encryption might work from an end user perspective (developer), I imagined using a wizard program written in C with Qt to implement this.
I might actually consider writing it in Python for ease of development and make it simpler for people to modify. In any outcome, the idea would be to have a signing program that could help manage keys and do all the heavy lifting, then the loader simply needs to write to flash. Since the loader doesn't need any crypto, because the chip does everything on bootup, it can be simple and focused at the specifics.
The important part is to have a program that can generate a binary image to give to the loader, perhaps I'll put together a script that uses openssl today, so at least there's a simple and direct way of testing.
Pedward figured all this out a year ago and wrote an initial Prop1 PASM implementation which I used as stock for making the Prop2 implementation. Many thanks for Pedward for getting all this stuff figured out. It was the right solution to a complicated problem which had hung around for a long time.
40 P8X32C's are headed to Rocklin!!!!
Get NORAD to track Santa because he's somewhere over the Pacific today!!
That variant would work better on a Prop1, but could be used with Counters with care.
The fish-hook is the delay from clk to data change, is spec'd at more than one nominal Prop clk, and you do not want to ever be right on that change.
However, the data is still stable during CLK=L, and the Prop 1 counter has Logic modes, so you can
a) Generate 10MHz MCLK out, using a Binary NCO
b) Use a LOGIC A & !B counter mode, !B is the MCLK pin, A is MDAT
(I'm assuming a CLK out from a Prop, is always GATE legal in IP delay terms)
That counter will increment when MDAT is high, 4 clocks at a time. (with 4 clk pauses)
Run for some fixed time (eg SysCLK/2^19), and read the LOGIC mode counter and >> 2 for direct Logic value.
Hehe, no tracking number ?
Could have raised all sorts of flags, at FedEX by crashing their tracking system !!
( It could already have landed, as I see the Date is two days ago, on Taiwan's side of the date line.)
We're not in the middle of the Walnut Harvest Festival or a Tortilla maker fair someplace, are we? There shouldn't be any distractions!
Fingers and toes crossed! Good luck Parallax, you guys deserve every success and thanks for sharing
Many thanks for sharing such developments with us!
Yup, thar be magic reindeer heddin' this way.