MCU mimicking a SPI flash slave

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi folks-

I'm hoping to tap into your various experiences to see if what I'm  
thinking is practical.

Our customer has a device into which a Datakey is plugged to extract  
data stored in the device.  The Datakey is a really just a trade name  
for a SPI flash with ergonomic features that resemble a real key (see  
datakey.com).  Our customer would like to replace the Datakey with a new  
design that will transmit the data wirelessly instead of storing it to  
the Datakey SPI flash.

We're proposing a design based on an MCU which will appear as a SPI  
slave flash device, store the data pumped to it from the customer's  
device, and forward it wirelessly.  I'm wondering if it's practical to  
accomplish it.  The firmware would have to be totally responsive  
temporally and in data content.  That sounds like a tough hill to climb  
that requires getting the interface just right, nearly perfect.  I see a  
lot of pitfalls that could make the effort a dead end.

Does anybody have any success or failure stories to relate that would  
help us gauge the feasibility of the proposed design?

Thanks - John Speth

Re: MCU mimicking a SPI flash slave
On 6/14/2017 10:44 AM, John Speth wrote:
Quoted text here. Click to load it

So, the "device" is the SPI master (the Datakey being the first downstream
slave)

Quoted text here. Click to load it

But, the customer owns the IP for the "device"?  I.e., in the best case
(in terms of making YOUR job easier), they could redesign the device
(or its firmware) to be compatible with your new gizmo.  In the worst
case, they would want to make no changes to the "device" and expect
your gizmo to take up the challenge of behaving like a "real" Datakey.

Regardless, as they own(?) the IP for the device, it is possible to
understand EXACTLY how the device expects to interact with a genuine
Datakey and your "replacement" gizmo.  I.e., you don't really have to emulate
a Datakey but, rather, emulate a Datakey AS ACCESSED BY their device.

[This could give you considerable leeway in your implementation without
requiring a change to the "device".]

Quoted text here. Click to load it

Again, thinking worst case...

Your new device would have to be able to emulate the FLASH device (Datakey)
irrespective of the wireless link's functionality.  For example, if the
"device" pushes data into the Datakey at a particular burst rate, you have
to ensure you can accept AND RETAIN that data in the face of a dubious
wireless link.

What happens if the link *never* comes up?
Does the wireless link protocol include acknowledgements of received data?
What if the data (or some portion of it) is not acknowledged in a particular
timeframe (see below)?

Does the device do a read-back of the Datakey to verify the contents written?
Can you use (abuse) this to indicate a confirmation that the link is up and/or
the wireless transmission has completed successfully?

Quoted text here. Click to load it

The first hurdle is looking at the (peak) data rates (and frequencies) from
the "device" and characterize the "typical" and "worst case" traffic.  With
access to the sources (and schematics), you should be able to opine as to
their likely values.  Else, you're stuck with a protocol analyzer (or, a
'scope) and a hopeful attitude that you will actually *see* worst case
examples of these transactions.

 From that, you can determine if you can tackle it with a bit-banging interface.
Or, an SPI tricked to behave as a slave.  Or, as some amount of hardware
assist (external shift register?).

Until you can confidently claim that you can reliably behave as a *local*
SPI slave, the rest of the problem isn't worth evaluating.  Once that's
assured, you can start exploring ways of fitting some sort of acknowledgement
into the existing device's expectations of the Datakey.

(I.e., presumably, it has to deal with defective Datakeys *and* Datakeys
that are withdrawn while a communication transaction is in progress.
Can a Datakey be *bodged* by incorrect usage?  How does their "system"
accommodate this?  etc.)

