D
Don Y
Guest
A colleague relayed a message from an old (really old!) client
for whom I\'d designed some custom CPUs, ages ago (in the \"tens
of megahertz\" days!). They wanted to get an idea what it would
cost (NRE+recurring) to do something \"more current\", today.
I\'m not keen on taking on someone else\'s design (I\'ve got
a mixed mode CPU planned for next year), now. So, would just
like to *relay* a quick recommendation (\"buy a *faster* COTS
device and emulate whatever instructions you need; barring
that, use a big/fast/expensive FPGA!\").
Prices on \"faster COTS\" CPUs are easy to come by. Likewise,
FPGAs (though probably need quotes for those kinds of quantities).
What I\'d like is a *rough* rule of thumb I could use to express
the past designs in terms of current FPGA resources. And, from
that, project what they\'d likely need for their newer requirements.
Then, I can give them parts/development costs and use that to
amplify the \"avoid custom\" argument as well as the \"avoid FPGA\"
argument! :> (it\'s silly to be designing CPUs nowadays -- unless
you have huge volumes or special integration concerns)
I\'m not keen on dragging out schematics and counting flip flops,
junk logic, etc. I\'d rather just look up the PO and see what
family of parts was used to ballpark the gate complexity for past
designs. Then, translate this into theoretical FPGA implementation.
And, finally, indicate the sort of COTS device that would be used
*today* to emulate that functionality.
Then, let them \"do the math\".
Processors tend to be heavily into FFs/register files, etc.
So, most of the past designs would have their gates embodied
in FFs with a bit of steering logic and instruction decode
logic. (today, I\'d use a WCS and skip the logic!)
Any *gross* rules of thumb? Within a factor of two would
likely be close enough (as they haven\'t said specifically
what they want so I don\'t have to be specific in my advice! :> )
[I *really* don\'t want to get into a conversation with them
so want to close off discussion pretty completely and not
invite them to add more detail -- for a project that I have
no intention of undertaking!]
for whom I\'d designed some custom CPUs, ages ago (in the \"tens
of megahertz\" days!). They wanted to get an idea what it would
cost (NRE+recurring) to do something \"more current\", today.
I\'m not keen on taking on someone else\'s design (I\'ve got
a mixed mode CPU planned for next year), now. So, would just
like to *relay* a quick recommendation (\"buy a *faster* COTS
device and emulate whatever instructions you need; barring
that, use a big/fast/expensive FPGA!\").
Prices on \"faster COTS\" CPUs are easy to come by. Likewise,
FPGAs (though probably need quotes for those kinds of quantities).
What I\'d like is a *rough* rule of thumb I could use to express
the past designs in terms of current FPGA resources. And, from
that, project what they\'d likely need for their newer requirements.
Then, I can give them parts/development costs and use that to
amplify the \"avoid custom\" argument as well as the \"avoid FPGA\"
argument! :> (it\'s silly to be designing CPUs nowadays -- unless
you have huge volumes or special integration concerns)
I\'m not keen on dragging out schematics and counting flip flops,
junk logic, etc. I\'d rather just look up the PO and see what
family of parts was used to ballpark the gate complexity for past
designs. Then, translate this into theoretical FPGA implementation.
And, finally, indicate the sort of COTS device that would be used
*today* to emulate that functionality.
Then, let them \"do the math\".
Processors tend to be heavily into FFs/register files, etc.
So, most of the past designs would have their gates embodied
in FFs with a bit of steering logic and instruction decode
logic. (today, I\'d use a WCS and skip the logic!)
Any *gross* rules of thumb? Within a factor of two would
likely be close enough (as they haven\'t said specifically
what they want so I don\'t have to be specific in my advice! :> )
[I *really* don\'t want to get into a conversation with them
so want to close off discussion pretty completely and not
invite them to add more detail -- for a project that I have
no intention of undertaking!]