Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • BobC
    Moderator
    Post count: 10
    in reply to: news? #3688

    My brother-in-law works for a small physics startup that in January started looking for another Angel to get through COVID. They wound up getting 3 VCs in March. (The 3 VCs were to ensure share dilution, not to get 3x money.) Not sure how that came to happen (who talked to who), but the money is out there.

    • This reply was modified 5 months, 2 weeks ago by  BobC.
  • BobC
    Moderator
    Post count: 10

    The embedded target environment does chunk well enough, so a handful of SoCs may cover much of it. Selling hard macros should service the gaps well enough, especially if you use standard interfaces, specifically AMBA. The key will be the timely conversion a Mill specification to a hard macro that will work on the client’s fab and process.

    I’m interested in where the smallest viable Mill CPU would fit relative to existing embedded processors (especially the ARM M0-4 family), primarily on the power/performance metric. If my embedded system can get more processing for less wattage, I win. The simplification of both the power supply and thermal management can easily offset a significant cost differential for the processor. Can’t wait to see data from the first complete FPGA implementation!

    Speaking of FPGAs: As a nearly incompetent FPGA designer, I have found it difficult to debug using testbench circuitry, or signal pins and a logic analyzer, or via JTAG. My preferred approach is to always include a rudimentary 8-bit processor within the FPGA to test each subsystem. Once the design works, I use the 8-bit processor for monitoring and logging. The resources used are small, the flexibility huge. And I can write 8-bit code better than I can create FPGA testbenches.

    There have been design situations where I’ve had to consider offloading some processing to an FPGA or GPU, though so far I’ve always been able to squeak by via careful optimization and/or a multicore bump. I’ll be very interested to see the workloads an embedded Mill SoC can support.

    When you mention the influence of the next round of funders, I presume you really mean the influence of the resulting Board of Directors. Even the greatest cash-equity deal can (and should) be sunk by poor BoD nominees or by unwarranted intrusions into the C-suite. I’ve seen the price of errors in this area. One tactic I’ve seen work is to identify BoD members and executives you’d like to have (but who won’t take your calls), then select funders who will recruit them. The same applies to lining up other partners and even early customers: Identify them in advance, then find the funders who can bring them aboard. Funders must provide far more than funding!

    Another thing to be wary of is VCs or banks partnering you with other startups. It multiplies your risk rather than reducing it, since their problems become your problems, and vice-versa. The sole exception is when synergy exists in a merger, which can be a great (optimal?) way to get lots of talent in a single transaction. I once helped with the engineering side of such a merger, and it turned out well for all involved.

  • BobC
    Moderator
    Post count: 10
    in reply to: Pipelining #1267

    You know, just when I think I want to share some insight, I once again realize we’re still chipping flakes from the periphery The Mill’s Big Picture. It’s like every “Ah-ha!” reveals just how much more of this there is to disclose.

    As Ivan repeatedly promised, the lectures are a “gross oversimplification” of The Mill reality.

    The last processors I worked on that were a “compiler writer’s dream” were the CISC VAX and 68K. When Ivan mentioned the B6500, another easy compiler machine, I was immediately thrown back into the reason the B6500 hardware was so expensive: Stack machines are DOA without fast memory, and the fast B6500 memory was terribly expensive. (You could buy slow memory, but why?)

    Then I worked on a CDC machine, and I saw the light: Speed is king, Then you have to do the software. Seymour Cray was my hero. Don’t know Seymour: Check this out:

    I appreciate Ivan’s emphasis on The Mill being a software-driven hardware architecture, but I’m beginning to hunger for some examples (however trivial) of how the hardware implementation will be accomplished. Block diagrams or schematics would suffice, but I’d kill for some VHDL/Verilog to play with.

  • BobC
    Moderator
    Post count: 10
    in reply to: Security #824

    The portal/service concept, along wiht much of hte rest of the Mill security architecture, would appear to be useful as a enhancement/modification to other CPU architectures. It appears to be lighter weight and more powerful than a traditional MMU (well, Memory Protection Unit, since there’s no hardware virtual memory on the Mill).

    The Mill is a 64-bit machine with a massive 60-bit physical address space (“an exabyte should be enough for anybody”), so an MPU is more appropriate. But there are lots of other processor uses that would benefit from a flexible MPU managing non-virtual memory: Just about every embedded system (my specialty).

    Do you think all or part the Mill security model could be usefully ported to 32-bit embedded processors? If so, is MillComputing considering any of the following?

    1. Port Mill innovations to existing architectures (with available IP: ARM, Nios, Mips, etc). (This could allow MillComputing to get fab experience and hardware revenue before the Mill itself is ready for roll-out.)

    2. License Mill innovations to those wanting to incorporate them into existing architectures. (License revenue, like ARM.)

    3. Some combination, where an experienced fabless partner (say, Qualcomm) would get limited Mill IP (for Snapdragon) in exchange for helping push the Mill toward silicon.

    Yes, ARM and Nios already have MPUs available, but they seem primitive compared to the Mill security architecture.

  • BobC
    Moderator
    Post count: 10

    Personally, I’m leery of using other login credentials because of the metadata expansion for honest users. Every credential use lets that service know that their user has used their credential to authenticate at OOTBC.

    After all, it is easy for a less-than-honest person to create a fake account on one of those services, then use it as a credential. So adding an external login authority actually adds little protection for the forum, and only a tiny bit of convenience for users.

    Account creation should certainly require an email address with a validating message, with a captcha for bot resistance. That’s already present, and is pretty much what those other services use.

    Browsers are good at managing login credentials, so there is not even much convenience benefit to using an external authority. The only benefit MAY be for non-browser use, if any such thing is supported by this forum.

    • This reply was modified 7 years, 9 months ago by  BobC.
  • BobC
    Moderator
    Post count: 10
    in reply to: First Thread! #192

    Not only wider, but the size of the avatar should be smaller to permit more posts to fit vertically.

  • BobC
    Moderator
    Post count: 10
    in reply to: First Thread! #185

    What do replies look like?

Viewing 7 posts - 1 through 7 (of 7 total)