[You've not mentioned costs, etc.]


Re: MCU mimicking a SPI flash slave
John Speth wrote on 6/14/2017 1:44 PM:
Quoted text here. Click to load it

I have no experience in building such a product, but why not use an actual  
SPI data flash as the intermediate storage while the MCU monitors the action  
and forwards the data?  This would require periods when the MCU could read  
the data flash.  Is that possible or practical?

I had a design that needed a 30 MHz SPI like interface (not entirely  
compatible though) which was designed to read/write registers.  I considered  
using a fast CPU to emulate the interface in software, but it just couldn't  
meet the timing.  Even with a 700 MIPS processor I wasn't sure it could  
receive the command to read a register and then get the data onto the output  
fast enough.  I'm not sure of the timing of the SPI interface you have, but  
it will likely be hard to emulate the SPI in software.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 15/06/17 02:54, rickman wrote:
Quoted text here. Click to load it

That sounds easy for the XMOS processors:
  - multicore (up to 32 100MIPS cores)
  - FPGA-like i/o, e.g. SERDES, buffers, programmable
    clocks to 250Mb/s, separate timer for each port
  - i/o timing changes can be specified/measured in
    software with 4ns resolution
  - guaranteed latencies <100ns
  - *excellent* programming model based on CSP
    (summary: of "Occam in C")
  - Eclipse-based dev environment

Currently I'm managing to count transitions in
software on two 50Mb/s inputs, plus do
simultaneous USB comms to a host computer.


and DigiKey.

Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/15/2017 3:01 AM:
Quoted text here. Click to load it

Any yet the XMOS can't run fast enough to return a result in the time  
available.  What a pity, all dressed up an nowhere to go.


Quoted text here. Click to load it

Can you output a result before the next input transition?



Quoted text here. Click to load it

Not a very good processor to use in cost conscious applications.  The lowest  
price at Digikey is $3 at qty 1000.  They can't make a part in the  
sub-dollar range?

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 15/06/17 17:13, rickman wrote:
Quoted text here. Click to load it

You'll have to explain that, because I don't understand
what you are referring to.



Quoted text here. Click to load it

Yes and no.

Yes: the output (to a host processor and/or LCD)
proceeds in parallel with the next capture phase.

No: in the current incarnation there is a short gap
between capture phases as the results are passed
from one core to another and the next capture phase
is started. While it isn't important in my application,
I may be able to remove that limitation in future
incarnations.



Quoted text here. Click to load it

Don't presume everybody has your constraints.

Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/15/2017 1:01 PM:
Quoted text here. Click to load it

Maybe I don't understand the speed of the XMOS.  Nothing you write above  
says to me it is any faster than the 700 MIPS processor I considered.  
Nothing written above would allow it to perform the task any differently  
than the bit banging approach I initially considered.

So what are you confused about?

Maybe you don't understand the problem.  A bit serial data port (two bits  
wide actually, but that is not relevant) provides data, address and a two  
bit command word serially.  The last bit of the command work is indicated by  
a "command" signal going high during that bit.  Data is clocked in on the  
rising edge of the clock.  When the command word is a read, the read data is  
provided serially starting on the subsequent falling edge.  This provides 15  
ns from rising edge to falling edge.  It is possible to prefetch the read  
data based on the shifted address on each rising edge until the command  
signal is asserted.  This helps with timing of the memory fetch, but still,  
that data has to be presented to the serial port output in 15 ns and updated  
every 30 ns.

I'd like to see code that will make this work.  Or maybe you weren't  
addressing my previous application?  For the OP, can the XMOS emulate a 30  
Mbps SPI port?


Quoted text here. Click to load it

I'm referring to bit I/O using the same 50 MHz clock.


Quoted text here. Click to load it

That's a lot more than a "short" gap in the context of a fast clock.



Quoted text here. Click to load it

I don't, but not everyone has *your* constraints.  If a processor can't be  
sold in a low cost product, it cuts off the largest volume parts of the  
market including the app I am looking at presently.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 15/06/17 22:52, rickman wrote:
Quoted text here. Click to load it

The XMOS devices clock at 500 MHz, with a dual-issue CPU for 1000 MIPS.  
And it really is 1000 MIPS - all code in data is in single-cycle SRAM.  
There is no cache, no prefetches, no branch prediction - everything is  
as fully deterministic as on a simple 8-bit microcontroller.  But that  
does require at least 5 hardware threads - the maximum for a single  
thread is 100 MHz, 200 MIPS.  (Some devices run at 400 MHz, and  
therefore fewer MIPS.  And older devices have only single-issue CPUs.)

The hardware timers, input/outputs, and serial-to-parallel and  
parallel-to-serial converters attached to the IO pins can handle 10 ns  
timing.

Of course, no one had mentioned that so far in this thread - so unless  
you were familiar with the devices, you would not know that.

Quoted text here. Click to load it

The XMOS has parallel/serial converters for every GPIO pin.  For an  
application like this, you would use an 8-bit SERDES on the MISO and  
MOSI pins, and use the clock pin to trigger the transfers.

Quoted text here. Click to load it

Quoted text here. Click to load it

