On Tuesday, January 12, 2021 at 2:49:26 PM UTC-5, David Brown wrote:> On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote:=20 >=20 > > I typed a reply and when I sent it it crapped out. I'm not typing all t=hat again.=20> > > OK, I suppose.=20 >=20 > Would this be a good time to point out that if you switch to a proper=20 > newsreader like Thunderbird, not only is it much more reliable than=20 > using a web browser, but you don't lose you drafts when your connection==20> to the server has a hiccup? In fact, as drafts are saved automatically=20 > every so often (or when you choose), you don't necessarily lose them=20 > even if the whole machine dies.That's a conversation that *never* gets old. I've used Tbird and it crappe= d out so bad I would have to trash all the history. So I switched to Seamo= nkey which shares a common code base and would work with the history files.= That eventually crapped out too. So phooey on both your houses and I'll = stick with the total piece of crap called Google. One less piece of softwa= re to try to keep working. Life's too short to spend fucking around with c= rap software. =20 The thread has already lost any purpose. In reality I should not have writ= ten the lost post the first time. That's why I didn't retype it.=20 Just like a conversation I've been having with some guys about multipliers = in FPGAs in eevblog. It started with me trying to figure out how to use th= e Gowin DSP units and as I dug through their simulation code it morphed int= o discussions of how the DSP units from various brands support signed vs. u= nsigned multiplies. Finally it turned into a Xilinx vs. Gowin argument com= plete with low level insults such as saying, 'It's very obvious to anyone "= in the know" that you didn't look...' So I won't be replying to that guy= anymore. I actually had already stopped replying to him, but he kept repl= ying to my posts to others. lol =20 The point is both threads have reached a denouement. =20 --=20 Rick C. -++ Get 1,000 miles of free Supercharging -++ Tesla referral code - https://ts.la/richard11209
Achronix Semiconductor in Talks for Merger
Started by ●January 6, 2021
Reply by ●January 12, 20212021-01-12
Reply by ●January 13, 20212021-01-13
On 12/01/2021 21:56, gnuarm.del...@gmail.com wrote:> On Tuesday, January 12, 2021 at 2:49:26 PM UTC-5, David Brown wrote: >> On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote: >> >>> I typed a reply and when I sent it it crapped out. I'm not typing >>> all that again. >>> >> OK, I suppose. >> >> Would this be a good time to point out that if you switch to a >> proper newsreader like Thunderbird, not only is it much more >> reliable than using a web browser, but you don't lose you drafts >> when your connection to the server has a hiccup? In fact, as drafts >> are saved automatically every so often (or when you choose), you >> don't necessarily lose them even if the whole machine dies. > > That's a conversation that *never* gets old. I've used Tbird and it > crapped out so bad I would have to trash all the history. So I > switched to Seamonkey which shares a common code base and would work > with the history files. That eventually crapped out too. So phooey > on both your houses and I'll stick with the total piece of crap > called Google. One less piece of software to try to keep working. > Life's too short to spend fucking around with crap software.Software experiences vary - that's always the case. I have used Thunderbird on perhaps a dozen machines over the last 15 years, and can't remember losing anything with it. (It's not problem free - I've had crashes, and the unpredictable changes to the extension API are a PITA.) But since a news account is based on a server, you can't lose anything more than a few minutes account setup even if the whole machine dies. The same applies to email (at least with sane email setups). Oh, and there are large numbers of newsreader clients. Thunderbird is just a popular modern one. Pick a different one if you don't like it. But this topic never gets anywhere with you. People can give all the advice, suggestions and help they want - you've already made up your mind long ago.> > The thread has already lost any purpose. In reality I should not > have written the lost post the first time. That's why I didn't > retype it. >Threads on Usenet wander - people talk about different topics, inspired by other posts. You don't own a thread, you don't control it, you don't determine what other posters will say, you don't get to decide its purpose or if it has lost it. But you are welcome to say it no longer interests /you/, and bow out of it - perhaps marking the thread as "ignored" (can Google Groups do that? Every real newsreader can).
Reply by ●January 13, 20212021-01-13
"gnuarm.del...@gmail.com" <gnuarm.deletethisbit@gmail.com> writes:> On Tuesday, January 12, 2021 at 3:16:13 AM UTC-5, Anssi Saari wrote:>> I haven't taken a close look but QuickLogic has come out with this kind >> of chip, Cortex M4-F and embedded FPGA on the same chip. Looks like it's >> smaller than a few kLUTs and doesn't have that much in the way of MCU >> peripherals though. >> QuickLogic??? Was that the name some 20 years ago???It's still QuickLogic. I don't know prices though, Mouser lists them as "non-stock, ask for quote".
Reply by ●January 13, 20212021-01-13
On Wednesday, January 13, 2021 at 2:44:23 AM UTC-5, David Brown wrote:> On 12/01/2021 21:56, gnuarm.del...@gmail.com wrote:=20 > > On Tuesday, January 12, 2021 at 2:49:26 PM UTC-5, David Brown wrote:=20 > >> On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote:=20 > >>=20 > >>> I typed a reply and when I sent it it crapped out. I'm not typing=20 > >>> all that again.=20 > >>>=20 > >> OK, I suppose.=20 > >>=20 > >> Would this be a good time to point out that if you switch to a=20 > >> proper newsreader like Thunderbird, not only is it much more=20 > >> reliable than using a web browser, but you don't lose you drafts=20 > >> when your connection to the server has a hiccup? In fact, as drafts=20 > >> are saved automatically every so often (or when you choose), you=20 > >> don't necessarily lose them even if the whole machine dies.=20 > >=20 > > That's a conversation that *never* gets old. I've used Tbird and it=20 > > crapped out so bad I would have to trash all the history. So I=20 > > switched to Seamonkey which shares a common code base and would work=20 > > with the history files. That eventually crapped out too. So phooey=20 > > on both your houses and I'll stick with the total piece of crap=20 > > called Google. One less piece of software to try to keep working.=20 > > Life's too short to spend fucking around with crap software. > Software experiences vary - that's always the case. I have used=20 > Thunderbird on perhaps a dozen machines over the last 15 years, and=20 > can't remember losing anything with it. (It's not problem free - I've=20 > had crashes, and the unpredictable changes to the extension API are a=20 > PITA.) But since a news account is based on a server, you can't lose=20 > anything more than a few minutes account setup even if the whole machine==20> dies. The same applies to email (at least with sane email setups).=20Anything outbound is lost. That's why I never used it for email. That was= the original reason for giving it a spin, to see if it was a suitable emai= l platform. Obviously not. =20 There were many other issues, including the lack of decent support. I use = Eudora which is a great email program, mature enough that I'm accustomed to= the few "eccentricities" (bugs) and it has only lost one piece of mail in = 20 years of use. That's a pretty dang good record.=20> Oh, and there are large numbers of newsreader clients. Thunderbird is=20 > just a popular modern one. Pick a different one if you don't like it.=20I did! =20> But this topic never gets anywhere with you. People can give all the=20 > advice, suggestions and help they want - you've already made up your=20 > mind long ago.LOL You mean you don't have a convincing argument and so you are frustrate= d. Whatever. This is YOUR problem, not mine. I lost a message that was n= ot important anyway. That's not a reason to switch to a newsreader that i= s yet another piece of crap software I will need to waste time setting up, = learning to use, getting used to its "eccentricities", et. al. No thanks.= =20> > The thread has already lost any purpose. In reality I should not=20 > > have written the lost post the first time. That's why I didn't=20 > > retype it.=20 > > > Threads on Usenet wander - people talk about different topics, inspired==20> by other posts. You don't own a thread, you don't control it, you don't==20> determine what other posters will say, you don't get to decide its=20 > purpose or if it has lost it. But you are welcome to say it no longer=20 > interests /you/, and bow out of it - perhaps marking the thread as=20 > "ignored" (can Google Groups do that? Every real newsreader can).I thought that is what I said. The topic had wandered to rather pointless = discussion of a wannabe FPGA/MCU combo that no one will build. Meanwhile G= owin has some reasonable offerings available and they are real as well as a= ffordable. If anyone has a true need for an MCU on an FPGA chip, there are= options at reasonable prices unlike the other vendors who start at rather = higher prices.=20 --=20 Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
Reply by ●January 13, 20212021-01-13
On Wednesday, January 13, 2021 at 5:59:10 AM UTC-5, Anssi Saari wrote:> "gnuarm.del...@gmail.com" <gnuarm.del...@gmail.com> writes:=20 >=20 > > On Tuesday, January 12, 2021 at 3:16:13 AM UTC-5, Anssi Saari wrote:=20 >=20 > >> I haven't taken a close look but QuickLogic has come out with this kin=d=20> >> of chip, Cortex M4-F and embedded FPGA on the same chip. Looks like it='s=20> >> smaller than a few kLUTs and doesn't have that much in the way of MCU==20> >> peripherals though.=20 > >=20 >=20 > > QuickLogic??? Was that the name some 20 years ago??? > It's still QuickLogic. I don't know prices though, Mouser lists them as==20> "non-stock, ask for quote".I was confusing them with Actel which has been swallowed up by bigger fish = two or three times now. Both were antifuse based FPGA companies. The dif= ference is Actel aka =E2=80=8EMicrochip actually makes and sells devices. = From looking at their web page it appears Quicklogic sells IP and you have = to fab your own chips or something. I can't really tell their products fro= m their new ideas. But Mouser is not stocking any Quicklogic devices. It'= s all call for quote. =20 They do list the EOS S3 with the CM4F, but other than the eval board which = may or may not yet be shipping, I don't see where this chip is sold. =20 For my needs this chip falls a bit short with 2.4 kLUT "effective". A desi= gn I need to port to a new device is currently on a 3 kLUT chip using close= to 90%. While in theory some of that design could be moved to the MCU, th= e preference would be to initially port the VHDL without modification. If = it were 4 or 5 kLUT I would take a more serious look at it. Being partly v= aporware at the moment to boot, makes it much less interesting. =20 --=20 Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
Reply by ●January 13, 20212021-01-13
On 13/01/2021 19:22, gnuarm.del...@gmail.com wrote:> On Wednesday, January 13, 2021 at 2:44:23 AM UTC-5, David Brown > wrote: >> On 12/01/2021 21:56, gnuarm.del...@gmail.com wrote: >>> On Tuesday, January 12, 2021 at 2:49:26 PM UTC-5, David Brown >>> wrote: >>>> On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote: >>>> >>>>> I typed a reply and when I sent it it crapped out. I'm not >>>>> typing all that again. >>>>> >>>> OK, I suppose. >>>> >>>> Would this be a good time to point out that if you switch to a >>>> proper newsreader like Thunderbird, not only is it much more >>>> reliable than using a web browser, but you don't lose you >>>> drafts when your connection to the server has a hiccup? In >>>> fact, as drafts are saved automatically every so often (or when >>>> you choose), you don't necessarily lose them even if the whole >>>> machine dies. >>> >>> That's a conversation that *never* gets old. I've used Tbird and >>> it crapped out so bad I would have to trash all the history. So I >>> switched to Seamonkey which shares a common code base and would >>> work with the history files. That eventually crapped out too. So >>> phooey on both your houses and I'll stick with the total piece of >>> crap called Google. One less piece of software to try to keep >>> working. Life's too short to spend fucking around with crap >>> software. >> Software experiences vary - that's always the case. I have used >> Thunderbird on perhaps a dozen machines over the last 15 years, and >> can't remember losing anything with it. (It's not problem free - >> I've had crashes, and the unpredictable changes to the extension >> API are a PITA.) But since a news account is based on a server, you >> can't lose anything more than a few minutes account setup even if >> the whole machine dies. The same applies to email (at least with >> sane email setups). > > Anything outbound is lost. That's why I never used it for email. > That was the original reason for giving it a spin, to see if it was a > suitable email platform. Obviously not.Eh? Lost? If we are talking email, with the normal setup for an IMAP email account you have a "Sent" folder. All outgoing email is copied into that. It's the same system that is used by all webmail solutions, including gmail, and Outlook. I have all the mail that was sent from this email account since I started using it about 15 years ago, all on the server and thus available on any of the many computers I have the account on (and webmail). If we are talking Usenet, I could equally well store sent messages on a server account. I don't bother - the posts are all there on public groups anyway.> > There were many other issues, including the lack of decent support.Decent support for what? Thunderbird handles email fine, and Usenet fine. It has done all I need both professionally and at home for about 15 years. Or do you mean technical support for when things go wrong or you don't know how to do something? I can't say that has been an issue for me - I usually figure things out myself, perhaps with a google search. (Google is great for many things - just not its groups interface.)> I use Eudora which is a great email program, mature enough that I'm > accustomed to the few "eccentricities" (bugs) and it has only lost > one piece of mail in 20 years of use. That's a pretty dang good > record. >Great. Use that. There's no need to change if you are happy with what you have. It wouldn't work for me - AFAIK there is no Linux version, and it doesn't support utf-8. But if those are not features you need, they don't matter. I don't really know how you could "lose" email anyway. You could do it in the days of POP3, but no one has used that for email clients since the days of AOL 3.5" floppies.> >> Oh, and there are large numbers of newsreader clients. Thunderbird >> is just a popular modern one. Pick a different one if you don't >> like it. > > I did! >Which? (Google groups doesn't count as a modern newsreader client.) Xnews and Pan are, I think, two of the most popular cross-platform choices for dedicated Usenet clients (along with the traditional text-based *nix clients).> >> But this topic never gets anywhere with you. People can give all >> the advice, suggestions and help they want - you've already made up >> your mind long ago. > > LOL You mean you don't have a convincing argument and so you are > frustrated. Whatever. This is YOUR problem, not mine.No, I don't have a problem. /You/ do. You lost your message because you use a crappy client. /You/ annoy people because you can't use standard Usenet formatting. (It's not a big problem unless you try to post pre-formatted text or code. Your inability to snip is more annoying, and is a common failing amongst google posters.) I'll admit it is a little frustrating to see someone who is usually smart, technically competent and interested in finding good solutions being so stubborn about wanting to use such a clearly second-rate system.> I lost a > message that was not important anyway. That's not a reason to > switch to a newsreader that is yet another piece of crap software I > will need to waste time setting up, learning to use, getting used to > its "eccentricities", et. al. No thanks. >Maybe you could ask a teenage neighbour kid to show you how to work these newfangled "compootaa" things.
Reply by ●January 13, 20212021-01-13
David Brown <david.brown@hesbynett.no> wrote:> A lot of the available devices are, as Theo says, too limited. PSoC's > have some programmable logic - but its far too limit. It's one thing to > say that the logic makes the device flexible - it can be used for an > SPI, an I²C, a UART, a PWM timer. But competing devices with boring old > fixed peripherals already have an SPI /and/ I²C /and/ UARTs /and/ PWMs. > You don't want programmable logic for these things that are commonly > found as fixed peripherals - you want the logic for odd things.Those hard cores are probably lower power too - if you don't use them they get turned off. FPGA logic is not known for being super low power.> > How many FPGA I/Os > > will require pins? I don't agree with mixing the FPGA I/O pins with > > the MCU peripherals since the FPGA I/Os naturally mux within > > themselves. > > Here I disagree. Mixing FPGA and MCU pins is exactly what I would want. > You'd be free from the usual MCU limitation of having lots of hardware > peripherals but not the right pin mux choices to let you have exactly > the combination you want. And you'd be free to take advantage of > combinations, without having to route signals back on the outside of the > device (say you want to use an internal UART but with the data used to > modulate a carrier signal). You want this kind of routing to be done > internally, not via the pin drivers.By all means implement the MCU pin mux using FPGA routing if you want. That's an argument for the hard MCU to live inside the sea of FPGA, but I'd argue it shouldn't be far from the shore. The default configuration might have the MCU wired to some sensible pins, rather than everything floating unless connected.> Certainly I'd want the MCU to be able to control loading the FPGA image. > > Modern high-end MCUs are now often without flash. You don't want flash > on the same die as the MCU - the optimal production processes for flash > and high-speed logic are too different, and you end up limiting both the > MCU and the flash. Look at the NXP RT10xx series - you have a 600 MHz > Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined > with an external QSPI flash chip, is cheaper than a typical 120 MHz M4 > microcontroller with a fraction of the flash, and the QSPI flash runs > faster than on-die MCU flash. (There are some RT10xx devices which > include flash - it is a separate die, in the same package, which is nice.) > > So external QSPI flash (or external die, internal package) is the way to > go IMHO.It depends where your focus is - my interest is in smaller, PSoC scale, parts (QFN48 sort of thing). You save die area and board complexity with integral flash - yes your parts are slower, but sometimes you don't care about that. For those you might want a flash FPGA, to avoid having to copy configuration as part of a (slow) boot process.> > > Many > > years ago Xilinx was working on partial reconfiguration in a way that > > would allow sections of the chip to be independently designed and > > configured. I think they never got it ready for prime time and only > > really ever saw it in a small number of high volume designs with lots > > of customer hand holding by the Xilinx experts. > > I remember hearing about that kind of thing (Altera had something of > that sort too, I think?). Wasn't it only available on their paid-for > subscription versions of their tools? Keeping a technology out of the > hands of amateurs, learners, experimenters and small users is a > sure-fire way to make sure no one uses it. > > (Even though I haven't used programmable logic much for a long time, I > still try to keep up with what's happening in the FPGA world.)It's actually commonly used these days. A lot of that is for accelerator cards in servers: you program the periphery of the FPGA with the I/Os (PCIe, DDR4, ethernet, etc) and then you can swap in different blocks in the middle for different applications. AWS F1 does this. Another application relevant to this thread is that the newer Intel parts (Arria 10, Stratix 10) which have an ARM core in the middle use partial reconfiguration as part of the boot process. To bring up the ARM, you need to provide it with some RAM. So first of all you configure enough of the I/Os to allow the ARM to get at its DDR4 channels. Then you can boot Linux. Later on you can program up the rest of the FPGA with whatever logic you want to run on it. Linux provides an API where you can funnel bitfiles at the FPGA logic, with associated device tree parts to teach Linux about what hardware it should expect inside.> > That's actually how > > Cypress got started with their PSOC devices. They didn't have the > > fancy software working very well, so they had weekly design seminars > > which were really just conference calls for you to pick the brains of > > the experts. Great way to get started with the parts, but still not > > great in place of workable tools. I believe they have much better > > tools now. I helped someone port a Forth to one of the PSOC ARM > > devices that actually was not programmable in a real sense, it has > > very flexible serial controllers so the same hardware could do SPI, > > UART or I2C if I recall. I figured out how to install a UART so the > > Forth could boot up and give a command prompt. Funny actually. The > > one small family of non-programmable PSOC devices.The PSoCs are interesting in that they have some kind of firmware inside. Different part numbers have different firmware that enable or disable different features. Of course somebody hacked the firmware to enable the features... https://hackaday.com/2017/03/04/reading-the-unreadable-srom-inside-the-psoc4/ Theo
Reply by ●January 13, 20212021-01-13
On Tuesday, January 12, 2021 at 1:56:46 PM UTC-7, gnuarm.del...@gmail.com w= rote:> On Tuesday, January 12, 2021 at 2:49:26 PM UTC-5, David Brown wrote:=20 > > On 12/01/2021 20:03, gnuarm.del...@gmail.com wrote:=20 > >=20 > > > I typed a reply and when I sent it it crapped out. I'm not typing all=that again.=20> > >=20 > > OK, I suppose.=20 > >=20 > > Would this be a good time to point out that if you switch to a proper==20> > newsreader like Thunderbird, not only is it much more reliable than=20 > > using a web browser, but you don't lose you drafts when your connection==20> > to the server has a hiccup? In fact, as drafts are saved automatically==20> > every so often (or when you choose), you don't necessarily lose them=20 > > even if the whole machine dies. > That's a conversation that *never* gets old. I've used Tbird and it crapp=ed out so bad I would have to trash all the history. So I switched to Seamo= nkey which shares a common code base and would work with the history files.= That eventually crapped out too. So phooey on both your houses and I'll st= ick with the total piece of crap called Google. One less piece of software = to try to keep working. Life's too short to spend fucking around with crap = software.=20>=20 > The thread has already lost any purpose. In reality I should not have wri=tten the lost post the first time. That's why I didn't retype it.=20>=20 > Just like a conversation I've been having with some guys about multiplier=s in FPGAs in eevblog. It started with me trying to figure out how to use t= he Gowin DSP units and as I dug through their simulation code it morphed in= to discussions of how the DSP units from various brands support signed vs. = unsigned multiplies. Finally it turned into a Xilinx vs. Gowin argument com= plete with low level insults such as saying, 'It's very obvious to anyone "= in the know" that you didn't look...' So I won't be replying to that guy an= ymore. I actually had already stopped replying to him, but he kept replying= to my posts to others. lol=20>=20 > The point is both threads have reached a denouement.=20 >=20 > --=20 >=20 > Rick C.=20 >=20 > -++ Get 1,000 miles of free Supercharging=20 > -++ Tesla referral code - https://ts.la/richard11209To address the original point: I checked the proposed post-"IPO" valuation= , and it is insane with respect to current revenues. I would advise agains= t investing.
Reply by ●January 14, 20212021-01-14
On Wednesday, January 13, 2021 at 7:05:49 PM UTC-5, Theo wrote:> David Brown <david...@hesbynett.no> wrote:=20 > > A lot of the available devices are, as Theo says, too limited. PSoC's==20> > have some programmable logic - but its far too limit. It's one thing to==20> > say that the logic makes the device flexible - it can be used for an=20 > > SPI, an I=C2=B2C, a UART, a PWM timer. But competing devices with borin=g old=20> > fixed peripherals already have an SPI /and/ I=C2=B2C /and/ UARTs /and/ =PWMs.=20> > You don't want programmable logic for these things that are commonly=20 > > found as fixed peripherals - you want the logic for odd things. > Those hard cores are probably lower power too - if you don't use them the=y=20> get turned off. FPGA logic is not known for being super low power.That's a common misconception. Just like MCUs, FPGAs come in different pow= er consumption lines. The smaller devices have fairly low quiescent power = levels and moderate to low dynamic levels. But people have in their minds = images of the massive FFT machines with heat sinks on the heat sinks. The = Lattice part I used on a board has two options, one with a 1.2V core and th= e same chip that uses an on board regulator so runs from a common voltage b= etween 1.8V and 3.3V. I build it both ways and never see a difference in p= ower consumption. The external regulator is only rated for 50 mA. Neither= device ever gets warm to the touch. =20 Lattice also makes the iCE40 devices with a static current of 100 uA max. = When it was SiBlue they were specing it below 40 uA, but I guess Lattice de= cided there was no market demand and bumped it up. I wanted to build a WWV= B clock using one but never completed the loop on some of the external comp= onents. It would be capable of running on a AA cell for over a year like m= ost clocks even at 100 uA quiescent.=20> > > How many FPGA I/Os=20 > > > will require pins? I don't agree with mixing the FPGA I/O pins with==20> > > the MCU peripherals since the FPGA I/Os naturally mux within=20 > > > themselves.=20 > >=20 > > Here I disagree. Mixing FPGA and MCU pins is exactly what I would want.==20> > You'd be free from the usual MCU limitation of having lots of hardware==20> > peripherals but not the right pin mux choices to let you have exactly==20> > the combination you want. And you'd be free to take advantage of=20 > > combinations, without having to route signals back on the outside of th=e=20> > device (say you want to use an internal UART but with the data used to==20> > modulate a carrier signal). You want this kind of routing to be done=20 > > internally, not via the pin drivers. > By all means implement the MCU pin mux using FPGA routing if you want.=20I was thinking that meant using routing for the pins outside of the FPGA, b= ut running the peripheral I/Os to the FPGA would provide great flexibility = including using them internally in the FPGA. =20> That's an argument for the hard MCU to live inside the sea of FPGA, but I='d=20> argue it shouldn't be far from the shore. The default configuration might==20> have the MCU wired to some sensible pins, rather than everything floating==20> unless connected.=20If it connects to the FPGA routing and the FPGA has lots of I/Os that would= be fine. Not sure what "close to the sea" would even mean in that context= . Routing in FPGAs is usually under a small handful of ns which is invisib= le to most peripherals unless you are talking about 100 Mbps Ethernet. My = thinking is typically for less intense designs. =20 One potential problem is management of the tristate aspects of an I/O. Is = that under FPGA control or MCU control? That might be hard to manage well,= at least in the standard way of having control registers in the MCU while = controlled by discrete signals in the FPGA. =20> > Certainly I'd want the MCU to be able to control loading the FPGA image=.=20> >=20 > > Modern high-end MCUs are now often without flash. You don't want flash==20> > on the same die as the MCU - the optimal production processes for flash==20> > and high-speed logic are too different, and you end up limiting both th=e=20> > MCU and the flash. Look at the NXP RT10xx series - you have a 600 MHz==20> > Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined==20> > with an external QSPI flash chip, is cheaper than a typical 120 MHz M4==20> > microcontroller with a fraction of the flash, and the QSPI flash runs==20> > faster than on-die MCU flash. (There are some RT10xx devices which=20 > > include flash - it is a separate die, in the same package, which is nic=e.)=20> >=20 > > So external QSPI flash (or external die, internal package) is the way t=o=20> > go IMHO. > It depends where your focus is - my interest is in smaller, PSoC scale,==20> parts (QFN48 sort of thing). You save die area and board complexity with==20> integral flash - yes your parts are slower, but sometimes you don't care==20> about that. For those you might want a flash FPGA, to avoid having to cop=y=20> configuration as part of a (slow) boot process.Nearly every part of my designs don't push FPGA speeds. I did have a desig= n with one signal that had 15 ns from the clock in to get data out to the o= ther chip on the other clock edge, similar to SPI but having to decode the = command to select the data. I was worried about making that timing constra= int. =20 A design I'm working on now is using a built in DSP section to do math cloc= ked at 30 MHz while they run at 100's of MHz. No speed issues there. Even= with that the math section will sit idle for 90% of the time. =20> > > Many=20 > > > years ago Xilinx was working on partial reconfiguration in a way that==20> > > would allow sections of the chip to be independently designed and=20 > > > configured. I think they never got it ready for prime time and only==20> > > really ever saw it in a small number of high volume designs with lots==20> > > of customer hand holding by the Xilinx experts.=20 > >=20 > > I remember hearing about that kind of thing (Altera had something of=20 > > that sort too, I think?). Wasn't it only available on their paid-for=20 > > subscription versions of their tools? Keeping a technology out of the==20> > hands of amateurs, learners, experimenters and small users is a=20 > > sure-fire way to make sure no one uses it.=20 > >=20 > > (Even though I haven't used programmable logic much for a long time, I==20> > still try to keep up with what's happening in the FPGA world.) > It's actually commonly used these days. A lot of that is for accelerator==20> cards in servers: you program the periphery of the FPGA with the I/Os (PC=Ie,=20> DDR4, ethernet, etc) and then you can swap in different blocks in the mid=dle=20> for different applications. AWS F1 does this.=20I guess I should look at the Xilinx tools once in a while. I don't have a = use for it now, so no biggie. At the time I was using an FPGA as the inter= face for various interchangeable modules, too small to put an FPGA on each = one. So a new download was required for each combination of peripherals on= four different sites. Lots of FPGA loads to manage.=20> Another application relevant to this thread is that the newer Intel parts==20> (Arria 10, Stratix 10) which have an ARM core in the middle use partial==20> reconfiguration as part of the boot process. To bring up the ARM, you nee=d=20> to provide it with some RAM. So first of all you configure enough of the==20> I/Os to allow the ARM to get at its DDR4 channels. Then you can boot Linu=x.=20> Later on you can program up the rest of the FPGA with whatever logic you==20> want to run on it. Linux provides an API where you can funnel bitfiles at==20> the FPGA logic, with associated device tree parts to teach Linux about wh=at=20> hardware it should expect inside.=20I would have expect the memory interface on the chip to be hardwired. =20> > > That's actually how=20 > > > Cypress got started with their PSOC devices. They didn't have the=20 > > > fancy software working very well, so they had weekly design seminars==20> > > which were really just conference calls for you to pick the brains of==20> > > the experts. Great way to get started with the parts, but still not==20> > > great in place of workable tools. I believe they have much better=20 > > > tools now. I helped someone port a Forth to one of the PSOC ARM=20 > > > devices that actually was not programmable in a real sense, it has=20 > > > very flexible serial controllers so the same hardware could do SPI,==20> > > UART or I2C if I recall. I figured out how to install a UART so the==20> > > Forth could boot up and give a command prompt. Funny actually. The=20 > > > one small family of non-programmable PSOC devices. > The PSoCs are interesting in that they have some kind of firmware inside.==20> Different part numbers have different firmware that enable or disable=20 > different features. Of course somebody hacked the firmware to enable=20 > the features...=20 > https://hackaday.com/2017/03/04/reading-the-unreadable-srom-inside-the-ps=oc4/=20 Those darn hackers!=20 --=20 Rick C. ++- Get 1,000 miles of free Supercharging ++- Tesla referral code - https://ts.la/richard11209
Reply by ●January 14, 20212021-01-14
On 14/01/2021 01:05, Theo wrote:> David Brown <david.brown@hesbynett.no> wrote: >> A lot of the available devices are, as Theo says, too limited. PSoC's >> have some programmable logic - but its far too limit. It's one thing to >> say that the logic makes the device flexible - it can be used for an >> SPI, an I²C, a UART, a PWM timer. But competing devices with boring old >> fixed peripherals already have an SPI /and/ I²C /and/ UARTs /and/ PWMs. >> You don't want programmable logic for these things that are commonly >> found as fixed peripherals - you want the logic for odd things. > > Those hard cores are probably lower power too - if you don't use them they > get turned off. FPGA logic is not known for being super low power.Yes. I think I mentioned low power somewhere (but not clock gating). And the MCU manufacturers already have the modules - the hard macros for die (and these are /tiny/ - therefore virtually free - compared to an FPGA implementation), the documentation, the header files, the driver code.> >>> How many FPGA I/Os >>> will require pins? I don't agree with mixing the FPGA I/O pins with >>> the MCU peripherals since the FPGA I/Os naturally mux within >>> themselves. >> >> Here I disagree. Mixing FPGA and MCU pins is exactly what I would want. >> You'd be free from the usual MCU limitation of having lots of hardware >> peripherals but not the right pin mux choices to let you have exactly >> the combination you want. And you'd be free to take advantage of >> combinations, without having to route signals back on the outside of the >> device (say you want to use an internal UART but with the data used to >> modulate a carrier signal). You want this kind of routing to be done >> internally, not via the pin drivers. > > By all means implement the MCU pin mux using FPGA routing if you want. > That's an argument for the hard MCU to live inside the sea of FPGA, but I'd > argue it shouldn't be far from the shore. The default configuration might > have the MCU wired to some sensible pins, rather than everything floating > unless connected.I'd definitely want /some/ MCU pins to be direct - at the very least, you want everything involved in booting and debugging (including at least one debug UART) and QSPI for reading in your FPGA image. Perhaps it would be better to think of internal FPGA input/output connections as just another option in the multiplexer choices for the MCU peripherals and pins. For a given pin, it might have a multiplexer letting you select GPIO, UART, or SPI - just add FPGA to that list. Similarly, a UART might be able to take its input from pin 10 or pin 25 - just add an FPGA signal to the list.> >> Certainly I'd want the MCU to be able to control loading the FPGA image. >> >> Modern high-end MCUs are now often without flash. You don't want flash >> on the same die as the MCU - the optimal production processes for flash >> and high-speed logic are too different, and you end up limiting both the >> MCU and the flash. Look at the NXP RT10xx series - you have a 600 MHz >> Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined >> with an external QSPI flash chip, is cheaper than a typical 120 MHz M4 >> microcontroller with a fraction of the flash, and the QSPI flash runs >> faster than on-die MCU flash. (There are some RT10xx devices which >> include flash - it is a separate die, in the same package, which is nice.) >> >> So external QSPI flash (or external die, internal package) is the way to >> go IMHO. > > It depends where your focus is - my interest is in smaller, PSoC scale, > parts (QFN48 sort of thing). You save die area and board complexity with > integral flash - yes your parts are slower, but sometimes you don't care > about that. For those you might want a flash FPGA, to avoid having to copy > configuration as part of a (slow) boot process. >Perhaps. But there are no fundamental reasons why you couldn't do as I suggested and put the flash on a separate die, mounted internally in the same package. Even in a QFN48 there is a big difference between the package size and the die size of the chip - there's room for adding another small die. And vertical stacking inside the package is also possible. Multi-die packaging, whether it is side-by-side or vertical stacking, used to be /very/ expensive. But it is becoming a lot more common in a range of devices. I don't think it will be long before we see not just flash dies but also ram dies of some kind inside high-end MCU (and FPGA) packages. The big issue with multi-die is power, but that's not going to be a problem in the sort of things we are envisioning here. Look at the NXP RT1024 to see the concept: <https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1024-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1024> Although the description says "4 MB on-chip flash", it is /not/ on the chip - the die. But it is in the same package. Logically, and in the MCU setup, the flash is an externally connected peripheral. (If anyone has used National Semiconductor COP8 microcontrollers, this was also how they implemented their OTP devices.)>> >>> Many >>> years ago Xilinx was working on partial reconfiguration in a way that >>> would allow sections of the chip to be independently designed and >>> configured. I think they never got it ready for prime time and only >>> really ever saw it in a small number of high volume designs with lots >>> of customer hand holding by the Xilinx experts. >> >> I remember hearing about that kind of thing (Altera had something of >> that sort too, I think?). Wasn't it only available on their paid-for >> subscription versions of their tools? Keeping a technology out of the >> hands of amateurs, learners, experimenters and small users is a >> sure-fire way to make sure no one uses it. >> >> (Even though I haven't used programmable logic much for a long time, I >> still try to keep up with what's happening in the FPGA world.) > > It's actually commonly used these days. A lot of that is for accelerator > cards in servers: you program the periphery of the FPGA with the I/Os (PCIe, > DDR4, ethernet, etc) and then you can swap in different blocks in the middle > for different applications. AWS F1 does this. > > Another application relevant to this thread is that the newer Intel parts > (Arria 10, Stratix 10) which have an ARM core in the middle use partial > reconfiguration as part of the boot process. To bring up the ARM, you need > to provide it with some RAM. So first of all you configure enough of the > I/Os to allow the ARM to get at its DDR4 channels. Then you can boot Linux. > Later on you can program up the rest of the FPGA with whatever logic you > want to run on it. Linux provides an API where you can funnel bitfiles at > the FPGA logic, with associated device tree parts to teach Linux about what > hardware it should expect inside. >The devices I have been thinking about would be a bit smaller - not big Linux systems. But I guess technology often starts at the high-end, high profit devices and rolls down to the mass market.>>> That's actually how >>> Cypress got started with their PSOC devices. They didn't have the >>> fancy software working very well, so they had weekly design seminars >>> which were really just conference calls for you to pick the brains of >>> the experts. Great way to get started with the parts, but still not >>> great in place of workable tools. I believe they have much better >>> tools now. I helped someone port a Forth to one of the PSOC ARM >>> devices that actually was not programmable in a real sense, it has >>> very flexible serial controllers so the same hardware could do SPI, >>> UART or I2C if I recall. I figured out how to install a UART so the >>> Forth could boot up and give a command prompt. Funny actually. The >>> one small family of non-programmable PSOC devices. > > The PSoCs are interesting in that they have some kind of firmware inside. > Different part numbers have different firmware that enable or disable > different features. Of course somebody hacked the firmware to enable > the features... > https://hackaday.com/2017/03/04/reading-the-unreadable-srom-inside-the-psoc4/ >I'll read that link when I get the chance, thanks.
