Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Michael Karas
06/01/13 08:24
Read: 1128 times
Beaverton Or

Msg Score: +1
 +1 Informative
#189843 - Reality Check......
Responding to: JosÚ A. Ruiz's previous message
Jos´┐Ż A. Ruiz said:
Hello all,
All advice is welcome, thank you for your thoughts!

There is such a lack of good dialog here at this site now that it is in slow die more.

Maybe this can get a good discussion going....

I would like to veer off the direct topic of your question and ask why you feel it productive to put energy into placing an 8051 core into an FPGA?

I have found it rare to be the case that such usage model makes a lot of sense. My experience has shown that it can make a lot more sense to use a well validated commercial part in a design to contain the code and then have this MCU interface to an FPGA for that special high performance circuitry that must be done there for either performance or density requirements.

Even though FPGA costs per glob of gates are continuing to come down in price it is still more expensive in terms of silicon cost to embed a microcontroller core into an FPGA as opposed to using an external commercial chip. The wide range of available commercial chips, both in terms of cost and capabilities, lets you easily select the appropriate part to connect to the FPGA. You can interface via slower serial links (SPI, I2C etc) or via an actual bus structure. For example many of the higher end SiLabs parts support an optional external BUS interface that can map your XRAM data space directly into the FPGA in a glueless manner.

With the use of the commercial MCU parts you get to retain the best selection of development tools, debugger capabilities and choice of free/commercial compiler/tool sets. You completely eliminate the pain in the a$$ issue that you are dealing with right now.

One argument often put forth for putting the MCU core into an FPGA is that the eventual goal is to advance to a custom made chip. That is all well and good but might I suggest that it may be a good idea to develop a separate firmware development platform using a well supported MCU mated with an FPGA where you can retain the best of the tools needed to develop good code. Once code is validated in such environment it can be moved over in object form to the custom chip environment where it can be tested and validated. For this mode of testing you rarely need to have the ability to look at MCU registers and step code after breakpoints!

If the custom chip environment needs validation visibility then design that into the firmware and its supporting hardware as a validation specific tool/interface. This is much simpler than trying to go through the pain of what you are asking about here.

List of 23 messages in thread
OCD for FPGA core      JosÚ A. Ruiz      06/01/13 03:48      
   Serial-to-EC2 reverse engineering      JosÚ A. Ruiz      06/01/13 06:12      
   C2spec.pdf      Jim Granville      06/01/13 06:36      
   Reality Check......        Michael Karas      06/01/13 08:24      
      Agreed      JosÚ A. Ruiz      06/01/13 12:53      
         multi-threaded      Jim Granville      06/01/13 16:54      
      FPGA and soft cores      Oliver Sedlacek      06/03/13 02:20      
         Yes ... but which debugger?       Richard Erlacher      06/03/13 10:48      
            Actually no      Oliver Sedlacek      06/04/13 01:55      
               Who's "they"      Richard Erlacher      06/04/13 12:48      
               I wouldn't use FPGA unless I need more than just the core      Richard Erlacher      06/07/13 14:50      
                  FPGA on-chip debugging redundant?      JosÚ A. Ruiz      06/14/13 02:49      
                  debugging embedded processors        Andy Peters      06/25/13 18:56      
                     That's good to know.      Richard Erlacher      06/26/13 11:13      
   nice idea      Maarten Brock      06/02/13 07:03      
      Von Neumann first      JosÚ A. Ruiz      06/02/13 10:23      
   if that were the case ...      Erik Malund      06/03/13 15:19      
      Poorly chosen acronym...      JosÚ A. Ruiz      06/14/13 02:59      
         On Chip Debug is common        Jim Granville      06/14/13 03:44      
            On Chip Debug *is* a very good idea indeed!      Andy Neil      06/15/13 13:44      
               PC        Maarten Brock      06/15/13 14:09      
                  PC        Michael Karas      06/17/13 06:55      
                     PC        Oliver Sedlacek      06/18/13 02:19      

Back to Subject List