You get a lot for your money with an XMOS - but not every application  
needs that power, and then your money is wasted.  They are certainly not  
as cheap as a small microcontroller, but if the alternative is an FPGA,  
they suddenly look much better value.


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/15/2017 5:37 PM:
Quoted text here. Click to load it

I think you are saying the CPU can do things with a 10 ns time resolution,  
no?  That is the relevant number for this if bit banging the I/O port.  I  
assume the "dual issue" can't simultaneously execute instructions where one  
depends on the result from the other?


Quoted text here. Click to load it

Serial to parallel converters may not help with this design.  Data is 8  
bits, address is 8 bits, command is 2 bits, the incoming data path is 2 bits  
wide, outgoing data path is 1 bit wide.  The design was made to be tolerant  
of extraneous clock edges between words.  The end of the serial transfer was  
flagged by a CMD signal going high on the 2 bit command word transfer.  I  
don't see how an 8 bit serial shift register would help receiving the input  
data even if it were only 1 bit wide (or you use two CPUs) since you can't  
rely on the clock count to always be right, *plus* you get a single clock  
with 2 input bits and a flag to indicate the end of the input transfer.  
Then you have 15 ns (minus setup and hold time on the output pin) to fetch  
the data and start shifting it out.

I recall even in the FPGA I was reading the output of a register mux which  
then had to feed a shift register.  I used another 1 bit mux to select the  
output of the mux for the first bit and the output of the shift register for  
the remaining bits *and* the timing was tight.

The data ports of the design had serial interfaces up to 50 MHz, time  
correlated to a CODEC.  The CODEC received a time code which was transmitted  
along with the digital data in packets over IP.  The same board on the other  
end received the packets and reconstructed the data and time  stamp.

Once an FPGA was on the board there was no reason to use a CPU, although I  
would have liked to have a hybrid chip with about 1000-4 input LUTs and a  
moderate CPU or DSP even.  Add a 16 bit stereo CODEC and it would be perfect!


Quoted text here. Click to load it

Quoted text here. Click to load it

I wonder why they can't make lower cost versions?  The GA144 has 144  
processors, $15 @ qty 1.  It's not even a modern process node, 150 or 180 nm  
I think, 100 times more area than what they are using today.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 16/06/17 00:15, rickman wrote:
Quoted text here. Click to load it

Yes, that sounds right.

Quoted text here. Click to load it

It sounds like a particularly challenging design you have here.  The
XMOS will let you do many things an ordinary microcontroller cannot, but
it can't do /everything/ !  There are some timing requirements that are
impossible without programmable logic.

Quoted text here. Click to load it

Often a soft processor can be enough for housekeeping, but an FPGA with
a fast ARM core would be nice.  Expensive, but nice.

I think Atmel/Microchip now have a microcontroller with a bit of
programmable logic - I don't know how useful that might be.  (Not for
your application here, of course - neither the cpu nor the PLD part are
powerful enough.)

Quoted text here. Click to load it

I guess it is the usual matter - NRE and support costs have to be
amortized.  When the chip is not a big seller (and I don't imagine the
GA144 is that popular), they have to make back their investment somehow.

Have you used the GA144?  It sounds interesting, but I haven't thought
of any applications for it.


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/16/2017 3:25 AM:
Quoted text here. Click to load it

I think it would have been possible with the GA144 and the 700 MIPS peak  
rate, but it depended on the I/O timing which I couldn't get them to  
provide.  They suggested I build one and test it!  lol


Quoted text here. Click to load it

Not sure what you mean by a "fast" ARM core, but ARMs combined with FPGAs  
are sold by three of the four FPGA companies.


Quoted text here. Click to load it

You might be thinking of the PSOC devices from Cypress.  They have either an  
8051 type processor or an ARM CM3 with various programmable logic and  
analog.  Not really an FPGA in any sense.  They can be programmed in  
Verilog, but they are not terribly capable.  Think of them as having highly  
flexible peripherals.

If you really mean the Atmel FPGAs, they are very old, very slow and very  
expensive.  I don't consider them to be in the FPGA business, they are more  
in the obsolete device business like Rochester Electronics.  The device line  
they had that included a small 8 bit processor is long gone and was never  
cost competitive.


Quoted text here. Click to load it

I'm talking about the XMOS device.  The GA144 could easily be sold cheaply  
if they use a more modern process and sold them in high volumes.  But what  
is holding back XMOS from selling a $1 chip?  My understanding is the CPU is  
normally a pretty small part of an MCU with memory being the lion's share of  
the real estate.  Even having 8 CPUs shouldn't run the area and cost up  
since the chip is really all about the RAM.  Is the RAM special in some way?  
  I thought it was just fast and shared through multiplexing.


Quoted text here. Click to load it

There are a number of issues with using the GA144 in a production design.  
Not the least is the lack of reliable supply.  The company runs on a  
shoestring with minimal offices, encouraging free help from anyone  
interested in writing an app note.  lol  When they kicked off the GA144  
there was a lot of interest from fairly fringe groups of designers (the  
assembly language is pretty much Forth) but I have yet to hear of any  
designs reaching production which is not the same thing as there being none.  
  The production runs appear to be the minimum size test runs from the  
foundry.  The chip is pretty small, so they get a *lot* from a wafer.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 16/06/17 19:52, rickman wrote:
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

By "fast", I mean "so much faster than strictly needed for the job in  
hand that you don't need to worry about speed" :-)

Alternatively, a Cortex-A core with Neon is "fast".

Quoted text here. Click to load it

No, I mean the new Atmel XMega E series.  They have a "custom logic  
module" with a couple of timers and some lookup tables.  It is not an  
FPGA - it's just a bit of programmable logic, more akin to a built-in PLD.

Quoted text here. Click to load it

No, I know about that line too (never used it, but I know of it).

Quoted text here. Click to load it

It is a fast RAM - the one RAM block runs at 500 MHz single-cycle, and  
may be dual-ported.  There is only one cpu on the smaller XMOS devices,  
with 8 hardware threads - larger devices have up to 4 cpus (and thus 32  
threads).  The IO pins have a fair amount of fast logic attached too.

But I don't know where the cost comes in.  The XMOS devices are, I  
guess, a good deal more popular than the GA144 - but they are not mass  
market compared to popular Cortex-M microcontrollers.

Quoted text here. Click to load it


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/18/2017 4:56 PM:
Quoted text here. Click to load it

Have you looked at the ARM + FPGAs offered by the mainstream FPGA vendors?  
The ARMs in the Xilinx and Altera/Intel parts are high end like the Cortex-A  
devices.  The Microsemi part is a CM3 or CM4, I forget which.


Quoted text here. Click to load it

I wouldn't even say the logic is comparable to a PLD type device other than  
a very, very simple one.  It only includes two LUTs.  This is more like a  
very lame Cypress PSOC device.  Actually Cypress makes one sub-family of  
PSOC devices that actually have no programmable logic as such.  They just  
have some peripherals that are very configurable, like it can be SPI or I2C  
or a couple of other serial devices, but no general logic.


Quoted text here. Click to load it

It doesn't have to be 100's of millions to be cost effective.  The GA144  
isn't even in the running.  But any practical MCU needs to be sold in  
sufficient quantities to make it affordable and for the company to keep  
running.


Quoted text here. Click to load it


--  

Rick C

Re: MCU mimicking a SPI flash slave
On 19/06/17 06:21, rickman wrote:
Quoted text here. Click to load it

Yes, I know.  (Perhaps you interpreted me to mean "it would be nice if
someone made an FGPA with a fast ARM core".  I actually meant "an FPGA
with a fast ARM core would be nice for this sort of application".)

Quoted text here. Click to load it

It is programmable logic, even though it is small.  And unlike the PSoC,
it is a supplement to a range of normal microcontroller peripherals and
the AVR's "event" system for connecting peripherals.  The idea is that
this logic can avoid the need of glue logic that you sometimes need
along with a microcontroller.  I think it is a neat idea, and if it
catches on then I am sure later models will have more.

Quoted text here. Click to load it

Again, I don't know the numbers here.  XMOS has been running for quite a
few years, with regular new products and new versions of their tools, so
they seem to be doing okay.


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/19/2017 3:02 AM:
Quoted text here. Click to load it

Small is not the word.  The PSOC is enormously more capable and *that* is  
small.  I'm not sure of the purpose of the distinction when you say  
"supplement to a range of normal microcontroller peripherals".  Why a need  
for "normal" peripherals?  The point of the PSOC is they can offer  
flexibility so your design can use what it needs without a lot of wasted  
silicon for peripherals that aren't used.  Instead they "waste" silicon by  
making the peripherals programmable.  In the process you get a degree of  
flexibility not found other than in FPGA type programmable logic as well as  
analog programmability you can only find in discrete analog chips.


Quoted text here. Click to load it

The issue I have isn't that they aren't stable, but that they don't seem to  
be able to produce a device price competitive with the lower end device.  
For me that make FPGAs a more viable solution economically for the large  
majority of designs.  Combine that with the large learning curve and we end  
up with many users never taking the time to become proficient with them.  If  
they get priced down to the $1 range, they will get a *lot* more users and  
sales.

Likewise, if they did a shrink to make the GA144 more cost competitive a lot  
more users would be interested in learning how to program the device.  But  
it would still be a very ugly duckling requiring a whole new approach to  
complex systems.  The inability to draw on the huge base of established  
software make the GA144 a non-starter for many apps.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 19/06/17 14:36, rickman wrote:
Quoted text here. Click to load it

What you get with the PSoC is a chip that can give you a couple of
specialised custom-tuned peripherals if that is what your application
needs, or 2 or 3 standard peripherals (timers, uarts, SPI, etc.) for the
silicon, power and dollar cost of 20 standard peripherals on a "normal"
microcontroller.  A fixed UART or 16-bit timer is /much/ more efficient
than one made from flexible digital cells and all the programmability
needed to make them into the same type of peripheral.

When you need a custom peripheral of some sort, then the flexibility of
a PSoC is (presumably) great.  But only then.

Quoted text here. Click to load it

I agree with you - and as I say, I don't really know why they can't make
(or sell) the chips for a lower price.

Quoted text here. Click to load it

Nah, the GA144 would not be popular even if they /paid/ people to use
them.  Less unpopular, perhaps, but not popular.


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/19/2017 8:47 AM:
Quoted text here. Click to load it

So programmability in the PSOC is a niche feature while programmability in  
the XMega E is somehow a big feature?

I think you may have missed some of the PSOC devices, like 90%.  One  
subfamily of about four devices have programmable peripherals.  The others  
have programmable logic and analog blocks.  Much more powerful.


Quoted text here. Click to load it

That much processing power in a very low cost device would become useful in  
many apps.  It is odd and difficult to learn, but it is not without  
functionality and application.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 19/06/17 15:23, rickman wrote:
Quoted text here. Click to load it

No, the small programmability of the XMega E is a nice addition to all
the other peripherals.  Without its timers, communications, ADCs, DMA,
etc., it would be a very poor microcontroller.

The small programmability of the PSoC is niche because it has its
programmable blocks /instead of/ ordinary microcontroller peripherals.
If they were on top of a base of solid standard peripherals, the
programmable blocks would be much more interesting.

Quoted text here. Click to load it

Well, I disagree.  I think the individual cpus are too weak to be
practical.  It does not really matter if they can do simple operations
at 700 MHz if they can't do more than a few dozen lines of code.  There
are not nearly enough processors on the chip, a far, far too little
communication channels between nodes, to be useful despite the small
memory size.



Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/19/2017 9:34 AM:
Quoted text here. Click to load it

I don't follow.  What can the XMega E do that the PSOC devices can't in  
terms of peripherals?


Quoted text here. Click to load it

Is an Ethernet interface an adequate indication of functionality?  I think  
that is more than "simple" operations, no?

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 20/06/17 06:16, rickman wrote:
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

It is a good while since I have looked at PSoC devices, and my
comparison was with the older 8-bit and 16-bit core devices (not
entirely unreasonable, since the XMega is an 8-bit device).  The key
difference is that the PSoC can have a couple of UARTs /or/ a few PWM
timers /or/ a couple of SPI interfaces /or/ other digital interfaces
with customisation.  The XMegaE can have a couple of UARTs /and/ some
PWM timers /and/ a couple of SPI interfaces /and/ a bit of customer
hardware.  Now do you see the point?

Now that I have looked at the PSoC website, I see that for their ARM
Cortex devices, Cypress have figured this one out and have dedicated
standard peripherals in additional to the programmable blocks - because,
as I have said all along, these are /far/ more efficient.

Quoted text here. Click to load it

OK, I admit to being impressed by that possibility.  It is 10 Mb, needs
external ram, and has little additional possibilities beyond simple UDP
telegrams, but I am still impressed.

(For comparison, the XMOS can do a software 100 Mb NIC in about half of
a cpu, letting you run lwip and network software in the other half.  But
if you really want Ethernet on an XMOS device, you are better off with
the chips that have a dedicated hardware Ethernet interface.)

Site Timeline